I recently started automating my build using Ansible for a new project. I heard great things about Ansible from colleagues who helped me get started and decided to take notes along the way. Here are a few items from the notes that you should consider before getting started.

#1: The plays have been created. You only have to put these together

Chances are most of the roles you want to create have been implemented before. Take a look here to find existing roles and use them in your playbook. If you absolutely have to write your own roles, use these as references to guide you. Moreover, there are many existing open-source playbooks for common automated builds that can be found with a quick google search. Here is an example of a common Django build playbook that I was able to reference. Remember to make your playbook, roles, etc open-source if you write your own custom automation.

#2: Know the difference between the Shell and Command modules

Shell executes a task on the remote node using a shell which means it has access to basic shell operations and variable like $HOME, $PATH, &&, etc. Command module executes the specified command with arguments on all selected nodes and is not processed through the shell therefore cannot access shell operations and variables. Here is a example that highlights how one shell task can be used in place of two command tasks.

``` #Example Command 1 - name: Run a script in /usr/bin/ command: /usr/bin/test_script.sh

Example Command 2

name: Remove test_script.sh in /usr/bin/
command: rm /usr/bin/test_script.sh

Example Shell

name: Run a script in /usr/bin/ and remove test_script.sh
shell: test_script.sh ; rm test_script.sh
chdir: /usr/bin/


 

</div><span class="s1">**#3: Avoid using the Shell and Command modules**</span>

<span class="s1">Ansible has a huge index of core modules that get installed by default. These modules make it easier to achieve simple tasks without the need to write shell scripts or commands. The list of modules can be found [here](http://docs.ansible.com/list_of_all_modules.html). Modules like pip, git, s3 (AWS), copy, yum and service make it easier to write and read Ansible playbooks. </span>

Here is a simple example that migrates a database managed my Django.

<div>```
#Run Django database migration using django-manage module
- name: Run migration
  django_manage:
    app_path=/path/to/manage.py/
    command=migrate
    virtualenv=testenv
  sudo: no

#Run Django database migration using shell
- name: Run migration
  shell: "source /testenv/bin/activate && cd /path/to/manage.py/ && python manage.py migrate"
  sudo: no

As you can see, the built in django_manage module makes it tremendously easier and simpler to run a django specific command. On the other hand, the shell module is very complex in terms of readability and comprehension.

#4: KISS And DRY

I am a big proponent of the KISS (Keep it Simple Stupid!) and DRY (Don’t Repeat Yourself) software development principles. Split up you roles into individual standalone entities that can be used elsewhere. Moreover, this makes it easier for others to follow your playbook and customize as necessary. For example, create two distinct roles for database installation and database setup so that others can use the database install role but not the database specific setup role. A good rule of thumb is to split up a role when it becomes hard to maintain and read.

Conclusion

Ansible is a very simple and direct automation tool with a large contributing user community. They have focused on building a tool that relies heavily on contributors to make modules, roles and playbooks in an open environment. I highly recommend trying out Ansible as your next automation tool and become a part of the growing community.