0% ont trouvé ce document utile (0 vote)

384 vues94 pages

Automatisation DevOps avec Linux

Ce document décrit les concepts et outils de l'automatisation DevOps tels que Puppet et Ansible. Il contient des sections sur la configuration avec Puppet, son installation et utilisation, ainsi que sur Ansible avec son vocabulaire, installation, utilisation de modules, playbooks et gestion de rôles.

Transféré par

elies_jabri7874

Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.

Formats disponibles

Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

0% ont trouvé ce document utile (0 vote)

384 vues94 pages

Automatisation DevOps avec Linux

Transféré par

elies_jabri7874

Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.

Formats disponibles

Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

FORMATUX - Support de cours

GNU/Linux
Automatisation - DevOPS
1.2, 23-08-2017
Table des matières
Préface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Crédits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Licence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Gestion des versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Généralités devops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Le vocabulaire DEVOPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Les outils devops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Gestion de configurations avec Puppet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

La gestion de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Puppet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Vocabulaire Puppet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Hello world . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Les modules Puppet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Depuis internet :. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Sans connexion internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Commandes utiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Cas concrets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

La création d’un noeud (node) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Gestion des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Gestion des dossiers et des fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Modification de valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Exécution d’une commande externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Le vocabulaire ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Installation sur le serveur de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Utilisation en ligne de commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Tester avec le module ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Authentification par clef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Création d’une clef SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Test d’authentification par clef privée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Exemple de connexion à une instance Cloud Amazon ECS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Utilisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Les modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Exemple d’installation logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Les playbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Exemple de playbook Apache et MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Exemple de préparation d’un noeud MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

La gestion des boucles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Les rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

La commande ansible-galaxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Ansible Niveau 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Les variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Externaliser les variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Afficher une variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Enregistrer le retour d’une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

La gestion des boucles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Les conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

La gestion des fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Le module ini_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Le module lineinfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Le module copy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Le module fetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Le module template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Le module get_url . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Les handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Les rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

La commande ansible-galaxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Les tâches asynchrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Connexion à une instance Cloud Amazon ECS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Ansistrano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Module 1 : Prise en main de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Exercice 1.1 : Déploiement de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Module 2 : Déployer le serveur Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Exercice 2.1 : Utiliser le rôle [Link] pour configurer le serveur. . . . . . . . . . . . . . . . . 42

Module 3 : Déployer le logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Exercice 3.1 : Installer le rôle ansistrano-deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Exercice 3.2 : Utiliser le rôle ansistrano-deploy pour déployer le logiciel . . . . . . . . . . . . . . . . . . . . 44

Exercice 3.3 : Visualiser le résultat dans un navigateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Exercice 3.4 : Vérification sur le serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Module 4 : Ansistrano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Exercice 4.1 : Limiter le nombre de releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Exercice 4.2 : Utiliser des shared_paths et shared_files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Exercice 4.3 : Utiliser un sous répertoire du dépôt pour le déploiement. . . . . . . . . . . . . . . . . . . . . 50

Module 5 : La gestion des branches ou des tags git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Exercice 5.1 : Déployer une branche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Exercice 5.2 : Déployer un tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Module 6 : Actions entre les étapes de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Exercice 6.1 : Envoyer un mail en début de MEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Exercice 6.2 : Redémarrer apache en fin de MEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Ordonnanceur centralisé Rundeck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Utiliser RunDeck. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Créer un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Créer une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Serveur d’Intégration Continue Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

En mode standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

En tant que servlet tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Installer Nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Configuration de Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

La sécurité et la gestion des utilisateurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Ajouter une tâche d’automatisation simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Asciidoc : Docs as Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Le format asciidoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Compiler sa documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Une proposition d’environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Références . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Terraform : Infrastructure as Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

La HCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Les providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Les actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Dépendances des ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Les provisionners. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Les variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

TD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

FORMATUX - Support de cours GNU/Linux

Préface
GNU/Linux est un système d’exploitation libre fonctionnant sur la base d’un noyau Linux,
également appelé kernel Linux.

Linux est une implémentation libre du système UNIX et respecte les spécifications POSIX.

GNU/Linux est généralement distribué dans un ensemble cohérent de logiciels, assemblés autour
du noyau Linux et prêt à être installé. Cet ensemble porte le nom de “Distribution”.

• La plus ancienne des distributions est la distribution Slackware.

• Les plus connues et utilisées sont les distributions Debian, RedHat et Arch, et servent de base
pour d’autres distributions comme Ubuntu, CentOS, Fedora, Mageia ou Manjaro.

Chaque distribution présente des particularités et peut être développée pour répondre à des
besoins très précis :

• services d’infrastructure ;

• pare-feu ;

• serveur multimédia ;

• serveur de stockage ;

• etc.

La distribution présentée dans ces pages est la CentOS, qui est le pendant gratuit de la distribution
RedHat. La distribution CentOS est particulièrement adaptée pour un usage sur des serveurs
d’entreprises.

Crédits
Ce support de cours a été rédigé par les formateurs :

• Patrick Finet ;

• Antoine Le Morvan ;

• Xavier Sauvignon ;

• Nicolas Kovacs.

Licence
Formatux propose des supports de cours Linux libres de droits à destination des formateurs ou des
personnes désireuses d’apprendre à administrer un système Linux en autodidacte.

Les supports de Formatux sont publiés sous licence Creative Commons-BY-SA et sous licence Art
Libre. Vous êtes ainsi libre de copier, de diffuser et de transformer librement les œuvres dans le

Préface | 1
FORMATUX - Support de cours GNU/Linux

respect des droits de l’auteur.

BY : Paternité. Vous devez citer le nom de l’auteur original.

SA : Partage des Conditions Initiales à l’Identique.

• Licence Creative Commons-BY-SA : [Link]

• Licence Art Libre : [Link]

Les documents de Formatux et leurs sources sont librement téléchargeables sur framagit :

• [Link]

Vous y trouverez la dernière version de ce document.

A partir des sources, vous pouvez générer votre support de formation personnalisé. Nous vous
recommandons le logiciel AsciidocFX téléchargeable ici : [Link]

Gestion des versions

Table 1. Historique des versions du document

Version Date Observations

1.0 Avril 2017 Version initiale.
1.1 Juillet 2017 Ajout de généralités.
1.2 Aout 2017 Ajout du cours Jenkins et Rundeck
1.3 Février 2019 Ajout des cours Ansible Niveau 2, Ansistrano, Asciidoc,
Terraform

2 | Préface
FORMATUX - Support de cours GNU/Linux

Généralités devops
Attendus du cours

 devops, automatisation, gestion de configuration, intégration continue, DSL.

Connaissances :  

Niveau technique : 

Temps de lecture : 5 minutes

Le mouvement devops cherche à optimiser le travail de toutes les équipes intervenant sur un
système d’information.

• Les développeurs (les dev) cherchent à ce que leurs applications soient déployées le plus
souvent et le plus rapidement possible.

• Les administrateurs systèmes, réseaux ou de bases de données (les ops) cherchent à garantir la
stabilité, la sécurité de leurs systèmes et leur disponibilité.

Les objectifs des dev et des ops sont donc bien souvent opposés, la communication entre les
équipes parfois difficile : les dev et les ops n’utilisent pas toujours les mêmes éléments de langage.

• Il n’y a rien de plus frustrant pour un développeur que de devoir attendre la disponibilité d’un
administrateur système pour voir la nouvelle fonctionnalité de son application être mise en
ligne ;

• Quoi de plus frustrant pour un administrateur système de devoir déployer une nouvelle mise à
jour applicative manuellement alors qu’il vient de finir la précédente ?

La philosophie devops regroupe l’ensemble des outils des deux mondes, offre un langage commun,
afin de faciliter le travail des équipes avec comme objectif la performance économique pour
l’entreprise.

Le travail des développeurs et des administrateurs doit être simplifié afin d’être automatisé avec
des outils spécifiques.

Le vocabulaire DEVOPS
• le build : concerne la conception de l’application ;

• le run : concerne la maintenance de l’application ;

• le change : concerne l’évolution de l’application.

• l'intégration continue (Continuous Integration CI) : chaque modification d’un code source
entraîne une vérification de non-régression de l’application.

Généralités devops | 3
FORMATUX - Support de cours GNU/Linux

Figure 1. Schéma de fonctionnement de l’intégration continue

• automation (automatisation) : fonctionnement d’un système sans intervention humaine,

automatisation d’une suite d’opération.

• idempotence : une opération est idempotente si elle a le même effet qu’on l’applique une ou
plusieurs fois. Les outils de gestion de configuration sont généralement idempotent.

• orchestration : processus automatique de gestion d’un système informatique.

• provisionning : processus d’allocation automatique des ressources.

4 | Généralités devops
FORMATUX - Support de cours GNU/Linux

Pourquoi scripter en Bash n’est pas considéré comme de

l’automatisation ?

Ou les langages impératifs contre les languages déclaratifs…

Même si la connaissance du Bash est une exigence de base pour un administrateur système,
celui-ci est un langage de programmation interprété "impératif". Il exécute les instructions
les unes à la suite des autres.

Les langages dédiés au domaine (DSL Domain Specific Language) comme Ansible ou Puppet,
quant à eux, ne spécifient pas les étapes à réaliser mais l’état à obtenir.

Parce qu’Ansible ou Puppet utilisent un langage déclaratif, ils sont très simples. Il suffit de
leur dire "Fais cette action" ou "Met le serveur dans cet état". Ils considéreront l’état désiré
indépendamment de l’état initial ou du contexte. Peu importe dans quel état le serveur se
situe au départ, les étapes à franchir pour arriver au résultat, le serveur est mis dans l’état
désiré avec un rapport de succès (avec ou sans changement d’état) ou d’échec.

La même tâche d’automatisation en bash nécessiterait de vérifier tous les états possibles, les
autorisations, etc. afin de déterminer la tâche à accomplir avant de lancer l’exécution de la
commande, souvent en imbriquant de nombreux "si", ce qui complique la tâche, l’écriture et
la maintenance du script.

Les outils devops

• Outils de gestion de configuration

◦ Puppet

◦ Ansible

◦ Saltstack

◦ Chef

• Intégration continue

◦ Jenkins

◦ Gitlab-ci

• Orchestration des tâches

◦ Rundeck

Généralités devops | 5
FORMATUX - Support de cours GNU/Linux

Gestion de configurations avec Puppet

Il est difficile de s’appuyer sur des processus manuels ou des scripts personnalisés pour accomplir
des tâches répétitives.

Lorsque les environnements grossissent ou que les équipes accueillent de plus en plus de
techniciens, ces méthodes sont difficiles à maintenir et à optimiser. Elles peuvent causer des
risques pour la sécurité du système, incluant des erreurs de configuration, ce qui au final, peut
faire réduire la productivité.

La gestion automatique des configurations élimine beaucoup de travail manuel et augmente la

réactivité des équipes. Cette réactivité devient de plus en plus importante avec la montée en
puissance de la virtualisation, qui révolutionne notre gestion du cycle de vie des serveurs : durée de
vie plus courte, déploiement plus rapide, configurations plus standardisées et conformes.

Parmi les systèmes de gestion de configurations, plusieurs systèmes ont fait leur apparition :

• puppet ;

• chef ;

• ansible ;

• etc.

Des outils ont également fait leur apparition pour encore faciliter l’administration de ces systèmes :

• geppetto : un environnement de développement (IDE) pour puppet ;

• the foreman : un gestionnaire de cycle de vie complet des serveurs.

La gestion de configuration
La gestion de configuration est le processus de standardisation des configurations de ressources et
l’assurance de leur état dans l’infrastructure informatique, avec des méthodes automatisées mais
agiles. Le management de configurations est devenu critique pour le succès des projets
informatiques.

Concrètement, lors de l’ajout d’un nouveau serveur au sein d’une infrastructure informatique
complexe, les administrateurs système ne doivent pas perdre de temps pour la configuration des
briques de base du système : la configuration des services NTP, DNS, SMTP, SSH, la création des
comptes utilisateurs, etc… doit être totalement automatisée et transparente aux équipes.

L’utilisation d’un gestionnaire de configuration doit également permettre d’installer un clone de

serveur d’une manière totalement automatisée, ce qui peut être pratique pour des environnements
multiples (Développement → Intégration → Pré-production → Production).

La combinaison d’outils de gestion de configuration avec l’utilisation de dépôts de gestion de

versions, comme « git », permet de conserver un historique des modifications apportées au

6 | Gestion de configurations avec Puppet

FORMATUX - Support de cours GNU/Linux

système.

Puppet
Puppet a été conçu pour fonctionner en mode client-serveur. Son utilisation en mode de
fonctionnement « autonome » est également possible et facile. La migration vers un système de
clients « Puppet / Master Puppet » n’est pas d’une réalisation complexe.

