Container RegistryからArtifact Registryへ移行する

2023.08.16 2023.09.01 XIMIX 江口

　　　　　　　　無題のプレゼンテーション

はじめに

Container Registryが2023年5月15日より非推奨化、2024年3月15日に廃止されるという発表がすでに出ています(Container Registry のサポート終了)。これに伴い、コンテナイメージをContainer Registryに保存していた場合にはArtifact Registryへ移行する必要があります。

移行自体は特段難しい話ではありませんが、移行先であるArtifact Registryとは何なのかという話と、移行の仕方、そして個人的に気にかけておくべきと思ったことをご紹介します。

Artifact Registryとは

公式の記述からかいつまんで言うと、以下の通りです(Artifact Registry の概要)

Artifact Registry は、パッケージと Docker コンテナイメージを 1 か所で保管し管理できる場所として機能します。

Artifact Registry は Container Registry の機能を拡張したもので、Google Cloud に推奨されるコンテナレジストリです。

「拡張」として主だったものとしては、Container Registryが名前の通り「コンテナ」のためのものでDocker リポジトリを管理Artifact Registryしていたのに対して、Artifact RegistryではJava,Node.js,Pythonなどのパッケージについても管理できる点です。

2023年8月15日現在でサポートされているのは以下の通りでした。

Docker
Maven
npm
Python
Apt
Yum
Kubeflow パイプライン
Go

またセキュリティ面では、リポジトリごとに権限を付与できるようになりました。これにより、同一プロジェクト上で複数のアプリケーション用パッケージ/イメージを管理するとしても、それぞれに対して権限を細やかに管理できます。

コンテナイメージの互換性

「コンテナイメージを管理する」という点においてContainer Registryから変更はありませんので、これまでContainer Registryに配置していたイメージをそのままArtifact Registryに移せば問題ありません。

Container Registryからの移行

移行にあたって気を付けるべきは、イメージのパスです。

Artifact Registryに移行することでイメージのパスが変わってしまうので、Cloud RunやGKEなどで指定しているパスがある場所は忘れずに変更しましょう。

※パスを変えずにリダイレクトさせるようにも設定できますが、ここでは公式手順のみ記載して割愛します(gcr.io ドメインをサポートするリポジトリを設定する)

例
Container Regsistry
asia.gcr.io/test-project/hello-image:latest
Artifact Registry
asia-northeast1-docker.pkg.dev/test-project/repo-hello/hello-image:latest

手順としては以下の通りです。

Artifact Registryのリポジトリを新規作成する
Artifact Registryへの権限付与(プロジェクト単位またはリポジトリ単位)を実施する
(リダイレクト設定以外の場合)コンテナイメージへのパスを変更する

注意事項

認証

Artifact Registry側を作成したあと、利用する上での手順として忘れられがちなのが、gcloud 認証情報ヘルパーです。

リポジトリを作成したリージョンごとに認証を通しておかないと、dockerコマンドによるリポジトリへの操作が出来ません。
例) us-central1とasia-northeast1に作ったリポジトリに対してdockerコマンドを実行したい場合に必要な認証
$ gcloud auth configure-docker us-central1-docker.pkg.dev,asia-northeast1-docker.pkg.dev
※ただし以下にも注意！
警告: Docker 認証ヘルパーは、Docker 18.03 以降でのみサポートされています。以前のバージョンの Docker クライアントのバグにより、認証情報ヘルパーが構成されていると docker build が大幅に遅くなります。

厄介なのが、この認証を設定していないときに出るメッセージが、この認証に起因していなさそうなものであることです

認証していない状態でdocker pushした際のエラー出力
denied: Permission "artifactregistry.repositories.uploadArtifacts" denied on resource "projects/test-project/locations/asia-northeast1/repositories/repo-hello" (or it may not exist)
また、ローカルなど手元の環境で一度通してしまえば良いですが、CI/CDのパイプラインを構築していて、ビルド後にイメージをArtifact Registryにpushする、などしている場合にも忘れないようにしましょう。
Cloud Functionsからの利用

Cloud Functions(第一世代)でデプロイをする際、ビルドの動きに起因するのか裏側ではContainer Registryが利用されています。(Cloud Functions イメージのビルド)。

現時点で公式ドキュメントにある記載からは定かではないですが、Container Registryが廃止された後にCloud Functionsのアプリケーションが使えなくなったり、使えたとしても次のデプロイの際に失敗するなどの影響が出るかもしれません。

Artifact Registryを指定する方法は、画面上での選択やデプロイコマンドのオプション --docker-registryを用いるなどが公式から示されています(イメージレジストリのオプション)。

まとめ

セキュリティへの対応であったり、上位互換サービスが出たりするなどで、使っていたサービスが非推奨/廃止になっていくのはどんなサービスでも考えられることです。
コンテナイメージの管理という、あまり前面に出てくることのないサービスの廃止ではありますが、アプリケーションのデリバリーに関わってくる点で実際には影響の大きい変更です。それもあってか、比較的アナウンスも強く、移行についてもやりやすくなっているかなという印象です。

ぜひ早めに対応をしていきましょう。