documentation technique - … · la liste des tâches qui seront exécutées au travers des rôles...

15
Documentation technique pour le postinst celya Documentation Technique Ansible - Celya Berthomier Gillian 1

Upload: vuongngoc

Post on 13-Sep-2018

213 views

Category:

Documents


0 download

TRANSCRIPT

Documentation technique pour le postinst celya

Documentation TechniqueAnsible - Celya

Berthomier Gillian 1

Documentation technique pour le postinst celya

Installation Ansible :

Écrit en Python, Ansible est un outil Open Source qui permet l’automatisation detâches. Grâce à lui, vous pourrez gérer vos configurations de serveurs plus facilement,et de façon automatique grâce à l’exécution de tâches sur des groupes d’hôtes.

Ansible à mis à notre disposition une documentation très détaillée, via laquelle j’ai faisl’installation de ce dernier.

Documentation installation : http://docs.ansible.com/ansible/intro_installation.html

Astuces d’utilisation : http://docs.ansible.com/ansible/playbooks_best_practices.html

Présentation des VM’s utilisées :

Afin de mettre en place le serveur Ansible, j’ai dû travailler sur machines virtuelles.Des tests ont donc été effectués sur ces machines :

Ansible-Srv1 : Il s’agit du serveur maître tournant sur Debian – Jessie contrôlant etexécutant les tâches à effectuer sur les serveurs nodes.Adresse IP : 192.168.222.90Utilisateur : RootMdp : P@ssw0rd

Ansible-Node1 : Il s’agit d’un des serveurs clients tournant sur Debian – Jessie quireçois les tâches du serveur maître.Adresse IP : 192.168.222.92Utilisateur : RootMdp : P@ssw0rd

Ansible-Node2 : Il s’agit d’un des serveurs clients tournant sur Centos – Core 7 quireçois les tâches du serveur maître.Adresse IP : 192.168.222.94Utilisateur : RootMdp : P@ssw0rd

La connexion et la configuration de ces serveurs ce fait par ssh via un terminal sur lamachine physique.

Berthomier Gillian 2

Documentation technique pour le postinst celya

Présentation Serveur Maître (Ansible-Srv1) :

Voici à quoi ressemble l’environnement de travail du serveur Ansible ayant le contrôle unefois installé :

• ansible.cfg : Fichier de configuration de Ansible

• AnsibleNode.yml : Playbook de lancement des Rôles (cf page 9)

• hosts : Fichier contenant tous les hôtes et groupes d’hôtes (cf page 4)

• Playbooks : Répertoire contenant tous les playbooks créer (cf page 5)

• Repository : Répertoire contenant tous les Repository que l’on souhaite installer

• Rôles : Répertoire contenant tous les Rôles créer (cf page 7)

• Templates : Répertoire contenant tous les Templates créer

Berthomier Gillian 3

Documentation technique pour le postinst celya

Hosts (Inventaire) : /etc/ansible/hosts

Il s’agit donc du fichier ( aussi appelé Inventory) contenant tous les hôtes ainsi que leursnoms de groupes utilisés pour cibler les serveurs sur lesquels on souhaite opérer :

Ce fichier utilise la syntaxe suivante :

• [ Nom de Groupe ]

Hostname-node

On peut également rajouter [ Nom de Groupe de Groupe : children ] afin de créer desgroupes de groupes, ce qui peut s’avérer être très utile dans le ciblage des hôtes à gérer.

• [ Nom de Groupe de Groupe: children ]

Nom de Groupe

Documentation inventaire : http://docs.ansible.com/ansible/intro_inventory.html

Berthomier Gillian 4

Documentation technique pour le postinst celya

Playbooks : /etc/ansible/playbooks/

Un playbook est un scénario décrivant les actions qui seront réalisées par lesserveurs, c’est à dire les paquets à installer, les fichiers à créer, les fichiers à éditer etles services à démarrer ou arrêter, etc …

Ces playbooks sont écrits en YAML, et sont donc facilement lisibles.