Puppet est un logiciel d’automatisation qui rend simple pour l’administrateur système le
provisionnement (la description matérielle d’une machine virtuelle), la configuration et la gestion
de l’infrastructure tout au long de son cycle de vie. Il permet de décrire l’état de configuration d’un
ensemble hétérogène de stations de travail ou de serveurs et de s’assurer que l’état réel des
machines correspond bien à l’état demandé.

Par sa structure de langage, il fait le lien entre les bonnes pratiques, le cahier de procédures et l’état
effectif des machines.

Vocabulaire Puppet

• Noeud (Node) : serveur ou poste de travail administré par Puppet ;

• Site : ensemble des noeuds gérés par le Puppet Master ;

• Classe : moyen dans Puppet de séparer des morceaux de code ;

• Module : unité de code Puppet qui est réutilisable et pouvant être partagé ;

• Catalogue : ensemble des classes de configuration à appliquer à un nœud ;

• Facter : librairie multi-plateforme qui fournit à Puppet sous forme de variables les
informations propres au système (nom, adresse ip, système d’exploitation, etc.) ;

• Ressource (Resource): objet que Puppet peut manipuler (fichier, utilisateur, service, package,
etc.) ;

• Manifeste (Manifest) : regroupe un ensemble de ressource.

Architecture

Puppet conseille de coupler son fonctionnement avec un gestionnaire de version type « git ».

Un serveur PuppetMaster contient la configuration commune et les points de différence entre

machines ;

Chaque client fait fonctionner puppetd qui :

• applique la configuration initiale pour le nœud concerné ;

• applique les nouveautés de configuration au fil du temps ;

• s’assure de manière régulière que la machine correspond bien à la configuration voulue.

La communication est assurée via des canaux chiffrés, en utilisant le protocole https et donc TLS

Gestion de configurations avec Puppet | 7

FORMATUX - Support de cours GNU/Linux

(une mini-pki est fournie).

Toute la configuration (le référentiel) de Puppet est centralisée dans l’arborescence /etc/puppet du
serveur de référence :

• /etc/puppet/manifests/[Link] : est le premier fichier analysé par Puppet pour définir son
référentiel. Il permet de définir les variables globales et d’importer des modules ;

• /etc/puppet/manifests/[Link] : permet de définir les nœuds du réseau. Un nœud doit être

défini par le nom FQDN de la machine ;

• /etc/puppet/modules/<module> : sous-répertoire contenant un module.

Installation
Les dépôts Puppets doivent être activés :

[root]# vim /etc/yum/[Link].d/[Link]

[puppetlabs-products]
name=Puppet Labs Products El 6 - $basearch
baseurl=[Link]
gpgkey=[Link]
enabled=1
gpgcheck=1

[puppetlabs-deps]
name=Puppet Labs Dependencies EL 6 - $basearch
baseurl=[Link]
gpgkey=[Link]
enabled=1
gpgcheck=1

puis :

[root]# yum update

[root]# yum install puppet

Hello world
Pour fonctionner, le client autonome puppet a besoin d’un fichier appelé manifeste, dont
l’extension sera en « .pp ».

Le langage utilisé est le ruby.

Créer un fichier /root/[Link] :

8 | Gestion de configurations avec Puppet

FORMATUX - Support de cours GNU/Linux

[root]# vim /root/[Link]

file {'helloworld':
path => '/tmp/helloworld',
ensure => present,
mode => 0640,
content => "Helloworld via puppet ! "
}

Exécuter ce manifeste avec la commande puppet :

[root]# puppet apply /root/[Link]

Notice : Compiled catalog for centos6 in environnement production in 0.31 seconds
Notice: /Stage[main]/main/File[helloworld]/ensure: created
Notice: Finished catalog run in 0.07 seconds

Les modules Puppet

Les modules complémentaires à Puppet peuvent être téléchargés sur le site puppetlabs.

L’installation d’un module complémentaire pourra se faire, soit directement depuis internet, soit
par le téléchargement manuel de l’archive .[Link].

Depuis internet :

puppet module install nomdumodule

Une commande de recherche de modules existe :

puppet module search nomdumodule

Pour rechercher les modules installés :

puppet module list

Et pour les mettre à jour :

puppet module upgrade nomdumodule

Gestion de configurations avec Puppet | 9

FORMATUX - Support de cours GNU/Linux

Pensez à préciser le proxy dans la commande puppet en exportant les variables

http_proxy et https_proxy :

 export http_proxy=[Link]
export https_proxy=[Link]

Sans connexion internet

Sans connexion internet, un module peut être installé en fournissant dans la commande puppet le
chemin vers le fichier [Link] :

puppet module install ~/[Link] --ignore-dependencies

Grâce aux modules du dépôt Puppet, les possibilités de l’outil sont quasiment infinies. Le
téléchargement et l’utilisation des modules du dépôt permettent un gain de temps confortable car
l’outil nécessite peu de compétences en développement.

Documentation
La liste des types et leurs attributs est consultable en ligne :

• [Link]

Une documentation de formation est également consultable :

• [Link]

Commandes utiles
Lister les objets connus par puppet :

puppet describe -l

Lister les valeurs possibles d’une ressource :

puppet describe user

Lister les objets du système :

puppet resource user

10 | Gestion de configurations avec Puppet

FORMATUX - Support de cours GNU/Linux

Cas concrets
La création d’un noeud (node)

Le code du manifeste doit être découpé en classe pour des raisons de maintenance et d’évolutivité.

Un objet de type node recevra les classes à exécuter. Le node « default » est automatiquement
exécuté.

Le fichier [Link] contiendra l’ensemble du code :

node default {
include init_services
}

Gestion des services

La classe init_services contient les services qui doivent être lancés sur le nœud et ceux qui doivent
être stoppés :

class init_services {

service { [“sshd”,”NetworkManager”,”iptables”,”postfix”,”puppet”,”rsyslog”,”sssd”,
”vmware-tools”]:
ensure => ‘running’,
enable => ‘true’,
}

service { [“atd”,”cups”,”bluetooth”,”ip6tables”,”ntpd”,”ntpdate”,”snmpd”,”snmptradp”]:
ensure => ‘stopped’,
enable => ‘false’,
}
}

La ligne ensure ⇒ a pour effet de démarrer ou non un service, tandis que la ligne enable ⇒ activera
ou non le démarrage du service au démarrage du serveur.

Gestion des utilisateurs

La classe create_users contiendra les utilisateurs de notre système. Pensez à ajouter l’appel de cette
classe dans le node default !

Gestion de configurations avec Puppet | 11

FORMATUX - Support de cours GNU/Linux

class create_users {
user { ‘antoine’:
ensure => present,
uid => ‘5000’,
gid => ‘users’,
shell => ‘/bin/bash’,
home => ‘/home/antoine’,
managehome => true,
}
}

node default {
include init_services
include create_users
}

Au départ du personnel pour mutation, il sera aisé de supprimer son compte en remplaçant la ligne
ensure ⇒ present par ensure ⇒ absent et en supprimant le reste des options.

La directive managehome permet de créer les répertoires personnels à la création des comptes.

La création des groupes est toute aussi aisée :

group { "DSI":
ensure => present,
gid => 1001
}

Gestion des dossiers et des fichiers

Un dossier peut être créé avec la ressource « file » :

file { '/etc/skel/boulot':
ensure => directory,
mode => 0644,
}

Un fichier peut être copié d’un répertoire vers un autre :

12 | Gestion de configurations avec Puppet

FORMATUX - Support de cours GNU/Linux

file { '/STAGE/utilisateurs/gshadow':
mode => 440,
owner => root,
group => root,
source => "/etc/gshadow"
}

Modification de valeurs

La commande augeas, développée par la société RedHat, permet de modifier les valeurs des
variables dans les fichiers de configuration. Son utilisation peut s’avérer autant puissante que
complexe.

Un usage minimaliste serait par exemple :

augeas { "Modification default login defs" :

context => "/files/etc/[Link]",
changes => ["set UID_MIN 2000","set GID_MIN 700","set PASS_MAX_DAYS 60"],
}

Le contexte est suffixé de « /files/ » pour préciser qu’il s’agit d’un système de fichiers local.

Exécution d’une commande externe

La commande exec est utilisée pour lancer une commande externe :

exec { "Redirection":
command => "/usr/sbin/useradd -D > /STAGE/utilisateurs/defaut",
}

De manière générale, les commandes et les fichiers doivent être décrits en absolu
dans les manifestes.

Rappel : la commande whereis fournit le chemin absolu d’une commande.

Gestion de configurations avec Puppet | 13

FORMATUX - Support de cours GNU/Linux

Ansible
 Objectifs

 Mettre en oeuvre Ansible ;

 Appliquer des changements de configuration sur un serveur ;
 Créer des playbooks Ansible.

Ansible centralise et automatise les tâches d’administration. Il est :

• sans agent (il ne nécessite pas de déploiements spécifiques sur les clients),

• idempotent (effet identique à chaque exécution)

• et utilise le protocole SSH pour configurer à distance les clients Linux.

L’interface graphique web Ansible Tower est payante.

Figure 2. Les fonctionnalités d’Ansible

L’ouverture des flux SSH vers l’ensemble des clients depuis le serveur Ansible font
 de lui un elément critique de l’architecture qu’il faudra attentivement surveiller.

14 | Ansible
FORMATUX - Support de cours GNU/Linux

Le vocabulaire ansible
• Le poste de gestion : la machine sur laquelle Ansible est installée. Ansible étant agentless,
aucun logiciel n’est déployé sur les serveurs gérés.

• L'inventaire : un fichier contenant les informations concernant les serveurs gérés.

• Les tâches (tasks) : une tâche est un bloc définissant une procédure à exectuer (par exemple
créer un utilisateur ou un groupe, installer un paquet logiciel, etc.).

• Un module : un module rend abstrait une tâche. Il existe de nombreux modules fournis par
Ansible.

• Les playbooks : un fichier simple au format yaml définissant les serveurs cibles et les tâches
devant être effectuées.

• Un rôle : un rôle permet d’organiser les playbooks et tous les autres fichiers nécessaires
(modèles, scripts, etc.) pour faciliter le partage et la réutilisation du code.

• Les facts : ce sont des variables globales contenant des informations à propos du système (nom
de la machine, version du système, interface et configuration réseau, etc.).

• les handlers: il sont utilisés pour provoquer un arrêt ou un redémarrage d’un service en cas de
changement.

Installation sur le serveur de gestion

Ansible est disponible dans le dépôt EPEL :

• Installation d’EPEL :

$ sudo yum install epel-release

La configuration du serveur se situe sous /etc/ansible.

Deux fichiers de configuration :

• Le fichier de configuration principal [Link] : commandes, modules, plugins, configuration

ssh ;

• Le fichier inventaire de gestion des machines clientes hosts : déclaration des clients, des
groupes.

Ansible | 15
FORMATUX - Support de cours GNU/Linux

Le fichier /etc/ansible/hosts

# This is the default ansible 'hosts' file.

#
# It should live in /etc/ansible/hosts
#
# - Comments begin with the '#' character
# - Blank lines are ignored
# - Groups of hosts are delimited by [header] elements
# - You can enter hostnames or ip addresses
# - A hostname/ip can be a member of multiple groups

# Ex 1: Ungrouped hosts, specify before any group headers.

## [Link]
## [Link]
## [Link]
## [Link]

# Ex 2: A collection of hosts belonging to the 'webservers' group

## [webservers]
## [Link]
## [Link]
## [Link]
## [Link]

...

Par exemple, un groupe centos7 est créé en insérant le bloc suivant dans ce fichier :

Création d’un groupe d’hôtes dans /etc/ansible/hosts

[centos7]
[Link]
[Link]

Utilisation en ligne de commande

La commande ansible lance une tâche sur un ou plusieurs hôtes cibles.

Syntaxe de la commande ansible

ansible <host-pattern> [-m module_name] [-a args] [options]

Exemples :

16 | Ansible
FORMATUX - Support de cours GNU/Linux

• Lister les hôtes appartenant à un groupe :

ansible {{group}} --list-hosts

• Pinger un groupe d’hôtes avec le module ping :

ansible {{group}} -m ping

• Afficher des facts d’un groupe d’hôtes avec le module setup :

ansible {{group}} -m setup

• Exécuter une commande sur un groupe d’hôtes en invoquant le module command avec des
arguments :

ansible {{group}} -m command -a '{{commande}}'

• Exécuter une commande avec les privilèges d’administrateur :

ansible {{group}} --become --ask-become-pass -m command -a '{{commande}}'

