保貴2021.09.19この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。Bit)込みの検証環境を構築するCloudFormationのテンプレートを以前紹介しました。Bitのデプロイ作業を簡略化するためにCodePipelineでCI/CDパイプラインを作成し連携させてます。デプロイメントを採用します。前回の環境おさらい前回アプリコンテナは素のNginxコンテナを利用していました。Bitのイメージは自前の設定ファイルを読み込ませる都合、ECRにビルドした設定ファイル込みのイメージをpushしたものを利用していました。今回はプレースホルダを利用してBlue/Greenデプロイをするためappspec.ymlとtaskdef.jsonが登場します。CodeBuildでイメージをビルドするためにbuildspec.ymlが必要になります。今回使用するテンプレート以下に置いてあります。事前準備CI/CDのCodePipelineを設定する前に準備が必要です。buildspec.yml)を保存するレポジトリが必要になります。前回作成したECRと同じ名前のイメージレポジトリ作成するため前回のは一度削除してください。rainコマンドで以下のパラメータで作成した環境を用います。\ProjectName=sample3,\Environment=dev,\CCRepositoryName1=webappservice,\ECRRepositoryName1=custom-logrouter-firelens,\ECRRepositoryName2=webappCodeCommitにソースコードと各種ファイルをPush検証で使用したコードは以下に置いてあります。taskdef.jsonのアカウントIDは環境に合わせて修正してください。"arn:aws:iam::0123456789012:role/sample3-dev-webapp-ECSTaskExecutionRole"}その他全般ではsample3-dev-とプレフィックを付けている箇所が多数あります。構築時のrainコマンド例通りの指定した場合は修正不要です。Environmentに合わせて適時修正してください。CodeBuildの設定Webアプリをビルドするためのbuildspec.ymlと、FireLensをビルドするためのbuildspec.ymlを用意しました。main.goWebアプリとFireLensではビルドする内容に違いがあるかもと思い分けて検証をはじめました。同じ内容に落ち着きました。buildする対象のDockerfileのパスの指定が異なるだけです。imageDetail.json${ACCOUNT_ID}と、${REPOSITORY_NAME}は環境変数を使っています。パイプライン作成のテンプレートで環境変数を渡しています。ポイントはCodeBuildに対する環境変数の設定ではなく、CodePipelineに対して環境変数を渡すところです。環境変数の設定はCodePipelineのパイプラインに対して設定します。CodeDeployの設定Blue/Greenデプロイするためのappspec.ymlは1個です。CodePipelineの都合、Webアプリ、FireLens同時にビルドを行います。その後、同時にデプロイする方法しか取れませんでした。検討した他のパターンは最下部の「おわりに」で取り上げています。Webアプリを修正すると変更のないFireLensも再度ビルドしてデプロイされます。Bitの更新をかけると、アプリも再ビルド・再デプロイが行われます。www.flaticon.comappsepc.ymlの設定内容ではコンテナ名を変更していた場合に修正が必要です。"1.4.0"CodePipeline作成テンプレート内で後々作成するデプロイグループ名を事前にsample3-dev-webservice-deploy-groupと指定しています。変更する場合は必要に応じてテンプレートを修正してください。"sample3-dev-webservice-deploy-group"rainコマンドで以下のパラメータで作成した環境を用います。\ProjectName=sample3,\Environment=dev,\AppName1=webapp,\AppName2=logrouter,\PipelineName=webservice,\S3BucketName1=artifact,\CodeSeriesStackName=sample3-code-stack,\AppECRName=sample3-webapp,\FireLensECRName=sample3-custom-logrouter-firelens,\CodeCommitRepositoryName=sample3-webappserviceパイプラインが作成されると初回は自動実行されます。初回は確実に失敗します。Deployフェーズで失敗します。Deployフェーズ以外のエラーの場合、環境依存でテンプレートの修正が必要になるかと思われます。sample3-devと固定で入力している箇所が疑わしいです。初回は確実に失敗する理由はCloudFormationがデプロイグループの作成に対応していなく必要なリソースが足りていません。テンプレートからすべて作成できませんでした。以下リンクのLambdaでカスタムリソースでデプロイグループを作成していた意味を理解できました。DevelopersIOデプロイグループ以外の設定はCodePipelineテンプレートで作成してあります。テンプレート内で決め打ちしてデプロイグループ名を指定しています。今回はsample3-dev-webservice-deploy-groupの名前でデプロイグループを手動作成します。事前にデプロイグループ名を変更している場合は置き換えて読み進めてください。手動設定箇所CodeDepolyからアプリーケーションを開きます。デプロイグループの作成します。デプロイグループ名は事前に設定した名前を入力してください。サービスロール、他はテンプレートからリソースを作成済みです。統一感ある名前のリソースを次々に選択していくだけです。本番稼働リスナーポートは80番、テストリスナーポートは8080番を想定して作成しています。デプロイ設定はお好みで設定してください。ここではBlue/Greenデプロイ時、待機時間10分を設けた設定としました。古いタスクは1時間15分間待機し、すぐに切り戻せる設定としています。(本当は15分のつもりだったのですが、この後デプロイしたときに1時間15分と表示されて気づきました)デプロイグループの手動作成は完了です。サービスロールも含め必要なリソースはテンプレートで作成されています。設定は選択するだけですので難しくはないと思います。似た名前のリソースが先にあったときは注意してください。パイプラインテストテストのため手動で変更をリリースします。Deployフェーズが実行中になりました。指定した10分間トラフィックを新しいタスクへルーティングするか否かの待機中です。Blue/Greenデプロイしている感がでてきました。実際にWebブラウザからアクセスして表示を確かめてみましょう。アクセステストELBのDNS名に対してWebブラウザからアクセスします。既存タスク)Nginxのデフォルトページが表示されます。既存環境は素のNginxコンテナをデプロイしているため期待通りです。新タスク)テスト環境はポート番号が8080でルーティングされるよう設定しています。別の表示のWebページを確認できました。新タスクで起動している自前の設定を入れたWebコンテナの表示です。ここまでの流れまずCodeCommitのレポジトリにGoのソースコードがあります。ソースコードをCodeBuildでビルドします。でき上がったバイナリファイルを別のイメージにコピーし、要はマルチステージビルドを行い最終的なできあがったイメージをECRにpushしています。CodeDeployがECRにある新しいイメージをFargateへBlue/Greenデプロイしました。テストリスナーポートを(8080)通じて新しいイメージのコンテナへアクセスできているのが今の状態です。本番環境へ切り替えるトラフィックの再ルーティングを押して、切り替えます。80番ポートでアクセスすると、自前の設定入りのWebコンテナの表示に切り替わっています。8080番ポートは変化なし。Nginxのデフォルトページが表示され、アクセス先のタスクが入れ替わると想定していたのですが違いました。気になったので後ほどターゲットグループの動きを確認します。待機時間が長いので早々に元のタスク終了します。Blue/Greenデプロイ完了です。パイプラインも完了しています。Blue/Greenの状態とターゲットグループ関係デプロイ完了後8080番ポートへアクセスすると80番ポートと同じ表示がされたので設定を確認しました。リスナーの設定をみると80も8080も同じターゲットグループに向いています。あれば、同じアプリコンテナにアクセスしているのだから当然同じ表示になりますね。Blue/Greenデプロイを行いリスナーとターゲットグループの変化を確認します。切り替え前のこの状態で確認します。リスナーを確認すると...次にトラフィックを切り替え後のこの状態で確認します。リスナーをみると同じターゲットグループになっています。最後にBlue/Greenデプロイが完了したこの状態で確認します。リスナーをみるとトラフィック切り替え後の設定と変化なしです。CodeCommitへのPushからの実行テストWebアプリの表示名を編集してからCodeCommitにPushすることでパイプラインが実行され、Blue/Greenデプロイができるか確認します。網走をこんにちは、あばしりに変更します。OK")}お行儀が悪いですがmainブランチにPushします。Eventsの設定を仕込んであります。Eventsで検知しパイプラインが走りはじめました。切り替えの状態まで来ました。80番ポートは以下の表示8080番ポートは以下のひらがな表示トラフィックの再ルーティングをクリックすると、80番ポートの表示はひらがな表示に切り替わりました。CodeCommitの特定ブランチの変更をトリガーにしたBlue/Greenデプロイに成功を確認できました。Bitの設定検証用途でCI/CDがたびたび必要になったためテンプレートにまとめました。同時にCodePipelineでモノレポのような構成(アプリコンテナと、FireLensコンテナ)の場合、どうビルドして、どのようにデプロイするのか検証しました。この場合レポジトリにあるソースコードを全ビルド・全デプロイの構成をとるしかありませんでした。上手いことできないかと試してみたのですが簡単な手法は思いつきませんでした。Bit用のレポジトリと分けたとします。Bitが起動する都合、同じタスク内で共にコンテナとして起動します。双方のレポジトリから別々のパイプラインでデプロイしたくても、CodeDeployの仕様でECSのサービスにつき1つのデプロイグループしか関連付けられません。デプロイ方法が課題でこのパターンは断念しました。