チュートリアル: Cloud Run での Filestore の使用

---

このチュートリアルでは、Filestore をネットワーク ファイル システムとして Cloud Run サービスにマウントし、複数のコンテナとサービス間でデータを共有する方法について説明します。このチュートリアルでは、Cloud Run の第 2 世代の実行環境を使用します。

注: Filestore を使用するインスタンスでは、最低月額費用が高額になります。料金について懸念がある場合は、費用についての説明をご覧ください。

第 2 世代の実行環境では、ネットワーク ファイル システムをコンテナ内のディレクトリにマウントできます。ファイル システムをマウントすると、ホストシステムとインスタンスの間でリソースを共有し、インスタンスがガベージ コレクションされた後もリソースを保持できます。

Cloud Run でネットワーク ファイル システムを使用するには、コンテナでファイル システムのマウントやアプリケーション プロセスなどの複数のプロセスを実行する必要があるため、高度な Docker の知識が必要です。このチュートリアルでは、実際の例を示しながら必要なコンセプトについて説明します。ただし、このチュートリアルをアプリケーションに合わせて変更する場合は、変更の影響を十分に確認してください。

デザインの概要

Filestore インスタンスは、Virtual Private Cloud（VPC）ネットワーク内でホストされます。VPC ネットワーク内のリソースは、プライベート IP アドレス範囲を使用して Google API やサービスと通信します。そのため、インスタンスに格納されているファイルにアクセスするには、クライアントが Filestore インスタンスと同じネットワーク上にある必要があります。Cloud Run サービスが VPC ネットワークに接続して Filestore と通信するには、サーバーレス VPC アクセス コネクタが必要です。サーバーレス VPC アクセスの詳細をご確認ください。

注: Filestore では、保存時と転送時の暗号化によって外部インターネットからもデータが保護されます。

この図は、サーバーレス VPC アクセス コネクタを介して Filestore インスタンスに接続する Cloud Run サービスを示しています。Filestore インスタンスとコネクタは、最高のパフォーマンスを得るために、Cloud Run サービスと同じ VPC ネットワーク（デフォルト）内の同じリージョン / ゾーンに配置されます。

制限事項

• このチュートリアルでは、ファイル システムの選択方法や本番環境に対応するための要件について説明しません。Filestore と利用可能なサービス階層の詳細をご確認ください。

• このチュートリアルでは、ファイル システムを使用する方法やファイル アクセス パターンについても説明しません。

目標

• ファイル共有として機能するデフォルトの VPC ネットワークに Filestore インスタンスを作成する。

• 同じデフォルト VPC ネットワーク上にサーバーレス VPC アクセス コネクタを作成して、Cloud Run サービスに接続する。

• システム パッケージと init プロセスを使用して、マウント プロセスとアプリケーション プロセスを管理する Dockerfile を構築する。

• Cloud Run にデプロイし、サービスでファイル システムへのアクセスを確認する。

費用

このチュートリアルでは、Google Cloud の課金対象となる以下のコンポーネントを使用します。

• Cloud Build
• Artifact Registry
• サーバーレス VPC アクセス
• Cloud Run
• Filestore

始める前に

1. Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

2. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   プロジェクト セレクタに移動

3. Google Cloud プロジェクトの課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

4. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   プロジェクト セレクタに移動

5. Google Cloud プロジェクトの課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

IAM の権限は、Filestore インスタンスの作成など、Filestore オペレーションへのアクセス権のみを制御します。読み取りや実行など、ファイル共有でのオペレーションへのアクセス権を制御するには、POSIX ファイル権限を使用します。詳細については、アクセス制御をご覧ください。

6. Cloud Run, Filestore, Serverless VPC Access, Artifact Registry, and Cloud Build API を有効にします。

   API を有効にする

7. gcloud CLI をインストールして初期化します。
8. gcloud components update で Google Cloud CLI を更新します。

必要なロール

チュートリアルを完了するために必要な権限を取得するには、プロジェクトに対して次の IAM ロールを付与するよう管理者に依頼してください。

