모듈 2 - AWS Fargate를 활용해 서비스 만들기

소요 시간 : 60분

사용된 서비스:

개요

모듈 2에서는 Amazon Elastic Concainer Service에서 AWS Fargate를 사용하여 호스팅되는 새로운 마이크로서비스를 생성하여 Mythical Mysfits 웹 사이트가 애플리케이션 백엔드를 사용하여 통합할 수 있도록 합니다. AWS Fargate는 Amazon ECS에서 클러스터나 서버를 관리할 필요 없이 컨테이너를 배포할 수 있는 배포 옵션입니다. Mythical Mysfits 백엔드에서는 파이썬을 사용하여 네트워크 로드 밸런서 뒤에 있는 도커 컨테이너에 Flask 앱을 만들 것입니다.

AWS CloudFormation을 사용해 핵심 인프라 리소스 생성하기

서비스를 생성하기 전에, 우리는 서비스가 사용할 핵심 인프라 환경을 만들어야 합니다. 여기에는 Amazon VPC의 네트워킹 인프라와 AWS IAM이 포함됩니다. 이 인프라는 AWS 위에 있는 ECS 및 NAT 컨테이너의 권한을 정의할 것입니다. 이를 위해 AWS CloudFormation을 사용할 것입니다. AWS CloudFormation은 JSON 또는 YAML 파일 내에서 선언하는 AWS 리소스를 프로그래밍하여 CloudFormation Templates라고 하는 서비스로서 인프라(Importure as Code)의 공통 모범 사례를 지원합니다. /module-2/cfn/core.yml 에 필요한 모든 네트워크 및 보안 리소스를 생성하는 CloudFormation 템플릿을 제공했습니다. 이 템플릿은 다음 리소스를 생성합니다.

Amazon VPC - 10.0.0.0/16 프라이빗 IP 공간을 가진 4개의 서브넷 (퍼블릭 2개, 프라이빗 2개)과 필요한 라우트 테이블 구성을 가진 네트워크 환경입니다. 이 네트워크의 서브넷은 AWS 리전의 여러 물리적 시설에서 고가용성을 가능하게 하기 위해 별도의 AZ(AWS Availability Zones)에 생성됩니다.
두 개의 NAT Gateways - (각 퍼블릭 서브넷마다 하나, 즉 여러 개의 AZ에 걸쳐 있음) - 궁극적으로 우리의 프라이빗 서브넷에 배포할 컨테이너들이 인터넷과 통신하여 필요한 패키지를 다운로드할 수 있도록 합니다.
DynamoDB VPC Endpoint - 모듈 3에서 Amazon DynamoDB와 결합하기 위해 필요한 부분입니다.
Security Group - 도커 컨테이너와 연결 네트워크로드 밸런서를 통해 인터넷에서 포트 8080에서 트래픽을 수신합니다.
IAM Roles - IAM 역할이 생성됩니다 이런 IAM 역할은 DyanmoDB, S3 등과 같은 다른 AWS 서비스에 대한 액세스 권한을 생성하며 워크샵 동안 사용됩니다.

이런 리소스를 생성하기 위해 Cloud9 터미널에서 아래 명령어를 입력합니다. (리소스를 생성하기 위해 약 10분 정도가 소요됩니다.)

aws cloudformation create-stack --stack-name MythicalMysfitsCoreStack --capabilities CAPABILITY_NAMED_IAM --template-body file://~/environment/aws-modern-application-workshop/module-2/cfn/core.yml

아래 명령어 또는 콘솔에서 CloudFormation 스택 생성의 상태를 확인할 수 있습니다.

aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack

"StackStatus": "CREATE_COMPLETE"이 될 때까지 입력합니다.

이 응답을 수신하면 CloudFormation은 위에서 설명한 모든 핵심 네트워킹 및 보안 리소스 프로비저닝을 완료했으며 계속 진행할 수 있습니다. 계속 진행하기 전에 위의 스택이 CREATE_COMPLETE를 보일 때까지 기다립니다.

