Восстановление данных WordPress и MySQL в объеме Kubernetes

Question

В настоящее время я использую mysql, wordpress и мое собственное приложение node.js + express на модулях kubernetes в том же кластере. Все работает довольно хорошо, но моя проблема в том, что все данные будут сброшены, если мне придется повторно запускать развертывания, службы и постоянные тома.

Я достаточно широко настроил WordPress и хотел бы сохранить все данные и вставить их снова после повторного развертывания. Как это можно сделать или я что-то не так думаю? Я использую mysql: 5.6 и wordpress: 4.8-apache images.

Я также хочу передать свою конфигурацию другим членам моей команды, чтобы им больше не приходилось настраивать WordPress.

Это мой mysql-deploy.yaml

apiVersion: v1
kind: Service
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  ports:
    - port: 3306
  selector:
    app: wordpress
    tier: mysql
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: hidden
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql

      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

Это wordpress-deploy.yaml

apiVersion: v1
kind: Service
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  ports:
    - port: 80
  selector:
    app: wordpress
    tier: frontend
  type: NodePort
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wp-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: frontend
    spec:
      containers:
      - image: wordpress:4.8-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          value: hidden
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim

Answer 1

Как это можно сделать или я что-то не так думаю?

Возможно, было бы лучше перенести настрой мышления с работы непосредственно на экземпляры базового контейнера на настройку образов / манифестов контейнера. У вас есть несколько подходов, только несколько указателей:

• Создайте собственный Dockerfile на основе образов, на которые вы ссылались, и объедините в них файлы конфигурации. Это жизнеспособный подход, если конфигурация более или менее статична и может обрабатываться с помощью env vars или нечастых сборок образов докеров, но для работы с k8s требуется обработка реестра докеров. При таком подходе вы добавляете все измененные файлы для построения контекста докера, а затем COPY их в соответствующие места.

• Создайте ConfigMaps и смонтируйте их в файловой системе контейнера как файлы конфигурации, где требуется изменение. Таким образом, вы все равно можете использовать базовые образы, на которые ссылаетесь напрямую, но изменения ограничиваются манифестами kubernetes вместо перестройки образов докеров. Подход в этом случае состоит в том, чтобы идентифицировать все измененные файлы в контейнере, затем создать из них kubernetes ConfigMaps и, наконец, смонтировать их соответствующим образом. Я не знаю, какие именно вещи вы меняете, но вот пример того, как вы можете разместить конфигурацию nginx в ConfigMap:

  kind: ConfigMap
  apiVersion: v1
  metadata:
    name: cm-nginx-example
  data:
    nginx.conf: |
  
       server {
          listen 80;
  
          ...
          # actual config here
          ...
  
        }
  

  и затем установите его в контейнер в соответствующем месте, например:

  ...
  containers:
   - name: nginx-example
     image: nginx
     ports:
     - containerPort: 80
     volumeMounts:
       - mountPath: /etc/nginx/conf.d
         name: nginx-conf
   volumes:
   - name: nginx-conf
     configMap:
       name: cm-nginx-example
       items:
       - key: nginx.conf
         path: nginx.conf
  ...
  

• Монтирование постоянных томов (подпутей) в местах, где вам нужны конфигурации, и сохранение конфигурации на постоянных томах.

Лично я бы, вероятно, выбрал ConfigMaps, так как вы можете легко делиться / редактировать их с помощью развертываний k8s, и детали конфигурации не теряются как некоторая мистическая «обширная работа», но могут быть просмотрены, настроены и сохранены в некоторой системе управления версиями кода для отслеживание версий ...