Whenever possible, we should automate the tasks we perform. Automate tasks will make it easy to perform them, allowing us to do all the deployments of an application that we want with fewer possibilities of committing manual errors or it will allow us to have a new machine provisioned exactly as the production machine can be in much less time. In the field of machine provisioning and IT infrastructure management, there are several options, including Chef, Puppet and Ansible.
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.
In the inventory described as a file in INI format, hostnames or their IP addresses are assigned, machine groups can also be made, for example, based on the role (database, web server, …). Once we have the inventory we can start using Ansible, for example, by pinging all the machines or installing a certain package:
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.
To run a playbook we use the ansible-playbook command instead of simply the ansible command.
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:
<script async class=”speakerdeck-embed” data-id=”e02a4f70ee4d01312be742839f79c6f5″ data-ratio=”1.33333333333333″ src=”//speakerdeck.com/assets/embed.js”></script>
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.
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.