Développer et sécuriser une solution Cloud

Der­nière révi­sion de la page : 02/03/2023

Création d’un nouveau repository

Un repo­si­to­ry Github est un espace de sto­ckage en ligne pour un pro­jet basé sur Git. Il per­met de sto­cker le code source, les fichiers de docu­men­ta­tion et les fichiers de confi­gu­ra­tion d’un pro­jet. Il per­met éga­le­ment de suivre les modi­fi­ca­tions appor­tées au code, de col­la­bo­rer avec d’autres déve­lop­peurs et de gérer les ver­sions du pro­jet. Il est pos­sible d’ac­cé­der, de télé­char­ger, de for­ker et de contri­buer à un repo­si­to­ry Github. Les uti­li­sa­teurs peuvent éga­le­ment uti­li­ser les fonc­tion­na­li­tés de Github pour créer des issues, gérer des tâches, et effec­tuer des revues de code. Nous allons donc nous rendre sur la page d’ac­cueil de Github pour créer un nou­veau repo­si­to­ry en cli­quant sur le bou­ton vert inti­tu­lé “New” situé sur la gauche dans la sec­tion de nos repo­si­to­ry.

Le screen­shot montre la page de créa­tion d’un nou­veau réfé­ren­tiel (repo­si­to­ry). On rem­plit le champ “Repo­si­to­ry name” qui va reflé­tait notre code, le champs des­crip­tion et licence sont option­nelles. Nous allons choi­sir un réfé­ren­tiel pri­vé, ain­si que l’a­jout d’un README file puis on clique sur “Create repo­si­to­ry”

SSH (Secure Shell) est un pro­to­cole de réseau qui per­met de se connec­ter à un ordi­na­teur dis­tant de manière sécu­ri­sée. Il per­met de se connec­ter à un ordi­na­teur dis­tant via une connexion chif­frée, ce qui pro­tège les infor­ma­tions échan­gées contre la sur­veillance et la modi­fi­ca­tion par des tiers. SSH est sou­vent uti­li­sé pour accé­der à un ser­veur à dis­tance pour exé­cu­ter des com­mandes ou trans­fé­rer des fichiers, ou pour confi­gu­rer une connexion sécu­ri­sée pour d’autres pro­to­coles de réseau, comme FTP ou Tel­net. SSH uti­lise géné­ra­le­ment des clés pour l’au­then­ti­fi­ca­tion plu­tôt que des mots de passe, ce qui ren­force encore la sécu­ri­té. On génère une nou­velle paire de clef SSH avec les para­mètres par défaut, cette paire de clef va nous per­mettre de nous iden­ti­fier auprès de notre compte GitHub.

ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/home/epsi/.ssh/id_rsa): 
Created directory '/home/epsi/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/epsi/.ssh/id_rsa
Your public key has been saved in /home/epsi/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:xN/A0FLqW2lgxCw9eezmB0V5gX27Z1hEljtSX+XoarA epsi@zeorus-epsi
The key's randomart image is:
+---[RSA 3072]----+
|       +o=...+.o*|
|      .oB++ + o*+|
|       .*=o. .oo*|
|       + o++ o +o|
|        So*.. ooo|
|         +.o....o|
|        . E.o  ..|
|           .     |
|                 |
+----[SHA256]-----+

On affiche notre clef publique pré­cé­dem­ment géné­ré afin de pou­voir la ren­sei­gner dans les para­mètres de notre compte GitHub.

cat .ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDSOgPI7UL53BgFqlED51METd24O5xiqmJvxGkT67HrWAOrzcyhAdy+wVKpNl5D+CBUQM7lGDdisGf1OEeZGOWxsl9TOHs5mOGCAXQj+ALYgLi0MjEuwLBgxLws42uhQ9HTqzordXIe4G0UCmDPwf+QPpqc/yXMFc0b5XZklgJpApGInYUhtLy/k6gApHVzBU8ChyHPpuIupe4XXKvOSpWEHhmHl1MqiLqT0658fMvYsrp9alWMz+ALrsRpZKn3u0R7YIejxRcK8kqvFheAsilFk7RgFDc/xRCPj8vX00B3ut0HZFq9qg/exDIfx/Jv61IAHh8FidcWumjnpAIIfjwf610m8kKMY/X813BJhp7oG2AuXt3gOWF7K2T0mjUaqSGEVii4kDL1lPJCFe8abnFAX5q0gqYCGtWhj4Csnfb9jYjRYfwXCLZkEgKbK1DJ5GahV6Z6LbdogsLzspKVLTjZ8wZ/YwAdqK0m7OeuG8tJeZExJUkt12d3QaePbRAcqCU= epsi@zeorus-epsi

