Project 2

Table of Contents

1. About The Project
2. Built With
3. Getting Started and Assumptions
4. Prerequisites
5. Installation
6. Usage
7. Roadmap
8. Contributing
9. License
10. Acknowledgments

About The Project

Key Concepts:

• This project uses a CI/CD pipeline which extensively focuses on code quality.
• This project leverages the power of ec2(s) and EKS to support the long-term viability of the deployment.
• This project has a blue/green deployment strategy which focuses on a clean, clear, and consistent user experience without hindering development.

This project listens to a webhook from github, sent on push(es) to an Amazon Web Services (AWS) Elastic Compute Cloud (ec2) instance. This t2.medium ec2 instance runs Jenkins which controls a Continuous Integration / Continuous Deployment (CI/CD) pipeline. The t2.medium was necessary for the overall health of the Jenkins instance, whereas the cheaper t2.micros can often hang on pipeline operations and become unreachable. This Jenkins pipeline runs a series of built-in tests, including Sonarqube code linting, code smells, vulnerability scans, and bug analyses. Jenkins then builds a docker image of the project and pushes it to Docker Hub. This pipeline then creates a deployment, ingress, and service to a remote Elastic Kubernetes Service (EKS) cluster through a single YAML file. To recreate this, your own EKS instance's credentials need to be properly provisioned for a service account in AWS Identity and Access Management (IAM) roles & users (eks* and cloudaccess* are recommended for creation + deployment configurations like ours). Finally, the code is deployed in a blue/green fashion, meaning that by changing the deployment but not the service and ingress we can change the outward appearance of our app while having very different internal functions.

We have submitted this project as part of our Revature training for group project 2.

(back to top)

Built With

• 
• 
• 
• 
• 

(back to top)

Getting Started and Assumptions

Be ready to spend a few dollars on this project (we spent around $20 between the four of us). This requires paid services from AWS. There are ways to build this without them, but we opted for this path to be better prepared for our future working environments.

In the following Prerequisites and Installation sections we have the following assumptions:

• The developer understands how to run commands in Amazon Linux 2 (more generally red hat/CentOS)
• The developer (you) can get an ec2 up and running without aid. If not there is an excellent tutorial at: https://www.jenkins.io/doc/tutorials/tutorial-for-installing-jenkins-on-AWS/
• The developer has a functional understanding of kubernetes loadbalancer/nodeport/ingress

Prerequisites

Once your ec2 instance (t2.medium) is up and running, this sequence of commands will install jenkins and java-openjdk11:

sudo yum update –y
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.key
sudo yum upgrade
sudo amazon-linux-extras install java-openjdk11 -y
sudo yum install jenkins -y
sudo systemctl enable jenkins
sudo systemctl start jenkins

Next we will install git:

sudo yum install git -y

Now we install docker, and give jenkins permission to use it:

sudo yum install docker -y
sudo usermod -a -G docker jenkins

Installation

The user account permissions used were maximal to get the target setup. Please don't use these in production, the authors intended use case is exclusively for minimum viable product (MVP) setup only.

1. Create a new user in your AWS IAM dashboard, and select a JSON permissions policy. The policy below contains the maximum permissions necessary for this task. Use them at your own risk (please secure your instances).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "eks_administrator",
            "Effect": "Allow",
            "Action": [
                "eks:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "cloudformation_administrator",
            "Effect": "Allow",
            "Action": [
                "cloudformation:*"
            ],
            "Resource": "*"
        }
    ]
}

2. Set this repository up with a webhook of your jenkins url with the addition of '/github-webhook/'. If you've never done it before we found a good tutorial here: https://hevodata.com/learn/jenkins-github-webhook/

3. On your AWS IAM dashboard navigate to the user you set up with the custom JSON access policy in step 1 above. Then, in that user's section entitled 'security credentials', click 'create access key'. This will generate a key specific to this user for this use case. Do not lose it, and keep it somewhere safe.

4. SSH back into your jenkins instance and in the command line, type 'aws configure'. In the following fields, fill in the user account we just created access keys for above in step 3. This will give your instance permissions to access and remote into your soon-to-exist EKS cluster.

5. Finally, create your EKS cluster using the following commands from the command line of the ec2 instance that jenkins is running on.

eksctl create cluster --name ERMS-project2 --version 1.22 --region us-east-2 --nodegroup-name linux-nodes --node-type t2.micro --nodes 1
aws eks --region us-east-2 update-kubeconfig --name ERMS-project2
kubectl get all

6. Now whenever anyone makes a push to the GitHub repository where your webhook is, it will be entered into the CI/CD pipeline, examined, and deployed on your local EKS cluster.

(back to top)

Usage

This pipeline is a fault-tolerant implementation of blue/green deployment off of a CI/CD pipeline. With a thorough understanding of the Jenkinsfile, any reasonably experienced developer can fork this repo to examine and deploy their own code to an EKS cluster after sonarqube evaluates it.

(back to top)

Roadmap

• Add Changelog
• Add back to top links
• Add Additional Templates w/ Examples
• Add "components" document to easily copy & paste sections of the readme

See the open issues for a full list of proposed features (and known issues).

(back to top)

Contributing

Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.

If you have a suggestion that would make this better, please fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!

1. Fork the Project
2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
3. Commit your Changes (git commit -m 'Add some AmazingFeature')
4. Push to the Branch (git push origin feature/AmazingFeature)
5. Open a Pull Request

(back to top)

License

Distributed under the MIT License. See LICENSE.txt for more information.

(back to top)

Acknowledgments

• Mehrab Rahman
• Runner up: dot.nick

(back to top)