Persistent Installation of MySQL and WordPress on Kubernetes
This post describes how to run a persistent installation of Wordpress on Kubernetes.
We’ll use the mysql and wordpress official Docker images for this installation. (The wordpress image includes an Apache server).
We’ll create two Kubernetes pods to run mysql and wordpress, both with associated persistent disks, then set up a Kubernetes service to front each pod.
This example demonstrates several useful things, including: how to set up and use persistent disks with Kubernetes pods; how to define Kubernetes services to leverage docker-links-compatible service environment variables; and use of an external load balancer to expose the wordpress service externally and make it transparent to the user if the wordpress pod moves to a different cluster node.
Some of the post details, such as the Persistent Disk setup, require that Kubernetes is running on Google Compute Engine.
Install gcloud and Start up a Kubernetes Cluster
First, if you have not already done so, create a Google Cloud Platform project, and install the gcloud SDK.
Then, set the gcloud default project name to point to the project you want to use for your Kubernetes cluster:
gcloud config set project <project-name>
Next, grab the Kubernetes release binary. (This example was tested with release 0.8.1).
Then, start up a Kubernetes cluster as described here.
<kubernetes> is the path to your Kubernetes installation.
Create and format two persistent disks
For this WordPress installation, we’re going to configure our Kubernetes pods to use persistent disks. This means that we can preserve installation state across pod shutdown and re-startup.
Before doing anything else, we’ll create and format the persistent disks that we’ll use for the installation: one for the mysql pod, and one for the wordpress pod. The general series of steps required is as described here, where $ZONE is the zone where your cluster is running, and $DISK_SIZE is specified as, e.g. ‘500GB’. In future, this process will be more streamlined.
So for the two disks used in this example, do the following. First create and format the mysql disk, setting the disk size to meet your needs:
Then create and format the wordpress disk. Note that you may not want as large a disk size for the wordpress code as for the mysql disk.
Start the Mysql Pod and Service
Now that the persistent disks are defined, the Kubernetes pods can be launched. We’ll start with the mysql pod.
Start the Mysql pod
Copy and then edit this mysql.yaml pod definition to use the database password you specify.
mysql.yaml looks like this:
Note that we’ve defined a volume mount for
/var/lib/mysql, and specified a volume that uses the persistent disk (
mysql-disk) that you created.
Once you’ve edited the file to set your database password, create the pod as follows, where
<kubernetes> is the path to your Kubernetes installation:
It may take a short period before the new pod reaches the
List all pods to see the status of this new pod and the cluster node that it is running on:
Check the running pod on the Compute instance
You can take a look at the logs for a pod by using
kubectl.sh log. For example:
If you want to do deeper troubleshooting, e.g. if it seems a container is not staying up, you can also ssh in to the node that a pod is running on. There, you can run
sudo -s, then
docker ps -a to see all the containers. You can then inspect the logs of containers that have exited, via
docker logs <container_id>. (You can also find some relevant logs under
Start the Myql service
We’ll define and start a service that lets other pods access the mysql database on a known port and host.
We will specifically name the service
mysql. This will let us leverage the support for Docker-links-compatible serviceenvironment variables when we up the wordpress pod. The wordpress Docker image expects to be linked to a mysql container named
mysql, as you can see in the “How to use this image” section on the wordpress docker hub page.
So if we label our Kubernetes mysql service
mysql, the wordpress pod will be able to use the Docker-links-compatible environment variables, defined by Kubernetes, to connect to the database.
Copy the mysql-service.yaml file, which looks like this:
Then, start the service like this:
You can see what services are running via:
Start WordPress Pod and Service
Once the mysql service is up, start the wordpress pod.
Copy this pod config file: wordpress.yaml and edit the database password to be the same as you used in
mysql.yaml. Note that this config file also defines a volume, this one using the
wordpress-disk persistent disk that you created.
Create the pod:
And list the pods to check that the status of the new pod changes to
Running. As above, this might take a minute.
Start the WordPress service
Once the wordpress pod is running, start its service. Copy wordpress-service.yaml.
The service config file looks like this:
createExternalLoadBalancer setting. This will set up the wordpress service behind an external IP.
createExternalLoadBalancer only works on GCE.
Note also that we’ve set the service port to 3000. We’ll return to that shortly.
Start the service:
and see it in the list of services:
Then, find the external IP for your WordPress service by listing the forwarding rules for your project:
$ gcloud compute forwarding-rules list
Look for the rule called
frontend, which is what we named the wordpress service, and note its IP address.
Visit your new WordPress blog
To access your new installation, you’ll first need to open up port 3000 (the port specified in the wordpress service config) in the firewall. Do this via:
$ gcloud compute firewall-rules create wordpress --allow tcp:3000
This will define a firewall rule called
wordpress that opens port 3000 in the default network for your project.
Now, we can visit the running WordPress app. Use the external IP that you obtained above, and visit it on port 3000:
You should see the familiar WordPress init page.
Take down and restart your blog
Set up your WordPress blog and play around with it a bit. Then, take down its pods and bring them back up again. Because you used persistent disks, your blog state will be preserved.
If you are just experimenting, you can take down and bring up only the pods:
When you restart the pods again (using the
create operation as described above), their services will pick up the new pods based on their labels.
If you want to shut down the entire app installation, you can delete the services as well.
If you are ready to turn down your Kubernetes cluster altogether, run: