Configuring Service storage

Overview

Given the ephemeral nature of containers, it’s important to consider storage solutions to avoid data loss. We suggest mounting volumes from your container to the host.

Adding simple storage volumes

The volumes directive of the service.yml allows you to mount custom host folders inside your container. This is useful if you need to run a database service for instance, as data written to the local filesystem of your container will not be persisted between container instances.

The volumes option is expressed as a comma separated list with the following form: HOST_FOLDER:CONTAINER_FOLDER.

You can optionally add ro or rw to specify that the container can read/write to the host folder (the default is read/write).

(Read our guide to using service.yml for more help on customizing your service configuration.)

services:
  <service_name>:
    volumes: ["/tmp/host/foo:/tmp/container/foo", "/tmp/host/bar:/tmp/container/bar:ro"]

This is the equivalent expanded form of the example above:

services:
  <service_name>:
    volumes:
    - mount_path: "/tmp/container/foo"
      host_path: 
        path: "/tmp/host/foo"
    - mount_path: "/tmp/container/bar"
      read_only: true
      host_path: 
        path: "/tmp/host/bar"

Adding Secret and/or ConfigMap storage volumes

Cloud 66 has a specific syntax to allow you to generate a Kubernetes Secret (or Kubernetes ConfigMap), and mount them to a path inside your service containers - making them available in a local folder your service application.

You can choose whether to populate the mounted folder from a Secret or ConfigMap - the contents of which are automatically generated from your application ConfigStore or Environment Variables.

Optionally you can filter the included values based on a tag/metadata filter. The filter must be of the syntax key=value ie. foo=bar. When applied to ConfigStore entries, it will match based on the entry metadata. When applied to Environment Variables, it will match based on tags.

The following examples illustrate your options:

services:
  <service_name>:
    volumes:
    # Include all ConfigStore into a Secret
    # and mount it in your container at: "/secret-config-store" 
    - mount_path: "/secret-config-store"
      secret: 
        from: "config_store"

    # Include all Environment Variables into a ConfigMap
    # and mount it in your container at: "/config-map-env-vars" 
    - mount_path: "/config-map-env-vars"
      config_map:
        from: "env_vars"

    # Include ConfigStore entries with metadata matching "mount=true" into a Secret
    # and mount it in your container at: "/secret-config-store-filtered" 
    - mount_path: "/secret-config-store-filtered"
      secret:
        from: "config_store"
        filter: "mount=true"

Adding custom storage volumes (advanced)

If you need to connect a container to a non-standard volume (for example NFS), Cloud 66 supports all the same volume types as Kubernetes. For example a custom emptyDir volume would look something like:

services:
  <service_name>:
    volumes:
    - mount_path: "/cache"
      empty_dir:
        medium: "Memory"

This would mount an emptyDir volume in the /cache folder of your container(s) and that volume would use RAM for storage instead of the disk (because medium is set to "memory").

Volume settings

Cloud 66 supports the following general settings for all volume-types:

For more information on any of these settings, please consult the official Kubernetes docs about volumes.