5

We have a custom docker image based on the official wordpress image that holds a custom theme that we are developing. We have CI/CD on this project using Gitlab CI and deploying branches on a bare-metal Kubernetes Cluster v1.6 for review. It works fine, however we are trying to enhance the process by automating the required manual actions when a new instance is deployed:

  • Installing Wordpress
    • Setting admin credential
    • Setting site name and url
  • Activating theme
  • Activating plugins
  • Importing data
  • etc.

wp-cli has all the commands needed. But how to use it with containers and K8S? We are aware that there are two options:

  • Installing the tool in our WordPress based image.
  • Using a second container that contains only wp-cli and communicates with the main container.

There are WordPress images with preinstalled wp-cli (e.g. tutum-docker-wordpress), but we don't feel this is the correct way. At some point we would like to use a CronJob resource with the cli image to export data each day and we are trying to make the process as generic as possible and we would like to stick with the official images so the second option is preferred. Based on our research in order to implement the second option we will need to achieve two things:

  • Access the files of the WordPress installation from the CLI container.
  • Do not retry after successful execution.

We researched couple of option with no complete success:

  • Second container in the same pod - It looks possible to share files between both containers using EmptyDir, however even if the container succeeds it will be restarted.
  • InitContainer - This one sounds very tempting because database migrations are done this way. However it seems impossible to get the files unless you use a custom image.
  • Job - It is designed exactly to handle one-time tasks, however accessing the files of a container in a pod does not seem to be possible.

This seems like a pretty common feature when you deploy review deployments of Wordpress on Kubernetes and someone should have already done that. But we could not find any specific info about this use case.

Please advice on what is the best way to achieve the desired implementation according to you and how?

kmotsov
  • 51
  • 3
  • Can wp-cli be run at image build time? It sounds from the description that it should be. – Jonah Benton Feb 05 '18 at 16:59
  • The commands on the wp-cli will write to the database which is on another pod, so it looks to me that it's not possible to run these commands on build time. – kmotsov Feb 06 '18 at 07:42
  • Changes made to the file system of a container at runtime are not persisted following container restarts. So the two options are: orchestrate a build-time process that produces an updated wordpress image with an importable database dump file; or orchestrate a startup process at runtime that will run the wp-cli sequence in an immutable manner in the wordpress container every time the container restarts. – Jonah Benton Feb 06 '18 at 17:00
  • The former can be orchestrated with tricks where the database is started in the background in the wordpress image, see for instance: https://stackoverflow.com/questions/29145370/how-can-i-initialize-a-mysql-database-with-schema-in-a-docker-container – Jonah Benton Feb 06 '18 at 17:00
  • Did you have any luck with this @user3532352? I'm looking at doing something similar. Feels like I'll go down the immutable startup process route as @Jonah Benton suggested, but curious do know how you end up doing this. – Jon Oct 23 '18 at 09:33
  • 1
    @Jon We went with using an init container that uses a slightly cistomized wp-cli image. The trick is that in order to get the theme inside it and not build two images, we are using another init container of the app image, run before the cli one, which copies the app into a shared storage folder. That way when the cli init container is started it has the themes, plugins, etc and can install them, populate the database, etc. Hope this info will be useful for you. – kmotsov Oct 24 '18 at 17:26

2 Answers2

0

You can use an NFS based file system and mount your wordpress content into any type of workload.

If you need something to help you get started check out https://matthewdavis.io/highly-available-wordpress-on-kubernetes/.

yomateo
  • 2,078
  • 12
  • 17
0

Based on @kotsov's hint above, we got this working using init containers in the deployment.

Steps:

  • The first init container starts the wordpress image, but with args overridden to ["apache2-foreground","-version"]. This will cause it to run the entry-point, installing/setting up wordpress if necessary, but then exiting with the version.
  • The second init container is the wordpress cli with its commands.
  • After these, the wordpress container is let run again.

We also set these up on a persistent volume for /var/www/html so if it's started again it wont have to do all this. The init steps will skip initialisation steps based on directory contents.

In the deployment template:

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>
Danny Staple
  • 7,101
  • 4
  • 43
  • 56