기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AppSpec 파일 구조 다음은 AWS Lambda 및 EC2/온프레미스 컴퓨팅 플랫폼으로의 배포에 사용되는 을 간단히 나타낸 것입니다. 문자열인 YAML 형식 AppSpec 파일의 값은 다른 방식으로 지정되지 않는 한 따옴표("")로 둘러싸면 안 됩니다. ## Amazon ECS 배포의 AppSpec 파일 구조 **참고** 이 AppSpec 파일은 YAML로 작성되지만, 동일한 구조를 사용하여 JSON으로 작성할 수 있습니다. JSON 형식 AppSpec 파일의 문자열은 항상 따옴표("")로 둘러싸야 합니다. ``` version: 0.0 resources: ecs-service-specifications hooks: deployment-lifecycle-event-mappings ``` 이 구조에서: ** **version** ** 이 섹션에서는 AppSpec 파일의 버전을 지정합니다. 이 값은 변경하지 마세요. 필수 항목입니다. 현재, 유일하게 허용되는 값은 **0.0**입니다. 이 값은 이후에 사용하기 위해 CodeDeploy에서 예약한 값입니다. 문자열로 **version**을 지정합니다. ** **resources** ** 이 섹션은 배포할 Amazon ECS 애플리케이션에 대한 정보를 지정합니다. 자세한 내용은 [Amazon ECS 배포를 위한 AppSpec 'resources' 섹션](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs) 단원을 참조하십시오. ** **hooks** ** 이 섹션은 배포를 확인하기 위해 특정 배포 수명 주기 이벤트 후크에서 실행할 Lambda 함수를 지정합니다. 자세한 내용은 [Amazon ECS 배포를 위한 수명 주기 이벤트 후크 목록](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs) 단원을 참조하십시오. ## AWS Lambda 배포를 위한 AppSpec 파일 구조 **참고** 이 AppSpec 파일은 YAML로 작성되지만, 동일한 구조를 사용하여 JSON으로 Lambda 배포용 AppSpec 파일을 작성할 수 있습니다. JSON 형식 AppSpec 파일의 문자열은 항상 따옴표("")로 둘러싸야 합니다. ``` version: 0.0 resources: lambda-function-specifications hooks: deployment-lifecycle-event-mappings ``` 이 구조에서: ** **version** ** 이 섹션에서는 AppSpec 파일의 버전을 지정합니다. 이 값은 변경하지 마세요. 필수 항목입니다. 현재, 유일하게 허용되는 값은 **0.0**입니다. 이 값은 이후에 사용하기 위해 CodeDeploy에서 예약한 값입니다. 문자열로 **version**을 지정합니다. ** **resources** ** 이 섹션은 배포할 Lambda 함수에 대한 정보를 지정합니다. 자세한 내용은 [AppSpec '리소스' 섹션(Amazon ECS 및 AWS Lambda 배포만 해당)](reference-appspec-file-structure-resources.md) 단원을 참조하십시오. ** **hooks** ** 이 섹션은 배포를 확인하기 위해 특정 배포 수명 주기 이벤트에서 실행할 Lambda 함수를 지정합니다. 자세한 내용은 [AppSpec 'hooks' 섹션](reference-appspec-file-structure-hooks.md) 단원을 참조하십시오. ## EC2 온프레미스 배포용 AppSpec 파일 구조 ``` version: 0.0 os: operating-system-name files: source-destination-files-mappings permissions: permissions-specifications hooks: deployment-lifecycle-event-mappings ``` 이 구조에서: ** **version** ** 이 섹션에서는 AppSpec 파일의 버전을 지정합니다. 이 값은 변경하지 마세요. 필수 항목입니다. 현재, 유일하게 허용되는 값은 **0.0**입니다. 이 값은 이후에 사용하기 위해 CodeDeploy에서 예약한 값입니다. 문자열로 **version**을 지정합니다. ** **os** ** 이 섹션은 배포할 인스턴스의 운영 체제 값을 지정합니다. 필수 항목입니다. 다음 값을 지정할 수 있습니다. + **Linux** – Amazon Linux, Ubuntu Server 또는 RHEL 인스턴스입니다. + **Windows** – Windows Server 인스턴스입니다. 문자열로 **os**를 지정합니다. ** **files** ** 이 섹션에서는 배포의 **설치** 이벤트 중 인스턴스에 복사해야 하는 파일의 이름을 지정합니다. 자세한 내용은 [AppSpec 'files' 섹션(EC2/온프레미스 배포만 해당)](reference-appspec-file-structure-files.md) 단원을 참조하십시오. ** **권한** ** 이 섹션은 `files` 섹션의 파일이 인스턴스에 복사되는 경우 이러한 파일에 특수 권한(있는 경우)이 어떻게 적용되어야 하는지를 지정합니다. 이 섹션은 Amazon Linux, Ubuntu Server 및 Red Hat Enterprise Linux(RHEL) 인스턴스에만 적용됩니다. 자세한 내용은 [AppSpec 'permissions' 섹션(EC2/온프레미스 배포만 해당)](reference-appspec-file-structure-permissions.md) 단원을 참조하세요. ** **hooks** ** 이 섹션은 배포 중 특정 배포 수명 주기 이벤트에서 실행되는 스크립트를 지정합니다. 자세한 내용은 [AppSpec 'hooks' 섹션](reference-appspec-file-structure-hooks.md) 단원을 참조하십시오. **Topics** + [Amazon ECS 배포의 AppSpec 파일 구조](#ecs-appspec-structure) + [AWS Lambda 배포를 위한 AppSpec 파일 구조](#lambda-appspec-structure) + [EC2 온프레미스 배포용 AppSpec 파일 구조](#server-appspec-structure) + [AppSpec 'files' 섹션(EC2/온프레미스 배포만 해당)](reference-appspec-file-structure-files.md) + [AppSpec '리소스' 섹션(Amazon ECS 및 AWS Lambda 배포만 해당)](reference-appspec-file-structure-resources.md) + [AppSpec 'permissions' 섹션(EC2/온프레미스 배포만 해당)](reference-appspec-file-structure-permissions.md) + [AppSpec 'hooks' 섹션](reference-appspec-file-structure-hooks.md) # AppSpec 'files' 섹션(EC2/온프레미스 배포만 해당) 배포의 **설치**이벤트 동안 인스턴스에 설치해야 하는 애플리케이션 수정 버전의 파일에 대한 정보를 CodeDeploy에 제공합니다. 이 섹션은 배포 중 수정의 파일을 인스턴스의 위치로 복사하는 경우에만 필요합니다. 이 섹션의 구조는 다음과 같습니다. ``` files: - source: source-file-location-1 destination: destination-file-location-1 file_exists_behavior: DISALLOW|OVERWRITE|RETAIN ``` 여러 개의 `source` 및 `destination` 페어를 설정할 수 있습니다. `source` 명령은 인스턴스에 복사할 수정의 파일 또는 디렉터리를 식별합니다. + `source`가 파일을 나타내는 경우 지정한 파일만 인스턴스에 복사됩니다. + `source`가 디렉터리를 나타내는 경우 디렉터리 내의 모든 파일이 인스턴스에 복사됩니다. + `source`이(가) 슬래시 하나인 경우(Amazon Linux, RHEL 및 Ubuntu Server 인스턴스의 경우: "/", Windows Server 인스턴스의 경우: "\$1") 수정 버전의 모든 파일이 인스턴스에 복사됩니다. `source`에 사용된 경로는 `appspec.yml` 파일에 상대적이며 수정 버전의 루트에 있어야 합니다. 수정 버전의 파일 구조에 대한 자세한 내용은 [CodeDeploy의 개정 계획](application-revisions-plan.md) 단원을 참조하세요. `destination` 명령은 인스턴스에서 파일이 복사되어야 하는 위치를 식별합니다. `/root/destination/directory`(Linux, RHEL, Ubuntu) 또는 `c:\destination\folder`(Windows)와 같은 정규화된 경로여야 합니다. `source` 및 `destination`은 각각 문자열을 사용하여 지정됩니다. `file_exists_behavior` 지침은 선택 사항이며, CodeDeploy가 배포 대상 위치에 이미 존재하지만 이전에 성공한 배포의 일부가 아닌 파일을 처리하는 방식을 지정합니다. 이 설정은 다음 값 중 하나일 수 있습니다. + DISALLOW: 배포가 실패합니다. 이는 옵션을 지정하지 않은 경우의 기본 동작입니다. + OVERWRITE: 현재 배포 중인 애플리케이션 수정 버전의 파일 버전이 인스턴스에 이미 있는 버전을 대체합니다. + RETATE: 인스턴스에 이미 있는 파일의 버전이 유지되고 새 배포의 일부로 사용됩니다. `file_exists_behavior` 설정을 사용하는 경우 다음 설정을 이해합니다. + 한 번만 지정할 수 있으며 `files:` 아래에 나열된 모든 파일 및 디렉터리에 적용됩니다. + 는 `--file-exists-behavior` AWS CLI 옵션 및 `fileExistsBehavior` API 옵션보다 우선합니다(둘 다 선택 사항임). 다음은 Amazon Linux, Ubuntu Server 또는 RHEL 인스턴스에 대한 `files` 섹션의 예입니다. ``` files: - source: Config/config.txt destination: /webapps/Config - source: source destination: /webapps/myApp ``` 이 예에서는 **설치** 이벤트 중 다음 두 가지 작업이 수행됩니다. 1. 수정의 `Config/config.txt` 파일을 인스턴스의 `/webapps/Config/config.txt` 경로에 복사합니다. 1. 수정의 `source` 디렉터리에 있는 파일을 인스턴스의 `/webapps/myApp` 디렉터리로 모두 복사합니다. ## 'Files' 섹션의 예 다음 예제에서는 `files` 섹션을 지정하는 방법을 보여줍니다. 이러한 예에서는 Windows Server 파일 및 디렉터리(폴더) 구조를 설명하고 있지만 이러한 구조는Amazon Linux, Ubuntu Server 및 RHEL 인스턴스에 대해 쉽게 조정할 수 있습니다. **참고** EC2/온프레미스 배포만 `files` 섹션을 사용합니다. AWS Lambda 배포에는 적용되지 않습니다. 다음 예에서는 이러한 파일이 `source`의 루트에 번들로 나타난다고 가정합니다. + `appspec.yml` + `my-file.txt` + `my-file-2.txt` + `my-file-3.txt` ``` # 1) Copy only my-file.txt to the destination folder c:\temp. # files: - source: .\my-file.txt destination: c:\temp # # Result: # c:\temp\my-file.txt # # --------------------- # # 2) Copy only my-file-2.txt and my-file-3.txt to the destination folder c:\temp. # files: - source: my-file-2.txt destination: c:\temp - source: my-file-3.txt destination: c:\temp # # Result: # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt # # --------------------- # # 3) Copy my-file.txt, my-file-2.txt, and my-file-3.txt (along with the appspec.yml file) to the destination folder c:\temp. # files: - source: \ destination: c:\temp # # Result: # c:\temp\appspec.yml # c:\temp\my-file.txt # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt ``` 다음 예에서는 `appspec.yml`이 `source`의 루트에 번들로 나타나고, 여기에는 파일 3개가 포함된 `my-folder` 폴더가 함께 있습니다. + `appspec.yml` + `my-folder\my-file.txt` + `my-folder\my-file-2.txt` + `my-folder\my-file-3.txt` ``` # 4) Copy the 3 files in my-folder (but do not copy my-folder itself) to the destination folder c:\temp. # files: - source: .\my-folder destination: c:\temp # # Result: # c:\temp\my-file.txt # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt # # --------------------- # # 5) Copy my-folder and its 3 files to my-folder within the destination folder c:\temp. # files: - source: .\my-folder destination: c:\temp\my-folder # # Result: # c:\temp\my-folder\my-file.txt # c:\temp\my-folder\my-file-2.txt # c:\temp\my-folder\my-file-3.txt # # --------------------- # # 6) Copy the 3 files in my-folder to other-folder within the destination folder c:\temp. # files: - source: .\my-folder destination: c:\temp\other-folder # # Result: # c:\temp\other-folder\my-file.txt # c:\temp\other-folder\my-file-2.txt # c:\temp\other-folder\my-file-3.txt # # --------------------- # # 7) Copy only my-file-2.txt and my-file-3.txt to my-folder within the destination folder c:\temp. # files: - source: .\my-folder\my-file-2.txt destination: c:\temp\my-folder - source: .\my-folder\my-file-3.txt destination: c:\temp\my-folder # # Result: # c:\temp\my-folder\my-file-2.txt # c:\temp\my-folder\my-file-3.txt # # --------------------- # # 8) Copy only my-file-2.txt and my-file-3.txt to other-folder within the destination folder c:\temp. # files: - source: .\my-folder\my-file-2.txt destination: c:\temp\other-folder - source: .\my-folder\my-file-3.txt destination: c:\temp\other-folder # # Result: # c:\temp\other-folder\my-file-2.txt # c:\temp\other-folder\my-file-3.txt # # --------------------- # # 9) Copy my-folder and its 3 files (along with the appspec.yml file) to the destination folder c:\temp. If any of the files already exist on the instance, overwrite them. # files: - source: \ destination: c:\temp file_exists_behavior: OVERWRITE # # Result: # c:\temp\appspec.yml # c:\temp\my-folder\my-file.txt # c:\temp\my-folder\my-file-2.txt # c:\temp\my-folder\my-file-3.txt ``` # AppSpec '리소스' 섹션(Amazon ECS 및 AWS Lambda 배포만 해당) AppSpec 파일의 `'resources'` 섹션 내용은 해당 배포의 컴퓨팅 플랫폼에 따라 다릅니다. Amazon ECS 배포의 `'resources'` 섹션에는 Amazon ECS 작업 정의, 업데이트된 Amazon ECS 작업 세트로 트래픽을 라우팅하기 위한 포트 및 컨테이너, 기타 선택적 정보가 포함되어 있습니다. AWS Lambda 배포 `'resources'` 섹션에는 Lambda 함수의 이름, 별칭, 현재 버전 및 대상 버전이 포함되어 있습니다. **Topics** + [AWS Lambda 배포를 위한 AppSpec 'resources' 섹션](#reference-appspec-file-structure-resources-lambda) + [Amazon ECS 배포를 위한 AppSpec 'resources' 섹션](#reference-appspec-file-structure-resources-ecs) ## AWS Lambda 배포를 위한 AppSpec 'resources' 섹션 `'resources'` 섹션은 배포할 Lambda 함수를 지정하며 다음과 같은 구조를 갖습니다. YAML: ``` resources: - name-of-function-to-deploy: type: "AWS::Lambda::Function" properties: name: name-of-lambda-function-to-deploy alias: alias-of-lambda-function-to-deploy currentversion: version-of-the-lambda-function-traffic-currently-points-to targetversion: version-of-the-lambda-function-to-shift-traffic-to ``` JSON: ``` "resources": [ { "name-of-function-to-deploy" { "type": "AWS::Lambda::Function", "properties": { "name": "name-of-lambda-function-to-deploy", "alias": "alias-of-lambda-function-to-deploy", "currentversion": "version-of-the-lambda-function-traffic-currently-points-to", "targetversion": "version-of-the-lambda-function-to-shift-traffic-to" } } } ] ``` 각 속성은 문자열로 지정됩니다. + `name` - 필수. 배포할 Lambda 함수의 이름입니다. + `alias` - 필수. Lambda 함수에 대한 별칭 이름입니다. + `currentversion` - 필수. 현재 가리키는 Lambda 함수 트래픽의 버전입니다. 값은 유효한 양의 정수여야 합니다. + `targetversion` - 필수. 전환되는 Lambda 함수 트래픽의 버전입니다. 값은 유효한 양의 정수여야 합니다. ## Amazon ECS 배포를 위한 AppSpec 'resources' 섹션 `'resources'` 섹션은 배포할 Amazon ECS 서비스를 지정하며 다음과 같은 구조를 갖습니다. YAML: ``` Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: "task-definition-arn" LoadBalancerInfo: ContainerName: "ecs-container-name" ContainerPort: "ecs-application-port" # Optional properties PlatformVersion: "ecs-service-platform-version" NetworkConfiguration: AwsvpcConfiguration: Subnets: ["ecs-subnet-1","ecs-subnet-n"] SecurityGroups: ["ecs-security-group-1","ecs-security-group-n"] AssignPublicIp: "ENABLED | DISABLED" CapacityProviderStrategy: - Base: integer CapacityProvider: "capacityProviderA" Weight: integer - Base: integer CapacityProvider: "capacityProviderB" Weight: integer ``` JSON: ``` "Resources": [ { "TargetService": { "Type": "AWS::ECS::Service", "Properties": { "TaskDefinition": "task-definition-arn", "LoadBalancerInfo": { "ContainerName": "ecs-container-name", "ContainerPort": "ecs-application-port" }, "PlatformVersion": "ecs-service-platform-version", "NetworkConfiguration": { "AwsvpcConfiguration": { "Subnets": [ "ecs-subnet-1", "ecs-subnet-n" ], "SecurityGroups": [ "ecs-security-group-1", "ecs-security-group-n" ], "AssignPublicIp": "ENABLED | DISABLED" } }, "CapacityProviderStrategy": [ { "Base": integer, "CapacityProvider": "capacityProviderA", "Weight": integer }, { "Base": integer, "CapacityProvider": "capacityProviderB", "Weight": integer } ] } } } ] ``` 각 속성은 숫자인 `ContainerPort`을(를) 제외하고 문자열로 지정됩니다. + `TaskDefinition` - 필수. 배포할 Amazon ECS 서비스의 작업 정의입니다. 작업 정의의 ARN으로 지정됩니다. ARN 형식은 `arn:aws:ecs:aws-region:account-id:task-definition/task-definition-family:task-definition-revision`입니다. 자세한 내용은 [Amazon 리소스 이름(ARNs) 및 AWS 서비스 네임스페이스를 참조하세요](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). **참고** ARN의 `:task-definition-revision` 부분은 선택 사항입니다. 생략할 경우 Amazon ECS는 작업 정의의 최신 ACTIVE 개정 버전을 사용합니다. + `ContainerName` - 필수. Amazon ECS 애플리케이션이 포함된 Amazon ECS 컨테이너의 이름입니다. Amazon ECS 작업 정의에 지정된 컨테이너여야 합니다. + `ContainerPort` - 필수. 트래픽이 라우팅되는 컨테이너의 포트입니다. + `PlatformVersion`: 선택 사항입니다. 배포된 Amazon ECS 서비스의 Fargate 작업의 플랫폼 버전입니다. 자세한 내용은 [AWS Fargate 플랫폼 버전](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform_versions.html)을 참조하세요. 지정하지 않으면 기본적으로 `LATEST`이(가) 사용됩니다. + `NetworkConfiguration`: 선택 사항입니다. `AwsvpcConfiguration`에서 다음을 지정할 수 있습니다. 자세한 내용은 *Amazon ECS Container Service API 참조*의 [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)을 참조하세요. + `Subnets`: 선택 사항입니다. Amazon ECS 서비스의 쉼표로 구분된 하나 이상의 서브넷 목록. + `SecurityGroups`: 선택 사항입니다. Amazon Elastic Container Service의 쉼표로 구분된 하나 이상의 보안 그룹 목록. + `AssignPublicIp`: 선택 사항입니다. Amazon ECS 서비스의 탄력적 네트워크 인터페이스가 퍼블릭 IP 주소를 수신하는지 여부를 지정하는 문자열. 유효 값은 `ENABLED` 및 `DISABLED`입니다. **참고** `NetworkConfiguration` 아래의 설정을 모두 지정하거나 아무 것도 지정하지 않아야 합니다. 예를 들어, `Subnets`를 지정하려는 경우 `SecurityGroups` 및 `AssignPublicIp`도 지정해야 합니다. 아무 것도 지정하지 않는 경우 CodeDeploy는 현재 네트워크 Amazon ECS 설정을 사용합니다. + `CapacityProviderStrategy`: 선택 사항입니다. 배포에 사용할 Amazon ECS 용량 공급자 목록입니다. 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [Amazon ECS 용량 공급자](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-capacity-providers.html)를 참조하세요. 각 용량 공급자에 대해 다음 설정을 지정할 수 있습니다. 이러한 설정에 대한 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [AWS::ECS::ServiceCapacityProviderStrategyItem](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-capacityproviderstrategyitem.html)을 참조하세요. + `Base`: 선택 사항입니다. 최소한 기준 값은 지정된 용량 공급자에서 실행할 태스크 수를 지정합니다. 용량 공급자 전략에서 하나의 용량 공급자만 기준을 정의할 수 있습니다. 값을 지정하지 않으면 기본값 0이 사용됩니다. + `CapacityProvider`: 선택 사항입니다. 용량 공급자의 짧은 이름입니다. 예: *capacityProviderA* + `Weight`: 선택 사항입니다. *가중치* 값은 지정된 용량 공급자를 사용해야 하는 시작된 총 작업 수의 상대 백분율을 지정합니다. `base` 값이 정의되어 있다면 이 값이 만족된 다음 `weight` 값을 고려합니다. `weight` 값을 지정하지 않으면 `0`의 기본값이 사용됩니다. 용량 공급자 전략 내에서 여러 용량 공급자가 지정된 경우 하나 이상의 용량 공급자가 0보다 큰 가중치 값을 가져야 하며 가중치가 `0`인 모든 용량 공급자는 태스크를 배치하는 데 사용되지 않습니다. 가중치가 모두 `0`인 전략에 여러 용량 공급자를 지정하면 용량 공급자 전략을 사용하는 모든 `RunTask` 또는 `CreateService` 작업이 실패합니다. 예를 들면 둘 다 `1`의 가중치를 갖는 경우 `base`가 충족되면 작업이 두 용량 공급자에 균등하게 분할되는 두 개의 용량 공급자를 포함하는 전략을 정의하는 가중치를 사용하는 시나리오입니다. 동일한 논리를 사용하여 *capacityProviderA*에 `1`의 가중치를 지정하고 *capacityProviderB*에 `4`의 가중치를 지정하면 *capacityProviderA*를 사용하여 실행되는 모든 태스크에 대해 네 가지 태스크에서 *capacityProviderB*를 사용합니다. # AppSpec 'permissions' 섹션(EC2/온프레미스 배포만 해당) `'permissions'` 섹션은 `'files'` 섹션의 파일 및 디렉터리/폴더가 인스턴스에 복사된 후 이러한 파일 및 디렉터리/폴더에 특수 권한(있는 경우)이 어떻게 적용되어야 하는지를 지정합니다. 여러 개의 `object` 명령을 지정할 수 있습니다. 이 섹션은 선택 사항입니다. Amazon Linux, Ubuntu Server 및 RHEL 인스턴스에만 적용됩니다. **참고** EC2/온프레미스 배포용으로만 `'permissions'` 섹션을 사용합니다. AWS Lambda 또는 Amazon ECS 배포에는 사용되지 않습니다. 이 섹션의 구조는 다음과 같습니다. ``` permissions: - object: object-specification pattern: pattern-specification except: exception-specification owner: owner-account-name group: group-name mode: mode-specification acls: - acls-specification context: user: user-specification type: type-specification range: range-specification type: - object-type ``` 명령은 다음과 같습니다. + `object` - 필수. 파일 시스템 객체가 인스턴스로 복사된 후 지정한 권한이 적용되는 파일 시스템 객체 세트(파일 또는 디렉터리/폴더)입니다. 문자열을 사용하여 `object`를 지정합니다. + `pattern` – 선택 사항. 권한을 적용할 패턴을 지정합니다. 지정하지 않거나 특수 문자 **"\$1\$1"**를 사용하여 지정하면 권한이 `type`에 따라 일치하는 모든 파일 또는 디렉터리에 적용됩니다. 따옴표("")가 있는 문자열을 사용하여 `pattern`을 지정합니다. + `except` – 선택 사항. `pattern`에 대한 예외인 파일 또는 디렉터리를 지정합니다. 대괄호 안에 있는 쉼표로 구분된 문자열 목록을 사용하여 `except`를 지정합니다. + `owner` – 선택 사항. `object`의 소유자 이름입니다. 지정하지 않으면 원본 파일 또는 디렉터리/폴더 구조에 적용된 기존의 모든 소유자가 복사 작업 후에도 아무 것도 변경되지 않습니다. 문자열을 사용하여 `owner`를 지정합니다. + `group` – 선택 사항. `object`의 그룹 이름입니다. 지정하지 않으면 원본 파일 또는 디렉터리/폴더 구조에 적용된 기존의 모든 그룹이 복사 작업 후에도 아무 것도 변경되지 않습니다. 문자열을 사용하여 `group`를 지정합니다. + `mode` – 선택 사항. `object`에 적용할 권한을 지정하는 숫자 값. 모드 설정은 Linux chmod 명령 구문을 따릅니다. **중요** 값이 0으로 시작하는 경우 큰 따옴표로 묶거나 세 자리 숫자만 남도록 선행하는 0을 제거해야 합니다. **참고** **u\$1x**와(과) 같은 기호 표기법은 `mode` 설정에 대해 지원되지 않습니다. 예시: + `mode: "0644"`은(는) 개체 소유자에게 읽기 및 쓰기 권한(6), 그룹에 읽기 전용 권한(4) 및 다른 모든 사용자에게 읽기 전용 권한(4)을 부여합니다 + `mode: 644`은(는) `mode: "0644"`와(과) 동일한 권한을 부여합니다. + `mode: 4755`은(는) setuid 특성(4)을 설정하고 소유자에게 모든 제어 권한(7)을 부여하며 그룹에 읽기 및 실행 권한(5), 다른 모든 사용자에게 읽기 및 실행 권한(5)을 부여합니다. 더 많은 예제를 보려면 Linux chmod 명령 설명서를 참조하세요. 모드를 지정하지 않으면 원본 파일 또는 폴더 구조에 적용된 기존의 모든 모드가 복사 작업 후에도 아무 것도 변경되지 않습니다. + `acls` – 선택 사항. `object`에 적용된 하나 이상의 ACL(액세스 제어 목록) 항목을 나타내는 문자열 목록. 예를 들어, **u:bob:rw**는 사용자 **bob**에 대해 읽기 및 쓰기 권한을 나타냅니다. (더 많은 예제를 보려면 Linux `setfacl` 명령 설명서에서 ACL 항목 형식의 예를 참조하세요.) ACL 항목은 여러 개 지정할 수 있습니다. `acls`를 지정하지 않으면 원본 파일 또는 디렉터리/폴더 구조에 적용된 모든 기존 ACL이 복사 작업 후에 변경되지 않고 그대로 유지됩니다. 기존 ACL을 대체합니다. 대시(-), 그 다음에 공백, 그 다음에 문자열을 사용하여 `acls`를 지정합니다(예: `- u:jane:rw`). 2개 이상의 ACL이 있는 경우 각각 별도의 줄에서 지정됩니다. **참고** 이름이 없는 사용자, 이름이 없는 그룹 또는 기타 유사한 ACL 항목을 설정하면 AppSpec 파일이 실패합니다. 이러한 유형의 권한을 지정하려면 `mode`를 대신 사용하세요. + `context` – 선택 사항. 보안 강화 Linux(SELinux) 기반 인스턴스의 경우 복사된 객체에 적용되는 보안 관련 컨텍스트 레이블 목록. 레이블은 `user`, `type` 및 `range`가 포함된 키로 지정됩니다. 자세한 내용은 SELinux 설명서를 참조하세요. 각 키는 문자열로 입력됩니다. 지정하지 않으면 원본 파일 또는 디렉터리/폴더 구조에 적용된 기존의 모든 레이블이 복사 작업 후에도 아무 것도 변경되지 않습니다. + `user` – 선택 사항. SELinux 사용자 + `type` – 선택 사항. SELinux 유형 이름. + `range` – 선택 사항. SELinux 범위 지정자. 머신에서 MLS(다중 수준 보안) 및 MCS(다중 범주 보안)를 활성화하지 않으면 아무 영향이 없습니다. 활성화하지 않으면 `range`는 기본적으로 **s0**으로 지정됩니다. 문자열을 사용하여 `context`를 지정합니다(예: `user: unconfined_u`). 각 `context`는 별도의 줄에서 지정됩니다. + `type` – 선택 사항. 지정한 권한을 적용할 객체 유형입니다. `type`은 **file** 또는 **directory**로 설정될 수 있는 문자열입니다. **file**을 지정하면 복사 작업 후 `object`에 즉시 포함되는 파일에만 권한이 적용됩니다(`object` 자체에는 적용되지 않음). **directory**를 지정하면 복사 작업 후 `object` 안의 어떤 위치에든 있는 모든 디렉터리/폴더에 권한이 반복적으로 적용됩니다(`object` 자체에는 적용되지 않음). 대시(-), 그 다음에 공백, 그 다음에 문자열을 사용하여 `type`을 지정합니다(예: `- file`). ## 'permissions' 섹션의 예 다음 예제에서는 `object`, `pattern`, `except`, `owner`, `mode` 및 `type` 명령을 사용하여 `'permissions'` 섹션을 지정하는 방법을 보여 줍니다. 이 예제는 Amazon Linux, Ubuntu Server 및 RHEL 인스턴스에만 적용됩니다. 이 예에서는 다음 파일 및 폴더가 아래와 같은 계층 구조로 복사된다고 가정합니다. ``` /tmp `-- my-app |-- my-file-1.txt |-- my-file-2.txt |-- my-file-3.txt |-- my-folder-1 | |-- my-file-4.txt | |-- my-file-5.txt | `-- my-file-6.txt `-- my-folder-2 |-- my-file-7.txt |-- my-file-8.txt |-- my-file-9.txt `-- my-folder-3 ``` 다음 AppSpec 파일은 파일 및 폴더가 복사된 후 이러한 파일 및 폴더에 대한 권한을 설정하는 방법을 보여줍니다. ``` version: 0.0 os: linux # Copy over all of the folders and files with the permissions they # were originally assigned. files: - source: ./my-file-1.txt destination: /tmp/my-app - source: ./my-file-2.txt destination: /tmp/my-app - source: ./my-file-3.txt destination: /tmp/my-app - source: ./my-folder-1 destination: /tmp/my-app/my-folder-1 - source: ./my-folder-2 destination: /tmp/my-app/my-folder-2 # 1) For all of the files in the /tmp/my-app folder ending in -3.txt # (for example, just my-file-3.txt), owner = adm, group = wheel, and # mode = 464 (-r--rw-r--). permissions: - object: /tmp/my-app pattern: "*-3.txt" owner: adm group: wheel mode: 464 type: - file # 2) For all of the files ending in .txt in the /tmp/my-app # folder, but not for the file my-file-3.txt (for example, # just my-file-1.txt and my-file-2.txt), # owner = ec2-user and mode = 444 (-r--r--r--). - object: /tmp/my-app pattern: "*.txt" except: [my-file-3.txt] owner: ec2-user mode: 444 type: - file # 3) For all the files in the /tmp/my-app/my-folder-1 folder except # for my-file-4.txt and my-file-5.txt, (for example, # just my-file-6.txt), owner = operator and mode = 646 (-rw-r--rw-). - object: /tmp/my-app/my-folder-1 pattern: "**" except: [my-file-4.txt, my-file-5.txt] owner: operator mode: 646 type: - file # 4) For all of the files that are immediately under # the /tmp/my-app/my-folder-2 folder except for my-file-8.txt, # (for example, just my-file-7.txt and # my-file-9.txt), owner = ec2-user and mode = 777 (-rwxrwxrwx). - object: /tmp/my-app/my-folder-2 pattern: "**" except: [my-file-8.txt] owner: ec2-user mode: 777 type: - file # 5) For all folders at any level under /tmp/my-app that contain # the name my-folder but not # /tmp/my-app/my-folder-2/my-folder-3 (for example, just # /tmp/my-app/my-folder-1 and /tmp/my-app/my-folder-2), # owner = ec2-user and mode = 555 (dr-xr-xr-x). - object: /tmp/my-app pattern: "*my-folder*" except: [tmp/my-app/my-folder-2/my-folder-3] owner: ec2-user mode: 555 type: - directory # 6) For the folder /tmp/my-app/my-folder-2/my-folder-3, # group = wheel and mode = 564 (dr-xrw-r--). - object: /tmp/my-app/my-folder-2/my-folder-3 group: wheel mode: 564 type: - directory ``` 그 결과, 권한은 다음과 같습니다. ``` -r--r--r-- ec2-user root my-file-1.txt -r--r--r-- ec2-user root my-file-2.txt -r--rw-r-- adm wheel my-file-3.txt dr-xr-xr-x ec2-user root my-folder-1 -rw-r--r-- root root my-file-4.txt -rw-r--r-- root root my-file-5.txt -rw-r--rw- operator root my-file-6.txt dr-xr-xr-x ec2-user root my-folder-2 -rwxrwxrwx ec2-user root my-file-7.txt -rw-r--r-- root root my-file-8.txt -rwxrwxrwx ec2-user root my-file-9.txt dr-xrw-r-- root wheel my-folder-3 ``` 다음 예제에서는 `acls` 및 `context` 명령을 추가로 사용하여 `'permissions'` 섹션을 지정하는 방법을 보여 줍니다. 이 예제는 Amazon Linux, Ubuntu Server 및 RHEL 인스턴스에만 적용됩니다. ``` permissions: - object: /var/www/html/WordPress pattern: "**" except: [/var/www/html/WordPress/ReadMe.txt] owner: bob group: writers mode: 644 acls: - u:mary:rw - u:sam:rw - m::rw context: user: unconfined_u type: httpd_sys_content_t range: s0 type: - file ``` # AppSpec 'hooks' 섹션 AppSpec 파일의 `'hooks'` 섹션 내용은 해당 배포의 컴퓨팅 플랫폼에 따라 다릅니다. EC2/온프레미스 배포에 대한 `'hooks'` 섹션에는 배포 수명 주기 이벤트 후크를 하나 이상의 스크립트에 연결하는 매핑이 포함되어 있습니다. Lambda 또는 Amazon ECS 배포에 대한 `'hooks'` 섹션은 배포 수명 주기 이벤트 중 실행하는 Lambda 확인 함수를 지정합니다. 이벤트 후크가 없는 경우 해당 이벤트에 대해 작업이 실행되지 않습니다. 이 섹션은 배포의 일부로 스크립트 또는 Lambda 확인 함수를 실행하는 경우에만 필요합니다. **Topics** + [Amazon ECS 배포를 위한 AppSpec 'hooks' 섹션](#appspec-hooks-ecs) + [AWS Lambda 배포를 위한 AppSpec 'hooks' 섹션](#appspec-hooks-lambda) + [EC2/온프레미스 배포를 위한 AppSpec 'hooks' 섹션](#appspec-hooks-server) ## Amazon ECS 배포를 위한 AppSpec 'hooks' 섹션 **Topics** + [Amazon ECS 배포를 위한 수명 주기 이벤트 후크 목록](#reference-appspec-file-structure-hooks-list-ecs) + [Amazon ECS 배포 시 후크의 실행 순서입니다.](#reference-appspec-file-structure-hooks-run-order-ecs) + ['hooks' 섹션의 구조](#reference-appspec-file-structure-hooks-section-structure-ecs) + [샘플 Lambda 'hooks' 함수](#reference-appspec-file-structure-hooks-section-structure-ecs-sample-function) ### Amazon ECS 배포를 위한 수명 주기 이벤트 후크 목록 AWS Lambda 후크는 수명 주기 이벤트 이름 뒤의 새 줄에 문자열로 지정된 하나의 Lambda 함수입니다. 각 후크는 배포별로 한 번 실행됩니다. 다음은 Amazon ECS 배포 중에 후크를 실행할 수 있는 수명 주기 이벤트에 대한 설명입니다. + `BeforeInstall` – 대체 작업 세트가 생성되기 전에 작업을 실행하려면 이 항목을 사용합니다. 대상 그룹 하나가 원래 작업 세트와 연결됩니다. 테스트 리스너(선택 사항)가 지정된 경우 원래 작업 세트와 연결됩니다. 이 시점에서는 롤백이 불가능합니다. + `AfterInstall` – 대체 작업 세트가 생성되고 대상 그룹 중 하나가 연결된 후 작업을 실행하면 이 항목을 사용합니다. 테스트 리스너(선택 사항)가 지정된 경우 원래 작업 세트와 연결됩니다. 이 수명 주기 이벤트에서 후크 함수의 결과는 롤백을 트리거할 수 있습니다. + `AfterAllowTestTraffic` – 테스트 리스너가 대체 작업 세트에 트래픽을 제공한 후 작업을 실행하려면 이 항목을 사용합니다. 이 시점에서 후크 함수의 결과는 롤백을 트리거할 수 있습니다. + `BeforeAllowTraffic` – 두 번째 대상 그룹이 대체 작업 세트와 연결된 후 트래픽이 대체 작업 세트로 전환되기 전에 작업을 실행하려면 이 항목을 사용합니다. 이 수명 주기 이벤트에서 후크 함수의 결과는 롤백을 트리거할 수 있습니다. + `AfterAllowTraffic` – 두 번째 대상 그룹이 대체 작업 세트에 트래픽을 제공한 후 작업을 실행하려면 이 항목을 사용합니다. 이 수명 주기 이벤트에서 후크 함수의 결과는 롤백을 트리거할 수 있습니다. 자세한 내용은 [Amazon ECS 배포 중에 발생하는 일](deployment-steps-ecs.md#deployment-steps-what-happens) 및 [튜토리얼: Amazon ECS 서비스 배포 및 확인 테스트](tutorial-ecs-deployment-with-hooks.md) 섹션을 참조하세요. ### Amazon ECS 배포 시 후크의 실행 순서입니다. Amazon ECS 배포에서 이벤트 후크는 다음 순서대로 실행됩니다. ![\[Amazon ECS 배포 시 이벤트 후크의 실행 순서입니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/lifecycle-event-order-ecs.png) **참고** 배포의 **Start**, **Install**, **TestTraffic**, **AllowTraffic** 및 **End** 이벤트는 스크립팅할 수 없기 때문에 이 다이어그램에서 회색으로 표시됩니다. ### 'hooks' 섹션의 구조 다음은 `'hooks'` 섹션 구조의 예입니다. YAML 사용: ``` Hooks: - BeforeInstall: "BeforeInstallHookFunctionName" - AfterInstall: "AfterInstallHookFunctionName" - AfterAllowTestTraffic: "AfterAllowTestTrafficHookFunctionName" - BeforeAllowTraffic: "BeforeAllowTrafficHookFunctionName" - AfterAllowTraffic: "AfterAllowTrafficHookFunctionName" ``` JSON 사용: ``` "Hooks": [ { "BeforeInstall": "BeforeInstallHookFunctionName" }, { "AfterInstall": "AfterInstallHookFunctionName" }, { "AfterAllowTestTraffic": "AfterAllowTestTrafficHookFunctionName" }, { "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName" }, { "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName" } ] } ``` ### 샘플 Lambda 'hooks' 함수 `'hooks'` 섹션을 사용하여 CodeDeploy가 Amazon ECS 배포를 확인하기 위해 호출할 수 있는 Lambda 함수를 지정합니다. `BeforeInstall`, `AfterInstall`, `AfterAllowTestTraffic`, `BeforeAllowTraffic` 및 `AfterAllowTraffic` 배포 수명 주기 이벤트에 동일한 함수 또는 다른 함수를 사용할 수 있습니다. 검증 테스트가 완료되면 Lambda `AfterAllowTraffic` 함수는 CodeDeploy를 다시 호출하고 `Succeeded` 또는 `Failed` 결과를 전달합니다. **중요** CodeDeploy가 1시간 이내에 Lambda 확인 함수를 통해 알림을 받지 못하면 배포가 실패한 것으로 간주합니다. Lambda 후크 함수 호출 전에 서버는 `putLifecycleEventHookExecutionStatus` 명령을 사용하여 배포 ID와 수명 주기 이벤트 후크 실행 ID를 통지받아야 합니다. 다음은 Node.js로 작성된 샘플 Lambda 후크 함수입니다. ``` 'use strict'; const aws = require('aws-sdk'); const codedeploy = new aws.CodeDeploy({apiVersion: '2014-10-06'}); exports.handler = (event, context, callback) => { //Read the DeploymentId from the event payload. var deploymentId = event.DeploymentId; //Read the LifecycleEventHookExecutionId from the event payload var lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId; /* Enter validation tests here. */ // Prepare the validation test results with the deploymentId and // the lifecycleEventHookExecutionId for CodeDeploy. var params = { deploymentId: deploymentId, lifecycleEventHookExecutionId: lifecycleEventHookExecutionId, status: 'Succeeded' // status can be 'Succeeded' or 'Failed' }; // Pass CodeDeploy the prepared validation test results. codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) { if (err) { // Validation failed. callback('Validation test failed'); } else { // Validation succeeded. callback(null, 'Validation test succeeded'); } }); }; ``` ## AWS Lambda 배포를 위한 AppSpec 'hooks' 섹션 **Topics** + [AWS Lambda 배포를 위한 수명 주기 이벤트 후크 목록](#reference-appspec-file-structure-hooks-list-lambda) + [Lambda 함수 버전 배포에서 후크 실행 순서](#reference-appspec-file-structure-hooks-run-order-lambda) + ['hooks' 섹션의 구조](#reference-appspec-file-structure-hooks-section-structure-lambda) + [샘플 Lambda 'hooks' 함수](#reference-appspec-file-structure-hooks-section-structure-lambda-sample-function) ### AWS Lambda 배포를 위한 수명 주기 이벤트 후크 목록 AWS Lambda 후크는 수명 주기 이벤트 이름 뒤의 새 줄에 문자열로 지정된 하나의 Lambda 함수입니다. 각 후크는 배포별로 한 번 실행됩니다. 다음은 AppSpec 파일에서 사용할 수 있는 후크에 대한 설명입니다. + **BeforeAllowTraffic** – 배포된 Lambda 함수 버전으로 트래픽을 전환하기 전에 작업을 실행하려면 이 항목을 사용합니다. + **AfterAllowTraffic** – 배포된 Lambda 함수 버전으로 모든 트래픽이 전환된 후에 작업을 실행하려면 이 항목을 사용합니다. ### Lambda 함수 버전 배포에서 후크 실행 순서 서버리스 Lambda 함수 버전 배포에서 이벤트 후크는 다음 순서로 실행됩니다. ![\[Lambda 배포의 이벤트 후크 순서입니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/lifecycle-event-order-lambda.png) **참고** 배포의 **Start**, **AllowTraffic**, **End** 이벤트는 스크립팅할 수 없기 때문에 이 다이어그램에서 회색으로 표시됩니다. ### 'hooks' 섹션의 구조 다음은 'hooks' 섹션 구조의 예입니다. YAML 사용: ``` hooks: - BeforeAllowTraffic: BeforeAllowTrafficHookFunctionName - AfterAllowTraffic: AfterAllowTrafficHookFunctionName ``` JSON 사용: ``` "hooks": [{ "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName" }, { "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName" }] ``` ### 샘플 Lambda 'hooks' 함수 'hooks' 섹션을 사용하여 CodeDeploy가 Lambda 배포를 확인하기 위해 호출할 수 있는 Lambda 함수를 지정합니다. `BeforeAllowTraffic` 및 `AfterAllowTraffic` 배포 수명 주기 이벤트에 동일한 함수 또는 다른 함수를 사용할 수 있습니다. 검증 테스트가 완료되면 Lambda 확인 함수는 CodeDeploy를 다시 호출하고 `Succeeded` 또는 `Failed` 결과를 전달합니다. **중요** CodeDeploy가 1시간 이내에 Lambda 확인 함수를 통해 알림을 받지 못하면 배포가 실패한 것으로 간주합니다. Lambda 후크 함수 호출 전에 서버는 `putLifecycleEventHookExecutionStatus` 명령을 사용하여 배포 ID와 수명 주기 이벤트 후크 실행 ID를 통지받아야 합니다. 다음은 Node.js로 작성된 샘플 Lambda 후크 함수입니다. ``` 'use strict'; const aws = require('aws-sdk'); const codedeploy = new aws.CodeDeploy({apiVersion: '2014-10-06'}); exports.handler = (event, context, callback) => { //Read the DeploymentId from the event payload. var deploymentId = event.DeploymentId; //Read the LifecycleEventHookExecutionId from the event payload var lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId; /* Enter validation tests here. */ // Prepare the validation test results with the deploymentId and // the lifecycleEventHookExecutionId for CodeDeploy. var params = { deploymentId: deploymentId, lifecycleEventHookExecutionId: lifecycleEventHookExecutionId, status: 'Succeeded' // status can be 'Succeeded' or 'Failed' }; // Pass CodeDeploy the prepared validation test results. codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) { if (err) { // Validation failed. callback('Validation test failed'); } else { // Validation succeeded. callback(null, 'Validation test succeeded'); } }); }; ``` ## EC2/온프레미스 배포를 위한 AppSpec 'hooks' 섹션 **Topics** + [수명 주기 이벤트 후크 목록](#reference-appspec-file-structure-hooks-list) + [수명 주기 이벤트 후크 가용성](#reference-appspec-file-structure-hooks-availability) + [배포 시 후크의 실행 순서](#reference-appspec-file-structure-hooks-run-order) + ['hooks' 섹션의 구조](#reference-appspec-file-structure-hooks-section-structure) + [후크 스크립트에서 파일 참조](#codedeploy-agent-working-directory) + [후크의 환경 변수 가용성](#reference-appspec-file-structure-environment-variable-availability) + [후크 예제](#reference-appspec-file-structure-hooks-example) ### 수명 주기 이벤트 후크 목록 EC2/온프레미스 배포 후크는 인스턴스에 대한 배포별로 한 번 실행됩니다. 후크에서 실행할 하나 이상의 스크립트를 지정할 수 있습니다. 수명 주기 이벤트에 대한 각 후크는 별도의 줄에서 문자열로 지정됩니다. 다음은 AppSpec 파일에서 사용할 수 있는 후크에 대한 설명입니다. 어떤 수명 주기 이벤트 후크가 어떤 배포 및 롤백 유형에 유효한지는 [수명 주기 이벤트 후크 가용성](#reference-appspec-file-structure-hooks-availability) 단원을 참조하세요. + `ApplicationStop` – 이 배포 수명 주기 이벤트는 애플리케이션 수정이 다운로드되기 전에도 발생합니다. 이 이벤트에 대해서는 애플리케이션을 안전하게 종료하거나 배포 준비 중에 현재 설치된 패키지를 제거하도록 스크립트를 지정할 수 있습니다. 이 배포 수명 주기 이벤트에 사용되는 AppSpec 파일 및 스크립트는 이전에 성공적으로 배포된 애플리케이션 수정에서 가져옵니다. **참고** AppSpec 파일은 인스턴스에 배포하기 전에는 인스턴스에 존재하지 않습니다. 이러한 이유로, 인스턴스에 처음으로 배포할 때는 `ApplicationStop` 후크가 실행되지 않습니다. 인스턴스에 두 번째로 배포할 때는 `ApplicationStop` 후크를 사용할 수 있습니다. 가장 마지막으로 배포가 완료된 애플리케이션 수정의 위치를 확인하기 위해 CodeDeploy 에이전트는 `deployment-group-id_last_successful_install` 파일에 나와 있는 위치를 찾습니다. 이 파일의 위치는 다음과 같습니다. Amazon Linux, Ubuntu Server 및 RHEL Amazon EC2의 `/opt/codedeploy-agent/deployment-root/deployment-instructions` 폴더 Windows Server Amazon EC2 인스턴스에 대한 `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions` 폴더. `ApplicationStop` 배포 수명 주기 이벤트 중 실패하는 배포 문제를 해결하려면 [실패한 ApplicationStop, BeforeBlockTraffic 또는 AfterBlockTraffic 배포 수명 주기 이벤트 문제 해결](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures) 단원을 참조하세요. + `DownloadBundle` – 이 배포 수명 주기 이벤트 중 에이전트는 애플리케이션 수정 파일을 다음 임시 위치로 복사합니다. Amazon Linux, Ubuntu Server 및 RHEL Amazon EC2의 `/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive` 폴더 Windows Server Amazon EC2 인스턴스에 대한 `C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archive` 폴더. 이 이벤트는 CodeDeploy 에이전트에 예약되어 있으므로 스크립트 실행에 사용할 수 없습니다. `DownloadBundle` 배포 수명 주기 이벤트 중 실패하는 배포 문제를 해결하려면 [실패하고 UnknownError: not opened for reading이 표시되는 DownloadBundle 배포 수명 주기 이벤트 문제 해결](troubleshooting-deployments.md#troubleshooting-deployments-downloadbundle) 단원을 참조하세요. + `BeforeInstall` – 파일 암호화 해제 및 현재 버전의 백업 만들기와 같은 사전 설치 작업에 이 배포 수명 주기 이벤트를 사용할 수 있습니다. + `Install` – 이 배포 수명 주기 이벤트 중에 CodeDeploy 에이전트는 수정 파일을 임시 위치에서 최종 대상 폴더로 복사합니다. 이 이벤트는 CodeDeploy 에이전트에 예약되어 있으므로 스크립트 실행에 사용할 수 없습니다. + `AfterInstall` – 애플리케이션 구성 또는 파일 권한 변경과 같은 작업에 이 배포 수명 주기 이벤트를 사용할 수 있습니다. + `ApplicationStart` - `ApplicationStop` 중에 중지된 서비스를 다시 시작하려면 일반적으로 이 배포 수명 주기 이벤트를 사용합니다. + `ValidateService` – 마지막 배포 수명 주기 이벤트입니다. 배포가 성공적으로 완료되었는지 확인하는 데 사용됩니다. + `BeforeBlockTraffic` – 로드 밸런서에서 작업이 등록 취소되기 전에 인스턴스에서 작업을 실행하려면 이 배포 수명 주기 이벤트를 사용할 수 있습니다. `BeforeBlockTraffic` 배포 수명 주기 이벤트 중 실패하는 배포 문제를 해결하려면 [실패한 ApplicationStop, BeforeBlockTraffic 또는 AfterBlockTraffic 배포 수명 주기 이벤트 문제 해결](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures) 단원을 참조하세요. + `BlockTraffic` – 이 배포 수명 주기 이벤트 중에는 트래픽을 현재 제공하고 있는 인스턴스에 액세스할 수 없도록 인터넷 트래픽이 차단됩니다. 이 이벤트는 CodeDeploy 에이전트에 예약되어 있으므로 스크립트 실행에 사용할 수 없습니다. + `AfterBlockTraffic` – 각 로드 밸런서에서 작업이 등록 취소된 후 인스턴스에서 작업을 실행하려면 이 배포 수명 주기 이벤트를 사용할 수 있습니다. `AfterBlockTraffic` 배포 수명 주기 이벤트 중 실패하는 배포 문제를 해결하려면 [실패한 ApplicationStop, BeforeBlockTraffic 또는 AfterBlockTraffic 배포 수명 주기 이벤트 문제 해결](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures) 단원을 참조하세요. + `BeforeAllowTraffic` – 로드 밸런서에 작업이 등록되기 전에 인스턴스에서 작업을 실행하려면 이 배포 수명 주기 이벤트를 사용할 수 있습니다. + `AllowTraffic` – 이 배포 수명 주기 이벤트 중에는 배포 후 인터넷 트래픽이 인스턴스에 액세스할 수 있도록 허용됩니다. 이 이벤트는 CodeDeploy 에이전트에 예약되어 있으므로 스크립트 실행에 사용할 수 없습니다. + `AfterAllowTraffic` – 로드 밸런서에 작업이 등록된 후 인스턴스에서 작업을 실행하려면 이 배포 수명 주기 이벤트를 사용할 수 있습니다. ### 수명 주기 이벤트 후크 가용성 다음 표에는 각 배포 및 롤백 시나리오에 사용할 수 있는 수명 주기 이벤트 후크가 나와 있습니다. | 수명 주기 이벤트 이름 | Auto Scaling 시작 배포¹ | Auto Scaling 종료 배포¹ | 현재 위치 배포¹ | 블루/그린 배포: 원본 인스턴스 | 블루/그린 배포: 대체 인스턴스 | 블루/그린 배포 롤백: 원본 인스턴스 | 블루/그린 배포 롤백: 대체 인스턴스 | | --- | --- | --- | --- | --- | --- | --- | --- | | ApplicationStop | ✓ | ✓ | ✓ | | ✓ | | | | DownloadBundle³ | ✓ | | ✓ | | ✓ | | | | BeforeInstall | ✓ | | ✓ | | ✓ | | | | Install³ | ✓ | | ✓ | | ✓ | | | | AfterInstall | ✓ | | ✓ | | ✓ | | | | ApplicationStart | ✓ | | ✓ | | ✓ | | | | ValidateService | ✓ | | ✓ | | ✓ | | | | BeforeBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ | | BlockTraffic³ | | ✓ | ✓ | ✓ | | | ✓ | | AfterBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ | | BeforeAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | | | AllowTraffic³ | ✓ | | ✓ | | ✓ | ✓ | | | AfterAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | | | ¹ Amazon EC2 Auto Scaling 배포에 대한 자세한 내용은 [Amazon EC2 Auto Scaling에서 CodeDeploy를 사용하는 방식](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors) 단원을 참조하세요. ² 현재 위치 배포의 롤백에도 적용됩니다. ³ CodeDeploy 작업을 위해 예약되어 있습니다. 스크립트를 실행하는 데 사용할 수 없습니다. | ### 배포 시 후크의 실행 순서 **Auto Scaling 시작 배포** Auto Scaling 시작 배포 중에 CodeDeploy는 다음 순서로 이벤트 후크를 실행합니다. Amazon EC2 Auto Scaling 시작 배포에 대한 자세한 내용은 [Amazon EC2 Auto Scaling에서 CodeDeploy를 사용하는 방식](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors) 단원을 참조하세요. ![\[Auto Scaling 시작 배포 중에 이벤트 후크의 실행 순서입니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/lifecycle-event-order-scale-out.png) **참고** 배포의 **Start**, **Install**, **TestTraffic**, **AllowTraffic** 및 **End** 이벤트는 스크립트화할 수 없으므로 이 다이어그램에서 회색으로 표시됩니다. 그러나 AppSpec 파일의 `'files'` 섹션을 편집하여 **Install** 이벤트 중 설치되는 항목을 지정할 수 있습니다. **Auto Scaling 종료 배포** Auto Scaling 종료 배포 중에 CodeDeploy는 다음 순서로 이벤트 후크를 실행합니다. Amazon EC2 Auto Scaling 종료 배포에 대한 자세한 내용은 [Auto Scaling 확장 이벤트 중 종료 배포 활성화](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors-hook-enable) 단원을 참조하세요. ![\[Auto Scaling 종료 배포 중에 이벤트 후크의 실행 순서입니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/lifecycle-event-order-scale-in.png) **참고** 배포의 **Start**, **BlockTraffic**, **End** 이벤트는 스크립팅할 수 없기 때문에 이 다이어그램에서 회색으로 표시됩니다. **인 플레이스(in-place) 배포** 인 플레이스(in-place) 배포 시(인 플레이스(in-place) 배포의 롤백 포함) 이벤트 후크는 다음 순서로 실행됩니다. **참고** 인 플레이스 배포의 경우 트래픽 차단 및 허용과 관련된 6개의 후크는 배포 그룹의 Elastic Load Balancing에서 Classic Load Balancer, Application Load Balancer 또는 Network Load Balancer를 지정한 경우에만 적용됩니다. ![\[인플레이스 배포 롤백 중 이벤트 후크의 순서입니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/lifecycle-event-order-in-place.png) **참고** 배포의 **Start**, **DownloadBundle**, **Install** 및 **End** 이벤트는 스크립팅할 수 없기 때문에 이 다이어그램에서 회색으로 표시됩니다. 그러나 AppSpec 파일의 `'files'` 섹션을 편집하여 **Install** 이벤트 중 설치되는 항목을 지정할 수 있습니다. **블루/그린 배포** 블루/그림 배포에서 이벤트 후크는 다음 순서대로 실행됩니다. ![\[블루/그린 배포에서 이벤트 후크의 실행 순서입니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/lifecycle-event-order-blue-green.png) **참고** 배포의 **Start**, **DownloadBundle**, **Install**, **BlockTraffic**, **AllowTraffic** 및 **End** 이벤트는 스크립팅할 수 없기 때문에 이 다이어그램에서 회색으로 표시됩니다. 그러나 AppSpec 파일의 'files' 섹션을 편집하여 **Install** 이벤트 중 설치되는 항목을 지정할 수 있습니다. ### 'hooks' 섹션의 구조 `'hooks'` 섹션의 구조는 다음과 같습니다. ``` hooks: deployment-lifecycle-event-name: - location: script-location timeout: timeout-in-seconds runas: user-name ``` 배포 수명 주기 이벤트 이름 뒤의 **hook** 항목에 다음 요소를 포함할 수 있습니다. ** location ** 필수 사항입니다. 수정의 스크립트 파일 번들 위치 `hooks` 섹션에서 지정한 스크립트 위치는 애플리케이션 수정 번들의 루트를 기준으로 합니다. 자세한 내용은 [CodeDeploy의 개정 계획](application-revisions-plan.md) 단원을 참조하십시오. ** 제한 시간 ** 선택 사항. 스크립트가 실패로 간주되기 전에 실행할 수 있는 기간(초). 기본값은 3600초(1시간)입니다. 3600초(1시간)은 각 배포 수명 주기 이벤트에 대한 스크립트 실행에 허용되는 최대 시간입니다. 스크립트가 이 한도를 초과하면 배포가 중지되고 인스턴스에 대한 배포가 실패합니다. 각 배포 수명 주기 이벤트의 모든 스크립트에 대해 **timeout**에 지정된 총 시간(초)이 이 한도를 초과하지 않아야 합니다. ** runas ** 선택 사항. 스크립트 실행 시 가장하는 사용자. 기본적으로 인스턴스에서 실행 중인 CodeDeploy 에이전트입니다. CodeDeploy는 암호를 저장하지 않기 때문에 **runas** 사용자에게 암호가 필요합니다. 이 요소는 Amazon Linux, Ubuntu Server 및 RHEL 인스턴스에만 적용됩니다. ### 후크 스크립트에서 파일 참조 AppSpec [AppSpec 'hooks' 섹션](#reference-appspec-file-structure-hooks) 섹션에 설명된 대로 스크립트를 CodeDeploy 수명 주기 이벤트에 연결하고 스크립트에서 파일(예: `helper.sh`)을 참조하려는 경우 다음을 사용하여 `helper.sh`를 지정해야 합니다. + (권장) 절대 경로. [절대 경로 사용](#codedeploy-agent-working-dir-absolute)을(를) 참조하세요. + 상대 경로. [상대 경로 사용](#codedeploy-agent-working-dir-relative)을(를) 참조하세요. #### 절대 경로 사용 *절대* 경로를 사용하여 파일을 참조하려면 다음 중 하나를 사용할 수 있습니다. + AppSpec 파일의 `files` 섹션의 `destination` 속성에서 절대 경로를 지정합니다. 그런 다음 후크 스크립트에서 동일한 절대 경로를 지정합니다. 자세한 내용은 [AppSpec 'files' 섹션(EC2/온프레미스 배포만 해당)](reference-appspec-file-structure-files.md) 단원을 참조하십시오. + 후크 스크립트에서 동적 절대 경로를 지정합니다. 자세한 내용은 [배포 아카이브 위치](#codedeploy-agent-working-dir-archive)를 참조하세요. **배포 아카이브 위치** [DownloadBundle](#reference-appspec-file-structure-hooks-list) 수명 주기 이벤트 중에 CodeDeploy 에이전트는 배포를 위한 [개정 버전](application-revisions.md)을 다음 형식의 디렉터리로 추출합니다. `root-directory/deployment-group-id/deployment-id/deployment-archive` 경로의 *root-directory* 부분은 항상 다음 표에 표시된 기본값으로 설정되거나 `:root_dir` 구성 설정으로 제어됩니다. 구성 설정에 대한 자세한 내용은 [CodeDeploy 에이전트 구성 참조](reference-agent-configuration.md) 단원을 참조하세요. | 에이전트 플랫폼 | 기본 루트 디렉터리 | | --- | --- | | Linux – 모든 RPM 분포 | /opt/codedeploy-agent/deployment-root | | Ubuntu 서버 – 모든 Debian 분포 | /opt/codedeploy-agent/deployment-root | | Windows Server | %ProgramData%\$1Amazon\$1CodeDeploy | 후크 스크립트에서 루트 디렉터리 경로와 `DEPLOYMENT_ID` 및 `DEPLOYMENT_GROUP_ID` 환경 변수를 사용하여 현재 배포 아카이브에 액세스할 수 있습니다. 사용할 수 있는 변수에 대한 자세한 내용은 [후크의 환경 변수 가용성](#reference-appspec-file-structure-environment-variable-availability) 섹션을 참조하세요. 예를 들어 Linux에서 개정 버전의 루트에 있는 `data.json` 파일에 액세스하는 방법은 다음과 같습니다. ``` #!/bin/bash rootDirectory="/opt/codedeploy-agent/deployment-root" # note: this will be different if you # customize the :root_dir configuration dataFile="$rootDirectory/$DEPLOYMENT_GROUP_ID/$DEPLOYMENT_ID/deployment-archive/data.json" data=$(cat dataFile) ``` 다른 예로, 다음은 Windows에서 Powershell을 사용하여 개정 버전의 루트에 있는 `data.json` 파일에 액세스하는 방법입니다. ``` $rootDirectory="$env:ProgramData\Amazon\CodeDeploy" # note: this will be different if you # customize the :root_dir configuration $dataFile="$rootDirectory\$env:DEPLOYMENT_GROUP_ID\$env:DEPLOYMENT_ID\deployment-archive\data.json" $data=(Get-Content $dataFile) ``` #### 상대 경로 사용 *상대* 경로를 사용하여 파일을 참조하려면 CodeDeploy 에이전트의 작업 디렉터리를 알아야 합니다. 파일 경로는 이 디렉터리를 기준으로 합니다. 다음 표는 CodeDeploy 에이전트의 지원되는 각 플랫폼에 대한 작업 디렉터리를 보여줍니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html) ### 후크의 환경 변수 가용성 각 배포 수명 주기 이벤트 중 후크 스크립트는 다음 환경 변수에 액세스할 수 있습니다. ** APPLICATION\$1NAME ** 현재 배포의 일부인 CodeDeploy의 애플리케이션 이름(예: `WordPress_App`) ** DEPLOYMENT\$1ID ** ID CodeDeploy가 현재 배포에 할당됩니다(예: `d-AB1CDEF23`). ** DEPLOYMENT\$1GROUP\$1NAME ** 현재 배포의 일부인 CodeDeploy의 배포 그룹 이름(예: `WordPress_DepGroup`) ** DEPLOYMENT\$1GROUP\$1ID ** 현재 배포의 일부인 CodeDeploy의 배포 그룹 ID(예: `b1a2189b-dd90-4ef5-8f40-4c1c5EXAMPLE`) ** LIFECYCLE\$1EVENT ** 현재 배포 수명 주기 이벤트의 이름(예: `AfterInstall`) 이러한 환경 변수는 각 배포 수명 주기 이벤트에 대해 로컬에서 적용됩니다. 배포 번들의 소스에 따라 후크 스크립트에 사용할 수 있는 추가 환경 변수가 있습니다. **Amazon S3의 번들** + **BUNDLE\$1BUCKET** 배포 번들을 다운로드할 수 있는 Amazon S3 버킷의 이름입니다(예: `my-s3-bucket`). + **BUNDLE\$1KEY** Amazon S3 버킷에서 다운로드한 번들의 객체 키입니다(예: `WordPress_App.zip`). + **BUNDLE\$1VERSION** 번들의 객체 버전입니다(예: `3sL4kqtJlcpXroDTDmJ+rmSpXd3dIbrHY+MTRCxf3vjVBH40Nr8X8gdRQBpUMLUo`). 이 변수는 Amazon S3 버킷에 [객체 버전 관리](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html)가 활성화된 경우에만 설정됩니다. + **BUNDLE\$1ETAG** 번들의 객체 etag입니다(예: `b10a8db164e0754105b7a99be72e3fe5-4`). **GitHub에서 제공하는 번들** + **BUNDLE\$1COMMIT** Git에서 생성한 번들의 SHA256 커밋 해시입니다(예: `d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26`). 다음 스크립트는 **DEPLOYMENT\$1GROUP\$1NAME**의 값이 `Staging`과 동일하면 Apache HTTP 서버의 수신 포트를 80이 아니라 9090으로 변경합니다. `BeforeInstall` 배포 수명 주기 이벤트 중에 이 스크립트를 호출해야 합니다. ``` if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ] then sed -i -e 's/Listen 80/Listen 9090/g' /etc/httpd/conf/httpd.conf fi ``` 다음 스크립트 예제는 **DEPLOYMENT\$1GROUP\$1NAME** 환경 변수의 값이 `Staging`과 동일하면 오류 로그에 기록되는 메시지의 세부 수준을 경고에서 디버그로 변경합니다. `BeforeInstall` 배포 수명 주기 이벤트 중에 이 스크립트를 호출해야 합니다. ``` if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ] then sed -i -e 's/LogLevel warn/LogLevel debug/g' /etc/httpd/conf/httpd.conf fi ``` 다음 스크립트 예제는 지정된 웹 페이지의 텍스트를 이러한 환경 변수의 값을 표시하는 텍스트로 바꿉니다. `AfterInstall` 배포 수명 주기 이벤트 중에 이 스크립트를 호출해야 합니다. ``` #!/usr/bin/python import os strToSearch="

