배포 자동화 구축기

 

1. 배포 자동화를 구축하게 된 계기

 

현재 교내 서버실에 운영서버가 구축되어 있고,
교내망 정책에 따라 외부 액세스 포트는 80, 443 2개만 사용할 수 있었다.

이미 80, 443은 애플리케이션 배포를 위해 사용하고 있다.
따라서 교내망에 접속해 있을 때만 22번 포트로 ssh 접속을 통해 변경사항을 운영서버에 배포할 수 있었다.

이렇듯 교내망에 접속해야만 한다는 문제도 있었지만,
결국에는 수동으로 배포하다 보니 명령어를 잘못 입력하는 경우도 있었고 배포할 때마다 반복되는 작업을 진행하다 보니 배포 자동화가 정말 절실했다.

 

2. 배포 자동화 플로우

우선 Jenkins를 이용하여 배포 자동화를 구축하고자 한다.

1. PR이 Master 브랜치로 Merge되면 Github WebHook이 Trigger 된다.
2. 해당 Gtihub Webhook을 통해 아래의 Jenkins의 배포 PipeLine이 실행된다.
3. Github를 통해 코드를 복사해 온다. 
4. 빌드를 진행한다.
5. docker build를 통해 image를 생성한다.
6. ECR로 해당 docker image를 push 한다.
7. EC2에 등록해 놓은 deploy.sh 쉘 스크립트를 수행한다.

이번에 배포 자동화를 구축하면서 정말 많은 오류를 접했고, 하나의 오류를 잡지 못해서 이틀 동안 고생하기도 했다.

 

3.  (트러블 슈팅 1) .gitignore 처리한 비밀정보를 포함한 yml 설정 파일

DB의 비밀번호나 토큰의 key 등 여러 암호정보를 포함한 yml 파일들은 이미 .gitignore 설정을 통해 github에는 올라가 있지 않은 상태이다.
따라서, Jenkins에서 빌드를 진행할 때 어떻게든 해당 정보들을 삽입해줘야 한다.

해당 문제를 해결하기 위한 방법은 여러 가지가 있었다.

1. private repo로 만든다.
2. 환경변수를 이용하고 .gitignore 하지 않는다.
3. 암호화된 비밀정보를 yml파일에 넣고 .gitignore를 하지 않는다.
4. git submodule을 이용하여 public repo에 설정정보들이 담긴 private sub repo를 추가한다.
5. Config Server를 이용한다.

여러 방법이 있지만, 나는 4번 방법을 선택하였다.

Git에 submodule이라는 개념이 있다는 것을 이번 기회에 알게 되었고, application-db.yml과 같이 비밀정보가 담긴 파일을 private repo에 저장하고 이 submodule을 배포하려는 public repo에 추가해 주었다.

해당 방식을 이용하기 위해서는 우선 Github access token을 Jenkins Credentials에 추가해주어야 하고 아래와 같은 스크립트를 작성해야 한다.

checkout scmGit(
        branches: [[name: 'master']],
        extensions: [submodule(parentCredentials: true,reference: '', trackingSubmodules: true)],
        userRemoteConfigs: [[credentialsId: 'access token credentials id', url: 'https://github.com/{배포하려는repo}']]
)

 

 

4. (트러블 슈팅 2) Jenkins 내부에서 docker가 실행되지 않음

나는  Jenkins를 Docker 컨테이너 환경으로 실행하였다.
또한, 파이프라인 내에 docker build, push 등의 명령을 실행하는 스크립트가 존재하지만 "docker not found" 에러가 발생하였다.

결론적으로는 Jenkins 컨테이너의 docker.sock을 Host의 docker.sock에 마운트 해주지 않아서 에러가 발생하였다.
Jenkins를 Docker 컨테이너 환경으로 실행하면 컨테이너 내부에서 Host의 Docker를 이용하여 작업을 해야 한다.
하지만, 그게 Host와 연결되어 있지 않아서 문제가 발생한 것이었다.

docker.sock(Docker Socket)이란 도커 데몬이 기본으로 Listen 하고 있는 유닉스 소켓이다. 결국 컨테이너 내부에서 데몬과 상호작용할 수 있게 해주는 역할을 한다.

 

5. (트러블 슈팅 3) Jenkins를 구동하는 EC2 서버의 계속된 Down

Jenkins를 구동 중인 서버는 프리티어로 구성하여서 성능이 매우 낮다. RAM도 1GB여서 Jenkins의 작업을 수행하기는 무리가 있다.
작업을 원활하게 수행하기 위해서는 Swap 메모리를 설정해 주어야 한다.

이걸 몰랐을 때 어떻게 해야 하나 참 난감했었다. 인스턴스에 접속해서 아래 명령어를 입력하면 된다.

sudo fallocate -l 1.5G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

 

 

6. (트러블 슈팅 4) No basic auth credentials Error

해당 에러 때문에 거의 이틀 동안 고생한 기억이 있다.

aws configure 명령을 통해 정보를 등록하고
aws ecr get-login-password --region ap-northeast-2 | docker login -u AWS --password-stdin{계정번호}.dkr.ecr.ap-northeast-2.amazonaws.com 명령을 통해 인증코드를 갱신하였음에도 계속해서 해당 에러가 발생하였다.

정말 포기할까 수십 번 고민하다가 아까워서라도 계속 이것저것 변경해 보면서 수정하다가
deploy.sh 스크립트 내에 sudo docker compose up -d 명령에서 sudo를 삭제해 보니 잘되었다. 

눈물이 핑 돌았다.. 왜 sudo를 지웠을 때 잘되는지 사실 이해가 잘 가지는 않는다.
문제를 해결하였지만, 해당 부분에 대해 기술 부채를 떠안은 것 같아 마음이 무겁다.

 

후기

배포자동화를 결국 3일 만에 구축하게 되었다.

위에 작성한 트러블 슈팅 케이스 이외에도 정말 많은 문제가 발생했었다. 그냥 하지 말까라는 고민을 계속했지만 시간을 쏟아 넣는 만큼 에러는 하나씩 지워져 나갔다. 배포 자동화라는 게 정말 큰 숙제처럼 느껴졌었는데, 이렇게 구축하고 나니 한 단계 성장했다는 생각이 든다.

결국 Jenkins라는 도구를 이용한 것뿐이지만 3일 동안 "이거 하나 제대로 못하나"라는 생각에 정말 힘들었다.
생각보다 내 케이스에 맞는 참고자료는 별로 없었고, 관련된 책과 StackOverFlow도 전부 뒤져보고 나서야 문제를 해결할 수 있었다.
무작정 에러를 복사해서 검색창에 붙여 넣기 해서 해결한 경우도 물론 있었지만, 왜 문제가 발생한 것인지를 먼저 생각해 보고 검색하였을 때 문제 해결 속도가 더 빠름을 느꼈다.

이제 수동으로 배포하지 않고 자동으로 배포할 수 있게 되어 더욱 개발 환경이 세련되었다.
며칠 전에는 개발서버를 Cloud 환경으로 옮기는 작업을 진행하였는데, 이번에는 배포자동화까지 구축하여 점점 더 환경을 발전시키는 것에 대해 성취감이 확실히 있다.
다음에는 ECS로 배포 환경을 변경하고 그에 대해 script를 변경해 봐야겠다.