こまったリスト

こまった1　DownloadBundleした時のファイルの場所がわからない・・・

deployした元のファイルは以下の場所に展開されている。

/opt/codedeploy-agent/deployment-root/
|-- 0XXXXeea-XXXX-YYYY-ZZZZ-FFFFFFFFFe64
|   |-- d-50QKXXXXX
|   |-- d-XXXXX8FUNB
|   |-- d-XXXXX9TNB
|   |-- d-XXXXXWSNB
|   `-- d-XXXXXDPNB
`-- deployment-instructions
    |-- 0XXXXeea-XXXX-YYYY-ZZZZ-FFFFFFFFFe64-cleanup
    |-- 0XXXXeea-XXXX-YYYY-ZZZZ-FFFFFFFFFe64-install.json
    `-- 0XXXXeea-XXXX-YYYY-ZZZZ-FFFFFFFFFe64_last_successful_install

ぱっと見て「前回の成功したインストール」とかその種の情報が保存されているのがわかる。

XXXXXX-cleanup ファイルには、インストール時に作ったファイルが(たぶん appspec.yml の file エントリで置かれたファイル)が記述されている。これは次回のインストール時にクリアされる対象だということなんだろう。

こまった2 ログの出力がしょぼすぎるのでは

実際問題、マネジメントコンソールからも情報が少なすぎてうまく動作しないときのトレースがやりづらい。

/etc/codedeploy-agent/conf/codedeployagent.yml verbose を true に設定して codedeploy-agent サービスを再起動しよう。

$ cat /etc/codedeploy-agent/conf/codedeployagent.yml
---
:log_aws_wire: false
:log_dir: '/var/log/aws/codedeploy-agent/'
:pid_dir: '/opt/codedeploy-agent/state/.pid/'
:program_name: codedeploy-agent
:root_dir: '/opt/codedeploy-agent/deployment-root'
:verbose: false
:wait_between_runs: 1

そうするとけっこうドバドバとログがでる。

ちなみにログを眺めていると、ああ codedeploy というのはつまり1分バッチで更新情報を取得するプル型のアーキテクチャなんだなーとわかる。

こまった3 ApplicationStopが古いものが実行されている?

ある時、ApplicationStop のスクリプトがこけてしまい、どうしてもデプロイが進まなくなった。appspec.yml から該当のフックを削除しても、全く同じく ApplicationStop の失敗でデプロイがこける。

これは自分が勘違いしていて、そもそも ApplicationStop は「前回デプロイが成功した時のリビジョンの appspec.yml のフックが実行される」動作をする。これは理にかなった設計だが罠だと思った。

つまり、前回デプロイ成功したリビジョンに必ず失敗する ApplicationStop フックがあった場合、死ぬ。新規リビジョンのデプロイはそのサーバにはできない。と思う。

こまった4　対象サーバによって処理を分けたい / Web起動するとかCronを切り替えるとかデバッグモードにするとか

できない。現時点ではフック側やAWSのサービス側からデプロイプロセスに環境変数などを渡す方法はないっぽい。

サーバに環境情報は用意しよう。もしくはフックのシェルスクリプトでがんばる。

フックは実行権限さえあれば python だろうが ruby だろうが突っ込める。自分自身の情報を awscli 経由で持ってくるか、予め環境情報を /etc/myapp.env などに置いてがんばることもできる。でもつらいのでサーバ側に環境情報は配置した方がいいかなぁ。

ということで

なんとなく、使いたい用途には十分かなという気がしてきました。

CodeDeploy 困った4