WordPress deployed via Minikube & Data stored in AWS RDS
In this article, I will explain how to deploy a WordPress website on local Kubernetes using Minikube and store the data of WordPress inside Amazon RDS (Amazon Relational Database Service) using 1 single Infrastructure-as-Code using Terraform.
In my last article, I had set up a WordPress server on top of 1 EC2 instance and stored its data in an SQL Server which was also set up by me on an EC2 Instance.
This is an amazing setup, but the problem would arise when:
- there is a disaster or an unforeseen circumstance,
- when the WordPress Instance goes down or the SQL Instance goes down or gets corrupt, there will be no one to start it up again.
So what we need is a smart solution that keeps on monitoring these instances and if it goes down, start it up again so that the clients never face downtime.
One of the smart & intelligent solutions will be to use EKS instead of EC2 instances directly. Amazon Elastic Kubernetes Service (Amazon EKS) is a fully managed Kubernetes service. EKS runs upstream Kubernetes and is certified Kubernetes conformant so you can leverage all benefits of open source tooling from the community.
Along with this, we can also integrate an Elastic Load Balancing from AWS. It automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, IP addresses, and Lambda functions. This demonstrates actually how the industry works and most websites run.
I have already created an EKS Setup entirely using Terraform previously and I am sharing the link below:
Provisioning & Monitoring EKS using Terraform | Helm | Kubernetes | EFS
Complete research-based project on the integration of many different technologies to come up with 1 solution for quick…
Also, I have configured an Application Load Balancer on AWS to manage traffic between AWS EC2 Instances entirely using Terraform and I am sharing the link below:
In this article I will show a different approach:
The entire setup will be shown as a 1-click setup using Terraform.
- Create an AWS RDS Instance and all required dependencies.
- Configure WordPress on local Kubernetes via Minikube.
- Put the data of WordPress into AWS RDS (MySQL).
- Then finally expose the WordPress pod/deployment to be accessible to the outside public.
- Then finally, like I do every time, open the WordPress site on your favorite browser automatically.
Let’s start by building the code.
First, we set up the provider for downloading the plugins required for the Kubernetes set up & AWS Cloud Platform.
Profile is set so that the Terraform code automatically picks up credentials from the local system without passing it through code.
Profile can be set using the following command:
aws configure --profile profilename
Then I have set a Data Source of Availability Zone so that it can be used later in the code.
Creating the RDS -
There are 5 steps involved in creating a DB Instance in a VPC:
- Step 1: Create a VPC
- Step 2: Add Subnets to the VPC
- Step 3: Create a VPC Security Group
- Step 4: Create a DB Subnet Group
- Step 5: Create a DB Instance in the VPC
Here I have used the default VPC and default subnet groups. In my previous articles linked above, I have shown how to create VPC and subnet from scratch using Terraform.
So directly creating Security Group -
Security groups control the access that traffic has in and out of a DB instance. Each VPC security group rule enables a specific source to access a DB instance in a VPC that is associated with that VPC security group.
Ingress means the traffic that is coming into our website. We need to specify this, keeping in mind what ports we want to keep open. Following the security best practices I have kept only port 3306 open for MySQL.
Egress has been set to all ports so that outbound traffic originating from within a network can go.
Then creating the DB Subnet Group & the DB Instances -
DB Subnet Group
A DB subnet group allows specifying a particular VPC when creating DB instances using the CLI or API, in our case, Terraform. Amazon RDS uses the DB subnet group and your preferred Availability Zone to choose a subnet and an IP address to associate with your DB instance.
If the primary DB instance of a Multi-AZ deployment fails, Amazon RDS can promote the corresponding standby and create a new standby using an IP address of the subnet in one of the other Availability Zones.
Finally, to create a DB instance I used the VPC name, the DB subnet group, and the VPC security group created in the previous steps.
I will explain the options from this resource here:
- engine & engine version — Here, write the database engine and the version of the engine to use. There are many engines available like MySQL, MariaDB, and more.
- identifier — The name of the RDS instance.
- username & password — This is the username and password for the Database to login to. For further security, set the password in a secure file.
- instance class — The instance type of the RDS instance.
- storage type — Standard GP2: General Purpose SSD storage offers cost-effective storage that is acceptable for most database workloads.
- allocated storage — Specified the amount of allocated storage. I have used the default value 20.
- Then specified the Subnet group & VPC ID used.
- publicly accessible — This is set true because I want it to be accessed by the pod launched in Minikube. If an EC2 instance would have been used then it could be set to false.
- name — This is the name of the first database that will be created, if not specified no database will be created initially.
- parameter group name — Name of the DB parameter group to associate.
- skip final snapshot — I have set this value false, so no snapshot will be created while deleting the DB instance. If you have set this to true then specify the name of the snapshot.
Creating WordPress pod on local Kubernetes -
This is the deployment file for WordPress pod.
The image used to create a pod is “wordpress” so that it automatically downloads the latest image and uses it to create the pod.
Using Environment variables I have provided values to the WordPress configuration:
- WORDPRESS_DB_HOST — URL of the DB Instance.
- WORDPRESS_DB_DATABASE — Name of the DB.
- WORDPRESS_DB_USER — Username to connect to.
- WORDPRESS_DB_PASSWORD — Password of the DB.
Then finally specified the port of the WordPress pod — 80.
Creating the Service to expose the pod -
Finally created the Service for the WordPress pod. Here I have specified the node_port = 31002. This will allow the client to hit on a fixed URL.
Bonus Part -
Finally, the code for opening the website on a browser as soon as the code is completely deployed and everything is ready.
I have used the command minikube service <service_name> to open the website automatically.
Step 1 :
Start Minikube in the local system.
Run terraform apply. This will create the RDS Instances and launch the WordPress pod in Minikube.