Gitlab CI/CD 사용하기

현재 회사에서는 Gitlab Free tier로 사용하고 있다.

그러다보니 워낙에 Gitlab의 다른 기능에는 관심이 없었는데, (소스만 Private하게 잘 저장하는 곳 아니였나요.. 🤔)

실제 운영 환경까지 고려하면서 서비스 구조를 바꾸다보니 어느정도 잘 동작하는 CI/CD까지 고려하게되고, 그러다보니 GItlab에 있는 기능들을 살펴보게 되었다.

 

기존엔 회사 한 구석탱이에있는 일반 PC를 활용해서 Jenkins 빌드서버로 사용하면서, API를 이용하여 반자동의 CI/CD툴을 만들어서 사용해왔다. 사용자가 빌드까지는 직접 진행해두고, 배포할 Application과 인스턴스를 선택해서 배포하면 알아서(정해진 로직에 의해🤫) Gracefully하게 배포되는 방식이다. 그렇지만 이런 방식은 커밋/빌드 단계에서부터 관여하지 않다보니 시간이 흐르면서 각 개발자가 로컬에서 개발하는 환경과 자꾸만 괴리감이 생기고 환경이 틀어지는 문제가 생기기 시작했다. (python.. 너이자식.. 😮‍💨)

아직 갈길이 먼 배포툴 😵‍💫

 

메인 Cloud로 AWS를 사용하고있다보니 자연스럽게 Code Commit, Code Build, Code Deploy, Code Pipeline와 같은 서비스를 사용할까 고민도 되었는데, 비용적인 측면에서 비싸긴 비쌌다. (사용자당 얼마, 건당 얼마 식의 과금은 아무래도 부담이 확 되는 것이 사실🤑)

그리고 무엇보다도 위의 서비스들은 GitHub와는 기본적으로 연동되지만, Gitlab은 AWS에서 직접적으로 연동지원해주지 않는다. 

그래도 Python환경을 위해서는 Container기반의 서비스를 사용하는 것이 바람직하다고 생각이되어 ECS+Fargate를 사용하기로 마음먹었고, 해당 환경으로 배포되는 것을 고민하게 되었다. 

 

직접 구현해야되나 고민을 하면서, 최초로 생각했던 방향은 다음과 같다.

특정 git repository에 commit이 되면, 해당 code를 반영한 docker image를 만들고, 만들어진 image를 fargate로 배포한다. 

 

어쨌든 git에 commit되는 것을 체크해야하니 Gitlab의 기능을 살펴보았고 AWS와 연동이 가능한 template을 제공하고 있음을 확인했다.  물론 template의 세부적인 command flow는 직접 구현해야하지만, 그래도 완전 새로 구현하는것보다는 훨씬 편하게 진행했다.

 

각 순서에 진행되는 gitlab cicd flow

간단히 살펴보면,

0. (사용자가 원하는 조건에 따라) 새로 code가 commit 되면,

1. gitlab runner가 새로운 이미지를 build하고, ECR에 push한다.

2. push된 이미지를 ecs service (강제) 업데이트를 통해 배포한다. 

3. 이 과정에서 ELB는 gracefully하게 변경되고, 일정시간후에 기존에 실행중인 container는 종료된다. 

 

조금 더 손을 본다면, 배포 단계에서는 docker에서 실행되는 것이아니라 local shell에서 실행되게 하면 deploy단계는 좀더 빨리 진행되지 않을까 싶긴하다.

우선은 이 정도에서 만족하고, 실제 서비스 환경에 적용하면서 조금 더 구체화 시켜보자.