Github Actions를 이용한 ECR, ECS 배포 자동화하기 (1)

팀 프로젝트를 진행하며 개발 및 배포 환경을 통일하기 위해 Docker를 활용해 백엔드 서버를 배포하였습니다. 

 AWS를 활용해 서버를 배포하는 과정에서 ECR과 ECS를 처음 접하게 되어 ECR과 ECS에 대해 정리해보겠습니다.

또한 코드가 변경되는 매번 ECR과 ECS를 업데이트를 하는 과정이 번거로웠기 때문에 Github Actions를 도입했는데, Github Actions에 대한 소개도 진행해보겠습니다.

ECR

https://aws.amazon.com/ko/ecr/

Amazon Elastic Container Registry(Amazon ECR)는 어디서나 애플리케이션 이미지 및 아티팩트를 안정적으로 배포할 수 있도록 뛰어난 성능 호스팅을 제공하는 완전관리형 컨테이너 레지스트리입니다. (Docker Hub와 비슷한 개념이라고 보시면 됩니다.)

 

ECR Private Repository에 Docker Image를 등록 해두면 권한이 있는 사용자만 도커 이미지에 접근할 수 있고,  Amazon ECS에서 Docker Image를 실행하여 컨테이너 기반 애플리케이션을 손쉽게 배포하고 관리할 수 있습니다. 이를 통해 ECR과 ECS 간의 통합된 워크플로를 활용해 더욱 간편하고 안전하게 컨테이너화된 서비스를 운영할 수 있습니다.

실제 AWS 계정 ECR 레포지토리

ECR Private Repository는 리포지토리 이름을 기준으로 관리되며, 동일한 리포지토리에 저장된 이미지는 태그(Tag)를 사용해 구분됩니다. 저희 프로젝트에서는 GitHub Actions에서 제공하는 {{github.sha}}를 활용하여, 현재 워크플로가 실행되는 커밋의 고유 해시 값을 태그로 설정하여 이미지를 관리하고 있습니다.

ECS

https://boostbrothers.github.io/technology/2020/01/29/AWS-ECS-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0/

Amazon Elastic Container Service(Amazon ECS)는 컨테이너 애플리케이션을 쉽게 배포, 관리 및 확대할 수 있도록 도와주는 완전 관리형 컨테이너 오케스트레이션 서비스입니다. 

 

ECR에 저장된 이미지를 실행하기 위해 AWS에서 제공하는 EKS와 ECS 서비스 중 ECS를 선택한 이유는 2가지 정도의 이유가 있었습니다.

 

1. EKS는 Kubernetes를 기반으로 다양한 커스터마이징과 설정 옵션을 제공하지만, Kubernetes에 대한 학습이 필요하고, 짧은 시간 안에 적용하기 어렵다고 판단했습니다.
2. EKS는 클러스터 마스터와 워커 노드에 대한 추가 비용이 발생하는 반면, ECS는 클러스터 구성에 별도의 비용이 들지 않아 비용 효율적이라고 생각했습니다.

이러한 이유로, 저희 팀은 ECS를 활용해 백엔드 서버 이미지를 효율적으로 배포, 관리할 수 있었습니다.

ECS 구성요소

https://blog.kyobodts.co.kr/2022/03/25/aws-ecs%EB%9E%80/

ECS의 구성에는 Task Definition, Task, Service, Cluster가 있습니다.

• Task Definition: 컨테이너를 실행하기 위해 정의한 설정입니다.
• Task : Task Definition에 의해 배포된 컨테이너 Set입니다.
• Service: 클러스터에 Task를 몇 개나 배포할 것인지 결정하고 ELB와 연결하거나 Auto Scaling을 설정하는 등 Task의 LifeCycle을 관리합니다.
• Cluster: Task가 배포되는 환경들이 논리적으로 그룹화되는 단위를 의미합니다.

ECS Cluster는 미리 정의해둔 Task Definition을 읽은 후 ECR Image를 Pull하여 컨테이너(Task)를 실행시킵니다.

Task가 실행되면, ECS는 정의된 설정에 따라 컨테이너를 시작하고, 필요에 따라 EC2 또는 Fargate(서버리스)에서 실행합니다.

Task Definition

이 중에서 ECS Task Definition에 대해서 자세하게 설명하자면

