[2025年2月18日から] Cloud Run Functions(第1世代)のデプロイが自動的にArtifact Registryに移行します

[2025年2月18日から] Cloud Run Functions(第1世代)のデプロイが自動的にArtifact Registryに移行します

Clock Icon2025.02.03

2025/1/30に[Important Clarification] Migrate your Cloud Run functions (1st generation) to Artifact RegistryというタイトルでCloud Run Functions(第1世代)のデプロイについての変更点がメール通知されましたので内容をまとめました。

概要

  • 2025年2月18日以降、Cloud Run Functions(第1世代)の新しいデプロイは、すべて自動的にArtifact Registryを使用
  • すでにデプロイされている関数については、Container Registryを使用している場合でも引き続き動作。ただし、再デプロイする場合はArtifact Registryが使用される

以前よりアナウンスされていたContainer Registry廃止にともない、これまで実施する様に呼び掛けられていたContainer RegistryからArtifact Registryへの移行作業は不要になるとのことです。
https://cloud.google.com/artifact-registry/docs/transition/transition-from-gcr?hl=ja

The previous communication stated that you may need to refer to the Container Registry transition guide. We wanted to clarify that this will not be necessary as we will begin using Artifact Registry automatically across all deployments starting on February 18, 2025. For more details, see “What you need to do.”
前回の連絡では、Container Registry移行ガイドを参照する必要があるかもしれないと述べました。2025年2月18日からすべてのデプロイメントで自動的にArtifact Registryの使用を開始するため、その必要はないことを明確にしたいと思います。(DeepL翻訳)

確認しておいたほうがよいこと

確認観点:

  • Artifact Registry APIが有効になっていること
  • Cloud Run Functionsをデプロイする際にカスタムビルドサービスアカウントを使用している場合はroles/artifactregistry.writerが付与されているか確認
  • 2024/5/3以降に組織を作成している場合、Compute Engineのデフォルトサービスアカウントにroles/artifactregistry.writerが付与されているか確認

以下の場合は影響ありません。

  • すでにArtifact Registry APIを有効にし、上記のIAMロールをカスタムビルドサービスアカウントに確認済みである場合
  • 第1世代の関数がArtifact Registryをイメージレジストリとして使用している場合
  • 第1世代の関数がFirebase CLIバージョン11.2.0(2022年6月30日リリース)以降で作成されたFirebase用Cloud Functionである場合
  • 関数がCloud Run関数(以前のCloud Functions第2世代)である場合

Cloud Run Functionsをデプロイする際にサービスアカウントを明示的に指定しない場合はCloud Buildのサービスアカウント、またはCompute Engineのサービスアカウントがビルドに使用されます。

Cloud Run functions は、Cloud Run 関数をビルドしてデプロイするときに Cloud Build を利用します。デフォルトでは、Cloud Run functions はビルドを実行する際にプリンシパルとして、デフォルトの Cloud Build サービス アカウントを使用します。

https://cloud.google.com/functions/docs/securing/build-custom-sa?hl=ja

Cloud Buildのサービスアカウントが使用されるか、Compute Engineのサービスアカウントが使用されるかは組織・プロジェクト作成・APIを有効化したタイミングによって変わりますのでご注意ください。
https://cloud.google.com/build/docs/cloud-build-service-account-updates?hl=ja

Compute Engineのデフォルトサービスアカウントを使用する場合で2024/5/3以降に組織を作成した場合は編集者ロールが付与されていないためデプロイのためにCloud Run Functions開発者などのロールを付与していると思います。この場合はroles/artifactregistry.writerを付与する必要があるのでご注意ください。
https://cloud.google.com/compute/docs/access/service-accounts?hl=ja#default_service_account

上記より、2024/5月以降に組織を作成した場合は、Compute Engineのデフォルトサービスアカウントにroles/artifactregistry.writer権限が付与されているか確認したほうが良いと考えます。
この場合、デプロイにはCloud BuildのデフォルトサービスアカウントではなくCompute Eingineのデフォルトサービスアカウントが使用されます。

Compute Engineのデフォルトサービスアカウントへ付与されている権限の確認方法の一例としては、以下のコマンドを発行します([PROJECT_ID/NUMBER]はご自身の環境に置き換えてください)。

gcloud projects get-iam-policy [PROJECT_ID] \
    --flatten="bindings[].members" \
    --format="table(bindings.role)" \
    --filter="bindings.members:[PROJECT_NUMBER]-compute@developer.gserviceaccount.com"

2024/5/3以降に組織を作成した場合のデフォルトでは何も権限が付与されていない状態です。

カスタムビルドサービスアカウントを指定している場合の例

gcloud functions deploy 関数名 \
  --gen2 \
  --region=asia-northeast1 \
  --runtime=python311 \
  --source=./ \
  --entry-point=get_file_names \
  --trigger-http \
  --build-service-account=projects/[PROJECT_ID]/serviceAccounts/***@[PROJECT_ID].iam.gserviceaccount.com

上記の通り。--build-service-accountにてサービスアカウントを指定します。
https://cloud.google.com/functions/docs/securing/build-custom-sa?hl=ja#deploy_a_function_with_a_custom_service_account

まとめ

Container RegistryからArtifact Registryへの移行作業は不要になったことはとてもありがたいですが、一方でArtifact Registryへの権限が付与されているか・APIが有効になっているかは確認したほうが良いと考えます(特に2024/5月以降に組織を作成した場合)。

それではまた。ナマステー

参考

https://dev.classmethod.jp/articles/update-cloud-build-default-service-account/

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.