• Artifact Registry 管理者（roles/artifactregistry.admin）
• Cloud Build 編集者（roles/cloudbuild.builds.editor）
• Cloud Filestore 編集者（roles/file.editor）
• Cloud Run 管理者（roles/run.admin）
• Compute ネットワーク ユーザー（roles/compute.networkUser）
• サーバーレス VPC アクセス管理者（roles/vpcaccess.admin）
• サービス アカウント ユーザー（roles/iam.serviceAccountUser）
• Service Usage ユーザー（roles/serviceusage.serviceUsageConsumer）
• ストレージ管理者（roles/storage.admin）

ロールの付与の詳細については、アクセスの管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

注: IAM の基本ロールに、チュートリアルを完了するための権限も含まれている場合があります。本番環境では基本ロールを付与すべきではありません。基本ロールは、開発環境またはテスト環境で付与してください。

gcloud のデフォルトを設定する

Cloud Run サービスを gcloud のデフォルトに構成するには:

1. デフォルト プロジェクトを設定します。

   gcloud config set project PROJECT_ID

   PROJECT_ID は、このチュートリアルで作成したプロジェクトの名前に置き換えます。

2. 選択したリージョン向けに gcloud を構成します。

   gcloud config set run/region REGION

   REGION は、任意のサポートされている Cloud Run のリージョンに置き換えます。

3. Filestore 用に gcloud を構成します。

   gcloud config set filestore/zone ZONE
   

   ZONE は、サポートされている任意の Filestore ゾーンに置き換えます。

   注: 最適なパフォーマンスを確保し、リージョン間でのネットワーク料金が発生しないようにするため、Filestore インスタンスは、アクセスが必要な Cloud Run サービスと同じリージョン / ゾーンに配置してください。

コードサンプルを取得する

使用するサンプルコードを取得するには:

1. ローカルマシンにサンプルアプリのリポジトリのクローンを作成します。

   Python

   git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git

   または、zip 形式のサンプルをダウンロードし、ファイルを抽出してもかまいません。

   Java

   git clone https://github.com/GoogleCloudPlatform/java-docs-samples.git

   または、zip 形式のサンプルをダウンロードし、ファイルを抽出してもかまいません。

2. Cloud Run のサンプルコードが含まれているディレクトリに移動します。

   Python

   cd python-docs-samples/run/filesystem/

   Java

   cd java-docs-samples/run/filesystem/

コードについて

通常、コンテナ内では、単一のプロセスまたはアプリケーションを実行します。1 つのコンテナにつき 1 つのプロセスを実行すると、複数プロセスのライフサイクルを管理する複雑さが軽減されます（たとえば、再起動の管理、プロセスが失敗した場合のコンテナの終了、シグナルの送信やゾンビの子の刈り取りといった PID 1 問題など）。一方、Cloud Run でネットワーク ファイル システムを使用する場合、ファイル システムのマウント プロセスとアプリケーションの両方を実行するためにマルチプロセス コンテナを使用する必要があります。このチュートリアルでは、プロセスの障害時にコンテナを終了し、PID 1 問題を管理する方法について説明します。mount コマンドには、再試行を扱う機能が組み込まれています。

プロセス マネージャーを使用することで、コンテナのエントリポイントとして複数のプロセスを実行、管理できます。このチュートリアルでは、tini を使用します。これは、init の代わりになるもので、ゾンビプロセスをクリーンアップしてシグナル送信を行います。具体的には、この init プロセスにより、シャットダウン時の SIGTERM シグナルがアプリケーションに伝えられます。SIGTERM シグナルは、アプリケーションを正常に終了するためにキャッチされます。詳細については、Cloud Run 上のコンテナのライフサイクルをご覧ください。

Dockerfile で環境構成を定義する

