翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AppSpec ファイル構造 次に示すのは、 AWS Lambda および EC2/オンプレミスコンピューティングプラットフォームへのデプロイに使用される AppSpec ファイルのハイレベルな構造です。 文字列である YAML 形式の AppSpec ファイルの値は、別途指定されている場合を除き、引用符 ("") で囲んではいけません。 ## Amazon ECS デプロイ向けの AppSpec ファイル構造 **注記** この AppSpec ファイルは YAML で記述されますが、同じ構造を使用して JSON で記述することもできます。JSON 形式の AppSpec ファイルの文字列は、常に引用符 ("") で囲みます。 ``` version: 0.0 resources: ecs-service-specifications hooks: deployment-lifecycle-event-mappings ``` この構造の説明 ** **バージョン** ** このセクションでは、AppSpec ファイルのバージョンを指定します。この値を変更しないでください。これは必須です。現在許容されている値は、**0.0** のみです。将来の利用のために CodeDeploy で予約されます。 文字列で **version** を指定します。 ** **リソース** ** このセクションでは、デプロイする 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)」を参照してください。 ## Lambda AWS デプロイの AppSpec ファイル構造 **注記** この AppSpec ファイルは、YAML で記述されますが、同じ構造を使用して JSON で Lambda デプロイ用の AppSpec ファイルを記述することもできます。JSON 形式の AppSpec ファイルの文字列は、常に引用符 ("") で囲みます。 ``` version: 0.0 resources: lambda-function-specifications hooks: deployment-lifecycle-event-mappings ``` この構造の説明 ** **バージョン** ** このセクションでは、AppSpec ファイルのバージョンを指定します。この値を変更しないでください。これは必須です。現在許容されている値は、**0.0** のみです。将来の利用のために CodeDeploy で予約されます。 文字列で **version** を指定します。 ** **リソース** ** このセクションでは、デプロイする 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 ``` この構造の説明 ** **バージョン** ** このセクションでは、AppSpec ファイルのバージョンを指定します。この値を変更しないでください。これは必須です。現在許容されている値は、**0.0** のみです。将来の利用のために CodeDeploy で予約されます。 文字列で **version** を指定します。 ** **os** ** このセクションでは、デプロイ先であるインスタンスのオペレーティングシステムの値を指定します。これは必須です。次の値を指定できます。 + **linux**— インスタンスは Amazon Linux、Ubuntu Server、RHEL インスタンスです。 + **windows**— インスタンスは Windows Server インスタンスです。 文字列で **os** を指定します。 ** **ファイル** ** このセクションでは、デプロイの **Install** イベント中に、インスタンスにコピーするファイル名を指定します。 詳細については、「[AppSpec の「ファイル」セクション (EC2/オンプレミスデプロイのみ)](reference-appspec-file-structure-files.md)」を参照してください。 ** **アクセス権限** ** このセクションでは、インスタンスへのコピー中に特別なアクセス権限をファイルの `files` セクションに適用する方法を指定します。このセクションは、Amazon Linux、Ubuntu Server、および Red Hat Enterprise Linux (RHEL) インスタンスのみに適用されます。 詳細については、「[AppSpec の「許可」セクション (EC2/オンプレミスデプロイのみ)](reference-appspec-file-structure-permissions.md)」を参照してください。 ** **hooks** ** このセクションでは、デプロイ中に特定のデプロイライフサイクルイベントで実行するスクリプトを指定します。 詳細については、「[AppSpec の「hooks」セクション](reference-appspec-file-structure-hooks.md)」を参照してください。 **Topics** + [Amazon ECS デプロイ向けの AppSpec ファイル構造](#ecs-appspec-structure) + [Lambda AWS デプロイの AppSpec ファイル構造](#lambda-appspec-structure) + [EC2/オンプレミスデプロイの AppSpec ファイル構造](#server-appspec-structure) + [AppSpec の「ファイル」セクション (EC2/オンプレミスデプロイのみ)](reference-appspec-file-structure-files.md) + [AppSpec の「リソース」セクション (Amazon ECS と AWS Lambda デプロイのみ)](reference-appspec-file-structure-resources.md) + [AppSpec の「許可」セクション (EC2/オンプレミスデプロイのみ)](reference-appspec-file-structure-permissions.md) + [AppSpec の「hooks」セクション](reference-appspec-file-structure-hooks.md) # AppSpec の「ファイル」セクション (EC2/オンプレミスデプロイのみ) デプロイの **Install** イベント中にインスタンスにインストールする、アプリケーションリビジョンのファイルに関する情報を 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: 現在デプロイされているアプリケーションリビジョンのファイルのバージョンにより、インスタンスの既存のファイルのバージョンが置き換えられます。 + RETAIN: インスタンスにすでに存在するファイルのバージョンは保持され、新しいデプロイの一部として使用されます。 `file_exists_behavior` 設定を使用する場合、この設定を理解してください。 + は 1 度だけ指定でき、`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 ``` この例では、次の 2 つのオペレーションが、**Install** イベント中に実行されます。 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 サービス内の、1 つ以上のサブネットのカンマ区切りリスト。 + `SecurityGroups`: オプション。Amazon Elastic Container Service にある、1 つ以上のセキュリティグループのカンマ区切りリスト。 + `AssignPublicIp`: オプション。Amazon ECS サービスの Elastic Network Interface がパブリック 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`: オプション。ベース値は、指定されたキャパシティープロバイダーで実行するタスクの最小限の数を指定します。キャパシティープロバイダー戦略では、ベースを定義できるキャパシティープロバイダーは 1 つだけです。値が指定されていない場合は、デフォルト値の 0 が使用されます。 + `CapacityProvider`: オプション。容量プロバイダーの短い名前。例: *capacityProviderA* + `Weight`: オプション。 *ウエイト*値は、指定したキャパシティープロバイダーを使用する起動済みタスクの総数に対する相対的な割合を示します。`weight` 値は、`base` 値が、もし定義されている場合、満たされた後に、考慮されます。 `weight` 値が指定されていない場合は、デフォルト値の `0` が使用されます。キャパシティープロバイダー戦略内で複数のキャパシティープロバイダーを指定する場合、少なくとも 1 つのキャパシティープロバイダーのウェイト値が 0 より大きい必要があり、ウェイトが `0` のキャパシティープロバイダーはタスクを配置するのに使用しません。すべてのキャパシティープロバイダーが `0` のウェイトを持つ戦略で複数のキャパシティープロバイダーを指定すると、キャパシティープロバイダー戦略を使用する `RunTask` または `CreateService` アクションは失敗します。 例えば、加重を使用するシナリオが 2 つのキャパシティープロバイダーを含む戦略を定義し、両方の加重が `1` である場合、`base` が満たされたとき、タスクは 2 つのキャパシティープロバイダー間で均等に分割されます。同じロジックを使用して、キャパシティープロバイダー *capacityProviderA* に `1` のウエイトを指定し、*capacityProviderB* に `4` のウエイトを指定すると、*capacityProviderA* を使用して実行されるタスクごとに、4 つのタスクが *capacityProviderB* を使用します。 # AppSpec の「許可」セクション (EC2/オンプレミスデプロイのみ) `'permissions'` セクションでは、インスタンスへのコピー後に、特別なアクセス許可を `'files'` セクションのファイルおよびディレクトリ/フォルダに適用する方法を指定します。複数の `object` 指示を指定できます。このセクションはオプションです。Amazon Linux、Ubuntu Server、RHEL インスタンスにのみ適用されます。 **注記** EC2/オンプレミスデプロイにのみ、`'permissions'` セクションを使用します。Lambda または Amazon ECS AWS のデプロイには使用されません。 このセクションの構造は次のとおりです。 ``` 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 コマンド の構文に従います。 **重要** 値の先頭にゼロが含まれる場合は、ダブルクォートで囲むか、先頭のゼロを削除して 3 桁だけにする必要があります。 **注記** **u\$1x** の設定では、`mode` のような記号表記はサポートされていません。 例: + `mode: "0644"` は、オブジェクトの所有者に読み書きのアクセス権限 (6)、グループに対する読み取り専用アクセス許可 (4)、およびその他すべてのユーザーに読み取り専用アクセス権限 (4) を与えます。 + `mode: 644` と同じ権限を付与する `mode: "0644"`。 + `mode: 4755` は setuid 属性を設定し (4)、所有者にフルコントロール権限を与え (7)、グループに対する読み取りと実行の権限を付与し (5)、他のすべてのユーザーに読み取りと実行の権限を付与します (5)。 その他の例については、Linux の chmod コマンドのドキュメントを参照してください。 モードを指定しない場合、既存のすべてのモードが元のファイルに適用されます。それ以外の場合、フォルダ構造は、コピーオペレーションによって変更されません。 + `acls` - オプション。1 つ以上のアクセスコントロールリスト (ACL) エントリを表す文字列のリストが、`object` に適用されます。たとえば、**u:bob:rw** は、ユーザー **bob** の読み取りおよび書き込みアクセス権限を表します （その他の例については、Linux の `setfacl` コマンドドキュメントの ACL 入力形式の例を参照してください）。複数の ACL エントリを指定できます。`acls` を指定しない場合、既存のすべての ACL が元のファイルに適用されます。それ以外の場合、ディレクトリ/フォルダ構造は、コピーオペレーションによって変更されません。既存の ACL は置き換えられます。 `acls` を指定します。ダッシュ (-) の後にスペースを続け、その後に文字列を続けます（例: `- u:jane:rw`）。ACL が複数ある場合は、それぞれ個別の行で指定します。 **注記** 名前のないユーザー、名前のないグループ、またはその他の同様の ACL エントリを設定すると、AppSpec ファイルは失敗します。これらのタイプのアクセス許可を指定するには、代わりに `mode` を使用します。 + `context` - オプション。Security-Enhanced 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'` セクションには、デプロイライフサイクルイベントフックを 1 つ以上のスクリプトにリンクするマッピングが含まれます。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 の「フック」関数のサンプル](#reference-appspec-file-structure-hooks-section-structure-ecs-sample-function) ### Amazon ECS のデプロイ向けのライフサイクルイベントフックのリスト AWS Lambda フックは、ライフサイクルイベントの名前の後に新しい行に文字列で指定された 1 つの Lambda 関数です。各フックはデプロイごとに 1 回実行されます。以下は、Amazon ECS デプロイ中にフックを実行できるライフサイクルイベントの説明です。 + `BeforeInstall` 置き換えタスクセットが作成される前にタスクを実行するために使用します。1 つのターゲットグループが元のタスクセットに関連付けられています。オプションのテストリスナーが指定されている場合、それは元のタスクセットに関連付けられます。この時点で、ロールバックはできません。 + `AfterInstall` 置き換えタスクセットが作成され、ターゲットグループの 1 つがそれに関連付けられた後、タスクを実行するために使用します。オプションのテストリスナーが指定されている場合、それは元のタスクセットに関連付けられます。このライフサイクルイベントでのフック関数の結果により、ロールバックをトリガーできます。 + `AfterAllowTestTraffic` テストリスナーが置き換えタスクセットにトラフィックを提供した後、タスクを実行するために使用します。この時点でのフック関数の結果により、ロールバックをトリガーできます。 + `BeforeAllowTraffic` 2 番目のターゲットグループが置き換えタスクセットに関連付けられた後、かつ、トラフィックが置き換えタスクセットに移行される前に、タスクを実行するために使用します。このライフサイクルイベントでのフック関数の結果により、ロールバックをトリガーできます。 + `AfterAllowTraffic` 2 番目のターゲットグループが置き換えタスクセットにトラフィックを提供した後、タスクを実行するために使用します。このライフサイクルイベントでのフック関数の結果により、ロールバックをトリガーできます。 詳細については、「[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/ja_jp/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'` セクションを使用して、Amazon ECS のデプロイを検証するために CodeDeploy が呼び出すことができる Lambda 関数を指定します。`BeforeInstall`、`AfterInstall`、`AfterAllowTestTraffic`、`BeforeAllowTraffic`、および `AfterAllowTraffic` のデプロイライフサイクルイベントに対して、同じ関数または異なる関数を使用できます。検証テストが完了すると、Lambda `AfterAllowTraffic` 関数は CodeDeploy を呼び戻し、`Succeeded` または `Failed` の結果を配信します。 **重要** 1 時間以内に CodeDeploy が 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 の「フック」関数のサンプル](#reference-appspec-file-structure-hooks-section-structure-lambda-sample-function) ### AWS Lambda デプロイのライフサイクルイベントフックのリスト AWS Lambda フックは、ライフサイクルイベントの名前の後に新しい行に文字列で指定された 1 つの Lambda 関数です。各フックはデプロイごとに 1 回実行されます。以下は、AppSpec ファイルに使用できるフックの説明です。 + **BeforeAllowTraffic** – これを使用して、トラフィックがデプロイされた Lambda 関数のバージョンに移行する前にタスクを実行します。 + **AfterAllowTraffic** – これを使用して、トラフィックがデプロイされた Lambda 関数のバージョンに移行した後でタスクを実行します。 ### Lambda 関数のバージョンのデプロイでのフックの実行順 サーバーレスの Lambda 関数のバージョンのデプロイでは、イベントフックは次の順序で実行されます。 ![\[Lambda デプロイのイベントフックの順序。\]](http://docs.aws.amazon.com/ja_jp/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」セクションを使用して、Lambda のデプロイを検証するために CodeDeploy が呼び出すことができる Lambda 関数を指定します。`BeforeAllowTraffic` および `AfterAllowTraffic` デプロイライフサイクルイベントには、同じ関数または異なる関数を使用できます。検証テストが完了すると、Lambda 検証関数は CodeDeploy を呼び戻し、`Succeeded` または `Failed` の結果を配信します。 **重要** 1 時間以内に CodeDeploy が 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) + [hooks の例](#reference-appspec-file-structure-hooks-example) ### ライフサイクルイベントフックのリスト EC2/オンプレミスのデプロイのフックは、デプロイごとに 1 回インスタンスに対して実行されます。フックには実行するスクリプトを 1 つまたは複数指定することができます。ライフサイクルイベントの各フックは、文字列で個別の行に指定します。以下は、AppSpec ファイルに使用できるフックの説明です。 デプロイおよびロールバックの種類別の有効なライフサイクルフックの詳細については、「[ライフサイクルイベントフックの可用性](#reference-appspec-file-structure-hooks-availability)」を参照してください。 + `ApplicationStop` このデプロイライフサイクルイベントは、アプリケーションリビジョンがダウンロードされる前でも発生します。アプリケーションを適切に中止するか、現在インストールされているパッケージを削除してデプロイの準備をする場合は、このイベントのスクリプトを指定できます。このデプロイライフサイクルイベントに使用される AppSpec ファイルとスクリプトは、前回正常にデプロイされたアプリケーションリビジョンのものです。 **注記** AppSpec ファイルは、デプロイする前にはインスタンスに存在しません。したがって、`ApplicationStop` フックは、初めてインスタンスにデプロイするときは実行されません。インスタンスに 2 回目にデプロイするときは、`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` このデプロイライフサイクルイベント中に、CodeDeploy エージェントはアプリケーションリビジョンファイルを一時的な場所にコピーします。 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` デプロイライフサイクルイベント中に失敗するデプロイをトラブルシューティングするには、「[「不明なエラー: 読み取り用に開いていません」で失敗した 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 終了デプロイ¹ | インプレースデプロイ¹ | Blue/Green デプロイ: 元のインスタンス | Blue/Green デプロイ: 代替インスタンス | Blue/Green デプロイのロールバック: 元のインスタンス | Blue/Green デプロイのロールバック: 代替インスタンス | | --- | --- | --- | --- | --- | --- | --- | --- | | 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 は次の順序でイベントフックを実行します。 Auto Scaling 起動デプロイの詳細については、「[Amazon EC2 Auto Scaling と CodeDeploy の連携](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors)」を参照してください。 ![\[Auto Scaling 起動デプロイ時のイベントフックの順序。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/lifecycle-event-order-scale-out.png) **注記** デプロイの **Start**、**DownloadBundle**、**Install**、**AllowTraffic**、**End** の各イベントはスクリプト化できないため、この図ではグレーで表示されています。ただし、AppSpec ファイルの `'files'` セクションを編集して、**Install** イベント中にインストールされるものを指定できます。 **Auto Scaling 終了デプロイ** Auto Scaling 終了デプロイ中に、CodeDeploy は次の順序でイベントフックを実行します。 Auto Scaling 終了デプロイの詳細については、「[Auto Scaling スケールインイベント中の終了デプロイの有効化](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors-hook-enable)」を参照してください。 ![\[Auto Scaling 終了デプロイ時のイベントフックの順序。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/lifecycle-event-order-scale-in.png) **注記** デプロイの **Start**、**BlockTraffic**、**End** の各イベントはスクリプト化できないため、この図ではグレーで表示されています。 **インプレースデプロイ** インプレースデプロイのロールバックを含むインプレースデプロイで、イベントフックは次の順序で実行されます。 **注記** インプレースデプロイの場合、トラフィックのブロックと許可に関する 6 つのフックは、 デプロイグループに Elastic Load Balancing から Classic Load Balancer、Application Load Balancer、または Network Load Balancer を指定した場合のみ適用されます。 ![\[インプレースデプロイのロールバック時のイベントフックの順序。\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/lifecycle-event-order-in-place.png) **注記** デプロイの **Start**、**DownloadBundle**、**Install**、および **End** イベントはスクリプト化できないため、この図ではグレーで表示されています。ただし、AppSpec ファイルの `'files'` セクションを編集して、**Install** イベント中にインストールされるものを指定できます。 **Blue/Green デプロイ** Blue/Green デプロイでは、イベントフックは次の順序で実行されます。 ![\[ブルー/グリーンデプロイのイベントフックの順序。\]](http://docs.aws.amazon.com/ja_jp/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 の「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 の「ファイル」セクション (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 サーバー — すべての deb ディストリビューション | /opt/codedeploy-agent/deployment-root | | Windows サーバー | %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/ja_jp/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html) ### フックの環境変数の可用性 各デプロイライフサイクルイベントの間、フックスクリプトは次の環境変数にアクセスできます。 ** APPLICATION\$1NAME ** 現在のデプロイの一部である CodeDeploy のアプリケーションの名前 (`WordPress_App` など)。 ** DEPLOYMENT\$1ID ** CodeDeploy が、現在のデプロイに割り当てられた ID (例えば、`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() ``` ### hooks の例 **hooks** エントリの例を次に示します。`AfterInstall` ライフサイクルイベントに 2 つのフックを指定しています。 ``` hooks: AfterInstall: - location: Scripts/RunResourceTests.sh timeout: 180 - location: Scripts/PostDeploy.sh timeout: 180 ``` デプロイプロセスの `AfterInstall` ステージ中に、`Scripts/RunResourceTests.sh` スクリプトが実行されます。スクリプトの実行に 180 秒 (3 分) 以上かかる場合、デプロイは成功しません。 「hooks」セクションで指定するスクリプトの場所は、アプリケーションリビジョンバンドルのルートに相対的な位置です。前述の例では、`RunResourceTests.sh` という名前のファイルが `Scripts` という名前のディレクトリにあります。`Scripts` ディレクトリはバンドルのルートレベルにあります。詳細については、「[CodeDeploy のリビジョンを計画する](application-revisions-plan.md)」を参照してください。