DEV Community: Mubin

MERN CI/CD Project Using AWS Cloud Native Tools

Mubin — Sun, 25 Jun 2023 03:34:24 +0000

Turn any MERN stack application into a CI/CD project using the cloud native tools provided by AWS!

This article will walk you through doing just that.

We will need to modify the MERN app source code to fit the CI/CD flow.

The flow is pretty straightforward. The developer will push the code on GitHub, which triggers “AWS Codepipeline” and it will start the CI/CD pipeline by first pulling the source code and generating build using “AWS CodeBuild”. Then the generated build artifacts will be stored in the S3 bucket in versions and the application will be deployed by “AWS CodeDeploy”.

Let’s get started!!!

Step 1: AWS Role creation

AWS CodeDeploy and the EC2 instance would need permission to access the build artifacts from S3 storage.
So, we’ll begin by creating roles for them.
Go to Roles inside the IAM dashboard on the AWS console.
Click Create Role button. Select “AWS Service” as the entity type and “EC2” option in common use cases.

In the Permissions policy, search for "s3readonly", select "AmazonS3ReadOnlyAccess" from the entry, and click the next button.

Give any name (like "EC2S3ReadPermission") for this role in the text box and click create role button at the bottom of the screen.
Go back to the create role page and select "AWS service" like before, scroll down to the bottom of the page, and select "CodeDeploy" from the dropdown field in the use cases for other AWS services.
After selecting this option, select the first radio option with the text "CodeDeploy"

When you click next, the "AWSCodeDeployRole" policy would be attached. Click next and on the final page give a name (like CodeDeployPermission) and click "Create role".

Step 2: Launch the EC2 instance

Now, we will launch an EC2 instance where we will run Docker.
In the EC2 launch instance page, give any name ("mern-devops") and select Amazon Linux 2 AMI image.
In the Network Settings, allow SSH traffic and HTTP from anywhere.
If you have a key pair already select it or else create a new one.
Ensure "Auto-assign public IP" is selected in Network Settings.
Scroll down and open the "Advanced Details" section.
For the "IAM instance profile" field, open the dropdown and select the role created for the EC2 instance (EC2S3ReadPermission)as shown in the image below.

Once the instance is created and ready, ssh into it:
ssh -i <login-key-file> ec2-user@<public-ip-of-ec2-instance>

Step 3: Configuration & Installation

Inside the terminal connected to the EC2 instance via SSH, run the update command: sudo yum update -y
Then add a user (give any name and password):

sudo su
useradd mubin
passwd mubin

Now make this user a sudoer:

echo "mubin ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

Note: The above setting is not good for production environment.

Now switch to this user and install Docker

su - mubin

sudo yum install docker -y

Start the service: sudo service docker start
Switch to root user and add the user to the docker group

sudo su

usermod -aG docker mubin

Switch back to the normal user: su - mubin
Check the docker installation by running : docker ps
Next, install the Docker Compose tool and check its installation:

#download the binary
sudo curl -L "https://github.com/docker/compose/releases/download/1.23.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

#make binary executable
sudo chmod +x /usr/local/bin/docker-compose

#check installlation
docker-compose --version

Next, we need to set up a CodeDeploy agent.

sudo yum install ruby
sudo yum install wget
wget https://aws-codedeploy-us-east-1.s3.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto

Check the status of the service: sudo service codedeploy-agent status
Let's check if this EC2 instance has access to S3 storage. Run aws s3 ls
If we don't get any error in the console output, it means our instance has access.
Go to the AWS console and create a bucket. Give a name like "mern-artifact-bucket" . Enable Bucket versioning and click the "Create bucket" button. You can verify bucket creation by going back into the console connected to EC2 via SSH and run aws s3 ls . And you should see the name of the bucket appearing.

Step 4: Prep existing MERN app source code

Now we need a MERN app source code from GitHub or any other platform that we can use.
You can search for it or use your own existing repo.
I am going to follow an architecture where you have a "client" folder for the front-end and a "server" folder for the back-end. You can also put source code for front-end from a separate repo and put it inside "client" directory and place back-end source code from another repo and place it inside "server" directory. Please ensure that there is no .git folder in either of "client" and "server" directory.

I am going to use my own MERN stack app code which is a StackOverflow clone. The repo location for this project can be found here. I'll be removing the .git folder from the root of the repo, since I'll be modifying it and creating it as a new repo for our CI/CD project.

Once you have the source code in your local system, open it up in your favorite code editor.

First, create a folder, in the root path of our source repo, by the name "nginx" with nginx.conf file inside it with the following content:

#vi nginx.conf
upstream nodeapp{
     server node_app:3001;
}

server {
  listen 80;
  root /usr/share/nginx/html;
  index index.html;

  location / {
   try_files $uri /index.html =404;
  }

  location /test {
 proxy_pass http://nodeapp/test;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
  }

  location /user/ {
        proxy_pass http://nodeapp/user/;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
    }

    location /questions/ {
        proxy_pass http://nodeapp/questions/;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
    }

    location /answer/ {
        proxy_pass http://nodeapp/answer/;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
    }

    location /static/css {
        alias /usr/share/nginx/html/static/css;
    }

    location /static/js {
        alias /usr/share/nginx/html/static/js;
    }

    location = /favicon.ico {
        alias /usr/share/nginx/html/favicon.ico;
    }

}

As seen from the above file we are configuring Nginx by setting up reverse proxy and API endpoints defined in each location directive based on the routes defined in the back-end of application source code. We are giving an alias of "node_app" for our back-end server.

Then create Dockerfile inside the server directory with the following content:

#vi server/Dockerfile
FROM node:latest

WORKDIR /app

COPY . .

RUN npm install

EXPOSE 3001

Create a file .dockerignore with the content node_modules , both in the root project and inside the server directory.

Next, create Dockerfile in the root of the repo with the following content

#vi Dockerfile
FROM nginx:latest

WORKDIR /usr/share/nginx/html

COPY . .

RUN rm /etc/nginx/conf.d/default.conf

COPY ./nginx.conf /etc/nginx/conf.d

ENTRYPOINT [ "nginx" , "-g" , "daemon off;" ]