この Cloud Run サービスには、デフォルト以外のシステム パッケージを 1 つ以上追加する必要があります。RUN 命令によって、tini が init プロセスおよび nfs-common としてインストールされ、NFS クライアントの最小限の機能が提供されます。Cloud Run サービスでのシステム パッケージの操作について詳しくは、システム パッケージ・チュートリアルを使用するをご覧ください。

注: パッケージ マネージャーはオペレーティング システムによって異なります。

次の一連の手順では、作業ディレクトリの作成、ソースコードのコピー、アプリの依存関係のインストールが行われます。

ENTRYPOINT は、CMD 命令の前に付加される init-process バイナリを指定します（この例では起動スクリプト）。これにより、単一の tini プロセスが起動され、受信したすべてのシグナルが、その子プロセスをルートとするセッションに代理転送されます。

CMD 命令は、イメージを動作させる際に実行されるコマンド（起動スクリプト）を設定します。また、ENTRYPOINT のデフォルトの引数も指定します。CMD と ENTRYPOINT の操作方法をご覧ください。

Python

run/filesystem/Dockerfile

GitHub で表示 フィードバック

# Use the official lightweight Python image.
# https://hub.docker.com/_/python
FROM python:3.11-slim

# Install system dependencies
RUN apt-get update -y && apt-get install -y \
    tini \
    nfs-common \
    && apt-get clean

# Set fallback mount directory
ENV MNT_DIR /mnt/nfs/filestore

# Copy local code to the container image.
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./

# Install production dependencies.
RUN pip install -r requirements.txt

# Ensure the script is executable
RUN chmod +x /app/run.sh

# Use tini to manage zombie processes and signal forwarding
# https://github.com/krallin/tini
ENTRYPOINT ["/usr/bin/tini", "--"]

# Pass the startup script as arguments to tini
CMD ["/app/run.sh"]

Java

run/filesystem/Dockerfile

GitHub で表示 フィードバック

# Use the official maven/Java 11 image to create a build artifact.
# https://hub.docker.com/_/maven
FROM maven:3.8.6-jdk-11 as builder

# Copy local code to the container image.
WORKDIR /app
COPY pom.xml .
COPY src ./src

# Build a release artifact.
RUN mvn package -DskipTests

# Use AdoptOpenJDK for base image.
# https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds
FROM eclipse-temurin:18-jdk

# Install filesystem dependencies
RUN apt-get update -y && apt-get install -y \
    tini \
    nfs-kernel-server \
    nfs-common \
    && apt-get clean

# Set fallback mount directory
ENV MNT_DIR /mnt/nfs/filestore

# Copy the jar to the production image from the builder stage.
COPY --from=builder /app/target/filesystem-*.jar /filesystem.jar

# Copy the statup script
COPY run.sh ./run.sh
RUN chmod +x ./run.sh

# Use tini to manage zombie processes and signal forwarding
# https://github.com/krallin/tini
ENTRYPOINT ["/usr/bin/tini", "--"]

# Run the web service on container startup.
CMD ["/run.sh"]

注: ENTRYPOINT と CMD は、シェル形式ではなく実行可能ファイル形式である必要があります。シェル形式は /bin/sh -c のサブコマンドとして開始され、シグナルを渡しません。つまり、実行可能ファイルはコンテナの PID 1 にはならず、Unix のシグナルを受け取りません。したがって、アプリケーションは SIGTERM を受け取りません。CMD と ENTRYPOINT のシェル形式と実行可能ファイル形式の詳細をご覧ください。

起動スクリプトでプロセスを定義する

起動スクリプトによってマウント ポイントとなるディレクトリが作成されます。これにより、Filestore インスタンスがアクセス可能になります。次に、スクリプトが mount コマンドを使用して Filestore インスタンスを接続します。具体的には、インスタンスの IP アドレスとファイル共有名をサービスのマウント ポイントに指定し、アプリケーション サーバーを起動します。mount コマンドには、再試行機能が組み込まれています。したがって、bash スクリプトをさらに追加する必要はありません。最後に、wait コマンドでは、バックグラウンド プロセスの終了をリッスンし、スクリプトを終了します。

