🚀

【GCP🐳】まだArtifact Registryに移行してないアナタへ

2022/08/20に公開

Docker

記事にしたきっかけ

私はGCP上で組まれたプロジェクトを動かしているのですが、時間ができた時にArtifact Registryに移行したいと思っています。
その際に一体何が変わるのか概要を掴んでおきたく、手頃な記事が少なかったのでまとめてみました。

比較テーブル

機能	Container Registry	Artifact Registry
サポート対象のファイル形式	コンテナイメージのみ	コンテナイメージ、Java パッケージ、Node.js モジュールなど、複数のアーティファクト形式（※パッケージリポジトリはアルファ版です。）
リポジトリ	これまでイメージを push したことがない場合、マルチリージョンにリポジトリを自動的に作成します。	イメージを push する前にリポジトリを作成する必要があります。マルチ・単体リージョンのいずれかに作成できます。
組織	Google Cloud プロジェクト内の同じマルチリージョンホスト上のリポジトリはすべて、単一のストレージバケットを共有します。	リージョンまたはマルチリージョンごとに、個別のリポジトリを作成できます。ラベルを適用して、チーム、開発段階、その他のカテゴリ別にグループ化します。
アクセス制御	プロジェクトレベルまたはマルチリージョンホストごとにストレージバケットに対して権限を付与します	プロジェクトまたは個々のリポジトリに対する権限を付与します。
ホスト名	ホストは gcr.io ドメインにあります。	ホストは pkg.dev ドメインにあります。名前の形式の詳細についてはリポジトリとアーティファクトの名前をご覧ください。
権限	Cloud Storage の権限を使用してアクセス権を付与する。個々のリポジトリではアクセスを制限することはできません。	Artifact Registry の権限を使用してアクセス権を付与する。個々のリポジトリへのアクセスを制限できます。
顧客管理の暗号鍵（CMEK）	CMEK を使用して、イメージを含むストレージバケットを暗号化する。	個々のリポジトリを暗号化するには、CMEK を使用します。
Pub/Sub 通知	gcr トピックの変更を公開します。	gcr トピックの変更を公開します。既存の Container Registry サービスと同じプロジェクトにリポジトリを作成すると、既存の Pub/Sub 構成が自動的に機能します。
料金	ストレージと外向きネットワークを含む Cloud Storage の使用量に基づいています。	ストレージと外向きネットワークに基づいて独自の料金が設定

つまり...Artifact Registryのいい所は💭

複数のアーティファクト形式で保存が可能になった
より細かい権限管理ができるようになった
リージョンリポジトリの作成をサポートされたことにより適切な場所を選んでイメージ等を置けるようになった。
リージョンを尊重した料金モデル　お金周りは特に気になる所ということで以下引用

Artifact Registry の料金体系は、下り（外向き）ネットワークとストレージ使用量の組み合わせに基づいていますが、リージョンリポジトリをサポートしています。つまり、コンテナリポジトリをホストするリージョンを選択可能であることを意味しています。ユニットあたりのストレージの費用は Artifact Registry の方が高くなりますが、リポジトリの地域を最適化し、使用するリージョンと同じリージョンにホストすることで、結果としてコスト削減につながります。同一リージョン内のネットワークトラフィックは下り（外向き）とは見なされず、無料となるためです。

Container Registry はどうなるの？

Container Registry は現在も利用可能で Google Enterprise API によるサポートは継続されますが、リリースされる新機能は Artifact Registry でのみ利用可能で、Container Registry では重要なセキュリティ修正のみが適用されます。

今からGCPでCI/CD組むならContainer Registryを使う必要はなさそうですね！

Artifact Registry についてちょっと詳しくみてみる

あらゆるビルドのアーティファクト管理

Container Registry の進化形である Artifact Registry は、組織がコンテナイメージと言語パッケージ（Maven や NPM など）を 1 か所で管理できる場所になりました。これは Google Cloud のツールとランタイムと完全に統合されており、ネイティブのアーティファクトプロトコルのサポートが付属します。これにより、CI / CD ツールと簡単に統合して自動化パイプラインを設定できるようになりました。

キャッシュされた Docker Hub のイメージは？🐥

mirror.gcr.io で引き続き、Docker Hub から頻繁にリクエストされるイメージがmirror.gcr.io にキャッシュされます。キャッシュに保存された公開イメージが使用可能な場合はそれを使用して Docker デーモンを構成でき、キャッシュに保存されたコピーがない場合は Docker Hub からイメージを pull しています。

（コンテナ動かしている時はキャッシュを意識してみると解決することが多いです）⇦を意識していることでコンテナ系の記事を見る際に読みやすくなったと感じています。

Google が提供するイメージは、引き続き gcr.io で利用できます🐥

どちらのプロダクトも、Pub/Sub 通知に同じ「gcr」トピックを使用します。つまり、「gcr」トピックへの既存のサブスクリプションには、Artifact Registry と Container Registry の両方の通知が含まれています。

どちらのプロダクトも同じ Container Analysis API を使用します。Container Registry または Artifact Registry のどちらかで Container Analysis API を有効にすると、両方のプロダクトで API が有効になります。

Container Analysis は、Artifact Registry と Container Registry の両方で、コンテナイメージのメタデータ保存と脆弱性スキャンをサポートしています。

記事を読んで頂き

最後まで記事を読んで頂きありがとうございます！
また、前回の記事で沢山のいいねを頂きありがとうございました！
良いね貰えると記事を書くモチベに繋がるのでとても嬉しいです🥺！

移行ドキュメント