

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# チュートリアル: Amazon EC2 インスタンスに WordPress をデプロイする (Amazon Linux または Red Hat エンタープライズ Linux および Linux、macOS、または Unix)
<a name="tutorials-wordpress"></a>

このチュートリアルでは、PHP および MySQL に基づくオープンソースのブログツールおよびコンテンツ管理システムである WordPress を、Amazon Linux または Red Hat Enterprise Linux (RHEL) を実行している 1 つの Amazon EC2 インスタンスにデプロイします。

お探しのものではありませんか。
+ 代わりに Windows Server を実行している Amazon EC2 インスタンスへのデプロイの演習を行う場合は、「[チュートリアル: 「Hello, World\$1」 CodeDeploy を使用したアプリケーション (Windows Server)](tutorials-windows.md)」を参照してください。
+ Amazon EC2 インスタンスではなくオンプレミスインスタンスへのデプロイの演習を行う場合は、「[チュートリアル: CodeDeploy (Windows サーバー、Ubuntu サーバー、または Red Hat エンタープライズ Linux) を使用してオンプレミスインスタンスにアプリケーションをデプロイします。](tutorials-on-premises-instance.md)」を参照してください。

このチュートリアルのステップは、Linux や macOS、Unix を実行しているローカルの開発用マシンの観点から説明されています。Windows を実行しているローカルマシンでこれらのステップのほとんどを完了できますが、**chmod** や **wget** などのコマンド、sed などのアプリケーション、および `/tmp` などのディレクトリパスを扱うステップは環境に合わせて変更する必要があります。

このチュートリアルを開始する前に、「[CodeDeploy の開始方法](getting-started-codedeploy.md)」の前提条件を完了している必要があります。これには、ユーザーの設定、 のインストールまたはアップグレード AWS CLI、IAM インスタンスプロファイルとサービスロールの作成が含まれます。

**Topics**
+ [ステップ 1: Amazon Linux または Red Hat エンタープライズ Linux Amazon EC2 インスタンスを起動して設定する](tutorials-wordpress-launch-instance.md)
+ [ステップ 2: Amazon Linux または Red Hat エンタープライズ Linux Amazon EC2 インスタンスにデプロイされるようにソースコンテンツを設定する](tutorials-wordpress-configure-content.md)
+ [ステップ 3: Amazon S3 に WordPress アプリケーションをアップロードする](tutorials-wordpress-upload-application.md)
+ [ステップ 4: WordPress アプリケーションをデプロイする](tutorials-wordpress-deploy-application.md)
+ [ステップ 5: WordPress アプリケーションを更新して再デプロイする](tutorials-wordpress-update-and-redeploy-application.md)
+ [ステップ 6: WordPress のアプリケーションと関連リソースのクリーンアップ](tutorials-wordpress-clean-up.md)

# ステップ 1: Amazon Linux または Red Hat エンタープライズ Linux Amazon EC2 インスタンスを起動して設定する
<a name="tutorials-wordpress-launch-instance"></a>

CodeDeploy を使用して WordPress アプリケーションをデプロイするには、Amazon Linux または Red Hat Enterprise Linux (RHEL) を実行する Amazon EC2 インスタンスが必要です。Amazon EC2 インスタンスでは、HTTP 接続を許可する新しいインバウンドセキュリティルールが必要です。このルールは、正しくデプロイした後で WordPress ページをブラウザで表示するために必要です。

「[CodeDeploy のための Amazon EC2 インスタンスを作成します。](instances-ec2-create.md)」の手順に従います インスタンスの Amazon EC2 インスタンスタグの割り当てに関するこれらの指示の一部を実行する際には、必ず **Name** のタグキーと、**CodeDeployDemo** のタグ値を指定します。(別のタグキーまたはタグ値を指定した場合、[ステップ 4: WordPress アプリケーションをデプロイする](tutorials-wordpress-deploy-application.md) の手順で予期しない結果が生成される場合があります)。

Amazon EC2 インスタンスを起動する手順に従った後、このページに戻り、次のセクションに進みます。次のステップとして、[CodeDeploy でアプリケーションを作成する](applications-create.md) には進まないでください。

## Amazon Linux と RHEL Amazon EC2 インスタンスに接続します
<a name="tutorials-wordpress-launch-instance-connect"></a>

Amazon EC2 インスタンスが起動した後、手順に従ってインスタンスに接続する演習をします。

1. **ssh** コマンド (または SSH 対応の [PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html) などのターミナルエミュレータ) を使用して Amazon Linux または RHEL Amazon EC2 インスタンスに接続します。Amazon EC2 インスタンスを開始した時に使用したインスタンスのパブリック DNS アドレスとキーペアのプライベートキーが必要になります。詳細については、「[インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html)」を参照してください。

   例えば、パブリック DNS アドレスが **ec2-01-234-567-890.compute-1.amazonaws.com** で、SSH アクセスの Amazon EC2 インスタンスキーペアが **codedeploydemo.pem** という名前の場合、以下のように入力します。

   ```
   ssh -i /path/to/codedeploydemo.pem ec2-user@ec2-01-234-567-890.compute-1.amazonaws.com
   ```

   `/path/to/codedeploydemo.pem` を `.pem` ファイルのパスに置き換え、例の DNS アドレスを Amazon Linux または RHEL Amazon EC2 インスタンスのアドレスと置き換えます。
**注記**  
キーファイルのアクセス権限がオープンすぎるというエラーを受信した場合は、現在のユーザー (お客様) だけにアクセス権限を与えるように限定する必要があります。例えば、**chmod** Linux、macOS、または UNIX の場合は、次のように入力します。

   ```
   chmod 400 /path/to/codedeploydemo.pem
   ```

1. サインインしたら、Amazon EC2 インスタンスについては、AMI のバナーを参照してください。Amazon Linux の場合は、次のようになります。

   ```
          __|  __|_  )
          _|  (     /   Amazon Linux AMI
         ___|\___|___|
   ```

1. 実行中の Amazon EC2 インスタンスからサインアウトできます。
**警告**  
Amazon EC2 インスタンスを停止または削除しないでください。そうしないと、CodeDeploy がインスタンスにデプロイできません。

## HTTP トラフィックを許可するインバウンドルールの Amazon Linux または RHEL Amazon EC2 インスタンスへの追加
<a name="tutorials-wordpress-launch-instance-add-inbound-rule"></a>

次のステップでは、デプロイされた WordPress アプリケーションのホームページがブラウザに表示されるように、Amazon EC2 インスタンスに開いている HTTP ポートがあることを確認します。

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。

1. **インスタンス** を選択後、ご自分のインスタンスを選択します。

