Our experience with Ansible as a deployment & configuration management tool

In the month of Jan 2019, business was talking about reducing downtime in the deployment process for our customers. 

Motive behind the requirement was very clear - 

1. Reduce manual intervention in the deployment process.

2. Reduce the deployment time as much as possible. It should be less or almost zero. 

This was a herculean task as deployment process was (and is still) a different ball game altogether. It is a semi-automated deployment process where certain quality checks are needed after certain stages.

A whole application is a workflow-based application which has a lot of dependency on different monolith applications. Also a lot of applications need to deployed at different locations/hosts based on user-role based requirements. Deployment window period that you receive from customers is so less that there is hardly any room for error. So your deployment has to be precise and error-free. 

During our initial evaluation, it was clear that project was demanding deployment automation along with configuration management.

We evaluated three different tools - Ansible, Chef and Puppet on following parameters.

1. Number of questions asked on stack overflow.

2. Number of commits, contributors, stars, forks etc. on Github.

3. Number of questions asked on its own community forum.

4. Conclusions derived from our PoCs. 

Based on our evaluation, we chose Ansible as it was a clear winner in the above criteria. Following two points helped us to conclude on Ansible. 

1. Ansible provides agent less architecture.

2. Ansible Tower can be used for future enhancements. 

We delivered the project within 2 quarters. Project execution offered a lot of leanings.

Some leanings stood out from all others which are worth sharing with others.  

1. Ansible Vault:

- This project helped us to place all the credentials at one place instead of maintaining it at different places like confluence, wiki, share point or source code repositories etc.

- But as security is of almost priority, there was a need to keep these credentials in secured way.

- To keep our credentials secured, we used Ansible Vault. 

- Ansible Vault is a feature that allows you to keep sensitive data such as passwords in encrypted files. These vault files can be then be placed in source control. Ansible Vault offers two types of encryption - File level encryption or variable level encryption.

- We used file level encryption as we are encrypting all the files containing all sensitive data. 

2. Roles:

- Ansible Role was perfect fit for our solution.

- We defined a separate ‘Role’ for each component.

- This approach provided the flexibility to extend current deployment process. If you need to deploy any new component, you just need to create a new ‘Role’.

- Role offered the primary mechanism for breaking a complex playbook into multiple smaller files.

- In practical terms, a role is a directory structure containing all the files, variables, handlers and tasks needed to automate a workflow. 

3. Playbook:

- We defined separate playbook for each operation.

- Each operation was defined in such a way that it can be reused in the roles wherever needed. - Examples of operations are as follows: - Back-up the existing artifacts - Replace artifacts with new artifacts - Start/stop service 

- Database backups

- Playbook is an ordered list of Tasks and task is an ‘unit of action’. 

4. Inventory:

- In Ansible, you can work against multiple managed nodes or “hosts” in your infrastructure at the same time using a list or group of lists known as inventory.

- Once inventory is defined, you can use “Patterns” to select the hosts or groups you want Ansible to run against.

- Default location for inventory file is - /etc/ansible/hosts.

- But you can override with a different inventory file by specifying in command line using <PATH> option. - We opted for overriding default inventory location. 

- We are maintaining a separate inventory file for each different environment.

- This helped us to maintain all hosts/ip’s required by different applications at a single place.  

Future scope: Project created high business value by reducing deployment time from 5 hours to less than 1.5 hours. Though there are some challenges due to semi-automated way of deployment, we would like to reduce the deployment time as low as possible. There are some future enhancements which are ‘In Progress’ status right now. 

1. Ansible Tower:

- Ansible Tower provides feature rich dashboard UI. This dashboard displays everything that is going on in your Ansible environment.

- It provides real-time job updates. 

- It also maintains the old jobs history which is very important to track what went wrong.

2. Docker: - We would like to dockerize our solution.  

- All the artifacts will be bundled together in a docker file and will be shipped to the client site.  

Conclusion:

With our experience, we can definitely say that Ansible is suitable where is deployment automation is needed along with configuration management.