On se rend de nou­veau sur notre compte GitHub, on clique sur le bou­ton en haut à droite qui nous per­met d’af­fi­cher les para­mètres de notre compte, puis “Set­tings”

La page des para­mètres s’af­fiche, dans le menu sur la gauche, vous cli­quez sur SSH and GPG keys. Sur cette inter­face, nous pou­vons nos clefs exis­tantes si l’on en pos­sède, et on clique sur “New SSH Key”

Nous lui indi­quons un nom expli­cite, pour notre part c’est notre machine machine pour l’en­vi­ron­ne­ment de déve­lop­pe­ment.

Nous allons pou­voir main­te­nant à par­tir de notre machine de déve­lop­pe­ment pour­voir com­men­cer à déve­lop­per. Pour cela nous allons nous rendre sur l’in­ter­face de notre repo et de récu­pé­rer le lien afin d’ins­tal­ler une ver­sion en local du repo sur notre machine.

Les commandes GIT

Si le package git n’est pas ins­tal­lé sur votre machine, vous pou­vez le faire sim­ple­ment avec cette com­mande :

apt-get install git -y

La com­mande “git clone” est uti­li­sée pour créer une copie d’un dépôt Git exis­tant (Ansible-EPSI) sur votre machine de déve­lop­pe­ment. Elle prend en entrée l’URL du dépôt à clo­ner et crée un nou­veau réper­toire qui contient tous les fichiers et l’his­to­rique de com­mits de ce dépôt. Elle per­met­tra éga­le­ment de syn­chro­ni­ser avec d’autres com­mande plus tard sur le repo­si­to­ry dis­tant, Github.

git clone git@github.com:FlynnHub/Ansible-EPSI.git

On se rend dans le dos­sier pré­cé­dem­ment clo­né

cd Ansible-EPSI

Pour la confi­gu­ra­tion de git, nous allons lui décla­rer notre iden­ti­té pour nos futurs com­mits

git config --global user.email "theophilegarin@hotmail.com"
git config --global user.name "Théophile Garin"

On peut deman­der à Git les modi­fi­ca­tions qui sont appor­tés à notre dos­sier. Pour l’ins­tant il n’y a eu aucune modi­fi­ca­tion.

git status

Sur la branche main
Votre branche est à jour avec 'origin/main'.

rien à valider, la copie de travail est propre

Nous allons créer un nou­veau dos­sier et un nou­veau fichier dedans, vous pou­vez le faire avec l’é­di­teur de code Visual Stu­dio Code,soit vous le faites à l’aide des com­mandes ci-des­sous

mkdir inventory

vim inventory/hosts

[all]

A nou­veau si nous refai­sons notre git sta­tus, nous voyons que nous avions de nou­veau dos­sier et fichier non sui­vis, git nous recom­mande d’ailleurs d’u­ti­li­ser une com­mande afin de pou­voir suivre ce fichier.

git status

Sur la branche main
Votre branche est à jour avec 'origin/main'.

Fichiers non suivis:
  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)
	inventory/

aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre)

La com­mande “git add .” est uti­li­sée pour ajou­ter tous les fichiers modi­fiés ou nou­veaux dans l’in­dex de Git. L’in­dex est un étape inter­mé­diaire avant de faire un com­mit, il per­met de sélec­tion­ner les fichiers qui seront inté­grés dans le pro­chain com­mit. Cette com­mande ajoute tous les fichiers dans le réper­toire cou­rant et ses sous-réper­toires à l’in­dex. Cela vous per­met de pré­pa­rer les fichiers pour le pro­chain com­mit

git add .

git status

Sur la branche main
Votre branche est à jour avec 'origin/main'.

Modifications qui seront validées :
  (utilisez "git restore --staged <fichier>..." pour désindexer)
	nouveau fichier : inventory/hosts

