Difference between revisions of "Ansible"

From ArchWiki
Jump to navigation Jump to search
(→‎See also: add relevant references)
(→‎Basic usage: create new section, provide some simple example to demonstrate the usage)
Line 11: Line 11:
 
On the managed machines (clients, slaves), where you want to automate deployment or configuration tasks, install {{Pkg|python2}} (or the experimental alternative {{Pkg|python}}) and {{Pkg|openssh}}.   
 
On the managed machines (clients, slaves), where you want to automate deployment or configuration tasks, install {{Pkg|python2}} (or the experimental alternative {{Pkg|python}}) and {{Pkg|openssh}}.   
 
Note that [[SSH_keys#Copying_the_public_key_to_the_remote_server|some ssh key settings]] are needed for the ssh connections to function properly.
 
Note that [[SSH_keys#Copying_the_public_key_to_the_remote_server|some ssh key settings]] are needed for the ssh connections to function properly.
 +
 +
== Basic usage ==
 +
=== Inventory ===
 +
According to the default settings in {{ic|/etc/ansible/ansible.cfg}}, one can define its infrastructure in {{ic|/etc/ansible/hosts}}.  For instance, the following inventory defines a tiny cluster with three nodes:
 +
{{hc|/etc/ansible/hosts|
 +
[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 [http://docs.ansible.com/ansible/latest/intro_inventory.html the official document] for the details.
 +
 +
=== Ping ===
 +
You may check if all the nodes listed in the inventory is alive by
 +
 +
$ ansible all -m ping
 +
 +
=== Playbook ===
 +
Playbook serves as a powerful tool to deploy and configure the whole infrastructure.  Check [http://docs.ansible.com/ansible/latest/playbooks.html 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:
 +
{{hc|syu.yml|
 +
- 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 ==
 
== Tips and tricks ==

Revision as of 15:20, 2 August 2017

From docs.ansible.com:

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.

Installation

On the control machine (server, master), Install the ansible package.

On the managed machines (clients, slaves), where you want to automate deployment or configuration tasks, install python2 (or the experimental alternative python) and openssh. Note that some ssh key settings are needed for the ssh connections to function properly.

Basic usage

Inventory

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:

/etc/ansible/hosts
[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 the details.

Ping

You may check if all the nodes listed in the inventory is alive by

$ ansible all -m ping

Playbook

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:

syu.yml
- 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 [1] 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:

Inventory file
[archlinux]
server1
server2

[debian]
server3

[archlinux:vars]
ansible_python_interpreter=/usr/bin/python2

More information this is available in [2], [3] and [4].

See also