This guide will walk you through the process of deploying WordPress with MySQL on a Statehub registered Kubernetes cluster, using Statehub as a data service enabling cross-region and multi-cloud continuity.

That means, that in the event of a failure of your cluster, or the entire cloud region where it is deployed, you’ll be able to start your WordPress and Database Processes, with all of its latest data intact, on another cluster at a different location in just a few seconds.

 

Deploying WordPress with MySQL on K8s - Statehub

Before You Begin

Before you begin, it might be useful to familiarize yourself with Statehub concepts such as Clusters, States, Volumes, and the Default State.

Prerequisites

The following is necessary to use Statehub with your Kubernetes clusters:

  1. A Statehub account. Sign up here
  2. A UNIX-compatible command-line interface (Linux or Mac terminal, WSL or CygWin for Windows)
  3. The kubectl command-line utility to control your clusters
  4. The helm command-line utility to deploy Helm charts on your clusters

Initial Setup

This guide assumes you have two Kubernetes clusters in two distinct cloud locations, similar to the diagram below:

Deploying WordPress with MySQL on K8s - Statehub

 

 

Step 1: Set Up the Statehub CLI

Go to Get-Statehub to Download and Install the Statehub CLI

Setting up your Kubernetes clusters to use Statehub requires using the Statehub CLI. After installation is complete, copy the link to your browser and go to the Statehub login page.

If you don’t already have a Statehub account, you can create one by clicking a link on the Statehub login page.

Once you’ve logged in to your Statehub account, you should be automatically redirected to the tokens page and prompted to create a token for your CLI. Click “Yes” to create a token. Copy the token to the CLI prompt and press Enter.

Your Statehub CLI installation should now be configured.

 

Step 2: Register Your Clusters with Statehub

Register the Clusters Using the Statehub CLI

The following command will register the cluster associated with your current context:

kubectl config use-context my-cluster 
statehub register-cluster

To register another cluster, switch to its context, and then run register it:

kubectl config use-context another-cluster 
statehub register-cluster

For further information about the cluster register process go to Statehub – Cluster Registration

 

💡 Please Note:
In certain scenarios, you might not have a second cluster in place at another location. If you wish your data to be replicated to another location, and create a cluster on-demand if needed, follow the procedure to add a location to a state.


What We’ve Done

To use Statehub with your Kubernetes clusters, register them using the Statehub CLI. The Statehub CLI makes use of your Kubernetes configuration contexts to identify your clusters and is aware of the current context.

To register another cluster, either switch to the appropriate context or run the above command. You need to register all the clusters between which you want to move your stateful applications.

This operation will:

  1. Make Statehub aware of your clusters
  2. Identify your clusters’ location(s) and report them to Statehub
  3. Generate a cluster token for your cluster and save it in your cluster’s secrets, so that your cluster can access the Statehub REST API.
  4. Install the Statehub Controller components and the Statehub CSI driver on your cluster
  5. Add the cluster’s location(s) to the default state, if the default state doesn’t span this location yet
  6. Configure the default state’s corresponding storage class (default.your-statehub-org-id.statehub.io) as the default storage class.

Once you’ve registered all of your clusters, you should be able to start stateful applications and fail them over between your clusters.

At this point, your topology will look as follows:

Deploying WordPress with MySQL on K8s - Statehub

Step 3: Configure and Apply Your Cluster Components

Create a Secret File

In the following example, an Opaque-type secret will be used as a MySQL root password.


Create WordPress and MySQL PersistentVolumeClaims

An example of a PVC (PersistentVolumeClaims) YAML for WordPress and MySQL:


 

💡 Please Note:

The minimum storage size supported by the Statehub volume provisioner is – 4Gi. The storageClassName is set to the storage class corresponding with the default state (replace YourStatehubOrgId with your Statehub organization ID). If you’ve registered the cluster with default parameters, you can omit the storage class name since your default state storage class should have been set as the default for this cluster.

 

Apply your PVC file:

kubectl apply -f <'your-PVC-file-name'>.yml

Create WordPress and MySQL Services

An example of a Service YAML for WordPress and MySQL:


Apply your Service:

kubectl apply -f <'your-service-file-name'>.yml

Create WordPress Deployment and MySQL StatefulSet

A WordPress deployment YAML example:

A MySQL StatefulSet YAML example:

Apply your deployments:

kubectl apply -f <'your-file-name'>.yml

To see all the needed components’ current state and make sure all of them were launched properly:

kubectl get all use-context 'cluster-name'

You will be able to see all your components and their status – Including Pods, Services, Deployments, and Replicasets.

Access WordPress Through LocalHost

In case you wish to access your WordPress UI through your LocalHost:

kubectl port-forward service/'your-wordpress-service-name' 8080:80

In this example, every request that will be sent through port 8080 of your local host will be forwarded to port 80 of the WordPress pod as configured in the WordPress Service example.


What We’ve Done

As soon as Kubernetes tries to create a PVC with a Statehub-created storage class (i.e – default.your-statehub-org-id.statehub.io), Statehub will create a volume on the state corresponding to the storage class, replicated between all of the locations the state spans.

Since the owner of the state is our primary cluster, only it is allowed to access the volumes, and create new volumes on the state.

After starting your application, your setup will resemble this:

Step 4: Failing Over Between Clusters in Different Locations

When you need to switch over your application to another cluster, set the other cluster as the owner of the state and apply the configuration to it.

Deploying WordPress with MySQL on K8s - Statehub

 

Optionally, in case of a planned switchover, remove the application on the cluster you’re moving away from. The Data will not be affected:

kubectl delete -f mysql.yaml 
kubectl delete -f wordpress.yaml

To start your application on the other cluster:

1. Choose the cluster on which you want your application and switch to its context

kubectl config use-context another-cluster

2. Make sure this cluster is the owner of the default state by running

statehub set-owner default another-cluster

3. Apply your stateful application configuration

kubectl apply -f wordpress.yaml

kubectl apply -f mysql.yaml

Deploying WordPress with MySQL - Statehub

Conclusion

While failures might happen anytime, there is a simple solution for preventing data loss and managing stateful data and applications, using the features of Statehub.

In this guide, we went through the basic steps of Deploying WordPress with MySQL on Kubernetes with Cross-Region or Multi-cloud Business Continuity using Statehub, giving you the freedom of running stateful MySQL databases for your WordPress without worrying about Data lost in a case of a failure or in a need for a change.

As always, feel free to ping us back with any questions at support@statehub.io