Ansible Community: open source ACS tool without agents
This post is also available in: Spanish
Ansible Community: architecture, considerations and installation
For some people when they hear the word Ansible, it may remind them of the science fiction communication device that connects instantaneously, faster than the speed of light. Of course, it has something to do with the software we will present today.
If you are a Local Area Network Administrator or programmer the concepts will be easy to assimilate and since there are also people who work in the field of monitoring in the web console area, a fundamental cornerstone of this corporate sector, and who wish to expand their knowledge, we will start from the most basic to the most advanced, with web links to clarify doubts or expand information. Bear in mind: we must all learn something new every day, so let’s go!
The Ansible Community was published in 2012 under the GNU 3.0 General Public License, which means that we have the four freedoms of free software. Its public source code, open to modifications by us (and it can even assimilate our proposals and modifications) is currently hosted in GitHub (more details in Wikipedia). As we’ll see, it’s a simple command-line software, but powerful. If we are in charge of no more than a dozen machines (even up to a hundred of them) we can easily use this version.
Architecture of the Ansible Community
An Agent (“Software Agent“) is a small program that is installed in a device and then sends data to Pandora FMS Server, and is a working method to collect data. Pandora FMS can also work with remote verifications, without the need of agents: it uses both methods because Flexibility is part of our name and is demonstrated with facts, not just words.
The Server Configuration Administration in Pandora FMS is fully supported by Puppet: with this software tool we will be able to install the necessary Pandora FMS agents for a correct monitoring. Although we use Puppet to install Pandora FMS Software Agents, with Pandora FMS we will also be able to monitor Puppet with a plugin updated to December 2017 through this web link.
Unlike Puppet, Ansible doesn’t need agents to do its job. With Ansible we will be able to control a remote machine (called a node) or several of them in a list (called an inventory) defined in a central local machine (called a controller) by means of scripts, small programs with precise instructions, called modules. To complete the overview, a set of instructions containing hyphens is called a “Playbook”.
- Local Machine: Controller.
- Remote Machine: Node.
- List with the addresses of the Nodes: Inventory.
- Hyphenated file: Module.
- File with dashes and instructions that calls other dashes: Booklet.
At the same time, within the inventory we will be able to group devices assigning a name between straight brackets and then the desired equipment. For the Booklets YAML is used, and for the communications JSON uses over SSH (Pandora FMS uses XML over Tentacle protocol); as we see, this guarantees that the communications are safe between the Controller and its Nodes.
Ansible needs the programming language Python 2.6 or higher and Open SSH to access and communicate securely both in the Controller and in each of its Nodes. These two components are in 99% of the servers in GNU/Linux environment and a critical point for our Controller is to generate an authentication by public key. This is necessary so that Ansible does not use our user password to connect to each one of the nodes, we will only introduce our password when we copy this public key to the respective node. In addition, the user we work with must have administrator or root rights, in other words in the sudoers group.
We will use a virtual machine with Ubuntu 18 (Controller) to do our tests with the IP address 192.168.1.60 and a Node with the address 192.168.1.47.
Installation of Ansible Community
In the terminal window of our future controller:
Once installed we verify which version we have with the command “ansible –version”. Our first job is to create our Inventory by modifying with your favourite text editor the file “/etc/ansible/hosts”, which is in INI format, so we can group other nodes in a section of web servers, for example:
[N47] 192.168.1.47 [ServidoresWeb] example.com 192.168.1.1 mail[1:7:].example.com
When saving the file, Ansible will know the Nodes it controls. Notice that we put an alias “N47” on our Node. Also, as an example, we have a group of mail servers numbered from 1 to 7, take note of the syntax. Ansible can dynamically manage Inventory with another solution from the same Ansible author, Mr. Michael DeHaan: the software is called Cobbler, which has superior functions like DHCP, DNS and IPAM for PXE boot (assumes the same features as phpIPAM), so it is a more complex solution.
The next thing will be to generate a pair of keys, public and private, and then copy the public key to each of the Nodes with our password:
mkdir -p $HOME/.ssh chmod 0700 $HOME/.ssh ssh-keygen -t rsa
We will now copy our public key from the Controller to the Node with “ssh-copy-id -i $HOME/.ssh/id_rsa.pub [email protected]” and then test the connection without a password:
Working with Ansible
We will disconnect from the Node with “exit” and execute our first test (in red the fictitious nodes):
We broke down the command line:
- ansible: the name of the application.
- -m: name of the module to use, “shell” in this case to execute any command we need.
- ‘uptime’: command that returns the time of use of the computer
- all: all the Inventory Nodes, the only one working is “N47”, henceforth it is the one we will use.
As we can see, with Ansible we can do basic monitoring tasks, for example we could ask if a Node needs to be restarted (in Ubuntu there is a service to avoid restarts even if we update kernel): we can send “ansible -m shell -a ‘ls /var/run/reboot-required’ N47”. The command “ls”, which is used to list files and directories, returns an error if it does not get the file (it does not need to be restarted) and this value receives it and interprets Ansible.
If we install Ansible with Pandora FMS we could, in theory, create a remote check to know which Nodes need to be restarted, but we could go even further: with Ansible install “sudo apt-get install needrestart” to then list the processes that need to be restarted with the instruction “needrestart -r l” and send an alert through Pandora FMS Web Console. The detail is that we will need the root password to install any software.
Booklets in Ansible
We will create a text file and name it “my.yml” with the following:
--- - hosts: N47 tasks: - name: installing needrestart apt: name: needrestart state: latest
Then we execute the following command and the software “needrestart” will be installed in the Node that we call “N47”:
ansible-playbook --ask-vault-pass --extra-vars '@password.yml' my.yml N47
Imagen sugerida: colectivo-ansible-6.jpg
Leyenda: “Installing “needrestart” on a Node with Ansible Collective”
Bear in mind that in the figure that we execute the instruction twice, Ansible informs us if it made any change in the Node (idempotent behaviour).
It is also possible, by means of an official script, to condition machines with Microsoft Windows® so that they accept commands with WinRM (here we talk a little bit more about the subject as a whole) from Ansible and in the Controller we must install “python-pip” and then “pywinrm”.
The Ansible Community has a special page called “Ansible Galaxy“, where there are a large number of booklets to be used freely. For example, in the monitoring section they dedicate objects for Grafana ( we talked about this software to monitor Microsoft SQL Server and with Ansible we can automate its installation), there is also a Zabbix agent (which we analysed here), even Kazuki Matsuda has his own booklet to install the Pandora FMS Server!; in short, there are many resources available in that page, plus the official modules.