Sunday 25 October 2020

Building CI/CD pipeline in AWS infrastructure



Hello fellow engineers, in this blog we are going to create a basic CI/CD pipeline using Jenkins and Ansible to deploy a WAR application on the Apache Tomcat servers and most importantly we are utilizing AWS cloud platform for setting up this infrastructure.
For testing purpose, we have provisioned 2 EC2 instances in AWS for creating the Jenkins and Ansible servers. Follow the below links for setting up these servers:

We have incorporated the best DevOps practices in building this project. But firstly let's understand what is DevOps and why do we need it.

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization's ability to deliver applications and services at high velocity. It helps in evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes.
This methodology is best suited for the development environment requiring very frequent releases.


Purpose of CI/CD Pipeline

We are delivering a product which is a web application and we have to incorporate lot of changes to the application very frequently like new feature rollouts, UI changes, bugs fixes, etc.
In this scenario, the development happens continuously and updated application code needs to be deployed and tested very frequently.

For overcoming the manual effort for each deployment and we created a uniform process that is continuously integrated with the code repository and continuously deploying the build automatically.
This is the Continuous Integration/Continuous Deployment pipeline OR CI/CD pipeline in short.




Technologies Used:


Source code management: Git
Build management: Maven
Continuous integration: Jenkins
Artifact management: S3 Bucket, Docker Hub
Configuration management: Ansible
Containerization: Docker containers
Cloud: AWS

Understanding the pipeline in steps


  1. Developer commits his/her code into the GIT repository, in which webhook is configured to send the message to trigger the Jenkins job on every successful push in develop branch.
  2. This will trigger the Jenkins job to pull the repository and build the web application package with the help of Maven tool.
  3. This package or the WAR artifact created needs to be deployed on to the fleet of Tomcat servers but before deploying it should be stored in some artifactory to maintain the backup and keep versioning of the product. We have configured the Jenkins to store this WAR artifact on a S3 bucket.
  4. Jenkins sends this file to Ansible server via scp command. As this Tomcat application needs to be deployed on many QA servers, it would be easier and faster way of deploying to a fleet of servers.
  5. Ansible server runs the playbook that builds the customized Docker image of the Tomcat application and uploads it to the Docker Hub private repository.
  6. Ansible runs the another playbook to build the containers with the latest docker image on the QA environment.
  7. Once the deployment is done and the testers have done their Sanity test on the web application. The application gets approval to be deployed on the staging servers and finally on the Production servers.

I hope with this blog I am able to make you guys understand why implementing CI/CD pipeline is important in delivering a final product. Please reach out to me via comments or email if have any questions.

Friday 2 October 2020

AEM as a Service

Adobe Experience Manager is an enterprise Content Management System and Digital asset management. It is a Software as a Service (SaaS) which is a suite of online cloud-based services provided by Adobe for Digital Asset Management.

In this blog, we will learn about the AEM installation process on Linux server and setting up the AEM service to avoid manual effort on starting AEM process every time the server is rebooted.

Once the AEM package is downloaded on your local server. It basically contains AEM Quickstart Jar (AEM_6.x_Quickstart.jar) and a License file which should be placed in the same installation folder on the instance running in Author or Publisher mode.

Installation process


  • Create a installation directory named "aem" under opt directory.
    mkdir -p /opt/aem/

  • Copy the downloaded AEM package into the aem folder:
cp cq-quickstart-6.5.0.jar /opt/aem/cq-quickstart-6.5.0.jar
cp license.properties /opt/aem/license.properties
  • Unpack the JAR file
java -jar /opt/aem/cq-quickstart-6.5.0.jar -unpack
  • Unpacking of the jar files creates a folder named ‘crx-quickstart’ which contains the script to start/stop the AEM instance.
  • Edit start script, if you want to run the aem instance in publisher mode.
CQ_PORT=4503
CQ_RUNMODE='publish'
  • Start the aem process with this script
bash /opt/aem/crx-quickstart/bin/start

Implementation of AEM as a Service


1. Create the following file:

vi /etc/systemd/system/aem.service

[Unit]
Description=AEM Author/Publisher Service

[Service]
Type=simple
ExecStart=/opt/aem/crx-quickstart/bin/start
ExecStop=/opt/aem/crx-quickstart/bin/stop
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

2. Provide the permissions:
chmod 755 aem.service

3. Reload all systemd service files: 
systemctl daemon-reload

4. Check that it is working by starting the service with following commands
systemctl start aem.service
systemctl status aem.service

5. Enable the service to start on boot:
systemctl enable aem.service
Created symlink from /etc/systemd/system/multi-user.target.wants/aem.service to /etc/systemd/system/aem.service.

6. Reboot the server and check the status of AEM service once it boots up again. It should be up and running.
systemctl status aem.service