1. **セキュリティグループ** 内の **説明** タブで、**インバウンドのルールの表示** を選択します。

   セキュリティグループのルールの一覧は、次のように表示されます。

   ```
   Security Groups associated with i-1234567890abcdef0
    Ports     Protocol     Source     launch-wizard-N
    22        tcp          0.0.0.0/0          ✔
   ```

1.  **セキュリティグループ** では、Amazon EC2 インスタンスのセキュリティグループを選択します。**launch-wizard-*N*** と名前が付けられる可能性があります。***N*** は、インスタンスの作成時にセキュリティグループに割り当てられた名前です。

    **[Inbound]** (インバウンド) タブを選択します。次の値を持つルールが表示された場合、ご利用のインスタンスのセキュリティグループは正しく設定されています。
   + [**Type**]: HTTP
   + [**Protocol**]: TCP
   + **[Port Range**]: 80
   + **ソース**: 0.0.0.0/0

1.  これらの値を持つルールが表示されない場合は、[セキュリティグループへのルールの追加](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) の手順を使用して、新しいセキュリティルールに追加します。

# ステップ 2: Amazon Linux または Red Hat エンタープライズ Linux Amazon EC2 インスタンスにデプロイされるようにソースコンテンツを設定する
<a name="tutorials-wordpress-configure-content"></a>

ここでは、アプリケーションのソースコンテンツを設定し、インスタンスにデプロイできるものを用意します。

