Canonical uses the WordPress blogging system for all our company blogs. Earlier this year I was tasked with updating our WordPress charm from a Services Framework Juju Charm on OpenStack to a Kubernetes based Operator Framework Charm.
The WordPress Operator Charm is simple by design, the goal of the charm is to just provide the various configuration options for our WordPress Kubernetes image, which does all the heavy lifting. See the config.yaml file for details on what is supported, one option that can be useful during testing is container_config, which gives you the ability to pass through custom Kubernetes spec environment variables. For example, to enable debug level logging and ensuring you always have the latest image, you would set:
microk8s.juju config wordpress container_config='WORDPRESS_DEBUG: "1" imagePullPolicy: "always"'
The image build process downloads the latest WordPress codebase and installs it behind an Apache web server, it then downloads the plugins all of our blogs depend on, such as, akismet anti-spam support, SSO with the openid teams plugin, and a variety of Canonical Open Source themes. By default the charm will use the current stable build here, however if you wish to customise the image you can fork the code and update the image charm config option to point to the location of your custom image.
To get started with the Operator Framework WordPress charm you will need a MySQL database running locally. As I write this post there is no Kubernetes MySQL charm, so deploy one to an IaaS model with juju deploy cs:mysql. Initialise the database as follows:
CREATE DATABASE wordpress CHARACTER SET utf8 COLLATE utf8_unicode_ci;
CREATE USER 'wordpress'@'%' IDENTIFIED BY 'wordpress';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'%';
FLUSH PRIVILEGES;
Once the database is prepared we are now able to deploy the WordPress charm. The easiest way to get started with a local Kubernetes cluster is to have MicroK8s installed, reference the README of the charm for details on how to get one setup. Deploy the charm as follows.
Deploy the charm into your Kubernetes Juju model.
microk8s.juju deploy cs:~wordpress-charmers/wordpress
The charm requires Kubernetes TLS secrets to be pre-configured to ensure logins are kept secure. Create a self-signed certificate and upload it as a Kubernetes secret.
openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout server.key -out server.crt
microk8s.kubectl create secret tls -n wordpress tls-wordpress --cert=server.crt --key=server.key
Tell the charm where the database is and provide some initial setup.
DB_HOST=$IP_OF_YOUR_MYSQL_DATABASE
microk8s.juju config wordpress db_host=$DB_HOST db_user=wordpress db_password=wordpress tls_secret_name=tls-wordpress \
initial_settings="user_name: admin
admin_email: devnull@example.com
weblog_title: Test Blog
blog_public: False"
From there you can test the site by updating your /etc/hosts file and creating a static entry for the IP address of the Kubernetes ingress gateway.
App Version Status Scale Charm Store Rev OS Address
Messagewordpress wordpress:bionic-stable waiting 1 wordpress local 0 kubernetes 10.152.183.140
echo '10.152.183.140 myblog.example.com' | sudo tee -a /etc/hosts
It will take about 5 to 10 minutes for Juju hooks to discover the site is live and perform the initial setup for you. Look for this line in the output of juju debug-log to confirm.
unit.wordpress/0.juju-log Wordpress configured and initialised
This is due to issue #166 and will be fixed once Juju supports a Kubernetes pod ready hook.
To retrieve the random admin password, run the following.
microk8s kubectl exec -ti -n wordpress wordpress-operator-0 -- cat /root/initial.passwd
You should now be able to browse to https://myblog.example.com/wp-admin.
We’ve been using this charm in production for five months now, but recently updated it to bring it up to date with a current version of the Operator Framework. We’d be interested in any feedback on the charm itself, either here or via bugs against the charm project on Launchpad.