Adds support for read-only ConfigMap-based volumes to be used with k8s deployments. This provides us a simple mechanism for supplying configuration files in remote k8s deployments. A regular volume will not do in that case, because we cannot bind to a host directory and any brand-new volume will be provisioned empty.
Note; An important limitation of ConfigMap volumes is that they only support files in a single directory. They do not descend recursively through the source directory.
The current mechanism for determining if a volume, as defined in a compose file, should be considered a ConfigMap rather than a regular volume is:
Is the deploy-to type k8s or k8s-kind?
And is the volume marked read-only (ro) everywhere it is used?
And does it have "config" in its name?
If all are the above are true, it is placed in the spec file under the configmaps heading rather than volumes:
Adds support for read-only ConfigMap-based volumes to be used with k8s deployments. This provides us a simple mechanism for supplying configuration files in remote k8s deployments. A regular volume will not do in that case, because we cannot bind to a host directory and any brand-new volume will be provisioned empty.
The current mechanism for determining if a volume, as defined in a compose file, should be considered a ConfigMap rather than a regular volume is:
ro
) everywhere it is used?If all are the above are true, it is placed in the spec file under the
configmaps
heading rather thanvolumes
: