はじめに
前回、ローカルのOrbStackでちょっとしたWebサービスを作りました。
今回はそのdockerイメージをGitHub ActionsでECRへ自動pushする設定を進めたいと思います。
主な流れは以下の通りです。
事前準備（AWS側）
├── ECRリポジトリを作成
└── IAMユーザーの作成（GitHub Actionsが使う）
└── アクセスキーを発行
事前準備（GitHub側）
└── シークレットの登録
├── AWS_ACCESS_KEY_ID
├── AWS_SECRET_ACCESS_KEY
└── AWS_REGION
ワークフロー作成
└── .github/workflows/deploy.yml
├── mainブランチへのpushをトリガー
├── Dockerイメージをビルド
├── ECRにログイン
└── ECRにpush
事前準備（AWS）
今回はAWSコンソールで作成します。（terraform化についてはまたの機会に）
ECRリポジトリを作成
設定項目
- リポジトリ名：flask-to-ecs（名前空間はなしでOK）
- タグのイミュータビリティ：Mutable（今回はこれでOK）
- 暗号化設定：AES-256（デフォルトでOK）
- イメージのスキャン設定：無効（検証なので、気にしない）
リポジトリが作成されるとURIが発行されます。
123456789.dkr.ecr.ap-northeast-1.amazonaws.com/flask-to-ecs
このURIは後で使うのでメモしておきます。
IAMユーザを作成
設定（ポイントだけ）
- ユーザー名：github-actions-user（分かり易い名前で。）
- AWSマネジメントコンソールへのアクセス：チェックしない
⇒コンソールログインは不要。APIアクセスのみでOK - アタッチするポリシー：AmazonEC2ContainerRegistryPowerUser
これでECRへのpushに必要な権限が付与できます。
IAMユーザができたら、アクセスキーを作成します。
作成したユーザーをクリック → セキュリティ認証情報タブ → アクセスキーを作成 → ユースケース:「サードパーティのサービス」を選択 → アクセスキーIDとシークレットキーを忘れずにメモ（この画面だけ！）
⚠️ シークレットキーはこの画面を閉じると二度と見れないので必ずメモしてください！
事前準備（GitHub側）
GitHub Secretsの登録手順
続いてGitHubの設定。先程設定したAWSのアクセス情報をシークレットに登録していきます。
GitHubのリポジトリページでSecret登録画面へ移動しましょう。
Settings → Secrets and variables → Actions → New repository secret
GitHub Actionsのシークレット入力画面（初期）
登録するシークレット
1つずつ「New repository secret」で追加してください。
まずはAWSのアクセス情報
名前: AWS_ACCESS_KEY_ID 値: さっきメモしたアクセスキーID 名前: AWS_SECRET_ACCESS_KEY 値: さっきメモしたシークレットキー 名前: AWS_REGION 値: ap-northeast-1
ECRのURIも登録しておきましょう
名前: ECR_REGISTRY 値: 1234XXXXX.dkr.ecr.ap-northeast-1.amazonaws.com 名前: ECR_REPOSITORY 値: flask-to-ecs
合計5つ登録します。
登録後はこのような感じになります。
ワークフローファイルの作成
次に今回のメインとなるワークフローの本体、ワークフローファイルを作成します。
まずはローカルリポジトリでディレクトリを作成。
mkdir -p .github/workflows
.github/workflows/deploy.yml
ポイントをコメントで記載しました。
# ワークフローの名前
name: Deploy to ECR
# トリガー：mainブランチへのpushで実行
on:
push:
branches:
- main
# Node.js 24を強制（警告対策）
env:
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
jobs:
deploy:
# GitHubが用意したUbuntu環境で実行
runs-on: ubuntu-latest
steps:
# リポジトリのコードをランナーに取得
# uses: 公開されているActionを使う宣言
- name: ソースコードをチェックアウト
uses: actions/checkout@v4
# AWSの認証情報を設定
# with: Actionに渡すパラメーター
# secrets: GitHubに登録した秘密情報
- name: AWS認証
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ${{ secrets.AWS_REGION }}
# ECRへのログイン
# id: 後のステップから参照するための識別子
- name: ECRにログイン
id: login-ecr
uses: aws-actions/amazon-ecr-login@v2
# イメージのビルド＆プッシュ
# run: シェルコマンドを直接実行
# env: このステップ内で使う環境変数
# github.sha: コミットのハッシュ値（自動で取得）
- name: Dockerイメージをビルド＆プッシュ
env:
REGISTRY: ${{ secrets.ECR_REGISTRY }}
REPOSITORY: ${{ secrets.ECR_REPOSITORY }}
IMAGE_TAG: ${{ github.sha }}
run: |
docker build -t $REGISTRY/$REPOSITORY:$IMAGE_TAG ./app
docker tag $REGISTRY/$REPOSITORY:$IMAGE_TAG $REGISTRY/$REPOSITORY:latest
docker push $REGISTRY/$REPOSITORY:$IMAGE_TAG
docker push $REGISTRY/$REPOSITORY:latest
ポイント
IMAGE_TAGについて → github.sha（コミットのハッシュ）をタグに使用 → latestも同時に更新 → どのコミットのイメージか追跡できる 例） latest ← 常に最新 a1b2c3d4...（省略） ← コミットと紐づいたイメージ
ワークフローファイルの各要素等について簡単に補足。
uses → 公開されているActionを使う宣言
actions/checkout など公式・サードパーティ製がある
with → Actionに渡すパラメーター
認証情報やリージョンなどを指定
id → 後のステップから結果を参照するための識別子
run → シェルコマンドを直接実行
複数行は | を使う
env → 環境変数の定義
secrets.XXX でGitHub Secretsを参照
${{ github.sha }}
→ GitHubが自動で提供する変数（コンテキスト）
コミットハッシュをイメージタグに使うことで
どのコミットのイメージか追跡できる
動作確認
動作確認といっても特別な事をするわけではなく、単にリポジトリのmainブランチにpushするとワークフローが実行されます。
git add . git commit -m "ci: GitHub ActionsでECRへの自動ビルド＆プッシュを追加" git push
ワークフローの確認
GitHubリポジトリのActionsタブを開くと、ワークフロー名毎に実行された履歴を確認できます。
下の図は3回ほどコミット＆pushした状態です。ワークフローはコミットコメントがタイトルとして表示されています。
さらに各実行履歴を見ると各ステップの状況を確認することが出来ます。
AWS ECRの状態
ECRコンソールでリポジトリを確認すると、イメージがpushされていることが確認できました。
ワークフローの警告について
ところで、ワークフロー自体は成功しているのですが、下図のように警告が出ています。
この警告は簡潔にまとめるとNode.jsのバージョン警告でした。
2行でまとめました。
2026年6月2日 → Node.js 24がデフォルトになる 2026年9月16日 → Node.js 20が削除される
念のため、この警告の対策としてNode.js 24 の強制を追加しています。
# Node.js 24を強制（警告対策） env: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
ただ、これを追加しても警告は消えなかったのですが、バージョン対応としては問題無いので、これで進めたいと思います。
ワークフローに関する補足
今回は個人レベルでの実装なので、直接mainブランチにコミットしてpush⇒ワークフロー起動！という流れとなっています。
ですが、一般な業務での流れは次のように開発ブランチでPRを承認してmainにマージされるという流れかと思います。
開発の流れ
feature/xxx ブランチで開発
↓
PRを作成
↓
レビュー・承認
↓
mainにマージ
↓
pushイベント発火 → GitHub Actions実行
この場合もワークフローは今のままで問題無く、ブランチ保護（mainブランチへのマージはPRを必須化する）を追加するだけで実務的な運用になります。
まとめ
ということで、GitHub ActionsでAWS ECRへdockerイメージをプッシュすることが出来ました。
次はこのECRイメージを使用したAWS ECSを作成してみたいと思います。
ではでは。
