AWS CodeDeploy FAQ

애플리케이션은 인스턴스 그룹에 배포할 소프트웨어와 구성의 모음입니다. 대개 그룹 내 인스턴스는 동일한 소프트웨어를 실행합니다. 예를 들어, 대규모 분산 시스템이 있는 경우 일반적으로 웹 계층이 하나의 애플리케이션을 구성하고 데이터 계층이 다른 애플리케이션을 구성하게 됩니다.

수정 버전이란 AppSpec 파일과 함께 배포할 수 있는 콘텐츠(예: 소스 코드, 빌드 후 아티팩트, 웹 페이지, 실행 파일, 배포 스크립트)의 특정 버전입니다. AWS CodeDeploy Agent는 GitHub 또는 Amazon S3 버킷에서 수정 버전에 액세스합니다.

배포 그룹이란 EC2 인스턴스 또는 AWS Lambda 함수를 CodeDeploy 배포에 그룹화하기 위한 AWS CodeDeploy 엔터티입니다. EC2 배포의 경우에는 배포 대상인 애플리케이션과 관련된 인스턴스의 집합이기도 합니다. 태그, Auto Scaling 그룹 이름 또는 둘 다 지정하여 인스턴스를 배포 그룹에 추가할 수 있습니다. AWS Lambda 배포에서 배포 그룹은 경보 및 롤백과 같은 향후 서버리스 Lambda 배포의 AWS CodeDeploy 구성 세트를 정의합니다.

애플리케이션에 스테이징, 프로덕션 등 여러 배포 그룹을 정의할 수 있습니다. 태그에 대한 자세한 내용은 콘솔에서 Amazon EC2 태그 사용 섹션을 참조하세요. Auto Scaling 그룹에 배포하는 방법에 대한 자세한 내용은 Auto Scaling 통합 섹션을 참조하세요.

배포 구성은 배포 장애 처리 방법을 비롯하여 배포 그룹을 통해 배포가 진행되는 방식을 지정합니다. 배포 구성을 사용하여 여러 인스턴스 배포 그룹에 다운타임 없이 배포를 수행할 수 있습니다. 예를 들어, 애플리케이션에서 배포 그룹에 있는 50% 이상의 인스턴스가 가동되어 트래픽을 처리하도록 요구하는 경우 배포 구성에 이를 지정하여 배포로 인해 다운타임이 발생하는 것을 방지할 수 있습니다. 배포나 배포 그룹에 연결된 배포 구성이 없는 경우 AWS CodeDeploy는 기본적으로 한 번에 하나의 인스턴스에 배포합니다.  배포 구성에 대한 자세한 내용은 인스턴스 상태 섹션을 참조하세요.

배포에 지정하는 파라미터는 다음 세 가지가 있습니다.

1. 수정 버전 – 배포할 것을 지정합니다.
2. 배포 그룹 – 배포할 위치를 지정합니다.
3. 배포 구성 – 배포할 방법을 지정하는 선택적 파라미터입니다.

AppSpec 파일은 복사할 파일과 실행할 스크립트를 지정하는 구성 파일입니다. AppSpec 파일의 형식은 YAML이고 저장 위치는 수정 버전의 루트 디렉터리입니다. AppSpec 파일은 AWS CodeDeploy Agent가 사용하며 두 섹션으로 구성됩니다. 파일 섹션에서는 복사할 수정 버전의 소스 파일과 각 인스턴스의 대상 폴더를 지정합니다. 후크 섹션은 각 배포 단계 동안 실행할 스크립트의 위치(수정 버전 번들의 루트에서 시작하여 상대 경로로)를 지정합니다. 각 배포 단계를 배포 수명 주기 이벤트라고 합니다. 다음은 샘플 AppSpec 파일입니다. 지정할 수 있는 모든 옵션을 비롯하여 AppSpec 파일에 대한 자세한 내용은 AppSpec File 참조 섹션을 참조하세요.

os: linux

files: 

# You can specify one or more mappings in the files section.

  - source: /

    destination: /var/www/html/WordPress

hooks:

 # The lifecycle hooks sections allows you to specify deployment scripts.

