レジストリを選ぶ - registry
Docker Hub・GHCR・ECR・GCR・Harbor などの主要レジストリを、公開／プライベート・認証方式・コスト観点で比較する。
概念図
構文
# ログインホストはレジストリごとに異なる
docker login # Docker Hub
docker login ghcr.io # GitHub Container Registry
docker login <acct>.dkr.ecr.<region>.amazonaws.com # AWS ECR
docker login <region>-docker.pkg.dev # GCP Artifact Registry
docker login harbor.example.com # Harbor実例
GHCR は GITHUB_TOKEN で同一 Organization 内に push できる
# GitHub Actions から GHCR に OIDC ではなく GITHUB_TOKEN で push
- uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}ECR は OIDC で短命クレデンシャルを受け取るのが安全
# GitHub Actions から ECR に OIDC で push
- 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公開レジストリ比較
代表的な公開／クラウドレジストリの特徴は以下の通り。
| レジストリ | ホスト | 認証 | 強み | 注意点 |
|---|---|---|---|---|
| Docker Hub | docker.io |
ユーザー/PAT | 最大の公開レジストリ。公式イメージが豊富 | 無料枠は匿名 pull のレート制限（IP あたり 100 回 / 6 時間）があり CI で引っかかりやすい |
| GitHub Container Registry (GHCR) | ghcr.io |
GITHUB_TOKEN / PAT |
GitHub との統合が強く、リポジトリの公開範囲に合わせて権限を管理できる | 権限設定がリポジトリ/Org に紐付く |
| AWS ECR | *.dkr.ecr.*.amazonaws.com |
AWS IAM（短命トークン） | IAM と統合し、Fargate や EKS からの pull を IAM ロールで認可できる | リージョン・アカウント単位の運用 |
| GCP Artifact Registry（旧 GCR） | *-docker.pkg.dev |
GCP IAM | GCP プロジェクト単位で権限管理 | リポジトリ作成・リージョン指定が必要 |
| Azure Container Registry (ACR) | *.azurecr.io |
Azure AD / アクセストークン | Azure リソースと統合、Alibaba / Huawei にも類似サービス | SKU でレプリケーション等の機能差あり |
# レジストリと特徴の対応
# docker.io (Docker Hub) : 公開最大・レート制限あり
# ghcr.io : GitHub 連携・GITHUB_TOKEN 可
# *.dkr.ecr.*.amazonaws.com: IAM 連携・AWS 内で完結
# *-docker.pkg.dev : GCP Artifact Registry
# *.azurecr.io : Azure ACRプライベートレジストリの選び方
自社運用のプライベートレジストリが必要な場合、候補は registry:2（公式オープンソース）と Harbor、JFrog Artifactory、Sonatype Nexus、AWS ECR のプライベートリポジトリなど。
registry:2 は最小限の機能（push/pull・認証）しか持たないため本格運用には辛く、UI・RBAC・脆弱性スキャン・レプリケーションが必要なら Harbor が定番。
マネージドに寄せたいなら各クラウドのレジストリが運用負担が小さい。
選定軸は、オンプレ／クラウドの要件、RBAC の粒度、脆弱性スキャン、イメージ署名（cosign）と Notation のサポート、レプリケーション、コスト、既存の ID 基盤との連携。
認証方式（PAT / OIDC / IAM）
認証は大きく 3 系統。
PAT（Personal Access Token）は GitHub・Docker Hub などで発行する長寿命の個人トークンで、設定は簡単だが漏洩時の影響が大きく、定期ローテーションが必要。
OIDC は GitHub Actions などの CI が発行する短命トークンで、信頼関係を結んだクラウド IAM（AWS、GCP、Azure）と交換して、そのジョブの間だけ有効なクレデンシャルを得る方式。
シークレット長期保管が不要になる点が大きい。
IAM は AWS・GCP などのネイティブ認可で、EC2／EKS／Cloud Run のワークロードアイデンティティから追加シークレットなしでレジストリにアクセスできる。
可能なら PAT より OIDC / IAM を優先する。
# GitHub Actions -> AWS IAM (OIDC)
permissions:
id-token: write
contents: read
steps:
- 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