In this file, we are setting up a working directory for the client side, copying all files from the build into the working directory, replacing default nginx default configuration with our custom configuration file and running nginx in the foreground (so that container keeps running without halting).

Copy this Dockerfile inside the nginx folder as well.

Then create a "docker-compose.yml" file with the following content:

#vi docker-compose.yml
version: "3.3"
services:
  nginx_app:
    container_name: nginx_app
    build:
      context: ./nginx
      dockerfile: Dockerfile
    ports:
      - 80:80
    restart: always

  node_app:
    container_name: node_app
    build:
      context: ./server
      dockerfile: Dockerfile
    command: npm start
    restart: always
    expose:
      - 3001
    ports:
      - 3001:3001
    links:
      - mongo_db

  mongo_db:
    container_name: mongo_db
    image: mongo
    volumes:
      - mongo_volume:/data/db
    expose:
      - 27017
    ports:
      - 27017:27017

volumes:
  mongo_volume:

In this file, we are defining services for Nginx, server, and Mongo DB. We are also setting up containers for each of the services.

Important: Please use the version specified as it is, else you will encounter error during deployment

We are using persistent storage as seen in the volumes section of the mongo_db container.

Next, create a scripts folder in the root of the repo and put two bash files inside it (start-containers.sh and stop-containers.sh ) with the following respective content:

#start-containers.sh

#!/bin/sh
cd /home/mubin/devopspipeline

docker-compose build
docker-compose up -d

#stop-containers.sh

#!/bin/sh

cd /home/mubin/devopspipeline
sudo cp -r build/* nginx

if ! docker info > /dev/null 2>&1; then
    service docker start
fi

docker-compose down
echo $?

In start-containers.sh script file we are navigating to the "devopspipeline" directory inside the home directory of our user and then running docker-compose build which will read our docker-compose.yml which in turn will look for all services and run a docker build for each one. And finally docker-compose up -d to create and start containers in the background.

In stop-containers.sh, we are copying all the files from the build into the nginx and shutting down containers. The next code snippet checks if the docker is started or not. If it is not running then start the service. This is required when you stop your instance for some reason and resume again. Also in a fresh deployment, there will be no containers, the last command echo $? will output a non-zero value.

Now open up your .env file or the file where the Mongoose connection is being made and change the Mongo URL as
mongodb://mongo_db:27017/stack-overflow-clone

Instead of using localhost or "127.0.0.1", we are using "mongo_db", since this is what we have specified in the docker-compose.yaml

In the package.json file located inside the client directory, add the Nginx proxy:

"proxy": "http://node_app:3001",

Also, replace any localhost with the public IP of the EC2 instance on the client side (either in .env) or wherever the client is referencing the server/back-end.
To wind up our MERN source code we need two more files: appspec.yml and buildspec.yml.
The appspec.yml will be used by AWS CodeDeploy to manage deployment, while buildspec.yml which contains a collection of build commands and related settings that will be used by AWS CodeBuild.
So in the root path of the repo, create these two files with the following content:

#vi appspec.yml
version: 0.0
os: linux
files:
  - source: /
    destination: /home/mubin/devopspipeline
permissions:
  - object: scripts/
    mode: 777
    type:
      - directory
hooks:
  AfterInstall:
    - location: scripts/stop-containers.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start-containers.sh
      timeout: 300
      runas: mubin

#vi buildspec.yml
version: 0.2
phases:
  install:
    commands:
      - echo "the installation phase begins"
  pre_build:
    commands:
      - echo "the prebuild phase begins"
      - cd client
      - npm install
  build:
    commands:
      - echo "the build phase begins"
      # - echo `pwd`
      - npm run build
      # - echo `ls -la`

  post_build:
    commands:
      - echo "the post build phase. navigating back to root path"
      - cp -R build/ ../

artifacts:
  files:
    - build/**/*
    - appspec.yml
    - server/**/*
    - nginx/*
    - scripts/*
    - docker-compose.yaml
    - Dockerfile

In appspec.yml file, we define our deployment configuration like the choice of the operating system, recursively copy all files from / path to "devopspipeline" directory inside our user's home directory and then run scripts in respective hook actions. If the "devopspipeline" directory doesn't exist, it will get created during the deployment process. Next, we are giving execute permission to all files in the scripts directory.
The "AfterInstall" hook is triggered after the CodeDeploy operation is completed i.e. after our app is deployed.

In buildspec.yml file, we are specifying certain commands at different phases (majorly to build front-en d/client side) and finally defining our list of artifacts.

_Important: Please ensure that version mentioned in both appspec.yml and builspec.yml is same as written in the snippet above. Otherwise you will encounter errors.

Note: */ represents all files recursively._

That's it! With the above structure, set this up as our new repo on GitHub.

Step 5: AWS Tools setup and manual flow

Go to the CodeBuild page on AWS Console. Then click the "Create build project" button.
Give a name like "MyMernBuild".
Scroll down and in the Source section, select "GitHub" as the source provider and select the "Repository in my GitHub account" option in the Repository field. Click Connect to GitHub. In the pop-up window, provide your GitHub credentials and provide confirmation of access.
you should see a message like "You are connected to GitHub using OAuth".

Enter the URL of your repo. Enter "main" as the source version. Scroll down to the Environment section and select "Amazon Linux 2" as the operating system. Select "Standard" as runtime.
Select "aws/codebuild/amazonlinux2-arch-x86_64-standard:4.0". Select "Linux" as the environment type.
For the "Service role" field, select the "New service role" option.
In the Role ARN field, select a new service role and give a name ("MyMernBuild").

Scroll to the Buildspec section, and make sure the "use a buildspec file" option is selected.
Also since we have named our file as "buildspec.yml" we can leave the Buildspec name field blank. Had the file name been different, we would have had to enter that in this field.

Scroll down to the Artifacts section, and select the Amazon S3 option in the type field.
Enter the bucket name ("mern-artifact-bucket") that we created at the beginning of the project.
Select the "Zip" option for the Artifacts packaging field.
Check the CloudWatch logs as it will help us in reading logs in case something fails in the pipeline. Give any group name ("mymernbuildlogs") and stream name ("mymernlogs").

Click the "Create build project" button.

Since we added a new service role we need to give this role S3 permission.

