Créer si n’est déjà fait le dossier networking-workshop
et s’y rendre.
mkdir networking-workshop
cd networking-workshop/
Lancer la commande ansible
avec l’option --version
pour examiner sa configuration.
ansible --version
ansible 2.6.2
config file = /etc/ansible/ansible.cfg
configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python2.7/site-packages/ansible
executable location = /usr/bin/ansible
python version = 2.7.5 (default, Jul 13 2018, 13:06:57) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]
Note: Vous pourriez obtenir des résultats différents.
Cette commande vous indique la version d’Ansible, la version de Python ainsi que les emplacements suivants :
Utilisez la commande cat
pour créer le contenu du fichier de configuration ansible.cfg
.
cat << EOF > ./ansible.cfg
[defaults]
inventory = /root/networking-workshop/lab_inventory/hosts
host_key_checking = False
#private_key_file = /root/.ssh/id_rsa
EOF
Veuillez vérifier la prise en compte du fichier avec la commande ansible --version
:
ansible --version | grep 'config file'
config file = /root/networking-workshop/ansible.cfg
On remarquera les paramètres suivants du fichier ansible.cfg
:
inventory
: l’emplacement de l’inventaire utiliséprivate_key_file
: l’emplacement de la clé publique pour les connexions SSH (ici le paramètre est commenté)Voici l’ordre de précédence du fichier de configuration :
ANSIBLE_CONFIG
(comme variable d’environnement)ansible.cfg
(dans le dossier courant)~/.ansible.cfg
(à la racine du dossier utilisateur en fichier caché)/etc/ansible/ansible.cfg
dans le dossier de configuration du logicielLa portée d’un jeu (“play”) au sein du “playbook” est limité aux groupes d’hôtes définis dans l’inventaire (”inventory”).
La page de documentation sur l’inventaire est certainement à consulter : Introduction à l’inventaire Ansible.
Une inventaire peut être une collection d’hôtes définis dans un fichier plat ou un script dynamique (qui interroge un CMDB par exemple qui génère une liste de périphériques) à utiliser dans “playbook”.
Voici des fournisseurs supportés par un inventaire dynamique : BSD Jails, DigitalOcean, Google Compute Engine, Linode, OpenShift, OpenStack Nova, Ovirt, SpaceWalk, Vagrant (à ne pas confondre avec le “provisioner” dans Vagrant, qui est préféré), Zabbix, …
Dans ce lab, vous allez travailler avec un fichier d’inventaire plat écrit en format INI. Les consignes indiquent que le fichier doit se situer dans le dossier ~/networking-workshop/lab_inventory/
dans fichier nommé hosts
. Il est nécessaire de créer le dossier lab_inventory/
au préalable.
mkdir lab_inventory
Veuillez créer le fichier hosts
dans ce dossier avec la commande cat
:
cat << EOF > ~/networking-workshop/lab_inventory/hosts
[all:vars]
ansible_user=root
ansible_ssh_pass=testtest
ansible_port=22
[routers:children]
cisco
[cisco]
rtr1
rtr2
rtr3
rtr4
[cisco:vars]
ansible_network_os=ios
[dc1]
rtr1
rtr3
[dc2]
rtr2
rtr4
EOF
Dans ce fichier les termes entre les crochets [ ]
définissent un groupe. Par exemple, [dc1]
est un groupe qui contient les hôtes rtr1
et rtr2
. Les groupes peuvent aussi s’emboiter (nested). Le groupe [routers]
est le groupe parent du groupe [cisco]
Les groupes parents sont déclarés en utilisant la directive children
. Utiliser des groupes emboités permet plus de flexibilité dans l’assignation de valeurs plus spécifiques aux variables.
Notes aussi qu’un groupe all existe toujours et reprend tous les groupes et tous les hôtes définis dans l’inventaire.
On peut associer des variables aux groupes ou aux hôtes.
Les variables hôtes sont définies sur la même ligne que l’hôte lui-même. Un exemple pour l’hôte rtr1
:
rtr1 ansible_host=52.90.196.252 ansible_ssh_user=ec2_user ansible_network_os=ios private_ip=10.11.12.13
rtr1
- Le nom que Ansible utilisera. Il peut être résolu par DNS mais ce n’est pas une obligation.ansible_host
- L’adresse IP que Ansible utilisera. Si cette variable n’est pas définie, DNS est utiliséansible_ssh_user
- Le compte utilisateur des connexions SSH. Si non défini, c’est l’utilisateur courant d’Ansible qui est utiliséprivate_ip
- Cette valeur n’est pas réservée par Ansible. Elle peut donc être utilisée comme variable hôte. Cette variable peut être utilisé dans les “playbooks” ou être totalement ignorée.ansible_network_os
- Cette variable est nécessaire pour utiliser le type de connexion network_cli
(plugin) dans les jeux qui sont utilisés dans ce document. (voir ansible-doc -t connection -l
et ansible-doc -t connection network_cli
)Le mode Ad-Hoc permet l’exécution de tâches parallèles.
Dès qu’une instance est disponible, on peut lui parler immédiatement, sans aucune configuration supplémentaire, ici sur une instance Red Hat:
ansible rtr1 -c network_cli -m ping
Un accès à des modules de ressources basés sur des états, ainsi qu’à des commandes raw est disponible. Ces modules sont extrêmement faciles à écrire. Par ailleurs, Ansible est livré avec énormément de modules déjà développé (plus de 750) de telle sorte qu’un bonne partie du travail est déjà réalisée.
Par exemple le code du module “ping” tient en 66 lignes documentation comprise.
ansible rtr1 -c network_cli -m ios_command -a "commands='show version'"
ansible rtr1 -c network_cli -m ios_command -a "commands='show run'"
ansible cisco -c network_cli -m ios_command -a "commands='show version'"
ansible cisco -c network_cli -m ios_command -a "commands='show version'" | grep flash0
ansible cisco -c network_cli -m ios_command -a "commands='show version'" | egrep 'SUCCESS|Software'
ansible cisco -c network_cli -m ios_command -a "commands='show version'" | egrep 'SUCCESS|Version'
ansible cisco -c network_cli -m ios_command -a "commands='show run'" | grep 'username'
ansible cisco -c network_cli -m ios_command -a "commands='show run'" | egrep 'SUCCESS|username'
ansible cisco -c network_cli -m ios_command -a "commands='show ip interface brief'" | egrep 'SUCCESS|Giga'
Note : On ajoutera les paramètres -u root -k
sans configuration de variables ansible_*
dans l’inventaire.