Python

run/filesystem/run.sh

GitHub で表示 フィードバック

#!/usr/bin/env bash
set -eo pipefail

# Create mount directory for service.
mkdir -p $MNT_DIR

echo "Mounting Cloud Filestore."
mount -o nolock $FILESTORE_IP_ADDRESS:/$FILE_SHARE_NAME $MNT_DIR
echo "Mounting completed."

# Run the web service on container startup. Here we use the gunicorn
# webserver, with one worker process and 8 threads.
# For environments with multiple CPU cores, increase the number of workers
# to be equal to the cores available.
# Timeout is set to 0 to disable the timeouts of the workers to allow Cloud Run to handle instance scaling.
exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app

Java

run/filesystem/run.sh

GitHub で表示 フィードバック

#!/usr/bin/env bash
set -eo pipefail

# Create mount directory for service
mkdir -p $MNT_DIR

echo "Mounting Cloud Filestore."
mount -o nolock $FILESTORE_IP_ADDRESS:/$FILE_SHARE_NAME $MNT_DIR
echo "Mounting completed."

# Start the application
java -jar filesystem.jar

# Exit immediately when one of the background processes terminate.
wait -n

注: 詳細なログを表示するには、mount コマンドで --verbose フラグを使用します。

ファイルを操作する

Python

ファイルシステムの操作については、main.py をご覧ください。

Java

ファイルシステムの操作については、FilesystemApplication.java をご覧ください。

サービスを配布する

1. Filestore インスタンスを作成します。

   gcloud filestore instances create INSTANCE_ID \
       --tier=STANDARD \
       --file-share=name=FILE_SHARE_NAME,capacity=1TiB \
       --network=name="default"
   

   INSTANCE_ID は Filestore インスタンスの名前（例: my-filestore-instance）に置き換え、FILE_SHARE_NAME は Filestore インスタンスから提供されるディレクトリの名前（例: vol1）に置き換えます。インスタンスに名前を付けるとファイル共有の命名をご覧ください。

   クライアント（Cloud Run サービス）が Filestore インスタンスに保存されているファイルにアクセスするには、そのインスタンスと同じネットワーク上に存在する必要があります。このコマンドでは、デフォルトの VPC ネットワークにインスタンスを作成して、無料の IP アドレス範囲を割り当てます。新しいプロジェクトはデフォルトのネットワークで開始されますが、別にネットワークを作成する必要はほぼありません。

   インスタンス構成の詳細については、インスタンスの作成をご覧ください。

   注: CLI を使用して Filestore を操作するには、インスタンスを Compute Engine VM にマウントする必要があります。VM にマウントする方法とデータをコピーする方法をご覧ください。

2. サーバーレス VPC アクセス コネクタを設定します。

   Filestore インスタンスに接続するには、Cloud Run サービスが Filestore インスタンスの承認済み VPC ネットワークにアクセスする必要があります。

   VPC コネクタごとに、コネクタ インスタンスを配置する独自の /28 サブネットが必要です。この IP 範囲は、VPC ネットワーク内の既存の IP アドレス予約と重複してはいけません。たとえば、10.8.0.0（/28）はほとんどの新規プロジェクトで機能しますが、10.9.0.0（/28）など、別の未使用のカスタム IP 範囲を指定することもできます。現在予約されている IP 範囲は、Google Cloud コンソールで確認できます。

   gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
     --region REGION \
     --range "10.8.0.0/28"
   

   CONNECTOR_NAME は、アプリケーションの名前に置き換えます。

   このコマンドは、Filestore インスタンスと同じデフォルト VPC ネットワークに、e2-micro マシンサイズのコネクタを作成します。コネクタのマシンサイズを大きくすると、コネクタのスループットを向上させることができますが、コストも増加します。コネクタは、Cloud Run サービスと同じリージョンに存在する必要があります。サーバーレス VPC アクセスの構成の詳細をご確認ください。

   注: Cloud Run サービスとサーバーレス VPC アクセス コネクタは、同じリージョンに存在する必要があります。Filestore インスタンスとサーバーレス VPC アクセス コネクタは、同じ VPC ネットワークに存在する必要があります。Cloud Run サービスと Filestore インスタンスは、同じリージョンに存在する必要はありませんが、パフォーマンスが向上し、下り（外向き）のコストがかからないため、同じリージョンにすることをおすすめします。

