refirio.org

■タスク定義ファイル作成 ※この「タスク定義ファイル作成」という手順自体、丸ごと不要だったりするか アプリケーションのリポジトリに taskdef.json を含めても、参照されている気配が無い そもそもこの内容は、プログラムからでは無くAWSコンソールから設定すべき（アプリケーション開発者に触らせるべきものではない）もののような 環境変数の値も、リポジトリ内のコードに含めると変数化している意味が無いような アプリケーションのリポジトリに含めることができたとして、緊急でAWSコンソールから編集した場合のことを考える必要がある ※以下によると「AWSコンソールから管理できるが、必要ならコードでも管理できる。それぞれ一長一短」みたい。ひとまず、タスク定義ファイルは作成しない方針でいいような ECSタスク定義をコンソールから作って後悔した後、コード管理するため最速でJSON登録可能にする超愚直な方法 | DevelopersIO https://dev.classmethod.jp/articles/ecs-task-definition-to-json/ ※引き続き要検証 ★Fargateで再検証するにあたって、ひとまずこの「タスク定義ファイル作成」という手順を丸ごと飛ばして以降の検証を進めている Elastic Container Service → Amazon ECS → タスク定義 → Container-Test-Task 最新のリビジョンのページ内で「JSON」タブに表示される内容をもとに、taskdef.json というファイルを作る その際、イメージの指定部分を「"image": "<IMAGE1_NAME>",」に調整し、さらに以下の項目を削除する ・taskDefinitionArn ・revision ・status ・requiresAttributes ・compatibilities FargateではなくEC2の場合、動的ポートマッピングのために、hostPortは「0」にしておく（もとからそうなっているなら問題無い） describe で出力した ECS タスク定義をさくっと登録可能な形に整形する | Stuck inside https://blog.msysh.me/posts/2020/12/transform_task_definition_by_describe_to_be_able_to_register.htm... describe-task-definitionで取得したJSONはそのままではregister-task-definitionで登録できないお話 | DevelopersIO https://dev.classmethod.jp/articles/describe-task-definition-to-register-task-definition/ 内容は異なるが、以下は参考までにファイル内容の具体例 sbcntr-resources/taskdef.json at main - uma-arai/sbcntr-resources https://github.com/uma-arai/sbcntr-resources/blob/main/cicd/taskdef.json このファイルはコミット＆プッシュし、アプリケーションのリポジトリに含めておく リポジトリ直下に配置するのが一般的かもしれないが、今回は以下に配置してみる（Dockerに関するファイルは docker フォルダにまとめる） 値がnullの項目は削除できるかもしれないが、そのままでも支障はないはず 参考までに、以下は実際に登録した内容 ※まだ不要な情報を削れるかもしれない docker\ecr_php81_apache\taskdef.json ■CodePipelineを作成 ※「Container-Test」というパイプライン名は、実際は案件名と環境をもとに付けると良さそう CodePipeline → パイプライン → パイプラインを作成する パイプラインの設定を選択する パイプライン名: Container-Test サービスロール: 新しいサービスロール（以前作成したものがあれば「既存のサービスロール」を選択する） ロール名: AWSCodePipelineServiceRole-ap-northeast-1-Container-Test（パイプライン名を入力すると、自動で入力された / 以前作成したものがあれば選択する） 「次に」ボタンをクリック ソースステージを追加する ソースプロバイダー: Bitbucket 接続: Bitbucketに接続（パイプラインを再作成する場合、以前作成したものを選択した） 接続名: Container-Test ※この接続名は、本番・検収・開発で共通して使う想定で良さそう 「Bitbucketに接続」ボタンをクリック Bitbucketへのログインを求められるのでログイン 以下の許可を求められるので許可する AWS CodeStar is requesting access to the following: ・アカウント情報の読み取り ・あなたの所属するチーム情報を読み取る 「接続」ボタンをクリック Bitbucketアプリ: 「新しいアプリをインストールする」ボタンをクリック アクセスの許可を求められるので許可 以下の許可を求められるので許可する AWS CodeStar requests access ・アカウント情報の読み取り ・リポジトリとそのプルリクエストを確認する ・自分のリポジトリの管理 ・リポジトリを確認し修正する Authorize for workspace: refirio（対象のリポジトリがあるプロジェクトを選択する） 「アクセスを許可する」ボタンをクリック 「接続」ボタンをクリック もとの画面に戻って「接続する準備が完了しました」と表示されることを確認する リポジトリ名: refirio/ecr_php81_apache ブランチ名: master 検出オプションを変更する: 「ソースコードの変更時にパイプラインを開始する」にチェックを入れる 出力アーティファクト形式: CodePipeline のデフォルト 「次に」ボタンをクリック ビルドステージを追加する プロバイダーを構築する: AWSCodeBuild リージョン: アジアパシフィック(東京) プロジェクト名: Container-Test（選択対象に表示されるので選択する） ビルドタイプ: 単一ビルド 「次に」ボタンをクリック デプロイステージを追加する デプロイプロバイダー: Amazon ECS リージョン: アジアパシフィック(東京) クラスター名: Container-Test-Cluster サービス名: Container-Test-Service イメージ定義ファイル: imagedefinitions.json 「次に」ボタンをクリック レビュー 「パイプラインを作成する」ボタンをクリック 「成功」と表示されるのを確認する 引き続き、各処理がそれぞれ実行されていくのを確認する 「Source」はすぐに「成功しました」となった その2〜3分後くらいに、「Build」が「成功しました」となった その4〜5分後くらいに、「Deploy」が「成功しました」となった 合計10分ほどでデプロイが完了したが、本番反映自体は3〜4分ほどでされていた（以降は不要なタスクやターゲットグループの削除） どんなにイメージのビルド時間を短くしても、デプロイ完了までは5〜6分程度かかるかもしれない（デプロイ時間については、後述の「デプロイ時間の短縮」も参照） 以降は、プログラムの修正をmasterブランチにコミット＆プッシュするだけで、処理が開始されデプロイされる （developブランチの内容をmasterにマージ＆プッシュとしても、同様に処理される） プッシュすると、すぐにCodePipelineの「Source」処理が始まる なお、本番反映時に30秒程度、新旧が混在する状態が続く これは恐らく標準デプロイ（ローリングアップデート）の仕様で、避けるためにはBlue/Greenデプロイにする必要があると思われる ■問題の修正1 「Build」で「失敗しました」となった 詳細から「実行の詳細へのリンク」を表示すると、以下が表示される イメージのプッシュができなかったみたい すでに指定のタグ名でイメージがビルド＆プッシュ済みになっているからだった （タグの上書きを禁止している） リポジトリでプログラムを微調整してコミット＆プッシュしてみる パイプラインが「進行中」になった CodeBuildの画面でも「進行中」になっているので、詳細を見つつ見守る 今度はビルドが成功した ■問題の修正3 「Deploy」で「失敗しました」となった 詳細を表示すると、以下が表示される docker/buildspec.yml に記述ミスがあったので修正して再実行したところ、デプロイも進むようになった 「詳細」をクリックすると Container-Test-Service に遷移した 「デプロイメント」を確認すると、すぐに完了していた 「イベント」を確認すると「service Container-Test-Service was unable to place a task because no container instance met all of its requirements. The closest matching container-instance 653f223309c54e67b32b21e6ea8e8408 is already using a port required by your task. For more information, see the Troubleshooting section.」と表示されていた しばらくして「タスク定義」と「サービス」を確認すると、更新されていた ただし、いつまで待っても「タスク」が置き換わらなかった ■問題の修正4 15分以上待っても「タスク」が置き換わらなかったので「停止して中止」にした CodePipelineなしでも発生していたものと同じ現象だったので、動的ポートマッピングを設定すると完了できた 動的ポートマッピングに対応した taskdef.json をコミットしてもデプロイできない場合、 あらかじめAWSコンソール上で動的ポートマッピングに対応させてデプロイを行っておいてから再度試す （デプロイ前の時点で動的ポートマッピングに対応している必要があるのかもしれない。そもそも今回は taskdef.json が参照されていないようにも思う）