DEV Community: Abhishek Vaidya

In this post, we’ll build an automation that updates JIRA ticket statuses instantly based on Slack emoji reactions—saving time and making life easier!

Abhishek Vaidya — Thu, 06 Feb 2025 13:53:32 +0000

Automate JIRA Ticket Updates with Slack Reactions

Abhishek Vaidya ・ Feb 2

Automate JIRA Ticket Updates with Slack Reactions

Abhishek Vaidya — Sun, 02 Feb 2025 07:36:51 +0000

Tired of Manually Updating JIRA Tickets? Let Slack Reactions Do It for You! 🚀

On-call engineers already have enough on their plate—manually updating JIRA ticket statuses shouldn’t be one of them. It’s a tedious, time-consuming task that’s easy to forget, leading to delays and miscommunication.

But what if a simple Slack reaction could handle it for you? In this post, we’ll build an automation that updates JIRA ticket statuses instantly based on Slack emoji reactions—saving time and making life easier!

Fun Fact: Even AI can't generate this solution. Yet! 😎

Architecture

The workflow begins when an end-user creates a JIRA ticket in Slack using the /jira create command or directly from the console. Automation is triggered based on the emoji reaction to the Slack message, which seamlessly updates the JIRA ticket status.

Prerequisites:

Need a paid Slack subscription.
An AWS User/Role with the below permissions:
- AWSLambda_FullAccess
- IAMFullAccess
Jira Cloud integration with Slack

GitHub

You can find the resources in abhivaidya07/slack-reaction-bot

Steps:

Create a Slack Application

On the Your Apps page, select Create New App.
Select From scratch.
Enter your App Name.
Select the Workspace where you'll be developing your app. You'll be able to distribute your app to other workspaces later if you choose.
Click Create App.

Adding Permissions to Slack application

Go to the Slack application created in the above steps.
From the left navigation panel, select OAuth & Permissions, scroll down to Scopes.
Under Bot Token Scopes, select Add an OAuth Scope.
To allow your app to react based on slack reactions, add below scopes:
- channels:history
- reactions:read
- users:read
- users:read.email
Scroll up to OAuth Tokens and click on Install to Workspace button.
You'll now be sent through the Slack OAuth flow. Select Allow on the following screen.
Copy and Save the Bot User OAuth Token (starting with xoxb), we will need it in the next steps !!

Enable Workflow steps

From the left navigation panel, select Org Level Apps.
Click Enable Org-Readiness and enable it.
Go to Workflow steps in left navigation panel.
Click on Update settings
We'll enable Event Subscriptions in further steps.

Create Lambda Function (Using AWS Console)

Open the Functions page of the Lambda console.
Choose Create function.
Select Author from scratch.
In the Basic information panel, enter the Function name.
For Runtime, choose Python 3.9.
Leave architecture set to x86_64.
Expand Additional Configurations and then select Enable function URL.
For Auth type, choose NONE.
Choose Create function.

Create/Attach Lambda Layers

Install python version 3.9
Run the below command to install jira package on the local filesystem.
```
pip3 install jira -t jira/python
```
Repeat the same command to install requests package on the local filesystem.
```
pip3 install requests -t requests/python
```

Create .zip files for both the install packages

cd jira && zip -r ../jira_layer.zip python
cd ..
cd requests && zip -r ../requests_layer.zip python
cd ..

Create AWS lambda layers using the below commands:

aws lambda publish-layer-version --layer-name jira-layer --zip-file fileb://jira_layer.zip --compatible-runtimes python3.9 --query 'LayerVersionArn' --output text
aws lambda publish-layer-version --layer-name requests-layer --zip-file fileb://requests_layer.zip --compatible-runtimes python3.9 --query 'LayerVersionArn' --output text

Copy LayerVersionArn from the above commands
Run the below command to attach layers to the lambda function.
```
aws lambda update-function-configuration \
--function-name <FUNCTION_NAME> \
--layers <JIRA_LAYER_VERSION_ARN> <REQUEST_LAYER_VERSION_ARN>
```
Replace the following:
- FUNCTION_NAME: Name of the lambda function created in above steps.
- JIRA_LAYER_VERSION_ARN: ARN of the JIRA layer.
- REQUEST_LAYER_VERSION_ARN: ARN of the request layer.

Upload Code to Lambda Function (Using AWS Console)

Clone this GitHub repository.

Zip the repository content using the below commands.

cd slack-reaction-bot
zip -r slack_reaction_function.zip . -x ".git/*"