Documentation Playbook : http://docs.ansible.com/ansible/playbooks.html

Il s’agit ici d’un exemple de playbook qui va copier des clés ssh dans le fichier« known_hosts » de toutes les nodes.

La syntaxe est très importante pour les playbooks puisqu’un seul espace de trop peutfaire planter l’exécution.

Documentation syntaxe YAML : http://docs.ansible.com/ansible/YAMLSyntax.html

Le modèle de base fonctionnant pour un simple playbook est le suivant :

- name : Le nom du playbook

hosts : Hostname du node ou Nom du groupe à gérer

tasks :

- module : (L’utilisation des modules sont expliquer dans la doc Ansible)

paramètre du module : Valeur

paramètre du module : Valeur

Berthomier Gillian 5

Documentation technique pour le postinst celya

Documentation Modules : http://docs.ansible.com/ansible/modules.html

Afin de lancer un playbook on utilise la commande suivante :

ansible-playbook /chemin/vers/playbook.yaml

Une variable peut également être placée à la place du hostname avec la formesuivante :

hosts : « {{ HostTarget }} »

Ce qui peut nous être utile si l’on souhaite cibler les nodes au moment de l’exécution dela commande avec la syntaxe :

ansible-playbook /chemin/vers/playbook.yaml -e « HostTarget=hostname »

Ici l’option -e ( --extra-vars ) comme son nom l’indique va nous servir afin de déclarer desvaleurs de variables au moment du lancement du playbook.

Pendant l’exécution d’un playbook nous obtenons dans le terminal un résumé détaillédes opérations en cours ainsi que leurs statues :

ok ⇒ rien à faire (en général car déjà fait)

changed ⇒ la tâche à été appliquée

unreachable ⇒ l’hôte cible n’est pas joignable

failed ⇒ la tâche n’a pu être appliquée ( un détail de l’erreur est affiché)

skipping la condition «⇒ when » n’est pas respectée donc la tâche est passée

Berthomier Gillian 6

Documentation technique pour le postinst celya

Rôles : /etc/ansible/roles/

Il s’avère parfois plus utile de regrouper les tâches listées dans un playbook dans desrôles bien précis.

Documentation Rôles : http://docs.ansible.com/ansible/playbooks_roles.html

La création d’un rôle s’effectue de la même manière qu’un playbook en utilisant lesmêmes balises, tout en créant un dossier pour chaque rôles avec l’arborescencesuivante :

• files : Contient les fichiers transférable sur les hôtes sur lesquels le rôle est

déployés.

• handlers : fait référence aux actions annexes (redémarrage de service, par

exemple).

• meta : Contient les fichiers relatif aux dépendances de rôles.

• templates : Contient tous les fichiers qui utilisent des variables pour remplacer des

informations lors de la création dans ce répertoire.

• tasks : fait référence aux tâches qui seront exécutées sur les hôtes.

• vars : Les variables pour les rôles peuvent être spécifiés dans ce répertoire et

utilisés dans vos fichiers de configuration.

Une fois les fichiers de rôles créés, il devrait ressembler à ce qui suit :

Et le dossier Rôles à :

Berthomier Gillian 7

Documentation technique pour le postinst celya

La liste des tâches qui seront exécutées au travers des rôles est contenue dans un fichierécrit en yaml ( donc playbook ) : >> /etc/ansible/roles/roleschoisie/task/main.yml

Quant-il s’agit de décrire les tâches d’un rôle il suffit de les lister dans le fichier enrespectant la syntaxe suivante :

- name : (1ère tâche Pas obligatoire mais ajoute de la lisibilitée au moment de l’exécution)

module :

paramètre du module : Valeur

paramètre du module : Valeur

with_items : (Si l’on souhaite faire une boucle, cf doc boucles)

- { item : valeur }

- { item2 : valeur }

when : (Équivalent d’un if, cf doc condition)

- « condition »

- « condition2 »

- name : (2ème tâche)

module :

