Mounting File System Service Resources

Before you create a container instance that mounts FSS storage, create the required OCI file storage resources first.

• Create the File System.
• Create or identify the mount target that exposes the file system.
• Create the export that the container instance mounts.

Ensure that the user creating the Container Instance has permission to read the referenced FSS resources.

Start with the standard Container Instances IAM policies that allow users to create and use container instances, networks, and container images. Then add FSS-specific permissions so the caller can use the referenced File Storage resources.

For general Container Instance IAM policies, refer to the Container Instances policy reference:

Container Instances Policy Reference

The following examples use the same style as the Container Instances policy reference and assume a group named ContainerInstanceLaunchers.

Enable container and networking policies.

Allow group ContainerInstanceLaunchers to manage compute-container-family in compartment <container-instance-compartment-name>
Allow group ContainerInstanceLaunchers to use virtual-network-family in compartment <network-compartment-name>
Allow group ContainerInstanceLaunchers to read repos in tenancy

If the Container Instance and the FSS resources are in the same tenancy, add:

Allow group ContainerInstanceLaunchers to use file-family in tenancy

If the Container Instance is created from one tenancy and the FSS resources are in another tenancy, configure cross-tenancy policies.

Write the following Endorse policies in the tenancy where the ContainerInstanceLaunchers group is defined:

Define tenancy FssResourceTenancy as <fss-resource-tenancy-ocid>

Endorse group ContainerInstanceLaunchers to use file-family in tenancy FssResourceTenancy
Endorse group ContainerInstanceLaunchers to associate compute-container-instances in tenancy with all-resources in tenancy FssResourceTenancy where ALL { 2.resource.kind = 'file-family', request.operation = 'CreateContainerInstance' }

Write the following Admit policies in the tenancy where the FSS resources exist:

Define tenancy ContainerInstanceResourceTenancy as <source-tenancy-ocid>
Define group ContainerInstanceLaunchers as <source-group-ocid>

Admit group ContainerInstanceLaunchers of tenancy ContainerInstanceResourceTenancy to associate compute-container-instances in tenancy ContainerInstanceResourceTenancy with all-resources in compartment id <fss-resource-compartment-ocid> where ALL { 2.resource.kind = 'file-family', request.operation = 'CreateContainerInstance' }
Admit group ContainerInstanceLaunchers of tenancy ContainerInstanceResourceTenancy to use file-family in tenancy

If the subnet used by the Container Instance is also in a different tenancy, add cross-tenancy virtual network policies as well. This is commonly needed when the subnet and the FSS resources are managed together in the same tenancy.

Write the following Endorse policies in the tenancy where the ContainerInstanceLaunchers group is defined:

Define tenancy NetworkResourceTenancy as <network-resource-tenancy-ocid>

Endorse group ContainerInstanceLaunchers to manage virtual-network-family in tenancy NetworkResourceTenancy
Endorse group ContainerInstanceLaunchers to associate compute-container-instances in tenancy with subnets in tenancy NetworkResourceTenancy

Write the following Admit policies in the tenancy where the subnet resources exist:

Define tenancy ContainerInstanceResourceTenancy as <source-tenancy-ocid>
Define group ContainerInstanceLaunchers as <source-group-ocid>
                    
Admit group ContainerInstanceLaunchers of tenancy ContainerInstanceResourceTenancy to manage virtual-network-family in compartment id <network-resource-compartment-ocid>
Admit group ContainerInstanceLaunchers of tenancy ContainerInstanceResourceTenancy to associate compute-container-instances in tenancy ContainerInstanceResourceTenancy with subnets in compartment id <network-resource-compartment-ocid>

Allow traffic from the container instance to the FSS servers over both TCP and UDP for the following ports:

• 111
• 2048-2051

Configure the relevant security lists or network security groups so the selected subnet path can reach the FSS mount target.

Configure the FSS export so that every export client option has requirePrivilegedSourcePort set to true.

If any export client option uses requirePrivilegedSourcePort=false, the create workflow can fail with a user-facing error stating that the export has requirePrivilegedSourcePort set to false for one or more client options. Such exports are not allowed to be mounted, and requirePrivilegedSourcePort must be true for all client options.

Only the following NFSv3 mount options are supported for FSS volumes.

If you specify any other option, or give a supported option an invalid value, the request is rejected.

The file system can only be specified while creating a container instance. The file system will be automatically mounted when the container instance is being created. The example below shows an FSS volume referenced by mount target OCID and export OCID, mounted into a container at /mnt/fss.

Create the instance using the CLI, which reference the payload JSON:

oci container-instances container-instance create --from-json ci-fss-payload.json

Example ci-fss-payload.json:

{
  "displayName": "ci-fss-demo",
  "compartmentId": "ocid1.compartment.oc1..exampleuniqueID",
  "availabilityDomain": "Uocm:PHX-AD-1",
  "shape": "CI.Standard.E4.Flex",
  "shapeConfig": {
    "ocpus": 1,
    "memoryInGBs": 2
  },
  "securityContext": {
    "securityContextType": "LINUX",
    "fsGroup": 1000,
    "fsGroupChangePolicy": "ON_ROOT_MISMATCH"
  },
  "volumes": [
    {
      "name": "shared-fss",
      "volumeType": "OCI_FSS_FILE_SYSTEM",
      "mountTarget": {
        "ociFssMountTargetType": "OCID",
        "id": "ocid1.mounttarget.oc1.phx.exampleuniqueID"
      },
      "export": {
        "ociFssExportType": "OCID",
        "id": "ocid1.export.oc1.phx.exampleuniqueID"
      },
      "security": {
        "auth": "SYS",
        "isEncryptedInTransit": true
      },
      "mountCommand": {
        "mountOptions": [
          { "option": "hard" },
          { "option": "noac" },
          { "option": "retrans", "value": "11" }
        ]
      }
    }
  ],
  "containers": [
    {
      "displayName": "app",
      "imageUrl": "docker.io/library/busybox:latest",
      "command": ["/bin/sh", "-c"],
      "arguments": ["sleep 3600"],
      "volumeMounts": [
        {
          "volumeName": "shared-fss",
          "mountPath": "/mnt/fss",
          "subPath": "team-a",
          "isReadOnly": false
        }
      ]
    }
  ],
  "vnics": [
    {
      "subnetId": "ocid1.subnet.oc1.phx.primaryuniqueID"
    }
  ]
}

Additionally, the file systems will be automatically mounted when the container instance with file system is being started or restarted.

Once the container instance has been created, the only way to unmount the file system is by either stopping or deleting the container instance. The service does not delete the file system after it is unmounted. So the file system can be mounted again later by either starting the container instance or creating a new container instance with the file system referenced by mount target OCID and export OCID.