Nous allons main­te­nant pou­voir effec­tuer notre pre­mier com­mit. Il existe des bonnes pra­tiques en terme de mes­sage de com­mit pour pou­voir les publier, il n’est pas néces­saire mais assure la bonne com­pré­hen­sion.

git commit -m "feat(inventory):Add hosts file"

[main ba87ed9] feat(inventory):Add hosts file
 1 file changed, 1 insertion(+)
 create mode 100644 inventory/hosts

Nous pou­vons main­te­nant pous­ser nos modi­fi­ca­tions sur le repo­si­to­ry dis­tant sur GitHub

git push

Énumération des objets: 5, fait.
Décompte des objets: 100% (5/5), fait.
Compression par delta en utilisant jusqu'à 2 fils d'exécution
Compression des objets: 100% (2/2), fait.
Écriture des objets: 100% (4/4), 360 octets | 360.00 Kio/s, fait.
Total 4 (delta 0), réutilisés 0 (delta 0), réutilisés du pack 0
To github.com:FlynnHub/Ansible-EPSI.git
   823281c..ba87ed9  main -> main

Si nous retour­nons main­te­nant sur notre inter­face GitHub, nous pou­vons aper­ce­voir nos modi­fi­ca­tions, que le dos­sier inven­to­ry est bien appa­ru, il y’a deux minutes

Nous pou­vons affi­cher toutes nos branchs dis­po­nible via cette com­mande. L’é­toile dési­gnant la branch actuelle sur laquelle on se trouve. La branch main étant la prin­ci­pale, c’est celle qui doit être “Pro­duc­tion Rea­dy”, tout le temps uti­li­sable.

git branch -a 

* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/main

Nous pou­vons créer des autres branchs afin de pou­voir déve­lop­per des nou­velles fonc­tion­na­li­tés ou encore amé­lio­rer notre code. Une fois que sur notre branch le code est prêt et fonc­tion­nel sans rétro­gra­da­tion, nous pour­rons le mer­ger plus tard. Nous sou­hai­tons créer une nou­velle branch afin de com­plé­ter notre inven­taire.

git checkout -b "Complete_Inventory"

git branch -a

* Complete_Inventory
  main
  remotes/origin/HEAD -> origin/main
  remotes/origin/main

On créé nos dos­siers

mkdir inventory/group_vars && mkdir inventory/host_vars
touch inventory/group_vars/APACHE.yml && touch inventory/host_vars/apache1.yml

On regarde nos modi­fi­ca­tions

git status

Sur la branche Complete_Inventory
Fichiers non suivis:
  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)
	inventory/group_vars/
	inventory/host_vars/

aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre)

On les ajoutes à notre Index

git add .

On com­mit nos modi­fi­ca­tions

git commit -m "feat(inventory): Add Apache group and host_vars"

On push nos modi­fi­ca­tions

git push

fatal: La branche courante Complete_Inventory n'a pas de branche amont.
Pour pousser la branche courante et définir la distante comme amont, utilisez

    git push --set-upstream origin Complete_Inventory

Vu qu’il s’a­git d’une nou­velle branche qui est connu en local, mais pas sur notre repo­si­to­ry dis­tant, nous devons effec­tuer cette com­mande à chaque fois qu’une nou­velle branch n’est pas connu par Github

git push --set-upstream origin Complete_Inventory

Énumération des objets: 8, fait.
Décompte des objets: 100% (8/8), fait.
Compression par delta en utilisant jusqu'à 2 fils d'exécution
Compression des objets: 100% (3/3), fait.
Écriture des objets: 100% (6/6), 528 octets | 528.00 Kio/s, fait.
Total 6 (delta 0), réutilisés 0 (delta 0), réutilisés du pack 0
remote: 
remote: Create a pull request for 'Complete_Inventory' on GitHub by visiting:
remote:      https://github.com/FlynnHub/Ansible-EPSI/pull/new/Complete_Inventory
remote: 
To github.com:FlynnHub/Ansible-EPSI.git
 * [new branch]      Complete_Inventory -> Complete_Inventory
La branche 'Complete_Inventory' est paramétrée pour suivre la branche distante 'Complete_Inventory' depuis 'origin'.

Main­te­nant que nous retour­nions sur notre branch main que ce soit sur notre repo local (La machine de déve­lop­pe­ment) ou sur notre repo­si­to­ry dis­tant (Github). Nous voyons seule­ment les modi­fi­ca­tions pré­cé­dem­ment effec­tué seule­ment sur la branch Complete_Inventory

