Working with YAML it is essential to maintain indentation within the files.
As well as being for suitable for MySQL databases this procedure is also valid for MariaDB databases, with the necessary adjustments.
- Create a Kubernetes cluster;
- allocate it to a VPC;
- create a subnet for the cluster, giving it a name and a CIDR;
- once the cluster is active, download the configuration file;
- replace the configuration with the contents of your client's configuration file for the Kubernetes cluster, or use your operating system's environment variables to export the path to the configuration file you want to use.
In our case, we will use
kubectl as example client, where the variable is called KUBECONFIG. So on Linux, for example, we will use the command:
export KUBECONFIG=/home/myuser/downloads/filediconf
If you use
kubectl the first command you can try is:
$ kubectl get nodes
If everything is working correctly, you should receive a list of nodes within your node pool.
Let's now create a simple example Web application using the WordPress CMS.
In our application, we'll have a front-end load balancer, also known as a presentation layer, a couple of containers to handle requests, and a back-end database.
For each section, we'll write a portion of code that can be executed independently from the others.
This portion of code can be saved in a separate file or in a single file. For simplicity, we will proceed by defining and writing everything in a single file using the separators available in YAML.
Let's start by creating a deployment for our first WordPress container. Place this portion of code inside a file named wordpress.yaml. It's important to remember to add the three dashes at the beginning and end of the code, as shown in the example:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: Recreate
template:
metadata:
labels:
app: wordpress
tier: frontend
spec:
containers:
- image: wordpress:latest-apache # Installa l'ultima versione disponibile su Docker Hub
name: wordpress
env:
- name: WORDPRESS_DB_HOST
value: wordpress-mysql
- name: WORDPRESS_DB_PASSWORD
value: PassqUord_WodprEssDB # Normalemtne non andrebbe messa in chiaro qui ma questo è solo un esempio
- name: WORDPRESS_DB_USER
value: wordpress_USer # Wordpress DB username
ports:
- containerPort: 80
name: wordpress
volumeMounts:
- name: wordpress-persistent-storage
mountPath: /var/www/html
volumes:
- name: wordpress-persistent-storage
persistentVolumeClaim:
claimName: wp-pv-claim
---
To impement the changes, use the command:
$ kubectl delete –f wordpress.yaml
To check that our deployment has been successful, use the command:
$ kubectl get all
After configuring the WordPress service and ensuring everything is online without errors, it's time to connect the storage. Add the following lines of code at the top of the file you have from the previous execution:
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wp-pv-claim
labels:
app: wordpress
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
---
We should now be able to see our newly created volume with the command:
$ kubectl get pvc
f it displays correctly as created and with status Bound, it's time to connect it to our WordPress to create an ephemeral, "disposable" container with persistent storage that can be reused and won't be deleted if we destroy or move the pod.
Before continuing, scale our deployment to zero with the command:
$ kubectl delete –f wordpress.yaml
Go to the end of your file and add the following lines (the section in green):
- name: WORDPRESS_DB_USER
value: wordpress_USer # Wordpress DB username
ports:
- containerPort: 80
name: wordpress
volumeMounts:
- name: wordpress-persistent-storage
mountPath: /var/www/html
volumes:
- name: wordpress-persistent-storage
persistentVolumeClaim:
claimName: wp-pv-claim
---
With this and with the command:
$ kubectl apply -f wordpress.yaml
We have finally completed the installation of a WordPress container with a connected 20 GB persistent storage for our data. The last step is to create the load balancer that will allow us to access our presentation service from the public network.
Once this is done, we can move on to the backend level and deploy the database.
To create and connect the load balancer to our service, add the lines below (section in green) to the end of the wordpress.yaml file:
volumes:
- name: wordpress-persistent-storage
persistentVolumeClaim:
claimName: wp-pv-claim
---
apiVersion: v1
kind: Service
metadata:
name: wordpress
labels:
app: wordpress
spec:
ports:
- port: 80
selector:
app: wordpress
tier: frontend
type: LoadBalancer
---
Before running the file again, since we'll be assigning a public IP address to our load balancer (LB), you'll need to go to the
New Cloud Management Platform and purchase a
public IP address.
Specify a name for your reservation and create it in the same region where your cluster is located. IP addresses are announced on the public network from the region where they are reserved, so an address reserved in Rome cannot be used in PSP and vice versa.
Once this is done, apply your new configuration from the panel using the command:
$ kuiectl apply –f wordpress.yaml
Next, we check the outcome using the command:
$ kubectl get all
Our installation is now partially complete, but we need to instantiate a database so that our WordPress pod can function correctly.
Let's use what we have so far and create a deployment for a MySQL database with the same username and password used for the WordPress deployment.
For simplicity, you can create a new file or paste the code below at the end of the previous file where we described the WordPress deployment:
---
apiVersion: v1
kind: Service
metadata:
name: wordpress-mysql
labels:
app: wordpress
spec:
ports:
- port: 3306
selector:
app: wordpress
tier: mysql
clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
labels:
app: wordpress
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress-mysql
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
tier: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: wordpress
tier: mysql
spec:
containers:
- image: mysql:8.0
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: mysqlrootpassword # Utilizzare la password root di MySQL
- name: MYSQL_DATABASE
value: wordpress
- name: MYSQL_USER
value: wordpress
- name: MYSQL_PASSWORD
value: mysqlpassword # Utilizzare la password di MySQL
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
---
Just as we did earlier, we'll declare a service name for MySQL to allow WordPress to reach and use it, the declaration of the MySQL instance, the 20 GB storage, and directives for MySQL on how and where to use the storage.
Once we've verified that all changes are made correctly, go to the system's IP address to check that the WordPress website is online and you're greeted by the installation screen.
Proceed with the installation to create a minimal website complete with a content control panel and a theme.
From the WordPress control panel, add a couple of images to the media library and insert them into a post; these actions will save data both in the database's persistent storage and in the WordPress pod's persistent storage.
Now, let's verify the persistence of the systems by deleting the WordPress and MySQL pods and recreating them with the following commands:
$ kubectl get pods # For a list of pods that are currently online
$ kubectl delete nomepod-wordpress nomepod-mysql
If we immediately use the command to view all online pods, we'll see that the deployments have already detected that the containers are no longer online and have started new ones with the same configurations and connected volumes.
If you try to return to the WordPress site you configured, you should be able to view it without issues.
To delete the entire installation, simply execute:
$ kubectl delete –f wordpress.yaml