paramètre du module : Valeur

paramètre du module : Valeur

etc ….

Documentation boucles : http://docs.ansible.com/ansible/playbooks_loops.html

Documentation conditions : http://docs.ansible.com/ansible/playbooks_conditionals.html

Berthomier Gillian 8

Documentation technique pour le postinst celya

Puis il nous faudra faire appel à ce rôle dans notre fichier de lancement :

>> /etc/ansible/AnsibleNode.yaml

On a ici remplacé les valeurs des hôtes cibles et des rôles à exécutés par des variablesafin de pouvoir les déclarer dans la commande de lancement.

Ce qui lance l’installation du rôle sur les Nodes clients :

On retrouve ainsi nos rôles installés dans les deux nodes dans le répertoire >> /skel

Berthomier Gillian 9

Documentation technique pour le postinst celya

Adaptation Postinst à Ansible :

Le postinst est un script rédigé en bash qui permet de rendre opérationnel un serveuraprès l’exécution de ce dernier.

Le bash étant un langage assez lourd, j’ai donc dû adapter le travail du postinst avec lesrôles ansibles suivants :

Dans lesquels ce trouvent des tâches détaillées dans le /tasks/main.yml de chaque rôles.

Asterisk/etc/ansible/roles/asterisk/tasks/main.yml

Berthomier Gillian 10

Documentation technique pour le postinst celya

Ce task vas aller copier tous les fichiers contenus dans

/etc/ansible/roles/asterisk/Debian et Centos/files/Debian et Centos/etc et opt

du serveur maître pour les coller dans /skel/Debian et Centos/etc et opt/celya desserveurs nodes cibles.

Le premier « include » va ici rajouter des lignes de configurations dans le fichierfail2ban/jail.conf, et le deuxième va faire la même chose mais dans le fichier deconfiguration de Asterisk.

Firewall/etc/ansible/roles/firewall/tasks/main.yml

Ce task va réaliser la même copie que pour le rôle Asterisk mais dans son propredossier Firewall.

Les deux « include » ici font appellent à des playbooks qui vont respectivement installertous les paquets nécessaires au bon fonctionnement de notre firewall sur les serveursainsi que configurer les fichiers de confs de fail2ban.

Berthomier Gillian 11

Documentation technique pour le postinst celya

Freepbx/etc/ansible/roles/freepbx/tasks/main.yml

Toujours la même copie pour la première partie du playbook.

Le premier « include » va faire appel à un playbook qui démarre et arrête des serviceslistés dans ses tâches et le deuxième force Asterisk à démarrer en background(nécessaire pour le démarrage par amportal).

VoIP/etc/ansible/roles/voip/tasks/main.yml

Berthomier Gillian 12

Documentation technique pour le postinst celya

Toujours la même copie pour la première partie du playbook.

Le premier et le second « include » respectivement exécutés sur distribution Debian etCentos, vont ajouter les clés données dans leurs listes de tâches, dans le fichier~/.ssh/known_hosts de leurs cibles afin de pouvoir se connecter en ssh.

Le troisième et dernier playbook vont quant à eux créer les « aliases » pour le mail surleurs cibles.

Web/etc/ansible/roles/web/tasks/main.yml

Berthomier Gillian 13

Documentation technique pour le postinst celya

Toujours la même copie pour la première partie du playbook.

Le premier playbook à être appelé va installer tous les paquets nécessaires sur lesnodes Debian et le deuxième sur les nodes Centos.

Quant au dernier, lui, va démarrer et arrêter des services listés dans ses tâches.

Wordpress/etc/ansible/roles/wordpress/tasks/main.yml

L’ « include » va ici installer les paquets nécessaires à l’utilisation de wordpress sur le serveur web.

Toujours la même copie pour la première partie du playbook.

Berthomier Gillian 14

Documentation technique pour le postinst celya

Xivo/etc/ansible/roles/tasks/main.yml

Toujours la même copie pour cette première partie de playbook.

Berthomier Gillian 15