ApplicationStop: 

# Step 1: Stop Apache and MySQL if running.

    - location: helper_scripts/stop_server.sh

BeforeInstall: 

# Step 2: Install Apache and MySQL.

# You can specify one or more scripts per deployment lifecycle event.

    - location: deploy_hooks/puppet-apply-apache.sh

    - location: deploy_hooks/puppet-apply-mysql.sh 

 AfterInstall: 

# Step 3: Set permissions.

    - location: deploy_hooks /change_permissions.sh

      timeout: 30

      runas: root

# Step 4: Start the server.

    - location: helper_scripts/start_server.sh

      timeout: 30

      runas: root

배포는 배포 수명 주기 이벤트라는 사전 설정된 일련의 단계를 거칩니다. 배포 수명 주기 이벤트를 사용하면 배포의 일부로 코드를 실행할 수 있습니다. 다음 표는 같이 사용할 수 있는 시기 관련 예제와 함께 현재 지원되는 다른 배포 수명 주기 이벤트를 실행 순서대로 표시합니다.

배포 수명 주기 이벤트:

• ApplicationStop

  • 수정 버전이 다운로드되기 전에 일어나는 첫 번째 배포 수명 주기 이벤트입니다. 이 배포 수명 주기 이벤트에 사용되는 AppSpec 파일과 스크립트는 마지막에 성공적으로 배포한 수정 버전에서 가져옵니다.  

    배포를 준비할 때 애플리케이션을 점진적으로 중지하거나 현재 설치된 패키지를 제거하려는 경우 ApplicationStop 배포 수명 주기 이벤트를 사용할 수 있습니다.

• DownloadBundle

  • 이 배포 수명 주기 이벤트 동안 에이전트는 수정 버전 파일을 인스턴스의 임시 위치로 복사합니다. 이 배포 수명 주기 이벤트는 에이전트에 예약되어 있으며 사용자 스크립트 실행에 사용할 수 없습니다.

• BeforeInstall

  • 파일 암호 해독과 현재 버전의 백업 생성 등 설치 전 작업에 BeforeInstall 배포 수명 주기 이벤트를 사용할 수 있습니다.

• 설치

  • 이 배포 수명 주기 이벤트 동안 에이전트는 수정 버전 파일을 임시 위치에서 최종 대상 폴더로 복사합니다. 이 배포 수명 주기 이벤트는 에이전트에 예약되어 있으며 사용자 스크립트 실행에 사용할 수 없습니다.

• AfterInstall

  • 애플리케이션 구성이나 파일 권한 변경 등의 작업에 AfterInstall 배포 수명 주기 이벤트를 사용할 수 있습니다.

• ApplicationStart

  • ApplicationStart 배포 수명 주기 이벤트는 대개 ApplicationStop 이벤트 동안 중지된 서비스를 다시 시작하는 데 사용합니다.

• ValidateService

  • ValidateService는 마지막 수명 주기 이벤트로서 배포가 성공적으로 완료되었는지 확인할 수 있습니다.

 

 

AWS Management Console에 로그인하고 AWS CodeDeploy를 사용하여 시작할 수 있습니다. 서비스에 대한 간단한 개요를 보려면 단계별 자습서가 포함된 시작하기를 참조하세요.

Amazon EC2 인스턴스가 IAM 인스턴스 프로파일과 연결되어 있어야 하고 지원되는 운영 체제를 실행해야 합니다. 자세한 내용은 기존 Amazon EC2 인스턴스 사용 섹션을 참조하십시오.

다음 다이어그램은 배포하는 동안 수행하는 일반적인 단계를 보여줍니다. 애플리케이션 생성 및 배포 그룹(용어에 대한 설명은 개념 섹션 참조)은 대개 애플리케이션당 한 번 수행하는 설정 작업입니다. 반복되는 작업은 수정 버전 업로드와 배포입니다. 각 작업에 대한 단계별 안내를 비롯하여 자세한 설명은 배포를 참조하세요.

AWS Management Console, AWS Command Line Interface(AWS CLI), AWS SDK 및 AWS CodeDeploy API를 사용하여 AWS CodeDeploy에 액세스할 수 있습니다.

