AWS 기반 프로젝트

현대적 웹 애플리케이션 구축

웹 애플리케이션 배포, 데이터베이스 연결 및 사용자 행동 분석

모듈 2: 웹 서버에서 애플리케이션 호스팅

이 모듈에서는 AWS Fargate를 사용하여 호스팅하는 마이크로서비스를 새로 생성합니다.  

개요

이 모듈에서는 Mythical Mysfits 웹 사이트를 애플리케이션 백엔드와 통합할 수 있도록 AWS Fargate를 사용하여 호스팅하는 새 마이크로서비스를 생성합니다.

AWS Fargate는 클러스터나 서버를 관리하는 부담 없이 컨테이너를 배포할 수 있는 Amazon Elastic Container Service(ECS)의 개발 옵션입니다. Mythical Mysfits 백엔드에는 Python을 사용하고 Network Load Balancer가 적용되는 Docker 컨테이너에 Flask 앱을 생성합니다. 이들 구성 요소가 프런트엔드 웹 사이트의 마이크로서비스 백엔드를 구성합니다.

Fargate를 선택한 이유는 무엇입니까?

이 모듈용으로 Fargate를 선택한 이유는 웹 및 모바일 플랫폼과 PaaS 플랫폼의 마이크로서비스 백엔드 같은 장기 실행 프로세스를 구축하는 데 적합하기 때문입니다. Fargate를 사용하면 컨테이너를 제어할 수 있으며 서버를 프로비저닝하거나 확장하는 번거로움 없이 필요에 따라 컨테이너를 유연하게 실행할 수 있습니다. 또한 네트워킹, 보안 및 서비스 간에 통신을 완벽하게 제어할 수 있으며, AWS 서비스와 기본적으로 통합되어 보안, 네트워킹, 액세스 제어, 개발자 도구, 모니터링, 로깅 등을 지원합니다.

Fargate 외에, 컴퓨팅을 지원하는 옵션으로 AWS Lambda를 사용할 수도 있습니다. Lambda는 Fargate와 동일하게 서버리스의 이점을 제공하면서도 데이터 변경 사항, 시스템 상태 변화 또는 사용자가 수행하는 작업에 실시간으로 대응해야 하는 데이터 중심의 애플리케이션에 최적의 솔루션이 됩니다. Lambda는 모듈 5에서 사이트에서의 고객 행동을 분석하는 데 사용하면서 자세히 살펴보도록 하겠습니다.

구현 지침

아래의 단계별 지침에 따라 AWS Fargate 서비스를 생성합니다. 이 모듈은 분량이 커서 3개의 하위 모듈로 나누었습니다. 모듈 2a에서는 서비스 배포를 준비하는 단계로서 코어 인프라를 설정합니다. 모듈 2b에서는 AWS Fargate를 사용하여 서비스를 배포합니다. 마지막으로 모듈 2c에서는 AWS Code Services를 사용하여 자동 배포를 설정합니다.

모듈 2A: 인프라 설정

서비스를 생성하려면 먼저 Amazon VPC의 네트워킹 인프라, AWS에서 ECS와 컨테이너에 부여할 권한을 정의하는 AWS Identity and Access Management 역할 등, 서비스에 사용할 핵심 인프라 환경을 구축해야 합니다.

