Talk Lowy(kr)

Nodejs에서 만든 프로젝트를 github에 올리면 CI/CD처럼 받아 백그라운드에서 지속 실행 보통 nodejs를 서비스로서 실행하는 서비스를 설치하거나 jenkins등을 이용해서 설치하는 방법이 있으나, giip를 이용해서 간단하게 실행하는 방법을 소개합니다. giip가입 및 Logical Server 생성 https://github.com/LowyShin/giipdoc-ko/wiki/%EB%B9%A0%EB%A5%B8-%EC%8B%9C%EC%9E%91 양은 좀 많지만 어렵지 않으니 따라하시기 바랍니다. giipAgentLinux 를 서버에 설치 1번의 링크를 따라하면 giipAgentLinux를 서버에 설치까지 끝납니다. git clone으로 첫 소스 가져옴 git clone명령을 사용하여 서버에서 소스를 우선 가져옵니다. mkdir -p /usr/projects cd /usr/projects git clone https://github.com/LowyShin/myprj.git git clone에서 권한등의 이유로 막혀있다면 아래 링크를 참조하여 ssh-key를 등록해 주셔야 합니다. https://github.com/LowyShin/KnowledgeBase/blob/master/dic/g/git.md#account 소스 위치와 스크립트의 위치를 맞출 필요가 있습니다. 만약 맞추기 귀찮다면  mkdir -p /usr/projects  라고 생성해서 그 위치에서 git clone을 하면 편리합니다. node를 기동하는 스크립트 작성 https://github.com/LowyShin/giip/blob/gh-pages/giipscripts/sh/nodejs-githubsyncandrun.sh 위 링크에 있는 소스를 그대로 복사해서  Automation > AddScript  에 등록 합니다. 등록 방법은 1번에 있는 Quick Start의 하단의 [서버 정보 취득 스크립트의 등록]을 참고하세요. 기동하지 않는다면 이슈에...

서버 관리를 하다보면 주기적으로 또는 특정 상황마다 사소한 정보를 보기 위해 서버에 들어가서 확인을 해야하는 경우가 종종 발생한다. 요즘 대부분의 DevOps를 활용하면 이런 불편함이 해소되긴 하지만.. 중요한 것은 DevOps를 준비하기 위해 다시 공부가 필요하고, 설정이 필요하고 노가다가 필요해진다. 적은 숫자의 서버를 관리하는 입장에서는 그럴 필요가 전혀 없음에도 불구하고 해야 하는 상황이 발생한다. 때문에 서버 관리의 방법론은 규모나 상황, 서비스 특징 등등에 따라 무한대의 경우의 수를 가지게 된다. 여기서 서버의 정보를 가져오는 두 가지 팁을 소개하려 한다. 하나는 서버에서 보내는 방법. 또 하나는 내가 가져오는 방법. 어짜피 노가다 아니냐고? 나의 궁극의 빈둥을 실현하기 위해 이 방법보다 편할 수 없는 방법을 소개하려 한다. (블로그 글 조차 쓰기 귀찮아서 관리가 안되는...) 두 가지 모두 공통으로 필요한 것이 있다. 우선 github에 계정을 만들자.. (개발자라면 거의 가지고 있겠지만, 서버 관리자들은 안가지고 있는 케이스가 많으나 만들자!) 혹시 보안때문에 정보를 올릴 수 없다면 자체 서버에 gitlab을 설치해서 운영해도 똑같이 쓸 수 있다. 관리 서버가 수천대가 되면 그룹으로 관리하지 않으면 더욱 힘들어진다. 서비스나 용도 등에 맞추어 repository를 만든다. 이번에는 파일서버로 하겠다. A, B 두 대의 서버를 gpfs용으로 사용하기로 한다. gpfs가 뭐냐고? 내가 만든 용어다. 무시해라. (giip file system...) 1. 서버에서 보내는 방법. 서버에 github계정 설정을 해두면 로그인 정보 없이 명령을 날릴 수 있다. 우선 linux를 예로 들면.. root로 접속 후 echo " machine github.com " > ~/.netrc echo " login ai@netbako.com " >> ...

소스에 코멘트를 달다보면 끝이 없기 때문에  상세사양을 따로 적습니다. 여러분은 github의 README.md 에 상세를 기입하시나요? 아니면 github의 wiki에 상세를 기입하시나요? 여기서 명확한 답이 아직 서지 않았는데.. README.md에 내용을 넣다보면 소스와 같이 관리되는 장점이 있지만,  README.md만 갱신해도 commit회수가 늘어나고 지나치게 README.md가 늘어날 수가 있습니다.  Func.md 등 여러 파일로 나누어 관리하는 것도 방법이지만,  소스의 파일이 많아지게 되네요. github wiki를 사용하게 되면 wiki에 걸맞는 여러가지 기능을 활용할 수 있는데. (sidebar나 footer 등) 소스와 따로 관리를 하게 되므로 관리 포인트가 늘어납니다. 그래도 github답게 wiki조차도  다른 git으로 통으로 내려받고 관리가 되네요. MSA를 추구하게 되다보니  저 같은 경우는  root 디렉토리에서 공통 파일을 넣은 core.git과 각각의 모듈들을 각각의 directory로 관리합니다.  관리가 쉽도록  directory name = repository name  으로 관리 중이구요.. (giip는 구 버전 구조라 service별로 쪼개지고  virtual directory구조임) 무엇이 대세다.. 라는 것은 웃기는 얘기구요.. 대세 따라갈 실력도 없으면서 뭐 만든 사람이 했다 라는 이유로 맹목적으로 따라가는 것을 보면.. 언제나 고민해야 하는 것은 이게 MSA가 되었을 때  어떻게 활용해야 심플하면서 확장성이 높은가? 그리고 노드가 망가졌을 때  다른 노드에 무엇만 올리면 되는가? 내가 100개의 노드를 가지고 있다면 이를  ...

요즘 많은 백서의 기술 검증을 하고  여러 ICO에서의 설명을 듣고,  Github에서 소스를 내려받으면서  실제 소스를 보고 있습니다.  Genesis 블럭은 어떻게 만들고 있는지? 기본 구조는 몇 세대 체인 구조를 가지고 있는지? DAG이 최선? 고속 합의 및 용량 제약을 풀어낸  DAG이 IOTA덕분에 좀 활기를 치고 있지만,  최초의 DAG Whitepaper에서도 언급했던 것 처럼 이건 이론일 뿐이고 실제로는 어떻게 될지 모릅니다.  즉, 현재 국내 DAG구조를 발표한 백서에서  DAG원래 취약성의 보완 방법을 언급한 Whitepaper는 못봤습니다.  블록체인이 최고인양,  블록체인이 최첨단 기술인양 자기의 비즈니스를  억지로 구겨넣고 있는 모습을 많이 봅니다.  블록체인은 어떤 단점이 있는지조차 모른채.. 블록체인의 중요한 단점은 다음과 같습니다.  1. 블록체인은 Transaction이 느릴 수 밖에 없다! 요즘 들어 TPS(transaction per second, 초당 처리수) 우위로  광고하는 블록체인들이 늘고 있습니다.  5000TPS? 어떻게 그렇게 구현할 수 있죠?  github에 구조좀 공개해 주세요!  5000이라고 얘기한 것은 아마  Open source RDB의 TPS허용량을  기준으로 얘기한 것일 겁니다.   그렇다면 그냥 RDB라고 하지..  블록체인은 구조상  네트워크로 요청을 보내서  여러 네트워크에 오는 결과의  정합성을 검증하여 참을 가리는  합의 프로토콜을 가지고 있습니다.  즉, 아무리 가까운 곳에...