This application was deployed using CodeDeploy.

" strToReplace="

This page for "+os.environ['APPLICATION_NAME']+" application and "+os.environ['DEPLOYMENT_GROUP_NAME']+" deployment group with "+os.environ['DEPLOYMENT_GROUP_ID']+" deployment group ID was generated by a "+os.environ['LIFECYCLE_EVENT']+" script during "+os.environ['DEPLOYMENT_ID']+" deployment.

" fp=open("/var/www/html/index.html","r") buffer=fp.read() fp.close() fp=open("/var/www/html/index.html","w") fp.write(buffer.replace(strToSearch,strToReplace)) fp.close() ``` ### 후크 예제 `AfterInstall` 수명 주기 이벤트에 대한 두 개의 후크를 지정하는 **hooks** 항목의 예입니다. ``` hooks: AfterInstall: - location: Scripts/RunResourceTests.sh timeout: 180 - location: Scripts/PostDeploy.sh timeout: 180 ``` `Scripts/RunResourceTests.sh` 스크립트는 배포 프로세스의 `AfterInstall` 단계 중 실행됩니다. 스크립트 실행 시간이 180초(3분)를 넘어가면 배포에 성공하지 못합니다. 'hooks' 섹션에서 지정한 스크립트 위치는 애플리케이션 수정 번들의 루트를 기준으로 합니다. 위의 예제에서 `RunResourceTests.sh` 파일은 `Scripts` 디렉터리에 있습니다. `Scripts` 디렉터리는 번들의 루트 수준에 있습니다. 자세한 내용은 [CodeDeploy의 개정 계획](application-revisions-plan.md) 단원을 참조하십시오.