将 wordpress 和 mysql 数据恢复到 kubernetes 卷

Question

我目前在同一集群中的 kubernetes pod 上运行 mysql、wordpress 和我的自定义 node.js + express 应用程序。一切运行良好，但我的问题是，如果我必须重新运行部署、服务和持久卷，所有数据都将被重置。

我已经对 wordpress 进行了相当广泛的配置，并希望保存所有数据并在重新部署所有内容后再次插入。这怎么可能呢，还是我想错了？我正在使用 mysql:5.6 和 wordpress:4.8-apache 图像。

我还想将我的配置转移给我的其他团队成员，这样他们就不必再次配置 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 或不经常构建的 docker 映像来处理，这是一种可行的方法，但需要 docker 注册表处理才能与 k8s 一起使用。在这种方法中，您将添加所有更改的文件以构建 docker 的上下文，然后将 COPY 它们添加到适当的位置。

• 创建 ConfigMap 并将它们作为需要更改的配置文件安装在容器文件系统上。这样，您仍然可以使用直接引用的基础镜像，但更改仅限于 kubernetes 清单，而不是重建 docker 镜像。这种情况下的方法是识别容器上所有更改的文件，然后从中创建 kubernetes ConfigMaps，最后适当地挂载。我不知道您到底要更改哪些内容，但这里是如何在 ConfigMap 中放置 nginx 配置的示例：

  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 部署轻松共享/编辑那些配置细节，并且配置细节不会因为一些神秘的“广泛工作”而丢失，但可以查看、调整并存储到一些代码版本控制系统中版本跟踪...