이 명령의 출력에서 나온 값을 나머지 워크샵에서 사용할 것입니다. 다음 명령을 실행하여 위의 description-stacks 명령을 IDE의 새 파일로 직접 출력하여 cloudformation-core-output.json로 저장할 수 있습니다

aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack > ~/environment/cloudformation-core-output.json

모듈 2a : AWS Fargate를 활용해 서비스 만들기

Flask 서비스 컨테이너 만들기

도커 이미지 빌드하기

다음으로 Flask로 생성된 마이크로서비스 API로 Mythical Mysfits 백엔드를 실행하는 데 필요한 모든 코드와 구성이 포함된 도커 컨테이너 이미지를 생성합니다. Cloud9 내에 도커 컨테이너 이미지를 구축하고 이를 Amazon Elastic Constant Registry(ECR)로 푸시할 것 입니다. ECR을 통해 나중에 Fargate를 사용하여 서비스를 생성할 때 컨테이너 이미지를 가져올 수 있습니다.

서비스 백엔드를 실행하는 데 필요한 모든 코드는 Cloud9 IDE에 복제된 저장소의 /module-2/app/directory에 저장됩니다. Flask를 사용하여 서비스 API를 만드는 파이썬 코드를 확인하고 싶다면 /module-2/app/service/mythicalMysfitsService.py 파일을 참조하세요.

도커는 사용자가 생성한 Cloud9 IDE에 이미 설치되어 있습니다. 도커 이미지를 빌드하기 위해 /module-2/app/service/requirements.txt 파일에 다음과 같이 itsdangerous==2.0.1 을 추가합니다.

도커 이미지를 빌드하기 위해 아래 명령어를 Cloud9 터미널에 입력해줍니다. 이때 REPLACE_ME_ACCOUNT_ID과REPLACE_ME_REGION를 이전에 CloudFormation의 **describe-stacks에 나온 값으로 변경해줍니다. 이 명령은 -t 옵션을 사용하여 도커 이미지를 특정 태그 형식으로 태깅하여 나중에 Amazon Elastic Container Registry 서비스로 푸시할 수 있도록 해줍니다.

docker build . -t REPLACE_ME_ACCOUNT_ID.dkr.ecr.REPLACE_ME_REGION.amazonaws.com/mythicalmysfits/service:latest

명령어를 입력하면 도커가 우리의 애플리케이션이 필요로 하는 모든 필수 종속성 패키지를 다운로드하고 설치하며, 내장된 이미지의 태그를 출력하는 것을 볼 수 있습니다. 나중에 참조할 수 있도록 이미지 태그를 복사합니다. 예제 태그는 다음과 같습니: 111111111111.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest

Successfully built 8bxxxxxxxxab
Successfully tagged 111111111111.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest

로컬에서 서비스 테스트하기

Cloud9 내에서 이미지를 로컬로 테스트하여 모든 것이 예상대로 작동하는지 확인해보겠습니. 이전 명령에서 나온 이미지 태그를 복사하고 REPLACE_ME_WITH_DOCKER_IMAGE_TAG를 변경 다음 명령을 실행하여 컨테이너를 로컬에 배포합니다(이 컨테이너는 실제로 AWS 내에 있는 Cloud9 IDE 내에 있습니다!)

docker run -p 8080:8080 REPLACE_ME_WITH_DOCKER_IMAGE_TAG

이 결과로 컨테이너가 로컬로 실행되고 있다는 메시지를 확인할 수 있습니다.

 * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)

로컬 요청으로 서비스를 테스트하려면 IDE 인스턴스에서 실행 중인 애플리케이션을 미리 보는 데 사용할 수 있는 Cloud9 IDE 내에 내장 웹 브라우저를 엽니다. 미리 보기 웹 브라우저를 열려면 Cloud9 메뉴 모음에서 Preview > Preview Running Application을 선택합니다.

