NAS로 gitlab-postgres 데이터 이전 중 DB 기동 실패

개요

• 기존 Node1에서 돌던 Redis 및 Node2에서 돌던 PostgreSQL(이하 PG), gitlab의 데이터를 NAS로 이전

• Redis의 경우 4.0.7 버전을 사용중에 중지시키고, 예전에 사용했던 YAML파일을 복사해 붙여넣기 하다가 3.0.7 버전으로 사용하는 바람에 개발규칙-참고 페이지가 불능이 되었던 사태가 있었음 → redis 버전을 제대로 되돌려주니 해결됨

• PG의 경우 기존 Deployment, replica=1으로 실행되던 것을 replica=2로 HA구성을 위해 바꾸었으나 조부장님 컴퓨터에서 깃랩이 자주 팅기는 현상이 발생함(난 안그랬음)

• 그래서 Deployment를 StatefulSet으로 변경하고 replica=2를 주었더니 CrashLoopBack과 함께 컨테이너가 시작되지를 않음.

PANIC: could not locate a valid checkpoint record

해결

• 검색 결과, 해당 오류는 PG의 로그 시스템이 꼬여서 생기는 오류라고 한다. 그래서 강제로 로그 시스템을 리셋시켜줘야 하는데, 리셋하는 방법은 다음과 같다.

su postgres # root으로 실행할 수 없음
pg_resetwal -f /var/lib/postgresql/data # DATADIR로 명명된 데이터 디렉토리를 지정하면 되는데, 깃랩의 경우 이 위치를 데이터 디렉토리를 잡고 있었음

• 그러나 컨테이너가 계속 생성과 동시에 폭파되므로, deployment에 args 인자로 강제로 sleep을 전달

  spec.template.spec.containers[0].args: ["sleep","1000000"]

• 이후 상단의 명령어를 따라 로그를 리셋해주고 파드를 삭제해주면 Deployment가 알아서 파드를 생성하면서 정상적으로 기동

미해결

• 결국 튕기는 현상은 아직 복구하지 못함

21. 08. 17

개요

• 튕기는 현상에 대하여 NAS의 네트워크 상태를 모니터링한 결과, 초당 12Mbps로 어딘가에서 데이터를 읽어들이고 있음.

• 타 서버의 경우 기가급 네트워크를 사용하고 있는데 반해, node2:251서버의 경우 메인보드에 랜카드를 꽂을 슬롯이 부족해 기본 랜카드를 사용하고 있어 100Mbps급 네트워크를 사용하고 있는 것으로 추정됨

• 네트워크 최대 제한에 걸려서 더이상 데이터를 보내지 못하고 트래픽 과부하로 인해 깃랩이 빈번하게 튕기는 것으로 추정

해결

• NAS로 이전했던 postgre 데이터를 다시 node2로 재이전하고 HA 계획을 보류

DevOps?

• 대부 없으, 즉 대출해줄 대부업체가 없다는 뜻
• Dev(Development) + Ops(Operations)의 합성어로, 소프트웨어의 개발과 운영 간의 협업 및 통합을 강조하는 개발환경을 말함
• 좁게는 애자일 기법에 기반한 개발을 의미하고, 넓은 의미에서는 어플리케이션 개발주기 전체를 일컫기도 한다
• 개발자가 개발에만 집중할 수 있도록 개발이 끝난 어플리케이션의 빌드, 테스트, 배포, 피드백 및 개선 등 기타 운영 관련 업무 등을 핵심 업무로 삼는 이들을 DevOps 엔지니어라고 한다.

CI/CD?

