ジョブの NFS ボリューム マウントを構成する

このページでは、Cloud Run で NFS ファイル共有をボリュームとしてマウントする方法について説明します。オンプレミスまたは Compute Engine VM でホストされている独自の NFS サーバーなど、任意の NFS サーバーを使用できます。NFS サーバーをまだ使用していない場合は、 Google Cloudのフルマネージド NFS サービスである Filestore をおすすめします。

NBD、9P、CIFS / Samba、Ceph のネットワーク ファイル システムを使用する場合は、NBD、9P、CIFS / Samba、Ceph のネットワーク ファイル システムを使用するをご覧ください。

Cloud Run で NFS ファイル共有をボリュームとしてマウントすると、ファイル共有がコンテナ ファイル システム内のファイルとして提示されます。ファイル共有をボリュームとしてマウントした後、プログラミング言語のファイル システム オペレーションとライブラリを使用して、ローカル ファイル システム上のディレクトリと同じようにアクセスします。

使用できないパス

Cloud Run では、/dev、/proc、/sys、またはそのサブディレクトリにボリュームをマウントすることはできません。

制限事項

• NFS ボリュームに書き込むには、コンテナを root として実行する必要があります。コンテナでファイル システムからの読み取りを行うだけの場合は、任意のユーザーとして実行できます。

• Cloud Run は NFS ロックをサポートしていません。NFS ボリュームは、ロックなしモードで自動的にマウントされます。

始める前に

Cloud Run で NFS サーバーをボリュームとしてマウントするには、次のものが必要です。

• VPC ネットワーク。このネットワークで NFS サーバーまたは Filestore インスタンスが実行されます。
• VPC ネットワークで実行される NFS サーバー。ここで、Cloud Run ジョブが VPC ネットワークに接続されます。NFS サーバーがまだない場合は、Filestore インスタンスを作成してサーバーを作成します。
• Cloud Run ジョブは、NFS サーバーが実行されている VPC ネットワークに接続されます。最高のパフォーマンスを得るには、VPC コネクタではなくダイレクト VPC を使用します。
• 既存のプロジェクトを使用している場合は、VPC ファイアウォール構成で Cloud Run が NFS サーバーにアクセスできることを確認してください（新しいプロジェクトから開始する場合は、デフォルトで true になります）。NFS サーバーとして Filestore を使用している場合は、Filestore のドキュメントに従って下り（外向き）ファイアウォール ルールを作成し、Cloud Run が Filestore にアクセスできるようにします。

必要なロール

Cloud Run ジョブの構成に必要な権限を取得するには、ジョブに対する次の IAM ロールを付与するよう管理者に依頼してください。

• Cloud Run ジョブに対する Cloud Run デベロッパー ロール（roles/run.developer）
• サービス ID に対するサービス アカウント ユーザー ロール（roles/iam.serviceAccountUser）

Cloud Run に関連付けられている IAM ロールと権限のリストについては、Cloud Run IAM ロールと Cloud Run IAM 権限をご覧ください。Cloud Run ジョブがGoogle Cloud API（Cloud クライアント ライブラリなど）と連携している場合は、サービス ID の構成ガイドをご覧ください。ロールの付与の詳細については、デプロイ権限とアクセスの管理をご覧ください。

NFS ボリュームをマウントする

複数の NFS サーバー、Filestore インスタンス、または他のボリューム タイプを異なるマウントパスにマウントできます。

複数のコンテナを使用している場合は、まずボリュームを指定してから、各コンテナのボリューム マウントを指定します。

resource "google_cloud_run_v2_job" "default" {
  name     = "JOB_NAME"
  location = "REGION"

  template {
    template {
      containers {
        image = "us-docker.pkg.dev/cloudrun/container/hello"
        volume_mounts {
          name       = "VOLUME_NAME"
          mount_path = "MOUNT_PATH"
        }
      }
      vpc_access {
        network_interfaces {
          network    = "default"
          subnetwork = "default"
        }
      }
      volumes {
        name = "VOLUME_NAME"
        nfs {
          server    = google_filestore_instance.default.networks[0].ip_addresses[0]
          path      = "NFS_PATH"
          read_only = IS_READ_ONLY
        }
      }
    }
  }
}

