アプリケーションのデプロイ環境として、AWSから提供されるCodedeployですが、
インフラ技術者から見たら、一体どんなことが出来るのでしょうか？
レジュメ
結論、従来のインフラ構築した後に行うアプリケーションのデプロイ方法
CodeDepodyは、S3やGitHubにデプロイしたいファイルを配置し、オートスケール含むEC2にアプリケーションをデプロイできる仕組みです。
ポイントはAutoScalingへデプロイ可能とBlue/Greenデプロイ可能
ポイントは、AWSのオートスケールにデプロイが対応しているということです。オートスケールはEC2が生まれては死んでを繰り返して運用されているのでデプロイの手法が悩ましくあります。
CodeDeployではオートスケールグループがコピーされ新しいバージョンのアプリケーションがデプロイされるので、万が一アプリのデプロイに何か問題があった場合もフェールバックは簡単です。
AWSのホワイトペーパーから学ぶブルーグリーンデプロイメント – サーバーワークスエンジニアブログ
S3やGitHubにデプロイZipを配置するとオートスケール時の取りに行くようになる。
CodeDeployのアプリケーションの配置先は
- S3
- GitHub
が利用できます。インフラ技術者にはわかりずらいですが、アプリ開発技術者にはGitHubはなじみが深いのではないでしょうか。
デプロイzipにはデプロイ時にコピーやコマンド実行など命令を書いたappspec.ymlが必要
デプロイZipの中身は、beanstalkとは異なり、デプロイ時に何を実行するのか命令を書いたappspec.ymlを用意する必要がある。
例えば、以下のような appspec.yml を用意すれば
hooksとしてBefareInstallのタイミングにシェルスクリプトのコマンドを実行することが可能です。
しかし、エラーになると原因がわかりづらい
問題はCodeDeployのデプロイでエラーが出た場合です。
エラーの原因をつかむのが難しいです。
自分の場合
- デプロイ先のEC2がインターネットにアクセス出来ないためデプロイ出来なかった。
- AMIにあるファイルを上書き出来ないためデプロイ出来なかった（「追加のデプロイ動作設定」でエラーを回避するこ都が可能）
という事象を経験しました。