Links

ConfigMap

Very similarly to the PeristentVolumeClaim module, you can also mount Kubernetes ConfigMaps on container modules using the configmap module type (see here for the full reference).
Example:
kind: Module
name: my-configmap
type: configmap
data:
config.properties: |
some: data
or: something
---
kind: Module
name: my-module
type: container
services:
- name: my-service
volumes:
- name: my-configmap
module: my-configmap
containerPath: /config
...
This mounts all the keys in the data field on the my-configmap module under the /config directory in the container. In this case, you'll find the file /config/config.properties there, with the value above (some: data ...) as the file contents.
You can do the same for tests and tasks using the tests.volumes and tasks.volumes fields. configmap volumes can of course also be referenced in kubernetes and helm modules, since they are deployed as standard ConfigMap resources.
Take a look at the configmap module type and container module docs for more details.

Shared volumes

For a volume to be shared between multiple replicas, or multiple services, tasks and/or tests, it needs to be configured with a storage class (using the storageClassName field) that supports the ReadWriteMany (RWX) access mode. The available storage classes that support RWX vary by cloud providers and cluster setups, and in many cases you need to define a StorageClass or deploy a storage class provisioner to your cluster.
You can find a list of storage options and their supported access modes here. Here are a few commonly used RWX provisioners and storage classes:
Once any of those is set up you can create a persistentvolumeclaim module that uses the configured storage class. Here, for example, is how you might use a shared volume with a configured azurefile storage class:
kind: Module
name: shared-volume
type: persistentvolumeclaim
spec:
accessModes: [ReadWriteMany]
resources:
requests:
storage: 1Gi
storageClassName: azurefile
---
kind: Module
name: my-module
type: container
services:
- name: my-service
volumes:
- &volume # <- using a YAML anchor to re-use the volume spec in tasks and tests
name: shared-volume
module: shared-volume
containerPath: /volume
...
tasks:
- name: my-task
volumes:
- *volume
...
tests:
- name: my-test
volumes:
- *volume
...
Here the same volume is used across a service, task and a test in the same module. You could similarly use the same volume across multiple container modules.