Check out how our engineers use Ansible and give us a call if you need any help.
There comes a moment in the life of every IT professional where they get a hot potato. A hot potato is by (alternative) definition a situation in which someone is trying to pass on a rough task. Everyone in the situation about to receive the hot potato acts in the same way: they blindly accept the rules and put all their efforts into finding a way to pass the potato on to another unlucky person. Luckily, in in our careers (and in life) much better things happen. One of those things is Ansible, which negates all notions of a hot potato.
Ansible is an open source platform by Red Hat used for automation. It is most often described in three words: simple, powerful and agentless. It’s easy to install and configure. After a simple installation of only a few minutes (e.g. with yuma) you’re ready to profit without any experience needed! The default configuration is probably enough for you to run your first modules. What you need to do is define hosts on which you will run the modules. In order to do that, it’s enough to specify a DNS alias, IP address and a name to mark a host, in which case you will also need to specify its address. You can group the hosts accordingly (by projects, environments; you can also create unions, intersections…). Ansible is also powerful. You can create (automate) a wide range of everyday or less frequent actions. You can use it to control services and configuration, for provisioning, deployment of applications, orchestrating the deployment of applications and services. Finally, it’s also important that Ansible is agentless. The majority of similar tools (e.g. Puppet, Chef) is client-server architecture, so you have to install not only the server, but also agents on all the nodes you control. Ansible doesn’t work in that way, it uses the already-existing transport mechanisms—it uses SSH on Linux/Unix systems and PowerShell Remoting (default, can also use SSH) on Windows Systems.
All that we’ve mentioned leads to the conclusion that Ansible is more than ready for use. So, after the installation, define the hosts (even if you only provide the IP addresses/DNS aliases) and you’re ready for some basic actions. The most generic (not the best) example how to quickly use Ansible is to run a script on multiple hosts. Otherwise you would have to copy the script on your desired environments, set up a ssh key on each node—and if we want to make it even more complicated and say that the script accepts different arguments in different environments, then we have to adjust those arguments—and that is complicated enough, meaning you can already save some time by using Ansible. Ansible actually consists of many modules which can mostly fulfill all your needs. By stacking the modules, you create playbooks that are a collection of instructions to be done on a certain host (or group of hosts). In order to solve the aforementioned case, you will need only the module for copying files (in this example scripts) and another one to run the script. The parameters can be defined when defining hosts, and the variables can be used when running. This simple example will do for the start, just to convince you to start playing with Ansible. By exploring what is necessary for the simpler examples you will start to understand the more complicated modules, and ideas for solving even more complicated problems will be born – because Ansible is everything but a tool for just running scripts, even though you can do just that with it.
In order to broaden your horizons, we will mention a few other examples of how we use Ansible. For instance, it’s a nice tool to do healthchecks. One of the most useful modules is the template module in which you create a template (Jinja2) and then fill it with different values (static variables that you define yourself or some that you discover dynamically on each host). For example, for healthcheck you create a HTML template, gather information from your hosts (e.g. by using the setup module), and fill the template with that information. The result is a HTML document with information you define yourself (e.g. memory status on the server, filesystem capacity, analyzing different system logs, CPU…). You can solve deploying different configuration files in the same way (properties files, XML, different input files for other tools and applications, etc.). We have also created a nice example in which we have automated the migration of WebSphere Application Server by using Ansible. We have created a playbook that completes (almost) the whole migration process – from installing the product and preparing the OS to migrating the resources etc. Such a playbook is not universal for all environments, but it can be expanded and adjusted for other environments and thus gain speed and consistency in executing the process.
So, Ansible is a simple tool that you can install and configure in a brief time, deployed with a bunch of useful modules that cover most of your needs. It’s easy to learn and easy to read. If you give it a chance, it will win you over and convince you that it’s equally useful for both simple and complicated tasks. We should also mention Ansible Tower, a commercial tool which is actually a web GUI dashboard offering some interesting functions, such as controlling access, scheduling tasks, real-time status of task execution, different groups of jobs and teams etc. Red Hat is also the sponsor of the AWX project, which is an open-source version of Ansible Tower. The whole deal is made even better by the enthusiastic community that keeps sharing its solutions. You may not be able to use everything that’s offered, but you can surely get inspired by another’s solution and solve your own problems. All in all, Ansible is a tool that will make your everyday routine (at least) a bit better.