• Exécuter une commande en utilisant un fichier d’inventaire personnalisé :

ansible {{group}} -i {{inventory_file}} -m command -a '{{commande}}'

Table 2. Options principales de la commande ansible

Option Information
-a 'arguments' Les arguments à passer au module.
-b -K Demande un mot de passe et lance la commande avec des privilèges
supérieurs.
--user=utilisateur Utilise cet utilisateur pour se connecter à l’hôte cible au lieu d’utiliser
l’utilisateur courant.
--become Exécute l’opération en tant que cet utilisateur (défaut : root).
-user=utilisateur
-C Simulation. Ne fait pas de changement sur la cible mais la teste pour voir ce
qui devrait être changé.
-m module Exécute le module appelé

Ansible | 17
FORMATUX - Support de cours GNU/Linux

Tester avec le module ping

Par défaut la connexion par mot de passe n’est pas autorisée par Ansible.

Décommenter la ligne suivante de la section [defaults] dans le fichier de configuration

/etc/ansible/[Link] :

ask_pass = True

Lancer un ping sur chacun des serveurs du groupe CentOS 7 :

# ansible centos7 -m ping

SSH password:
[Link] | SUCCESS => {
"changed": false,
"ping": "pong"
}
[Link] | SUCCESS => {
"changed": false,
"ping": "pong"
}

Le mot de passe root des serveurs distants vous est demandé, ce qui pose un
 problème de sécurité…

Authentification par clef

L’authentification par mot de passe va être remplacée par une authentification par clefs
privée/publique beaucoup plus sécurisée.

Création d’une clef SSH

La bi-clefs va être générée avec la commande ssh-keygen :

18 | Ansible
FORMATUX - Support de cours GNU/Linux

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:RpYuJzkkaeZzve8La8Xd/8kTTE8t43DeS+L7WB26WF8 root@ansible-srv
The key's randomart image is:
+---[RSA 2048]----+
| |
| . . |
| = . + .|
| + o * . +.o|
| o * S. . *o*.|
| o * .o ..=+=|
| o. .oooE|
| .+ o.*o+|
| ...+o +o=+|
+----[SHA256]-----+

La clef publique peut être copiée sur les serveurs :

# ssh-copy-id root@[Link]
# ssh-copy-id root@[Link]

Re-commenter la ligne suivante de la section [defaults] dans le fichier de configuration

/etc/ansible/[Link] pour empêcher l’authentification par mot de passe :

#ask_pass = True

Test d’authentification par clef privée

Pour le prochain test, le module shell, permettant l’exécution de commandes à distance, est utilisé :

# ansible centos7 -m shell -a "uptime"

[Link] | SUCCESS | rc=0 >>
[Link] up 57 min, 1 user, load average: 0.00, 0.00, 0.00

[Link] | SUCCESS | rc=0 >>

[Link] up 57 min, 1 user, load average: 0.00, 0.00, 0.00

Ansible | 19
FORMATUX - Support de cours GNU/Linux

Aucun mot de passe n’est demandé, l’authentification par clé privée/publique fonctionne !

Exemple de connexion à une instance Cloud Amazon ECS

Lors de la création d’une instance Amazon, une clef privée est créée et téléchargée sur le poste
local.

Ajout de la clef dans l’agent SSH :

ssh-add path/to/[Link]

Lancement des facts sur les serveurs aws :

ansible aws --user=ec2-user --become -m setup

Pour une image ubuntu, il faudra utiliser l’utilisateur ubuntu :

ansible aws --user=ubuntu --become -m setup

Utilisation
Ansible peut être utilisé depuis l’interpréteur de commandes ou via des playbooks.

Les modules

La liste des modules classés par catégories se trouve à l’adresse [Link]

modules_by_category.html. Ansible en propose plus de 750 !

Un module s’invoque avec l’option -m de la commande ansible.

Il existe un module pour chaque besoin ou presque ! Il est donc conseillé, au lui d’utiliser le module
shell, de chercher un module adapté au besoin.

Chaque catégorie de besoin dispose de son module. En voici une liste non exhaustive :

Table 3. Catégories de modules

Type Exemples
Gestion du système user (création des utilisateurs), group (gestion
des groupes), etc.
Gestion des logiciels yum, apt, pip, npm
Gestion des fichiers copy, fetch, lineinfile, template, archive
Gestion des bases de données mysql, postgresql, redis

20 | Ansible
FORMATUX - Support de cours GNU/Linux

Type Exemples
Gestion du cloud amazon S3, cloudstack, openstack
Gestion d’un cluster consul, zookeeper
Envoyer des commandes shell, script, expect
Gestion des messages
Gestion du monitoring
Gestion du réseau get_url

Gestion des notifications

Gestion des sources git, gitlab

Exemple d’installation logiciel

Le module yum permet d’installer des logiciels sur les clients cibles :

# ansible centos7 -m yum -a name="httpd"

[Link] | SUCCESS => {
"changed": true,
"msg": "",
"rc": 0,
"results": [
...
\n\nComplete!\n"
]
}
[Link] | SUCCESS => {
"changed": true,
"msg": "",
"rc": 0,
"results": [
...
\n\nComplete!\n"
]
}

Le logiciel installé étant un service, il faut maintenant le démarrer avec le module service (CentOS
6) ou systemd (CentOS 7) :

Ansible | 21
FORMATUX - Support de cours GNU/Linux

# ansible centos7 -m systemd -a "name=httpd state=started"

[Link] | SUCCESS => {
"changed": true,
"name": "httpd",
"state": "started"
}
[Link] | SUCCESS => {
"changed": true,
"name": "httpd",
"state": "started"
}

Les playbooks
Les playbooks ansible décrivent une politique à appliquer à des systèmes distants, pour forcer leur
configuration. Les playbooks sont écrits dans un format texte facilement compréhensible
regroupant un ensemble de tâches : le format yaml.

 En savoir plus sur le yaml : [Link]

Syntaxe de la commande ansible-playbook

ansible-playbook <[Link]> ... [options]

Les options sont identiques à la commande ansible.

La commande renvoi les codes d’erreurs suivants :

Table 4. Codes de sortie de la commande ansible-playbook

Code Erreur
0 OK ou aucun hôte correspondant
1 Erreur
2 Un ou plusieurs hôtes sont en échecs
3 Un ou plusieurs hôtes ne sont pas joignables
4 Erreur d’analyse
5 Mauvaises options ou options incomplètes
99 Execution interrompue par l’utilisateur
250 Erreur inattendue

Exemple de playbook Apache et MySQL

Le playbook suivant permet d’installer Apache et MySQL sur nos serveurs cibles :

22 | Ansible
FORMATUX - Support de cours GNU/Linux

---
- hosts: centos7
remote_user: root

tasks:
- name: ensure apache is at the latest version
yum: name=httpd,php,php-mysqli state=latest
- name: ensure httpd is started
systemd: name=httpd state=started
- name: ensure mysql is at the latest version
yum: name=mysql-server state=latest
- name: ensure mysqld is started
systemd: name=mysqld state=started

L’exécution du playbook s’effectue avec la commande ansible-playbook :

$ ansible-playbook test

PLAY [centos7] ****************************************************************

TASK [setup] ******************************************************************

ok: [[Link]]
ok: [[Link]]

TASK [ensure apache is at the latest version] *********************************

ok: [[Link]]
ok: [[Link]]

TASK [ensure httpd is started] ************************************************

changed: [[Link]]
changed: [[Link]]

TASK [ensure mysql is at the latest version] **********************************

changed: [[Link]]
changed: [[Link]]

TASK [ensure mysqld is started] ***********************************************

changed: [[Link]]
changed: [[Link]]

PLAY RECAP *********************************************************************

[Link] : ok=5 changed=3 unreachable=0 failed=0
[Link] : ok=5 changed=3 unreachable=0 failed=0

Ansible | 23
FORMATUX - Support de cours GNU/Linux

Exemple de préparation d’un noeud MySQL

Dans ce playbook, un serveur va être installé et configuré pour héberger une base de données
MySQL.

Le playbook utilise :

• Des variables ;

• Ajoute des lignes dans le fichier /etc/hosts ;

• Installe et démarre MariaDB ;

• Créer une base de données, un utilisateur et lui donne tous les droits sur les bases de données.

24 | Ansible
FORMATUX - Support de cours GNU/Linux

---

- hosts: centos7
become: yes
vars:
mysqlpackage: "mariadb-server,MySQL-python"
mysqlservice: "mariadb"
mysql_port: "3306"
dbuser: "synchro"
dbname: "mabase"
upassword: "M!rro!r"

tasks:
- name: configurer le noeud 1 dans /etc/hosts
lineinfile:
dest: /etc/hosts
line: "[Link] [Link] mirroir1"
state: present
- name: configurer le noeud 2 dans /etc/hosts
lineinfile:
dest: /etc/hosts
line: "[Link] [Link] mirroir2"
state: present
- name: mariadb installe et a jour
yum: name="{{ mysqlpackage }}" state=latest
- name: mariadb est demarre
service: name="{{ mysqlservice }}" state=started
- name: creer la base de donnee
mysql_db: name="{{ dbname }}" state=present
- name: creer un utilisateur
mysql_user: name="{{ dbuser }}" password="{{ upassword }}" priv=*.*:ALL host='%'
state=present
- name: restart mariadb
service: name="{{ mysqlservice }}" state=restarted
...

La gestion des boucles

Il existe plusieurs type de boucles sous Ansible :

• with_items
• with_file
• with_fileglob
• …

Exemple d’utilisation, création de 3 utilisateurs :

Ansible | 25
FORMATUX - Support de cours GNU/Linux

- name: ajouter des utilisateurs

user:
name: "{{ item }}"
state: present
groups: "users"
with_items:
- antoine
- xavier
- patrick

Les rôles
Un rôle Ansible est une unité favorisant la réutilisabilité des playbooks.

Un squelette de rôle, servant comme point de départ du développement d’un rôle personnalisé,
peut être généré par la commande ansible-galaxy :

$ ansible-galaxy init formatux

La commande aura pour effet de générer l’arborescence suivante pour contenir le rôle formatux :

$ tree formatux
formatux/
├── defaults
│   └── [Link]
├── handlers
│   └── [Link]
├── meta
│   └── [Link]
├── [Link]
├── tasks
│   └── [Link]
├── tests
│   ├── inventory
│   └── [Link]
└── vars
└── [Link]

La commande ansible-galaxy

La commande ansible-galaxy gère des rôles en utilisant le site [Link].

26 | Ansible
FORMATUX - Support de cours GNU/Linux

Syntaxe de la commande ansible-galaxy

Table 5. Sous-commandes de la commande ansible-galaxy

Sous-commandes Observations
install installe un rôle
remove retire un ou plusieurs rôles
init génère un squelette de nouveau rôle
import importe un rôle depuis le site web galaxy. Nécessite un login au préalable.

Ansible | 27
FORMATUX - Support de cours GNU/Linux

Ansible Niveau 2
 Objectifs

 Utiliser les variables ;

 Mettre en oeuvre des boucles et des conditions ;
 Gérer les fichiers ;
 Envoyer des notifications et réagir ;
 Gérer les fichiers ;
 Créer des tâches asynchrones.

Les variables
Plus d’informations sur [Link]
 playbooks_variables.html

Sous Ansible, il existe deux types de variables :

• la valeur simple

• le dictionnaire

Une variable peut être définie dans un playbook, dans un rôle ou depuis la ligne de commande.

Par exemple, depuis un playbook :

---
- hosts: apache1
remote_user: root
vars:
port_http: 80
service:
debian: apache2
centos: httpd

ou depuis la ligne de commande :

$ ansible-playbook [Link] --extra-vars "service=httpd"

Une fois définie, une variable peut être utilisée en l’appellant entre doubles accolades :

• {{ port_http }} pour la valeur simple

◦ {{ service['centos'] }} ou {{ [Link] }} pour le dictionnaire.

28 | Ansible Niveau 2
FORMATUX - Support de cours GNU/Linux

Par exemple :

tasks:
- name: make sure apache is started
service: name={{ service['centos'] }} state=started

Evidemment, il est également possible d’accéder aux variables globales d’Ansible (type d’OS,
adresses IP, nom de la VM, etc.).

Externaliser les variables

Les variables peuvent être déportées dans un fichier externe au playbook, auquel cas il faudra
définir ce fichier dans le playbook avec la directive vars_files :

---
- hosts: apache1
remote_user: root
vars_files:
- [Link]

Le fichier [Link]

---
port_http: 80
service:
debian: apache2
centos: httpd

Afficher une variable

Pour afficher une variable, il faut activer le mode debug de la façon suivante :

Afficher une variable

- debug:
msg: "Afficher la variable : {{ service['debian'] }}"