Open the Functions page of the Lambda console.
Choose the function created above and choose the Code tab.
Under Code source, choose Upload from.
Choose .zip file, and then choose Upload.
Select the zip file we created in earlier steps.
Uploaded code structure should look like this:
Click Deploy.

Set Environment Variables for Lambda Function (Using AWS Console)

Open the Functions page of the Lambda console.
Choose the function created above and choose the Configuration tab.
Select Environment variables, choose Edit.
Click Add environment variable and add below variables:
- Key: JIRA_SERVER, Value: Your JIRA server URL for eg. https://org-name.atlassian.net
- Key: JIRA_USERNAME, Value: Your JIRA username.
- Key: JIRA_API_TOKEN, Value: API Token for above user. Refer to this link for token creation.
- Key: SLACK_APP_TOKEN, Value: Slack token created in Adding Permissions to Slack application step
- Key: DONE_TRANSITION_ID, Value: Transition ID of done status. for example: 41
- Key: IN_PROGRESS_TRANSITION_ID, Value: Transition ID of in-progress status. for example: 31
  - Steps to get transition ID:
    - Go to JIRA board > Project settings > Workflows > Edit workflow
Click Save.

Enable Event Subscriptions

On the Your Apps page, select application created in above steps.
From the left navigation panel, select Event Subscriptions and toggle Enable Events to ON.
Paste the Function URL of our lambda function into Request URL
Request URL should be Verified.
(Temporary) Within Subscribe to bot events, select Add Bot User Event, then search for reaction_added.
Click Save Changes.

Note: We will remove the reaction_added event to ensure we do not receive two events when a slack reaction is added.

Create Workflow Steps

From the left navigation panel, select Workflow Steps.
Click Update settings from the highlighted text.
Go to Event Subscriptions, remove the reaction_added event added in the earlier step and click Save Changes.
Go back to Workflow Steps and click Add Step.
Provide the Basic Information as shown in the below image:
Click Input Parameters and fill in the details as follows:
- Input 1:
  - Input type: String
  - Make required: Enabled
  - Parameter ID: message_ts
  - Title: Message Timestamp
- Input 2:
  - Input type: Channel
  - Make required: Enabled
  - Parameter ID: channel_id
  - Title: Message Channel ID
- Input 3:
  - Input type: User
  - Make required: Enabled
  - Parameter ID: user_id
  - Title: Message User ID
Click Create.
Add one more step, while providing Basic Information as shown in the below image:
Click Input Parameters and fill in the details as follows:
- Input 1:
  - Input type: String
  - Make Required: Enabled
  - Parameter ID: message_ts
  - Title: Message Timestamp
- Input 2:
  - Input type: Channel
  - Make Required: Enabled
  - Parameter ID: channel_id
  - Title: Message Channel ID
- Input 3:
  - Input type: User
  - Make Required: Enabled
  - Parameter ID: user_id
  - Title: Message User ID
Click Create.
Go to Install App from the left navigation bar and then click Reinstall

Now we are ready to create automation based on Slack reactions !!

Add Automation on Slack Channel

Open the slack channel on which you want to add automation.
Click on the name of the channel and go to the Integration tab.
Under Apps, click Add apps and select the slack application created in earlier steps.
Go back to the Integration tab, then click on Add Automation.
Now click on + New Workflow and select Build Workflow.
For event choose When an emoji reaction is used.
Choose an emoji of your choice and channel on which you want automation to work. for eg. I'm using emoji as ✅ and channel as #devops
Click Continue.
For Steps, scroll down to the last and select Custom.
Select the Slack application, which we created in earlier steps.
Select Update Status Done, as this automation is to update the JIRA ticket status as done.
Provide inputs for Message Timestamp, Channel ID, and User ID as specified in the image below:
Click Save, then click on Finish Up
Provide Name and Description to the automation.
(Optional) You can also specify who can manage, copy, or find this workflow by clicking on Show more permissions.
Click Publish.
Repeat the same steps to create automation for updating the JIRA ticket status as In Progress.

Is it working?

Create a JIRA ticket on Slack using /jira create command.
Add a 👀 reaction to the ticket.
This will trigger our In-Progress automation and perform the following steps:
- Update the ticket status to In Progress.
- Update the Assignee to the user who reacted.
- If the ticket status is already In Progress, then the Lambda function specifies it in CloudWatch logs.
Now add a ✅ reaction to the ticket.
This will trigger our Done automation and perform the following steps:
- Update the ticket status to Done.
- Add a comment on the ticket.
- If the ticket status is already Done, then the Lambda function specifies it in CloudWatch logs.