3. Filestore インスタンスの IP アドレスを格納する環境変数を定義します。

   export FILESTORE_IP_ADDRESS=$(gcloud filestore instances describe INSTANCE_ID --format "value(networks.ipAddresses[0])")
   

4. サービス ID として機能するサービス アカウントを作成します。このアカウントには、デフォルトでは、プロジェクト メンバーシップ以外の権限は付与されません。

   gcloud iam service-accounts create fs-identity

   このサービスは、Google Cloud の他のサービスとやり取りする必要がないため、このサービス アカウントに追加の権限を割り当てる必要はありません。

5. コンテナ イメージをビルドして Cloud Run にデプロイします。

   gcloud run deploy filesystem-app --source . \
       --vpc-connector CONNECTOR_NAME \
       --execution-environment gen2 \
       --allow-unauthenticated \
       --service-account fs-identity \
       --update-env-vars FILESTORE_IP_ADDRESS=$FILESTORE_IP_ADDRESS,FILE_SHARE_NAME=FILE_SHARE_NAME
   

   このコマンドは、VPC コネクタと第 2 世代の実行環境を指定し、Cloud Run サービスをビルドしてデプロイします。ソースからデプロイすると、Dockerfile に基づいてイメージがビルドされ、Artifact Registry リポジトリ（cloud-run-source-deploy）にイメージが push されます。

   ソースコードからのデプロイで詳細をご確認ください。

   注: このリソースに対して VPC コネクタ経由で送信するアウトバウンド トラフィックは、デフォルトでプライベート範囲のみです。

デバッグ

デプロイが失敗した場合は、Cloud Logging で詳細を確認してください。

• 接続がタイムアウトした場合は、Filestore インスタンスの正しい IP アドレスを指定していることを確認します。

• アクセスがサーバーから拒否された場合は、ファイル共有名が正しいことを確認します。

• マウント プロセスからのログをすべて取得するには、次のように mount コマンドと --verbose フラグを組み合わせて使用します。mount --verbose -o nolock $FILESTORE_IP_ADDRESS:/$FILE_SHARE_NAME $MNT_DIR

試してみる

完成したサービスを試すには:

1. ブラウザで、前述のデプロイの手順により提供された URL に移動します。
2. 新しく作成したファイルが Filestore インスタンスに表示されます。
3. ファイルをクリックすると内容が表示されます。

これらのサービスの開発を継続する場合、Google Cloud の他のサービスへの Identity and Access Management（IAM）アクセスが制限されます。他の多くのサービスにアクセスするには、追加の IAM ロールをこれらのサービスに与える必要があることにご注意ください。

費用の説明

1 TiB の Filestore インスタンスとサーバーレス VPC アクセス コネクタを使用してアイオワ（us-central1）でホストされているサービスの費用内訳の例:最新の料金については、個別の料金ページをご覧ください。

プロダクト	月額
Filestore（使用量では変わりません）	費用 = プロビジョニングされた容量（1,024 GiB または 1 TiB）× リージョン ティアの料金（us-central1） スタンダード ティア: 1,024 GiB × $0.20 / 月 = $204.80 プレミアム ティア / 高スケール SSD: 1,024 GiB × $0.30 / 月 = $307.20 Enterprise: 1,024 GiB × $0.60 / 月 = $614.40
サーバーレス VPC アクセス	費用 = マシンサイズの料金 × インスタンス数（最小インスタンス数はデフォルトで 2） f1-micro: $3.88 × 2 インスタンス = $7.76 e2- micro: $6.11 × 2 インスタンス = $12.22 e2-standard-4: $97.83 × 2 インスタンス = $195.66
Cloud Run	費用 = CPU + メモリ + リクエスト数 + ネットワーキング
合計	$204.80 + $12.22 = $217.02/月 + Cloud Run の費用

