Automate Git Deployment using Ansible in AWS …!!!!!

We are using Ansible to manage application deployments to EC2 with Auto Scaling in AWS, while pushing code to gitlab. GitLab offers a continuous integration service. If you add a .gitlab-ci.yml file to the root directory of your repository, and configure your GitLab project to use a Runner, then each commit or push, triggers your CI pipeline.

Prerequisites

• Ubuntu 16.04
• Installed with gitlab & Ansible 2.4(Python-boto & boto3)

Setting up Gitlab Environment

Adding .gitlab-ci.yml file

Once server is ready with prerequisites, We are going to create .gitlab-ci.yml file in root directory of repository. The file tells the GitLab runner what to do. By default the pipeline will run three stages,

• build
• test
• deploy

We don’t need to use all three stages, if needed we can use.

before_script:
   - apt-get update
   - apt-get install awscli
   - aws s3 cp /tmp/test.sh s3://your-s3-bucket/
deploy:
  script:
    - echo "HELLO"
build:
  script:
    - echo "WELCOME"

Once created .giltlab-ci.yml file need to push gitlab repository. Following commands for pushing your files to gitlab.

git add .gitlab-ci.yml
git commit -m “Add .gitlab-ci.yml”
git push origin master

Configuring a Runner

In gitlab, Runner run the jobs which you have define in .gitlab-ci.yml file. Gitlab and Runners communicate through an API, So the runner machine having internet access. For more information about runner please read this Runner document.

Runner Installation:

For runner installation get repository from GitLab’s official site.

Adding repository,

# For Debian/Ubuntu/Mint
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

# For RHEL/CentOS/Fedora
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

Install the latest version of GitLab Runner by using following command.

# For Debian/Ubuntu/Mint
sudo apt-get install gitlab-runner

# For RHEL/CentOS/Fedora
sudo yum install gitlab-runner

Registering Runners:

Go to official document for registering runner.

WOW...!!! We have successfully done our gitlab setup.

Setting up Ansible Environment

Already we have installed Ansible 2.4 in same server so, we can use that server for creating ansible playbooks & roles.

Step 1: Adding variables in group vars.

---
#group_vars/all.yml
aws_access_key: XXXXXXXXXXXXXXXXXX 
aws_secret_key: XXXXXXXXXXXXXXXXXX
region: us-east-1
zone: us-east-1e
## Creating AMI of deployment Instance:
instance_id: XXXXXXXXXXXX
## Launch-Configuration:
keypair: example.pem
instance_type: t2.micro
security_groups: XXXXXXXXX
volumes:
  - device_name: /dev/sda1
    device_type: gp2
    volume_size: 20
    delete_on_termination: true
## Autoscaling Configuration:
current_asg_name: <Current Autoscaling Group Name>
new_asg_name: <New Autoscaling Group Name>
## Current Load-Balancer:
load_balancers: <Load Balancer Name>

Step 2: Creating roles for deployment

Created role as a “role-build-env” this role will be build your environment in AWS console by launching autoscaling group with deployment.

Role “role-build-env” having two directories, each one doing some jobs while running the ansible playbook.

• tasks
• library

You can create jobs(tasks) under tasks directory.

Find main.yml file. It’s doing some jobs like, Creating Launch Configuration from deployed instance and launch new Autoscaling Group under your LoadBalancer.

Step 3: Terminate old Configurations.

Now, We can delete old Autoscaling group, Launch Configuration & AMI.

Find clear.yml file. It will delete your old configurations from AWS console.

Note: That whilst you can request increased limits per region for your account, in our experience sometimes these requests are refused on the grounds that AWS would prefer for you to clean up your cruft instead of relying on perpetual service limit increases.

Leaving unused resources lying around is not very good practise in any case, and we certainly don’t want to be paying for those resources unnecessarily. To fix this, we’ll make use of the ec2_ami_find / ec2_ami modules to delete the older AMIs, and a quick and dirty (but effective) hand rolled module to discard old launch configurations.

So, You can add python module files under library directory.

We have Done for creating roles …!!!!!

Step 4: Create ansible playbook

Now, We are creating playbook for running from anisble. In playbook define only roles no other tasks.

---
# /etc/ansible/playbook-build.yml
- name: "Setting Ansible Hosts"
  hosts: localhost
  connection: local
  roles:
    - { role: role-build-env, tags: role-build-env }

Successfully we have done all setup !!!!!

Now, we can run our playbook from ansible root directory. It will launch Autoscaling Group & Delete old configurations. Following command to use run your playbook.

ansible-playbook playbook-build.yml

Now, we have a completed playbook to handle deployments of our application to EC2 Auto Scaling.