In this article, I will make a brief introduction of Ansible that is mainly used in servers but we could also use it for our own machine. With Ansible we can:
Automate the provisioning of machines.Manage the configuration of the services of those machines.Perform deployments and orchestrate services.
It should be noted that Ansible does not need to install an agent (unlike Chef or Puppet) in each of the inventory machines that we want to administer, which makes it easy to use, it uses a “push” model in which the machine where executes Ansible sends by ssh the necessary commands to apply instead of each of the machines that obtain the recipes to use from a repository. To work with Ansible we will need to inventory the machines and probably define some variables. It could be in the following way in the case of a machine to develop.
devbox ansible_connection=local ansible_python_interpreter=python2 [devbox] devbox [devbox:vars] path = “projects” subversion_user = “lateef” subversion_password = “***”
$ ansible devbox -i hosts -m ping $ ansible devbox -i hosts -m pacman -a “name=docker state=installed”
The -m parameter indicates the Ansible module that we use and then we indicate the parameters. Ansible has a wide collection of modules that allow us to do many tasks.But instead of using Ansible through commands we can use recipes contained in playbooks described in YAML format in which we define several tasks and we can use the inventory variables. With the following playbook we install several packages in an Arch Linux machine and we do a checkout of two subversion projects, for this we use in the first task the module to manage packages with pacman, there are modules for the package managers of other distributions (apt, yum,…) and in the second task we check out two projects using the subversion version control system module. The modules are idem potent so that once the system is in the desired state the operation is not performed, this means that the same playbook can be executed as many times as desired avoiding collateral effects due to re-execution, the important thing is the state that wants to get.
- hosts: devbox
tasks:
- name: install packages (Arch Linux)
pacman: name={{ item }} state=present
sudo: true
when: ansible_distribution == “Archlinux”
with_items:
- vim
- subversion
- mariadb
- redis
- docker
- ansible
- python2-pip
- python2-virtualenv
- name: checkout projects
environment:
LANG: en_US.UTF-8
LC_CTYPE: en_US.UTF-8
subversion: repo={{ item.url }} dest={{ projects }}/{{ item.path }} username={{ subversion_user }} password={{ subversion_password }}
with_items:
- { url: “http://server.com/svn/repos/project1/trunk", path: “project1” }
- { url: “http://server.com/svn/repos/project2/trunk", path: “project2” }
- name: install packages (Arch Linux)
pacman: name={{ item }} state=present
sudo: true
when: ansible_distribution == “Archlinux”
with_items:
To run a playbook we use the ansible-playbook command instead of simply the ansible command.
$ ansible-playbook ansible/install.yml -i hosts
In playbooks we can use tasks, group of machine, variable, group variables, assign value to variables, use conditionals, loops, facts (facts, information obtained by ansible), notifications and perform actions based on them, apply labels to tasks, make includes, templates (for the configuration files of the services, for example, Apache or mysql), wait for conditions, encrypt files that contain sensitive information and that we can include in a version control tool without compromising the information, use roles that apply all these things according to the function we want a machine to have. The book Ansible Up & Running is a good starting point that explains the basic aspects already in its preview version, of course, the project’s own documentation and evangelization resources are quite good. In the following good and complete presentation are explained with a little more detail more things:
Also, in the following GitHub repository, there are several examples that we can review to see how the files and folders are organized and the conventions in their structure that are used implicitly.
Conclusion
As it has happened to me with the Elasticsearch tool Ansible ‘s documentation has not been written in a didactic way to master it starting from no knowledge, for that reason a book like Ansible: Up and Running is an interesting option to learn.
