CREATING CUSTOMIZED DOCKER IMAGES

Part 4

In Part 4 of this 5-part tutorial, we will complete the integration of the “remote-host” container with Jenkins, so that we can proceed with the backup of the WordPress MySQL database using the customized container that we created in (Part 1, Part 2, and Part 3) of the tutorial.

In Part 3 of this tutorial, we had successfully taken a manual backup of the WordPress MySQL database, but that is not a practical solution for real-world deployment. This entire process should be automated, so that there is no manual intervention required from the user.

To achieve this automation, you need to ensure that WordPress, Jenkins and the “remote-host” pod are all running on the Kubernetes cluster.

In this tutorial, we will integrate the “remote-host” with Jenkins, write a bash script for automating the process and then create a job with cron, so that the backups are taken automatically and at a specific time as desired by us.

STEP1: Install the SSH plugin in Jenkins

To integrate the “remote-host” pod with Jenkins, the first thing we need to do is to install the SSH plugin in Jenkins.

Login to the Jenkins dashboard. (How to login to Jenkins dashboard is mentioned here.)
Dashboard –> Manage Jenkins –> Plugin Manager –> Available plugins –> Search (“SSH”) –> Select the SSH 2.6.1
Install the SSH 2.6.1 (or latest version) plugin without a restart.
Restart Jenkins after the plugin is installed.

This will restart the Jenkins container. Once the Jenkins is restarted you can check in the “Installed plugins”, SSH plugin should be displayed.

Dashboard –> Manage Jenkins –> Plugin Manager –> Available plugins –> Search (“SSH”) –> SSH 2.6.1 should be displayed

STEP2: Integrate Remote-host pod with Jenkins pod

Configure Jenkins with the remote host.

Dashboard -> Manage Jenkins –> Manage Credentials –> System –> Global credentials (unrestricted) –> Add Credentials.
- New Credentials –> kind (SSH Username with private key) –> Username (remote_user) –> Private Key –> Enter directly –> (enter the private key created using ssh-keygen cmd for the remote user done in Part 1) –> Create

Configure the SSH host.

Prior to configuring the SSH host, we need to set up CSRF Protection in Jenkins.

CSRF protection uses a token (called crumb in Jenkins) that is created by Jenkins and sent to the user. Any form submissions or similar action resulting in modifications, like triggering builds or changing configuration, requires that the crumb be provided.

Dashboard –> Manage Jenkins –> Security –> CSRF Protection –> Enable proxy compatibility (Select this option) –> Save
Dashboard –> Manage Jenkins –> Configure System –> SSH remote hosts –> Hostname (clusterIP of “remote-host” pod (10.97.129.185). ) –> Port –> 22 –> Credentials –> “remote_user” (created earlier) –> check connection (if successful) –> Save

You can obtain the ClusterIP of the “remote-host” pod by running the below command on the Master node:

- $ kubectl get all -n remote-host

It should give the below output:

NAME              READY   STATUS    RESTARTS   AGE

pod/remote-host   1/1     Running   0          21h

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE

service/remote-host   ClusterIP   10.97.129.185   <none>        22/TCP    21h

STEP 3: Store sensitive passwords secretly in Jenkins

To create automatic jobs for backups, we provide info on all other parameters in the script in the Jenkins job. However, info like AWS_ACCESS,ID, AWS_SECRET_KEY and DATABASE_PASSWORD is not provided in the script or directly in the Jenkins job.

Jenkins provides mechanisms so that these secret credentials can be stored in Jenkins and then used whenever and wherever required.

Create secret keys for AWS_SECRET_KEY, AWS_ACCESS_ID and DATABASE_PASSWORD in Jenkins.

On the Jenkins dashboard

Create the AWS_SECRET_KEY credentials.

Dashboard –> Manage Jenkins –> Manage Credentials –> System –> Global credentials –> Add credentials –> Kind –> Secret Text –> ID –> “AWS_SECRET_KEY ” –> Secret –> (Provide the “Secret access key” from the Excel sheet which is downloaded when the “remote_user” was created) –> Description –> “Remote user AWS Secret Key” –> Create

