Explorer l'environnement de lab

Étape 1 : Dossier de travail

Créer si n’est déjà fait le dossier networking-workshop et s’y rendre.

mkdir networking-workshop
cd networking-workshop/

Étape 2 : Vérification de la configuration

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 emplacement :

  • du fichier de configuration utilisé
  • du chemin de recherche des modules
  • des modules
  • de l’exécutable ansible

Étape 3 : Fichier de configuration

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 logiciel

Étape 4 : Inventaire

La 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éfini 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

Étape 5 : Examen de l’inventaire

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 private_ip=172.16.165.205 ansible_network_os=ios
  • 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)

Mode Ad Hoc

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 all -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 : -u root -k sans configuration de variables