**Topics**
+ [ソースコードの入手](#tutorials-wordpress-configure-content-download-code)
+ [アプリケーションを実行するスクリプトの作成](#tutorials-wordpress-configure-content-create-scripts)
+ [アプリケーション仕様ファイルの追加](#tutorials-wordpress-configure-content-add-appspec-file)

## ソースコードの入手
<a name="tutorials-wordpress-configure-content-download-code"></a>

このチュートリアルでは、開発マシンからターゲット Amazon EC2 インスタンスに WordPress コンテンツ発行プラットフォームをデプロイします。WordPress のソースコードを入手するには、組み込みのコマンドラインの呼び出しを使用できます。または、開発マシンに Git をインストールしている場合は、代わりにそれを使用します。

これらのステップでは、WordPress ソースコードのコピーを開発マシンの `/tmp` ディレクトリにダウンロードすることを前提としています (任意のディレクトリを選択できますが、ステップで `/tmp` が指定されている場合は、その場所に必ず置き換えてください)。

次の 2 つのオプションのいずれかを選択して、開発マシンに WordPress ソースファイルをコピーします。最初のオプションでは、組み込みのコマンドラインの呼び出しを使用します。2 番目のオプションでは、Git を使用します。

**Topics**
+ [WordPress のソースコード (組み込みのコマンドライン呼び出し) のコピーを入手するには](#tutorials-wordpress-configure-content-download-code-command-line)
+ [WordPress ソースコード (Git) のコピーを入手するには](#tutorials-wordpress-configure-content-download-code-git)

### WordPress のソースコード (組み込みのコマンドライン呼び出し) のコピーを入手するには
<a name="tutorials-wordpress-configure-content-download-code-command-line"></a>

1. **wget** コマンドを呼び出して、WordPress のソースコードのコピーを .zip ファイル形式で現在のディレクトリにダウンロードします。

   ```
   wget https://github.com/WordPress/WordPress/archive/master.zip
   ```

1. **unzip**、**mkdir**、**cp**、**rm** コマンドを呼び出して、以下を実行します。
   + `master`.zip ファイルを `/tmp/WordPress_Temp` ディレクトリ (フォルダ) に解凍します。
   + 解凍された内容を、`/tmp/WordPress` 宛先フォルダにコピーします。
   + 一時的な `/tmp/WordPress_Temp` フォルダと `master` ファイルを削除します。

   コマンドを一度に 1 つずつ実行します。

   ```
   unzip master -d /tmp/WordPress_Temp
   ```

   ```
   mkdir -p /tmp/WordPress
   ```

   ```
   cp -paf /tmp/WordPress_Temp/WordPress-master/* /tmp/WordPress
   ```

   ```
   rm -rf /tmp/WordPress_Temp
   ```

   ```
   rm -f master
   ```

   これにより、`/tmp/WordPress` フォルダに WordPress ソースコードファイルのクリーンなセットが配置されます。

### WordPress ソースコード (Git) のコピーを入手するには
<a name="tutorials-wordpress-configure-content-download-code-git"></a>

1. 開発マシンで [Git](http://git-scm.com) をダウンロードしてインストールします。

1. `/tmp/WordPress` フォルダで **git init** コマンドを呼び出します。

1. **git clone** コマンドを呼び出してパブリック WordPress レポジトリのクローンを作成し、その独自のコピーを `/tmp/WordPress` 宛先フォルダで作成します。

   ```
   git clone https://github.com/WordPress/WordPress.git /tmp/WordPress
   ```

   これにより、`/tmp/WordPress` フォルダに WordPress ソースコードファイルのクリーンなセットが配置されます。

## アプリケーションを実行するスクリプトの作成
<a name="tutorials-wordpress-configure-content-create-scripts"></a>

次に、ディレクトリでフォルダとスクリプトを作成します。CodeDeploy はこれらのスクリプトを使用して、ターゲット Amazon EC2 インスタンスでアプリケーションリビジョンをセットアップし、デプロイします。スクリプトの作成には任意のテキストエディタを使用できます。

1. WordPress ソースコードのコピーでスクリプトディレクトリを作成します。

   ```
   mkdir -p /tmp/WordPress/scripts
   ```

1. `install_dependencies.sh` に `/tmp/WordPress/scripts` ファイルを作成します。ファイルに以下の行を追加します。この `install_dependencies.sh` スクリプトは Apache、MySQL、および PHP をインストールします。また、PHP に MySQL のサポートを追加します。

   ```
   #!/bin/bash
   sudo amazon-linux-extras install php7.4
   sudo yum install -y httpd mariadb-server php
   ```

1. `start_server.sh` に `/tmp/WordPress/scripts` ファイルを作成します。ファイルに以下の行を追加します。この `start_server.sh` スクリプトは Apache および MySQL を起動します。

   ```
   #!/bin/bash
   systemctl start mariadb.service
   systemctl start httpd.service
   systemctl start php-fpm.service
   ```

1. `stop_server.sh` に `/tmp/WordPress/scripts` ファイルを作成します。ファイルに以下の行を追加します。この `stop_server.sh` スクリプトは Apache および MySQL を停止します。

   ```
   #!/bin/bash
   isExistApp="pgrep httpd"
   if [[ -n $isExistApp ]]; then
   systemctl stop httpd.service
   fi
   isExistApp=pgrep mysqld
   if [[ -n $isExistApp ]]; then
   systemctl stop mariadb.service
   fi
   isExistApp=pgrep php-fpm
   if [[ -n $isExistApp ]]; then
   systemctl stop php-fpm.service
   
   fi
   ```

1. `create_test_db.sh` に `/tmp/WordPress/scripts` ファイルを作成します。ファイルに以下の行を追加します。この `create_test_db.sh` スクリプトは、MySQL を使用して、WordPress で使用する **test** データベースを作成します。

   ```
   #!/bin/bash
   mysql -uroot <<CREATE_TEST_DB
   CREATE DATABASE IF NOT EXISTS test;
   CREATE_TEST_DB
   ```

1. 最後に、`/tmp/WordPress/scripts` に `change_permissions.sh` スクリプトファイルを作成します。これは Apache のフォルダのアクセス権限を変更するために使用されます。
**重要**  
 このスクリプトにより、誰でも書き込めるように、`/tmp/WordPress` フォルダのアクセス権限が更新されました。これは、「[ステップ 5: WordPress アプリケーションを更新して再デプロイする](tutorials-wordpress-update-and-redeploy-application.md)」で WordPress がそのデータベースに書き込みを行うために必要です。WordPress アプリケーションがセットアップされたら、次のコマンドを実行して、アクセス権限をよりセキュアな設定に更新します。  

   ```
   chmod -R 755 /var/www/html/WordPress
   ```

   ```
   #!/bin/bash
   chmod -R 777 /var/www/html/WordPress
   ```

1. すべてのスクリプトに実行可能権限を付与します。コマンドラインで、次のように入力します。

   ```
   chmod +x /tmp/WordPress/scripts/*
   ```

## アプリケーション仕様ファイルの追加
<a name="tutorials-wordpress-configure-content-add-appspec-file"></a>

次に、アプリケーション仕様ファイル (AppSpec ファイル) [YAML](http://www.yaml.org) CodeDeploy によって使用されるフォーマットされたファイルを追加します。
+ アプリケーションリビジョンのソースファイルを、ターゲット Amazon EC2 インスタンスの宛先にマッピングする。
+ デプロイされたファイルのカスタムアクセス権限を指定する。
+ デプロイ中にターゲット Amazon EC2 インスタンスで実行するスクリプトを指定する。

AppSpec のファイル名は、`appspec.yml` とする必要があります。アプリケーションソースコードのルートディレクトリに配置する必要があります。このチュートリアルでは、ルートディレクトリは `/tmp/WordPress` です。

テキストエディタで `appspec.yml` という名前のファイルを作成します。このファイルに次の行を追加します。

```
version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html/WordPress
hooks:
  BeforeInstall:
    - location: scripts/install_dependencies.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: scripts/change_permissions.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
    - location: scripts/create_test_db.sh
      timeout: 300
      runas: root
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 300
      runas: root
```

CodeDeploy はこの AppSpec ファイルを使用して、開発マシンの `/tmp/WordPress` フォルダのすべてのファイルを、ターゲットの Amazon EC2 インスタンスの `/var/www/html/WordPress` フォルダにコピーします。デプロイ中に CodeDeploy は、デプロイライフサイクルで `root` や `/var/www/html/WordPress/scripts` などの中に指定されたイベントで、指定するスクリプトをターゲットの Amazon EC2 インスタンスの **BeforeInstall**、**AfterInstall** のフォルダとして実行します。これらのスクリプトのいずれかで実行に 300 秒 (5 分) 以上かかる場合、CodeDeploy はデプロイを停止し、デプロイを失敗としてマークします。

これらの設定の詳細については、「[CodeDeploy AppSpec ファイルのリファレンス](reference-appspec-file.md)」を参照してください。

**重要**  
このファイルの項目間のスペースの場所と数は重要です。間隔が正しくない場合、CodeDeploy はデバッグが困難な可能性のあるエラーを発生させます。詳細については、「[AppSpec ファイルの間隔](reference-appspec-file.md#reference-appspec-file-spacing)」を参照してください。

# ステップ 3: Amazon S3 に WordPress アプリケーションをアップロードする
<a name="tutorials-wordpress-upload-application"></a>

ここでソースコンテンツを CodeDeploy がデプロイできる場所に準備してアップロードします。次の手順では、Amazon S3 バケットをプロビジョニングしてバケット用のアプリケーションリビジョンのファイルを準備し、リビジョンのファイルをバンドルしてから、そのリビジョンをバケットにプッシュする方法を示します。

**注記**  
このチュートリアルでは説明されていませんが、CodeDeploy を使用して GitHub リポジトリからインスタンスにアプリケーションをデプロイできます。詳細については、「[GitHub と CodeDeploy との統合](integrations-partners-github.md)」を参照してください。

**Topics**
+ [Amazon S3 バケットをプロビジョニングします](#tutorials-wordpress-upload-application-create-s3-bucket)
+ [バケットのアプリケーションファイルを準備する](#tutorials-wordpress-upload-application-prepare-application-files)
+ [アプリケーションのファイルを 1 つのアーカイブファイルにバンドルし、アーカイブファイルをプッシュする](#tutorials-wordpress-upload-application-bundle-and-push-archive)

## Amazon S3 バケットをプロビジョニングします
<a name="tutorials-wordpress-upload-application-create-s3-bucket"></a>

ストレージコンテナあるいは Amazon S3 *バケット* を作成、または既存のバケットを使用します。バケットにリビジョンをアップロードできること、およびデプロイで使用する Amazon EC2 インスタンスがバケットからリビジョンをダウンロードできることを確認します。

 AWS CLI、Amazon S3 コンソール、または Amazon S3 APIs を使用してAmazon S3バケットを作成できます。バケットを作成したら、バケットとその AWS アクセス許可を付与します。

**注記**  
バケット名は、すべての AWS アカウントで Amazon S3 全体で一意である必要があります。**amzn-s3-demo-bucket** を使用できない場合、**amzn-s3-demo-bucket** の後にダッシュと自分の名前のイニシャル、または他の一意な識別子など別のバケット名を試してください。このチュートリアル全体で、バケット名を **amzn-s3-demo-bucket** に置き換えます。  
Amazon S3 バケットは、ターゲット Amazon EC2 インスタンスが起動されるのと同じ AWS リージョンに作成する必要があります。例えば、バケットを米国東部 (バージニア北部) リージョンで作成する場合、対象の Amazon EC2 インスタンスを米国東部 (バージニア北部) リージョンで起動する必要があります。

**Topics**
+ [Amazon S3 バケット (CLI) の作成](#tutorials-wordpress-upload-application-create-s3-bucket-cli)
+ [Amazon S3 バケット (コンソール) の作成](#tutorials-wordpress-upload-application-create-s3-bucket-console)
+ [Amazon S3 バケットと AWS アカウントにアクセス許可を付与する](#tutorials-wordpress-upload-application-create-s3-bucket-grant-permissions)

### Amazon S3 バケット (CLI) の作成
<a name="tutorials-wordpress-upload-application-create-s3-bucket-cli"></a>

**mb** コマンドを呼び出して、**amzn-s3-demo-bucket** という名前の Amazon S3 バケットを作成します。

```
aws s3 mb s3://amzn-s3-demo-bucket --region region
```

### Amazon S3 バケット (コンソール) の作成
<a name="tutorials-wordpress-upload-application-create-s3-bucket-console"></a>

1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。

1. Amazon S3 コンソールで [**バケットの作成**] を選択します。

1. [**Bucket name**] ボックスで、バケットの名前を入力します。

1. [**Region**] リストで、ターゲットリージョンを選択し、[**Create**] を選択します。

### Amazon S3 バケットと AWS アカウントにアクセス許可を付与する
<a name="tutorials-wordpress-upload-application-create-s3-bucket-grant-permissions"></a>

Amazon S3 バケットへのアップロードには、許可が必要です。Amazon S3 バケットポリシーで、これらのアクセス許可を指定できます。たとえば、次の Amazon S3 バケットポリシーでは、ワイルドカード文字 (\$1) を使用すると、 AWS アカウント`111122223333`は という名前の Amazon S3 バケット内の任意のディレクトリにファイルをアップロードできます`amzn-s3-demo-bucket`。

```
{
    "Statement": [
        {
            "Action": [
                "s3:PutObject"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
            "Principal": {
                "AWS": [
                    "111122223333"
                ]
            }
        }
    ]
}
```

 AWS アカウント ID を表示するには、[AWS 「アカウント ID の検索](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html#FindingYourAWSId)」を参照してください。

今は、Amazon S3 バケットが参加している各 Amazon EC2 インスタンスからのダウンロードリクエストを許可していることを確認するのに適した時期です。Amazon S3 バケットポリシーで、これを指定できます。例えば、次の Amazon S3 バケットポリシーでは、ワイルドカード文字 (\$1) を使用すると、ARN `arn:aws:iam::444455556666:role/CodeDeployDemo` を含む IAM インスタンスプロファイルがアタッチされた Amazon EC2 インスタンスが、`amzn-s3-demo-bucket` という名前の Amazon S3 バケットの任意のディレクトリからファイルをダウンロードすることを許可します。

```
{
    "Statement": [
        {
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::444455556666:role/CodeDeployDemo"
                ]
            }
        }
    ]
}
```

 Amazon S3 バケットポリシーを生成しアタッチする方法の詳細については、「[バケットポリシーの例](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html)」を参照してください。

IAM ポリシーを作成しアタッチする方法については、「[ポリシーの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingPolicies.html#AddingPermissions_Console)」を参照してください。

## バケットのアプリケーションファイルを準備する
<a name="tutorials-wordpress-upload-application-prepare-application-files"></a>

WordPress アプリケーションファイル、 およびスクリプトが、次のような開発用マシンで構成されることを確認します。

```
/tmp/
  |--WordPress/
      |-- appspec.yml  
      |-- scripts/
      |    |-- change_permissions.sh
      |    |-- create_test_db.sh
      |    |-- install_dependencies.sh
      |    |-- start_server.sh
      |    |-- stop_server.sh
      |-- wp-admin/
      |    |-- (various files...)
      |-- wp-content/
      |    |-- (various files...)
      |-- wp-includes/
      |    |-- (various files...)
      |-- index.php
      |-- license.txt
      |-- readme.html
      |-- (various files ending with .php...)
```

## アプリケーションのファイルを 1 つのアーカイブファイルにバンドルし、アーカイブファイルをプッシュする
<a name="tutorials-wordpress-upload-application-bundle-and-push-archive"></a>

WordPress アプリケーションファイルと をアーカイブファイル (アプリケーション *リビジョン* と呼ばれる) にバンドルします。

**注記**  
バケットにオブジェクトを保存したり、バケットの内外にアプリケーションのリビジョンを転送したりする場合に課金されることがあります。詳細については、「[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)」を参照してください。

1. 開発マシンで、ファイルが保存されたフォルダに切り替えます。

   ```
   cd /tmp/WordPress
   ```
**注記**  
このフォルダに切替わらなければ、ファイルのバンドルは現在のフォルダで起動されます。例えば、現在のフォルダが `/tmp` ではなく `/tmp/WordPress` である場合、バンドルは、`tmp` サブフォルダ以上を含む可能性のある `WordPress` フォルダ内のファイルとサブフォルダから開始します。

1. **create-application** コマンドを呼び出して、**WordPress\$1App** という名前の新しいアプリケーションを登録します。

   ```
   aws deploy create-application --application-name WordPress_App
   ```

1. CodeDeploy で [push](https://docs.aws.amazon.com/cli/latest/reference/deploy/push.html) コマンドを呼び出してファイルをまとめてバンドルし、Amazon S3 にリビジョンをアップロードし、アップロードされたリビジョンに関する情報を 1 つの操作で CodeDeploy に登録します。

   ```
   aws deploy push \
     --application-name WordPress_App \
     --s3-location s3://amzn-s3-demo-bucket/WordPressApp.zip \
     --ignore-hidden-files
   ```

   このコマンドは、現在のディレクトリ (隠しファイルを除く) から、**WordPressApp.zip** という名前の 1 つのアーカイブファイルにファイルをバンドルし、リビジョンを **amzn-s3-demo-bucket** バケットにアップロードし、CodeDeploy でアップロードしたリビジョンについての情報を登録します。

# ステップ 4: WordPress アプリケーションをデプロイする
<a name="tutorials-wordpress-deploy-application"></a>

ここで、Amazon S3 にアップロードしたサンプルの WordPress アプリケーションリビジョンをデプロイします。 AWS CLI または CodeDeploy コンソールを使用してリビジョンをデプロイし、デプロイの進行状況をモニタリングできます。アプリケーションリビジョンが正常にデプロイされた後に、その結果を確認します。

**Topics**
+ [CodeDeploy を使用して、アプリケーションリビジョンをデプロイします](#tutorials-wordpress-deploy-application-create-deployment)
+ [デプロイをモニタリングおよびトラブルシューティングします。](#tutorials-wordpress-deploy-application-monitor)
+ [デプロイの確認](#tutorials-wordpress-deploy-application-verify-deployment)

## CodeDeploy を使用して、アプリケーションリビジョンをデプロイします
<a name="tutorials-wordpress-deploy-application-create-deployment"></a>

 AWS CLI または コンソールを使用して、アプリケーションリビジョンをデプロイします。

**Topics**
+ [アプリケーションリビジョン (CLI) をデプロイするには](#tutorials-wordpress-deploy-application-create-deployment-cli)
+ [アプリケーションリビジョン (コンソール) のデプロイ](#tutorials-wordpress-deploy-application-create-deployment-console)

### アプリケーションリビジョン (CLI) をデプロイするには
<a name="tutorials-wordpress-deploy-application-create-deployment-cli"></a>

1. デプロイにはデプロイグループが必要です。ただし、デプロイグループを作成する前に、サービスロール ARN が必要です。サービスロールは、ユーザーに代わってサービスアクセス権限を付与する IAM ロールです。この場合、サービスロールは、Amazon EC2 インスタンスにアクセスして Amazon EC2 インスタンスタグを拡張 (読み込み) するためのアクセス権限を CodeDeploy に付与します。

   すでに [サービスロールの作成 (CLI)](getting-started-create-service-role.md#getting-started-create-service-role-cli) の手順に従ってサービスロールを作成している必要があります。サービスロールの ARN を取得するには、「[サービスロール ARN の取得 (CLI)](getting-started-create-service-role.md#getting-started-get-service-role-cli)」を参照してください。

1. サービスロールの ARN を取得したら、**create-deployment-group** コマンドを呼び出し、**WordPress\$1DepGroup** という名前の Amazon EC2 タグと **WordPress\$1App** という名前のデプロイ設定を使用して、**CodeDeployDemo** という名前のアプリケーションと関連付けられる **CodeDeployDefault.OneAtATime** という名前のデプロイグループを作成します。

   ```
   aws deploy create-deployment-group \
     --application-name WordPress_App \
     --deployment-group-name WordPress_DepGroup \
     --deployment-config-name CodeDeployDefault.OneAtATime \
     --ec2-tag-filters Key=Name,Value=CodeDeployDemo,Type=KEY_AND_VALUE \
     --service-role-arn serviceRoleARN
   ```

   
**注記**  
[デプロイメントグループの作成](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment-group.html) コマンドは、デプロイおよびインスタンス内の指定されたイベントについて、トピックサブスクライバーに Amazon SNS 通知を送信するトリガーの作成に対応しています。このコマンドは、Amazon CloudWatch アラームのモニタリングしきい値が満たされたときにデプロイを自動的にロールバックし、デプロイを停止するアラームを設定するオプションもサポートします。このチュートリアルでは、これらのアクションに関するコマンドは含まれていません。

1. デプロイを作成する前に、デプロイグループのインスタンスに CodeDeploy エージェントがインストールされている必要があります。 AWS Systems Manager で次のコマンドを使用して、コマンドラインからエージェントをインストールできます。

   ```
   aws ssm create-association \
     --name AWS-ConfigureAWSPackage \
     --targets Key=tag:Name,Values=CodeDeployDemo \
     --parameters action=Install,name=AWSCodeDeployAgent \
     --schedule-expression "cron(0 2 ? * SUN *)"
   ```

   このコマンドは、CodeDeploy エージェントをインストールし、毎週日曜日の午前 2:00 に更新を試行する関連付けを Systems Manager ステートマネージャーに作成します。CodeDeploy エージェントの詳細については、「[CodeDeploy エージェントの使用](https://docs.aws.amazon.com/codedeploy/latest/userguide/codedeploy-agent.html)」を参照してください。Systems Manager のさらなる詳細については、「[AWS Systems Managerとは](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)」 を参照してください。

1. 次に、**create-deployment** コマンドを呼び出して、**amzn-s3-demo-bucket** という名前のバケットで **WordPressApp.zip** という名前のアプリケーションバージョンを使用して、**WordPress\$1App** という名前のアプリケーション、**CodeDeployDefault.OneAtATime** という名前のデプロイ設定と **WordPress\$1DepGroup** という名前のデプロイグループに関連付けられるデプロイを作成します。

   ```
   aws deploy create-deployment \
     --application-name WordPress_App \
     --deployment-config-name CodeDeployDefault.OneAtATime \
     --deployment-group-name WordPress_DepGroup \
     --s3-location bucket=amzn-s3-demo-bucket,bundleType=zip,key=WordPressApp.zip
   ```

### アプリケーションリビジョン (コンソール) のデプロイ
<a name="tutorials-wordpress-deploy-application-create-deployment-console"></a>

1. CodeDeploy コンソールを使用してアプリケーションリビジョンをデプロイする前に、サービスロール ARN が必要になります。サービスロールは、ユーザーに代わってサービスアクセス権限を付与する IAM ロールです。この場合、サービスロールは、Amazon EC2 インスタンスにアクセスして Amazon EC2 インスタンスタグを拡張 (読み込み) するためのアクセス権限を CodeDeploy に付与します。

   すでに [サービスロールの作成 (コンソール)](getting-started-create-service-role.md#getting-started-create-service-role-console) の手順に従ってサービスロールを作成している必要があります。サービスロールの ARN を取得するには、「[サービスロール ARN の取得 (コンソール)](getting-started-create-service-role.md#getting-started-get-service-role-console)」を参照してください。

1. ARN があるので、CodeDeploy コンソールを使用して、アプリケーションリビジョンをデプロイします。

   にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/codedeploy](https://console.aws.amazon.com/codedeploy) で CodeDeploy コンソールを開きます。
**注記**  
「[CodeDeploy の開始方法](getting-started-codedeploy.md)」で設定したのと同じユーザーでサインインします。

1. ナビゲーションペインで [**デプロイ**] を展開し、[**アプリケーション**] を選択します。

1. アプリケーションのリストで、**WordPress\$1App** を選択します。

1. [**デプロイグループ**] タブで、[**デプロイグループの作成**] を選択します。

1. **[Deployment group name]** (デプロイグループ名) に「**WordPress\$1DepGroup**」と入力します。

1. [**Deployment type**] で、[**In-place deployment**] を選択します。

1. [**環境設定**] で、[**Amazon EC2 インスタンス**] を選択します。

1. **を使用した エージェント設定 AWS Systems Manager**では、デフォルトのままにします。

1. **[Key]** (キー) に、「**Name**」と入力します。

1. **[値]** には「**CodeDeployDemo**」と入力します。
**注記**  
**CodeDeployDemo** と入力すると、[**1**] が [**Matching instances**] の下に表示され、CodeDeploy が一致する Amazon EC2 インスタンスを 1 つ見つけたことを確認します。

1. [**デプロイ設定**] で [**CodeDeployDefault.OneAtATime**] を選択します。

1. [**サービスロール ARN**] でサービスロール ARN を選択し、[**デプロイグループの作成**] を選択します。

1. **[デプロイの作成]** を選択します。

1. [**デプロイグループ**] で [**WordPress\$1DepGroup**] を選択します。

1. [**Repository type**] の横の [**My application is stored in Amazon S3**] を選択します。[**リビジョンの場所**] で、前に Amazon S3 にアップロードしたサンプルアプリケーション WordPress のリビジョンの場所を入力します。場所の取得

   1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。

   1. バケットのリストで、**[amzn-s3-demo-bucket]** (または、アプリケーションリビジョンをアップロードしたバケットの名前) を選択します。

   1. オブジェクトのリストで、**WordPressApp.zip** を選択します。

   1. [**概要**] タブで、[**リンク**] フィールドの値をクリップボードにコピーします。

      次のように表示されます。

      **https://s3.amazonaws.com/amzn-s3-demo-bucket/WordPressApp.zip**

   1. CodeDeploy コンソールに戻り、**[リビジョンの場所]** に **[リンク]** フィールドの値を貼り付けます。

1. [**ファイルタイプ**] リストで、ファイルの種類を検出できないというメッセージが表示される場合は、[**.zip**] を選択します。

1. (オプション) [**Deployment description**] ボックスにコメントを入力します。

1. [**Deployment group overrides (デプロイグループの上書き)**] を展開し、[**デプロイ設定**] から [**CodeDeployDefault.OneAtATime**] を選択します。

1. **デプロイの開始** を選択します。新しく作成されたデプロイに関する情報は [**Deployments**] ページに表示されます。

## デプロイをモニタリングおよびトラブルシューティングします。
<a name="tutorials-wordpress-deploy-application-monitor"></a>

 AWS CLI または コンソールを使用して、デプロイをモニタリングおよびトラブルシューティングします。

**Topics**
+ [デプロイ (CLI) をモニタリングおよびトラブルシューティングするには](#tutorials-wordpress-deploy-application-monitor-cli)
+ [デプロイ (コンソール) をモニタリングおよびトラブルシューティングするには](#tutorials-wordpress-deploy-application-monitor-console)

### デプロイ (CLI) をモニタリングおよびトラブルシューティングするには
<a name="tutorials-wordpress-deploy-application-monitor-cli"></a>

1. **WordPress\$1App** という名前のアプリケーションと **WordPress\$1DepGroup** という名前のデプロイグループに対して **list-deployments** コマンドを呼び出して、デプロイの ID を取得します。

   ```
   aws deploy list-deployments --application-name WordPress_App --deployment-group-name WordPress_DepGroup --query 'deployments' --output text
   ```

1. デプロイ ID を使用して **get-deployment** コマンドを呼び出します。

   ```
   aws deploy get-deployment --deployment-id deploymentID --query 'deploymentInfo.status' --output text
   ```

1. コマンドはデプロイの全体ステータスを返します。成功すると、値は `Succeeded` になります。

   全体的なステータスが `Failed` の場合、[list-deployment-instances](https://docs.aws.amazon.com/cli/latest/reference/deploy/list-deployment-instances.html) や [デプロイメントインスタンスの取得](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) などのコマンドを呼び出してトラブルシューティングを行います。トラブルシューティングの他のオプションについては、「[ログファイルの分析によるインスタンスでのデプロイの失敗の調査](troubleshooting-ec2-instances.md#troubleshooting-deploy-failures)」を参照してください。

### デプロイ (コンソール) をモニタリングおよびトラブルシューティングするには
<a name="tutorials-wordpress-deploy-application-monitor-console"></a>

CodeDeploy コンソール の [**Deployments**] ページで、[**Status**] 列でデプロイのステータスをモニタリングできます。

特に [**Status**] 列の値が [**Succeeded**] 以外の値である場合にデプロイに関する詳細情報を取得するには。

1. [**デプロイ**] テーブルで、デプロイの名前を選択します。デプロイが失敗すると、失敗の原因を説明するメッセージが表示されます。

1. [**インスタンスアクティビティ**] に、デプロイに関する詳細情報が表示されます。デプロイ失敗後、デプロイが失敗した Amazon EC2 インスタンスおよびステップを特定できる場合があります。

1. より多くのトラブルシューティングを行う場合、「[CodeDeploy を用いてインスタンスの詳細の表示](instances-view-details.md)」で説明されているような手法を使用できます。また、Amazon EC2 インスタンスでデプロイログファイルを分析できます。詳細については、「[ログファイルの分析によるインスタンスでのデプロイの失敗の調査](troubleshooting-ec2-instances.md#troubleshooting-deploy-failures)」を参照してください。

## デプロイの確認
<a name="tutorials-wordpress-deploy-application-verify-deployment"></a>

デプロイが成功したら、WordPress インストールが動作していることを確認します。Amazon EC2 インスタンスのパブリック DNS アドレスの後に `/WordPress` を使用して、ウェブブラウザのサイトを表示します。(Amazon EC2 コンソールでパブリック DNS 値を取得するには、Amazon EC2 インスタンスを選択して [**説明**] タブで **[パブリック DNS**] で値を探します。)

例えば、Amazon EC2 インスタンスのパブリック DNS アドレスが **ec2-01-234-567-890.compute-1.amazonaws.com** である場合、次の URL を使用します。

```
http://ec2-01-234-567-890.compute-1.amazonaws.com/WordPress
```

ブラウザでサイトを表示すると、次のような WordPress のウェルカムページが表示されます。

![\[WordPress ウェルカムページ\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/images/WordPress-Welcome-Page-013118.png)


 Amazon EC2 インスタンスで、HTTP インバウンドルールがそのセキュリティグループに追加されていない場合、WordPress ウェルカムページは表示されません。リモートサーバーが応答していないというメッセージが表示された場合は、Amazon EC2 インスタンスのセキュリティグループにインバウンドルールがあることを確認します。詳細については、「[HTTP トラフィックを許可するインバウンドルールの Amazon Linux または RHEL Amazon EC2 インスタンスへの追加Windows Server の Amazon EC2 インスタンスへの HTTP トラフィックを許可するインバウンドルールを追加する](tutorials-wordpress-launch-instance.md#tutorials-wordpress-launch-instance-add-inbound-rule)」を参照してください。

# ステップ 5: WordPress アプリケーションを更新して再デプロイする
<a name="tutorials-wordpress-update-and-redeploy-application"></a>

正常にアプリケーションリビジョンをデプロイしたので、開発用マシンで WordPress コードを更新し、 CodeDeploy を使用して、サイトを再デプロイします。後で、Amazon EC2 インスタンスのコード変更を確認する必要があります。

**Topics**
+ [WordPress サイトの設定](#tutorials-wordpress-update-and-redeploy-application-configure-and-install)
+ [サイトの変更](#tutorials-wordpress-update-and-redeploy-application-modify-code)
+ [サイトの再デプロイ](#tutorials-wordpress-update-and-redeploy-application-deploy-updates)

## WordPress サイトの設定
<a name="tutorials-wordpress-update-and-redeploy-application-configure-and-install"></a>

コード変更の効果を表示するには、完全に機能するインストールができるように、WordPress サイトの設定を終了します。

1. ウェブブラウザにサイトの URL を入力します。URL は Amazon EC2 インスタンスと `/WordPress` 拡張子のパブリック DNS アドレスです。この WordPress サイト例 (Amazon EC2 インスタンスのパブリック DNS アドレスの例) では、URL は **http://ec2-01-234-567-890.compute-1.amazonaws.com/WordPress** です。

1. サイトをまだ設定していない場合は、WordPress のデフォルトのウェルカムページが表示されます。[**始めましょう**] を選択します。

1. デフォルトの MySQL データベースを使用するため、データベース設定ページで、以下の値を入力します。
   + **データベース名**: **test**
   + **ユーザー名**: **root**
   + **パスワード**: 空白のままにします。
   + **データーベースホスト**: **localhost**
   + **テーブルプレフィックス**: **wp\$1**

   [**Submit**] を選択して、データベースをセットアップします。

1. サイト設定を続行します。[**Welcome**] ページで任意の値を入力して [**Install WordPress**] を選択します。インストールが完了したら、ダッシュボードにサインインできます。

**重要**  
 WordPress アプリケーションのデプロイ中に、**change\$1permissions.sh** スクリプトにより `/tmp/WordPress` フォルダのアクセス権限が更新されたため、誰でもこのフォルダに書き込むことができます。ここで、次のコマンドを実行して、所有者のみが書き込めるようにアクセス権限を制限します。  

```
chmod -R 755 /var/www/html/WordPress
```

## サイトの変更
<a name="tutorials-wordpress-update-and-redeploy-application-modify-code"></a>

WordPress サイトを変更するには、開発用マシンのアプリケーションのフォルダを参照してください。

```
cd /tmp/WordPress
```

サイトの色の一部を変更するには、`wp-content/themes/twentyfifteen/style.css` ファイルで、テキストエディターまたは **sed** を使用して、`#fff` を `#768331` に変更します。

Linux または、GNU **sed** を持つほかのシステムでは、以下を使用します。

```
sed -i 's/#fff/#768331/g' wp-content/themes/twentyfifteen/style.css
```

macOS、Unix、または BSD **sed** を持つ他のシステムでは、以下を使用します。

```
sed -i '' 's/#fff/#768331/g' wp-content/themes/twentyfifteen/style.css
```

## サイトの再デプロイ
<a name="tutorials-wordpress-update-and-redeploy-application-deploy-updates"></a>

サイトのコードを変更したので、Amazon S3 および CodeDeploy を使用してサイトを再デプロイします。

「[アプリケーションのファイルを 1 つのアーカイブファイルにバンドルし、アーカイブファイルをプッシュする](tutorials-wordpress-upload-application.md#tutorials-wordpress-upload-application-bundle-and-push-archive)」の説明に従って、変更内容をバンドルして Amazon S3 にアップロードします。(これらの手順に従うときに、アプリケーションを作成する必要がないことに注意してください。) 新しいリビジョンに以前と同じキーを指定します (**WordPressApp.zip**)。それを先に作成した同じ Amazon S3 バケットにアップロードします (例: **amzn-s3-demo-bucket**)。

サイトを再デプロイするには AWS CLI、、CodeDeploy コンソール、または CodeDeploy APIs を使用します。

**Topics**
+ [サイト (CLI) に再デプロイするには](#tutorials-wordpress-update-and-redeploy-application-deploy-updates-cli)
+ [サイト (コンソール) の再デプロイ](#tutorials-wordpress-update-and-redeploy-application-deploy-updates-console)

### サイト (CLI) に再デプロイするには
<a name="tutorials-wordpress-update-and-redeploy-application-deploy-updates-cli"></a>

**create-deployment** コマンドを呼び出して、新しくアップロードされたリビジョンに基づいたデプロイを作成します。**amzn-s3-demo-bucket** という名前のバケットにある **WordPress\$1App** という名前のアプリケーション、**CodeDeployDefault.OneAtATime** という名前のデプロイ設定、**WordPress\$1DepGroup** という名前のデプロイグループ、**WordPressApp.zip** という名前のリビジョンを使用します。

```
 aws deploy create-deployment \
  --application-name WordPress_App \
  --deployment-config-name CodeDeployDefault.OneAtATime \
  --deployment-group-name WordPress_DepGroup \  
  --s3-location bucket=amzn-s3-demo-bucket,bundleType=zip,key=WordPressApp.zip
```

「[デプロイをモニタリングおよびトラブルシューティングします。](tutorials-wordpress-deploy-application.md#tutorials-wordpress-deploy-application-monitor)」に説明されているように、デプロイのステータスを確認できます。

CodeDeploy がサイトを再デプロイしたら、ウェブブラウザのサイトに再度アクセスして、色が変更されたことを確認します。(ブラウザを更新することが必要な場合があります。) 色が変更されていた場合は、サイトは正常に変更され、再デプロイされています。

### サイト (コンソール) の再デプロイ
<a name="tutorials-wordpress-update-and-redeploy-application-deploy-updates-console"></a>

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/codedeploy](https://console.aws.amazon.com/codedeploy) で CodeDeploy コンソールを開きます。
**注記**  
「[CodeDeploy の開始方法](getting-started-codedeploy.md)」で設定したのと同じユーザーでサインインします。

1. ナビゲーションペインで [**デプロイ**] を展開し、[**アプリケーション**] を選択します。

1. アプリケーションのリストで、**WordPress\$1App** を選択します。

1. [**デプロイグループ**] タブで、[**WordPress\$1DepGroup**] を選択します。

1. **[デプロイの作成]** を選択します。

1. [**Create deployment**] ページの

   1. [**デプロイグループ**] で [**WordPress\$1DepGroup**] を選択します。

   1. [**リポジトリタイプ**] エリアで、[**My application is stored in (アプリケーションは Amazon S3 に格納されています)**] を選択し、リビジョンの Amazon S3 リンクを [**リビジョンの場所**] ボックスにコピーします。リンク値の確認 

      1. 別のブラウザタブで

         にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) で Amazon S3 コンソールを開きます。

          **[amzn-s3-demo-bucket]** を参照して開き、リビジョンとして **WordPressApp.zip** を選択します。

      1.  [**Properties**] ペインが Amazon S3 コンソールに表示されない場合、[**Properties**] ボタンを選択します。

      1.  [**Properties**] ペインで、[**Link**] フィールドの値をCodeDeploy コンソールの [**Revision location**] ボックスにコピーします。

   1. ファイルの種類を検出できないというメッセージが表示される場合は、[**.zip**] を選択します。

   1. [**Deployment description**] ボックスを空白のままにしておきます。

   1. [**Deployment group overrides (デプロイグループの上書き)**] を展開し、[**デプロイ設定**] から [**CodeDeployDefault.OneAtATime**] を選択します。

   1. **デプロイの開始** を選択します。新しく作成されたデプロイに関する情報は [**Deployments**] ページに表示されます。

   1. 「[デプロイをモニタリングおよびトラブルシューティングします。](tutorials-wordpress-deploy-application.md#tutorials-wordpress-deploy-application-monitor)」に説明されているように、デプロイのステータスを確認できます。

      CodeDeploy がサイトを再デプロイしたら、ウェブブラウザのサイトに再度アクセスして、色が変更されたことを確認します。(ブラウザを更新することが必要な場合があります。) 色が変更されていた場合は、サイトは正常に変更され、再デプロイされています。

# ステップ 6: WordPress のアプリケーションと関連リソースのクリーンアップ
<a name="tutorials-wordpress-clean-up"></a>

これで、WordPress コードを正常に更新し、サイトを再デプロイしました。このチュートリアル用に作成したリソースの継続的な料金の発生を回避するため、以下を削除する必要があります。
+  CloudFormation スタック (または、 の外部で作成した場合は Amazon EC2 インスタンスを終了 CloudFormation)。
+ Amazon S3 バケットの場合。
+ CodeDeploy 内の `WordPress_App` アプリケーションの名前です。
+ CodeDeploy エージェントの AWS Systems Manager ステートマネージャーの関連付け。

クリーンアップを実行するには AWS CLI、、 CloudFormation、Amazon S3、Amazon EC2、CodeDeploy コンソール、または AWS APIsを使用できます。

**Topics**
+ [リソース (CLI) をクリーンアップするには](#tutorials-wordpress-clean-up-cli)
+ [リソース (コンソール) をクリーンアップするには](#tutorials-wordpress-clean-up-console)
+ [次のステップ](#tutorials-wordpress-clean-up-whats-next)

## リソース (CLI) をクリーンアップするには
<a name="tutorials-wordpress-clean-up-cli"></a>

1. このチュートリアルで CloudFormation テンプレートを使用した場合は、 という名前のスタックに対して **delete-stack** コマンドを呼び出します**CodeDeployDemoStack**。これにより、付随するすべての Amazon EC2 インスタンスが終了し、スタックによって作成された付随するすべての IAM ロールが削除されます。

   ```
   aws cloudformation delete-stack --stack-name CodeDeployDemoStack
   ```

1. Amazon S3 バケットを削除するには、**rm** スイッチを使用して **--recursive** という名前のバケットに対して **amzn-s3-demo-bucket** コマンドを呼び出します。これにより、バケットとバケット内のすべてのオブジェクトが削除されます。

   ```
   aws s3 rm s3://amzn-s3-demo-bucket --recursive --region region
   ```

1. `WordPress_App` アプリケーションを削除するには、**delete-application** コマンドを呼び出します。これにより、関連するすべてのデプロイグループレコードと、アプリケーションのデプロイレコードも削除されます。

   ```
   aws deploy delete-application --application-name WordPress_App
   ```

1. Systems Manager ステートマネージャーの関連付けを削除する場合、**delete-association** コマンドを呼び出します。

   ```
   aws ssm delete-association --assocation-id association-id
   ```

   **describe-association** コマンドを呼び出して、*アソシエーション ID* を取得することができます。

   ```
   aws ssm describe-association --name AWS-ConfigureAWSPackage --targets Key=tag:Name,Values=CodeDeployDemo
   ```

このチュートリアルで CloudFormation スタックを使用しなかった場合は、 **terminate-instances** コマンドを呼び出して、手動で作成した Amazon EC2 インスタンスをすべて終了します。終了させる Amazon EC2 インスタンスの ID を指定します。

```
aws ec2 terminate-instances --instance-ids instanceId
```

## リソース (コンソール) をクリーンアップするには
<a name="tutorials-wordpress-clean-up-console"></a>

このチュートリアルで CloudFormation テンプレートを使用した場合は、関連する CloudFormation スタックを削除します。

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。

1. **フィルター**ボックスに、前に作成した CloudFormation スタック名を入力します (例: **CodeDeployDemoStack**)。

1. スタック名の横のボックスをオンにします。[**Actions**] メニューで、[**Delete Stack**] を選択します。

   CloudFormation はスタックを削除し、付随するすべての Amazon EC2 インスタンスを終了し、付随するすべての IAM ロールを削除します。

 CloudFormation スタックの外部で作成した Amazon EC2 インスタンスを終了するには:

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) で Amazon EC2 コンソールを開きます。

1. [**INSTANCES**] リストで、[**Instances**] を選択します。

1. 検索ボックスで、終了する Amazon EC2 インスタンス名 (例: **CodeDeployDemo**) を入力して Enter キーを押します。

1. Amazon EC2 インスタンスを選択します。

1. [**Actions**] メニューで [**Instance State**] をポイントし、[**Terminate**] を選択します。プロンプトが表示されたら、[**Yes, Terminate**] を選択します。

インスタンスごとにこれらの手順を繰り返します。

Amazon S3 バケットの削除

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) で Amazon S3 コンソールを開きます。

1. バケットのリストで、前に作成した Amazon S3 バケットの名前を参照して選択します (例: **amzn-s3-demo-bucket**)。

1. バケットを削除する前に、まず、そのコンテンツを削除する必要があります。**WordPressApp.zip** のようなバケット内のすべてのファイルを選択します。[**Actions**] メニューで、[**Delete**] を選択します。削除を確認するプロンプトが表示されたら、[**OK**] を選択します。

1. バケットが空になると、バケットを削除できます。バケットのリストで、バケットの行 (バケット名ではなく) を選択します。[**Delete bucket**] を選択し、確認が求められたら [**OK**] を選択します。

CodeDeploy から `WordPress_App` アプリケーションの削除

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/codedeploy](https://console.aws.amazon.com/codedeploy) で CodeDeploy コンソールを開きます。
**注記**  
「[CodeDeploy の開始方法](getting-started-codedeploy.md)」で設定したのと同じユーザーでサインインします。

1. ナビゲーションペインで [**デプロイ**] を展開し、[**アプリケーション**] を選択します。

1. アプリケーションのリストで、**WordPress\$1App** を選択します。

1. [**Application details**] ページで、[**Delete application**] を選択します。

1. プロンプトが表示されたら、アプリケーションの名前を入力して削除することを確定し、[**削除**] を選択します。

Systems Manager ステートマネージャーの関連付けの削除

1. https://console.aws.amazon.com/systems-manager で AWS Systems Manager コンソールを開きます。

1. ナビゲーションペインで、[**ステートマネージャー**] を選択してください。

1. 作成した関連付けを選択し、[**削除**] を選択します。

## 次のステップ
<a name="tutorials-wordpress-clean-up-whats-next"></a>

ここまでの作業で、CodeDeploy デプロイが正常に完了し、サイトのコードが更新され、再デプロイされました。