Gérer son inventaire Ansible

L’in­ven­taire Ansible à la base est com­po­sé d’un seul fichier “Hosts”. Il réfé­rence la liste des hôtes et des groupes de ser­veurs ou équi­pe­ments réseaux qui peut-être géré par Ansible. En terme de bonnes pra­tiques, pour une pla­te­forme qui va entre 1 à 200–300 ser­vers, on le com­pose d’un dos­sier inven­to­ry qui contien­dra notre fichier hosts, puis deux dos­siers, un qui sera uti­li­sé pour les variables par ser­vers, et un qui sera uti­li­sé pour les variables par groupe de ser­vers. Exemple :

Géné­ra­tion d’un inven­taire deux envi­ron­ne­ments qui sont ISO, un envi­ron­ne­ment pour la pré­pro­duc­tion ain­si qu’un envi­ron­ne­ment pour la pro­duc­tion. Les deux envi­ron­ne­ments contiennent cha­cun :

• 1 Haproxy
• 2 Apaches
• 1 MyS­QL

#################### PREPRODUCTION ####################

[PPROD:children]
PPROD_HAPROXY
PPROD_APACHE
PPROD_MYSQL

#################### PRODUCTION #######################

[PROD:children]
PROD_HAPROXY
PROD_APACHE
PROD_MYSQL

#################### HOSTS ############################

[PPROD_HAPROXY]
192.168.0.10

[PPROD_APACHE]
192.168.0.12
192.168.0.13

[PPROD_MYSQL]
192.168.0.17

[PROD_HAPROXY]
192.168.0.20

[PROD_APACHE]
192.168.0.22
192.168.0.23

[PROD_MYSQL]
192.168.0.27

Une fois que le fichier hosts est créé, il faut pas­ser main­te­nant à la créa­tion des host_vars et des group_vars. Nous allons au moins créer un dos­sier dans les group_vars par groupe dans fichier hosts, voi­ci un exemple :

Préparation de l’environnement pour les connexions SSH

Dans un pre­mier temps, nous allons nous assu­rer que le package conte­nant SSH est bien ins­tal­lé. Il est pos­sible que si vous avez un ser­veur avec une inter­face gra­phique, le package ne soit pas ins­tal­lé par défaut.

apt-get install openssh-server -y

Nous allons pas­ser le Per­mi­tRoot­Lo­gin à yes. Cette mani­pu­la­tion va nous per­mettre de nous connec­ter direc­te­ment en root sur la machine dis­tante, cette authen­ti­fi­ca­tion de base sur OpenSSH est géné­ra­le­ment désac­ti­vée sur les dis­tri­bu­tions par défaut pour des rai­sons de sécu­ri­té. Une bonne pra­tique étant de créer un uti­li­sa­teur tech­nique sur la machine qui va être uti­li­sé afin de pou­voir pas­ser les com­mandes Ansible. La mani­pu­la­tion sui­vante que nous allons faire n’est pas recom­man­dé mais va nous per­mettre de gagner du temps.

vim /etc/ssh/sshd_config

#PermitRootLogin prohibit-password

PermitRootLogin yes

Nous allons ensuite redé­mar­rer notre ser­vice SSH afin de prendre en compte les nou­velles modi­fi­ca­tions

systemctl restart ssh

Nous allons ensuite impor­ter notre clef SSH de notre ser­veur. Elle va per­mettre la connexion sans mot de passe depuis notre bas­tion qui fait office d’en­vi­ron­ne­ment de déve­lop­pe­ment avec cette com­mande :

ssh-copy-id root@192.168.0.20

The authenticity of host '192.168.0.20 (192.168.0.20)' can't be established.

ED25519 key fingerprint is SHA256:ppCKTa6I0XB2+KquawymTaRkYBj8RcOV78AvDLwG9uQ.

This key is not known by any other names

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

root@192.168.0.20's password: 



Number of key(s) added: 1



Now try logging into the machine, with:   "ssh 'root@192.168.0.20'"

and check to make sure that only the key(s) you wanted were added.

Afin de tes­ter le bon échange des clefs, nous pou­vons exé­cu­ter la com­mande sui­vante, elle est cen­sé nous per­mettre de se connec­ter sur le ser­veur dis­tant, avec l’u­ti­li­sa­teur root et sans mot de passe