Enregistrer le retour d’une tâche

Pour enregistrer le retour d’une tâche et pouvoir y accéder plus tard, il faut utiliser le mot clef
register à l’intérieur même de la tâche.

Ansible Niveau 2 | 29
FORMATUX - Support de cours GNU/Linux

Utilisation d’une variable stockée

tasks:
- name: contenu de /home
shell: ls /home
register: homes

- name: affiche le premier repertoire

debug:
var: homes.stdout_lines[0]

- name: affiche le second repertoire

debug:
var: homes.stdout_lines[1]

Les chaînes de caractères composant la variable enregistrée sont accessibles via la valeur stdout (ce
qui permet de faire des choses comme [Link]("core") != -1), de les exploiter en
utilisant une boucle (voir with_items), ou tout simplement par leurs indices comme vu dans
l’exemple précédent.

La gestion des boucles

 Plus d’informations sur [Link]

Il existe plusieurs types de boucles sous Ansible, en fonction de l’objet que vous voulez manipuler :

• with_items
• with_file
• with_dict
• with_fileglob
• …

Exemple d’utilisation, création de 3 utilisateurs :

- name: ajouter des utilisateurs

user:
name: "{{ item }}"
state: present
groups: "users"
with_items:
- antoine
- kevin
- nicolas

Nous pouvons reprendre l’exemple vu durant l’étude des variables stockées pour l’améliorer :

30 | Ansible Niveau 2
FORMATUX - Support de cours GNU/Linux

Utilisation d’une variable stockée

tasks:
- name: contenu de /home
shell: ls /home
register: homes

- name: affiche le nom des repertoires

debug:
msg: "Dossier => {{ item }}"
with_items:
- "{{ homes.stdout_lines }}"

Une fois un dictionnaire créé, celui-ci peut être parcouru en utilisant la variable item comme index :

---
- hosts: ansiblecli
remote_user: ansible
become: true
vars:
users:
antoine:
group: users
state: present
erwan:
group: users
state: absent

tasks:

- name: creer les utilisateurs

user:
name: "{{ item }}"
group: "{{ users[item]['group'] }}"
state: "{{ users[item]['state'] }}"
with_items: "{{ users }}"

Les conditions
Plus d’informations sur [Link]
 playbooks_conditionals.html

L’instruction when est très pratique dans de nombreux cas : ne pas effectuer certaines actions sur
certains type de serveur, si un fichier ou un n’utilisateur n’existe pas, etc.

Ansible Niveau 2 | 31
FORMATUX - Support de cours GNU/Linux

Derrière l’instruction when les variables ne nécessitent pas de doubles accolades (il
 s’agit en fait d’expressions Jinja2…).

tasks:
- name: "ne redemarre que les OS Debian"
command: /sbin/shutdown -r now
when: ansible_os_family == "Debian"

Les conditions peuvent être regroupées avec des parenthèses :

tasks:
- name: "ne redémarre que les CentOS version 6 et Debian version 7"
command: /sbin/shutdown -r now
when: (ansible_distribution == "CentOS" and ansible_distribution_major_version ==
"6") or
(ansible_distribution == "Debian" and ansible_distribution_major_version ==
"7")

Les conditions correspondant à un ET logique peuvent être fournies sous forme de liste :

tasks:
- name: "ne redémarre que les CentOS 6"
command: /sbin/shutdown -r now
when:
- ansible_distribution == "CentOS"
- ansible_distribution_major_version == "6"

Le résultat de la variable peut aussi être utilisé conjointement aux conditions when et son absence
de contenu évalué :

tasks:

- name: check if /data exists

command: find / -maxdepth 1 -type d -name data
register: datadir

- name: print warning if /data does not exist

debug: msg="Le dossier /data n'existe pas..."
when: [Link] == ""

32 | Ansible Niveau 2
FORMATUX - Support de cours GNU/Linux

La gestion des fichiers

Plus d’informations sur [Link]
 list_of_files_modules.html

En fonction de votre besoin, vous allez être amenés à utiliser différents modules Ansible pour
modifier les fichiers de configuration du système.

Le module ini_file

Lorsqu’il s’agit de modifier un fichier de type INI (section entre [] puis paires de clef=valeur), le plus
simple est d’utiliser le module ini_file.

Le module nécessite :

• La valeur de la section

• Le nom de l’option

• La nouvelle valeur

Exemple d’utilisation :

- name: change value on inifile

ini_file: dest=/path/to/[Link] section=SECTIONNAME option=OPTIONNAME
value=NEWVALUE

Le module lineinfile

Pour s’assurer qu’une ligne est présente dans un fichier, ou lorsqu’une seule ligne d’un fichier doit
être ajoutée ou modifiée.

 Voir [Link]

Dans ce cas, la ligne à modifier d’un fichier sera retrouvée à l’aide d’une regexp.

Par exemple, pour s’assurer que la ligne commençant par 'SELINUX=' dans le fichier
/etc/selinux/config contiennent la valeur enforcing :

- lineinfile:
path: /etc/selinux/config
regexp: '^SELINUX='
line: 'SELINUX=enforcing'

Ansible Niveau 2 | 33
FORMATUX - Support de cours GNU/Linux

Le module copy

Lorsqu’un fichier doit être copié depuis le serveur Ansible vers un ou plusieurs hosts, dans ce cas il
est préférable d’utiliser le module copy :

- copy:
src: /data/ansible/sources/[Link]
dest: /etc/[Link]
owner: root
group: root
mode: 0644

Le module fetch

Lorsqu’un fichier doit être copié depuis un serveur distant vers le serveur local.

Ce module fait l’inverse du module copy.

- fetch:
src: /etc/[Link]
dest: /data/ansible/backup/monfichier-{{ inventory_hostname }}.conf
flat: yes

Le module template

