Skip to main content

Installation & utilisation d'Ansible

Installation de l'environnement virtuel python

Création de l'utilisateur d'ansible :

adduser user-ansible

Installation de l'environnement virtuel python : 

apt-get install python-virtualenv sshpass

sshpass sert au bon fonctionnement de la suite !

Changement d'utilisateur : 

su - user-ansible

Lancement de l'environnement virtuel : 

virtualenv ansible4.6.0

Activation de l'environnement virtuel : 

source ansible4.6.0/bin/activate

Installation d'ansible

Installation d'ansible : 

pip install ansible==4.6.0

Est-ce que ansible est bien installé ?

ansible --version

image-1633383044412.png

Préparation de la communication avec les nodes

Définition des nodes :

Création du fichier de définition des nodes :

nano inventaire.ini
http1
bdd1

Modification de notre fichier host : 

nano /etc/hosts

On ajoute : 

# le node http1
34.88.193.243 http1
# le node bdd1
35.228.198.62 bdd1

Test du bon fonctionnement SSH des nodes :

ssh root@http1
ssh root@bdd1
Réalisation de pings sur nos nœuds : 
ansible -i inventaire.ini -m ping http1 --user root --ask-pass
ansible -i inventaire.ini -m ping bdd1 --user root --ask-pass

image-1633442685680.png

image-1633442696209.png

Installation de python à distance sur nos nœuds : 
ansible -i inventaire.ini -m raw -a "yum install -y python3" http1 --user root --ask-pass
ansible -i inventaire.ini -m raw -a "yum install -y python3" bdd1 --user root --ask-pass

Résultat :

image-1633385833649.png

Génération d'une chaine SHA-512 :
ansible localhost -i inventaire.ini -m debug -a "msg={{ 'passforce' | password_hash('sha512', 'sceretsalt') }}"

Le mot de passe pour l'utilisateur user-ansible est donc "passforce", choisissez-en un différent !

Résultat  :
localhost | SUCCESS => {
    "msg": "$6$sceretsalt$tBcfGEgifQpQZsg5CIGZ79XC55h5vHy7UWrys7cAF37KNCQQbm7iCvy58MlLQLaS2fLF6ZjqDVHhVrkMdRi0f0"
}

Notre clef SHA-512 a bien été générée !

Création d'un utilisateur nommé "ansible" sur tous les nodes : 
ansible -i inventaire.ini -m user -a 'name=user-ansible password=$6$sceretsalt$tBcfGEgifQpQZsg5CIGZ79XC55h5vHy7UWrys7cAF37KNCQQbm7iCvy58MlLQLaS2fLF6ZjqDVHhVrkMdRi0f0' --user root --ask-pass http1
ansible -i inventaire.ini -m user -a 'name=user-ansible password=$6$sceretsalt$tBcfGEgifQpQZsg5CIGZ79XC55h5vHy7UWrys7cAF37KNCQQbm7iCvy58MlLQLaS2fLF6ZjqDVHhVrkMdRi0f0' --user root --ask-pass bdd1

Résultat : 

image-1633442774848.png

image-1633442802700.png

Mettez évidement votre chaine à vous !

 

Ajout des droits de sudoers à nos nouveaux utilisateurs : 

ansible -i inventaire.ini -m user -a 'name=user-ansible groups=wheel append=yes ' --user root --ask-pass http1
ansible -i inventaire.ini -m user -a 'name=user-ansible groups=wheel append=yes ' --user root --ask-pass bdd1

image-1633443099352.png

Nos deux utilisateurs sont maintenant sudoers ! 

 

Nous vérifions maintenant que l'utilisateur  user-ansible dispose bien des droits sudo :

ansible -i inventaire.ini -m user -a 'name=user-ansible groups=wheel append=yes ' --user user-ansible --ask-pass --become --ask-become-pass all

Nous répondons : 

SSH password: passforce
BECOME password[defaults to SSH password]: passforce

En sortie nous avons :

image-1633446465335.png

L'utilisateur a bien le droit de sudo ! 