ssh root@192.168.0.20

Afin d’être un peu plus repré­sen­ta­tif de ce que l’on pour­rait avoir en entre­prise, nous allons modi­fier notre fichier /etc/hosts. C’est un fichier de confi­gu­ra­tion qui per­met de faire cor­res­pondre des noms d’hôtes à adresses IP sur un sys­tème d’ex­ploi­ta­tion. Elle per­met­tra de simu­ler une entrée DNS pour nos noms de domaine.

127.0.0.1       localhost
127.0.1.1       zeorus-epsi

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

192.168.0.20    apache01
192.168.0.16    apache02                                                                                                                                                                                                                                                                                                                   

Les commandes ad-hoc

Les com­mandes ad-hoc sont la pre­mière uti­li­sa­tion d’An­sible. Ansible fonc­tionne avec des modules avec lequel nous allons faire appel. Pour tes­ter le bon fonc­tion­ne­ment de la connexion on va uti­li­ser le module ping. Dans cette com­mande on appelle :

• ansible : Est le nom de notre logi­ciel auquel nous fai­sons appel
• apache1 : Ce deuxième para­mètre spé­ci­fie les hôtes, ou le groupe d’hôte dis­tant, apache1
• -i inventory/ : Per­met de spé­ci­fier ou se trouve notre inven­taire, inven­to­ry
• -u root : Per­met de spé­ci­fier avec quel uti­li­sa­teur se connec­ter sur l’hôte dis­tant, root
• -m ping : Per­met de spé­ci­fier le nom du module à exé­cu­ter, ping

ansible apache1 -i inventory/ -u root -m ping

apache1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Ici on effec­tue la même com­mande mais avec le para­mètre de spé­ci­fi­ca­tion des hôtes avec “PROD_APACHE”. Il va donc essayer de ping les deux machines, sur cet exemple le second hôte du groupe est down, il n’ar­rive donc pas à la ping et nous affiche un “UNREACHABLE”.

ansible PPROD_APACHE -i inventory/ -u root -m ping

apache1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
apache2 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: ssh: connect to host apache2 port 22: Connection timed out",
    "unreachable": true
}

Les com­mandes ad-hocs sont sou­vent uti­li­sées pour effec­tuer une seule tâche sur plu­sieurs ser­veurs comme leur mise à jour, par exemple :

ansible PPROD_APACHE -i inventory/ -u root -m shell -a "apt-get update && apt-get upgrade -y"

apache2 | CHANGED | rc=0 >>
Atteint :1 http://security.debian.org/debian-security bullseye-security InRelease
Atteint :2 http://http.us.debian.org/debian bullseye InRelease
Atteint :3 http://http.us.debian.org/debian bullseye-updates InRelease
Lecture des listes de paquets…
Lecture des listes de paquets…
Construction de l'arbre des dépendances…
Lecture des informations d'état…
Calcul de la mise à jour…
Les paquets suivants ont été conservés :
  linux-image-amd64
0 mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour.
apache1 | CHANGED | rc=0 >>
Atteint :1 http://security.debian.org/debian-security bullseye-security InRelease
Atteint :2 http://http.us.debian.org/debian bullseye InRelease
Atteint :3 http://http.us.debian.org/debian bullseye-updates InRelease
Lecture des listes de paquets…
Lecture des listes de paquets…
Construction de l'arbre des dépendances…
Lecture des informations d'état…
Calcul de la mise à jour…
Les paquets suivants ont été conservés :
  linux-image-amd64
0 mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour.

Ansible pos­sède éga­le­ment une fonc­tion­na­li­té de gathers_facts qui sont des variables magiques. C’est une étape qui peut-être facul­ta­tive qui per­met de col­lec­ter des infor­ma­tions sur l’hôte dis­tant avant d’ef­fec­tuer des tâches. Elles incluent des infor­ma­tions détaillés comme le sys­tème d’ex­ploi­ta­tion, sa ver­sion, la mémoire dis­po­nible etc.

ansible apache1 -i inventory/ -u root -m setup

