리팩토링 전에 갖고 있는 가상서버들을 정리해 보겠습니다.
최종 목표는 이겁니다. 가상 서버가 사양에 비해 금액이 적지 않다고 판단하였고 더 높은 사양을 원하기에 물리 서버를 두대 둬야한다고 생각 했습니다. 클라우드에 비해 물리서버가 죽을 확률은 높아서 프록시 서버는 클라우드에 한대 뒀습니다. 리버스 프록시에서 로드 밸런싱과 서버 health check 를 담당할 예정입니다.
우선은 북구에 놓을 서버가 없기에 Linode 60달러짜리 서버를 한대 빌렸습니다. 지금은 데탑 서버(평사)와 리노드(일본) 두대가 있습니다.
이제 자동 배포를 구축할 겁니다.
기존에는 리눅스 서비스를 만들어두고 관리하는 방식으로 했는데 코드를 변경할 때 마다 재시작 명령어를 입력해줘야 해서 배포하기가 매우 귀찮았습니다. 이걸 젠킨스를 통해 자동화 할 계획입니다.
게다가 서비스마다 각각 다른 부분이 있어 신경써야 할 부분이 많습니다. 이걸 도커로 만들어두면 서비스를 올릴 때 같은 명령으로 전부 처리할 수 있고 어느 환경에서나 동일하게 동작하기 때문에 배포할 때 뇌를 덜 사용해도 됩니다.
그리고 docker-compose를 사용할 겁니다. docker run 뒤에 오는 수많은 옵션을 관리하는 것도 상당히 귀찮은 일 입니다. docker-compose 는 이런 옵션들을 파일로 만들어뒀다고 생각하시면 됩니다. 옵션을 미리 파일로 저장해 두고 docker-compose up -d 만 입력하면 서비스가 올라갑니다.
빌드 촉발은 깃허브 푸시로 진행할 겁니다. 지금 생각하고 있는 배포 방식은 두가지 입니다.
도커 허브를 잘 활용하기 위해 깃허브에서 푸시가 들어오면 도커 빌드 → 도커 푸시 과정을 거치는것은 똑같습니다. 다만 깃허브 액션으로 빌드와 푸시를 할것인지, 도커 허브를 통해 빌드를 할것인지는 선택해야 합니다.
깃허브 액션으로 하면 다음과 같은 특징이 있습니다
- ＋ 빌드, 배포를 한 곳에서 관리 가능함.
- － CI Minute 을 보고 비용 신경써야 함.
- △ 배포 명령 전달시 젠킨스를 사용해도 됨
도커 허브와 젠킨스를 사용하면 다음과 같은 특징이 있습니다
- ＋ 젠킨스 사용으로 자동화 자유도가 넓어짐
- － 과정이 좀 복잡함. (깃허브 푸시 → 도커 허브 → 젠킨스 순)
- △ 어짜피 도커 허브 프로를 샀는데 활용하자는 마인드
지금은 dockerhub 를 통해 빌드하고 있습니다. 이제 젠킨스 세팅을 알아보겠습니다.
처음 젠킨스를 설치하고 할 일은 다음과 같습니다.
- 웹훅 플러그인 설치, 배포(over ssh 로 검색) 플러그인 설치
- 대상 서버에서 ssh-keygen 을 하고 이 키를 깃허브에 등록합니다. (docker-compose 파일을 받기 위함)
- 배포 플러그인(Publish over SSH) 에서 ssh 서버 추가 (관리 → 시스템 설정 에 있음)
- 대상 서버에서 레포지토리 받기(또는 docker-compose 파일만 있어도 됨)
빌드 유발은 웹훅 입니다. 젠킨스에서 웹훅 플러그인을 깔고 토큰을 설정해 주면 됩니다.
빌드 환경 설정은 다음과 같습니다. 말이 빌드 환경일 뿐이지 사실은 서버에 접속해서 도커 재시작 해주는 명령이 전부 입니다.
cd /root/srtbot
git pull
docker-compose pull
docker-compose up -d --remove-orphans
yes | docker image prune위 명령어를 젠킨스가 웹훅이 들어오면 실행해 줍니다.
이로써 자동 빌드 환경이 구성되었습니다. git commit 과 push 를 하게 되면 dockerhub → jenkins → 서버에서 docker-pull 과정을 거쳐서 서비스가 최신 상태로 올라오게 됩니다.
다음은 attend 프로젝트의 도커화와 cockroach 데이터베이스 연결, sqlite3 에서 cockroach 데이터베이스로 데이터 이동을 할 것 같습니다.