Difference between revisions of "Ansible"
(Clarify Installation section (experimental python3 support, ssh-key infra))
m (→Inventory: Style)
|Line 25:||Line 25:|
One can assign specific attributes to every node in the file. Check [http://docs.ansible.com/ansible/latest/intro_inventory.html the official document] for
One can assign specific attributes to every node in the file. Check [http://docs.ansible.com/ansible/latest/intro_inventory.html the official document] for details.
=== Ping ===
=== Ping ===
Revision as of 16:57, 4 August 2017
- Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates.
On the control machine (server, master), Install the package.
On the managed machines (clients, slaves), where you want to automate deployment or configuration tasks, installand . (Or you can use instead of , but Python 3 support in Ansible is currently experimental.)
Note that a functioning SSH key setup makes the use of Ansible much more frictionless (but this is not required).
According to the default settings in
/etc/ansible/ansible.cfg, one can define its infrastructure in
/etc/ansible/hosts. For instance, the following inventory defines a tiny cluster with three nodes:
[control] 192.168.12.1 [managed] 192.168.12.2 192.168.12.3
One can assign specific attributes to every node in the file. Check the official document for details.
You may check if all the nodes listed in the inventory is alive by
$ ansible all -m ping
Playbook serves as a powerful tool to deploy and configure the whole infrastructure. Check the official document for more details. Here is an extremely simple use case, only for demonstration purpose, where the administrator of above inventory want to perform a full system upgrade on all nodes. First, create a playbook file, in YAML format:
- hosts: control managed tasks: - name: full system upgrade script: /usr/bin/pacman -Syu
Then, run the playbook script:
# ansible-playbook syu.yml
Tips and tricks
Telling Ansible where Python is located
Ansible requires Python on the target machine, Python 3 is supported as a preview  but might not work for all modules. By default Ansible assumes it can find a
/usr/bin/python on your remote system that is a 2.X or 3.X version of Python, specifically 2.4 or higher.
If some of your modules requires Python 2 you need to tell Ansible where to find Python 2 by setting the
ansible_python_interpreter variable in your Ansible inventory file. This can be done succinctly by using host groups in the inventory:
[archlinux] server1 server2 [debian] server3 [archlinux:vars] ansible_python_interpreter=/usr/bin/python2