apache1 | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "192.168.0.12"
        ],
        "ansible_all_ipv6_addresses": [
            "fe80::20c:29ff:feff:213"
        ],
        "ansible_apparmor": {
            "status": "enabled"
        },
        "ansible_architecture": "x86_64",
        "ansible_bios_date": "11/12/2020",
        "ansible_bios_vendor": "Phoenix Technologies LTD",
        "ansible_bios_version": "6.00",
        "ansible_board_asset_tag": "NA",
        "ansible_board_name": "440BX Desktop Reference Platform",
        "ansible_board_serial": "None",
        "ansible_board_vendor": "Intel Corporation",
        "ansible_board_version": "None",
        "ansible_chassis_asset_tag": "No Asset Tag",
        "ansible_chassis_serial": "None",
        "ansible_chassis_vendor": "No Enclosure",
        "ansible_chassis_version": "N/A",
        "ansible_cmdline": {
            "BOOT_IMAGE": "/boot/vmlinuz-5.10.0-20-amd64",
            "quiet": true,
            "ro": true,
            "root": "UUID=3faf6c6b-7a9b-44c7-925b-728a8cd81ad4"
        },

Les playbooks

---
- name: Basic roles

Les roles

Nous allons pro­cé­der à l’ins­tal­la­tion de rôle exis­tant, et pour cela nous allons les spé­ci­fier dans notre fichier requirements.yml

---
- name: python
  src: git+https://github.com/OCG-EPSI/python.git
  version: latest
  
- name: haproxy
  src: git+https://github.com/OCG-EPSI/haproxy.git
  version: latest
  
- name: apache
  src: git+https://github.com/OCG-EPSI/apache2.git
  version: latest
  
- name: mysql
  src: git+https://github.com/OCG-EPSI/mysql_server.git
  version: latest

Une fois notre fichier rem­plis avec les rôles dont lequel on a le besoin, on les prends en local sur notre poste afin de pou­voir s’en ser­vir

ansible-galaxy install -r requirements.yml --force

Pour notre pla­te­forme, nous avons le besoin d’un rôle SFTP, mais mal­heu­reu­se­ment nous n’en pos­sé­dons pas par­mi les rôles com­muns à l’en­tre­prise. On ini­tia­lise donc un nou­veau rôle que l’on va déve­lop­per qui va ser­vir à la fois pour notre pla­te­forme et ain­si aux autres grâce à son fait géné­rique.

ansible-galaxy init sftp

Nous pou­vons appe­ler le rôle SFTP pré­cé­dem­ment créé depuis notre play­books afin de pou­voir l’ins­tan­cier sur nos machines. Dans notre cas, nous allons l’ap­pe­ler à par­tir d’un play­book qui s’ap­pelle main.yml et qui va conte­nir nos rôles que l’on sou­haite appe­ler :

---
- name: Basic roles
  hosts: all
  gather_facts: true
  roles:
    - { name: python, tags: python }
    - { name: sftp, tags: sftp }
    - { name: haproxy, tags: haproxy }
    - { name: apache, tags: apache }
    - { name: mysql, tags: mysql }

On fait donc appelle à notre rôle, en lan­çant notre play­book main.yml

ansible-playbook main.yml -u root -i inventory -l PROD_APACHE --tags sftp

Chiffrement des données sensibles

Afin de pou­voir chif­frer nos don­nées sen­sibles qui sont livrés avec Ansible, nous pou­vons uti­li­ser l’ou­til Ansible-vault. Il existe plu­sieurs façon de l’u­ti­li­ser, nous allons en voir une ci-des­sous. Notre rôle Ansible SFTP uti­lise des don­nées sen­sible, comme les mots de passe SFTP. On peut télé­char­ger une exten­sion visual stu­dio code “ansible-vault” qui vous per­met­tra avec la com­bi­nai­son de touche ctrl+alt+0 de pou­voir chif­frer et déchif­frer à la volée.

Il faut pour cela indi­quer dans notre fichier ansible.cfg où se trouve notre fichier conte­nant notre secret :

[defaults]
host_key_checking = False
inventory = inventory
vault_password_file = $HOME/secrets/rte

Main­te­nant que nous avons para­mé­tré notre fichier ansible.cfg, nous avons ce fichier conte­nant un uti­li­sa­teur SFTP avec son mot de passe asso­cié qui appa­raissent en clair

On exé­cute notre com­bi­nai­son de touches ctrl + alt + 0 et voi­ci notre nou­veau ren­du :