Below is a screenshot of AWS_SECRET_KEY:

Create the AWS_ACCESS_ID credentials.

Dashboard –> Manage Jenkins –> Manage Credentials –> System –> Global credentials –> Add credentials –> Kind –> Secret Text –> ID –> “AWS_ACCESS_KEY_ID” –> Secret –> (Provide the “Access key ID” from the Excel sheet which is downloaded when the “remote_user” was created) –> Description –> “Remote user AWS Access Key ID” –> Create

Below is a screenshot of AWS_ACCESS_KEY_ID:

Create the WordPress MySQL password credentials.

Dashboard –> Manage Jenkins –> Manage Credentials –> System –> Global credentials –> Add credentials –> Kind –> Secret Text –> ID –> “WP_MYSQL_PASSWD” –> Secret –> (Provide the WordPress MySQL password) –> Description –> “WordPress MySQL Password” –> Create

Below is a screenshot of the MySQL password screen.

In the above 3 steps, we have stored the credentials of user “remote_user” for AWS secret key and Access key ID. We have also stored the WordPress MySQL password.

As these credentials are sensitive and secretive, they should not be directly mentioned in any script. However, using Jenkins’s Global credentials we can now define the credentials in our bash script, without the threat of openly declaring the credentials.

The Global credentials should look like below:

STEP 4: Create the automated script for backup and configure remote-host pod

We will now create a shell script to automate the process of taking a backup.

The script for taking automated backup is below. You can create this script on your Laptop or desktop. We have named this script “my-wp-db-backup-s3.sh” but you can give it any name you like.

my-wp-db-backup-s3.sh

#!/bin/bash
DB_HOST=$1
PASSWD=$2
DB_NAME=$3
AWS_ACCESS_ID=$4
AWS_SECRET=$5
AWS_DIR=$6
DATE=$(date +%d%m%y-%H%M%S)
BACKUP=my-db-backup-$DATE.sql
mysqldump -u root -h $DB_HOST -p$PASSWD $DB_NAME > /tmp/$BACKUP &&\
export AWS_ACCESS_KEY_ID=$AWS_ACCESS_ID &&\
export AWS_SECRET_ACCESS_KEY=$AWS_SECRET &&\
export AWS_DEFAULT_REGION=ap-south-1
echo “Uploading ….”
aws s3 mv /tmp/$BACKUP s3://$AWS_DIR/$BACKUP ### This moves the sql file directly to s3 ###

Important:

This script has to be stored and run from the “/tmp” directory of the “remote_host” pod. This script “my-wp-db-backup-s3.sh” can be manually copied, however, if the “remote-host” stops and is restarted, the “my-wp-db-backup-s3.sh” script will no longer be present in the “/tmp” directory. Due to this we will not be able to take automated backups and we will have to copy the “my-wp-db-backup-s3.sh” script, again in the “tmp” directory.

To overcome this situation and ensure that the backup environment is automated, we will have to permanently mount the “my-wp-db-backup-s3.sh” script on the “remote-host” pod.

To permanently mount the shell script on the “remote-host” pod, we need to modify the “remote-host” Kubernetes deployment files.

We will modify the “remote-host-pv.yaml“, “remote-host-pvc.yaml“, and the “remote-host-deploy.yaml” files.

What we will be doing is to permanently store the “my-wp-db-backup-s3.sh” on the EFS of the Worker node and ensure that whenever the “remote-host” pod comes up, it automatically mounts the above shell script in the “/tmp” directory of the “remote-host” pod.

Jenkins will always run the script from the “/tmp” directory of the remote host.

In Part 5 of this tutorial, we will automate the process of backing up the WordPress MySQL database to the AWS S3 bucket.

Part 3–> Deploying the customized pod on Kubernetes

Part 5 –> Automating the backup process

Information

Follow Us

Information

Follow Us