1. What is Ansible?
Ansible was meant to be another configuration management tool written in Python, which put emphasis on ease of use. As opposite to other configuration management tools like Puppet or Chef, Ansible doesn’t have any agent installed on the target server. Over time, Ansible becomes much more than just a configuration management tool and now it can be used to create resources across many cloud providers like Amazon Web Services or Microsoft Azure, configure network devices like Cisco ASA and even manage microservices running on Kubernetes or RedHat OpenShift.
2. Why would one use Ansible?
Because Ansible is really easy to use, is under rapid development and has support for almost anything you would want to use either on-prem or in the cloud. Ansible is using something called playbooks which are basically YAML formatted files, which are easy to read and also easy to write (develop). Each task in playbook can have a name, so even people with little to none experience with it have at least some clue what’s going on.
Another advantage of Ansible is that you don’t need to install any agent to your servers. It will connect remotely using SSH or WINRM. This can be also disadvantage in some cases though because Ansible will not check the desired state periodically. If you need to do these periodical checks, you may want to look elsewhere (for example to Puppet). Usually, you will find those tools much more complex though, which means a steeper learning curve.
3. Do I need to know any programming language to use Ansible?
In short: no, you don’t.
Ansible provides many modules, so the only thing you need is to use your OS distribution’s package manager and sometimes Python’s package manager PIP. For the usual scenarios where you use just the modules, you don’t need to know any programming language. You just need to know YAML syntax. It might be helpful to know some programming language for more complex scenarios though. For example, Ansible can template configuration files to the target machines and it is using Python’s Jinja2 syntax. Jinja2 is a subset of Python, so if you know Python, you will be fine with using Jinja2. Also in case that there is not a module that you could use for your particular use-case, you may want to use some kind of programming language to develop your very own module. You can actually use any programming language which can accept JSON and produce JSON. For example modules for Windows are usually written in Windows Powershell scripting language. You can even use BASH in Linux if you want to. It is really up to you. But overall, you will be good with simple scripting experience which will allow you to use Jinja2 for more complex scenarios.
4. Does Ansible have any graphical UI?
Ansible itself is just a command-line tool that can either run playbooks you developed or ad-hoc commands to a set of hosts. There is no UI for Ansible itself.
However, you can buy a license from RedHat for product Ansible Tower (or use its upstream version called AWX – hosted on Github), which is a Web UI for Ansible. It is a web application also written in Python using Django framework and it will give you fine role-based access control using teams and organizations (you can point it to an existing Active Directory or other LDAP solution, or even use Single sign-on using SAML) as well as dynamic inventory plugins for you infrastructure in public and private cloud. You can even chain your playbooks into workflows and import those playbooks conditionally based on results from the first playbook. Ansible Tower will also give you the option to create surveys for the Tower users so that they can just fill it and it will pass the values as variables to the underlying playbooks. Big benefit of Ansible Tower is its REST API, so the workflow can be triggered by a CI/CD tool. It has much more features which you may want to check here: https://www.ansible.com/products/tower
5. How is it with the documentation?
Ansible and even Ansible tower have really great documentation. Documentation is generated from the module’s code. Every Ansible module has to have a DOCUMENTATION block which provides all the information necessary to use that module. You, as a user, can then use command-line tool to get the documentation to a specific module, or search the Ansible’s web documentation which is really nicely structured and also provides documentation to modules based on Ansible version (because there are usually some changes between Ansible releases – remember I told you it’s under rapid development, right?). You can even find a lot of information about inventories, plugins and even Jinja2 features on the Documentation web-site as well as guidelines on how to develop your very own Ansible module.
6. How do you target your systems when Ansible doesn’t have an agent?
As I said earlier, Ansible is using SSH and WinRM (among others) for connection to the remote systems. It also uses something called inventories. There are two types of inventory – static and dynamic.
Static inventory is something you will probably use at the beginning because it is really easy to use. These inventories are just plaintext INI files where you add hostnames or IP addresses of the systems you want to configure and possibly set some variables for each group or for a single host.
Dynamic inventory, on the other hand, is usually some kind of script usually written in python (don’t worry, you don’t have to write it on your own even though you can), which is usually used with public clouds like AWS or Azure (there are dynamic inventories for VMWare and OpenStack too). If you use such inventory, it will fetch all your instances from using cloud-provider’s API and group them based on tags. You may imagine how convenient this can be. You don’t need to know how many instances for a specific workload you have, it will always add all of them.
7. Who would you recommend Ansible to?
I would recommend to anyone who is either new to automation and configuration management and even experienced professionals who want to do more than just configuration management. On the other hand, if a company is successfully using something else like Chef or Puppet, I would stay with those tools or possibly combine Ansible with them. I know some companies which are using both types of tools (with and without agents) and it works for them. Ansible is being used due to its ease of use, while for example Puppet is used to make sure that servers are in the specified state.
Overall, it really depends on your use-case, but I believe Ansible fits almost everywhere.