그러면 IDE에 웹 브라우저를 사용할 수 있는 다른 패널이 열립니다. 새 패널의 미리 보기 브라우저의 주소 표시줄에 URI의 끝에 /mysfits를 추가하고 Enter 키를 누릅니다.

성공하면 /aws-moden-application-workshop/module-2/app/service/mysfits-response.json에 저장된 JSON 문서를 반환하는 서비스 응답이 표시됩니다. PC 또는 Mac에서 Ctrl-c를 눌러 서비스를 중지할 수 있습니다.

Amazon ECR에 도커 이미지 푸하기

성공적인 로컬 테스트를 통해 Amazon ECR(Amazon Elastic Constant Registry)에 컨테이너 이미지 저장소를 생성하고 이미지를 넣을 준비가 되었습니다. 레지스트리를 생성하려면 다음 명령을 실행하여 계정에 대해 생성된 기본 AWS ECR 레지스트리에 새 저장소를 생성합니다.

aws ecr create-repository --repository-name mythicalmysfits/service

이 명령에 대한 응답은 생성된 저장소에 대한 추가 메타데이터를 포함합니다. 컨테이너 이미지를 새 저장소로 푸시하려면 Docker 클라이언트의 인증 자격 증명을 저장소로 얻어야 합니다. 다음 명령을 실행하여 로그인 명령을 반환하여 Docker 클라이언트에 대한 자격 증명을 검색한 다음 자동으로 실행합니다(아래 $를 포함한 전체 명령 포함). 명령이 성공하면 'Login Succeeded'을 확인할 수 있습니다.

$(aws ecr get-login --no-include-email)

이제 위에서 복사한 태그를 사용하여 생성한 이미지를 ECR 저장소로 푸시합니다. 아래 명령을 사용하면 도커가 여러분의 이미지와 필요한 모든 이미지를 Amazon ECR에 푸시합니다.

docker push REPLACE_ME_WITH_DOCKER_IMAGE_TAG

다음 명령을 실행하여 ECR 저장소에 저장된 도커 이미지를 확인할 수 있습니다.

aws ecr describe-images --repository-name mythicalmysfits/service

Amazon ECS에서 서비스 사전 필요사항 구성하기

ECS 클러스터 생성하기

이제 우리는 AWS Fargate를 사용하여 Amazon ECS에 호스팅된 서비스에 배포할 수 있는 ECR 이미지를 가지고 있습니다. 마지막 모듈에서는 Cloud9 터미널을 통해 로컬로 테스트한 동일한 서비스가 이제 클라우드에 배포되고 네트워크 로드 밸런서와 함께 사용되는 것을 확인할 수 있습니다.

먼저 우리는 Amazon Elastic Constant Service(ECS)에 클러스터를 만들 것입니다. 이는 서비스 컨테이너가 배포될 "서버"의 클러스터를 나타냅니다. Fargate를 사용하면 실제로 서버를 프로비저닝하거나 관리할 필요 없이 컨테이너가 클러스터에 배포되도록 지정할 수 있습니다.

ECS에서 새 클러스터를 생성하려면 다음 명령을 실행합니다.

aws ecs create-cluster --cluster-name MythicalMysfits-Cluster

AWS CloudWatch Logs 그룹 생성하기

다음으로 AWS CloudWatch Logs에 새로운 로그 그룹을 만들 것입니다. AWS CloudWatch Logs는 로그 수집 및 분석을 위한 서비스입니다. 컨테이너가 생성하는 로그는 이 특정 그룹의 일부로 AWS CloudWatch 로그로 자동으로 푸시됩니다. 이는 컨테이너가 실행 중인 서버 인프라에 액세스할 수 없기 때문에 AWS Fargate를 사용할 때 특히 중요합니다.

