Dock Stay
レジストリへ push する - registry push の使い方・オプション・サンプル
Dock Stay

レジストリへ push する - registry push

ビルドしたイメージはレジストリに push して初めて本番で使える。GHCR・ECR・GAR・Docker Hub など目的地ごとに認証・命名・保管ポリシーが異なる。

概念図

registry push diagram

構文

bash
docker push <registry>/<namespace>/<repo>:<tag>

実例

OIDC で短命クレデンシャルを得て ECR に push する。

bash
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/gha-ecr-push
    aws-region: ap-northeast-1
- uses: aws-actions/amazon-ecr-login@v2
- uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    tags: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/app:${{ github.sha }}

主要レジストリの比較

レジストリ ホスト 認証の定番 主な特徴
GHCR ghcr.io GITHUB_TOKEN / PAT リポジトリと権限を統合管理。public / private を細かく切り替え
Docker Hub docker.io アクセストークン 知名度が高いが、匿名 pull のレート制限が厳しい
AWS ECR <acct>.dkr.ecr.<region>.amazonaws.com IAM（OIDC 推奨） VPC エンドポイント経由で AWS 内に閉じられる
Google Artifact Registry <region>-docker.pkg.dev Workload Identity Federation GCP 内の IAM / 組織ポリシーが活きる
Azure Container Registry <name>.azurecr.io Entra ID / アクセストークン Entra ID 側のロール管理と統合

個人・OSS は GHCR / Docker Hub、クラウド本番は自社クラウドの純正レジストリ（ECR / GAR / ACR）に押し込むのが素直です。

認証: 長期キーから OIDC へ

伝統的な方法は「アクセスキー / シークレット」を CI の Secrets に保存することでしたが、漏洩時の影響が大きいため、短命クレデンシャル + OIDC への移行が進んでいます。

  • AWS ECR: aws-actions/configure-aws-credentials@v4 が GitHub Actions の OIDC を使って sts:AssumeRoleWithWebIdentity を実行する。IAM 側で信頼ポリシーを設定すれば、長期 Access Key を置かずに済む
  • Google Artifact Registry: Workload Identity Federation で同様に OIDC からサービスアカウントになり代わる
  • Azure Container Registry: GitHub Actions OIDC → Entra ID のフェデレーション資格情報

GHCR や Docker Hub はこの流れに完全には乗っていませんが、PAT のスコープを push 対象リポジトリに絞る／回数制限のある組織トークンを使う、等の運用で限定的に代替します。

タグ戦略と保管ポリシー

本番で推奨されるのは次の 3 種の併用です。

  • 不変タグ: sha-<short> / v1.2.3 のようにビルド成果物を 1:1 で指す。デプロイ・ロールバックはこれを指定する
  • 可変タグ: latest / main / stable のように「今の最新」を指す。ローカル開発の pull だけに使う
  • 環境タグ: prod / staging のように「今その環境で動いている版」を指す。デプロイ成功時に不変タグへ再アサインする運用にすると、環境別の最新がすぐわかる

イメージは放っておくとどんどん溜まるので、保管ポリシー（retention）で「最新 N 件を残す」「タグなしは X 日で削除」といったルールを設定します。

ECR なら Lifecycle Policy、GHCR なら Container retention、GAR なら Cleanup policies が相当機能です。

プッシュ前後の安全策

push は「ここから配布が始まる」瞬間なので、その前後に薄いチェックを足すとインシデントが減ります。

  • push 前: イメージスキャン（Trivy 等）を失敗で止める／ベースイメージが想定どおりか docker/metadata-action の annotations で確認
  • push 時: sigstore (cosign) で署名する。検証する側は cosign verify で改ざんを検出できる
  • push 後: SBOM（Software Bill of Materials）を生成してアーティファクトに同梱する。GitHub Actions の anchore/sbom-action などが手軽

これらは「1 回だけ通せば満足」ではなく、全ブランチの全 push に機械的に組み込むのが本来の姿です。

関連トピック

GitHub Actionsbuildx cachescan in CI