코드를 변경할 필요가 없습니다. 복사할 파일과 실행할 스크립트를 지정하는 구성 파일(AppSpec이라는 파일)을 수정 버전 번들의 루트 디렉터리에 추가하면 됩니다.

GitHub를 사용 중이라면 리포지토리에서 직접 .zip, .tar 또는 .tar.gz 형식의 수정 버전을 인스턴스에 배포할 수 있습니다. 다른 소스 제어 시스템의 경우 수정 버전을 번들로 묶어 Amazon S3 버킷에 .zip, .tar 또는 .tar.gz 형식으로 업로드하고 배포할 때 Amazon S3 위치를 지정할 수 있습니다. 애플리케이션에 빌드 단계가 필요한 경우 GitHub 리포지토리나 Amazon S3 버킷에 빌드 후 아티팩트가 포함되어 있어야 합니다. GitHub에서 AWS CodeDeploy 사용에 대한 자세한 내용은 제품 통합 페이지를 참조하세요. 수정 버전 저장에 Amazon S3 사용에 대한 자세한 내용은 수정 버전 푸시를 참조하십시오.

AppSpec 파일의 모든 배포 수명 주기 이벤트 후크에서 구성 관리 도구를 호출할 수 있습니다. 예를 들어, 배포의 일부로 실행하려는 Chef 레시피가 있다면 AppSpec 파일에 있는 적절한 배포 수명 주기 이벤트 후크에 이를 지정하여 실행할 수 있습니다. 또한 구성 관리 시스템을 활용하여 인스턴스에 AWS CodeDeploy 에이전트를 설치할 수 있습니다. Chef, Puppet, Ansible 및 Saltstack 등 구성 관리 시스템과 함께 AWS CodeDeploy를 사용하는 법을 보여주는 샘플은 제품 통합 페이지를 참조하세요.

예. AWS CLI 또는 AWS SDK를 사용하여 퍼블릭 API 호출을 통해 AWS CodeDeploy를 지속적인 통합 및 배포와 통합할 수 있습니다. 사전 구축된 통합 및 샘플은 제품 통합 페이지에서 참조할 수 있습니다.

애플리케이션을 가져오려면 새로 추가된 인스턴스의 배포 그룹에 최신 수정 버전을 배포합니다. Auto Scaling 그룹의 일부로 실행된 인스턴스를 제외하면 AWS CodeDeploy는 새로 추가된 Amazon EC2 인스턴스에 최신 수정 버전을 자동으로 배포하지 않습니다.

Auto Scaling 그룹을 배포 그룹과 연결하면 새로 실행된 인스턴스가 항상 애플리케이션의 최신 버전을 가져오도록 할 수 있습니다. Auto Scaling 그룹에 새 Amazon EC2 인스턴스가 시작되면 먼저 Amazon EC2 인스턴스의 상태가 'Pending'으로 전환됩니다. 그런 다음, 해당 배포 그룹에 최근 성공적으로 배포된 수정 버전이 새 Amazon EC2 인스턴스에 배포되도록 트리거됩니다. 배포가 완료되면 Amazon EC2 인스턴스의 상태가 'InService'로 변경됩니다. 배포에 실패하면 Amazon EC2 인스턴스가 종료되고 새로운 Amazon EC2 인스턴스가 'Pending' 상태로 시작되며 새로 시작된 EC2 인스턴스에 배포가 트리거됩니다. Auto Scaling 그룹 인스턴스 수명 주기 이벤트에 대한 자세한 내용은 Auto Scaling 그룹 수명 주기를 참조하세요.

AWS Management Console, AWS Command Line Interface(AWS CLI), AWS SDK 및 AWS CodeDeploy API를 사용하여 배포 상태에 액세스할 수 있습니다. 배포의 전체 상태를 확인하고 더 드릴다운하여 각 인스턴스의 상태와 인스턴스에 대한 각 배포 수명 주기 이벤트의 상태를 확인할 수 있습니다. 또한 실패에 해당하는 로그 항목을 보고 인스턴스에 로그인하지 않고도 손쉽게 배포 문제를 디버깅할 수 있습니다.

