ECS를 활용한 배포-적용(2022.04.13~2022.04.18)

시나리오

실제 프로젝트를 업데이트 하는 상황에서 발생하는 시나리오에 대한 동작 방식을 정리하였다.

통계 서버의 API 수정 사항 발생

기본적으로 깃랩의 MR에 따른 Jenkins pipeline이 시작된다고 가정하에 요청을 보내기 전, 처리해야할 작업은 다음과 같다.

젠킨스 서버(EC2)에 들어가서 .env 파일을 수정한다.

소스코드의 홈 디렉토리는 /var/lib/jenkins/workspace/dashboard-api이다.
AWS 페이지의 ECR에 들어가 가장 최신 상태의 이미지 태그를 확인한다.

겹치지 않는 태그를 설정한 후에 Jenkinsfile 파라미터를 수정한다.

현재 1.1이 가장 최신 태그이므로, 겹치는 태그가 없도록 사전에 파라미터 수정을 해야한다.

빨간색 부분의 기본값을 설정한다.

부하의 증가로 celery 컨테이너 추가

</aside>

컨테이너를 새롭게 추가하기 위해서는 deploy.py의 태스크 정의를 수정해야한다. 태스크 정의를 작성하는 부분은 아래의 홈페이지를 참고하도록 하자

결론적으로 태스크 정의를 deploy.py의 ecs_client.register_Task_definition() 함수의 내부 컨테이너 정의를 변경하면 된다.

→ 네트워크 변경사항이 발생할 경우 도커의 브릿지 네트워크를 참고하도록 하자

‣

파라미터를 이용해서 각 스테이지별로 부울 값을 지정하여 파이프라인을 실행하는 상황에서 건너 뛸 것인지를 결정할 수 있다. 기본적으로 false로 설정할 경우 트리깅이 되더라도 파이프라인의 각 스테이지가 실행되지 않는다.

스테이지가 실행되지 않은 것을 볼 수 있다.

이후 Build with Parameters를 이용하여 태그를 입력값으로 지정하여 수동으로 트리깅을 시킬 수 있다.

테스트 부분의 스테이지는 건너뛰고 싶을 때

아직 테스트코드의 작성이 충분하지 않거나, 패키지 에러가 나는 상황에서는 Test 태스크를 건너 뛰어야 하는 상황에서는 파라미터를 조정하여 파이프라인을 실행하면 된다.

트리깅 방식 MR로 괜찮을까?

WebHook의 경우 모든 MR에 대해서 실행이 된다. 즉, 이 방식을 사용할 경우 배포 상황에 대해 특정지어서 젠킨스 파이프라인을 실행하기 어려울 수 있다.

→ 깃랩의 웹훅 트리거 설정에서 Tag push events를 사용하여 태그를 설정하여 push하는 상황에서만 파이프라인이 실행될 수 있도록 하는 방법. 태그를 통해서 배포상황을 명확하게 정의할 수 있다는 장점이 있을 것으로 판단됨
환경변수 볼륨 마운트를 이요한 로컬 환경 관리

현재 환경변수 파일이 config/settings/에 들어있는 상황. 도커 이미지 빌드 시에 절대 경로로 마운트할 수 없기 때문에 루트 경로에 이미지 빌드용 .env를 써야하는 상황

이 상황의 경우 환경변수 파일을 2개 관리해야한다는 단점이 존재, 번거로움을 감수해야 할 지에 대한 논의 필요...

→ 젠킨스 서버(EC2) 홈 디렉토리 참고
```
# Prod bastion server
ssh jenkins
# Jenkins server
cd /var/lib/jenkins/workspace/dashboard-api
tree -L 2 -N -a
```