AWS CodeDeploy のよくある質問

アプリケーションとは、1 つのインスタンスグループにデプロイするソフトウェアおよび設定の集合体です。基本的に、同じグループのインスタンスは同じソフトウェアを実行しています。たとえば、大規模な配信システムを使用している場合、たいていはウェブ層が 1 つのアプリケーションを構成し、データ層は別のアプリケーションを構成しています。

リビジョンとはソースコード、ポストビルドアーティファクト、ウェブページ、実行ファイル、デプロイスクリプト、AppSpec ファイルなどのデプロイコンテンツの特定のバージョンです。AWS CodeDeploy エージェントは GitHub または Amazon S3 バケットからリビジョンにアクセスできます。

デプロイグループは、CodeDeploy のデプロイにおける EC2 インスタンスまはた AWS Lambda 機能をグループ化するための AWS CodeDeploy エンティティです。EC2 デプロイでは、デプロイグループはアプリケーションに関連するインスタンスの集合体で、デプロイのターゲットとなります。タグまたは Auto Scaling グループ名、またはその両方を指定して、インスタンスをデプロイグループに追加します。AWS Lambda デプロイでは、デプロイグループはアラームやロールバックなど、将来のサーバーレス Lambda デプロイグループのための AWS CodeDeploy の構成のセットとして定義されます。

ステージングや実稼働など、1 つのアプリケーションに対して複数のデプロイグループを定義できます。タグについての情報は「コンソールでの Amazon EC2 タグの使用」をご覧ください。Auto Scaling グループに対するデプロイについての情報は、「自動スケーリングの統合」をご覧ください。

デプロイ設定では、デプロイエラーの扱い方など、デプロイグループを通してどのようなビヘイビアーでデプロイが実行されるべきかを指定します。デプロイ設定を使用して、複数インスタンスのデプロイグループにダウンタイムゼロのデプロイを実行できます。例えば、アプリケーションに対して、デプロイグループ内のインスタンスの最低 50% が起動したままでトラフィックを提供する必要がある場合、デプロイ設定でそのように指定し、デプロイがダウンタイムを発生させないようにできます。デプロイ設定がデプロイにもデプロイグループにも関連付けられていない場合、AWS CodeDeploy はデフォルトで 1 度に 1 つのインスタンスにデプロイします。 デプロイ設定についての詳しい情報は、「インスタンスの状態」をご覧ください。

デプロイのために指定するパラメーターは 3 つあります。

1. リビジョン – 何をデプロイするか指定します。
2. デプロイグループ – どこにデプロイするか指定します。
3. デプロイ設定 – デプロイ方法を指定する任意のパラメータです。

AppSpec ファイルとは、コピーするファイルおよび実行するスクリプトを指定する設定ファイルです。AppSpec ファイルは YAML フォーマットを使用しており、リビジョンのルートディレクトリに含める必要があります。AppSpec ファイルは AWS CodeDeploy に使用され、2 つのセクションで構成されています。ファイルセクションは、リビジョンの中のコピーされるソースファイル、および各インスタンスの送信先フォルダを指定します。フックセクションはデプロイの各段階で実行するスクリプトのロケーション (リビジョンバンドルのルートから始まる相対パス) を指定します。デプロイの各段階は、デプロイのライフサイクルイベントと呼ばれます。AppSpec ファイルの例を次に示します。指定できるすべてのオプションなど、AppSpec ファイルについて詳しくは、AppSpec ファイルのリファレンスをご覧ください。

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

  • 基本的に、このデプロイのライフサイクルイベントは ApplicationStop で停止したサービスを再起動するために使用します。

• ValidateService

  • ValidateService は最後のデプロイのライフサイクルイベントであり、デプロイが正常に完了したことを検証します。

 

 

AWS マネジメントコンソールにサインインすれば AWS CodeDeploy の利用を開始できます。サービスの概要を簡単に確認するには、手順を追ったチュートリアルをご利用できる「ご利用開始にあたって」をご覧ください。

Amazon EC2 インスタンスが IAM インスタンスプロファイルに関連付けられており、サポートされているオペレーティングシステムを実行している必要があります。詳しくは、「既存の Amazon EC2 の使用」をご覧ください。

以下のダイアグラムはデプロイ中の基本的な手順を説明しています。アプリケーションおよびデプロイグループの作成（これらの用語の説明は「概念」のセクションをご覧ください）は、基本的に各アプリケーションにつき 1 度限りのタスクです。定期的なアクションによりリビジョンがアップロードおよびデプロイされます。各タスクの手順を追った指示など、詳しい説明は「デプロイ」をご覧ください。

