追記 12/19

成功しました。

たぶんやってることはこんなこと

EC2にAgentを導入する。

デフォルトではCodeDeployから操作できないためAgentを追加する必要がある。
（オンプレミスのサーバーも然り。Agentを入れればデプロイ可能となる。）

インスタンス作成画面の高度な詳細→ユーザーデータではインスタンスの起動時に実行する内容を記述できる。

ここへ、CodeDeployを利用するためのAgentをインストールする処理を書く。

#!/bin/bash
yum -y update
yum install -y ruby
cd /home/ec2-user
curl -O https://バケット名.s3.amazonaws.com/latest/install
chmod +x ./install
./install auto

バケット名はCodeDeployリソースキットファイルが含まれている公式のバケットのものを指し、リージョン別リソースキットバケット名から適切なものを選択して書く。

コメント

なお、Amazon Linux2では上記では成功したが、1世代前のAmazon Linuxでは最後のコマンド実行時にエラーした。（2019/11/18時点）

appspec.ymlを作成する。

これは仕様書みたいなもの（Application Specification file）。

書き方は以下の規定がある。
CodeDeploy AppSpec File リファレンス

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

sourceはソースファイルの場所を指定し、destinationはzipで上げるアプリケーションの展開先を指定する。
hooksには、イベント名とそのイベントで実行するファイル（場所）と実行時間、ユーザーを指定する。各イベントのタイミングで指定したスクリプトが実行される。
なお、ApplicationStopフックは2回目のデプロイ以降で呼ばれる（1回目はそもそもインスタンスがないから）。

参考）AppSpec の「hooks」セクション

s3へアップロードし、CodeDeployと紐付ける。

デプロイするzipファイルを置くバケットを作成しておく。

バケットポリシー

バケットポリシーでPutObject可能なように設定すること。

なお、ポリシーの見方はアクセスポリシー言語の概要参照。

{
    "Version": "2012-10-17",
    "Id": "ExamplePolicy01",
    "Statement": [
        {
            "Sid": "ExampleStatement01",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam:000011112222:user/許可するユーザー名"
            },
            "Action": [
                "s3:GetObject",
                "s3:GetBucketLocation",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::examplebucket/*",
                "arn:aws:s3:::examplebucket"
            ]
        }
    ]
}

Effectは許可するのか拒否するのか。競合する場合、一般に設定なし＜許可＜拒否の順で優先される。
Principalは誰が以下のアクションを実行するのか。アクセス元。rootユーザの指定方法は"AWS": "arn:aws:iam:000011112222:root"。
Actionは対象の操作内容。アクション。
ResourceはどのAWSリソースに対するアクションか。アクセス先。

CodeDeployアプリケーションの作成と紐付け

$ aws deploy create-application --application-name アプリケーション名

$ aws deploy push \
  --application-name WordPress_App \
  --s3-location s3://codedeploydemobucket/WordPressApp.zip \
  --ignore-hidden-files

コメント

後者のコマンドはs3のポリシーとかIAMをいろいろやってもAccess Deniedだった（謎）。
ただ、裏ではこんなことをしているようなので、上記のコマンドをバラして一個一個実行していったところ、S3へアップできて紐付けまで成功した。

$ zip -r WordPressApp.zip .
$ aws s3api put-object --bucket YOUR-BUCKET --key WordPressApp.zip --body WordPressApp.zip
$ aws deploy register-application-revision \
  --application-name WordPress_App \
  --s3-location bucket=YOUR-BUCKET,key=WordPressApp.zip,bundleType=zip

デプロイ

デプロイグループを作成する。
EC2にアクセスするがあるため、AWSCodeDeployRoleポリシーをあてたサービスロールを付与する。

$ 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=対象のEC2名,Type=KEY_AND_VALUE \
  --service-role-arn serviceRoleARN

デプロイする。

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

なんどもs3の参照先を設定する理由がよくわからないが、一応これでデプロイが走る。

コメント

tutorialで進めるとデプロイ成功までは行けなかった。
そもそもyum installができない問題や、その先のhttpd、mysqldを起動できないといった問題が起きた。
気が向いたら調べてみる。

CodeDeployの用語整理

用語	意味
アプリケーション	デプロイしようとしているリビジョンのこと。今回はzipでS3に置いているので、どこに置いているか、形式は何かといったことを紐付けたデータがアプリケーション。
デプロイグループ	デプロイ先はどこか、一度にデプロイするのか、ロールなどの設定をしたものデプロイの型みたいなもの。
デプロイ	1回1回のデプロイのこと。成功/失敗のステータスが出る。