🚍 Intro

저번 글의 내용이 길어짐에 따라, 나누어서 글을 작성한다.

기존 글의 마지막 부분은 최종 CICD 파일에 대한 결과물을 작성하고 끝이 났다.

name: Continuous Integration and Deployment

on:
  pull_request:
    branches:
      - develop
    types: [closed]

jobs:
  ### step 1. code integration check
  CI:
    runs-on: self-hosted
    if: github.event.pull_request.merged == true
    env:
      BRANCH: develop
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          ref: ${{ env.BRANCH }}
          token: ${{ secrets.ACCESS_TOKEN }}

      - name: Set node environment
        uses: actions/setup-node@v4
        with:
          node-version: 20.11.1 # see .nvmrc

      - name: Caching Primes # for this case, node_modules
        id: cache-primes
        uses: actions/cache@v4
        with:
          path: node_modules
          key: npm-packages-${{ hashFiles('**/package-lock.json') }}

      - name: Install dependencies if no cache
        if: steps.cache-primes.outputs.cache-hit != 'true'
        run: npm install

      - run: npm run check:lint
      - run: npm run check:type

  ### step 2. publish code to external environment
  CD:
    needs: CI # If CI is done, then do CD
    runs-on: self-hosted
    steps:
      - name: AWS credential
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} # IAM access key
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} # IAM access
          aws-region: ${{ secrets.AWS_REGION }}

      # 1. ECR
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2 # result : registry (ECR repo uri)

      - name: Build, tag, and push image to Amazon ECR
        id: build-image
        env:
          ECR_REPO_URI: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPO_NAME: ${{ secrets.ECR_REPO_NAME }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          IMAGE_NAME='${{ env.ECR_REPO_URI }}/${{ env.ECR_REPO_NAME }}:${{ env.IMAGE_TAG }}'
          docker build -t ${IMAGE_NAME} .
          docker push ${IMAGE_NAME}
          docker system prune --volumes -a -f
          echo "image=${IMAGE_NAME}" >> $GITHUB_OUTPUT

      # 2. ECS
      # https://fig.io/manual/aws/ecs/describe-task-definition
      - name: Generate task-definition.json from latest active ECS task definition
        run: |
          aws ecs describe-task-definition \
            --task-definition ${{ secrets.ECS_TASK_DEFINITION }} \
            --query taskDefinition \
            > task-definition.json

      - name: Render Amazon ECS task definition
        id: render-task-definition
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          # this step exports the task-definition as an output automatically (used from next step)
          task-definition: task-definition.json
          container-name: ${{ secrets.ECS_TASK_CONTAINER_NAME }}
          image: ${{ steps.build-image.outputs.image }}

      - name: Deploy Amazon ECS task definition
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.render-task-definition.outputs.task-definition }}
          service: ${{ secrets.ECS_SERVICE }}
          cluster: ${{ secrets.ECS_CLUSTER }}
          wait-for-service-stability: true

CI는 사실상 lint와 type 체크를 하는 것에 불과해서 특별한 내용은 없지만, CD 부분은 아무래도 composite action이 많다보니, 각각의 액션들이 설명하는 조건들을 잘 이해해야 했다.

우선 나는 ECR 및 ECS를 기준으로 작성하였다.

AWS에 대한 설명을 적기에는 나도 아직 공부가 부족하기에 그냥 필요한 핵심만 설명으로 남겨놓는다.

참고로, 저렇게 한 파일로 입력하지 않고 당연히 CI파일, CD 파일을 분리해서 작성하는 것이 낫다. 위 내용은 테스트를 위해서 한 파일에 다 작성한 버전이다.

개인적으로 도커를 통한 프론트엔드 배포에 대해 개인적으로 느끼는 아쉬운 점이 좀 있어서 nginx를 통한 무중단 배포를 구현하였고, 이에 대해서 다음글에 기술해둔다.

이 기록은 나중에 도커를 통해 배포해야 하는 개발 환경일 경우를 대비해서 문서화하는 내용이다.

---

1. 🚍 ECR

1. AWS credential

   steps:
     - name: AWS credential
       uses: aws-actions/configure-aws-credentials@v4
       with:
         aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} # IAM access key
         aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} # IAM secret key
         aws-region: ${{ secrets.AWS_REGION }}

