Skip to content
Snippets Groups Projects
Commit f6597be0 authored by ExtraDev's avatar ExtraDev
Browse files

documentation

parent 56b31d8f
No related branches found
No related tags found
No related merge requests found
Show whitespace changes
Inline Side-by-side
README.md → Birner_tp3_Network_Automation_avec_Ansible.md
+ 117
− 24
View file @ f6597be0
...@@ -20,21 +20,24 @@ header-includes: ...@@ -20,21 +20,24 @@ header-includes:
\newpage \newpage
# Git du projet
# Topologie # Topologie
Illustration de la topologie que nous allons utiliser pour ce laboratoire. Illustration de la topologie que nous allons utiliser pour ce laboratoire.
![Configiguration de base](./images/config_de_base.png) ![Topologie de base](./images/config_de_base.png)
## Commandes ad-hoc # Commandes ad-hoc
## Expliquez ce que fait cette commande ? utilisez la commande ansible-doc pour répondre à la question.
```bash ```bash
ansible -m ping -i "H1,H2,R1,R2" all ansible -m ping -i "H1,H2,R1,R2" all
``` ```
- Expliquez ce que fait cette commande ? utilisez la commande ansible-doc pour répondre à la question. Cette commande fait appel au module de ping et effectue un ping sur tous les hôtes spécifié dans l'inventory. En réalise un test connectivity depuis notre machine.
Fait appel au module de ping et ping tous les hots spécifié dans l'inventory.
**Résultat de la commande:**
``` ```
R2 | SUCCESS => { R2 | SUCCESS => {
"ansible_facts": { "ansible_facts": {
...@@ -66,13 +69,13 @@ R1 | SUCCESS => { ...@@ -66,13 +69,13 @@ R1 | SUCCESS => {
} }
``` ```
- Donner la commande ad-hoc qui permet d’afficher l’uptime de toutes les machines, sans écrire de fichier inventaire. Démontrez que cette commande est correcte en l’exécutant sur la topologie. ## Donner la commande ad-hoc qui permet d’afficher l’uptime de toutes les machines, sans écrire de fichier inventaire. Démontrez que cette commande est correcte en l’exécutant sur la topologie.
```bash ```bash
ansible -i "H1, H2, R1, R2" all -m command -a "uptime" ansible -i "H1, H2, R1, R2" all -m command -a "uptime"
``` ```
Résuultat de la commande: Résultat de la commande:
``` ```
R1 | CHANGED | rc=0 >> R1 | CHANGED | rc=0 >>
05:13:30 up 40 min, 2 users, load average: 0.00, 0.00, 0.00 05:13:30 up 40 min, 2 users, load average: 0.00, 0.00, 0.00
...@@ -84,7 +87,7 @@ R2 | CHANGED | rc=0 >> ...@@ -84,7 +87,7 @@ R2 | CHANGED | rc=0 >>
05:13:31 up 40 min, 2 users, load average: 0.00, 0.00, 0.00 05:13:31 up 40 min, 2 users, load average: 0.00, 0.00, 0.00
``` ```
- Donner la commande ad-hoc qui va créer le fichier /tmp/hello.txt sur toutes les machines. Montrez sa sortie par une capture d’écran. ## Donner la commande ad-hoc qui va créer le fichier /tmp/hello.txt sur toutes les machines. Montrez sa sortie par une capture d’écran.
Pour ce faire, on fait appel au module "file". Pour ce faire, on fait appel au module "file".
```bash ```bash
...@@ -117,34 +120,89 @@ ssh H1 ls /tmp/hello.txt ...@@ -117,34 +120,89 @@ ssh H1 ls /tmp/hello.txt
/tmp/hello.txt /tmp/hello.txt
``` ```
- Quelle est la différente entre les modules command, shell et raw ? Expliquez et donner des exemples. ## Quelle est la différente entre les modules command, shell et raw ? Expliquez et donner des exemples.
Ces trois commande on le même objectif, à savoir exécuter des commandes sur les noeuds.
### Command
**command** Le module **command** est utilisé pour exécuter des commandes sur l'hôte distant en utilisant l'interpréteur de commande de l'hôte en question ('/bin/sh'). Avec le module "command" on ne peut pas utiliser le piping ou la redirection.
Le module "command" est utilisé pour exécuter des commandes sur l'hôte distant en utilisant l'interpréteur de commande de l'hôte en question ('/bin/sh').
Exemple ad-hoc
```bash
ansible node4 -m command -a "cat /etc/os-release"
node4 | FAILED! => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"module_stderr": "Shared connection to node4 closed.\r\n",
"module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
"msg": "The module failed to execute correctly, you probably need
to set the interpreter.\nSee stdout/stderr for the exact error",
"rc": 127
}
```
Exemple Exemple playbook
```yml ```yml
- name: Exécutez la commande "uptime" avec le module "command" - name: Exécutez la commande "uptime" avec le module "command"
command: uptime command: uptime
``` ```
**shell** ### Shell
Le module "shell" est utilisé pour exécuter des commandes sur l'hôte distant en utilisant un shell de commande complet, généralement /bin/bash. Il permet d'interpréter les caractères spéciaux tels que les pipes, les redirections et les variables d'environnement. Il est donc plus flexible que le module "command". Cependant, cela signifie également qu'il peut être plus dangereux s'il est utilisé de manière incorrecte.
Le module **shell** est utilisé pour exécuter des commandes sur l'hôte distant en utilisant un shell de commande complet, généralement /bin/bash. Il permet d'interpréter les caractères spéciaux tels que les pipes, les redirections et les variables d'environnement. Il est donc plus flexible que le module "command". Cependant, cela signifie également qu'il peut être plus dangereux s'il est utilisé de manière incorrecte.
Exemple ad-hoc
```bash
ansible node2 -m shell -a "lscpu | head -n 5"
Exemple node2 | CHANGED | rc=0 >>
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
```
Exemple playbook
```yml ```yml
- name: Exécutez la commande "ls" avec le module "shell" - name: Exécutez la commande "ls" avec le module "shell"
shell: ls -l /home/user/ shell: ls -l /home/user/
``` ```
**raw** ### Raw
Raw signifie que la commande sera exécutée directement avec les droits de l'utilisateur utilisé par Ansible pour se connecter à l'hôte distant. Cela le rend très puissant, mais également très dangereux s'il est utilisé de manière incorrecte. Le module "raw" est utile lorsque vous avez besoin de faire des choses comme installer Python sur un hôte où Python n'est pas déjà installé
Maintenant, le module **raw** utilise simplement SSH et contourne le sous-système du module Ansible. De cette façon, le module **raw** fonctionnera avec succès sur le nœud géré même si Python n'est pas installé (sur le nœud géré). Le module "raw" est utile lorsque vous avez besoin de faire des choses comme installer Python sur un hôte où Python n'est pas déjà installé.
Exemple ad-hoc
```bash
ansible node4 -m raw -a "cat /etc/os-release"
node4 | CHANGED | rc=0 >>
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
```
Exemple playbook
```yml ```yml
- name: Exécutez la commande "apt-get update" avec le module "raw" - name: Exécutez la commande "apt-get update" avec le module "raw"
raw: apt-get update raw: apt-get update
``` ```
![command vs. shell vs. raw modules. Source: learn_ansible_quickly.pdf](./images/module_capacities.png)
\newpage \newpage
# Routage et adressage # Routage et adressage
...@@ -167,7 +225,7 @@ Playbook permettant d'appliquer les règles ci-dessus: ...@@ -167,7 +225,7 @@ Playbook permettant d'appliquer les règles ci-dessus:
--- ---
# 1: Renommage des hosts du réseau # 1: Renommage des hosts du réseau
- name: Configuration et démarrage des interfaces réseau - name: Configuration et démarrage des interfaces réseau
hosts: all # Récupération des hosts provenant de l'intentory passé en en paramètre hosts: all # On spécifie tous les hosts provenant de l'intentory (inventory.ini) passé en en paramètre
become: true # en tant que root become: true # en tant que root
tasks: tasks:
...@@ -175,13 +233,13 @@ Playbook permettant d'appliquer les règles ci-dessus: ...@@ -175,13 +233,13 @@ Playbook permettant d'appliquer les règles ci-dessus:
# du fichier "variables.yml" # du fichier "variables.yml"
- name: Load the variables - name: Load the variables
include_vars: variables.yml include_vars: variables.yml
# Renommage de nos host (H1, H2, R1, R2)
- name: Rename hosts - name: Rename hosts
command: hostnamectl set-hostname {{ inventory_hostname }} command: hostnamectl set-hostname {{ inventory_hostname }}
# 2: Configuration des hotes # 2: Configuration des hotes
- name: Setup network for hosts - name: Setup network for hosts
hosts: hotes # On applique sur tous nos hôte (inventory.ini) hosts: hotes # On applique sur tous nos hôtes
become: true become: true
tasks: tasks:
...@@ -224,7 +282,7 @@ Playbook permettant d'appliquer les règles ci-dessus: ...@@ -224,7 +282,7 @@ Playbook permettant d'appliquer les règles ci-dessus:
value: '1' value: '1'
sysctl_set: true sysctl_set: true
state: present state: present
# Redémarre l'interface pour prendre en compte la nouvelle configuration
handlers: handlers:
- name: Restart network - name: Restart network
ansible.builtin.service: ansible.builtin.service:
...@@ -374,6 +432,13 @@ iface eth0 inet static ...@@ -374,6 +432,13 @@ iface eth0 inet static
post-up ip route add 3.0.0.0/24 via 1.0.0.1 post-up ip route add 3.0.0.0/24 via 1.0.0.1
``` ```
```{.numberLines}
root@H1:~# ip r
1.0.0.0/24 dev eth0 proto kernel scope link src 1.0.0.3
3.0.0.0/24 via 1.0.0.1 dev eth0 <---
10.0.2.0/24 dev mgmt0 proto kernel scope link src 10.0.2.15
```
**Configuration de R1** **Configuration de R1**
```{.numberLines} ```{.numberLines}
...@@ -389,6 +454,14 @@ iface eth0 inet static ...@@ -389,6 +454,14 @@ iface eth0 inet static
post-up ip route add 3.0.0.0/24 nexthop via 2.0.0.2 post-up ip route add 3.0.0.0/24 nexthop via 2.0.0.2
``` ```
```{.numberLines}
root@R1:~# ip route
1.0.0.0/24 dev eth1 proto kernel scope link src 1.0.0.1
2.0.0.0/24 dev eth0 proto kernel scope link src 2.0.0.1
3.0.0.0/24 via 2.0.0.2 dev eth0 <----
10.0.2.0/24 dev mgmt0 proto kernel scope link src 10.0.2.15
```
**Configuration de R2** **Configuration de R2**
```{.numberLines} ```{.numberLines}
...@@ -404,6 +477,14 @@ iface eth1 inet static ...@@ -404,6 +477,14 @@ iface eth1 inet static
post-up ip route add 1.0.0.0/24 nexthop via 2.0.0.1 post-up ip route add 1.0.0.0/24 nexthop via 2.0.0.1
``` ```
```{.numberLines}
root@R2:~# ip route
1.0.0.0/24 via 2.0.0.1 dev eth0 <-----
2.0.0.0/24 dev eth0 proto kernel scope link src 2.0.0.2
3.0.0.0/24 dev eth1 proto kernel scope link src 3.0.0.1
10.0.2.0/24 dev mgmt0 proto kernel scope link src 10.0.2.15
```
**Configuration réseau de H2** **Configuration réseau de H2**
```{.numberLines} ```{.numberLines}
...@@ -414,6 +495,13 @@ iface eth0 inet static ...@@ -414,6 +495,13 @@ iface eth0 inet static
post-up ip route add 1.0.0.0/24 via 3.0.0.1 post-up ip route add 1.0.0.0/24 via 3.0.0.1
``` ```
```{.numberLines}
root@H2:~# ip route
1.0.0.0/24 via 3.0.0.1 dev eth0 <----
3.0.0.0/24 dev eth0 proto kernel scope link src 3.0.0.2
10.0.2.0/24 dev mgmt0 proto kernel scope link src 10.0.2.15
```
\newpage \newpage
# Tunnel wireguard et serveur web # Tunnel wireguard et serveur web
...@@ -647,7 +735,8 @@ Script permettant de générer les clés publique et privée de H1 et H2. ...@@ -647,7 +735,8 @@ Script permettant de générer les clés publique et privée de H1 et H2.
wg genkey > privkey_H2 wg genkey > privkey_H2
wg pubkey < privkey_H2 > pubkey_H2 wg pubkey < privkey_H2 > pubkey_H2
# Chiffre le contenu de chaque fichier en utilisant le mode passe fournit dans le fichier 'vault_file' et l'écrit dans le fichier pubkey_H2 et privkey_h2 # Chiffre le contenu de chaque fichier en utilisant le mode passe fournit dans le fichier
# 'vault_file' et l'écrit dans le fichier pubkey_H2 et privkey_h2
cat pubkey_H2 | xargs -i ansible-vault encrypt_string --vault-password-file vault_file {} cat pubkey_H2 | xargs -i ansible-vault encrypt_string --vault-password-file vault_file {}
--output pubkey_H2 --output pubkey_H2
cat privkey_H2 | xargs -i ansible-vault encrypt_string --vault-password-file vault_file {} cat privkey_H2 | xargs -i ansible-vault encrypt_string --vault-password-file vault_file {}
...@@ -672,7 +761,7 @@ echo " H1PRIV: $(cat privkey_H1 )" >> keys.yml ...@@ -672,7 +761,7 @@ echo " H1PRIV: $(cat privkey_H1 )" >> keys.yml
echo " H1PUB: $(cat pubkey_H1 )" >> keys.yml echo " H1PUB: $(cat pubkey_H1 )" >> keys.yml
``` ```
Ce script permet de générer les clés ssh de H1 et H2 via **wg genkey** et en plus de les chiffrer avec le mot de passe contenu dans le fichier **vaul_file**. Enfin, les clés sont stockée dans le fichier keys.yml qui est chargé au début du playbook (première tâche). Ce script permet de générer les clés ssh de H1 et H2 via **wg genkey** et en plus de les chiffrer avec le mot de passe contenu dans le fichier **vaul_file**. Enfin, les clés sont stockée dans le fichier keys.yml qui est chargé au début du playbook (première tâche) pour être repartie sur les hotes.
Contenu du fichier vault_file Contenu du fichier vault_file
```{.numberLines} ```{.numberLines}
...@@ -683,6 +772,8 @@ PASSWORD_HERE ...@@ -683,6 +772,8 @@ PASSWORD_HERE
### Configuration sur H1 ### Configuration sur H1
Nous allons connecter H1 à H2 via wireguard, pour ce faire, voici la configuration que H1 devra contenir. Nous allons connecter H1 à H2 via wireguard, pour ce faire, voici la configuration que H1 devra contenir.
Template jinja2:
```{.numberLines} ```{.numberLines}
[Interface] [Interface]
Address = 10.0.0.2/24 Address = 10.0.0.2/24
...@@ -698,6 +789,7 @@ AllowedIPs = 10.0.0.0/24 ...@@ -698,6 +789,7 @@ AllowedIPs = 10.0.0.0/24
La partie **[Interface]** est la configuration de **wg0** sur la machine de H1. C'est via cette interface que la connection wireguard se fera. La partie **[Interface]** est la configuration de **wg0** sur la machine de H1. C'est via cette interface que la connection wireguard se fera.
### Configuration sur H2 ### Configuration sur H2
Template jinja2
```{.numberLines} ```{.numberLines}
[Interface] [Interface]
Address = 10.0.0.1/24 Address = 10.0.0.1/24
...@@ -708,6 +800,7 @@ PrivateKey = {{ keys["H2PRIV"] }} ...@@ -708,6 +800,7 @@ PrivateKey = {{ keys["H2PRIV"] }}
PublicKey = {{ keys["H1PUB"] }} PublicKey = {{ keys["H1PUB"] }}
AllowedIPs = 10.0.0.0/24 AllowedIPs = 10.0.0.0/24
``` ```
Ici, on peut constaté que H2 accepte toute les connexions venant du réseau 10.0.0.0/24. (H1 est configuré en 10.0.0.2 et donc aura accès). Ici, on peut constaté que H2 accepte toute les connexions venant du réseau 10.0.0.0/24. (H1 est configuré en 10.0.0.2 et donc aura accès).
\newpage \newpage
...@@ -727,7 +820,7 @@ server { ...@@ -727,7 +820,7 @@ server {
} }
} }
``` ```
La configuration nginx suivante définit un serveur web qui écoute l'adresse 10.0.0.1, sur le port 80. La configuration nginx suivante définit un serveur web qui écoute l'adresse 10.0.0.1, sur le port 80. En effet, une fois la configuration installée, nous ferons un "curl 10.0.0.1" depuis H1 pour accéder au site web sur H2.
La partie "location" spécifie que toutes les requêtes HTTP reçues seront traitées à partir du répertoire racine **/var/www/html**, et que le fichier index.html sera servi comme point d'entrée. La partie "location" spécifie que toutes les requêtes HTTP reçues seront traitées à partir du répertoire racine **/var/www/html**, et que le fichier index.html sera servi comme point d'entrée.
...@@ -876,7 +969,7 @@ ansible-playbook --syntax-check -i ../inventory.ini Config_H1_H2_Playbook.yml ...@@ -876,7 +969,7 @@ ansible-playbook --syntax-check -i ../inventory.ini Config_H1_H2_Playbook.yml
# Permet de valider les tâches du playbook sans appliquer les modifications sur les hôtes # Permet de valider les tâches du playbook sans appliquer les modifications sur les hôtes
ansible-playbook -i ../inventory.ini Config_H1_H2_Playbook.yml -CD ansible-playbook -i ../inventory.ini Config_H1_H2_Playbook.yml -CD
# Permet d'appliquer le playbook, # Permet d'appliquer le playbooken passant le fichier vault
ansible-playbook -i ../inventory.ini Config_Wireguard.yml --vault-password-file vault_file ansible-playbook -i ../inventory.ini Config_Wireguard.yml --vault-password-file vault_file
``` ```
......
README.pdf → Birner_tp3_Network_Automation_avec_Ansible.pdf
+ 0
− 0
View file @ f6597be0
No preview for this file type
images/module_capacities.png 0 → 100644
+ 0
− 0
View file @ f6597be0
images/module_capacities.png

25.4 KiB

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment