将wordpress和mysql数据恢复到kubernetes卷

Question

我目前在同一个集群中的kubernetes pods上运行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，并在其中捆绑配置文件。如果配置或多或少是静态的，并且可以使用环境变量或docker镜像的不频繁构建来处理，但需要docker注册表处理才能与k8s一起工作，则这是一种可行的方法。在这种方法中，您将添加所有更改的文件来构建docker的上下文，然后将它们创建到适当的位置。
• 创建ConfigMaps并将它们作为配置文件挂载到容器文件系统上，在需要更改的位置。这样，您仍然可以使用直接引用的基础映像，但更改仅限于kubernetes清单，而不是重新构建docker映像。这种情况下的方法是识别容器上所有更改的文件，然后从中创建kubernetes ConfigMaps，最后适当地挂载。我不知道你到底改变了哪些东西，但下面是你如何在ConfigMap中放置nginx配置的例子：

种类: ConfigMap apiVersion:服务器元数据:名称:cm-nginx-示例数据: nginx.conf：| v1 {监听80；... #实际配置在这里... }

然后将其挂载到容器中的适当位置，如下所示：

..。容器：-名称: nginx -示例图像:nginx端口：- containerPort: 80 volumeMounts：- mountPath: /etc/nginx/conf.d名称: nginx-conf卷：-名称: nginx-conf configMap:名称:cm-nginx-示例项目：- key: nginx.conf路径: nginx.conf ...

• 在需要配置的位置装载永久卷(子路径)，并在永久卷上保留配置。

就我个人而言，我可能会选择ConfigMaps，因为你可以很容易地与k8s部署共享/编辑这些内容，配置细节不会像一些神秘的“大量工作”那样丢失，但可以被审查、调整并存储到一些代码版本控制系统中以进行版本跟踪……