우선 AWS에 접근하여 작업을 하기 위해서는 credential을 얻어야 한다.
region은 어려울 게 없을텐데, access key랑 secret access key는 어디서 얻는지 처음하는 사람은 생소할 것이다.
이 credential을 얻기 위한 access,key와 secret key는 아래와 같은 장소에서 얻을 수 있다. ( 이미 백엔드 분들에게 IAM 계정을 부여받았다는 전제 하에서 작성한다)

• 1. IAM 에 접속
     
• 2. 사용자 클릭 => 내 계정으로 들어가기
     
     
• 3. 보안자격증명의 액세스 키 만들기
     
• 4. 컴퓨팅 서비스용 key 생성
     
• 5. 생성된 액세스키(access-key), 비밀 액세스 키 action의 secret으로 등록
     
     

---

2. ECR login and push image to ECR

      # 1. ECR
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2 # result : registry (ECR repo uri)
        
      - name: Build, tag, and push image to Amazon ECR
        id: build-image
        env:
          ECR_REPO_URI: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPO_NAME: ${{ secrets.ECR_REPO_NAME }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          IMAGE_NAME='${{ env.ECR_REPO_URI }}/${{ env.ECR_REPO_NAME }}:${{ env.IMAGE_TAG }}'
          docker build -t ${IMAGE_NAME} .
          docker push ${IMAGE_NAME}
          docker system prune --volumes -a -f
          echo "image=${IMAGE_NAME}" >> $GITHUB_OUTPUT

ECR이라는 것을 나도 이번에 처음 들어봤다. 그런데 생각보다 어려운 개념은 아니고 그냥 빌드된 도커 이미지를 저장해서 ECS의 원료(?) 로 쓰이기 위한 S3같은 저장소라고 여기면 가장 이해하기 쉬웠다.

우선 검색창에 ecr을 입력하여 아래에 보이는 프라이빗 ECR 레지스트리를 클릭한다.

이후, 옆의 탭에서 "Repositories"를 클릭한 뒤, 레포지토리 생성을 클릭해서 생성하면 된다. 생성탭에 있는 UI 입력내용은 몹시 간단하기 때문에 생략한다.

생성 후 만들어지는 위 두 탭 중에 두번째가 바로 git action secret의 ECR_REPO_NAME으로 들어가야 하는 값이 된다. ( ECR_REPO_URI 는 git action step에서 ECR로 로그인하는 순간 자동으로 받아와짐 )

ECR_REPO_URI는 추후 ECS의 작업 정의를 생성할 때 사용되야 하므로 미리 복사해두자.

      - name: Build, tag, and push image to Amazon ECR
        id: build-image
        env:
          ECR_REPO_URI: ${{ steps.login-ecr.outputs.registry }} <-- 요기
          ECR_REPO_NAME: ${{ secrets.ECR_REPO_NAME }} <-- 요기
          IMAGE_TAG: ${{ github.sha }} # automatically generated
        run: |
          IMAGE_NAME='${{ env.ECR_REPO_URI }}/${{ env.ECR_REPO_NAME }}:${{ env.IMAGE_TAG }}'
          docker build -t ${IMAGE_NAME} .
          docker push ${IMAGE_NAME}
          docker system prune --volumes -a -f
          echo "image=${IMAGE_NAME}" >> $GITHUB_OUTPUT

이후 run에 해당하는 부분은 단순한 docker 이미지 생성 후 이를 push하는 과정이 들어가있다.

IMAGE_NAME의 앞자리에 REPO_URI가 있으므로, docker build를 통해 만들어지는 이미지는 이 URI로 push되게 된다.

이후, 내 MAC OS에는 빌드하면서 도커 오버레이가 생성되게 된다. 이 오버레이는 이미지를 레이어 개념처럼 만들어 쌓아가는 도커의 특성상, 불필요한 레이어를 재생산하지 않도록 캐싱하게 되는데, 이것이 용량이 상당한 편이라 빌드를 할 때마다 계속 생기기 때문에 지워줘야 한다.

특히, 용량이 한정적인 EC2를 사용하고 있을 경우, 이 위에서 도커로 빌드하면 오버레이가 계속 쌓여서 나중에가면 메모리부족으로 EC2가 멈춰버리는 일까지 일어나니 잘 관리해줘야 한다.

그 명령어가 run 파트에서 밑에서 두번째줄인 docker system prune --volumes -a -f 에 해당한다.
볼륨 및, 사용하지 않는 이미지 컨테이너 네트워크 등을 밀어버린다.

참고로, run의 마지막줄인 echo ... >> $GITHUB_OUTPUT 문법은 git action에서 제공하는 문법으로, 저렇게 한 스탭에서 export 되는 값은 다른 step에서 ${{ steps.스탭 아이디.outputs.image }} 이런식으로 사용할 수 있게 해준다.

IMAGE_TAG: ${{ github.sha }} 이미지 태그는 무조건 github이 제공해주는 해싱된 값을 사용하여 기존의 이미지와 다르다는 것을 설정해줘야 한다. 그렇지 않을 경우 배포를 했음에도 불구하고 새로운 ECR의 이미지가 ECS에서 배포되지 않는 상황을 보게 될 것이다. 이럴 경우 직접 ECS에 들어가서 버전을 바꿔줘야 하는 번거로움이 생긴다.

---

3. 🚍 ECS

3. ECS deployment

방금 전 ECR이 AWS의 이미지 허브와 같은 역할을 한다면, ECS는 이 이미지를 이용해서 정해진 배포전략 (롤링 or 블루그린) 에 따라 컨테이너를 띄워주는 역할을 한다.

이 ECS가 조금 건들게 많았었다. (로드밸런서, 타겟그룹 등등)

우선, 만약 팀 내에 이미 사용중인 로드 밸런서가 있다면 그것을 사용하고, 없다면 먼저 우선적으로 만들어줘야 한다.

그 이유는 나중에 확인해보면 알겠지만 ECS 자체만으로는 EC2처럼 퍼블릭 DNS 같은게 없으므로 우리의 도커 이미지가 배포된 ECS에 접근하려면 로드밸런서와 엮어 접근하는 방식을 취해야 한다. (그리고 사실 EC2에 배포할 때에도 당연하겠지만 로드밸런서는 필요하다. 포트포워딩을 위해서라도, 네트워크 요청 분산 및 https 적용을 위해서라도 ...)

AWS가 익숙한 사람들에게는 로드밸런서의 작동원리를 굳이 생각 안해도 되겠지만, 로드 밸런서가 필요한 이유에 대해서 nginx를 만지작하다가 깨닫는 순간이 있었어서 정리할 겸 남겨본다.

Nginx란, 한마디로 말해서 웹 서버이다.

이 웹 서버는 인스턴스 내에서 웹 어플리케이션 서버(WAS) 들에게 오는 요청을 대신 수신하여 이를 목표하는 서버에게 전달하고, 여기서 오는 응답을 다시 네트워크를 통해 클라이언트에게 전달해주는 역할을 주 목적으로 한다.

(추후 nginx를 통한 무중단 배포에 대해서 작성할 예정이라 여기서는 이정도만 소개하겠다)

nginx와 같이 프록시 서버가 중간에서 요청을 분배해줄 경우, 하나의 서버에 과중되게 요청이 가지 않고 적절하게 처리할 수 있도록 작업을 정의시켜줄 수 있고, 캐싱 및 암호화와 같은 장점들도 존재한다.

여튼, 로드밸런싱에 대한 서버가 존재할 경우, 이 서버가 생각해봐야 하는 내용은 어느 포트로 열려있는 서버에 요청을 전달해줘야하는지에 대해서일 것이다.

만약 기본 http 기본 포트인 80번으로 어플리케이션이 구동되고 있을 경우는 상관없지만, 1023번 미만의 예약 포트인 "Well-known-port" 들이 아닌 그 외의 포트에 열려있는 어플리케이션일 경우, http 요청이 들어올 때 이 요청을 해당 포트로 포워딩을 해줘야하는 상황이 벌어진다.

이런 역할을 nginx 내부 설정에서 할 수 있듯이, load balancer도 동일한 역할을 하는 것이다.

그리고 그 포트 포워딩에 대한 정의들이 바로 Target group(대상 그룹)이다.

대략 이정도의 개념을 잡고 다시 로드밸런서의 설정으로 돌아가보면,

일단 로드밸런서 자체의 이름을 정의하고, 이 로드밸런서가 타겟팅할 VPC와 서브넷을 매핑해준다.

그리고 방화벽 역할을 해줄 보안그룹을 설정해준다. EC2를 쓰다보면 자주 보게되는, 인바운드와 아웃바운드에 대한 정의들이 되어있는 객체이다. (즉, 어느 포트로 들어오는 접근을 허용해줄거고, 어느 포트로 나갈 수 있게 해줄것인지에 대한 정의 모음집 )

그 다음에는 리스너에 대한 정의를 해줘야한다.
아까 위에서 본 이미지대로, 방화벽을 통과한 요청에 대해서 이제 직접적으로 각각의 포트에 따른 포워딩에 대한 정의를 해줄 차례이다(대상그룹). 대상그룹 생성을 눌러서 들어간다.

정말 편한 부분중 하나인데, ECS를 사용하면 EC2때와는 다르게 알아서 서비스로 배포되어있는 컨테이너의 포트와 매칭시켜주기 때문에 굳이 따로 지정하지 않고 그냥 80 포트 접근에 대한 타겟그룹 자체만 지정해둔다.

따라서 ECS가 알아서 배정해 줄 것이기 때문에 위에처럼 기본 설정된 Ipv4부분은 제거하고 만들어주기만 하면 된다.

다 되었으면 로드 밸런서로 다시 돌아와서 리스터 부분에 대상그룹에 새로고침을 누른 후, 아까 만들어두었던 대상그룹과 리스너를 연결시켜주면 된다.

이제 본격적으로 ECS로 넘어가게 된다.

먼저 ECS 내에서 사용될 작업 정의(task-definition)을 만들어야 한다

작업 정의란, ECS가 특정 ECR에 올라가있는 이미지를 기반으로 컨테이너를 생성할 때, 얼마만큼의 자원을 분배할것이고 어떤 OS를 쓰고, 컨테이너 생성하면 컨테이너 포트는 몇이고 ... 등등의 스펙 정의서와 같은 것을 JSON 형태로 생성하는 것을 뜻한다.

배포를 하게 되어 새로운 ECS 이미지가 생성된다면, 새로운 태스크를 정의하고 이것으로 ECS에서 호스팅할 수 있게 하는 작업이 필요하다. 물론, 우리는 자동화 과정으로 이것을 대체할 것이다.

각 요소에 대해서 상세한 설명은 AWS 공식 문서 를 참조하도록 하고, 여기서는 순수하게 사용을 위한 부분만 짚고 넘어가려고 한다.

ECS를 검색해서 새 테스크 정의 생성을 누른다.

맨 처음에 만나게 되는 것은 태스크 정의 패밀리 이름이다.
태스크 정의는 하나의 패밀리 정의 이름을 기반으로 계속해서 새로운 버전의 태스크들이 쌓이기 때문에 이렇게 패밀리 이름으로 감싸주는 것이라 이해하였다.

다른 내용들도 중요하긴 한데, 그것들은 그냥 기본으로 두더라도 제일 중요한건 우리의 docker image가 컨테이너화할 때 필요한 정보들을 작성해주어야 한다.
아래의 환경 변수 부분은 직접 저렇게 입력해도 되고, S3에 파일형태로 저장했다가 추가하여도 된다.

이 작접 정의서에 따라서 ECS가 컨테이너를 생성해줄것이다.

로컬에서 직접 docker을 이용해서 컨테이너 띄울 때를 생각해보면 이해에 도움이 될 것이다.

docker run -it -d -p 20160:20160 -e PORT=20160 testimage

여튼 그렇게 태스크 정의를 생성하게 되면, 아래와 같은 화면일 것인데

위에 보이는 태스크 정의 이름이 git action secret의 ECS_TASK_DEFINITION 부분에 들어갈 값이 된다.

      - name: Generate task-definition.json from latest active ECS task definition
        run: |
          aws ecs describe-task-definition \
            --task-definition ${{ secrets.ECS_TASK_DEFINITION }} \ <-- 여기
            --query taskDefinition \
            > task-definition.json

Run 파트는 간단히 설명하면 aws cli를 이용하여 task 정의에 대한 json을 추출하는 문법이다. (생성 후 task-definition.json이라는 이름의 파일에 저장시키게 하였다. 이 파일은 자동으로 다음 스탭에서 동일 이름으로 참조가 가능하다 )

자세한 옵션 설명은 task-definition cli 공식문서을 참조하도록 한다.

그러면 이 다음 스탭으로 넘어가보도록 하자.

      - name: Render Amazon ECS task definition
        id: render-task-definition
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          # this step exports the task-definition as an output automatically (used for next step)
          task-definition: task-definition.json
          container-name: ${{ secrets.ECS_TASK_CONTAINER_NAME }}
          image: ${{ steps.build-image.outputs.image }}

해당 스탭은 받아온 task-definition json을 실제 ECS에 돌아가기 위한 definition으로 랜더링하는 역할을 한다. (자세한 내부 구조는 잘 모르겠다)

aws-actions에서 제공해주는 aws-actions/amazon-ecs-render-task-definition@v1 을 활용하면 되며, 여기서 우리가 git action secret으로 정의해줘야 하는 부분은 아까 task-definition을 생성할 때 컨테이너 이름으로 정해놓았던 것을 넣어주면 된다.

그럼 이제 테스트 정의는 다 하였으니, 이 태스크를 기반하여 실제 컨테이너를 띄워줄 환경인 ECS 클러스터 정의를 하러 가야한다. (EC2로 대체해서 생각하면 이해하기 편하다.)

클러스터 그 자체는 서비스들을 묶어주는 집합의 이름만 해당하는 느낌이라 사실 이름 정의만 하면 된다.

그리고 나서 생성한 뒤 클러스터 내에서 묶여 있을 서비스들을 정의해야한다.
서비스는 단순하게 생각하면 배포 환경에 띄워져 있는 어플리케이션 서비스들이라고 생각하면 편하다. 자세한건 아래의 사진을 보면 더 이해가 쉬울것이다.

중간에 보이는 패밀리가 아까 우리가 정의했던 태스크 정의의 패밀리 이름이다.
현재 버전은 14로 되어있는데, 저 버전은 계속 바뀔것이다.(배포를 할 때마다)

서비스에 대한 이름을 정의해주고, 배포 옵션을 가야하는데,

사실 블루/그린 배포잔략을 선택하려면 AWS code deploy를 기반으로 해야한다.
그 부분까지 넣기는 너무 시간이 걸려서 일단 롤링업데이트로 진행하려고 한다.

참고로, 롤링 업데이트와 블루/그린 업데이트는 무중단 배포 기법들이며, 차이에 대해서는 간단히 설명하자면

1. 롤링 업데이트 : 현재 띄워져 있는 서비스를 유지하고 있는 상태에서, 점진적으로 서비스들을 하나하나 업데이트해나가면서 교체하는 방식. 필연적으로 두가지 버전이 동시에 호스팅되는 순간이 존재함.
   
   
2. 블루/그린 업데이트 : 현재 서비스를 유지하고 있는 상태에서, 다른 버전의 서비스들을 통째로 생성한 후, 로드밸런싱을 새로운 버전으로 치환한 뒤 기존 서비스를 죽이는 방법. 배포할 때 두 서비스를 다 띄울 자원이 필요함(즉 두배)
   

여튼, 이후 아까 만들어두었던 로드밸런서 설정도 불러온 후, 서비스를 생성 완료해주면 된다.

이후, 다음 git action step의 secret에 해당하는 값을 등록해주면 된다.

      - name: Deploy Amazon ECS task definition
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.render-task-definition.outputs.task-definition }}
          service: ${{ secrets.ECS_SERVICE }} <--- 이거
          cluster: ${{ secrets.ECS_CLUSTER }} <--- 이거
          wait-for-service-stability: true