AWS CodeDeploy には AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI)、AWS SDK、AWS CodeDeploy API を使用してアクセスできます。

コードを変更する必要はまったくありません。設定ファイル (AppSpec ファイル) を、コピーするファイルおよび実行するスクリプトを指定するリビジョンバンドルのルートディレクトリに追加するだけです。

GitHub を使用している場合、.zip、.tar、.tar.gz 形式でリポジトリから直接インスタンスにリビジョンをデプロイできます。その他のソースコントロールシステムを使用している場合は、リビジョンをバンドルして .zip、.tar、.tar.gz 形式で Amazon S3 バケットにアップロードし、デプロイの実行時に Amazon S3 のロケーションを指定します。アプリケーションにビルドステップが必要な場合は、GitHub リポジトリまたは Amazon S3 バケットにポストビルドアーティファクトが保存されていることを確認してください。AWS CodeDeploy での GitHub の使用に関してより詳しくは、製品の統合ページをご覧ください。Amazon S3 を使用したリビジョンの保存に関して詳しくは、リビジョンの送信をご覧ください。

AppSpec ファイルの任意のデプロイのライフサイクルイベントフックから設定管理ツールを起動できます。たとえば、デプロイの一環として実行する Chef レシピがある場合は、AppSpec ファイルの適切なデプロイのライフサイクルイベントフックでレシピを指定できます。さらに、設定管理システムを利用して AWS CodeDeploy エージェントをインスタンスにインストールすることもできます。AWS CodeDeploy と Chef、Puppet、Ansible、Saltstack などの設定管理システムを合わせて使用する方法を説明したサンプルは、製品の統合ページをご覧ください。

はい。AWS CLI または AWS SDK を使用してパブリック API を呼び出すことで、AWS CodeDeploy を継続統合およびデプロイシステムと統合できます。事前に構築された統合およびサンプルを製品の統合ページで確認できます。

該当するインスタンスのデプロイグループに、最新のリビジョンをデプロイすることで、アプリケーションをデプロイします。Auto Scaling group の一部として開始したインスタンスを除き、AWS CodeDeploy は新しく追加された Amazon EC2 インスタンスに対して、最新のリビジョンを自動でデプロイしません。

Auto Scaling Group をデプロイグループと関連付けることで、新しく開始したインスタンスに常にアプリケーションの最新のリビジョンがデプロイされるようにできます。Auto Scaling Group に新しい Amazon EC2 インスタンスが追加されるたびに、まず状態が Pending になり、前回デプロイグループで成功したリビジョンのデプロイが新しい Amazon EC2 インスタンスに対して開始されます。デプロイが正常に完了すると、Amazon EC2 インスタンスの状態が InService に変更されます。デプロイに失敗した場合、その Amazon EC2 インスタンスは終了し、新しい Amazon EC2 インスタンスが Pending の状態で開始されます。その後新しい Amazon EC2 インスタンスに対してデプロイが開始されます。Auto Scaling Group インスタンスのライフサイクルイベントに関して詳しくは、「Auto Scaling グループのライフサイクル」をご覧ください。

デプロイのステータスの追跡には AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI)、AWS SDK、AWS CodeDeploy API を使用できます。デプロイの全体的なステータスを確認し、さらにドリルダウンして各インスタンスのステータスと、インスタンスの各デプロイライフサイクルイベントのステータスを確認できます。また、失敗に対応するログエントリも確認できるため、インスタンスにログインする必要がなく、デプロイの問題のデバッグが容易になります。

はい。実行中のデプロイを停止する場合、AWS CodeDeploy サービスは各インスタンスのエージェントにそれ以上のスクリプトを実行しないように指示します。アプリケーションを矛盾のない状態に戻すには同じリビジョンを再デプロイするか、別のリビジョンをデプロイします。

過去のリビジョンにアプリケーションをロールバックするには、そのリビジョンをデプロイするだけです。AWS CodeDeploy は現在のリビジョン用にコピーされたファイルを追跡しており、新しいデプロイの開始前にはそれらを削除します。そのため、再デプロイとロールバックに違いはありません。ただし、過去のリビジョンがロールバックに適切であることを確認する必要があります。

はい。バージョニングした Amazon S3 バケットを使用し、バージョン ID を指定して単一のリビジョンを特定できます。

サービスの上限についての詳細は、制限を参照してください。サービスの上限を引き上げるには、AWS サポートセンターからリクエストを送信してください。

はい。自分のアカウントで呼び出した AWS CodeDeploy API の履歴を取得するには、AWS マネジメントコンソールで 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 を使用したアップデートの料金は、1 つのオンプレミスインスタンスあたり 0.02 USD です。詳細については、料金ページを参照してください。