я использую ConfigMap
чтобы открыть файл php, предназначенный для совместного использования между модулями и доступного для записи www-data
(Apache) пользователь.
ConfigMap
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
Файл доступен для записи только root
хотя
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
Есть ли способ изменить это? я отметил VolumeMount
имеет readOnly
свойство, которое по умолчанию false
. Действительно, том доступен для записи, но только root
.
Я пробовал установить APACHE_RUN_USER
к root
в Apache, но он хочет, чтобы я перекомпилировал (в настоящее время использую сборку из apt) lol, что кажется неправильным направлением. Я хотел бы просто выяснить, как использовать ConfigMap
если возможно, правильно.
Обновить:
Таким образом, вы должны использовать предыдущую версию Kubernetes <1.13, в которой все еще разрешено такое поведение объема данных. Я скажу вам, что в 1.13+ и более поздних версиях у вас не будет таких монтировок для чтения и записи. Однако есть обходной путь, и это может быть «Kubernetes» способ делать что-то (хотя мне трудно понять, почему это лучше).
Работа вокруг:
В вашем POD / Deployment создайте контейнер инициализации, который монтирует два тома. Первый том - это ваша конфигурационная карта (файл), а второй - контейнер emptyDir. Мы будем рассматривать первый том (configmap) в качестве источника, а второй - в качестве пункта назначения. Затем все, что вам нужно сделать в вашем новом контейнере инициализации, - это скопировать содержимое исходного тома в целевой том.
Затем в обычном разделе контейнера приложения смонтируйте целевой контейнер из приведенного выше, и тогда у вас будут полные возможности чтения / записи без необходимости иметь дело с изменениями API Kubernete. Это также должно выдержать многие изменения API, которые они планируют сделать в будущем.
Хорошо, я кое-что нашел работоспособный (но не идеально). Сначала я обнаружил, что могу смонтировать файл прямо из ConfigMap
с subPath
настройка:
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
Затем я обнаружил, что смена владельца файла внутри модуля работает, и однажды изменил www-data
можно писать в файл. Итак, я остановился на крючок жизненного цикла после запуска который меняет владельца при запуске модуля
containers:
- name: apache
image: apache:2.4
lifecycle:
postStart:
exec:
command: ["chown", "www-data:www-data", "/var/www/html/app/etc/env.php"]
В идеале владение файлом было бы чем-то, что мы могли бы настроить на volumeMount
настройка.