CodePipelineを実際に動かす際に意識しておくことをまとめる
今回のテーマ
こんにちはAWS事業本部コンサルティング部のこーへいです。
今回のテーマは「CodePipelineを実際に動かす際に意識しておくことをまとめる」です。
本記事では、ECS(ローリングアップデート)版のCodePipelineにて意識しておくといいポイントなどをノウハウ形式でまとめてみました。
今回の構成
上記構成図をベースに、今回お話しさせて頂きます。
基本的かつ簡易的な構成となっており、考え方自体は他にも流用できますので少し異なるCodePipeline構成の場合でも参考になる箇所があると思います。
起動編
CodePipelineの起動方法について
「トリガー条件を満たす(自動)」と「手動」の大きく2つがあります。
トリガー条件を満たし、CodePipelineを起動する
最も一般的なCodePipelineの起動方法です。
CodePipelineのソースステージによく使用されるCodeCommitやGitHubにて、対象リポジトリの指定ブランチの更新を検知(設定によりますが、裏でEventBridgeが動いています)し、CodePipelineが起動されます。
開発チームがアプリケーションコードを修正し、mainブランチを更新すると、CICDが走って本番環境に最新版がデプロイされる王道の流れとなります。
CodePipelineを手動実行する
一方、手動で起動する方法もございます。
こちらを利用する目的としては、動作検証的な意味合いで利用することが多いです。
アプリケーションコードを更新する必要はないがCodePipelineを動かしたい時、、、例えばCodePipelineの設定を変更し再度CodePipelineを実行したいタイミング等で利用します。
この場合は当たり前ですがコミットが更新されているわけではないので、既存の最新コミットにてCICDが実行される点は知っておく必要があります
エラー編
エラー内容を突き止める
CodePipelineをはじめ、CICDの開発はエラー対応の連続となります。
上記画像のようにCodePipelineの実行履歴→実行IDを確認することで、発生しているエラー原因を確認することができます。
よくあるエラー
TooManyRequest
詳細は下記記事をご確認いただければと思いますが、DockerHubの仕様により「TooManyRequest」と呼ばれるダウンロード制限に引っかかりエラーが発生することがしばしばあります。
存在を把握していないと沼ってしまう可能性があるので、頭の片隅に留めておいてください。
権限不足
CodePipelineやCodeBuildにアタッチしているIAMロールに権限が不足してエラーが発生することもよくある話です。
エラーが発生した場合は大人しく、権限を足してあげましょう
buildspec.yml
「buildspec.yml」ファイルはBuildに必要な実行コマンドを記載していきますが、コードを扱う以上やはりこれが最も頻発するエラーだと考えられます。
効率的にデバッグ作業を行うための方法の1つとして、ビルド実行環境の中に入られることを知っておくと良いでしょう。
停止編
途中で停止したくなったら
CodePipeline実行中に「実行を停止」を実行することでCodePipelineを途中で停止することができます。
ちなみに、「停止して待機」は現在進行中のアクション完了後、つまりBuildステージが進行中であればBuildステージが完了後にパイプラインが停止され、「停止して中止」は即座にパイプラインが停止します。
切り戻し編
CodePipeline完了前
基本的にCodePipeline完了前であれば、途中パイプラインを停止すれば最新版のアプリケーションがデプロイされることはありません。
また最新版のタスクが正常に起動しない場合は、ECSサービスのデプロイサーキットブレーカーの「ロールバックありで有効化」を選択することで前の正常なバージョンへ自動的に切り戻しが実施されます。
CodePipeline完了後
CodePipeline完了後に何かしらの理由により前バージョンのアプリケーションに戻したい場合は、手動対応が必要となります。
と言っても操作自体は簡単で、下記画像の通り対象のECSサービスを選択し更新を押下し、
その後、タスク定義を対象のバージョンに選択した状態でサービスを更新すれば切り戻しが完了します。
