This page describes how to configure a dedicated in-memory volume you can usefor file reads and writes using Cloud Run volume mounts. Note that thisfeature differs from the built-inin-memory file system provided byCloud Run.

When you mount the in-memory volume in Cloud Run, the in-memoryvolume shows up as files in the container file system. After you mount the in-memoryvolume, you access it as if it were a directory on your local filesystem, using your programming language's file system operations and libraries.

You can use in-memory volumes to do the following:

• Limit the size of the in-memory volume. When you limit the size of a volume,writes to a full volume will fail, which is preferable to havingCloud Run terminate instances due to the volumeconsuming too much memory.
• Share an in-memory volume between different containers in one Cloud Runinstance. When Cloud Run scales out to multiple instances of ajob task, each task will have its own in-memoryvolume shared by all the containers on that task. This volumeis available to all the containers when Cloud Run scales out to handle traffic.

Behavior

When creating an in-memory volume, we recommend specifying a size limit. If thevolume reaches its size limit, further writes will fail with an out-of-memoryerror. Your instance can handle this error and keep running.

Note that the size limit is just a limit: it does not allocate additional spacefor your in-memory volume. Rather, your in-memory volume consumes the memory youconfigured for your containers. If you deploy multiple containers, the memoryused by each write to the volume counts as memory usage for the container thatwrote the data.

If you don't specify a size limit, it is automatically set to half of thetotal size of all the containers in your job or service. For example,emptyDir volume size = [Memory (Container A) + Memory (Container B) + Memory (Container N)]/2.This default behavior can result in the size limit of the in-memory volume being higher than the memory allocated for some of your containers. This can lead to unexpected crashes if a single container exceeds its own allocated memory while trying to write more data to the volume, even though the volume size limit has not been reached.

Although setting a size limit is optional, we recommend setting one to protectyour containers from running out-of-memory and crashing.

Disallowed paths

Cloud Run does not allow you to mount a volume at/dev,/proc, and/sys, or on their subdirectories.

Required roles

To get the permissions that you need to configure Cloud Run jobs, ask your administrator to grant you the following IAM roles:

• Cloud Run Developer (roles/run.developer) on the Cloud Run job
• Service Account User (roles/iam.serviceAccountUser) on the service identity

For a list of IAM roles and permissions that are associated withCloud Run, seeCloud Run IAM rolesandCloud Run IAM permissions.If your Cloud Run job interfaces withGoogle Cloud APIs, such as Cloud Client Libraries, see theservice identity configuration guide.For more information about granting roles, seedeployment permissionsandmanage access.

Configure an in-memory volume

Any configuration change leads to thecreation of a new revision. Subsequent revisions will also automatically getthis configuration setting unless you make explicit updates to change it.

After you configure an in-memory volume for your Cloud Run service,an empty volume is created for every Cloud Run instance that is started, andthe volume exists as long as that instance is running. When the instance stops running, thedata in the volume is permanently deleted.

resource"google_cloud_run_v2_job""default"{name="JOB_NAME"location="REGION"template{template{containers{image="IMAGE_URL"volume_mounts{name="VOLUME_NAME"mount_path="MOUNT_PATH"}}volumes{name="VOLUME_NAME"empty_dir{medium="MEMORY"size_limit="SIZE_LIMIT"}}}}}

Reading and writing to a volume

If you use the Cloud Run volume mount feature, you access a mountedvolume using the same libraries in your programming language that you use toread and write files on your local file system.

This is especially useful if you're using an existing container that expectsdata to be stored on the local file system and uses regular file systemoperations to access it.

The following snippets assume a volume mount with amountPath set to/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");

Clear and remove volumes and volume mounts

You can clear all volumes and mounts or you can remove individual volumesand volume mounts.

Clear all volumes and volume mounts

To clear all volumes and volume mounts from your single-container job, run the following command:

gcloudrunjobsupdateJOB\--clear-volumes--clear-volume-mounts

If you have multiple containers, follow the sidecars CLI conventions to clearvolumes and volume mounts:

gcloudrunjobsupdateJOB\--clear-volumes\--clear-volume-mounts\--container=container1\--clear-volumes\-–clear-volume-mounts\--container=container2\--clear-volumes\-–clear-volume-mounts

Remove individual volumes and volume mounts

In order to remove a volume, you must also remove all volume mounts using thatvolume.

To remove individual volumes or volume mounts, use theremove-volume andremove-volume-mount flags:

gcloudrunjobsupdateJOB\--remove-volumeVOLUME_NAME--container=container1\--remove-volume-mountMOUNT_PATH\--container=container2\--remove-volume-mountMOUNT_PATH