WordPress on Kubernetes Part 1

DevOps Fundamentals

Introduction

For this tutorial, we will use the Kubernetes cluster created on CentOS-7.

What are real-world applications?

In this tutorial, we’ll explore deploying a WordPress application on a Kubernetes cluster. WordPress, a popular CMS (Content Management System), is used by approximately 64% of all websites on the internet. By containerizing WordPress and leveraging Kubernetes, we can efficiently manage and scale our website. Whether you’re using CentOS-7 or Ubuntu 18.04, the deployment process remains consistent. Let’s dive into the details and get your WordPress site up and running!

What is WordPress?

WordPress, often abbreviated as WP or WordPress.org, is a powerful and widely used content management system (CMS). It’s built using the PHP programming language and works seamlessly with either MySQL or MariaDB databases. Key features include a flexible plugin architecture and customizable themes. With built-in support for HTTPS, WordPress empowers users to create and manage websites effortlessly. Its primary features include a plugin architecture and a template system, referred to within WordPress as “Themes“.

How to deploy WordPress on a Kubernetes Cluster?

In the Kubernetes world, a “pod” (essentially a Docker container) can be deployed on a Kubernetes cluster using tools like “kubectl,” “kops,” or “helm.” While deploying a single pod is useful for basic testing, it’s not practical for larger deployments. To deploy pods, we create YAML files. YAML is a human-friendly language commonly used for configuring pods, services, and deployments. These YAML files act as manifest files, defining how a pod should be deployed and interact with other pods and services.

Kubernetes services manage communication between pods. A service abstracts a group of pods, providing a way to expose them over a network. Each service defines endpoints (usually pods) and policies for making those pods accessible. For more details, check out Kubernetes services and networking.

Part 1

Step 1: Pre-requisites and Infrastructure setup

Kubernetes Concepts

In Kubernetes, pods are temporary—when they stop or get terminated, all data is lost. While this is acceptable for development, it’s not suitable for production systems. To address this, we use Persistent Volumes in all our Kubernetes deployments. These volumes ensure data persistence even across pod restarts.

In Kubernetes, deployments originate from the master node, but the actual pods run on worker nodes. It’s crucial to avoid deploying pods directly on the master node. Reserve the master node for essential components that manage the Kubernetes cluster, while all other application pods should be deployed exclusively on worker nodes.

In our Kubernetes WordPress deployment when we use the Persistent Volumes (PV), the WordPress data is stored in the AWS EFS, which is mounted on a directory in the EC2 instance. Kubernetes pods do not directly access the PV, but it is done through Persistent Volume Claim (PVC). You can read more about PV vs PVC in the official Kubernetes documentaion.

Configuration Considerations

Use the CentOS-7 Master and Worker nodes AMIs created in this article.

Launch the 2 AMIs using EC2 instance =  “t3a.small” 2 vCPUs and 2 GB RAM for each EC2 instance.

Create 2 EFS storages. The first one is for storing the Kubernetes configuration files and the second one is for storing the WordPress data files.

Give appropriate names to the EFS storages (Ex: “config-files” for Kubernetes config files and “data-files” for the Kubernetes deployment data).

Creating AWS EFS and mounting it on an EC2 instance has been defined in this article.

Note: You can use even 1 storage and then create 2 separate mount points (1 for storing the Kubernetes configuration files and 1 for storing the WordPress data files). However, it’s always good practice to create 2 separate EFS mount points and then mount them on different directories.

 

Once the instances are launched, you have to log in to the instances (Master and Worker) as the “jenkins” user. This user was created in the blogs mentioned here (Pre-requisites), and (CentOS-7 installation). It is important to follow the steps mentioned in these blogs on creating the correct user and setting up the systems before proceeding.

To make things easier, we have created 4 “yaml” files for each deployment (WordPress & MySQL). So there are 4 “yaml” files for WordPress (pv, pvc, deployment and service file) and 4 “yaml” files for MySQL (pv, pvc, deployment and service file).

 

What does a “yaml” file contain:

• PV file –> For creating the Persistent Volume.
• PVC file –> For providing the storage to the pods. 
• Deployment file –> Specifies details about the number of pods, container image, volume mount points (PVC), etc.
• Service file –> Specifies the port number of the service and type of service. 

In addition to the above 8 files (4 for WordPress and 4 for MySQL), there is a secret file which contains the MYSQL_DATABASE_PASSWORD. This a MySQL environment variable which needs to be specified in order for WordPress front to connect to the MySQL database. We will configure the WordPress config file to use this password.

Important: The secret file information is stored in a key:value pair format. The value of the key “password” in this file has the value in the base64 format. So if you change the database password, then this value in base64 should also be updated, or else you will get a database connection error.

So finally we have a total of 9 “yaml” (the deployment files are available here) files which we need to deploy to get WordPress up and running,

How does Kubernetes deploy a WordPress application?

Let’s break down the key points and simplify the process of deploying WordPress on Kubernetes. 

Don’t worry if it seems confusing. We’ve set up the YAML files (the 9 deployment files are avalable here) to minimize manual changes. With these files, you’ll be able to deploy your WordPress application on your Kubernetes cluster successfully. Now, let’s get ready to deploy WordPress in PART 2