• DevOps 엔지니어의 핵심 임무로, 애자일 개발 주기를 자동화하고 각종 데이터의 수집 및 모니터링을 구성하여 이후의 개발 방향의 가이드라인을 제시, 고객에게 안정적이고 높은 신뢰도의 서비스를 제공하는 것이 목표
• CI : Continous Integration, 즉 어플리케이션을 지속적으로 빌드 및 테스트하는 것을 의미
• CD : Continous Delivery, 빌드된 어플리케이션을 지속적으로 배포하는 것을 의미
• 즉, 한국어로는 지속적 통합/지속적 제공 정도의 직역이 된다.
• 일반적으로 어플리케이션의 개발 주기인 Build-Test-Production에 기초한 파이프라인의 일종
• 최근 B2C(Business to Consumer) 프로젝트에서 핫한 트렌드로 떠오르는 개발 프로세스인 애자일(Agile)기법에 기반을 두고 있음

대표적 CI/CD 도구?

Jenkins

• 가장 많이 사용하고 대표적인 오픈소스 CI/CD 도구.
• 가장 자율적이고 많은 부분을 직접 디자인 가능하지만, 반대로 말하자면 사용법을 익히기가 가장 어렵다.
• 그러나 가장 커뮤니티가 방대해서 온갖 참고자료를 쉽게 찾을 수 있는 것은 장점.

Gitlab

• 오픈소스 CI/CD 도구
• Docker를 공식 실행자로 지원, 쿠버네티스와의 연동도 admin.conf 파일로 간단하게 구성가능.
• SaaS와 PaaS 모두 제공하고 있으며, PaaS의 경우는 오픈소스, SaaS의 경우는 엔터프라이즈로 제공하고 있다.
• Docker를 공식 executor로 제공하는데, 이때문에 도커 기반 환경(Docker swarm, K8s(<=1.20)-Gitlab)과의 상성이 아주 좋다.
• Podman이나 Openshift를 사용하는 경우 추천하고 싶지는 않음
• Gitlab 공식 Docs에서 예제 CI/CD 파이프라인을 제공하고 있고, 성능 역시 나쁘지 않다. helm 및 Dockerd에 대한 기초적인 이해가 있다면 가볍게 튜닝해서 사용할 수도 있다.

기타 다른 CI/CD Tools

• Travis
• CircleCI
• Bamboo
• Github action
• Chef
  • 위 도구들은 내가 미처 사용해보지 못했거나, 어딘가에 리뷰할 만큼 충분히 써보지는 못했던 것들이다. Reddit이나 StackOverflow등을 보면 Chef를 다들 탑으로 선택하던데, 써보지 못해서 잘 모르겠다.

개요

• Swagger를 적용한 node.js 웹사이트 하나를 띄워달라는 요청을 받음.

과정

• 특이하게 사내 템플릿으로 적용하는 PostgreSQL이 아니라 MySQL을 쓴다고 한다....덕분에 템플릿이 없어 DB로부터 각종 값을 받아오는 api는 동작이 불가능한 상태(artifacthub가 아니라, private helm core를 사용하고 있다).
• 코드를 받아서 돌렸더니 38 line에서"address is already use" 에러가 나온다. 다시 봐보니 개발자가 확인용 console.log를 두개 찍어놨는데, 동일한 포트로 띄워놨던 것이다...
• 해당 부분을 수정해 다시 올렸더니 이번엔 "cannot get /"가 뜬다.
• 검색해보니 해당 라우트 경로가 없어서 생기는 에러라고 한다.
• livenessProbe/readinessProbe가 "/" 경로로 GET을 날리도록 설정되어있는데, 정작 어플리케이션의 "/" 경로에선 POST를 받도록 만들어놨다.... 찾아봐도 DB 연동 없이 단순 GET을 날릴 수 있도록 만든 라우터는 없었다.
  • 이야기를 들어보니, 기기측에서 루트 경로로 POST를 날리면 바로 기기 등록과 함께 api가 실행되도록 하려고 했다고 한다.
• 따라서, "/" 경로에 새로 "GET"을 받을 수 있는 테스트 라우터를 생성해놨다.
• app.get('/', function (req, res) { res.send('테스트입니다.'); });
• 빌드 성공!