So go to the Role section on the IAM page. Click on the new role name we have given (MyMernBuild). Then click "Add Permissions" to open the dropdown and then click "Attach policies". In the new window, by "s3fullaccess". Check "AmazonS3FullAccess" and click the "Add permissions" button. Once this permission is added, come back to the CodeBuild page.

Click the "Start build" button. This will start to create a build and also upload it to our S3 bucket, wait until the build succeeds.

You can then verify whether all artifacts are present in the bucket by going into the S3 bucket page and clicking the Download button.

You can tick the checkbox against your build name and click download. You should see a zip file getting downloaded.
You can unzip and verify that it contains all the artifact files and folders specified in the buildspec.yml file are present in the zip file.

Now go back to the AWS console in the browser and search for CodeDeploy in the search bar and open the AWS CodeDeploy page. Click Application from the left menu.
Then click Create Application button.
Give it a name like "MyMernDeploy" and for the Compute platform, select the "EC2/On-premises" option.
Click on the Create button.

Once created, click the "Create deployment group" button.
On its creation page, enter a deployment group name (like "MyMernDeploymentGroup").
In the Service role section, type the role name that we created earlier for CodeDeploy (we gave "CodeDeployPermission")
and select the option accordingly.
In the environment configuration, tick the "Amazon EC2 instances" and in the tags field, enter "Name" as the key and value as "mern-devops" (the one which we gave to our EC2 instance at the beginning). Once you do this, you should see a message like this:

Scroll down and uncheck Load Balancer, since we will be creating it manually later. Click Create button.

Once the Deployment group is created, click the "Create deployment" button.
In this screen, ensure that for the Revision type field "My application is stored in Amazon S3" is selected.

Copy the S3 URI from the S3 bucket page and paste it into the "Revision location" field.
Then select "zip" as an option for the Revision file type field.
Click create deployment button.

Once the deployment is created, you should see all the artifacts in the "/home/mubin/devopspipeline" directory.

Note: To see deployment logs, open terminal connected to EC2 instance via SSH
tail -50 /var/log/aws/codedeploy-agent/codedeploy-agent.log

Now run, docker ps and you should see the containers running.

If you copy the EC2 instance public IP and paste it into the browser, you should see our app running.

Try out registering as a new user and then log in. The application should be working.

Now we need to automate the flow, so that every time we push the changes, AWS CodeBuild will be triggered, which will in turn trigger AWS CodeDeploy.

Step 6: AWS CodePipeline

Back in the AWS console in the browser, search for CodePipeline.
On the Codepipeline page, click the "Create pipeline" button.
Give a name like "MyMernPipeline".
Select "New service role" in the Service role field.
Expand the "Advanced Settings" section and select the "Custom location" option and enter the bucket name in the Bucket field, click the next button. In the next screen, for the Source provider field, select GitHub Version 1 option, since we will be using password-based authentication.

It is recommend by AWS to use GitHub version 2.

Click the "Connect to GitHub" button.
In a new pop-up window, click confirm button and you should see that the pop window gets closed and a success message.
Enter the repository name and main as the branch. Select "GitHub webhooks" as the Change detection option and click next.
On the next page, select AWS CodeBuild as the Build provider. Enter "MyMernBuild" in the Project name and click next.

On the next page, select AWS CodeDeploy as the Deploy provider. Enter "MyMernDeploy" in the Application name field.
Enter "MyMernDeploymentGroup" in the Deployment group field and click next.
Click create pipeline button.

Once the pipeline is created, you should the three stages, where the first stage is the source from GitHub, the second stage is to build from CodeBuild, and deploy using CodeDeploy.

So every time we push any changes to the repository, the pipeline will trigger and stages will run.

Also every time new changes are incorporated, artifacts will be generated with the same name. Hence the need for versioning in the S3 bucket, otherwise the build will fail.

Try changing some text or styling and push to GitHub and you should see the pipeline starting after the pipeline flow is complete, your new changes should be reflected on the web page.

Meanwhile, in the terminal connected to the EC2 instance via SSH, we will go into the container running Mongo docker exec -it <container-id-of-mongo> bash

Type mongosh and its shell should open.
run the command to show all databases: show dbs; and you should see your database.
Switch to our database use stackoverflow-clone
Show all users: db.users.find().pretty()

If you have registered in the application, you should see the user entry here:

Exit out of the shell by typing: exit. Type exit again to come out of the container.

Step 7 (Optional): Separate Volume for MongoDB

A recommended approach is to use persistent storage for MongoDB so that in the event of the instance getting terminated or corrupted our database is safe.

So we need to create a separate EBS volume and attached it to our instance and then mount that directory for MongoDB to use.

Go to the EC2 dashboard in the browser and click Volumes under the Elastic Block Store section. Click Create Volume. Select "gp2" as the volume type and can keep any size, but a minimum of 8GB is required. Ensure that this volume must be in the same availability zone (AZ) as the instance. You can check that by going to the details of the EC2 instance and under the Networking tab, see the AZ mentioned.
Add tag, with key as "Name" and value as "mern-mongodb-volume" and click create volume.

Once created, tick the checkbox against the volume name and click the Action button at the top and click Attach Volume. Enter the Instance by typing the tag and click attach.

Now, check if the volume is getting listed in our instance, by running the lsblk command in the terminal connected via SSH. You should see a new volume.

To check if our EBS volume is attached to any directory run:
sudo file -s /dev/xvdf
The output /dev/xvdf: data implies it is not attached to any directory.

In order to use, it we need to format it first.
sudo mkfs -t xfs /dev/xvdf

Then create a directory
sudo mkdir /mongodbvolume

Now mount the drive to the created directory
sudo mount /dev/xvdf /mongodbvolume

You can now access this directory and it should be empty.

Now, go to docker-compose.yaml file and make the following changes:

volumes:
 - mongo_volume:/data/db`

volumes:
 - /mongodbvolume:/data/db

Now push this code change via git which will trigger the AWS CodePipeline.

Now in the terminal connected to our EC2 instance via SSH, go inside the container (docker exec -it <container-id-of-mongo> bash) and again run the commands to show all users, you will find it empty i.e. there will be no output.
This is because we have changed the volume. So go back to the application in the browser and register as a new user.
Then come back to this mongo shell container and you should see the created user.

Step 8 (Optional): Create LoadBalancer

In this final step, we will make our application accessible via AWS ELB.

So open the EC2 dashboard in the AWS console in the browser.

First, go to Security Groups and click Create. Give a name like "my-mern-sg". Give the same description as the name. Select the default VPC. Click "Add rule" in the Inbound rules section. Enter port 80 in the Port range. Enter "0.0.0.0/0" as the CIDR block in Source and click create.

Next, in the left menu click LoadBalancer and click the "Create load balancer" button. Create an "Application Load Balancer". Enter a name (like my-mern-lb). Select at least two AZ. And in the Security Groups, enter my-mern-sg which we created above.

In the "Listeners and routing" section, click "Create Target Group".It will open a new window. In the new window of the Target Group creation screen, select Instances as the target type and give a target group name (like my-mern-tg). Ensure that the VPC is the default one. Expand the Tags section and enter "Name" as the key and "mern-devops" as the value (same tag as the EC2 instance). Keeping the rest of the field the same, click the next button at the bottom. In the next screen select our instance in the "Available instances" section and then click the "Include as pending below" button.

Then click "Create target group" at the bottom of the screen. Back in the "Listeners and routing" section in the LoadBalancer screen, click the refresh icon button and then select the target group we just created, and finally click create the load balancer.

Now go to the EC2 instance and in the networking tab, click the security group link under the Security tab. Click edit inbound rule. Click Add rule. Enter the "my-mern-sg" that we created and click save.

Now if you go back to the browser, our application will not load as we have configured our instance to run on LB.
So go to the created LB page and copy the DNS name and paste it into the browser.

That's it!!!

The Git repo for this article can be found here.

That's it! Hope you found the article useful.

Happy Coding!

If you found this post helpful, please like, share, and follow me. I am a developer, transitioning to DevOps, not a writer - so each article is a big leap outside my comfort zone.

If you need a technical writer or a DevOps engineer, do connect with me on LinkedIn: https://www.linkedin.com/in/mubin-khalife/.

Thank you for reading and for your support!

DevOps project using Terraform, Jenkins, and EKS

Mubin — Tue, 20 Jun 2023 10:53:27 +0000

In this article, we are going to create a DevOps project where we'll use Terraform, Jenkins, GitHub, and EKS.

The first part of the article deals with setting up a Jenkins server through Terraform.

The second part will deal with EKS setup using Terraform and setting up the Jenkins pipeline.

Note: It is assumed that you have Terraform and AWS CLI installed and configured on your local system. Please check this page for Terraform installation and this page for AWS CLI installation.

Let's begin!!!

Part 1: Jenkins server setup using Terraform

Terraform needs to store state information somewhere. We are going to keep it in AWS S3 storage.
So head over to your AWS panel and create a bucket. The bucket name has to be unique. So I am going to create it with the name: mubin-devops-cicd-terraform-eks , you'll have to keep something else. I'll be using US North Virginia (us-east-1) as the region for the bucket and keeping the rest of the settings the same to create the bucket.

We'll be needing a key to login into the Jenkins EC2 instance.
So go to the EC2 dashboard and scroll down to the Key Pairs link inside Network & Security menu.
Click the "Create key pair" button. Give a name like "jenkins-server-key". With the rest of the form fields as default, download the pem file and set its permission to 400.
chmod 400 jenkins-server-key.pem

Let's utilize the S3 storage to store terraform state by creating a terraform state file like below:

#backend.tf
terraform {
  backend "s3" {
    bucket = "mubin-devops-cicd-terraform-eks"
    region = "us-east-1"
    key = "jenkins-server/terraform.tfstate"
  }
}

Since we will be using AWS as a cloud provider with the "us-east-1" region, let's configure Terraform with this information as well.

#provider.tf
provider "aws" {
  region = "us-east-1"
}

Now let's declare terraform variables that we will be using.

#variables.tf
variable "vpc_cidr_block" {
 type = string
 description = "To set cidr for vpc"
}
variable "subnet_cidr_block" {
 type = string
 description = "To set cidr for subnet"
}
variable "availability_zone" {
 type = string
 description = "To set AWS availability region"
}
variable "env_prefix" {
 type = string
 description = "Set as dev or prod or qa etc. based on desired environment"
}
variable "instance_type" {
 type = string
 description = "To desired instance type for AWS EC2 instance"
}

Initialize the above variables in the "terraform.tfvars" file.

vpc_cidr_block      = "10.0.0.0/16"
subnet_cidr_block   = "10.0.10.0/24"
availability_zone   = "us-east-1a"
env_prefix          = "dev"
instance_type       = "t2.small"

We are using 'dev' as environment. You can change env-prefix variable according to your preference.
We are going to use the latest image of Amazon Linux 2 for our Jenkins server instance. If you go to the EC2 dashboard and select Amazon Linux 2, you see the following details:

As you can see the AMI value is "amzn2-ami-kernel-5.10-hvm-2.0.20230612.0-x86_64-gp2" which can be generalized using a regex style expression like: "amzn2-ami-kernel--hvm--x86_64-gp2"

Now we'll set up infrastructure for Jenkins through code.

Add the following content to the "server.tf" file.

data "aws_ami" "latest-amazon-linux-image" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["amzn2-ami-kernel-*-hvm-*-x86_64-gp2"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

resource "aws_instance" "myjenkins-server" {
  ami                         = data.aws_ami.latest-amazon-linux-image.id
  instance_type               = var.instance_type
  key_name                    = "jenkins-server-key"
  subnet_id                   = aws_subnet.myjenkins-server-subnet-1.id
  vpc_security_group_ids      = [aws_default_security_group.default-sg.id]
  availability_zone           = var.availability_zone
  associate_public_ip_address = true
  user_data                   = "${file("jenkins-server-setup.sh")}"
  tags = {
    Name = "${var.env_prefix}-server"
  }
}

We have customized the above by using official references from here and here for the above data and resource blocks respectively.

Once the instance is created, let's get the public IP of this instance by appending the below snippet in the above file.

output "ec2_public_ip" {
  value = aws_instance.myjenkins-server.public_ip
}

In the resource block, we used the jenkins-server-setup.sh script file to initialize packages on our Jenkins server. Let's create that file

#!/bin/bash

# install jenkins

sudo yum update
sudo wget -O /etc/yum.repos.d/jenkins.repo \
    https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key
sudo yum upgrade -y
sudo amazon-linux-extras install java-openjdk11 -y
sudo yum install jenkins -y
sudo systemctl enable jenkins
sudo systemctl start jenkins

# then install git
sudo yum install git -y

#then install terraform
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
sudo yum -y install terraform

#finally install kubectl
sudo curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.23.6/bin/linux/amd64/kubectl
sudo chmod +x ./kubectl
sudo mkdir -p $HOME/bin && sudo cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin

In the above script file, we are installing Jenkins, Git, Terraform, and Kubectl.

Now we need to set up the networking of our ec2 instance.

Let's start by creating "vpc.tf" file and entering the following content:

resource "aws_vpc" "myjenkins-server-vpc" {
  cidr_block = var.vpc_cidr_block
  tags = {
    Name = "${var.env_prefix}-vpc"
  }
}

resource "aws_subnet" "myjenkins-server-subnet-1" {
  vpc_id            = aws_vpc.myjenkins-server-vpc.id
  cidr_block        = var.subnet_cidr_block
  availability_zone = var.availability_zone
  tags = {
    Name = "${var.env_prefix}-subnet-1"
  }
}

resource "aws_internet_gateway" "myjenkins-server-igw" {
  vpc_id = aws_vpc.myjenkins-server-vpc.id
  tags = {
    Name = "${var.env_prefix}-igw"
  }
}

resource "aws_default_route_table" "main-rtbl" {
  default_route_table_id = aws_vpc.myjenkins-server-vpc.default_route_table_id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.myjenkins-server-igw.id
  }
  tags = {
    Name = "${var.env_prefix}-main-rtbl"
  }
}

resource "aws_default_security_group" "default-sg" {
  vpc_id = aws_vpc.myjenkins-server-vpc.id
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  ingress {
    from_port   = 8080
    to_port     = 8080
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "${var.env_prefix}-default-sg"
  }
}

In the above code, we are creating VPC with the CIDR block initialized in our variable file. Then we are creating a subnet in this VPC with its own CIDR block. Then we create Internet Gateway (IG) in this VPC. Then Route table is associated with our created IG. Finally, we are creating a Security Group (SG) which is allowing SSH port 22 and Jenkins web application port 8080 from everywhere.

It's not a good practice to allow all traffic from everywhere, but we are just doing this for testing purposes. If you want you can add your local system's public IP as CIDR block in the ingress rule.

Alright now our terraform scripts are ready, let's execute them.

Now open your favorite terminal and navigate to the directory where our above terraform scripts are located.

The first command to run is initializing the Terraform terraform init

The second command is to do a dry run i.e. to see what will happen when we apply the scripts. So run terraform plan . You should see output like this:

It implies that 6 resources will be created. One route table, one subnet, one internet gateway, one security group, one EC2 instance, and one VPC.
Cool! Let's apply this. Run: terraform apply - auto-approve Auto approve flag will not ask for confirmation. Once it is complete successfully, you can go to your AWS console and see all these 6 resources created.

Notice the EC2 public ip printed.

Most importantly you should see the S3 bucket containing Terraform's state file.

Let us set up the admin login of the Jenkins server. Copy the public IP of the EC2 instance and paste it into the address bar of your favorite browser. you should see the installation screen like this:

Log in to the instance via ssh by running:
ssh -i jenkins-server-key.pem ec2-user@<public-ip-of-instance> . Then copy the default password from /var/lib/jenkins/secrets/initialAdminPassword by running
sudo cat /var/lib/jenkins/secrets/initialAdminPassword and paste it into the input text box and click "Continue".

Click install selected plugins. Once done, create an admin user.

Now we need to establish a connection between Jenkins and GitHub. So go to Manage Jenkins by clicking on its link. Then click "Credentials".
Then in the tabular data, select the "global" link under the "Domain" column, as shown below:

Then in the Global credentials screen, click "Add Credentials".
Here we will first add our GitHub username and password to connect it to this Jenkins instance.
Select "Username and password" from the kind field. Ensure that "Global" is selected as the scope.
Enter your GitHub username and password. Give a recognizable ID, like "my-github-creds" and click create.
Once again back on the Global Credentials page click the "Add Credentials" button.
We need to add the AWS account access key id. Select "Secret Text" as the kind. In the ID field enter the "AWS_ACCESS_KEY_ID". And in the secret field enter your AWS account's access key id. Then hit create button.
Once again back on the Global Credentials page click the "Add Credentials" button. We need to add the AWS account secret key. Select "Secret Text" as the kind. In the ID field enter the "AWS_SECRET_ACCESS_KEY". And in the secret field enter your AWS account's secret key id. Then hit create button.

Next, we need to configure AWS CLI on this Jenkins EC2 instance. In the terminal connected to the instance via SSH, run aws configure and enter the values for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. Enter "us-east-1" for the AWS_DEFAULT_REGION.

This brings an end to our first part.

Part 2: Kubernetes setup using Terraform and Jenkins

Since two separate processes will be involved, one dealing with EKS setup and another for the pipeline, we will create two directories. Create the first one by the name "terraform-for-cluster" and another one by the name "kubernetes".

Navigate into the "terraform-for-cluster" directory. Let's start writing the required terraform files.

We will create the same "provider.tf" as the one created in part 1.

Also, we will use the same terraform state file but with a different key. Keeping the same key will overwrite the existing Jenkins infrastructure.

#backend.tf
terraform {
  backend "s3" {
    bucket = "mubin-devops-cicd-terraform-eks"
    region = "us-east-1"
    key = "eks/terraform.tfstate"
  }
}

Then we will create our custom VPC module in which our cluster will operate. We will use the code provided by Terraform here and tweak it a bit.

#vpc.tf
data "aws_availability_zones" "azs" {}
module "myjenkins-server-vpc" {
  source          = "terraform-aws-modules/vpc/aws"
  name            = "myjenkins-server-vpc"
  cidr            = var.vpc_cidr_block
  private_subnets = var.private_subnet_cidr_blocks
  public_subnets  = var.public_subnet_cidr_blocks
  azs             = data.aws_availability_zones.azs.names

  enable_nat_gateway   = true
  single_nat_gateway   = true
  enable_dns_hostnames = true

  tags = {
    "kubernetes.io/cluster/myjenkins-server-eks-cluster" = "shared"
  }

  public_subnet_tags = {
    "kubernetes.io/cluster/myjenkins-server-eks-cluster" = "shared"
    "kubernetes.io/role/elb"                  = 1
  }

  private_subnet_tags = {
    "kubernetes.io/cluster/myjenkins-server-eks-cluster" = "shared"
    "kubernetes.io/role/internal-elb"         = 1
  }
}

In the above script, we are setting our availability zone, public and private subnets with CIDR blocks value from the " terraform.tfvars" and NAT gateways.

The next step is to write a terraform module for the EKS cluster utilizing the above VPC module. We are going to be using the code provided here, by Terraform and tweak it to our requirement.

#eks-cluster.tf
module "eks" {
    source  = "terraform-aws-modules/eks/aws"
    version = "~> 19.0"
    cluster_name = "myjenkins-server-eks-cluster"
    cluster_version = "1.24"

    cluster_endpoint_public_access  = true

    vpc_id = module.myjenkins-server-vpc.vpc_id
    subnet_ids = module.myjenkins-server-vpc.private_subnets

    tags = {
        environment = "development"
        application = "myjenkins-server"
    }

    eks_managed_node_groups = {
        dev = {
            min_size = 1
            max_size = 3
            desired_size = 2

            instance_types = ["t2.small"]
        }
    }
}

Note the number of min, max, and desired nodes that we have set.

Let's configure terraform variables:

#terraform.tfvars
vpc_cidr_block = "10.0.0.0/16"
private_subnet_cidr_blocks=["10.0.1.0/24","10.0.2.0/24","10.0.3.0/24"]
public_subnet_cidr_blocks=["10.0.4.0/24","10.0.5.0/24","10.0.6.0/24"]

Define the above variables in its own file:

#variables.tf 
variable "vpc_cidr_block" {
 type = string
}

variable "private_subnet_cidr_blocks" {
 type = list(string)
}
variable "public_subnet_cidr_blocks" {
 type = list(string)
}

Now, that Terraform part is complete, let's look at the Jenkins pipeline code that we would be running from the Jenkins web panel.

#Jenkinsfile
pipeline {
    agent any
    environment {
        AWS_ACCESS_KEY_ID = credentials('AWS_ACCESS_KEY_ID')
        AWS_SECRET_ACCESS_KEY = credentials('AWS_SECRET_ACCESS_KEY')
        AWS_DEFAULT_REGION = "us-east-1"
    }
    stages {
        stage("Create an EKS Cluster") {
            steps {
                script {
                    #Give the location of terraform scripts directory relative 
                    #to the repo
                    dir('part2-cluster-from-terraform-and-jenkins/terraform-for-cluster') {
                        sh "terraform init"
                        sh "terraform apply -auto-approve"
                    }
                }
            }
        }
        stage("Deploy to EKS") {
            steps {
                script {
                    #Give the location of kubernetes scripts directory relative 
                    #to the repo
                    dir('part2-cluster-from-terraform-and-jenkins/kubernetes') {
                        sh "aws eks update-kubeconfig --name myapp-eks-cluster"
                        sh "kubectl apply -f deployment.yaml"
                        sh "kubectl apply -f service.yaml"
                    }
                }
            }
        }
    }
}

Let's go through the overview of the above script.
We are first setting our environment variables related to AWS. Then we are creating two stages for the pipeline.
In the first stage, we are creating a cluster for Kubernetes by specifying from which directory the terraform scripts should run.
In the second stage, we are deploying the default Nginx app on Kubernetes. We specify "kubernetes" as the directory as that is where our scripts for deployment and service will be located.
In that directory, we have two files, one for deployment and another one for exposing it as a service of type LoadBalancer.

#deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

#service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

Next, go to the Jenkins panel. From the dashboard click "New Item" from the left side menu. In the new screen, give a name and select "Pipeline" and click ok. This will create a pipeline. Scroll down to the Pipeline field. Select "Pipeline script from SCM". Then select "Git" as an option in the SCM field. Then enter the above repository URL in the "Repository URL" field. Then in credentials, select the git credentials that we created earlier in Jenkins. Then change the branch to "/main" instead of "/master". Then in the "Script" field give the location of Jenkinsfile e.g "part2-cluster-from-terraform-and-jenkins/Jenkinsfile"
Finally, click "Save".

Part 3: Witness the Action

Go to the created Jenkins pipeline in the web browser and click on "Build Now" from the left menu of the pipeline to set up EKS.

It will take about roughly 15 minutes to set up everything on AWS.

Once you see the "success" message of the build, go to EKS on the AWS console. You can see our cluster got created. Also when you go to S3 on the AWS console, you should be able to see one more folder by the name "eks" and a terraform state file inside it, which is related to the EKS cluster.

Then go to EC2, you should see our LoadBalancer also got created. Click on it and you should see the DNS name in the description section. Copy it and paste it in the browser and you should see nginx running

To clean up these resources created (things like LoadBalancers are not free in AWS), in your local system, navigate to the directory where the second part of terraform scripts are located. run:

terraform destroy - auto-approve

That's it! All your dynamically created resources will now be destroyed.

The Git repo for this article can be found here.

Hope you found the article useful.

Happy Coding!

If you found this post helpful, please like, share, and follow me. I am a developer, transitioning to DevOps, not a writer - so each article is a big leap outside my comfort zone.

If you need a technical writer or a DevOps engineer, do connect with me on LinkedIn: https://www.linkedin.com/in/mubin-khalife/.

Thank you for reading and for your support!

ElasticSearch in PHP

Mubin — Fri, 09 Jun 2023 12:39:10 +0000

A little overview of Elasticsearch

Elasticsearch is a real-time distributed and open-source full-text search engine.

It is accessible from the RESTful web service interface and uses schema-less JSON (JavaScript Object Notation) documents to store data.

Elasticsearch can be used as a replacement for document stores like MongoDB.

The following are key terminologies associated with Elasticsearch:

i) Node: It is a single-running instance of Elasticsearch. Multiple nodes could be running on a single server depending on its resource capabilities.

ii) Cluster: As the name suggests, it is a collection of one or more nodes that provides collective indexing and search capabilities across all nodes

iii) Index: Index is a collection of different types of documents and their properties. This means that you can have a collection of documents that contains data for a specific part of the application. In RDBMS it is analogous to a table.

iv) Field: A field is analogous to a column in RDMS.

v) Document: A document is a collection of fields in JSON format. In RDBMS it is analogous to a row. Every document has a unique identifier called UID.

vi) Shard: Indexes are horizontally subdivided into shards. This means that each shard contains all the properties of the document but contains less number of JSON objects. It is more like a subset of the entire index. It acts like an independent node and can be stored in any node. The primary shard is the original horizontal part of an index.

vii)Replicas: Elasticsearch allows users to create replicas of their indexes and shards. Replication helps in increasing the availability of data in case of failure. This also improves the performance by carrying out parallel search operations in these replicas.

Alright! Now that you are familiar with Elasticsearch, let’s put it to use in our simple PHP application

Installation & Configuration
We need to set up an Elasticsearch node. So install it from the instructions provided here.

I’m going to be using Ubuntu for this article. I am running Ubuntu on Vagrant. We can install via apt-get, but I’ll download the Debian package instead and run it.

#download with a simple name wget -c https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.8.0-amd64.deb -O elastic.deb

#run installer sudo dpkg -i elastic.deb

Elasticsearch also needs Java to run. So let’s install Java.

sudo apt-get update sudo apt install openjdk-11-jre-headless

We cannot run Elasticsearch as the root user. So, we need to give our user the required permission on certain files:

sudo chown -R $USER:$GROUP /etc/default/elasticsearch sudo chown -R $USER:$GROUP /usr/share/elasticsearch/ sudo chown -R $USER:$GROUP /etc/elasticsearch sudo chown -R $USER:$GROUP /var/lib/elasticsearch sudo chown -R $USER:$GROUP /var/log/elasticsearch

Modify its configuration file located at /etc/elasticsearch/elasticsearch.yml with the below content

xpack.security.enabled: false xpack.security.enrollment.enabled: false xpack.security.http.ssl: enabled: false keystore.path: certs/http.p12 xpack.security.transport.ssl: enabled: false

Configure Java path for Elasticsearch. Open /etc/default/elasticsearch and enter the following:

ES_JAVA_HOME=/usr/bin/java

Start the Elasticsearch service

sudo systemctl daemon-reload sudo systemctl enable elasticsearch.service sudo systemctl start elasticsearch.service
Let’s start the Elasticsearch instance. Simply run:

/usr/share/elasticsearch/bin/elasticsearch

Manual Testing

We need a REST client to perform manual operations on Elasticsearch. Visual Studio Code is a popular editor. We are going to use it. If you don’t have it already, then download it. We will use the “Thunder Client” plugin which is available in Visual Studio Code. So open your Visual Studio Code editor. From the left sidebar, click the extension icon. A drawer will open. In the search text field, enter “Thunder Client” and click the first item in the list. Then in the content area, click the install button.

Once this is installed, you’ll find the “Thunder Client” icon in the left sidebar. Click on it. It will open a side drawer. In that click, the “New Request” button.

In the content area, select the “PUT” method and enter the URL as “http://127.0.0.1:9200/blog" and hit the send button.

It’ll create an index by the name of “blog” as verified in the response:

Let’s test further by adding a record inside this index.

Click, the “New Request” button on the left side of the editor, select the “POST” method, and enter the URL as http://127.0.0.1:9200/blog/_doc/1.

Here “1” is the id for our intended document, which we are providing manually. Enter the following JSON content:

{ "title": "This is a test blog post", "body":"A dummy content for body of the post" }

Now hit send button and you should see the output like this:

If you send the data again, then it will increment its version. Basically an update operation.

Let’s do that. Since we need to be storing the “tags” field as well. Modify the JSON content like the below and hit send:

{ "title": "This is a test blog post", "body":"A dummy content for body of the post", "tags":["blog","post","test"] }

You should see output something like:

As you can see, the version of the record got updated from 1 to 2.

Insert another record without entering any manual id number. Click, the “New Request” button on the left side of the editor, select the “POST” method, and enter the URL as http://127.0.0.1:9200/blog/_doc.

Enter the following JSON content:

{ "title": "What is Lorem Ipsum?", "body":"Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.", "tags":["lorem","ipsum","capsicum"] }

Notice the “_id” value. It got assigned automatically.

To fetch all documents in the index, click the “New Request” button on the left side of the editor, select the “GET” method, enter the URL as http://127.0.0.1:9200/blog/_search and hit Send button:

Let’s delete the index so that we can start afresh.

Click the “New Request” button on the left side of the editor, select the “DELETE” method, enter the URL as http://127.0.0.1:9200/blog, and hit Send button.

Now when you search again you should get “index_not_found_exception”.

We are now set to perform operations programmatically.

Setup client
First, install the Apache web server.

sudo apt update && sudo apt install apache2 && sudo apt install libapache2-mod-php

Then make index.php as having high priority over its HTML counterpart. Open /etc/apache2/mods-enabled/dir.conf and change:

DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm

DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm

Restart Apache service:

sudo systemctl restart apache2

Now we are ready to code our web application. Since it is going to be a PHP application, let’s install it.

sudo apt install php-cli unzip

We need a PHP client for Elasticsearch. For that we need Composer. Composer is a PHP package dependency manager, like NPM for NodeJS.

To install composer, simply run:

curl -sS https://getcomposer.org/installer -o /tmp/composer-setup.php sudo php /tmp/composer-setup.php --install-dir=/usr/local/bin --filename=composer

Check the installation by running:

composer --version

Now go to /var/www/html and run this command to download the client:

composer require elasticsearch/elasticsearch

This will create a vendor directory and composer.json file.

Now create an additional directory with a client initialization script

mkdir app cd app touch init.php

Paste the following content in the init.php file

<?php require_once 'vendor/autoload.php'; $es = new Elasticsearch\Client([ 'hosts' => ['127.0.0.1:9200'], ]); ?>

The above code initializes the Elasticsearch client that will run on localhost at port 9200

Time for the web interface.

We are going to create two screens, one for searching and another one for adding data. We are going to keep the interface to a minimum.

So let’s create the first screen, index.php, and enter the following content:

<?php
require_once "app/init.php";

if(isset($_GET['q'])){
        $q = $_GET['q'];
        $query = $es->search([
            'body'=> [
                'query' => [
                    'bool' => [
                        'should' => [
                            [ 'match' => [ 'title' => $q ] ],
                            [ 'match' => [ 'body' => $q ] ],
                        ]
                    ]
                ]
            ]
        ]);

     if($query['hits']['total']["value"] >= 1){
        $results = $query['hits']['hits'];
     }
}
?>
<!doctype html>
<html>
    <head>
        <meta charset="utf-8">
        <title>Search | ElasticSearch Demo</title>
 <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM" crossorigin="anonymous">    
   </head>
    <body>
     <div class="row mt-3">
            <div class="mx-auto col-10 col-md-8 col-lg-6">
                <!-- We are setting method as GET for form post, so we can see the enered text in url -->
                <form action="<?=$_SERVER["PHP_SELF"]?>" method="GET" autocomplete="off">
                    <div class="row mb-3">
                        <div class="col">
                        <input type="text" class="form-control" name="q" placeholder="Enter text to Search Blog" />
                        </div>
                    </div>
                    <div class="row mb-3">
                        <div class="col">
                            <input type="submit" class="btn btn-primary" value="Search" />
                        </div>
                    </div>
  </form>
  <?php
        if(isset($results)){
            foreach($results as $r){
    ?>
            <div class="row mb-3">
                <div class="col">
   <div class="alert alert-secondary" role="alert">
                        <p class="fw-bolder"><?=$r["_source"]["title"]?></p>
                        <?=implode(",",$r["_source"]["tags"])?>
                    </div> 
  </div>
            </div>
    <?php
            }
 }else{
   echo '<div class="alert alert-danger" role="alert">
   No data found
    </div>';
 }
    ?>
            </div>
        </div>
            <!-- We are going to skip validation checks -->
    </body>
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js" integrity="sha384-geWF76RCwLtnZ8qwWowPQNguL3RmwHVBC9FhGdlKrxdiJJigb/j/68SIy3Te4Bkz" crossorigin="anonymous"></script>
</html>

Let’s analyze the code above. The PHP code before HTML doctype declaration is sub-divided into three parts:
i) Requiring the Elasticsearch client, which we created before, in this script
ii) If we get URL parameter ‘q’, then we are going to perform a search operation query on Elasticsearch on the “title” and “body” fields.
iii) $query[‘hits’][‘total’][“value”] will check if there is at least one record is present. If there is, then initialize a “results” variable like this:

$results = $query['hits']['hits'];

And after the closing of the HTML form tag, we are checking if the “results” variable is not empty then loop through the documents contained in it and display the “title” and “tags” field values.

Let’s create the final web interface for creating documents in the index. Create an “add.php” file and enter the following content:

<?php
    require_once "app/init.php";

    if(!empty($_POST)){
        if(isset($_POST["title"]) && isset($_POST["body"]) && isset($_POST["tags"])){
            $title = $_POST["title"];
            $body = $_POST["body"];
            $tags = explode("," , $_POST["tags"]);

            $indexed = $es->index([
                "index" => "blog",
                "title" => $title,
                "body" => [
                    'title' => $title,
                    'body' => $body,
                    'tags' => $tags 
                ]
            ]);

            if($indexed){
                echo '<div class="alert alert-success mt-3 mb-3" role="alert">
                        Document inserted successfully!
                      </div>';
            }
        }
    }
?>
<!doctype html>
<html>
    <head>
        <meta charset="utf-8">
        <title>Create | ElasticSearch Demo</title>
        <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-9ndCyUaIbzAi2FUVXJi0CjmCapSmO7SnpJef0486qhLnuZ2cdeRhO02iuK6FUUVM" crossorigin="anonymous"> 
   </head>
    <body>
 <div class="row mt-3">
   <div class="mx-auto col-10 col-md-8 col-lg-6">
        <!-- We are setting method as GET for form post, so we can see the enered text in url -->
        <form action="<?=$_SERVER["PHP_SELF"]?>" method="POST" autocomplete="off">
            <div class="row mb-3">
    <div class="col">
                 <input type="text" name="title" class="form-control" placeholder="Enter Title" />
  </div>
     </div>
            <div class="row mb-3">
    <div class="col">
                 <textarea name="body" rows="8" class="form-control" placeholder="Enter Body content"></textarea>
             </div>
     </div>
            <div class="row mb-3">
    <div class="col">
                 <input type="text" name="tags" class="form-control" placeholder="Enter comma separated Tags" />
             </div>
     </div>    
    <div class="row mb-3">
    <div class="col">
                 <input type="submit" class="btn btn-primary"  value="Create" />
             </div>
    </div>
 </form>
 </div>
 </div>
 <!-- We are going to skip validation checks -->
 <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js" integrity="sha384-geWF76RCwLtnZ8qwWowPQNguL3RmwHVBC9FhGdlKrxdiJJigb/j/68SIy3Te4Bkz" crossorigin="anonymous"></script>
    </body>
</html>

Let’s analyze the code above. The PHP code before HTML doctype declaration is sub-divided into three parts:
i) Like the search page, we insert the Elasticsearch client in this script.
ii) If the page is submitted with all the form fields, then we are going to perform an insert operation on the “blog” index in Elasticsearch.
iii) The result of the operation is stored in the “indexed” variable. If it is not empty, then we are displaying a success message using the Bootstrap alert component.

You can then go back to the Search screen (index.php) in the browser and try searching for something. Below is a screenshot of a generic search result of character ‘a’:

The Git repo for this article can be found here.

That’s it! Hope you found the article useful.

Happy Coding!

If you found this post helpful, please like, share and follow me. I am a developer, transitioning to DevOps, not a writer — so each article is a big leap outside my comfort zone.

If you need a technical writer or a DevOps engineer, do connect with me on LinkedIn: https://www.linkedin.com/in/mubin-khalife/.

Thank you for reading and for your support!