• Task에 실행될 하나 이상의 컨테이너에 대해서 정의하는 작업입니다.
• 컨테이너별로 할당될 CPU/메모리 크기, 포트 매핑 목록, 환경 변수 목록, 연결할 볼륨 목록 등이 포함되며, 작업 별로는 네트워크 모드, 작업에 할당될 IAM role ARN, 작업을 실행시키는데 사용할 IAM role ARN 등의 내용이 포함됩니다.
• Task Definition은 한번 생성되면 삭제할 수 없습니다. 따라서 작업 정의를 수정하려면, 기존의 작업 정의로부터 수정된 새로운 작업 정의를 생성해야 합니다.
• 이러한 작업 정의의 버전들을 구분하기 위해 작업 정의에는 리비전이라는 자동으로 증가되는 숫자 값이 할당됩니다. 서로 다른 리비전을 갖는 작업 정의의 모음을 작업 정의 패밀리라고 부릅니다.
• 예를 들어, "airflow-task" 작업 정의 패밀리를 정의 했다면 airflow-task:1, airflow-taks:2 등의 작업 정의들이 포함될 수 있습니다.

Task Definition의 json형식은 아래와 같습니다.

{
    "family": "작업 정의 패밀리",
    "containerDefinitions": [
        {
            "name": "컨테이너 이름",
            "image": "이미지 주소(ECR Image)",
            "cpu": 0,
            "portMappings": [
                {
                    "name": "database",
                    "containerPort": 3306,
                    "hostPort": 3306,
                    "protocol": "tcp",
                    "appProtocol": "http"
                },
                ... (생략)...
}

 

하지만 이렇게 배포한 후 Server 코드가 변경되면 ECR에 이미지를 다시 등록하고, ECS Task Definition을 업데이트한 뒤, ECS Cluster에서 재실행하는 반복적인 작업을 수동으로 진행해야 했습니다. 그래서 저희는 코드 변경 사항이 발생할 때 자동으로 배포까지 진행할 수 있는 방법을 찾게 되었고, 해결책으로 GitHub Actions를 도입하게 되었습니다.

Github Actions

Github Actions는 소프트웨어 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 도구입니다.
특정 Event가 발생했을 때 사용자가 정의해둔 Workflow를 실행해줍니다. 

이제부터 핵심 용어들에 대해서 설명해보겠습니다.

(1) Workflow (워크플로우)

• 하나 이상의 작업을 실행할 구성 가능한 자동화된 프로세스입니다.
• Github 리포지토리의 .github/workflows 디렉터리에 yml 파일을 작성해서 워크플로우를 정의합니다.

(2) Event (이벤트)

• Workflow 실행을 트리거하는 특정 활동이나 규칙입니다.
• 예를 들어 다음과 같은 이벤트를 정의할 수 있습니다.
  • Pull Request 생성했을 때
  • Issue를 Open 했을 때
  • Repository에 Commit을 Push할 때

(3) Job (작업)

• 각 단계에서 실행되는 셸 스크립트 또는 실행되는 작업입니다.
• Job은 여러 Step으로 구성되고, 가상 환경의 인스턴스에서 실행됩니다.
• 다른 Job의 실행에 의존 관계 가지거나 독립적일 수 있습니다.

(4) Step 

• Task 집합을 의미합니다.

(5) Action (액션)

• 자주 반복되는 태스크를 수행하기 위해 재사용이 가능한 컴포넌트를 정의해 둔 걸 의미합니다.

name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v2

위에서의 aws-actions/~~ 부분이 action을 의미합니다.

(6) Runner (실행기)

• Trigger될 때 Workflow를 실행될 인스턴스(서버)를 의미합니다.
• GitHub은(는) 워크플로를 실행할 Ubuntu Linux, Microsoft Windows, macOS 실행기를 제공합니다.
• 각 워크플로 실행은 새로 프로비저닝된 새 가상 머신에서 실행됩니다.

Github Actions을 이용한 CI/CD 파이프라인 정의

https://aws.amazon.com/ko/blogs/containers/create-a-ci-cd-pipeline-for-amazon-ecs-with-github-actions-and-aws-codebuild-tests/

참고한 레퍼런스는 다음과 같고, 현재 프로젝트에서는 CI 부분은 제외하고 CD 파이프라인만 구축하였습니다. 

아직은 완성되지 않아서, 좀 더 공부해서 다음 주에 Github Actions 부분을 소개해보겠습니다.

 

감사합니다 :)

레퍼런스

github action의 yaml파일 톺아보기

[AWS] ECS란? – 교보DTS 기술 블로그

AWS ECS 살펴보기 | 비브로스 기술 블로그

Create a CI/CD pipeline for Amazon ECS with GitHub Actions and AWS CodeBuild Tests | Amazon Web Services

GitHub Actions 설명서 - GitHub Docs

Github Action 사용법 정리