CloudWatch 로그에서 새 로그 그룹을 생성하려면 다음 명령을 실행합니다.

aws logs create-log-group --log-group-name mythicalmysfits-logs

ECS 작업 정의 등록하기

이제 우리는 클러스터를 만들었고 컨테이너 로그가 푸시되는 곳에 로그 그룹을 정의하여 ECS 작업 정의를 등록할 준비가 되었습니다. ECS의 작업은 함께 스케쥴링되어야하는 컨테이너 이미지 세트입니다. 작업 정의는 컨테이너가 필요로 하는 컨테이너 세트와 자원 및 구성을 선언합니다. AWS CLI를 사용하여 방금 생성한 ECS 클러스터에 대해 새로운 컨테이너가 스케쥴링되야하는 방법에 대한 새로운 작업 정의를 작성합니다.

CLI 명령에 대한 입력으로 사용할 JSON 파일은 제공되었습니다. IDE에서 ~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json 파일에서 확인하실 수 있습니다. 파일 내에 아래의 표시된 부분을 적절하게 변경합니다. 이러한 값은 이전에 생성한 CloudFormation outputs 및 ECR에 푸시한 결과물을 통해 확인하실 수 있습니다.

모든 값을 변경하였으면 task-definition.json 파일을 저장하고 ECS에서 새로운 작업 정의를 등록하기 위해 아래 명령어를 실행합니다.

aws ecs register-task-definition --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json

명령이 정상적으로 실행이 되었다면 아래와 같은 결과를 확인하실 수 있습니다.

Fargate 서비스에 로드밸런싱하기

Network Load Balancer 생성하기

새로운 작업 정의가 등록되었다면 서비스 스택에 필요한 인프라 리소스를 프로비저닝할 준비가 완료되었습니다. 우리는 우리의 서비스를 인터넷에 직접 노출하는 대신에 서비스 앞단에 배치할 Network Load Balancer를 프로비저닝할 것입니다. 이는 우리의 프런트 웹 사이트 코드가 단일 DNS 이름과 통신할 수 있게 해주면서 우리의 백엔드 서비스는 수요에 따라 또는 고장이 발생하거나 새로운 컨테이너를 프로비저닝해야 하는 경우 여러 가용성 영역에 탄력적으로 스케일 인 및 아웃할 수 있게 해줍니다.

새 NLB를 프로비저닝하려면 Cloud9 터미널에서 다음 CLI 명령을 실행합니다(저장한 CloudFormation 출력에서 subnetIds를 가져옵니다). 아래 파일에 해당하는 부분을 복사해 명령어에서 REPLACE_ME_PUBLIC_SUBNET_ONE REPLACE_ME_PUBLIC_SUBNET_TWO을 바꿔줍니다.

aws elbv2 create-load-balancer --name mysfits-nlb --scheme internet-facing --type network --subnets REPLACE_ME_PUBLIC_SUBNET_ONE REPLACE_ME_PUBLIC_SUBNET_TWO > ~/environment/nlb-output.json

이 명령이 성공적으로 완료되면 IDE에 nlb-output.json 라는 새 파일이 생성됩니다. DNSName, VpcId, LoadBalancerArn을 나중에 사용할 것입니다.

로드 밸런서 타겟 그룹 생성하기

다음으로, CLI를 사용하여 NLB target group을 생성합니다. 대상 그룹을 사용하면 AWS 리소스가 로드 밸런서가 전달하기 위해 수신하는 요청의 대상으로 등록될 수 있습니다. 서비스 컨테이너는 프로비저닝 시 NLB로부터 트래픽을 수신할 수 있도록 이 대상에 자동으로 등록합니다. 이 명령에는 이전에 저장된 MythicalMysfitsCoreStack 출력에서 찾을 수 있는 값으로 vpc-id를 교체해야 하는 부분이 포함되어 있습니다.

