Configuration management with Ansible
One of the best-known solutions is certainly Puppet. Ansible, which has been part of the Red Hat Group since 2015, is somewhat younger and so far less prominent. Ansible is an open source automation tool written in Python. A wide variety of automation options are already included in Ansible as so-called modules, but can also be written by the user themselves in any programming language. The prerequisite is that you can process or deliver input and output in JSON format.
Instructions are written by the user as ad-hoc tasks, or combined and reusable as playbooks in YAML style.
[root@ansible playbook]# ansible-playbook example_playbook.yml -i inventory/inventory.ini PLAY [example_webhost] ********************************************************** TASK [Gathering facts] ************************************************************ ok: [192 .168.121.31] TASK [Installiere httpd Paket] ************************************ changed: [192 .168.121.31] => (item=[u'epel-release', u'httpd']) TASK [Kopiere httpd config- Datei auf den Zielrechner] ********************************* changed: [192 .168.121.31] TASK [Starten des httpd Service] **************************** changed: [192 .168.121.31] PLAY RECAP ************************************* [192 .168.121.31] : ok=4 changed=3 unreachable=0 failed=0
Variables, templates and programming logic can be defined and used via Jiinja syntax. If a playbook is to be executed on a client, Ansible sets up an SSH connection and moves the required modules, usually Python scripts, there. These are then executed locally; communication between the module on the client side and the master node occurs via JSON statements. After the playbook has been successfully processed, the local files on the client side are deleted again. From this functional principle it is clear that Ansible uses the push principle, i.e. instructions are sent from a master node to any number of clients. In contrast, Puppet uses the pull principle, in which clients pull instructions from a dedicated master.
The advantages and disadvantages are obvious: Ansible does not require any additional software or complicated configuration. The only requirement on the master page, in addition to Ansible, is Python version 2.6 or 2.7, as well as the playbook that is to be executed. The only limitation currently is Windows, which, like Puppet, cannot serve as MasterOS. On the client side, SSH access from the master and Python version 2.6 or higher are required. The disadvantage lies in the automation of playbook executions: Ansible currently only offers the option of automatically executing tasks and playbooks via the paid tool Tower, if you don’t want to use crontabs. In addition, Tower can also manage individual Ansible users and user groups, as well as SSH keys and passwords.
Red Hat has now also made Ansible Tower available free of charge. Up to this point you could use one of the open source alternatives, e.g. Semaphores help. In addition, orcharhino or Foreman can of course also be used to orchestrate clients via Ansible. The Ansible community is very active and constantly growing, so new features and a rapidly growing range of functions are guaranteed.
All in all, Ansible already offers a great way to automate IT infrastructures with relatively simple means, which is already fully competitive with Puppet . The combination of Ansible and Puppet probably offers the absolute best solution at the moment. It definitely remains exciting, not least due to Red Hat’s announcement that Ansible will be deeply integrated into its new products. What this means for Foreman, Satellite and other products remains to be seen. zeigen.
You might also like
Der ATIX-Crew besteht aus Leuten, die in unterschiedlichen Bereichen tätig sind: Consulting, Development/Engineering, Support, Vertrieb und Marketing.