Ansible et son module template utilisent le système de template Jinja2 ([Link]

pour générer des fichiers sur les hôtes cibles.

- template:
src: /data/ansible/templates/monfichier.j2
dest: /etc/[Link]
owner: root
group: root
mode: 0644

Il est possible d’ajouter une étape de validation si le service ciblé le permet (par exemple apache
avec la commande apachectl -t) :

34 | Ansible Niveau 2
FORMATUX - Support de cours GNU/Linux

- template:
src: /data/ansible/templates/vhost.j2
dest: /etc/httpd/sites-available/[Link]
owner: root
group: root
mode: 0644
validate: '/usr/sbin/apachectl -t'

Le module get_url

Pour télécharger vers un ou plusieurs hôtes des fichiers depuis un site web ou ftp.

- get_url:
url: [Link]
dest: /tmp/[Link]
mode: 0640
checksum: sha256:f772bd36185515581aa9a2e4b38fb97940ff28764900ba708e68286121770e9a

En fournissant un checksum du fichier, ce dernier ne sera pas re-téléchargé s’il est déjà présent à
l’emplacement de destination et que son checksum correspond à la valeur fournie.

Les handlers
Plus d’informations sur [Link]
 playbooks_intro.html#handlers-running-operations-on-change

Les handlers permettent de lancer des opérations, comme relancer un service, lors de
changements.

Un module, étant idempotent, un playbook peut détecter qu’il y a eu un changement significatif sur
un système distant, et donc déclencer une opération en réaction à ce changement. Une notification
est envoyée à la fin d’un bloc de tâche du playbook, et l’opération en réaction ne sera déclenchée
qu’une seule fois même si plusieurs tâches différentes envoient cette notification.

Par exemple, plusieurs tâches peuvent indiquer que le service httpd nécessite une relance à cause
d’un changement dans ses fichiers de configuration. Mais le service ne sera redémarré qu’une seule
fois pour éviter les multiples démarrages non nécessaires.

- name: template configuration file

template: src=modele-site.j2 dest=/etc/httpd/sites-availables/[Link]
notify:
- restart memcached
- restart httpd

Ansible Niveau 2 | 35
FORMATUX - Support de cours GNU/Linux

Un handler est une sorte de tâche référencé par un nom unique global :

• Il est activé par ou un plusieurs notifiers.

• Il ne se lance pas immédiatement, mais attend que toutes les tâches soient complètes pour
s’exécuter.

Exemple de handlers

handlers:
- name: restart memcached
service: name=memcached state=restarted
- name: restart httpd
service: name=httpd state=restarted

Depuis la version 2.2 d’Ansible, les handlers peuvent se mettre directement à l’écoute des tâches :

handlers:
- name: restart memcached
service: name=memcached state=restarted
listen: "restart web services"
- name: restart apache
service: name=apache state=restarted
listen: "restart web services"

tasks:
- name: restart everything
command: echo "this task will restart the web services"
notify: "restart web services"

Les rôles
Plus d’informations sur [Link]
 playbooks_reuse_roles.html

Un rôle Ansible est une unité favorisant la réutilisabilité des playbooks.

Un squelette de rôle, servant comme point de départ du développement d’un rôle personnalisé,
peut être généré par la commande ansible-galaxy :

$ ansible-galaxy init claranet

La commande aura pour effet de générer l’arborescence suivante pour contenir le rôle claranet :

36 | Ansible Niveau 2
FORMATUX - Support de cours GNU/Linux

$ tree claranet
claranet/
├── defaults
│   └── [Link]
├── handlers
│   └── [Link]
├── meta
│   └── [Link]
├── [Link]
├── tasks
│   └── [Link]
├── tests
│   ├── inventory
│   └── [Link]
└── vars
└── [Link]

Les rôles permettent de s’affranchir totalement de l’inclusion des fichiers. Plus besoin de spécifier
les chemins d’accès aux fichiers, les directives include dans les playbook. Il suffit de spécifier une
tâche, ansible s’occupe des inclusions.

La commande ansible-galaxy

La commande ansible-galaxy gère des rôles en utilisant le site [Link].

Syntaxe de la commande ansible-galaxy

Table 6. Sous-commandes de la commande ansible-galaxy

Les tâches asynchrones

Plus d’informations sur [Link]
 playbooks_async.html

Par défaut, les connexions SSH vers les hosts restent ouvertes durant l’exécution des différentes
tâches d’un playbook sur l’ensemble des noeuds.

Ansible Niveau 2 | 37
FORMATUX - Support de cours GNU/Linux

Cela peut poser quelques problèmes, notamment :

• si la durée d’exécution de la tâche est supérieure au timeout de la connexion SSH

• si la connexion est interrompue durant l’action (reboot du serveur par exemple)

Dans ce cas, il faudra basculer en mode asynchrone et spécifier un temps maximum d’exécution
ainsi que la fréquence (par défaut à 10s) avec laquelle vous allez vérifier le status de l’hôte.

En spécifiant une valeur de poll à 0, Ansible va exécuter la tâche et continuer sans se soucier du
résultat.

Voici un exemple mettant en oeuvre les tâches asynchrones, qui permet de relancer un serveur et
d’attendre que le port 22 soit de nouveau joignable :

# On attend 2s et on lance un reboot

- name: Reboot system
shell: sleep 2 && shutdown -r now "Ansible reboot triggered"
async: 1
poll: 0
ignore_errors: true
become: true
changed_when: False

# On attend que ça revienne

- name: Waiting for server to restart (10 mins max)
wait_for:
host: "{{ inventory_hostname }}"
port: 22
delay: 30
state: started
timeout: 600
delegate_to: localhost

Connexion à une instance Cloud Amazon ECS

Lors de la création d’une instance Amazon, une clef privée est créée et téléchargée sur le poste
local.

Ajout de la clef dans l’agent SSH :

ssh-add path/to/[Link]

Lancement des facts sur les serveurs aws :

38 | Ansible Niveau 2
FORMATUX - Support de cours GNU/Linux

ansible aws --user=ec2-user --become -m setup

Pour une image ubuntu, il faudra utiliser l’utilisateur ubuntu :

ansible aws --user=ubuntu --become -m setup

Ansible Niveau 2 | 39
FORMATUX - Support de cours GNU/Linux

Ansistrano
 Objectifs

 Mettre en oeuvre Ansistrano ;

 Configurer Ansistrano ;
 Utiliser des dossiers et fichiers partagés entre versions déployées ;
 Déployer différentes versions d’un site depuis git ;
 Réagir entre les étapes de déploiement.

Introduction
Ansistrano est un rôle Ansible pour déployer facilement des applications PHP, Python, etc. Il se base
sur le fonctionnement de Capistrano

Ansistrano nécessite pour fonctionner :

• Ansible sur la machine de déploiement,

• rsync ou git sur la machine cliente.

Il peut télécharger le code source depuis rsync, git, scp, http, S3, …

Dans le cadre de notre exemple de déploiement, nous allons utiliser le protocole

 git.

Ansistrano déploie les applications en suivant ces 5 étapes :

• Setup : création de la structure de répertoire pour accueillir les releases

• Update Code : téléchargement de la nouvelle release sur les cibles

• Symlink Shared et Symlink : après avoir déployé la nouvelle release, le lien symbolique current
est modifié pour pointer vers cette nouvelle release

• Clean Up : pour faire un peut de nettoyage (suppression des anciennes versions)

40 | Ansistrano
FORMATUX - Support de cours GNU/Linux

Figure 3. Etapes d’un déploiement

Le squelette d’un déploiement avec ansistrano ressemble à :

Squelette d’un déploiement avec ansistrano

/var/www/site/
├── current -> ./releases/20180821070043Z
├── releases
│   └── 20180821070043Z
│   ├── css -> ../../shared/css/
│   ├── img -> ../../shared/img/
│   └── REVISION
├── repo
└── shared
├── css/
└── img/

Vous retrouverez toute la documentation ansistrano sur son dépôt Github.

Module 1 : Prise en main de la plateforme

Exercice 1.1 : Déploiement de la plateforme

Vous allez travailler sur 2 VM :

Ansistrano | 41
FORMATUX - Support de cours GNU/Linux

• La VM de gestion :

◦ Vous devrez installer ansible et déployer le rôle ansistrano-deploy

• La VM cliente :

◦ Cette VM n’a aucun logiciel spécifique.

◦ Vous devrez installer Apache et déployer le site du client

Module 2 : Déployer le serveur Web

Exercice 2.1 : Utiliser le rôle [Link] pour configurer le serveur

Pour gérer notre serveur web, nous allons utiliser le rôle [Link] qu’il faut installer sur
le serveur :

[ansiblesrv] $ ansible-galaxy install [Link]

Une fois le rôle installé, nous allons pouvoir créer la première partie de notre playbook, qui va :

• Installer Apache,

• Créer un dossier cible pour notre vhost,

• Créer un vhost par défaut,

• Démarrer ou rédémarrer Apache.

Considérations techniques :

• Nous allons déployer notre site dans le dossier /var/www/site/.

• Comme nous le verrons plus loin, ansistrano va créer un lien symbolique current vers le dossier
de la release en cours.

• Le code source à déployer contient un dossier html sur lequel le vhost devra pointer. Sa
DirectoryIndex est [Link].

• Le déploiement se faisant par git, le paquet sera installé.

 La cible de notre vhost sera donc : /var/www/site/current/html.

42 | Ansistrano
FORMATUX - Support de cours GNU/Linux

tasks:

- name: create directory for website

file:
path: /var/www/site/
state: directory
mode: 0755

- name: install git

package:
name: git
state: latest

roles:
- { role: [Link] }

Le playbook peut être appliqué au serveur :

[ansiblesrv] $ ansible-playbook -i hosts [Link]

Notez l’exécution des tâches suivantes :

TASK [[Link] : Ensure Apache is installed on RHEL.] ****************

TASK [[Link] : Configure Apache.] **********************************
TASK [[Link] : Add apache vhosts configuration.] *******************
TASK [[Link] : Ensure Apache has selected state and enabled on boot.] ***
RUNNING HANDLER [[Link] : restart apache] **************************

Le rôle [Link] nous facililte grandement la tâche en s’occupant de l’installation et la

configuration d’Apache.

Ansistrano | 43
FORMATUX - Support de cours GNU/Linux

Module 3 : Déployer le logiciel

Notre serveur étant maintenant configuré, nous allons pouvoir déployer l’applicatif.

Pour cela, nous allons utiliser le rôle [Link] dans un second playbook dédié au
déploiement applicatif (pour plus de lisibilité).

Exercice 3.1 : Installer le rôle ansistrano-deploy

[ansiblesrv] $ ansible-galaxy install [Link]

Exercice 3.2 : Utiliser le rôle ansistrano-deploy pour déployer le logiciel

Les sources du logiciel se trouvent dans le dépôt :

• sur framagit [Link] accessible depuis internet.

Nous allons créer un playbook [Link] pour gérer notre déploiement :

---
- hosts: ansiblecli
become: yes
vars:
dest: "/var/www/site/"
ansistrano_deploy_via: "git"
ansistrano_git_repo: [Link]
ansistrano_deploy_to: "{{ dest }}"

roles:
- { role: [Link] }

[ansiblesrv] $ ansible-playbook -i hosts [Link]

Exercice 3.3 : Visualiser le résultat dans un navigateur

Une redirection du port http a été mis en place pour accéder depuis l’extérieur à votre serveur.

• Ouvrir un navigateur web vers l’url [Link] :

44 | Ansistrano
FORMATUX - Support de cours GNU/Linux

Et voir apparaître le déploiement fonctionnel de la branche master de notre dépôt.

Exercice 3.4 : Vérification sur le serveur

• Se connecter en ssh sur le serveur client :

[ansiblesrv] $ ssh ansible@[Link]

• Faire un tree sur le repertoire /var/www/site/ :

Notez :

• le lien symbolique current vers la release ./releases/20180821070043Z

• la présence d’un dossier shared

• la présence du dépôt git dans ./repo/

Ansistrano | 45
FORMATUX - Support de cours GNU/Linux

• Depuis le serveur ansible, relancer 3 fois le déploiement, puis vérifier sur le client.

Notez :

• ansistrano a conservé les 4 dernières releases,

• le lien current pointe maintenant vers la dernière release exécutée

Module 4 : Ansistrano
Exercice 4.1 : Limiter le nombre de releases

La variable ansistrano_keep_releases permet de spécifier le nombre de releases à conserver.

• En utilisant la variable ansistrano_keep_releases, ne conserver que 3 releases du projet. Vérifier.

46 | Ansistrano
FORMATUX - Support de cours GNU/Linux

---
- hosts: ansiblecli
become: yes
vars:
dest: "/var/www/site/"
ansistrano_deploy_via: "git"
ansistrano_git_repo: [Link]
ansistrano_deploy_to: "{{ dest }}"
ansistrano_keep_releases: 3

roles:
- { role: [Link] }

---
[ansiblesrv] $ ansible-playbook -i hosts [Link]

Sur le client :

Exercice 4.2 : Utiliser des shared_paths et shared_files

Ansistrano | 47
FORMATUX - Support de cours GNU/Linux

roles:
- { role: [Link] }

Sur le client, créer le fichier logs dans le répertoire shared :

sudo touch /var/www/site/shared/logs

Puis lancer l’exécution du job :

TASK [[Link] : ANSISTRANO | Ensure shared paths targets are absent]

*******************************************************
ok: [[Link]] => (item=img)
ok: [[Link]] => (item=css)
ok: [[Link]] => (item=logs/log)

TASK [[Link] : ANSISTRANO | Create softlinks for shared paths and files]
**************************************************
changed: [[Link]] => (item=img)
changed: [[Link]] => (item=css)
changed: [[Link]] => (item=logs)

Sur le client :

48 | Ansistrano
FORMATUX - Support de cours GNU/Linux

Notez que la dernière release contient :

• Un répertoire css, un répertoire img, et un fichier logs

• Des liens symboliques :

◦ du dossier /var/www/site/releases/css/ vers le dossier ../../shared/css/.

◦ du dossier /var/www/site/releases/img/ vers le dossier ../../shared/img/.

◦ du fichier /var/www/site/releases/logs/ vers le fichier ../../shared/logs.

Dès lors, les fichiers contenus dans ces 2 dossiers et le fichier logs sont toujours accessibles via les
chemins suivants :

• /var/www/site/current/css/,

• /var/www/site/current/img/,

• /var/www/site/current/logs,

mais surtout ils seront conservés d’une release à l’autre.

Ansistrano | 49
FORMATUX - Support de cours GNU/Linux

Exercice 4.3 : Utiliser un sous répertoire du dépôt pour le déploiement

Dans notre cas, le dépôt contient un dossier html, qui contient les fichiers du site.

• Pour éviter ce niveau supplémentaire de répertoire, utiliser la variable

ansistrano_git_repo_tree en précisant le path du sous répertoire à utiliser. Ne pas oublier de
modifier la configuration d’apache pour prendre en compte ce changement !

Playbook de configuration du serveur [Link]

tasks:

- name: create directory for website

file:
path: /var/www/site/
state: directory
mode: 0755

- name: install git

package:
name: git
state: latest

roles:
- { role: [Link] }

① Modifier cette ligne

50 | Ansistrano
FORMATUX - Support de cours GNU/Linux

Playbook de déploiement [Link]

roles:
- { role: [Link] }

① Modifier cette ligne

• Vérifier sur le client :

Ansistrano | 51
FORMATUX - Support de cours GNU/Linux

① Notez l’absence du dossier html

Module 5 : La gestion des branches ou des tags git

La variable ansistrano_git_branch permet de préciser une branch ou un tag à déployer.

Exercice 5.1 : Déployer une branche

• Déployer la branche releases/v1.1.0 :

52 | Ansistrano
FORMATUX - Support de cours GNU/Linux

roles:
- { role: [Link] }

Vous pouvez vous amuser, durant le déploiement, à rafraichir votre navigateur, pour voir en 'live'
le changement s’effectuer.

Ansistrano | 53
FORMATUX - Support de cours GNU/Linux

Exercice 5.2 : Déployer un tag

• Déployer le tag v2.0.0 :

54 | Ansistrano
FORMATUX - Support de cours GNU/Linux

roles:
- { role: [Link] }

Vous pouvez vous amuser, durant le déploiement, à rafraichir votre navigateur, pour voir en 'live'
le changement s’effectuer.

Module 6 : Actions entre les étapes de déploiement

Un déploiement avec Ansistrano respecte les étapes suivantes :

• Setup
• Update Code
• Symlink Shared

Ansistrano | 55
FORMATUX - Support de cours GNU/Linux

• Symlink
• Clean Up

Il est possible d’intervenir avant et après chacune de ses étapes.

Un playbook peut être inclu par les variables prévues à cet effet :

• ansistrano_before_<task>_tasks_file

• ou ansistrano_after_<task>_tasks_file

Exercice 6.1 : Envoyer un mail en début de MEP

---
- hosts: ansiblecli
become: yes
vars:
dest: "/var/www/site/"
ansistrano_deploy_via: "git"
ansistrano_git_repo: [Link]
ansistrano_deploy_to: "{{ dest }}"
ansistrano_keep_releases: 3
ansistrano_shared_paths:
- "img"
- "css"
ansistrano_shared_files:
- "logs"
ansistrano_git_repo_tree: 'html'
ansistrano_git_branch: 'v2.0.0'
ansistrano_before_setup_tasks_file: "{{ playbook_dir }}/deploy/before-setup-
[Link]"

roles:
- { role: [Link] }

56 | Ansistrano
FORMATUX - Support de cours GNU/Linux

Le fichier deploy/[Link]

---
- name: Envoyer un mail
mail:
subject: Debut de MEP sur {{ ansible_hostname }}.
delegate_to: localhost

TASK [[Link] : include]

*************************************************************************************
included: /home/ansible/deploy/[Link] for [Link]

TASK [[Link] : Envoyer un mail]

*************************************************************************************
ok: [[Link] -> localhost]

[root] # mailx
Heirloom Mail version 12.5 7/5/10. Type ? for help.
"/var/spool/mail/root": 1 message 1 new
>N 1 root@[Link] Tue Aug 21 14:41 28/946 "Debut de MEP sur localhost."

Exercice 6.2 : Redémarrer apache en fin de MEP

Ansistrano | 57
FORMATUX - Support de cours GNU/Linux

roles:
- { role: [Link] }

Le fichier deploy/[Link]

---
- name: restart apache
service:
name: httpd
state: restarted

TASK [[Link] : include]

*************************************************************************************
included: /home/ansible/deploy/[Link] for [Link]

TASK [[Link] : restart apache]

**************************************************************************************
changed: [[Link]]

58 | Ansistrano
FORMATUX - Support de cours GNU/Linux

Ordonnanceur centralisé Rundeck

 Objectifs

 installer un serveur d’ordonnancement Rundeck ;

 créer un premier projet et une tâche simple.

Rundeck est un ordonnanceur centralisé open source (licence Apache) écrit en Java.

Depuis l’interface de Rundeck, il est possible de gérer les différents travaux (commandes ou scripts)
à exécuter sur les serveurs distants.

Fonctionnalités :

• Ordonnancement des tâches selon un scénario ;

• Exécution de scripts/tâches distantes à la demande ou de manière planifiée ;

• Notifications ;

• Interface CLI (ligne de commande) et API.

Rundeck peut être intégré aux autres outils de gestion de configuration comme Puppet, Ansible et
d’intégration continue comme Jenkins, etc.

La connexion avec les hôtes clients est gérée en SSH.

Installation
Rundeck utilisant le protocle SSH pour se connecter aux systèmes distants, un
 compte avec les droits sudo est nécessaire sur chacun des stations clientes.

• sur Debian 8 (Jessie) :

Rundeck étant écrit en Java, l’installation du JDK est nécessaire :

# apt-get install openjdk-7-jdk

Rundeck peut être téléchargé puis installé :

# wget [Link]
# dpkg -i ./[Link]

• Sur CentOS 7 :

Ordonnanceur centralisé Rundeck | 59

FORMATUX - Support de cours GNU/Linux

Rundeck étant écrit en Java, l’installation du JDK est nécessaire :

# yum install java-1.8.0

Rundeck peut être téléchargé puis installé :

# rpm -Uvh [Link]

# yum install rundeck

Configuration
Par défaut, Rundeck n’est configuré en écoute que sur l’adresse de boucle interne (localhost).

Si vous ne souhaitez pas mettre en place un proxy inverse (Apache, Nginx ou HAProxy), éditez les
fichiers /etc/rundeck/[Link] et /etc/rundeck/[Link] et remplacer
localhost par l’adresse IP du serveur, pour mettre en écoute Rundeck sur son interface réseau :

Modification du fichier /etc/rundeck/[Link]

[Link] = [Link]

Modification du fichier /etc/rundeck/[Link]

[Link]=[Link]

 Remplacer [Link] par l’adresse IP publique du serveur.

Rundeck est ensuite lancé par systemctl :

# systemctl start rundeckd

# systemctl enable rundeckd

L’interface d’administration de Rundeck est accessible depuis un navigateur internet à l’adresse

[Link]

Utiliser RunDeck
Le compte par défaut pour se connecter à l’interface web est admin (mot de passe : admin). Pensez à
changer le mot de passe le plus rapidement possible.

60 | Ordonnanceur centralisé Rundeck

FORMATUX - Support de cours GNU/Linux

Figure 4. La page d’accueil de RunDeck

Créer un projet

Un nouveau projet peut être ajouté en cliquant sur le lien Nouveau projet.

Figure 5. L’assistant de création de nouveau projet Rundeck

 Vous devez fournir au minimum un nom de projet.

Dans la section Resource Model Source, cliquer sur le bouton Edit et choisir Require File Exists `,
puis cliquer sur `Save.

Ordonnanceur centralisé Rundeck | 61

FORMATUX - Support de cours GNU/Linux

Dans la section Default Node Executor, choisir password pour l’authentification par SSH (pour une
meilleure gestion de la sécurité, l’utilisation d’une clef SSH est recommandée).

Cliquer sur Create pour créer le projet.

Créer une tâche

Le serveur est prêt à recevoir une première tâche. Cette tâche consiste en une connection SSH pour
lancer une commande distante.

• Cliquer sur Create a new job et saisir un nom pour la tâche.

Figure 6. L’assistant de création de tâche de RunDeck

Il va falloir fournir à RunDeck le mot de passe de l’utilisateur distant permettant de se connecter au

serveur ainsi que le mot de passe sudo pour lancer la commande. Pour cela :

• Ajouter une option

Cliquer sur Add New Option.

62 | Ordonnanceur centralisé Rundeck

FORMATUX - Support de cours GNU/Linux

Donner un nom pour l’option (par exemple sshPassword) et une valeur par défaut qui correspond à
votre mot de passe.

Dans le champ Input Type, choisir Secure Remote Authentication et mettre Required à Yes.

Répéter l’opération avec l’option sudoPassword.

Dans la section Add a Step, choisir Command. Fournir la commande dans le champ Command. Par
exemple :

sudo "top -b -n 1 | head -n 5"

Cliquer sur Save puis Create pour finaliser la nouvelle tâche.

Pour appliquer cette tâche à un système distant (appelé noeud), éditer le fichier de configuration du
noeud :

vi /var/rundeck/projects/your_project_name/etc/[Link]

Ajouter à la ligne commençant par localhost : ssh-authentication="password" ssh-password-

option="[Link]" sudo-command-enabled="true" sudo-password-
option="[Link]", pour activer l’authentification par SSH et fournir les valeurs des
options pour l’authentification.

Retourner dans l’interface web est executer la tâche.

Ordonnanceur centralisé Rundeck | 63

FORMATUX - Support de cours GNU/Linux

Le serveur RunDeck est prêt à recevoir vos projets d’ordonnancement.

64 | Ordonnanceur centralisé Rundeck

FORMATUX - Support de cours GNU/Linux

Serveur d’Intégration Continue Jenkins

 Objectifs

 installer un serveur d’intégration continue Jenkins ;

 configurer l’accès au service par un mandataire proxy inverse ;
 sécuriser les accès au service ;
 créer une première tâche simple.

Jenkins est un outil Open Source d'intégration continue écrit en Java.

Interfacé avec des systèmes de gestion de version tel que Git, Subversion etc., il peut être utilisé
pour compiler, tester et déployer des scripts shell ou des projets Ant, Maven, etc, selon des
planifications ou des requêtes à des URLs.

Le principe de l’intégration continue est de vérifier, idéalement à chaque modification du code, la

non-régression sur l’application des modifications apportées. Cette vérification systématique est
primordiale pour une équipe de développeur : le projet est stable tout au long du développement et
peut être livré à tout moment.

Le code source de l’application doit être :

• partagé avec un système de gestion versions ;

• testé automatiquement ;

• les modifications doivent être poussées régulièrement.

Ainsi, les problèmes d’intégrations peuvent être corrigés au plus tôt et la dernière version stable de
l’application est connue.

Installation
Jenkins peut fonctionner :

• en mode standalone : avec le serveur web intégré ;

• en tant que servlet : avec le serveur applicatif tomcat.

En mode standalone

Installation de Jenkins :

• Sous debian :

Installation de la clé et ajout du dépot dans /etc/apt/[Link] :

Serveur d’Intégration Continue Jenkins | 65

FORMATUX - Support de cours GNU/Linux

# wget -q -O - [Link] | # sudo apt-key add -

# deb [Link] binary/

Installation :

# apt-get update
# apt-get install jenkins

• Sous RedHat :

Installation du dépôt et ajout de la clé GPG :

# wget -O /etc/[Link].d/[Link] [Link]

# sudo rpm --import [Link]

Installation du paquet :

# yum update
# yum install java-1.8.0-openjdk jenkins

Jenkins peut maintenant être démarré :

# systemctl start jenkins

# systemctl enable jenkins

Jenkins est directement accessible à l’adressse :

• [Link]

En tant que servlet tomcat

Installation de tomcat :

• Sous debian :

apt-get install tomcat

• Sous redhat :

66 | Serveur d’Intégration Continue Jenkins

FORMATUX - Support de cours GNU/Linux

yum install java-1.8.0-openjdk tomcat

Téléchargement de l’application :

cd /var/lib/tomcat6/webapps
wget [Link]

Si tomcat est en cours de fonctionnement, l’application sera automatiquement déployée, sinon

lancer/relancer tomcat.

Jenkins est accessible à l’adressse :

• [Link]

Installer Nginx
Un proxy inverse Nginx (mais Apache ou HAproxy sont de bonnes alternatives) va permettre
d’accéder à l’application sur le port standard 80.

# yum -y install epel-release

# yum -y install nginx
# systemctl enable nginx

Créer un nouveau serveur dans la configuration de Nginx :

Serveur d’Intégration Continue Jenkins | 67

FORMATUX - Support de cours GNU/Linux

# vim /etc/nginx/conf.d/[Link]
upstream jenkins{
server [Link]:8080;
}

server{
listen 80;
server_name [Link];

access_log /var/log/nginx/[Link];
error_log /var/log/nginx/[Link];

proxy_buffers 16 64k;
proxy_buffer_size 128k;

location / {
proxy_pass [Link]
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503
http_504;
proxy_redirect off;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}

Lancer le serveur Nginx :

# systemctl start nginx

# systemctl enable nginx

Vous pouvez alternativement installer un proxy inversé Apache. Dans ce cas, le VHOST suivant
pourra être utilisé :

68 | Serveur d’Intégration Continue Jenkins

FORMATUX - Support de cours GNU/Linux

<Virtualhost *:80>
ServerName [Link]
ProxyRequests Off
ProxyPreserveHost On
AllowEncodedSlashes NoDecode

ProxyPass / [Link] nocanon

ProxyPassReverse / [Link]
ProxyPassReverse / [Link]
</Virtualhost>

Ouvrir les ports du parefeu :

• Sur un serveur en standalone sans proxy-inverse ou sous tomcat :

# firewall-cmd --zone=public --add-port=8080/tcp --permanent

Sur un serveur avec proxy inverse :

# firewall-cmd --zone=public --add-service=http --permanent

# firewall-cmd --reload

Autoriser Nginx à se connecter au serveur Jenkins d’un point de vue SELinux :

# setsebool httpd_can_network_connect 1 -P

Configuration de Jenkins
L’interface de gestion web du serveur d’intégration continue Jenkins est accessible à l’adresse
[Link] si le proxy inverse a été configuré ou à l’adresse
[Link] dans les autres cas.

La page par défaut suivante s’affiche :

Serveur d’Intégration Continue Jenkins | 69

FORMATUX - Support de cours GNU/Linux

Cette page demande un mot de passe admin initial, qui a été généré lors de l’installation et qui est
stocké dans le fichier /var/lib/jenkins/secrets/initialAdminPassword.

cat /var/lib/jenkins/secrets/initialAdminPassword

Utiliser le mot de passe pour ce connecter à l’interface de gestion.

L’assistant va ensuite demander quels plugins doivent être installés et proposer l’installation des
plugins suggérés.

70 | Serveur d’Intégration Continue Jenkins

FORMATUX - Support de cours GNU/Linux

En choisissant Installer les plugins suggérés, tous les plugins nécessaire pour bien commencer
seront installés :

L’étape suivante consiste à créer un utilisateur avec les droits d’administration pour l’accès à la

Serveur d’Intégration Continue Jenkins | 71

FORMATUX - Support de cours GNU/Linux

console de gestion :

La configuration terminée, la console de gestion s’affiche :

La sécurité et la gestion des utilisateurs

Depuis l’interface de gestion, configurer les options de sécurité de Jenkins : cliquer sur Manage

72 | Serveur d’Intégration Continue Jenkins

FORMATUX - Support de cours GNU/Linux

Jenkins, puis Configure Global Security.

Plusieurs méthodes d’autorisations peuvent être utilisées. En sélectionnant Matrix-based Security,

les droits des utilisateurs peuvent être gérés plus finement. Activer l’utilisateur admin et cliquer sur
Add. Lui donner tous les droits en sélectionnant toutes les options. Donner à l’utilisateur anonymous
uniquement les droits de lecture (read). Ne pas oublier de cliquer sur Save.

Ajouter une tâche d’automatisation simple

Dans l’interface de gestion, cliquer sur Create new jobs.

Saisir un nom pour la tâche, par exemple test. Choisir Freestyle Project et cliquer sur OK.

Serveur d’Intégration Continue Jenkins | 73

FORMATUX - Support de cours GNU/Linux

Aller dans l’onglet Build. Dans Add build step, selectionner l’option Execute shell.

Saisir la commande suivante dans le champ texte :

top -b -n 1 | head -n 5

Cliquer sur Save.

Dans la page dédiée à la tâche test, cliquer sur Build Now pour executer la tâche test.

Une fois que la tâche a été executée, vous verrez l’historique du Build. Cliquer sur la première tâche

74 | Serveur d’Intégration Continue Jenkins

FORMATUX - Support de cours GNU/Linux

pour visualiser les résultats.

Sources
Source principale : howtoforge.

Serveur d’Intégration Continue Jenkins | 75

FORMATUX - Support de cours GNU/Linux

Asciidoc : Docs as Code

Introduction
La Document as Code (Docs as Code) est une philosophie de rédaction documentaire.

Pour favoriser la rédaction de documentations de qualité, les mêmes outils que ceux utilisés pour
coder sont utilisés :

• gestionnaire de bugs,

• gestionnaire de version (git),

• revue de code,

• tests automatiques.

Plusieurs langages de balisage légers répondant à ces besoins sont apparus :

• le Markdown,

• le reStructuredText,

• l’Asciidoc.

Le contenu avant la forme

Les avantages d’un tel dispositif sont nombreux :

• Le rédacteur se concentre uniquement sur le contenu et non sur la mise en forme comme c’est
malheureusement trop souvent le cas avec les éditeurs de texte WYSIWYG (openoffice, word,
etc.),

• Le même code source permet de générer des formats différents : pdf, html, word, confluence,
epub, manpage, etc.

• Le travail collaboratif est grandement simplifié : code review, merge request, etc.

• Gestion des versions par branches ou tags git (pas une copie de fichier .doc).

• Edition de la documentation accessible à tous avec un simple éditeur de texte puisque la

documentation est composée de fichiers plats (texte).

Le format asciidoc
Ce langage de balisage léger a été créé en 2002 !

Le processeur initial était développé en python mais à depuis été réécrit en ruby
([Link]

La syntaxe asciidoc a eu du mal à percer au bénéfice du markdown, mais sa grande lisibilité et le

76 | Asciidoc : Docs as Code

FORMATUX - Support de cours GNU/Linux

lead de Dan Allen ([Link] lui permettent de rattraper aujourd’hui son

retard.

Voici un petit exemple de source asciidoc :

= Hello, AsciiDoc!
Doc Writer <doc@[Link]>

An introduction to [Link]

== First Section

* item 1
* item 2

Comme vous pouvez le constater, le texte (malgré le balisage) reste lisible, la syntaxe est facilement
assimilable et n’est pas trop lourde comparée à ce qui se faisait en latex.

Use AsciiDoc for document markup. Really. It’s actually readable by

humans, easier to parse and way more flexible than XML.

— Linus Torvalds

Une page référence les possibilités de la syntaxe asciidoc :

• [Link]

Compiler sa documentation

La documentation d’installation est disponible ici : [Link]

 install-toolchain/.

Comme pour un programme, la documentation nécessite une phase de compilation.

Après avoir installé l’environnement asciidoc, la commande suivante permet de compiler son
document .adoc en html5 (format par défaut) :

asciidoctor [Link]

Une image docker existant, il est facile d’utiliser la CI d’un environnement tel que GitLab pour
générer automatiquement la documentation à chaque commit, tag, etc.

Asciidoc : Docs as Code | 77

FORMATUX - Support de cours GNU/Linux

build:
stage: build
image: asciidoctor/docker-asciidoctor
script:
- asciidoctor-pdf -a icons="font" -a lang="fr" -D public [Link]
only:
- master
artifacts:
name: "compilation-pdf"
paths:
- public/

Une proposition d’environnement de travail

Atom ([Link] est un éditeur de code.

Après avoir installé Atom en suivant cette documentation : [Link]

started/sections/installing-atom/, activer les packages suivants :

• asciidoc-image-helper
• asciidoc-assistant
• asciidoc-preview
• autocomplete-asciidoc
• language-asciidoc

Références
• [Link]

• [Link]

78 | Asciidoc : Docs as Code

FORMATUX - Support de cours GNU/Linux

Terraform : Infrastructure as Code

Introduction
Terraform est un produit de la société HashiCorp (Terraform, Vault, Consul, Packer, Vagrant),
permettant de :

• décrire dans un langage humainement compréhensible l’infrastructure cible : la HCL (

HashiCorp Configuration Language),

• versionner les changements,

• planifier le déploiement,

• créer l’infrastructure.

Les changements apportés par une modification de code à l’infrastructure sont prédictifs.

If it can be codified, it can be automated.

Le même outil permet de créer des ressources chez les plus grands fournisseurs d’infrastructure :

• AWS,

• GCP,

• Azure,

• OpenStack,

• VMware,

• etc.

L’infrastructure devient reproductible (intégration ⇒ preproduction ⇒ production) et facilement

scalable. Les erreurs de manipulations humaines sont réduites.

Un exemple de création de ressouces :

Terraform : Infrastructure as Code | 79

FORMATUX - Support de cours GNU/Linux

# Une machine virtuelle

resource "digitalocean_droplet" "web" {
name = "tf-web"
size = "512mb"
image = "centos-7-5-x86"
region = "sfo1"
}

/* Un enregistrement DNS
en IPV4 type "A"
*/
resource "dnsimple_record" "hello" {
domain = "[Link]"
name = "test"
value = "${digitalocean_droplet.web.ipv4_address}"
type = "A"
}

Retrouvez plus d’informations sur le site [Link] dans la

 documentation [Link] et dans l’espace de
formation [Link]

La HCL
Le langage HashiCorp Configuration Language est spécifique. Voici quelques points d’attention :

• Les commentaires sur une seule ligne commencent avec un #

• Les commentaires sur plusieurs lignes sont encadrés par /* et */

• Les variables sont assignées avec la syntaxe key = value (aucune importance concernant les
espaces). Les valeurs peuvent être des primitives string, number ou boolean ou encore une list
ou une map.

• Les chaînes de caractères sont encadrées par des doubles-quotes.

• Les valeurs booléennes peuvent être true ou false.

Les providers
Terraform est utilisé pour gérer des ressources qui peuvent être des serveurs physiques, des VM,
des équipements réseaux, des containeurs, mais aussi pourquoi pas des utilisateurs grafana, etc.

La liste des providers disponibles est consultable ici : [Link]

[Link].

En voici quelques-uns :

80 | Terraform : Infrastructure as Code

FORMATUX - Support de cours GNU/Linux

• AWS,

• Azure,

• VMware vSphere

• OpenStack, CloudStack, OVH, DigitalOcean, etc.

• Gitlab,

• Datadog, PagerDuty,

• MySQL,

• Active Directory

• …

Chaque provider venant avec ses propres ressources, il faut lire la doc !

Les actions
• terraform init

La première commande à lancer pour une nouvelle configuration qui va initialiser la configuration
locale (import de modules par exemple).

La commande terraform init va automatiquement télécharger et installer les binaires des

providers nécessaires.

• terraform plan

La commande terraform plan permet d’afficher le plan d’exécution, qui décrit quelles actions
Terraform va prendre pour effectuer les changements réels de l’infrastructure.

Si une valeur est affichée comme <computed>, cela veut dire que cette valeur ne sera connue qu’au
moment de l’exécution du plan.

• terraform apply

La commande terraform apply va réellement appliquer les changements tels qu’ils ont été décrits
par la commande terraform plan.

• terraform show

La commande terraform show permet d’afficher l’état courant de l’infrastructure.

Une fois que l’infrastructure est gérée via Terraform, il est préférable d’éviter de la
 modifier manuellement.

Terraform va inscrire des données importantes dans un fichier [Link]. Ce fichier va

stocker les ID des ressources créées de façon à savoir quelles ressources sont gérées par Terraform,
et lesquelles ne le sont pas. Ce fichier doit donc à son tour être conservé et partagé avec toutes les

Terraform : Infrastructure as Code | 81

FORMATUX - Support de cours GNU/Linux

personnes devant intervenir sur la configuration.

Ce fichier [Link] contient des données sensibles. Il doit donc être

 partagé mais de manière sécurisée (des modules existent), éventuellement ailleurs
que dans le repo du code de l’infrastructure.

Des ressources déjà existantes peuvent être importées avec la commande

 terraform import [Link] id_existant.

• terraform destroy

Avec l’avènement du cloud, le cycle de vie d’un serveur et notre façon de consommer les ressources
ont considérablement changé. Une VM ou une infrastructure doit tout aussi facilement pouvoir être
créée que supprimée.

Avec Terraform, une infrastructure complète peut être déployée juste à l’occasion des tests de non
régréssion lors de la création d’une nouvelle version logicielle par exemple et être totalement
détruite à la fin de ceux-ci pour réduire les coûts d’infrastructure au plus juste.

La commande terraform destroy est similaire à la commande terraform apply.

Dépendances des ressources

Lorsqu’une ressource dépend d’une autre ressource, la ressource parent peut être appelée comme
ceci :

# Le VPC de la plateforme
resource "cloudstack_vpc" "default" {
name = "our-vpc"
cidr = "[Link]/16"
vpc_offering = "Default VPC offering"
zone = "EU-FR-IKDC2-Z4-ADV"
}

# Un réseau en [Link]/24 attaché à notre VPC

resource "cloudstack_network" "default" {
name = "our-network"
cidr = "[Link]/24"
network_offering = "Isolated VPC tier (100MBps) with SourceNAT and StaticNAT"
zone = "EU-FR-IKDC2-Z4-ADV"
vpc_id = "${cloudstack_vpc.[Link]}"
}

Dans l’exemple ci-dessus, un VPC (Virtual Private Cloud) est créé ainsi qu’un réseau privé. Ce réseau
privé est rattaché à son VPC en lui fournissant son id connu dans terraform en tant que
${cloudstack_vpc.[Link]} où :

82 | Terraform : Infrastructure as Code

FORMATUX - Support de cours GNU/Linux

• cloudstack_vpc est le type de ressource,

• default est le nom de la ressource,

• id est l’attribut exporté de la ressource.

Les informations de dépendances déterminent l’ordre dans lequel Terraform va créer les
ressources.

Les provisionners
Les provisionners permettent d’initialiser les instances une fois qu’elles ont été créées (lancer un
playbook ansible par exemple).

Afin de mieux comprendre l’utilité d’un provisionner, étudiez l’exemple ci-dessous :

resource "aws_instance" "example" {

ami = "ami-b374d5a5"
instance_type = "[Link]"

provisioner "local-exec" {
command = "echo ${aws_instance.example.public_ip} > ip_address.txt"
}
}

Lors de la création de la nouvelle VM, son adresse IP publique est stockée dans un fichier
ip_address.txt, mais elle aurait très bien pu être envoyée à la CMDB par exemple.

Le provisioner local-exec exécute une commande localement, mais il existe de nombreux autres
provisionners : [Link]

Les variables
Une variable est définie comme suit :

# variable de type string

variable "region" {
default = "us-east-1"
}

# variable de type list

# definition implicite
variable "cidrs" { default = [] }

# definition explicite
variable "cidrs" { type = "list" }

Terraform : Infrastructure as Code | 83

FORMATUX - Support de cours GNU/Linux

Pour ensuite être utilisée comme suit :

provider "aws" {
access_key = "${var.access_key}"
secret_key = "${var.secret_key}"
region = "${[Link]}"
}

Vous pouvez stocker vos variables dans un fichier externe (par exemple
 [Link]) sachant que tous fichiers ayant pour extension .tf du répertoire
courant seront chargés.

L’exemple du chapitre précédent peut être repris pour variabiliser la zone de déploiement de nos
ressources :

# La zone de deploiement cible

variable "zone" {
default = "EU-FR-IKDC2-Z4-ADV"
}

# Le VPC de la plateforme
resource "cloudstack_vpc" "default" {
name = "our-vpc"
cidr = "[Link]/16"
vpc_offering = "Default VPC offering"
zone = "${[Link]}"
}

# Un réseau en [Link]/24 attaché à notre VPC

resource "cloudstack_network" "default" {
name = "our-network"
cidr = "[Link]/24"
network_offering = "Isolated VPC tier (100MBps) with SourceNAT and StaticNAT"
zone = "${[Link]}"
vpc_id = "${cloudstack_vpc.[Link]}"
}

Les variables peuvent être également définies depuis la ligne de commande ou un fichier externe
[Link] qui sera chargé automatiquement à l’exécution.

Il est d’usage de stocker les variables critiques (api key, mots de passe, etc.) dans un
 fichier [Link] et d’exclure ce fichier de votre configuration git.

Voir la documentation pour plus d’informations sur les variables (Maps, etc.) :
 [Link]

84 | Terraform : Infrastructure as Code

FORMATUX - Support de cours GNU/Linux

TD
Plusieurs possibilités :

• Créer un compte gratuit chez AWS puis :

◦ Suivre le module getting-started d’hashicorp : [Link]

getting-started/install

◦ Créer votre propre infrastructure sur AWS.

• Créer un compte chez Ikoula et gérer une infrastructure CloudStack

([Link]

• Piloter votre infrastructure VMWare.

• Installer grafana ou un autre logiciel disposant d’un provider sur une de vos VM et utiliser les
ressources de ce provider.

Terraform : Infrastructure as Code | 85

FORMATUX - Support de cours GNU/Linux

Glossaire
BASH
Bourne Again SHell

BIOS
Basic Input Output System

CIDR
Classless Inter-Domain Routing

Daemon
Disk And Execution MONitor

DHCP
Dynamic Host Control Protocol

DNS
Domain Name Service

FIFO
First In First Out

FQDN
Fully Qualified Domain Name

GNU
Gnu is Not Unix

HA
High Availability (Haute Disponibilité)

HTTP
HyperText Transfer Protocol

ICP
Internet Cache Protocol

IFS
Internal Field Separator

LAN
Local Area Network

LDIF

86 | Glossaire
FORMATUX - Support de cours GNU/Linux

LDAP Data Interchange Format

NTP
Network Time Protocol

nsswitch
Name Service Switch

OTP
One Time Password

POSIX
Portable Operating System Interface

POST
Power On Self Test

RDBMS
Relational DataBase Managed System

SGBD-R
Systèmes de Gestion de Base de Données Relationnelles

SHELL
En français "coquille". Á traduire par "interface système".

SMB
Server Message Block

SMTP
Simple Mail Tranfer Protocol

SSH
Secure SHell

SSL
Secure Socket Layer

TLS
Transport Layer Security, un protocole de cryptographie pour sécuriser les communications IP.

TTL
Time To Live

TTY
teletypewriter, qui se traduit téléscripteur. C’est la console physique.

Glossaire | 87
FORMATUX - Support de cours GNU/Linux

UEFI
Unified Extensible Firmware Interface

88 | Glossaire
FORMATUX - Support de cours GNU/Linux

Index
A
augeas, 13

D
devops, 3

H
HCL, 79

J
Jenkins, 65

P
puppet, 6

R
Rundeck, 59

Index | 89

Vous aimerez peut-être aussi

Formatux Services
Pas encore d'évaluation
Formatux Services
256 pages
Alphorm 131111141511 Phpapp01
100% (1)
Alphorm 131111141511 Phpapp01
739 pages
Architecture SOA et Web Services
Pas encore d'évaluation
Architecture SOA et Web Services
5 pages
Formation DevOps : Docker et Kubernetes
Pas encore d'évaluation
Formation DevOps : Docker et Kubernetes
31 pages
TP DEVOPS Chaîne de Déploiement (Docker, Jenkins, Etc.) (Introduction) Une Chaîne de Déploiement Automatisé Pour Les Développeurs
Pas encore d'évaluation
TP DEVOPS Chaîne de Déploiement (Docker, Jenkins, Etc.) (Introduction) Une Chaîne de Déploiement Automatisé Pour Les Développeurs
25 pages
WebUIGuide KubernetesAdmin
Pas encore d'évaluation
WebUIGuide KubernetesAdmin
125 pages
Formation PHP5 et MVC pour Microservices
Pas encore d'évaluation
Formation PHP5 et MVC pour Microservices
44 pages
Projet Virtualisation Ouassine Elkhabich Lotfi Bougraine Raouzi
Pas encore d'évaluation
Projet Virtualisation Ouassine Elkhabich Lotfi Bougraine Raouzi
33 pages
Azure
Pas encore d'évaluation
Azure
5 pages
Installation de Windows Server 2012R2
Pas encore d'évaluation
Installation de Windows Server 2012R2
36 pages
Alphorm 160311113619
100% (1)
Alphorm 160311113619
221 pages
Pratique de .NET 2.0 Et C# 2.0
Pas encore d'évaluation
Pratique de .NET 2.0 Et C# 2.0
1 068 pages
Guide Référencement Virtualisation VMware
Pas encore d'évaluation
Guide Référencement Virtualisation VMware
4 pages
K8S 2122 Rattrapage V2
Pas encore d'évaluation
K8S 2122 Rattrapage V2
6 pages
M20462 Formation Administrer Une Base de Donnees Microsoft SQL Server 2014 PDF
Pas encore d'évaluation
M20462 Formation Administrer Une Base de Donnees Microsoft SQL Server 2014 PDF
2 pages
(Torrent911.Org) Windows and Internet Pratique - Juillet-Ao T 2022
100% (1)
(Torrent911.Org) Windows and Internet Pratique - Juillet-Ao T 2022
76 pages
Procédure WSUS
100% (1)
Procédure WSUS
18 pages
Protocoles AAA : Concepts et Implémentations
100% (1)
Protocoles AAA : Concepts et Implémentations
28 pages
Conteneurisation avec Docker en MSA
Pas encore d'évaluation
Conteneurisation avec Docker en MSA
22 pages
08-Déploiement Et Gestion Des Conteneurs Windows Et Hyper-V
Pas encore d'évaluation
08-Déploiement Et Gestion Des Conteneurs Windows Et Hyper-V
23 pages
Solutions libres de virtualisation PME
Pas encore d'évaluation
Solutions libres de virtualisation PME
98 pages
Ubanisation Des SI IT 5 Version 30062022
Pas encore d'évaluation
Ubanisation Des SI IT 5 Version 30062022
174 pages
Azure Arm
Pas encore d'évaluation
Azure Arm
404 pages
Leçon 1
100% (1)
Leçon 1
13 pages
Réussir l'examen AZ-900 Azure
Pas encore d'évaluation
Réussir l'examen AZ-900 Azure
11 pages
Rollback pour petites équipes DSI
Pas encore d'évaluation
Rollback pour petites équipes DSI
224 pages
SLAM2 - 02-1 Cours GIT
Pas encore d'évaluation
SLAM2 - 02-1 Cours GIT
15 pages
ABL Cloud
100% (1)
ABL Cloud
9 pages
Installation Administration Guide S
Pas encore d'évaluation
Installation Administration Guide S
528 pages
Google Cloud Computing
50% (2)
Google Cloud Computing
3 pages
Sécurité Réseau : Firewalls et ACL
Pas encore d'évaluation
Sécurité Réseau : Firewalls et ACL
69 pages
App Web Angular7 Springboot2 PDF
Pas encore d'évaluation
App Web Angular7 Springboot2 PDF
51 pages
Web Dev Déploiement
Pas encore d'évaluation
Web Dev Déploiement
90 pages
Formation Administration Oracle 19c-21c
Pas encore d'évaluation
Formation Administration Oracle 19c-21c
5 pages
Certification LPIC-2 : Administration Linux
Pas encore d'évaluation
Certification LPIC-2 : Administration Linux
563 pages
Web Dev Déploiement
Pas encore d'évaluation
Web Dev Déploiement
82 pages
Installer Terraform sur Linux et Windows
Pas encore d'évaluation
Installer Terraform sur Linux et Windows
17 pages
Évaluation de Variables en Informatique
Pas encore d'évaluation
Évaluation de Variables en Informatique
3 pages
Installation Odoo 17 sur Ubuntu 20.04
Pas encore d'évaluation
Installation Odoo 17 sur Ubuntu 20.04
9 pages
Introduction à Docker Swarm
Pas encore d'évaluation
Introduction à Docker Swarm
35 pages
FLEXlm Setup Guide FR
Pas encore d'évaluation
FLEXlm Setup Guide FR
9 pages
Installation Docker et Virtualisation Windows 10
Pas encore d'évaluation
Installation Docker et Virtualisation Windows 10
29 pages
Ejb JSF Struts Flex Jasper
Pas encore d'évaluation
Ejb JSF Struts Flex Jasper
439 pages
Créer une application cloud native
Pas encore d'évaluation
Créer une application cloud native
16 pages
Cours ASP - Net v2011
Pas encore d'évaluation
Cours ASP - Net v2011
79 pages
Cours Web Mobile Flutter
100% (1)
Cours Web Mobile Flutter
3 pages
Radius Vid2 - Bon01
Pas encore d'évaluation
Radius Vid2 - Bon01
8 pages
TP Conteneur
Pas encore d'évaluation
TP Conteneur
5 pages
Sécurité Vsphere - VMware Vsphere 6.7
Pas encore d'évaluation
Sécurité Vsphere - VMware Vsphere 6.7
334 pages
Base de Donnees Distribue
Pas encore d'évaluation
Base de Donnees Distribue
61 pages
Fiche de La Formation KVM
Pas encore d'évaluation
Fiche de La Formation KVM
4 pages
SME Server
100% (1)
SME Server
77 pages
Sauvegarde SQL Server : Guide Complet
Pas encore d'évaluation
Sauvegarde SQL Server : Guide Complet
33 pages
Formatux Devops
Pas encore d'évaluation
Formatux Devops
125 pages
SupportLinux Admin
Pas encore d'évaluation
SupportLinux Admin
225 pages
Handbook FR
Pas encore d'évaluation
Handbook FR
868 pages
Git Guide Utilisation
Pas encore d'évaluation
Git Guide Utilisation
119 pages
Formatux Maformationlinux
100% (1)
Formatux Maformationlinux
680 pages
Configuration Serveur Internet
Pas encore d'évaluation
Configuration Serveur Internet
22 pages
Préparation À La Certification LPIC-2
0% (1)
Préparation À La Certification LPIC-2
26 pages
KVM PDF
Pas encore d'évaluation
KVM PDF
71 pages
Activité Configuration Serveur DNS PDF
Pas encore d'évaluation
Activité Configuration Serveur DNS PDF
2 pages
Git FR PDF
100% (2)
Git FR PDF
240 pages
KVM PDF
Pas encore d'évaluation
KVM PDF
71 pages
Algorithme Algobox-Fonctions-Base PDF
100% (1)
Algorithme Algobox-Fonctions-Base PDF
3 pages
Ansible FR PDF
Pas encore d'évaluation
Ansible FR PDF
70 pages
TP OpenLDAP Sur Centos 6.5
Pas encore d'évaluation
TP OpenLDAP Sur Centos 6.5
6 pages
Support Cours VSphere 6 Install Configure Et Manage
100% (1)
Support Cours VSphere 6 Install Configure Et Manage
99 pages
Cracked 6741AK-FR - Configuration Et Dépannage Dune Infrastructure Réseau Windows Server 2008-TrainerHandbook - Ateliers - 02
Pas encore d'évaluation
Cracked 6741AK-FR - Configuration Et Dépannage Dune Infrastructure Réseau Windows Server 2008-TrainerHandbook - Ateliers - 02
174 pages
Cluster Apache Haute Disponibilité Avec Pacemaker (Centos 7)
Pas encore d'évaluation
Cluster Apache Haute Disponibilité Avec Pacemaker (Centos 7)
9 pages
Cracked 10224A-FRE - Installation Et Configuration Du Client Windows 7-TrainerHandbook - 02
50% (2)
Cracked 10224A-FRE - Installation Et Configuration Du Client Windows 7-TrainerHandbook - 02
412 pages
Installation et Configuration Apache
Pas encore d'évaluation
Installation et Configuration Apache
4 pages
Eveil Politique
Pas encore d'évaluation
Eveil Politique
62 pages
D'automatisation Avec Ansible Mise en Place de Serveurs Web
Pas encore d'évaluation
D'automatisation Avec Ansible Mise en Place de Serveurs Web
26 pages
Rapport Admin Linux Avancee Grp1
Pas encore d'évaluation
Rapport Admin Linux Avancee Grp1
25 pages
TP: Fonctionnalités Avancées D'ansible: P. Martini
Pas encore d'évaluation
TP: Fonctionnalités Avancées D'ansible: P. Martini
38 pages
Introduction à Ansible : Automatisation Simplifiée
Pas encore d'évaluation
Introduction à Ansible : Automatisation Simplifiée
69 pages
Automatisation de La Configuration Reseau Avec Ansible Et Nornir
Pas encore d'évaluation
Automatisation de La Configuration Reseau Avec Ansible Et Nornir
8 pages
Automatiser Les Réseaux
Pas encore d'évaluation
Automatiser Les Réseaux
17 pages
Exposer
Pas encore d'évaluation
Exposer
10 pages
Chapitre 2 Etat de Lart 2122
Pas encore d'évaluation
Chapitre 2 Etat de Lart 2122
18 pages
Ansibleuvrage
Pas encore d'évaluation
Ansibleuvrage
159 pages
Examen Sur La Programmation Des Architectures
Pas encore d'évaluation
Examen Sur La Programmation Des Architectures
116 pages
CheatSheet DevOps
Pas encore d'évaluation
CheatSheet DevOps
6 pages
Présentation 2
Pas encore d'évaluation
Présentation 2
13 pages
Ansible, Automatiser La Gestion Des Serveurs
Pas encore d'évaluation
Ansible, Automatiser La Gestion Des Serveurs
3 pages
Automatisation Réseau Avec Ansible
Pas encore d'évaluation
Automatisation Réseau Avec Ansible
17 pages
1 Intro Ansible
Pas encore d'évaluation
1 Intro Ansible
29 pages
Manus Wsus Comparison Opsi Wapt Ansible
Pas encore d'évaluation
Manus Wsus Comparison Opsi Wapt Ansible
16 pages
Udemy - Ansible Network & Windows Mastery 2023 FR Web 720P X264 MP4
Pas encore d'évaluation
Udemy - Ansible Network & Windows Mastery 2023 FR Web 720P X264 MP4
3 pages
Automatisation Avec Ansible
Pas encore d'évaluation
Automatisation Avec Ansible
31 pages
Automatisation Avec Ansible Et PBS 1744043961
Pas encore d'évaluation
Automatisation Avec Ansible Et PBS 1744043961
14 pages
Ansible : Automatisation DevOps Simplifiée
Pas encore d'évaluation
Ansible : Automatisation DevOps Simplifiée
16 pages
Support ANSIBLE Complet
Pas encore d'évaluation
Support ANSIBLE Complet
179 pages