aws elbv2 create-target-group --name MythicalMysfits-TargetGroup --port 8080 --protocol TCP --target-type ip --vpc-id REPLACE_ME_VPC_ID --health-check-interval-seconds 10 --health-check-path / --health-check-protocol HTTP --healthy-threshold-count 3 --unhealthy-threshold-count 3 > ~/environment/target-group-output.json

이 명령이 완료되면 IDE에 target-group-output.json으로 출력이 저장됩니다.

로드 밸런서 리스너 생성하기

다음 CLI를 사용하여 NLB의 로드 밸런서 리스너를 생성합니다. 이는 특정 포트에서 수신된 요청의 경우 위의 대상 그룹에 등록한 대상에 전달되어야 한다는 것을 로드 밸런서 알려 줍니다. REPLACE_ME_NLB_TARGET_GROUP_ARN 과 REPLACE_ME_NLB_ARN 값을 이전 단계에서 저장한 TargetGroup 및 NLB의 적절한 ARN으로 대체해야합니다.

aws elbv2 create-listener --default-actions TargetGroupArn=REPLACE_ME_NLB_TARGET_GROUP_ARN,Type=forward --load-balancer-arn REPLACE_ME_NLB_ARN --port 80 --protocol TCP

해당 명령어를 제대로 입력이 됐다면 아래와 같은 결과를 확인하실 수 있습니다.

Fargate의 서비스 생성하기

ECS를 위한 서비스 역할 생성하기

과거에 이미 ECS를 사용한 경우 이 단계를 건너뛰고 다음 단계로 이동할 수 있습니다. 이전에 ECS를 사용한 적이 없는 경우, ECS 서비스 자체에게 계정 내에서 ECS API 요청을 할 수 있는 권한을 부여하는 IAM에 서비스 연결 역할을 생성해야 합니다. 이는 ECS에서 서비스를 생성할 때 서비스가 계정 내에서 API를 호출하여 도커 이미지 풀링, 새 태스크 생성 등과 같은 작업을 수행할 것이기 때문에 필요합니다.

이 역할을 생하지 않으면 ECS 서비스는 필요한 조치를 수행할 수 있는 권한을 부여받지 않을 것입니다. 역할을 만들기 위해 터미널에서 다음 명령을 실행합니다.

aws iam create-service-linked-role --aws-service-name ecs.amazonaws.com

위의 역할 생성에 대한 오류가 발생한다면 계정에 자동으로 생성된 역할이 있으므로 에러를 무시할 수 있습니다.

서비스 생성하기

NLB가 생성 및 구성되고, ECS 서비스 적절한 권한을 부여함에 따라, 우리는 컨테이너가 실행될 실제 ECS 서비스를 생성하고 트래픽을 수신하기 위해 로드 밸런서에 등록할 준비가 되었습니다. CLI 입력에 대한 JSON 파일은 ~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json 에 있습니다. 이 파일에는 AWS Fargate로 해 서비스를 시작해야 한다는 표시와 함께 생성할 서비스에 대한 모든 구성 세부 정보가 포함되어 있습니다. 즉, Fargate를 사용하기 때문에 대상 클러스터 내의 서버를 프로비저닝할 필요가 없습니다. 이 서비스에서 사용되는 태스크의 일부로 예약된 컨테이너는 AWS가 완전히 관리하는 클러스터 위에서 실행됩니다.

IDE에서 ~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json 파일을 열어 아래 해당 부분을 변경 후 저장해야합니다.

서비스를 생성하기 위해 아래 명령어를 실행합니다.

aws ecs create-service --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json

명령어가 정상적으로 실행이 되면 아래와 같은 결과를 확인하실 수 있습니다.

서비스가 생성되면, ECS는 ECR로 푸시한 컨테이너를 실행하는 새 태스크를 프로비저닝하고 생성된 NLB에 등록합니다.

서비스 테스트하기

