CodePipeline으로 ECS 배포 자동화하기

들어가며

ECS로의 전환 이유

기존 인프라 구성

기존 인프라의 문제점

1. 새로운 타이어 커머스 API 서버를 위한 서버 환경을 다시 구성해야했고,

2. MVP인 타이어 커머스 API 서버의 자원 사용량이 크지 않음에도 인스턴스 하나를 통째로 사용해야했으며,

3. Terraform으로는 EC2 오토스케일링 그룹에 대한 CodeDeploy 블루/그린 배포 방식을 관리할 수 없다

ECS의 장점

1. 공개된 이미지들에 몇가지 설정만을 더하는 방식으로 쉽게 환경을 구성할 수 있고,

2. 0.25vCPU, 256MB 메모리 등, 작은 단위로 자원을 분배할 수 있며,

3. Terraform으로 ECS에 대한 CodeDeploy 블루/그린 배포 방식을 관리할 수 있기 때문에

ECS 기본 개념

클러스터(Cluster)

용량 공급자(Capacity Provider)와 용량 공급자 전략 (Capacity Provider Strategy)

용량 공급자

용량 공급자 전략

작업 정의(Task Definition)와 작업(Task)

네트워크 모드

환경 변수

작업 역할(Task Role)과 작업 실행 역할(Task Execution Role)

서비스(Service)

ECR 이미지 저장소(ECR Repository)

CodePipeline을 통한 ECS 배포 자동화

1. ECS. (Rolling Update)
새로운 이미지 URL을 참조하는 작업 정의를 생성하고, ECS 서비스가 참조하는 작업 정의를 업데이트합니다. ECS 서비스의 작업 정의를 수동으로 변경하는 것과 동일한 방식으로 배포가 이루어집니다.

2. CodeDeploy 블루/그린 배포.
ECS 서비스를 타겟으로하는 CodeDeploy 배포 그룹을 통해 배포를 진행합니다. 블루/그린 방식은 기존 작업 정의 기반의 작업들(블루 그룹)은 유지한채로, 같은 개수의 새로운 작업 정의 기반 작업들(그린 그룹)을 실행합니다. 그리고 블루 그룹으로 가는 트래픽을 서서히 그린 그룹 전환하고, 전환이 완료되면 블루 그룹의 작업들을 종료하는 방식으로 배포가 이뤄집니다.

ECS 클러스터 생성

ECS 클러스터 생성

오토스케일링 그룹 생성

#!bin/bash
echo Configuring ECS agent...
sudo cat > /etc/ecs/ecs.config <<EOF
ECS_CLUSTER=[ECS 클러스터명]
EOF

오토스케일링 그룹을 ECS 클러스터 용량공급자로 등록

컨테이너별 Dockerfile 작성

project root
├── nginx (Nginx 컨테이너)
│		├── Dokerfile
|		└── nginx.conf
└── app (애플리케이션 컨테이너)
		├── Dockerfile
		├── package.json
		└── src
				├── main.ts
				└── ...

FROM node:14 AS builder
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build

FROM node:14-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json

EXPOSE 8081
ENTRYPOINT ["node", "dist/main"]

FROM nginx:stable-alpine
COPY ./nginx.conf /etc/nginx/nginx.conf

EXPOSE 80
ENTRYPOINT ["nginx", "-g", "daemon off;"]

ECR 이미지 저장소 생성

• aws ecr get-login-password --region ap-northeast-2
ECR 레지스트리에 로그인 할 수 있는 비밀번호를 출력합니다. 이 명령어를 실행하기 위해서는 로컬 환경의 AWS CLI에 부여된 자격 증명에 ecr:GetAuthorizationToken 액션 실행 권한이 포함되어 있어야합니다. AWS CLI에 부여될 자격 증명을 관리하는 방법은 AWS 문서를 참조하세요.

• docker login --username AWS --password-stdin [ECR 레지스트리 URL]
이전 명령어로 발급 받은 비밀번호를 통해 docker CLI가 ECR 레지스트리에 접근 가능하도록 로그인시킵니다.