예. 진행 중인 배포를 중지하면 AWS CodeDeploy 서비스에서 각 인스턴스의 에이전트에 더 이상 스크립트 실행하지 않도록 알립니다. 애플리케이션을 다시 일관된 상태로 되돌리려면 수정 버전을 다시 배포하거나 다른 수정 버전을 배포할 수 있습니다.

애플리케이션을 이전 버전으로 롤백하려면 해당 수정 버전을 다시 배포하면 됩니다. AWS CodeDeploy는 현재 수정 버전으로 복사된 파일을 추적하고 새 배포를 시작하기 전에 이러한 파일을 제거하므로 재배포와 롤백 간에는 차이점이 없습니다. 하지만 이전 수정 버전을 롤백에 사용할 수 있는지 확인해야 합니다.

예. 버전 관리되는 Amazon S3 버킷을 사용하고 버전 ID를 지정하면 수정 버전을 고유하게 식별할 수 있습니다.

서비스 제한에 대한 자세한 내용은 제한 페이지를 참조하세요. 서비스 한도를 늘리려면 AWS Support Center를 통해 요청을 제출하세요.

예. 계정에서 이루어진 AWS CodeDeploy API 호출 기록을 수신하려면 AWS Management Console에서 AWS CloudTrail을 설정하면 됩니다.

배포에 영향을 주는 이벤트에 대한 알림을 생성할 수 있습니다. 알림은 Amazon SNS 알림 형식으로 수신됩니다. 각 알림에는 상태 메시지와 함께, 해당 알림이 생성되도록 한 이벤트가 발생한 리소스의 링크가 포함됩니다. 알림에는 추가 비용이 부과되지 않지만 Amazon SNS 등 알림에서 사용하는 다른 AWS 서비스에는 비용이 부과될 수 있습니다. 알림 사용을 시작하는 방법은 알림 사용 설명서를 참조하십시오. 또한 AWS Chatbot을 사용하는 고객은 Slack 채널 또는 Amazon Chime 채팅방으로 알림이 전송되도록 구성할 수 있습니다. 자세한 내용은 여기를 참조하세요.

예. 하지만 Amazon EC2에 설치된 AWS CodeDeploy 에이전트가 퍼블릭 AWS CodeDeploy와 Amazon S3 서비스 엔드포인트에 액세스할 수 있어야 합니다. 자세한 내용은 AWS CodeDeploy 엔드포인트 및 Amazon S3 엔드포인트를 참조하세요.

예. AWS CodeDeploy는 리소스 수준 권한을 지원합니다. 각 AWS CodeDeploy 리소스에 대해 액세스할 수 있는 사용자와 수행할 수 있는 작업을 지정할 수 있습니다. 예를 들어, IAM 정책을 설정하여 사용자가 특정 애플리케이션을 배포할 수 있지만 다른 애플리케이션에 대해서는 수정 버전만 표시하도록 설정할 수 있습니다. 이를 통해 사용자가 다른 애플리케이션을 실수로 변경하는 것을 방지할 수 있습니다. AWS CodeDeploy와 IAM 사용에 대한 자세한 내용은 액세스 권한 참조를 참조하세요.

CodeDeploy의 리전별 가용성에 대한 자세한 정보는 리전별 제품 및 서비스를 참조하세요.

AWS CodeDeploy는 같은 리전 내에 있는 AWS 리소스에 배포를 수행합니다. 애플리케이션을 여러 리전에 배포하려면 대상 리전에서 애플리케이션을 정의하고 각 리전의 Amazon S3 버킷에 애플리케이션 번들을 복사한 다음 리전 전체에 직렬 배포나 병렬 배포 중 하나를 사용해 배포를 시작합니다.

AWS CodeDeploy를 통해 Amazon EC2 인스턴스에 코드를 배포하는 데는 추가 비용이 부과되지 않습니다. AWS CodeDeploy를 사용해 온프레미스 인스턴스를 업데이트하는 경우에는 업데이트당 0.02 USD의 요금이 부과됩니다. 자세한 내용은 요금 페이지를 참조하세요.