아래 예시처럼 NLB를 생성할 때 저장한 DNS 이름을 복사하고 Cloud9의 미리 보기 브라우저(또는 이 경우 웹 브라우저에서 서비스를 사용할 수 있음)를 사용하여 요청을 전송합니다.

http://mysfits-nlb-384625fd9b94eecd.elb.us-east-1.amazonaws.com

NLB 호출을 위해 Mythical Mysfits 업데이트하기

API Endpoint 교체하기

다음으로 이전에 S3 업로드한 하드 코딩 데이터를 사용하는 대신 우리가 만든 웹사이를 새로운 백엔드 API와 통합해합니다. API 호출에 대해 동일한 NLB URL을 사용하려면 다음 파일을 업데이트 해야 합니다. ( /module-2/web/index.html )

붙여넣기를 한 후에는 다음과 같습니다.

S3에 업로드하기

이 파일을 S3 호스팅 웹 사이트에 업로드하려면 모듈 1에서 생성된 버킷 이름을 다시 사용하고 다음 명령을 실행합니다.

aws s3 cp ~/environment/aws-modern-application-workshop/module-2/web/index.html s3://INSERT-YOUR-BUCKET-NAME/index.html

모듈 1의 마지막에 사용된 동일한 URL을 사용하여 웹 사이트를 열어 AWS Fargate에 배포된 도커 컨테이너 내에서 실행되는 Flask API에서 JSON 데이터를 검색하는 새로운 Mythical Mysfits 웹 사이트를 확인해보세요!

모듈 2b : AWS Code 서비스를 사용해 배포 자동화하기

CI/CD 파이프라인 생성하기

파이프라인 아티펙트를 위해 S3 버킷 생성하기

이제 서비스를 시작하고 실행하므로 Flask 서비스에 대한 코드 변경을 생각할 수 있습니다. 새로운 기능을 서비스에 배포할 때마다 위의 모든 단계를 거쳐야 하는 경우 개발 속도에 병목 현상이 발생할 수 있습니다. 바로 그곳에서 Continuous Integration and Continuous Delivery 또는 CI/CD가 등장합니다!

이 모듈에서는 완전히 관리되는 CI/CD 스택을 생성하여 마지막 모듈 동안 생성한 서비스에 코드 베이스로 변경한 모든 코드를 자동으로 전송합니다.

먼저, CI/CD 파이프라인 실행 중간에 생성된 임시 아티팩트를 저장하는 데 사용될 다른 S3 버켓을 생성해야 합니다. 이러한 아티팩트의 새 버킷 이름을 선택하고 다음 CLI 명령을 사용하여 하나를 생성합니다.

aws s3 mb s3://REPLACE_ME_CHOOSE_ARTIFACTS_BUCKET_NAME

다음으로 이 버킷에는 버킷 정책이 있어야 그 안에 저장된 데이터에 대한 사용 권한을 정의할 수 있습니다. 그러나 누구나 접근할 수 있도록 해주는 웹사이트 버과는 달리, 우리의 CI/CD 파이프라인만이 이 버킷에 접근할 수 있어야 합니. 이 정책에 필요한 JSON 파일은 ~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json 에 위치합니다. 이 파일을 열면 이전에 MythicalMysfitsCoreStack의 일부로 생성된 ARN과 CI/CD 아티팩트에 대해 새로 선택한 버킷 이름을 포함하도록 여러 문자열을 교체해야 합니다.

이 파일을 수정하고 저장한 후에는 다음 명령을 실행하여 CI/CD 파이프라인에 이 버킷에 대한 액세스를 허용합니다.

aws s3api put-bucket-policy --bucket REPLACE_ME_ARTIFACTS_BUCKET_NAME --policy file://~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json

CodeCommit 리포지토리 생성하기

코드를 푸시하고 저장할 장소가 필요하기에 다음 CLI를 통해 AWS CodeCommit 리포지토리를 생성합니다.

aws codecommit create-repository --repository-name MythicalMysfitsService-Repository

