WordPress in Kubernetes and AWS RDS

What we are going to do?

  1. WordPress in Kubernetes Cluster (Local Minikube used here)
  2. Database for WordPress is deployed in AWS Relational Database Service (RDS)
  3. Mentioned things are done using Infrastructure as a Code (Terraform used here)

This task has been done on the following resources:

  1. Windows 10 as WorkStation
  2. AWS Account (Free-tier)
  3. Terraform v0.12.29
  4. Kubectl v1.18.0
  5. Minikube v1.12.3 (in a Virtual Machine)

Let’s fire up the code and deploy it.

As RDS is a service provided by AWS, hence we will use its provider. We will be using our default VPC and subnets for this so we will use the data source to retrieve them.

Configure your profile with the following to use in the AWS provider. The credentials can be created and found on the AWS dashboard.

aws configure --profile <profilename>

Kubernetes provider has been used to interact with the Minikube cluster that is a single node cluster running in my Virtual Machine. Instead of using the configuration from kubectl, I will be providing the host and credentials of the cluster manually.

Now we will be creating our database in AWS RDS.

We will start with the security group for the database. As we will be using MariaDB as the product which runs on port 3306 so we will allow ingress on it from anywhere using IPv4. For Egress, the database can go anywhere on the internet as it will require it for the updates. This sg is created in default VPC.

Since the RDS can be created on multiple subnets for high availability, we will use all three subnets for it and create an aws_db_subnet_group for it using out default subnet ids.

Now we will finally create the RDS database of size 5GB (keep it below 20GB to stay in the free tier) and make it publically accessible as our WordPress will run on our local workstation. We will be using MariaDB as the engine and its latest version. It will be based on micro instances. We will set the database credentials here. Add the security group for the firewall and subnet group as well. skip_final_snapshot thas been used so no snapshot is created while deleting the database.

If you don’t use this, then please set a snapshot name else you will face error while destroying the database as it prompts for snapshot name.

Don’t set the credentials in plain text. Keep is secure by using environment variables.

Now we will deploy our WordPress Server in the Minikube Cluster. We will pass the database credentials in the environment variables of the pods that will be created in the deployment and keep the port 80 open as webservers are hosted on it be the default.

We will expose the deployment on NodePort and the open port will be auto-assigned by the cluster.

And finally, our setup is ready. Let’s see the infrastructure created.

Resources created
Checking database details

All the used codes with steps are available on my GitHub.

--

--

--

Just a tech enthusiast… Research, implement and share is what I like to do

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

HashiCorp Waypoint! What point?

Implementing Modern Objective-C Optionals

How to transfer SOL with any coding language

Production-Ready CDK - Bootstrapping

Pointless Automation: Dropbox File Downloads With Python

Use the Type System

Few steps to prepare for a hackathon

The Impact and Implementation of Linked Lists

Get the Medium app

Ashish Kumar

Ashish Kumar

Just a tech enthusiast… Research, implement and share is what I like to do

More from Medium

How-to setup a HA/DR database in AWS? [3 — Simple database]

Jenkins on Fargate and ec2 Spotfleet

AWS Security Intro — 1. Access

Updating Terraform Cloud State with existing resources