[CI/CD 구축] AWS, Docker, GitLab을 사용하여 CI/CD 구축하기 2편

[이전글]

[CI/CD 구축] AWS, Docker, GitLab을 사용하여 CI/CD 구축하기

 

---

이제 GitLab runner가 설치된 서버(ec2, 이하 러너 서버로 명칭)에서 관련 파일을 어떻게 관리하고 배포할 것인가에 대해 여러 가지 방면으로 많은 생각을 하며 머릿속에 있는 flow를 직접 그려가며 정리해봤다.

 

첫 번째 방안은 도커 이미지를 만들어 Docker Hub로 컨트롤 하는 CI/CD.

1. 러너 서버에서 비즈니스 소스를 포함한 배포 서버 환경과 똑같은 도커 이미지를 만들고
2. 만든 Docker Image를 Docker Hub에 push 한 후에
3. Docker Hub에서 제공하는 WebHook으로 브랜치 별(staging, production 등) 배포 서버 트리거를 발생시킨다.
4. 각 브랜치별 해당하는 서버에서 Docker Hub에 Push 된 Image:latest 버전을 Pull & Run 하여 서비스를 반영한다

 

 

모놀리식 아키텍쳐의 서비스를 하고있는 경우 너무 간단하고 심플하게 Docker로만 CI/CD를 구성할 수 있을 것 같았고, 무중단 배포는 분명 저 안에서 도커 컨테이너를 각각 1개씩 더 띄워서 블루/그린으로 처리할 수 있지만 Docker Hub에서 제공하는 비가시성(Private) Repository는 무과금으로는 1개만 제공받기 때문에 개인이 토이 프로젝트를 배포하는 시스템을 만들어 보는 개념으로는 좋지만 회사 단위에서 사용하기에는 아무래도 Docker Hub를 사용하는 건 코스트 문제로 지양하는 편이라고 한다. Web Hook을 지원해주는 건 너무 장점이지만,, 생각만 해 보았다.

 

두 번째 방안은 도커 이미지를 만들어 Docker Private Registry로  컨트롤 하는 CI/CD.

1. 러너 서버에서 비즈니스 소스를 포함한 배포 서버 환경과 똑같은 도커 이미지를 만든다.
2. 러너 서버에 Docker Private Registry 역활을 하는 도커 컨테이너를 하나 더 띄운다.
3. 각 브랜치 별(staging, production 등) 배포 서버에 미리 Docker Private Registry에서 Docker Image를 가져와서 실행할 수 있게 하는 쉘 스크립트(. sh 파일 등)를 만들어 놓고, 해당 스크립트를 실행 가능하게 하는 간단한 API 프로젝트를 만들어 실행시켜놓는다.
4. 만든 Docker Image를 Docker Private Registry에 push 한다
5. Push가 완료되면 Docker Image를 만드는 도커 컨테이너를 내림과 동시에 3번에서 만든 API를 curl로 컨트롤한다.
6. 각 브랜치별 해당하는 서버에서 Docker Private Registry에 Push 된 Image:latest 버전을 Pull & Run 하여 서비스를 반영한다

첫 번째 방안과 달라진 건 Docker Hub의 단점인 private repository 사용을 위한 코스트 지불을 막기 위해 개인 서버에 설치하는 Docker Priate Registry로 대체한 후, Docker Hub의 Webhook 기능 대신으로 사용할 새로운 트리거인 API Request 형식으로 바꾼 것 밖에 없었다.  AWS Container Registry로 많이 사용하는 ECR도 코스트 문제가 있어서 사용기 꺼려졌고, Free open source로 제공되는 Harbor (설치형 Container Registry의 일종)를 사용해 볼까 심도 있게 고민하다가 세 번째 방안을 추천받았다.

 

세 번째 방안은 빌드를 통해 zip file을 만든 후 AWS S3 및 CodeDeploy로  컨트롤 하는 CI/CD.

(사전 시행 : AWS CodeDeploy 서비스를 설정한다)
1. 러너 서버에서 비즈니스 소스를 포함시킨 모든 파일을 빌드과정까지 마친 후 zip파일로 만드는 node기반 builder engine을 만든다.
2. 제작한 빌더 엔진을 통해 build 과정을 실행하며 zip파일을 특정 폴더에 만든다.
3. gitlab-ci.yml 파일의 script 부분에서 AWS S3 버킷으로 zip파일을 전송하는 스크립트를 통하여 upload한다.
4. AWS에서 제공하는 SDK 및 CLI를 활용하여 createDeploy 를 실행한다
5. 자동 배포가 진행되는걸 확인한다

물론 위의 과정은 많은 셋팅 과정과 yaml 파일의 스크립트 및 node 기반의 builder engine을 만들어야 하는 등, 기초 사전 작업이 힘들겠지만 나는 사전 답습을 끝낸 분의 도움을 받으며 세 번째 방안으로 CI/CD 구축을 진행하게 되었다. 

 

CI/CD를 구축하는 방법은 정말 많은 것 같다. GitLab이 아닌 GitHub을 사용할 때는 runner 개념이 아닌 action을 바로 캐치해서 처리하는 등 프로세스가 달라질 수도 있고, s3 버킷이 아닌 비트버킷을 사용하면서 중간의 프로세스가 바뀔 수 있고, 자체개발 배포 엔진이 아닌 젠킨스를 활용하여 CI/CD를 구축할 수 도 있다.

 

각자 CI/CD를 도입할 서비스의 구조를 잘 파악하여 Flow도 그려보고, 많은 생각도 해보고, 삽질도 해보고, 실패도 계~속 해보고, 그러다 성공하면 기분이 조크등요,,