resource "google_filestore_instance" "default" {
  name     = "cloudrun-job"
  location = "REGION"
  tier     = "BASIC_HDD"

  file_shares {
    capacity_gb = 1024
    name        = "share1"
  }

  networks {
    network = "default"
    modes   = ["MODE_IPV4"]
  }
}

ボリュームの読み取りと書き込み

Cloud Run のボリューム マウント機能を使用する場合、ローカル ファイル システムでファイルの読み取りと書き込みに使用するプログラミング言語のライブラリを使用して、マウントされたボリュームにアクセスします。

これは、ローカル ファイル システムにデータが保存されることを想定し、通常のファイル システム オペレーションを使用してデータにアクセスする既存のコンテナを使用している場合に特に便利です。

次のスニペットは、mountPath が /mnt/my-volume に設定されたボリューム マウントを前提としています。

var fs = require('fs');
fs.appendFileSync('/mnt/my-volume/sample-logfile.txt', 'Hello logs!', { flag: 'a+' });

f = open("/mnt/my-volume/sample-logfile.txt", "a")

f, err := os.Create("/mnt/my-volume/sample-logfile.txt")

import java.io.File;
File f = new File("/mnt/my-volume/sample-logfile.txt");

NFS のトラブルシューティング

問題が発生した場合は、次の点を確認してください。

• Cloud Run サービスが、NFS サーバーのある VPC ネットワークに接続されている。
• Cloud Run が NFS サーバーにアクセスすることを妨げるファイアウォール ルールがない。
• コンテナで NFS サーバーに書き込みを行う場合は、root として実行されていること。

コンテナの起動時間と NFS ボリュームのマウント

NFS ボリューム マウントを使用すると、コンテナの起動前にボリューム マウントが開始されるため、Cloud Run コンテナのコールド スタート時間がわずかに長くなる可能性があります。コンテナは、NFS が正常にマウントされた場合にのみ起動します。

NFS は、サーバーとの接続を確立してファイル ハンドルを取得した後にのみ、ボリュームを正常にマウントします。Cloud Run がサーバーに接続できない場合、Cloud Run ジョブは起動しません。

また、Cloud Run のすべてのマウントの合計タイムアウトが 30 秒であるため、ネットワークの遅延がコンテナの起動時間に影響する可能性があります。NFS のマウントに 30 秒以上かかると、Cloud Run ジョブの開始に失敗します。

NFS のパフォーマンス特性

複数の NFS ボリュームを作成すると、すべてのボリュームが並列でマウントされます。

NFS はネットワーク ファイル システムであるため、帯域幅の制限が適用されるため、帯域幅の制限により、ファイル システムへのアクセスに影響する可能性があります。

NFS ボリュームに書き込むと、データがフラッシュされるまで書き込みは Cloud Run メモリに保存されます。データは、次の状況でフラッシュされます。

• アプリケーションが sync(2)、msync(2)、または fsync(3) を使用してファイルデータを明示的にフラッシュする。
• アプリケーションが close(2) でファイルを閉じる。
• メモリ不足のため、システム メモリ リソースの再利用が強制的に実行される。

詳細については、Linux のドキュメントで NFS の説明をご覧ください。

ボリュームとボリューム マウントを消去して削除する

すべてのボリュームとマウントを消去できます。または、個々のボリュームとボリューム マウントを削除することもできます。

すべてのボリュームとボリューム マウントを消去する

単一コンテナのジョブからすべてのボリュームとボリューム マウントを消去するには、次のコマンドを実行します。

gcloud run jobs update JOB \
    --clear-volumes
    --clear-volume-mounts

複数のコンテナがある場合は、サイドカー CLI 規則に沿ってボリュームとボリューム マウントを消去します。

gcloud run jobs update JOB \
    --clear-volumes \
    --clear-volume-mounts \
    --container=container1 \
    --clear-volumes \
    -–clear-volume-mounts \
    --container=container2 \
    --clear-volumes \
    -–clear-volume-mounts

個々のボリュームとボリューム マウントを削除する

ボリュームを削除するには、そのボリュームを使用するすべてのボリューム マウントも削除する必要があります。

個々のボリュームまたはボリューム マウントを削除するには、remove-volume フラグと remove-volume-mount フラグを使用します。

gcloud run jobs update JOB \
    --remove-volume VOLUME_NAME
    --container=container1 \
    --remove-volume-mount MOUNT_PATH \
    --container=container2 \
    --remove-volume-mount MOUNT_PATH