Conclusion

To sum it up, we’ve created a seamless automation that updates JIRA ticket statuses directly through Slack reactions. With the power of a Slack app, AWS Lambda, and Slack workflow steps, this solution not only saves time but also ensures smoother workflows. Plus, it’s highly customizable—you can extend it to handle more reactions, add comments to JIRA tickets based on Slack threads, and much more. The possibilities are endless for optimizing your team's productivity!

Alternatively, you can explore JIRA Service Management, which costs approximately $140 for 4 agents (on-call engineers). However, with this solution, you only pay for the AWS Lambda executions, making it a more cost-effective approach. 🚀

Questions?

If you have any questions, I’ll be happy to read them in the comments.
You can connect with me on LinkedIn.

Thank you for reading :)

Kubernetes on CRI-O (CentOS)

Abhishek Vaidya — Mon, 14 Dec 2020 17:45:00 +0000

Docker is now deprecated in Kubernetes

Yes, it is true.

Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community.

So, Now Kubernetes is encouraging to use different Container Runtime Interface instead of docker.

Why CRI-O ?

CRI-O is an implementation of the Kubernetes CRI (Container Runtime Interface) to enable using OCI (Open Container Initiative) compatible runtimes.

It is a lightweight alternative to using Docker, Moby or rkt as the runtime for Kubernetes.

CRI-O is a CRI runtime mainly developed by Red Hat folks. In fact, this runtime is used in Red Hat OpenShift now. Yes, they do not depend on Docker anymore.

Interestingly, RHEL 7 does not officially support Docker either. Instead, they provide Podman, Buildah and CRI-O for container environment.

Let's get started

Here we are deploying a 3 node cluster:

one master node
two worker nodes

Installing CRI-O (should be done on all nodes)

Create a enviroment variable for OS.

$ export OS=CentOS_7

Note: If you are using CentOS 8 then give variable name as CentOS_8

Create another environment variable for VERSION of crio.

$ export VERSION=1.17

Note: If you are using CentOS 8 then you can also install crio version 1.18

Configure REPO for cri-o.

$ sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo

$ sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo

Install cri-o.

$ sudo yum install cri-o -y

Start and enable the cri-o service.

$ sudo systemctl start cri-o

If any issue with starting cri-o, refer troubleshooting section !!

$ sudo systemctl enable cri-o

Troubleshooting

Not able to start cri-o service:

$ sudo systemctl status cri-o

