【図解】AWS ECR / ECSとDockerを活用した効果的なCI/CDフロー：GitHub Actionsを添えて〜
はじめに
こんにちは、Takeです。都内の自社開発企業でエンジニアとして働いています。
本記事では、AWS ECR / ECSとDocker、そしてGitHub Actionsを活用したCI/CDフローの全体像を図解します。
具体的な構築手順には触れず、これらの技術がどのように組み合わせられているかに着目し視覚的に解説していきます。
主な使用技術
- VSCode：コーディング用のエディタ
- GitHub Actions（GA）：コード変更を自動でビルド、テストするCI/CDツール
- Docker：アプリをコンテナ化するツール
- AWS
- ECR (Elastic Container Registry)：Dockerコンテナイメージを管理するサービス
- ECS (Elastic Container Service)：コンテナ管理とオーケストレーションサービス
全体の流れ
- 開発者がVSCodeでコードを変更し、GitHubにpushする。
- GAがpushをトリガーにビルドやテストを実行し、Dockerを使用してコンテナイメージを作成。
- このイメージはAWS ECRに保存されてAWS ECSでデプロイされる。
パートごとに解説
コードがpushされてからGitHub Actions(GA)まで
以下のコマンドでローカルブランチの変更をリモートのGitHubリポジトリにpushする。
git add ~
git commit -m "commit message"
git push origin HEAD
すると、コードはGAに送られて自動的にビルドやテストが行われる。この際、Dockerがコンテナイメージを作成する。
GAからAWS ECRへ
ビルドとテストが成功したDockerイメージは、AWS ECR にアップロードされる。
補足として、ECR（Elastic Container Registry）はAWSのマネージドコンテナレジストリーサービスであるといわれてもパッとしないので、ECRの主な役割はDockerイメージの管理を行うサービスと覚えておこう。
具体的には、IAMを使用したアクセス制御やプライベートネットワーク接続に対応し、セキュリティの高い環境でコンテナイメージを管理できるメリットがある。
また、ECSとの関係では、ECSがECRからコンテナイメージを直接取得し、オーケストレーションとスケーリングを管理する連携プレーも魅力的だ。
これらの一連のプロセスにより、開発からデプロイまでのワークフローをセキュアかつオートメーション化して効率的な保守運用が可能となる。
AWS ECRからECSへ
続いてECRに保存されたDockerイメージは、ECSによってpullされて、必要な設定や初期化を行うentrypoint.shスクリプトが実行される。
pullとは、「ECS」がECRのコンテナレジストリからコンテナイメージを取得するプロセスを指す。具体的には、ECSがECRに保存されているコンテナイメージを取得しコンテナを起動する操作を行う。これにより、正確なバージョンのもとアプリケーションを管理できる。
pullについて着目👀
ECSからアプリケーション反映まで
上記では主に「Kick」の概念に着目する。
ECSでコンテナが起動するとアプリケーションが稼働し始める。ここで「kick」というプロセスが生じることがある。ECSにおいては特定のタスクが実行されたことを指し示す際に用いられることがある。（誤っていたらお手数ですがコメント頂けたら幸いです、kickを使ってみたかった⚽️）
具体的には、ECSがタスク定義に従って新しいタスクインスタンスを起動する行為、すなわちコンテナイメージを実際のコンテナとしてデプロイしてアプリケーションを稼働させる過程を指す。
このプロセスを通じて、ECSは指定された設定に基づき自動的にコンテナを配置しアプリケーションが予定通りに動作するよう管理する。
kickについて
参考
最後に
ここまで読んでいただきありがとうございました！
今回の記事が良かったと思ったらぜひ「いいね」を押していただけると嬉しいです 🎉
noteでも記事を執筆していますので、ぜひチェックしてみてください。
他にもこのようなことについて記載しているのでお読みいただければ幸いです。
最後までお読みいただき、誠にありがとうございました！
Discussion