• docker build -t [이미지명] [Dockerfile이 포함된 디렉토리 path]
도커 이미지를 빌드합니다.

• docker tag dev-drcha-app:latest [ECR 이미지 저장소 URL]:latest
이전 명령어를 통해 빌드한 이미지가 ECR 이미지 저장소에 latest 태그로 저장될 수 있도록 이미지에 latest 태그를 붙입니다.

• docker push [ECR 이미지 저장소 URL]:latest
latest 태그를 붙인 이미지를 ECR 이미지 저장소에 푸시합니다.

taskdef.json 작성

{
  "family": "sample-application-task-definition",
  "networkMode": "awsvpc",
  "cpu": "640",
  "memory": "1152",
  "taskRoleArn": "<TASK_ROLE_ARN>",
  "executionRoleArn": "<TASK_EXECUTION_ROLE_ARN>",
  "containerDefinitions": [
    {
      "name": "nginx",
      "image": "<NGINX_IMAGE_URL>",
      "essential": true,
      "cpu": 128,
      "memory": 128,
      "portMappings": [
        {
          "protocol": "tcp",
          "hostPort": 80,
          "containerPort": 80
        }
      ],
			"environment": [
        {
          "name": "[환경 변수명]",
          "value": "[환경 변수값]"
        }
      ],
      "environmentFiles": [
        {
          "type": "s3",
          "value": "[S3 환경 변수 객체 ARN]"
        }
      ],
      "secrets": [
        {
          "name": "[환경 변수명]",
          "valueFrom": "[환경 변수값이 저장된 AWS Secrets Manager secret, 또는 AWS System Manager 파라미터 스토어 파라미터 ARN]"
        }
      ]
    },
    {
      "name": "app",
      "image": "<APPLICATION_IMAGE_URL>",
      "essential": true,
      "cpu": 512,
      "memory": 1024,
      "portMappings": [],
		  "environment": [
        {
          "name": "[환경 변수명]",
          "value": "[환경 변수값]"
        }
      ],
      "environmentFiles": [
        {
          "type": "s3",
          "value": "[S3 환경 변수 객체 ARN]"
        }
      ],
      "secrets": [
        {
          "name": "[환경 변수명]",
          "valueFrom": "[환경 변수값이 저장된 AWS Secrets Manager secret, 또는 AWS System Manager 파라미터 스토어 파라미터 ARN]"
        }
      ]
    }
  ]
}

• family: taskdef.json 파일을 바탕으로 생성될 작업 정의의 패밀리명입니다. 프로젝트명에 맞게 자유롭게 작성하시면 됩니다.

• networkMode: 작업의 네트워크 모드. 앞서 설명하였듯, 특별한 이유가 없는 경우 awsvpc 모드를 사용하는 것이 좋습니다.

• cpu, memory: 작업에서 사용할 CPU와 메모리 자원량. cpu의 경우 1024가 1vCPU에 해당하며, memory의 단위는 MiB입니다. 작업의 자원량은 작업의 모든 컨테이너에 부여된 자원량의 합보다 커야합니다. 문자열로 입력해야합니다.

• taskRoleArn, executionRoleArn: 작업 IAM 역할 ARN과 작업 실행 IAM 역할 ARN입니다. 아직 두 역할을 생성하지 않았으니, 일단은 비워둡니다.