Génération de clefs SSH :

ssh-keygen -t ecdsa

image-1633443306629.png

Ajoutez la clé publique de l’utilisateur user-ansible sur les nodes :
ansible -i inventaire.ini -m authorized_key -a 'user=user-ansible state=present key="{{ lookup("file", "/home/user-ansible/.ssh/id_ecdsa.pub") }}"' --user user-ansible --ask-pass all

Le mot de passe demandé est "passforce" !

Résultat : 

image-1633446214381.png

Vérification du bon fonctionnement des clefs SSH :

ansible -i inventaire.ini -m authorized_key -a 'user=user-ansible state=present key="{{ lookup("file", "/home/user-ansible/.ssh/id_ecdsa.pub") }}"' --user user-ansible --become --ask-become-pass all
BECOME password: passforce

Nous constatons, que on nous as demandé uniquement le mot de passe de sudo (BECOME password). Cela confirme que la liaison fonctionne bel et bien sans mot de passe ! 

Organisation de déploiement :

A titre d'exemple, nous allons installer la solution "MediaWiki".

Pour ce faire, nous commençons par définir les différentes étapes -  que l'on nommera des rôle - d'installation : 

  • Installation d'apache
  • Installation de MariaDB
  • Configuration d'apache
  • Configuration de MariaDB
  • Variables Globales

 

Structure d'un rôle : 

  • role/
    • files/             ---> Contient tous les fichier à copier sur le node
    • tasks/           ---> Contient les taches à exécuter 
      • main.yml
    • handlers/     ---> Contient les taches de notification
      • main.yml
    • defaults/      ---> Contient des variables par défaut
      • main.yml
    • meta/           ---> Contient des dépendances et des informations
      • main.yml

 

On applique ça à nos rôles à nous : 

 

  • Apache
    • tasks/
      • taches à exécuter pour installer apache et php
    • handlers
      • tache pour redémarrer le service apache
  • MariaDB
    • tasks/
      • taches à exécuter pour installer MariaDB
  • Commun
    • defaults/
      • Définition des variables globales
  • ConfDB
    • meta/
      • Dépendance avec le rôle Commun
    • tasks/
      • Taches à exécuter pour installer la base de donnée
  • ConfApache
    • meta/
      • Dépendance avec le rôle Commun
    • tasks/
      • Taches à exécuter pour installer apache

 

Pour simplifier la suite, nous allons créer un groupe de nodes : 

nano inventaire.ini
[apache]
http1

[db]
bdd1

 

Création du répertoire roles :

mkdir roles
cd roles

 

Nous allons maintenant utiliser ansible-galaxy qui permet de télécharger, créer et gérer les rôles ansible :

ansible-galaxy init apache

Regardons ce qu'ansible-galaxy a créer :

image-1633550710976.png

Cependant, nous allons garder uniquement les répertoires handlers, meta et tasks. Puis nous allons créer le fichier de configuration de la tache php-7 dans le rôle apache  :
rm ./apache/{README.md,defaults/,files/,templates/,tests/,vars/} -r
touch apache/tasks/php7-install.yml

Création du rôle mariadb :

mkdir -p mariadb/tasks/
touch mariadb/tasks/main.yml

Création du rôle médiawiki :

mkdir mediawiki
Création du rôle Commun : 
mkdir -p mediawiki/commun/defaults/
touch mediawiki/commun/defaults/main.yml
Création du rôle Confdb :
mkdir -p mediawiki/confdb/meta mediawiki/confdb/tasks
touch mediawiki/confdb/tasks/main.yml 
touch mediawiki/confdb/meta/main.yml
Création du rôle Confapache :
mkdir -p confapache/meta confapache/tasks 
touch confapache/tasks/main.yml confapache/meta/main.yml

Ce qui nous donne cette arborescence là : 

image-1633551481750.pngimage-1633553546268.png

Modification du main.yml du rôle apache :

nano roles/apache/tasks/main.yml
---