인프라를 구축하는 데에는 AWS CloudFormation을 사용합니다. AWS CloudFormation은 CloudFormation 템플릿이라는 JSON 또는 YAML 파일 내에 선언하는 AWS 리소스를 프로그래밍 방식으로 프로비저닝하여 코드형 인프라의 일반적인 모범 사례를 지원할 수 있는 서비스입니다.  

  • 필요한 모든 네트워크 및 보안 리소스를 생성하는 CloudFormation 템플릿이 /module-2/cfn/core.yml에 있습니다. 이 템플릿은 다음 리소스를 생성합니다.

    • Amazon VPC - 10.0.0.0/16 프라이빗 IP 공간의 서브넷 4개(퍼블릭 서브넷 2개와 프라이빗 서브넷 2개)와 필요한 라우팅 테이블 구성을 포함하는 네트워크 환경입니다. 이 네트워크의 서브넷은 서로 다른 AWS 가용 영역(AZ)에 생성되므로 하나의 AWS 리전 내에 있는 여러 물리적 시설에 걸쳐 고가용성이 구현됩니다. 여러 개의 AZ가 고가용성을 실현하는 데 어떻게 도움이 되는지 자세히 알아보십시오.
    • 2개의 NAT 게이트웨이(퍼블릭 서브넷당 1개) - 프라이빗 서브넷에 배포할 컨테이너가 외부 인터넷과 통신하여 필요한 패키지 등을 다운로드할 수 있도록 합니다.
    • DynamoDB VPC 종단점 - 마이그로서비스 백엔드는 이후 단계(모듈 3)에서 지속성을 구현하기 위해 Amazon DynamoDB에 통합됩니다.
    • 보안 그룹 - Docker 컨테이너가 포트 8080에서 Network Load Balancer를 통해 인터넷 트래픽을 수신할 수 있도록 합니다.
    • IAM 역할 - Identity and Access Management 역할이 생성됩니다. 이 역할은 이 워크숍 전반에서 사용자가 생성하는 AWS 서비스 또는 리소스에 DynamoDB, 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

    스택 생성 상태는 AWS 콘솔을 통해 확인하거나 다음 명령을 실행하여 확인할 수 있습니다.

    aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack

    "StackStatus": "CREATE_COMPLETE" 상태가 표시될 때까지 describe-stacks 명령을 실행합니다.

    describe stacks

    (확대하려면 클릭)

    이 응답이 표시되면 CloudFormation이 위에서 설명한 모든 핵심 네트워킹 및 보안 리소스의 프로비저닝을 마쳤으므로 계속 진행할 준비가 되었다는 의미입니다. 위의 스택이 CREATE_COMPLETE 상태로 표시될 때까지 기다린 후 계속 진행합니다.

    이 명령의 출력에 표시되는 값은 워크숍의 나머지 단계에서 사용하게 됩니다. 다음 명령을 실행하여 위의 describe-stacks 명령을 cloudformation-core-output.json으로 저장되는 IDE의 새 파일에 직접 출력할 수 있습니다.

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

모듈 2B: AWS Fargate로 서비스 배포

다음으로, Mythical Mysfits 백엔드를 Flask로 생성한 마이크로서비스 API로서 실행하는 데 필요한 코드와 구성이 모두 포함된 Docker 컨테이너 이미지를 생성합니다. Cloud9을 사용하여 Docker 컨테이너 이미지를 구축한 후 Amazon Elastic Container Registry로 푸시합니다. Fargate를 사용하여 서비스를 생성할 때 이 레지스트리에서 Docker 컨테이너를 풀링할 수 있습니다.

아키텍처 다이어그램

