Scenario / Questions
ConfigMap to expose a php file intended to be shared across pods and writable by the
www-data (Apache) user.
apiVersion: v1 kind: ConfigMap metadata: name: magento-config data: env.php: | <?php return array ( ...
apiVersion: apps/v1beta1 kind: Deployment metadata: name: apache-deployment spec: ... spec: containers: - name: apache image: apache:2.4 ... volumeMounts: - name: magento-configs mountPath: /var/www/html/etc imagePullPolicy: Always volumes: - name: magento-configs configMap: name: magento-config
The file appears writable only by
root@apache-deployment-79c8548cdc-r6qhs:/# realpath /var/www/html/etc/env.php /var/www/html/etc/..2018_04_23_16_21_10.435323593/env.php root@apache-deployment-79c8548cdc-r6qhs:/# ls -l /var/www/html/etc/..2018_04_23_16_21_10.435323593/env.php -rw-r--r-- 1 root root 909 Apr 23 16:21
Is there any way to change this? I noticed
VolumeMount has a
readOnly property which defaults to
false. Indeed the volume is writable, but only by
I tried setting
root in Apache, but it wants me to recompile (currently using build from apt) lol, which feels like the wrong direction. I’d like to just figure out how to use
ConfigMap correctly if possible.
Find below all possible solutions or suggestions for the above questions..
So you must be using a prior version of Kubernetes < 1.13 which still allowed for that data volume behavior. I will tell you that in 1.13+ and later you will not be able to have read-write mounts like that. However, there is a work around, and it might be the ‘Kubernetes’ way of doing things (Although I struggle to understand why it’s better).
The work around:
In your POD/Deployment, create an init container which mounts two volumes. The first volume being your configmap(file), and the second one being an emptyDir container. We will consider the first (configmap) volume as your source, and the later as your destination. Then all you have to do in your new init container is to copy the contents of the source volume to the destination volume.
Then in your normal application container section, mount the destination container from the above, and then you have full read/write capabilities without having to deal with Kubernete’s API changes. This should also withstand much of the API changes they plan to do in the future as well.
OK, I found something workable (but not ideal). First I discovered I can mount the file directly from the
ConfigMap with the
containers: - name: apache image: apache:2.4 ... volumeMounts: - name: magento-configs mountPath: /var/www/html/app/env/etc.php subPath: etc.php imagePullPolicy: Always volumes: - name: magento-configs configMap: name: magento-config
I then discovered changing the ownership of the file inside the pod works, and once changed
www-data can write to the file. So I settled on a post start lifecycle hook that changes ownership when the pod starts
containers: - name: apache image: apache:2.4 lifecycle: postStart: exec: command: ["chown", "www-data:www-data", "/var/www/html/app/etc/env.php"]
Ideally file ownership would be something we could configure on the
Disclaimer: This has been sourced from a third party syndicated feed through internet. We are not responsibility or liability for its dependability, trustworthiness, reliability and data of the text. We reserves the sole right to alter, delete or remove (without notice) the content in its absolute discretion for any reason whatsoever.