CodeBuild 프로젝트 생성하기

우리의 코드를 저장할 저장소와 CI/CD 아티팩트에 사용될 S3 버킷사용하여 CI/CD 스택에 서비스 빌드가 발생할 수 있도록 추가할 수 있습니다. 이것은 AWS CodeBuild 프로젝트를 생성함으로써 가능합다. 빌드 실행이 트리거될 때마다 AWS CodeBuild는 자동으로 빌드 서버를 우리의 구성에 프로비저닝하고, 우리의 docker 이미지를 구축하기 위해 필요한 단계를 수행하고, 새로운 버전을 우리가 생성한 ECR 저장소로 푸시합니다.

Python 코드를 패키징하고 도커 컨테이너를 빌드하고 푸시하는 빌드 단계는 ~/environment/aws-modern-application-workshop/module-2/app/buildspec.yml 파일에 포함되어 있습니다. buildspec.yml 파일은 CodeBuild 프로젝트 내에서 빌드 실행에 필요한 단계를 지시하기 위해 생성하는 것입니다.

CodeBuild 프로젝트를 생성하려면 매개 변수를 사용하여 다른 CLI 입력 파일을 리소스별로 업데이트해야 합니다. 이 파일은 ~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json에 위치합니다. 마찬가지로 MythicalMysfitsCoreStackOutput에서 이전처럼 이 파일의 값을 대체합니다. 일단 저장되면 CLI를 사용하여 다음을 실행하여 프로젝트를 생성합니다.

aws codebuild create-project --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json

CodePipeline 파이프라인 생성하기

마지막으로 코드 변경 사항이 저장소로 푸시될 때마다 빌드가 자동으로 발생할 수 있도록 CodeComit 저장소를 CodeBuild 프로젝트와 지속적으로 통합할 수 있는 방법이 필요합니다. 그런 다음 새로 만든 아티펙트를 ECS의 서비스에 지속적으로 전달할 수 있는 방법이 필요합니다. AWS CodePipeline은 다음 번에 생성할 파이프라인에 이러한 작업을 결합하는 서비스입니다.

코드 변경이 CodeCommit 저장소에 푸시될 때마다 CodePipeline은 빌드가 발생할 수 있도록 AWS CodeBuild 프로젝트에 최신 코드를 전달할 것입다. CodeBuild가 성공적으로 구축되면 CodePipeline은 CodeBuild 실행으로 ECR에 푸시한 최신 컨테이너 이미지를 사용하여 ECS에 배포합니다.

이러한 모든 단계는 AWS CLI에 대한 입력으로 파이프라인을 생성하는 JSON 파일에 정의됩니다. 이 파일은~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json 에 위치합니다. 열어서 필요한 부분을 변경하고 파일을 저장합니다.

저장한 후 다음 명령을 사용하여 CodePipeline에 파이프라인을 생성합니다.

aws codepipeline create-pipeline --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json

ECR 이미지 리포지토리에 자동화된 접근 허용하기

CI/CD 파이프라인이 엔드 투 엔드로 성공적으로 실행되 전 마지막 단계가 남았습니다. CI/CD 파이프라인이 있으면 컨테이너 이미지를 ECR에 수동으로 푸시하지 않습니다. CodeBuild가 새 이미지를 푸시합니다. ECR 리포지토리 정책을 사용하여 이미지 저장소에서 작업을 수행할 수 있도록 CodeBuild 권한을 부여해야 합니다. 관련 정책 문서는 MythicalMysfitsCoreStack에서 생성한 코드 빌드 역할에 대한 특정 ARN으로 업데이트해야 하며, 정책 문서는 ~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json에 있습니다.

이 파일을 업데이트하고 저장한 다음 다음 명령을 실행하여 정책을 생성합니다.

aws ecr set-repository-policy --repository-name mythicalmysfits/service --policy-text file://~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json