로드 밸런서, Fargate로 차례로 이동
  • A: Docker 이미지 생성

    서비스 백엔드를 실행하는 데 필요한 모든 코드는 Cloud9 IDE에 복제한 리포지토리의 /module-2/app/ 디렉터리에 저장되어 있습니다. Flask를 사용하여 서비스 API를 생성하는 Python 코드를 검토하려면 /module-2/app/service/mythicalMysfitsService.py 파일을 살펴보십시오.

    Docker는 앞서 생성한 Cloud9 IDE에 이미 설치되어 있으므로 Docker 이미지를 로컬로 구축하기 위해서는 Cloud9 터미널에서 다음 두 가지 명령만 실행하면 됩니다.  

    첫 번째로 change directory를 실행하여 디렉터리를 ~/environment/module-2/app으로 변경합니다.

    cd ~/environment/aws-modern-application-workshop/module-2/app

    계정 ID와 기본 리전은 앞서 실행한 CloudFormation **describe-stacks의 출력에서 확인할 수 있습니다.

    다음 명령에서 REPLACE_ME_ACCOUNT_ID를 계정 ID로 바꾸고 REPLACE_ME_REGION을 기본 리전으로 바꾸어 Dockerfile로 Docker 이미지를 구축합니다. 이 파일에는 Docker 지침이 들어 있습니다. 이 명령은 나중에 이미지를 Amazon Elastic Container Registry 서비스로 푸시할 수 있도록 -t 옵션을 사용하여 특정 태그 형식으로 Docker 이미지에 태깅합니다.

    계정 ID를 확인하고 나면 Docker 이미지를 구축할 수 있습니다.

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

    Docker 다운로드가 표시되면 애플리케이션에 필요한 종속성 패키지를 모두 설치하고 구축된 이미지의 태그를 출력합니다. 나중에 참조할 수 있도록 이미지 태그를 복사합니다. 아래에 나와 있는 예제 태그는 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
    B: 로컬로 서비스 테스트

    Cloud9에서 로컬로 이미지를 테스트하여 모든 기능이 정상적으로 작동하는지 확인해보겠습니다. 이전 명령의 결과로 생성된 이미지 태그를 복사하고 다음 명령을 실행하여 컨테이너를 “로컬로” 배포합니다(AWS 내의 Cloud9 IDE에 배포).

    docker run -p 8080:8080 REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    그 결과로, Docker에서 컨테이너가 로컬로 실행 중이라는 메시지가 표시됩니다.

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

    로컬 요청을 통해 서비스를 테스트하기 위해 Cloud9 IDE에서 내장 웹 브라우저를 엽니다. 이 브라우저를 사용하여 IDE 인스턴스에서 실행 중인 애플리케이션을 미리 볼 수 있습니다.

    미리 보기 웹 브라우저를 열려면 [미리 보기] > [Cloud9에서 실행 중인 애플리케이션 미리 보기] 메뉴 모음을 선택합니다.

    preview-menu

     

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

    address-bar

    테스트가 성공적으로 완료된 경우 `/aws-modern-application-workshop/module-2/app/service/mysfits-response.json`에 저장된 JSON 문서를 반환하는 서비스의 응답이 표시됩니다.

    서비스 테스트를 완료하고 나면 PC 또는 Mac에서 CTRL-C를 눌러 중지할 수 있습니다.

    C: Amazon ECR로 Docker 이미지 푸시

    서비스를 성공적으로 로컬로 테스트하고 나면 Amazon Elastic Container Registry(Amazon ECR)에 컨테이너 이미지 리포지토리를 생성하고 여기로 이미지를 푸시할 수 있습니다. 레지스트리를 생성하려면 다음 명령을 실행합니다. 계정에 대해 생성된 기본 AWS ECR 레지스트리에 새 리포지토리가 생성됩니다.

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

    이 명령의 응답에는 생성된 리포지토리에 대한 추가 메타데이터가 포함되어 있습니다. 컨테이너 이미지를 새 리포지토리로 푸시하려면 해당 리포지토리에 대한 Docker 클라이언트의 인증 자격 증명을 획득해야 합니다.

    다음 명령을 실행하면 Docker 클라이언트의 자격 증명을 가져오는 login 명령이 반환되고 이 명령이 자동으로 실행됩니다(아래의 $를 비롯한 전체 명령 포함). 명령이 성공적으로 실행되면 [로그인 성공]이라는 메시지가 표시됩니다.

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

    다음으로, 위에서 복사한 태그를 사용하여 생성한 이미지를 ECR 리포지토리로 푸시합니다. Docker는 이 명령을 사용하여 위에서 생성한 이미지와 거기에 필요한 다른 모든 이미지를 Amazon ECR로 푸시합니다.

    docker push REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    다음 명령을 실행하여 ECR 리포지토리에 저장되어 있는 새로 푸시한 Docker 이미지를 표시합니다.

    aws ecr describe-images --repository-name mythicalmysfits/service
  • A: AWS Fargate 클러스터 생성

    이제 ECR에서 사용 가능한 이미지가 준비되었으므로 Amazon ECS에서 호스팅하는 서비스를 AWS Fargate를 사용하여 배포할 수 있습니다. 지난 모듈에서 Cloud9의 터미널을 통해 로컬로 테스트한 것과 동일한 서비스가 클라우드에 배포되고 Network Load Balancer를 통해 공개적으로 제공됩니다.

    먼저 Amazon Elastic Container Service(ECS)에 클러스터를 생성합니다. 이는 서비스 컨테이너를 배포할 대상 “서버”의 클러스터를 나타냅니다. AWS Fargate를 사용하기 때문에 서버는 "따옴표"로 표시되어 있습니다. Fargate에서는 실제로 사용자가 직접 서버를 프로비저닝하거나 관리해야 하는 부담 없이 컨테이너를 클러스터에 배포하도록 지정할 수 있습니다.

    ECS에 새 컨테이너를 생성하려면 다음 명령을 실행합니다.

    aws ecs create-cluster --cluster-name MythicalMysfits-Cluster
    B: AWS CloudWatch Logs 그룹 생성

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

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

    aws logs create-log-group --log-group-name mythicalmysfits-logs
    C: ECS 태스크 정의 등록

    클러스터를 생성하고 컨테이너 로그를 푸시할 로그 그룹을 정의했으므로 이제 ECS 태스크 정의를 등록할 수 있습니다. ECS에서 태스크는 함께 예약해야 하는 컨테이너 이미지의 세트입니다. 태스크 정의는 해당 컨테이너 세트와 리소스, 그리고 해당 컨테이너에 필요한 구성을 선언합니다. AWS CLI를 사용하여, 새로운 컨테이너 이미지를 방금 생성한 ECS 클러스터에 예약하는 방법에 대한 새 태스크 정의를 생성합니다.

    CLI 명령의 입력으로 사용할 JSON 파일을 제공해 드렸습니다.

    IDE에서 ~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json을 엽니다.

    표시된 값을 생성된 리소스에 해당하는 값으로 바꿉니다.

    이 값은 앞서 복사한 CloudFormation 응답과 앞서 ECR로 푸시한 Docker 이미지 태그에서 풀링됩니다(예: REPLACE_ME_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest).

    task-defintion.json의 값을 바꾼 후 저장합니다. 다음 명령을 실행하여 새 태스크 정의를 ECS에 등록합니다.

    aws ecs register-task-definition --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json
  • A: Network Load Balancer 생성

    새 태스크 정의가 등록되고 나면 서비스 스택에 필요한 인프라를 프로비저닝할 수 있습니다. 서비스를 인터넷에 직접 노출하지 않고 서비스 계층의 프런트엔드 역할을 할 Network Load Balancer(NLB)를 프로비저닝합니다. 그러면 프런트엔드 웹 사이트 코드가 단일 DNS 이름과 통신할 수 있으며, 장애가 발생하거나 새 컨테이너를 프로비저닝해야 할 경우에 백엔드 서비스가 수요에 따라 탄력적으로 확대/축소될 수 있습니다.

    새 NLB를 프로비저닝하려면 Cloud9 터미널에서 다음 CLI 명령을 실행합니다(저장한 CloudFormation 출력에서 서브넷 ID 검색).

    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을 사용하게 됩니다.

    B: 로드 밸런서 대상 그룹 생성

    다음으로, CLI를 사용하여 NLB 대상 그룹을 생성합니다. 대상 그룹은 AWS 리소스가 향후 로드 밸런서에 수신되는 요청의 대상으로 자신을 등록할 수 있게 해줍니다. 이 예제에서 서비스 컨테이너는 이 대상에 자동으로 등록하므로 NLB가 프로비저닝되면 서비스 컨테이너가 NLB에서 트래픽을 수신할 수 있습니다. 이 명령에서는 값을 하나 바꾸어야 합니다. 즉, vpc-id를 앞서 저장한 CloudFormation에서 반환된 MythicalMysfitsCoreStack 출력의 값으로 바꾸어야 합니다.

    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에 저장됩니다. TargetGroupArn 값은 후속 단계에서 참조해야 합니다.

    C: 로드 밸런서 리스너 생성

    다음으로, CLI를 사용하여 NLB의 로드 밸런서 리스너를 생성합니다. 그러면 로드 밸런서가 특정 포트에서 수신되는 요청을 위의 대상 그룹에 등록된 대상으로 전달합니다. 표시된 2개의 값을 TargetGroup의 해당 ARN과 이전 단계에서 저장한 NLB로 바꿉니다.

    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
  • A: ECS의 서비스 연결 역할 생성

    이전에 이미 ECS를 사용했던 사용자는 이 단계를 건너뛰고 다음 단계로 넘어가면 됩니다. 이전에 ECS를 사용한 적이 없는 경우 계정 내에서 ECS API 요청을 생성할 수 있는 권한을 ECS 서비스 자체에 부여하는 **서비스 연결 역할**을 IAM에 생성해야 합니다. ECS에서 서비스를 생성하면 해당 서비스가 계정 내에서 API를 호출하여 Docker 이미지를 풀링하고 새 태스크를 생성하는 등의 작업을 수행하므로 이 역할이 필요합니다.

    이 역할을 생성하지 않으면 필요한 작업을 수행할 권한이 ECS 서비스에 부여되지 않습니다. 이 역할을 생성하려면 터미널에서 다음 명령을 실행합니다.  

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

    위의 명령에서 해당 역할이 이미 있다는 오류 메시지가 반환될 경우 이전에 계정에서 해당 역할이 자동으로 생성되었음을 나타내므로 오류 메시지를 무시하면 됩니다.

    B: 서비스 생성

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

    IDE에서 ~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json을 열고 REPLACE_ME로 표시된 값을 바꿉니다. 이 파일을 저장한 후 다음 명령을 실행하여 서비스를 생성합니다.

    aws ecs create-service --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json
    C: 서비스 테스트

    NLB를 생성할 때 저장한 DNS 이름을 복사하고 Cloud9에서 미리 보기 브라우저를 사용하여 해당 DNS 이름에 대한 요청을 보냅니다. 이제 서비스를 인터넷에서 사용할 수 있으므로 일반 웹 브라우저를 사용해도 됩니다. mysfits 리소스로 요청을 보내봅니다.

    http://mysfits-nlb-123456789-abc123456.elb.us-east-1.amazonaws.com/mysfits

    앞서 Cloud9에서 로컬로 Docker 컨테이너를 테스트할 때 수신된 것과 동일한 JSON 응답이 표시될 경우 Flask API가 AWS Fargate에서 실행 중임을 의미합니다.

    참고: 이 Network Load Balancer에는 SSL/TLS 인증서가 설치되어 있지 않으므로 HTTP(http://) 요청만 지원합니다. 이 자습서에서는 http://만 사용하여 요청을 제출해야 합니다. https:// 요청은 정상적으로 작동하지 않습니다.

  • A: API 엔드포인트 교체

    다음으로, 앞서 S3로 업로드한 하드 코딩된 데이터를 사용하는 대신, 웹 사이트를 새 API 백엔드에 통합해야 합니다. 여러 API 호출에 동일한 NLB URL을 사용하려면 /module-2/web/index.html 파일을 업데이트해야 합니다(/mysfits 경로는 포함하지 않음).

    Cloud9에서 이 파일을 열고 아래의 따옴표 안의 선택된 영역을 NLB URL로 바꿉니다.

    before-replace

    URL을 붙여 넣으면 해당 줄이 아래와 비슷하게 됩니다.

    after-replace
    B: S3에 업로드

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

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

    새 Mythical Mysfits 웹 사이트를 표시하기 위해 모듈 1의 마지막에 사용한 것과 동일한 URL을 사용하여 웹 사이트를 엽니다. 이 웹 사이트는 AWS Fargate에 배포된 Docker 컨테이너 내에서 실행 중인 Flask API에서 JSON 데이터를 검색합니다.

모듈 2C: AWS Code Services를 사용하여 배포 자동화

이제 서비스가 실행 중이므로 Flask 서비스의 코드를 변경해볼 차례입니다. 서비스에 새 기능을 배포할 때마다 위의 단계를 모두 반복해야 한다면 배포 속도를 저해하는 병목 지점이 될 것입니다. 이 문제를 해결하는 데 지속적 통합과 지속적 전달, 즉 CI/CD가 사용됩니다.

이 모듈에서는 이전 모듈에서 생성한 코드 기반에 대한 모든 코드 변경 사항을 서비스에 자동으로 전달하는 완전관리형 CI/CD 스택을 생성합니다.

아키텍처 다이어그램

동적 웹 사이트 아키텍처 구축 - Cloud9, 코드 도구, Fargate
  • A: 파이프라인 아티팩트용 S3 버킷 생성

    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
    B: CodeCommit 리포지토리 생성

    코드를 푸시하고 저장할 위치가 필요합니다. CLI를 사용하여 이 용도로 사용할 **AWS CodeCommit 리포지토리**를 생성합니다.

    aws codecommit create-repository --repository-name MythicalMysfitsService-Repository
    C: CodeBuild 프로젝트 생성

    코드를 저장할 리포지토리와 CI/CD 아티팩트에 사용할 S3 버킷이 준비되었으므로, 이제 CI/CD 스택에 서비스 구축 작업을 수행할 방법을 추가해보겠습니다. 이 작업은 AWS CodeBuild 프로젝트를 생성하여 수행합니다. 구축 실행이 트리거될 때마다 AWS CodeBuild가 구축 서버를 구성에 자동으로 프로비저닝하며, Docker 이미지를 구축하고 Docker 이미지의 새 버전을 새로 생성한 ECR 리포지토리로 푸시하는 데 필요한 단계를 실행합니다(그런 다음 구축이 완료되면 서버를 스핀다운함).

    Python 코드를 패키징하고 Docker 컨테이너를 구축/푸시하는 구축 단계는 ~/environment/aws-modern-application-workshop/module-2/app/buildspec.yml 파일에 포함되어 있습니다. buildspec.yml 파일은 CodeBuild 프로젝트 내에서 구축 실행에 필요한 단계를 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
    D: CodePipeline 파이프라인 생성

    마지막으로, CodeCommit 리포지토리를 CodeBuild 프로젝트에 지속적으로 통합할 방법이 필요하므로 코드 변경 사항이 리포지토리로 푸시될 때마다 구축 작업이 자동으로 실행됩니다. 다음으로, 새로 구축된 아티팩트를 ECS의 서비스에 지속적으로 전달할 방법이 필요합니다. AWS CodePipeline은 이들 작업을 다음 단계에서 생성할 파이프라인으로 결합합니다.

    CodePipeline의 파이프라인은 방금 위에서 설명한 역할을 합니다. 코드 변경 사항이 CodeCommit 리포지토리로 푸시될 때마다 CodePipeline은 최신 코드를 AWS CodeBuild 프로젝트에 전달하므로 구축 작업이 실행됩니다. CodeBuild에 의해 성공적으로 구축될 경우 CodePipeline은 CodeBuild 실행을 통해 ECR로 푸시된 최신 컨테이너 이미지를 사용하여 ECS에 대한 배포 작업을 수행합니다.

    이러한 모든 단계는 제공된 JSON 파일에 정의되어 있습니다. 이 파일은 파이프라인을 생성할 때 AWS CLI에 대한 입력으로 사용됩니다. ~/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
    E: ECR 이미지 리포지토리에 대한 자동 액세스 활성화

    이제 마지막 단계만 수행하면 CI/CD 파이프라인을 엔드 투 엔드로 성공적으로 실행할 수 있습니다. CI/CD 파이프라인이 준비되었으므로 더 이상 컨테이너 이미지를 ECR에 수동으로 푸시할 필요가 없습니다. 이제 CodeBuild가 새 이미지를 푸시합니다.

    ECR 리포지토리 정책*을 사용하여 CodeBuild에 이미지 리포지토리 작업을 수행할 권한을 부여해야 합니다. MythicalMysfitsCoreStack에 의해 생성된 CodeBuild 역할에 해당하는 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 파이프라인이 만들어집니다.

  • A: AWS CodeCommit에 Git 사용

    새 파이프라인을 테스트하려면 Cloud9 IDE 내에 git를 구성하고 CodeCommit 리포지토리와 통합해야 합니다.

    AWS CodeCommit은 통합을 간소화하기 위해 사용할 git용 자격 증명 헬퍼를 제공합니다.

    터미널에서 다음 명령을 순서대로 실행하여 AWS CodeCommit에 사용하도록 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의 디렉터리를 환경 디렉터리로 변경합니다.

    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/
    B: 코드 변경 사항 푸시

    모듈 2에서 Fargate 서비스를 생성하는 데 사용한 완료된 서비스 코드가 AWS CodeCommit에서 방금 복제한 로컬 리포지토리에 저장되었습니다. Flask 서비스를 변경한 후 변경 사항을 커밋하여 새로 생성한 CI/CD 파이프라인이 정상적으로 작동하는지 살펴보겠습니다. Cloud9에서 ~/environment/MythicalMysfitsService-Repository/service/mysfits-response.json에 저장된 파일을 열고 mysfit 중 하나의 나이를 다른 값으로 변경한 후 파일을 저장합니다.

    파일을 저장한 후 디렉터리를 새 리포지토리 디렉터리로 변경합니다.

    cd ~/environment/MythicalMysfitsService-Repository/

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

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

    변경 사항이 리포지토리로 푸시되고 나면 AWS 콘솔에서 CodePipeline 서비스를 열어 CI/CD 파이프라인을 진행하는 동안 변경 내용을 확인할 수 있습니다. 코드 변경 사항을 커밋한 후 변경 사항이 Fargate에서 실행 중인 라이브 서비스로 배포되는 데 5~10분 정도 걸립니다.

    이 시간 동안 AWS CodePipeline은 변경 내용이 CodeCommit 리포지토리에 체크인될 때 파이프라인 실행을 트리거하는 동작을 오케스트레이션하고, CodeBuild 프로젝트를 트리거하여 새 구축 작업을 시작하고, CodeBuild가 ECR로 푸시한 Docker 이미지를 검색하며, 자동화된 ECS 업데이트 서비스 작업을 수행하여 서비스에서 실행 중인 기존 컨테이너를 Connection Draining하고 새로 구축된 이미지로 바꿉니다. 브라우저에서 Mythical Mysfits 웹 사이트를 새로 고쳐 변경 사항이 적용되는지 확인합니다.

    다음에서 CodePipeline 콘솔을 통해 코드 변경 작업의 진행 단계를 확인할 수 있습니다. 작업을 수행할 필요는 없으며 자동화된 작업 과정을 살펴보기만 하면 됩니다. AWS CodePipeline

    이것으로 모듈 2를 마치겠습니다.

다음으로, mysfit 데이터를 저장합니다.