5

我们有一个基于官方 wordpress 图像的自定义 docker 图像，其中包含我们正在开发的自定义主题。我们在这个项目上有 CI/CD，使用 Gitlab CI 并在裸机 Kubernetes Cluster v1.6 上部署分支以供审查。它工作正常，但是我们正在尝试通过在部署新实例时自动执行所需的手动操作来增强流程：

  • 安装 WordPress
    • 设置管理员凭据
    • 设置站点名称和网址
  • 激活主题
  • 激活插件
  • 导入数据
  • 等等

wp-cli有所有需要的命令。但是如何将它与容器和 K8S 一起使用呢？我们知道有两种选择：

  • 在我们基于 WordPress 的映像中安装该工具。
  • 使用仅包含wp-cli并与主容器通信的第二个容器。

有预装 wp-cli 的 WordPress 图像（例如tutum-docker-wordpress），但我们认为这不是正确的方法。在某些时候，我们希望每天使用带有 cli 图像的 CronJob 资源来导出数据，并且我们正在努力使该过程尽可能通用，并且我们希望坚持使用官方图像，因此首选第二个选项。根据我们的研究，为了实施第二个选项，我们需要实现两件事：

  • 从 CLI 容器访问 WordPress 安装文件。
  • 执行成功后不要重试。

我们研究了几个没有完全成功的选项：

  • 同一个 pod 中的第二个容器 - 看起来可以使用EmptyDir在两个容器之间共享文件，但是即使容器成功，它也会重新启动。
  • InitContainer - 这听起来很诱人，因为数据库迁移是以这种方式完成的。但是，除非您使用自定义图像，否则似乎无法获取文件。
  • Job - 它被专门设计用于处理一次性任务，但是访问 pod 中容器的文件似乎是不可能的。

当您在 Kubernetes 上部署 Wordpress 的审核部署时，这似乎是一个非常常见的功能，并且应该已经有人这样做了。但我们找不到有关此用例的任何具体信息。

请就根据您的要求实现所需实施的最佳方法是什么以及如何提供建议？

4

2 回答 2

0

您可以使用基于 NFS 的文件系统并将您的 wordpress 内容挂载到任何类型的工作负载中。

如果您需要一些东西来帮助您入门，请查看https://matthewdavis.io/highly-available-wordpress-on-kubernetes/。

于 2019-01-22T10:22:07.063 回答
0

根据上面@kotsov 的提示，我们在部署中使用初始化容器来完成这项工作。

脚步：

  • 第一个 init 容器启动 wordpress 图像，但 args 被覆盖为 ["apache2-foreground","-version"]。这将导致它运行入口点，必要时安装/设置 wordpress，然后退出该版本。
  • 第二个初始化容器是带有命令的 wordpress cli。
  • 在这些之后，让 wordpress 容器再次运行。

我们还在 /var/www/html 的持久卷上设置了这些，因此如果再次启动它就不必执行所有这些操作。初始化步骤将根据目录内容跳过初始化步骤。

在部署模板中：

initContainers:
- name: Initialise Wordpress
  image: wordpress: <version>
  args: ["apache2-foreground","-version"]
  env: 
    <your wordpress env>
  volumes:
    <shared volume info>
- name: Wordpress CLI commands
  image: wordpress-cli: <version>
  env: 
    <your wordpress cli env>
  volumes:
    <shared volume info>
containers:
- name: Wordpress
  image: wordpress: <version>
  env: 
    <your wordpress env>
  volumes:
    <shared volume info>
于 2021-05-13T09:18:03.580 回答