성공적으로 생성되면, ECS에서 서비스에 코드 변경을 자동으로 전달하기 위해 작동하는 엔드 투 엔드 CI/CD 파이프라인이 생깁니다.

CI/CD 파이프라인 테스트하기

AWS CodeCommit을 이용한 Git 사용하기

새로운 파이프라인을 테스트하려면 Cloud9 IDE 내에서 git을 구성하고 CodeCommit 저장소와 통합해야 합니다.

AWS CodeCommit은 통합을 용이하게 하기 위해 사용할 git에 대한 자격 증명 도움말을 제공합니다. 다음 명령을 순차적으로 실행하여 AWS CodeComit에서 사용할 git을 구성합니다.

git config --global user.name "REPLACE_ME_WITH_YOUR_NAME"

git config --global user.email REPLACE_ME_WITH_YOUR_EMAIL@example.com

git config --global credential.helper '!aws codecommit credential-helper $@'

git config --global credential.UseHttpPath true

다음 터미널을 사용하여 IDE의 디렉토리를 environment 디렉토리로 변경합니다.

cd ~/environment/

이제 터미널 명령을 사용하여 저장소를 복제할 준비가 되었습니다.

git clone https://git-codecommit.REPLACE_REGION.amazonaws.com/v1/repos/MythicalMysfitsService-Repository

이는 우리에게 저장소가 비어있다는 것을 알려 줍니다. 다음 명령을 사용하여 애플리케이션 파일을 저장소 디렉토리에 복사하여 이를 수정합니다.

cp -r ~/environment/aws-modern-application-workshop/module-2/app/* ~/environment/MythicalMysfitsService-Repository/

코드 변화 푸시하기

이제 모듈 2에서 Fargate 서비스를 생성하는 데 사용한 완료된 서비스 코드가 AWS CodeCommit에서 방금 복제된 로컬 저장소에 저장됩니다. 우리가 만든 CI/CD 파이프라인이 작동하고 있다는 것을 입증하기 위해, 변경 내용을 적용하기 전에 Flask 서비스를 변경합니다. Cloud9에서 ~/environment/MythicalMysfitsService-Repository/service/mysfits-response.json 에 저장된 파일을 열고 mysfits의 age를 하나 수정한 후 저장합니다. 파일을 저장한 후 디렉토리를 새 저장소 디렉토리로 변경합니다.

cd ~/environment/MythicalMysfitsService-Repository/

그런 다음 다음 git 명령을 실행하여 코드 변경을 푸시합니다.

git add .
git commit -m "I changed the age of one of the mysfits."
git push

변경 내용이 저장소로 푸시되 AWS 콘솔에서 CI/CD 파이프라인의 진행 중인 변경 내용을 보려면 CodePipeline 서비스를 열 수 있습니다. 코드 변경을 수행한 후 Fargate에서 실행 중인 라이브 서비스에 변경 사항을 배포하는 데 약 5분에서 10분 정도 걸립니다. 이 시간 동안 AWS CodePipeline은 변경 사항이 CodeComit 저장소로 확인되었을 때 파이프라인 실행을 트리거하고, CodeBuild 프로젝트를 트리거하여 새 빌딩을 시작하고, CodeBuild에 의해 ECR로 푸시된 도커 이미지를 검색하며, 연결을 해제하기 위해 자동화된 ECS Update Service 작업을 수행합니다. 서비스에서 실행 중인 기존 컨테이너를 새로 생성된 이미지로 교체합니다. 브라우저에서 Mythical Mysfits 웹 사이트를 새로 고쳐 변경 사항이 적용되었는지 확인합니다. 코드 파이프라인 콘솔을 통해 코드 변경 진행 상황을 볼 수 있습니다.

Previous모듈 1 - IDE 설정 및 정적 웹 사이트 호스팅 Next모듈 3 - Amazon DynamoDB를 통해 데이터 티어 추가하기

Last updated 3 years ago