crio.service - Container Runtime Interface for OCI (CRI-O)
   Loaded: loaded (/usr/lib/systemd/system/crio.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Fri 2020-12-11 05:42:49 EST; 29s ago
     Docs: https://github.com/cri-o/cri-o
  Process: 1259 ExecStart=/usr/bin/crio $CRIO_CONFIG_OPTIONS $CRIO_RUNTIME_OPTIONS $CRIO_STORAGE_OPTIONS $CRIO_NETWORK_OPTIONS $CRIO_METRICS_OPTIONS (code=exited, status=1/FAILURE)
 Main PID: 1259 (code=exited, status=1/FAILURE)

Dec 11 05:42:49 ip-172-31-89-94.ec2.internal systemd[1]: Starting Container Runtime Interface for OCI (CRI-O)...
Dec 11 05:42:49 ip-172-31-89-94.ec2.internal crio[1259]: time="2020-12-11 05:42:49.409813214-05:00" level=fatal msg="Validating root config: failed to get store to set defaults: kernel does not support overlay fs: overlay: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior. Reformat the filesystem with ftype=1 to enable d_type support. Running without d_type is not supported.: driver not supported"
Dec 11 05:42:49 ip-172-31-89-94.ec2.internal systemd[1]: crio.service: main process exited, code=exited, status=1/FAILURE
Dec 11 05:42:49 ip-172-31-89-94.ec2.internal systemd[1]: Failed to start Container Runtime Interface for OCI (CRI-O).
Dec 11 05:42:49 ip-172-31-89-94.ec2.internal systemd[1]: Unit crio.service entered failed state.
Dec 11 05:42:49 ip-172-31-89-94.ec2.internal systemd[1]: crio.service failed.

Root Cause:

The default container storage i.e. /var/lib/containers/storage is mounted with ftype=0, so d_type is disabled ( d_type enables mapping of filename to its inode ). For overlay, ftype=1 is a requirement !!

$ sudo xfs_info /var/lib/containers/storage | grep ftype

naming   =version 2              bsize=4096   ascii-ci=0 ftype=0

Solution:

Create a Logical Volume (LV).

$ sudo fdisk <disk_name>

$ sudo partprobe <disk_name>

$ sudo vgcreate vgname <partition>

$ sudo lvcreate -l 100%FREE -n lvname vgname

$ sudo lvs

LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
root   centos -wi-ao----  <6.67g
swap   centos -wi-ao---- 820.00m
lvname vgname -wi-a-----  <5.00g

Format LV with XFS filesystem

$ sudo mkfs.xfs /dev/mapper/vgname-lvname

meta-data=/dev/mapper/vgname-lvname isize=512    agcount=4, agsize=327424 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=1309696, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Now ftype is set to 1.
Mount LV on /var/lib/containers/storage permanently.

$ sudo cat /etc/fstab | grep /var/lib/containers/storage

/dev/mapper/vgname-lvname /var/lib/containers/storage xfs defaults 0 0

$ sudo mount -a

$ sudo df -hT | grep /var/lib/containers/storage

/dev/mapper/vgname-lvname xfs       5.0G   33M  5.0G   1% /var/lib/containers/storage

Change runroot path and un-hash both runroot & root in /etc/crio/crio.conf.

$ sudo cat /etc/crio/crio.conf | grep /var/lib/containers/storage

root = "/var/lib/containers/storage"
runroot = "/var/lib/containers/storage"

Then start and enable the cri-o service.

$ sudo systemctl start cri-o

$ sudo systemctl enable cri-o

Install and configure prerequisites for Kubernetes: (should be done on all nodes)

Load overlay module.

$ sudo modprobe overlay

Load br_netfilter module.

$ sudo modprobe br_netfilter

This module is enabled so that iptables, ip6tables and arptables can filter bridged IPv4/IPv6/ARP packets and makes the firewall transparent.

Set up required sysctl params, these persist across reboots.

$ cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

Apply sysctl params without reboot.

$ sudo sysctl --system

Disabling firewall.

$ sudo systemctl stop firewalld && sudo systemctl disable firewalld

Set SELinux in permissive mode (effectively disabling it).

$ sudo setenforce 0

$ sudo sed -i -e s/SELINUX=enforcing/SELINUX=permissive/g /etc/sysconfig/selinux

Switching off swap.

$ sudo swapoff -a

Also disable the swap in /etc/fstab (comment swap entry).

$ sudo cat /etc/fstab | grep swap

#/dev/mapper/centos-swap                                swap                    swap    defaults        0 0

Change cgroup_manager of crio in /etc/crio/crio.conf.

$ sudo cat /etc/crio/crio.conf | grep cgroup_manager

cgroup_manager = "cgroupfs"

Configure Kubernetes repo.

$ sudo cat /etc/yum.repos.d/kube.repo

[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

Deploying Kubernetes Cluster

COMMANDS ON MASTER

Install kubeadm package.

$ sudo yum install kubeadm -y

Start and enable kubelet.

$ sudo systemctl start kubelet && sudo systemctl enable kubelet

Now initialize the Kubernetes control-plane and master.

$ sudo kubeadm init

Note: If giving error of iptables does not exist, just load br_netfilter module again and run the command.

Output

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.46.157:6443 --token 7xlnp0.9uv4z0qr4wvzhtqn \
    --discovery-token-ca-cert-hash sha256:4a1a412d2e682556df0bf10dc380c744a98eb99e8c927fa58eb025d5ff7dc694

To make kubectl work for your non-root user, run these commands, which are also part of the kubeadm init output:

$ mkdir -p $HOME/.kube

$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

These commands store your Kubernetes configuration file in home directory.
Make a record of the kubeadm join command that kubeadm init outputs. You need this command to join nodes to your cluster.
We need to install CNI plugin. So that pods can communicate with each other.
There are different CNI plugins for different purpose. Here we are using Weave Net CNI plugin.

$ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

Weave Net creates a virtual network that connects containers across multiple hosts and enables their automatic discovery.

Once the CNI plugin has been installed, you can confirm that it is working by checking that the CoreDNS Pod is up and running.

$ kubectl get pods -n kube-system

Our master is ready !!

$ kubectl get nodes

NAME     STATUS   ROLES                  AGE   VERSION
master   Ready    control-plane,master   14m   v1.20.0

Now we need to add worker nodes to the cluster.

COMMANDS ON WORKER NODES

Install kubeadm package.

$ sudo yum install kubeadm -y

Start and enable kubelet.

$ sudo systemctl start kubelet && sudo systemctl enable kubelet

Run the kubeadm join command. (command in the output of kubeadm init)

$ sudo kubeadm join 192.168.46.157:6443 --token 7xlnp0.9uv4z0qr4wvzhtqn \
    --discovery-token-ca-cert-hash sha256:4a1a412d2e682556df0bf10dc380c744a98eb99e8c927fa58eb025d5ff7dc694

Output

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

Now our worker nodes have joined the cluster !!

COMMAND ON MASTER

Check whether nodes are ready.

$ kubectl get nodes

NAME      STATUS   ROLES                  AGE     VERSION
master    Ready    control-plane,master   15m     v1.20.0
worker1   Ready    <none>                 4m44s   v1.20.0
worker2   Ready    <none>                 4m18s   v1.20.0

HURRAH !! Kubernetes cluster is ready

THANK YOU!!

Connecting WordPress to Amazon RDS using Terraform

Abhishek Vaidya — Thu, 19 Nov 2020 09:15:43 +0000

Introduction

In this blog using terraform, we will launch WordPress application in an Amazon EC2 instance and connect it to Amazon RDS (database instance).

What is WordPress ?

WordPress is a free, open-source website creation platform which requires access to database to store information. Therefore we need database to make WordPress accessible.

What is Amazon RDS ?

Amazon Relational Database Service (Amazon RDS) makes it easy to set up, operate, and scale a relational database in the cloud.
Here we will use Amazon RDS as database for WordPress application.

What is Terraform ?

Terraform is used for writing infrastructure as Code to provision and manage any cloud, infrastructure, or service. In this blog we will provision different services provided by Amazon Web Services (AWS).

Getting Started !!

Configure AWS CLI, because terraform uses these credentials to authenticate with AWS.

$ aws configure

Give correct access_key and secret_key.

Note: If you are using aws student account give session token, by pasting it in .aws/credentials file

Install Terraform (Refer this link)
Clone Terraform file from this GitHub Repository

$ git clone https://github.com/abhivaidya07/wordpress_rds
$ cd wordpress_rds

Repository contains two files:
- script.sh: Contains commands which install WordPress application.
- main.tf: Terraform file which creates EC2 instance with WordPress installed in it (using script.sh) and also creates RDS database instance.
RDS database instance is of db.t2.micro type and contains username and password as root and redhat123 respectively.

You can change it by updating username and password parameter under aws_db_instance resource.

Initialize Terraform to install required providers.

$ terraform init

Run the terraform file.

$ terraform apply

RDS instance takes sometime to get created...

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Creates EC2 instance with WordPress application installed in it and also creates RDS instance with mysql 5.7 engine, wordpress database and 20 GiB storage.
EC2 instance name - wordpress
RDS instance name - sample
Browse to public ip of EC2 instance i.e. wordpress

Give Database Name - wordpress (Created in RDS instance)
Give Username - root (If you have not changed)
Give Password - redhat123 (If you have not changed)
Give Database Host - Endpoint of RDS instance

Note: To access Endpoint refer this link

Click on Submit button.
Then click Run the installation button.
Fill the required details and click on Install WordPress button.

Hurray !! Your WordPress application is working.

Now your WordPress application is using Amazon RDS as a backend !!

GCP Automation using Ansible

Abhishek Vaidya — Tue, 17 Nov 2020 18:06:20 +0000

Introduction

Ansible provides different Google Cloud Platform modules for automating google cloud platform. In this blog we will be creating a Google Compute Engine Instance and deploy Apache Server on it using Ansible.

Prerequisites

Create Project on Google Cloud Platform.
Create a Serviceaccount with editor access. (Refer Creating-service-account)

GitHub

You can find the resources in abhivaidya07/ansible_gcloud

Getting Started !!

Install python version > 3.0

$ sudo yum install python3-pip

The GCP modules require both the requests and the google-auth libraries to be installed.

$ sudo pip3 install requests google-auth

Install Ansible

$ sudo pip3 install ansible

Download .JSON credentials file of created service account.
Edit instance_name in vars/main.yml, by default it is centos-7.
Edit machine_type in vars/main.yml, by default it is e2-micro.
Edit zone in vars/main.yml, by default it is us-central1-a.
Edit source_image in vars/main.yml, by default it is CENTOS-7.
Give project id, .JSON file_path in vars/main.yml file.
Run the Playbook

$ ansible-playbook gce.yml

Your Google Compute Engine Instance is now created, with Apache Server installed in it.
Browse to instance public ip address, and you will see HELLO WORLD !! is getting displayed.