이렇게 해두면, 이제 다 완료되었다.

이제 git action은 조건에 맞춰서 실행될것이다. 나는 develop의 pull request가 close되는 순간에 실행되게 해놓았기 때문에 아래처럼 CD action이 진행되며

on:
  pull_request:
    branches:
      - develop
    types: [closed]

task defininition에도 제대로 새로운 버전이 올라가게 되면서 CD 과정으로 생성된 새로운 이미지가 등록되게 되고,

ECS 클러스터 내의 서비스에는 해당 최신의 이미지가 구동되게 된다.

해당 구동된 컨테이너에 접근하기 위해서는 로드 밸런서를 통해 들어가야 한다.
우리의 로드 밸런서는 클러스터 서비스에 들어가서 로드밸런서 부분을 누른 후, DNS 주소를 통해 접근해볼 수 있다.

---

🚍 맺음글

긴 여정이었다... 사실 이 과정 하나하나가 순탄한 과정이 아니었기 때문에 해야할 것이 정말 많았는데,
그래도 그 과정을 겪으면서 배워간 것이 정말 많았기 때문에 기록으로 남기면서도 아직도 많이 정진해야 함을 느낀다.

이렇게 정리해뒀으니 나중에 (내가) 다시 구현하라고 할 때 도움이 많이 되겠지 히히.