kanister-wordpress

Back up and restore WordPress on Kubernetes with Kanister

Overview

Kubernetes CSI enables us to take volume snapshots on supported storage backends as a first step towards protecting our data on Kubernetes but snapshots operate at the infrastructure level so they do not understand how applications operate and manage their data. This implies that snapshots, by nature, are crash-consistent but not application-consistent. For busy stateful workloads such as databases processing many transactions per second, crash-consistency is insufficient for data protection since in-progress transactions are not recorded so restoring from a snapshot may still lead to data loss and leave the application in a broken state.

Kanister provides a robust and flexible solution for defining your own actions for performing application-aware backups on Kubernetes. It does this by defining blueprints, which serve as templates for application-specific backup and restore actions. The backup administrator or application owner may then instantiate actions defined in these blueprints by creating ActionSets which perform the actual application-specific backup and recovery tasks.

This demo demonstrates how to back up and restore WordPress on Kubernetes with Kanister in a reliable manner, by creating a logical database backup (database dump) and exporting it to S3 which can be imported during the restore phase to return WordPress to a known good state. The backup procedure consists of the following 3 steps:

1. Scale the WordPress deployment to zero to stop accepting user traffic and complete pending database transactions
2. Take a logical dump of the database and upload it to S3
3. Scale the WordPress deployment back to the original count to start accepting user traffic again

The restore procedure is also similar:

1. Scale the WordPress deployment to zero to stop accepting user traffic and ensure no additional database transactions are made during the restore operation
2. Download the logical database dump from S3 and import it to our running database
3. Scale the WordPress deployment back to the original count to start accepting user traffic again

Developing

Fork and clone this repository, then navigate to the project root and follow the instructions below.

Install pre-commit hook (optional)

The pre-commit hook runs formatting and sanity checks such as tofu fmt to reduce the chance of accidentally submitting badly formatted code that would fail CI.

ln -s ../../hooks/pre-commit ./.git/hooks/pre-commit

Prerequisites

1. An AWS account
2. Valid AWS credentials for an IAM administrator account - see Configure the AWS CLI for details
3. OpenTofu v1.7.2 or later
4. A Kubernetes cluster - spin one up with kind if in doubt
5. Cluster-admin access to the Kubernetes cluster with kubectl
6. Helm
7. WordPress installed in the wordpress namespace with release name wordpress within your cluster via the Bitnami Helm chart
8. The Kanister operator installed on our Kubernetes cluster
9. Go 1.22.4 or above
10. The Kanister tools installed

Create the S3 bucket for storing our Kanister backups

Create the S3 bucket for storing our Kanister backups using OpenTofu:

tofu init
tofu plan
tofu apply

Supported variables:

Name	Type	Required	Default value	Description
profile	string	-	"default"	The profile to assume from the AWS credentials file
region	string	-	"ap-east-1"	The AWS region to assume

Back up our WordPress database to S3

This demo is adapted from the MariaDB Kanister example.

First create the blueprint:

kubectl create -f manifests/blueprint.yaml

Create a location profile and corresponding secret as well to point to our S3 bucket where we'll store our database dumps to.

kubectl create -f manifests/secret.yaml
kubectl create -f manifests/profile.yaml

Now run the quiesce action with kanctl which scales down our WordPress deployment to zero. This ensures that we are not writing to the database when the backup occurs at a later stage.

kanctl -n kanister create actionset \
    --action quiesce \
    --blueprint wordpress-bp \
    --deployment wordpress/wordpress

Sample output:

actionset quiesce-spx9q created

Now we can run the backup action to backup up our WordPress database:

kanctl -n kanister create actionset \
    --action backup \
    --blueprint wordpress-bp \
    --profile wordpress-s3-profile \
    --statefulset wordpress/wordpress-mariadb

Sample output:

actionset backup-pzxzz created

Once the backup is complete, run the unquiesce action which scales our WordPress deployment back to the original number of replicas so it can start accepting user traffic again.

QUIESCE_ACTIONSET="quiesce-spx9q" # Replace me!
kanctl -n kanister create actionset \
    --action unquiesce \
    --from "${QUIESCE_ACTIONSET}"

Restore our WordPress database from S3

As with backing our our WordPress database to S3, we should quiesce our WordPress application as well prior to restoring from our database dump:

kanctl -n kanister create actionset \
    --action quiesce \
    --blueprint wordpress-bp \
    --deployment wordpress/wordpress

Sample output:

actionset quiesce-2jtgj created

Now run the restore action to restore our WordPress database from the SQL dump uploaded to S3:

BACKUP_ACTIONSET="backup-pzxzz" # Replace me!
kanctl -n kanister create actionset \
    --action restore \
    --from "${BACKUP_ACTIONSET}"

Once the restore operation is complete, unquiesce our WordPress application so it can start accepting user traffic again:

QUIESCE_ACTIONSET="quiesce-2jtgj" # Replace me!
kanctl -n kanister create actionset \
    --action unquiesce \
    --from "${QUIESCE_ACTIONSET}"

License

MIT