• containerDefinitions: 작업에서 실행할 컨테이너 정의 목록.
• name: 컨테이너명. 이번 글에서는 애플리케이션 컨테이너와 nginx 컨테이너를 한 작업에서 실행하므로, nginx와 app으로 설정하였습니다.
• image: 컨테이너에서 실행할 이미지 URL. 이전 단계에서 빌드해 ECR 이미지 장소에 latest 태그를 붙여 푸시한 이미지 URL을 입력합니다.
• essential: 이 필드가 true로 설정된 컨테이너 실행에 실패하면 작업 전체가 실행에 실패합니다. 이 필드가 false로 설정된 컨테이너 실행에 실패하더라도 작업은 실행에 성공합니다. 한 작업에는 최소한 하나의 essential 컨테이너가 포함되어야합니다. 이 경우 애플리케이션을 정상적으로 실행하기 위해서는 Nginx와 애플리케이션 컨테이너가 모두 실행되어야하므로 모든 컨테이너를 essential 컨테이너로 설정합니다.
• cpu, memory: 컨테이너에서 사용할 CPU와 메모리 자원량입니다. 단위는 작업의 단위와 같습니다. 그러나, 컨테이너의 자원량은 문자열이 아닌 정수로 입력해야합니다.
• portMapping: 네트워크 인터페이스(hostPort)와 컨테이너(containerPort) 간에 매핑할 포트 목록입니다. awsvpc 네트워크 모드의 경우, 네트워크 인터페이스와 컨테이너의 포트를 다르게 설정할 수 없습니다. 또한 awsvpc 네트워크 모드의 경우, 컨테이너 간 네트워크 연결을 위해 별도의 포트 매핑을 설정할 필요가 없습니다. 작업의 모든 컨테이너에 같은 네트워크 인터페이스가 연결되므로, 로컬 호스트에 포트를 지정해 다른 컨테이너와 네트워크 연결을 만들 수 있습니다. 따라서, 하나의 작업에 포함된 컨테이너들이 모두 다른 포트를 사용해야합니다. 이번 글에서는 Nginx 컨테이너의 80번 포트만 외부로 노출하고, Nginx 컨테이너의 80번 포트로의 요청을 애플리케이션 컨테이너에서 사용하는 포트로 전달하도록 Nginx를 설정합니다.
• environment: 컨테이너가 실행되는 환경의 환경 변수 목록입니다. taskdef.json 파일 또한 깃허브 등에 올라가므로, API key와 같은 민감 정보는 이 필드로 전달하면 안됩니다.
• environmentFiles: 환경 변수들을 담은 파일을 통해 환경 변수를 설정할 수 있습니다. 현재 지원되는 유일한 파일 유형은 S3 객체입니다. value 필드에는 S3 객체의 ARN을 입력합니다.
• secrets: 민감 정보를 환경 변수로 전달할 때 사용합니다. AWS Secrets Manager의 secert이나, AWS System Manager의 파라미터 스토어 내 파라미터로부터 값을 가져올 수 있습니다. valueFrom 필드에 입력할 값은 AWS 문서를 참조하세요.

작업 IAM 역할 및 작업 실행 IAM 역할 생성

1. ECR 이미지 저장소 접근 및 이미지 다운로드 권한.

{
	  "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "ecr:GetAuthorizationToken",
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage"
            ],
            "Effect": "Allow",
            "Resource": [
                "[ECR Nginx이미지 저장소 ARN]",
                "[ECR 애플리케이션 이미지 저장소 ARN]"
            ]
        }
    ]
}

2. 환경 변수 파일 S3 객체 접근 권한 (environmentFiles 필드를 사용할 경우)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "s3:GetBucketLocation",
            "Effect": "Allow",
            "Resource": [
							"[환경 변수 파일이 저장된 S3 버킷 ARN]"
						]
        },
        {
            "Action": "s3:GetObject",
            "Effect": "Allow",
            "Resource": [
							"[환경 변수 파일 S3 객체 ARN]"
						]
        }
    ]
}

3. 환경 변수로 사용할 민감 정보를 가진 Secrets Manager secret, 또는 System Manager parameter 접근 권한. (secrets 필드를 사용할 경우)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "secretsmanager:GetSecretValue",
            "Effect": "Allow",
            "Resource": [
							"[Secrets Manager secret ARN]"
						]
        },
				{
						"Action": "ssm:GetParameters",
						"Effect": "Allow",
						"Resource": [
							"[System Manager parameter ARN]"
						]
				}
    ]
}

ECS 작업 정의 및 서비스 생성

작업 정의 생성

서비스 생성 (서비스 기본 설정)

서비스 생성 (로드밸런서 설정)

서비스 생성 (오토스케일링 설정)

buildec 및 appspec 작성

CodePipeline 생성

CodeStar Github connection 생성

CodeBuild 프로젝트 생성

CodeDeploy 애플리케이션 및 배포 그룹 생성

배포

개선점

이미지