#1. Cette tâche permet d’installer Apache (httpd) à l’aide du module yum
- name: "apache installation"
  yum:
name: "httpd"
state: "present"

#2. Cette tâche active le service Apache
- name: "apache service activation"
  service:
name: "httpd"
state: "started"
enabled: yes

#3. Cette tâche fait appel à un autre fichier de configuration pour installer PHP. Elle est exécutée uniquement si la variable php_install est à vraie (par défaut, elle est à faux)
- name: "install php7 packages"
  include: "php7-install.yml"
  when: php_install|default(False)|bool

  1. La première tâche, "apache installation" va installer le serveur Apache avec le module “yum”. Le name: "httpd" indique le paquet concerné et le state: "present" spécifie qu’il faut l’installer. 

  2. La deuxième tâche, “apache service activation” va activer le service Apache avec le module “service”. Le name: "httpd" indique le service concerné, le state: "started" indique que le service sera démarré et le enabled: yes indique que le service sera activé.

  3. La troisième tâche, “install php7 packages” inclut un fichier de configuration externe pour installer PHP. La tâche fait appel avec l’option “include” au fichier php7-install.yml qui est placé dans le répertoire tasks à coté de main.yml. La condition when avec le filtre (php_install|default(False)|bool) permettent de conditionner l’installation de PHP.

Source : https://openclassrooms.com/fr/courses/2035796-utilisez-ansible-pour-automatiser-vos-taches-de-configuration/6373887-controlez-lexecution-des-operations-et-enchainez-plusieurs-actions

Modification du fichier php7-install.yml du rôle apache :

---

#1. Cette tâche installe le dépôt  EPEL (Extra Packages for Enterprise Linux)
- name: "epel activation"
  yum:
name: "epel-release"
state: present

#2. Cette tâche installe le dépôt REMI pour bénéficier du paquet PHP7
- name: "remi repo activation"
  yum:
name: "https://rpms.remirepo.net/enterprise/remi-release-7.rpm"
state: present

#3. Cette tâche installe PHP7 et ses extensions
- name: "install php70 packages"
  yum:
name: "php,php-mysql,php-xml,php-mbstring,php-mcrypt,php-gd,php-intl"
state: latest
enablerepo: "remi-php70"
  changed_when: yes
  notify: [ "apache restart" ]

  1. La première tâche, "epel activation", va activer le dépôt epel avec le module “yum”. Le name: "epel-release" indique le dépôt concerné et le state: present spécifie qu’il faut l’installer.
    Sur Centos, tous les logiciels ne sont pas disponibles par défaut. C’est le cas pour PHP7 ; il faut donc ajouter le dépôt EPEL qui va contenir le paquet PHP7.

  2. La deuxième tâche, “remi repo activation”, va installer le paquet remi-release-7.rpm avec le module “yum”. Le nom indique le service concerné ; le state: present indique que le paquet sera installé.
    Sous Centos, les paquets logiciels sont sous la forme RPM. Pour installer PHP7, vous avez besoin du paquet remi-release-7.rpm qui est dans le dépôt REMI qui dépend du dépôt EPEL.

  3. La troisième tâche, “install php7 packages”, installe les paquets php7 avec le module “yum”. Et les options :

    • le name indique l’ensemble des paquets à installer ; 

    • state: latest indique qu’il faut installer les dernières versions disponibles des paquets ;

    • enablerepo: "remi-php70" indique d’utiliser le dépôt remi-php70 pour les installer ;

    • changed_when : force le changement d'état, c’est-à-dire qu'avec cette condition à yes, l'exécution de la tâche provoquera un changement ;  

    • notify: [ "apache restart" ] indique que si la tâche change d'état (et uniquement si la tâche a engendré un changement), notify fait appel au handler "apache restart" pour relancer le service Apache.

Source : https://openclassrooms.com/fr/courses/2035796-utilisez-ansible-pour-automatiser-vos-taches-de-configuration/6373887-controlez-lexecution-des-operations-et-enchainez-plusieurs-actions

 

 

 

 

 

 

 

 

Back to top