このチュートリアルでは、スタンダード ティア（基本 HDD）の Filestore インスタンスを使用しています。Filestore インスタンスのサービスティアは、そのインスタンス タイプとストレージの種類を組み合わせたものです。インスタンス タイプをアップグレードすることで、容量とスケーラビリティを増やすことができます。ストレージの種類をアップグレードすることで、パフォーマンスを上げることができます。詳細については、ストレージ タイプに関する推奨事項をご覧ください。リージョンと容量も Filestore の料金に影響します。たとえば、アイオワ（us-central1）のスタンダード ティア 1 TiB インスタンスの費用は、月に GiB あたり $0.20 かかるので、月当り約 $204.80 になります。

サーバーレス VPC アクセス コネクタは、インスタンスのサイズと数、下り（外向き）ネットワークによって課金されます。サイズと数を大きくすると、スループットが向上し、メッセージのレイテンシが短縮されます。マシンには、f1-micro、e2-micro、e2-standard-4 の 3 つのサイズがあります。インスタンスの最小数は 2 であるため、最小の費用はそのマシンサイズの費用の 2 倍になります。

注: サーバーレス VPC アクセス コネクタ インスタンスは、必要なスループットをサポートするためにスケールアウトしますが、スケールインにより戻すことはできません。つまり、時間とともにコストが増加する可能性があります。インスタンスの最大数によって料金の上限が設定されます。

Cloud Run の料金は、メモリ、CPU、リクエスト数、ネットワーキングなどのリソースの使用量に応じて課金され、100 ミリ秒単位で切り上げて計算されます。そのため、費用はサービスの設定、リクエスト数、実行時間によって異なります。このサービスでは、月額最低 $217.02 の料金が発生します。Google Cloud 料金計算ツールで見積もりを表示してご確認ください。

クリーンアップ

このチュートリアル用に新規プロジェクトを作成した場合は、そのプロジェクトを削除します。既存のプロジェクトを使用し、このチュートリアルで変更を加えずに残す場合は、チュートリアル用に作成したリソースを削除します。

プロジェクトを削除する

課金をなくす最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

プロジェクトを削除するには:

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このチュートリアルで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のチュートリアルとクイックスタートを検討する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て制限を超えないようにできます。

1. Google Cloud コンソールで、[リソースの管理] ページに移動します。

   [リソースの管理] に移動

2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

チュートリアル リソースを削除する

1. このチュートリアルでデプロイした Cloud Run サービスを削除します。

   gcloud run services delete SERVICE-NAME

   SERVICE-NAME は、選択したサービス名です。

   Cloud Run サービスは Google Cloud コンソールから削除することもできます。

2. チュートリアルの設定時に追加した gcloud のデフォルト リージョン構成を削除します。

    gcloud config unset run/region
   

3. プロジェクト構成を削除します。

    gcloud config unset project
   

4. このチュートリアルで作成した他の Google Cloud リソースを削除します。

   • Filestore インスタンスを削除します。
   • サーバーレス VPC アクセス コネクタを削除します。
   • Artifact Registry から gcr.io/PROJECT_ID/filesystem-app という名前のサービス コンテナ イメージを削除します。
   • サービス アカウント fs-identity@PROJECT_ID.iam.gserviceaccount.com を削除します。

次のステップ

• トラブルシューティング ガイドを確認する。
• Filestore の詳細を確認する。
• サーバーレス VPC アクセスの構成の詳細を確認する。
• サーバーレス VPC アクセス診断ツールで、サーバーレス ネットワーキングの問題のトラブルシューティングの方法を確認する。
• マルチプロセス コンテナの init プロセスの選択の詳細を確認する。