173 lines
6.0 KiB
Markdown
173 lines
6.0 KiB
Markdown
# gsb2025
|
||
|
||
* 2025-04-17 15h52 ps
|
||
* 2025-01-25 12h59 ps
|
||
|
||
Environnement et playbooks **ansible** pour le projet **GSB 2025**
|
||
|
||
## Quickstart
|
||
|
||
Prérequis :
|
||
* une machine **Linux Debian Bookworm** ou **Windows**
|
||
* VirtualBox
|
||
* git
|
||
* fichier machines virtuelles **ova** :
|
||
* **debian-bookworm-gsb-2025b.ova**
|
||
* **debian-bullseye-gsb-2024b.ova**
|
||
|
||
|
||
## Les machines
|
||
|
||
* **s-adm** : routeur adm, DHCP + NAT, déploiement, proxy squid
|
||
* **s-infra** : DNS maitre, autoconfiguration navigateurs avec **wpad**
|
||
* **r-int** : routage, DHCP
|
||
* **r-ext** : routage, NAT
|
||
* **s-proxy** : proxy **squid**
|
||
* **s-itil** : serveur GLPI
|
||
* **s-backup** : DNS esclave + sauvegarde s-win (SMB), Stork et Gotify
|
||
* **s-mon** : supervision avec **Nagios4/Zabbix**, notifications et journald
|
||
* **s-fog** : deploiement postes de travail avec **FOG**
|
||
* **s-win** : Windows Server 2019, AD, DNS, DHCP, partage fichiers
|
||
* **s-nxc** : NextCloud avec **docker** via proxy inverse **traefik** et certificat auto-signé
|
||
* **s-elk** : pile **ELK** dockerisée
|
||
* **s-lb** : Load Balancer **HaProxy** pour application Wordpress (DMZ)
|
||
* **r-vp1** : Routeur VPN Wireguard coté siège
|
||
* **r-vp2** : Routeur VPN Wireguard coté agence, DHCP
|
||
* **s-agence** : Serveur agence
|
||
* **s-lb** : Load Balancer **HaProxy** pour application Wordpress
|
||
* **s-lb-web1** : Serveur Wordpress 1 Load Balancer
|
||
* **s-lb-web2** : Serveur Wordpress 2 Load Balancer
|
||
* **s-lb-db** : Serveur Mariadb pour Wordpress
|
||
* **s-nas** : Serveur NFS pour application Wordpress avec LB
|
||
* **s-kea1** : Serveur DHCP Kea HA 1
|
||
* **s-kea2** : Serveur DHCP Kea HA 2
|
||
|
||
|
||
## Les playbooks
|
||
|
||
Il existe un playbook ansible pour chaque machine à installer, nommé comme la machine avec l'extension **.yml**
|
||
|
||
## Installation
|
||
|
||
On utilisera les images de machines virtuelle suivantes :
|
||
* **debian-bookworm-gsb-2025b.ova** (2025-04-17)
|
||
* Debian Bookworm 12.10 - 2 cartes - 1 Go - Stockage 20 Go
|
||
|
||
et pour **s-fog** :
|
||
* **debian-bullseye-2024b.ova** (2024-04-11)
|
||
* Debian Bullseye 11.9 - 2 cartes - 1 Go - stockage 20 Go
|
||
|
||
Les images **.ova** doivent etre stockées dans le répertoire habituel de téléchargement de l'utilisateur courant.
|
||
|
||
### Création d'une VM
|
||
|
||
Sur la machine physique, récupérer le dépot **gsb2025.git** avec :
|
||
```shell
|
||
git clone https://gitea.lyc-lecastel.fr/gsb2025/gsb2025.git
|
||
```
|
||
|
||
On utilisera le script (bash) **mkvm** ou (PowerShell) **mkvm.ps1** pour créer une VM Virtualbox.
|
||
|
||
```shell
|
||
cd gsb2025/scripts
|
||
mkvm -r -s s-adm
|
||
|
||
```
|
||
|
||
### Machine s-adm
|
||
|
||
La machine **s-adm** est la première machine à installer.
|
||
|
||
|
||
* créer la machine virtuelle **s-adm** avec **mkvm** comme décrit plus haut.
|
||
* démarrer la VM puis ouvir une session
|
||
* utiliser le script de renommage comme suit depuis `gsb2025/scripts` :
|
||
```shell
|
||
`bash chname <nouveau_nom_de_machine>` , puis redémarrer
|
||
```
|
||
* utiliser le script **s-adm-start** : `bash s-adm-start` , puis redémarrer
|
||
* ou alors inon :
|
||
```shell
|
||
mkdir -p tools/ansible ; cd tools/ansible
|
||
git clone https://gitea.lyc-lecastel.fr/gsb2025/gsb2025.git
|
||
cd gsb2025/pre
|
||
bash inst-depl
|
||
cd /root/tools/ansible/gsb2025/pre
|
||
DEPL=192.168.99.99 bash gsbboot
|
||
cd ../.. ; bash pull-config
|
||
```
|
||
- redémarrer
|
||
- la machine **s-adm** doit etre opérationnelle
|
||
|
||
### Pour chaque machine
|
||
|
||
#### Etape 1 - Nommage machine
|
||
|
||
- créer la machine avec **mkvm -r**, les cartes réseau sont paramétrées par **mkvm** selon les spécifications
|
||
- ouvrir une session sur la machine considérée
|
||
- renommer la machine soit
|
||
* en utilisant le script de renommage comme suit :
|
||
` /root/tools/ansible/gsb2025/scripts/chname <nouveau_nom_de_machine>`
|
||
* soit (ici on renomme la machine en **s-infra**) avec :
|
||
```shell
|
||
export HOST=s-infra
|
||
curl 192.168.99.99/gsbstore/inst1|bash
|
||
reboot # on redemarre
|
||
```
|
||
|
||
#### Etape 2 - installation outils, depot gsb2025 et lancement playbook
|
||
|
||
- utiliser le script **gsb-start** : `bash gsb-start`
|
||
- ou sinon:
|
||
```shell
|
||
curl 192.168.99.99/gsbstore/inst2|bash
|
||
```
|
||
- le script recupere le dépot **gsb2025.git**
|
||
- il lance ensuite le script **pull-config** avec le script portant le nom de la machine
|
||
- on peut alors redémarrer
|
||
|
||
#### Etape 3 - Redémarrage et tests
|
||
|
||
- redémarrer
|
||
- **Remarque** : une machine doit avoir été redémarrée pour prendre en charge la nouvelle configuration, en particulier la couche réseau et l'adressage.
|
||
- selon les situations, il est possible qu'un seul playbook ne soit pas suffisant pour installer complètement une machine. Dans ce cas de figure, le second playbook s'appelle **s-machine-post.yml**.
|
||
Il est à lancer depuis ''tools/ansible/gsb2025'' :
|
||
```shell
|
||
ansible-playbook -i localhost, -c local s-machine-post.yml
|
||
```
|
||
|
||
### Les tags ansible
|
||
|
||
Pour limiter l'effet de machines non disponible comme **s-mon**, il est possible d'utiliser des tags ansible , ...).
|
||
|
||
Les tags suivants sont définis : **zabbix** et **journald**.
|
||
|
||
L'appel de 'pull-config' comme ci-dessous permet d'ignorer les plays tagués 'zabbix' .
|
||
|
||
````shell
|
||
bash pull-config -l --skip-tags zabbix
|
||
````
|
||
|
||
## Les tests
|
||
|
||
Il peuvent êtres mis en oeuvre avec l'outil **goss** https://github.com/goss-org/goss de la façon suivante : chaque machine installée dispose d'un fichier de test ad-hoc portant le nom de la machine elle-même (machine.yaml).
|
||
|
||
```
|
||
cd tools/ansible/gsb2025
|
||
bash agoss # lance le test portant le nom de la machine
|
||
```
|
||
|
||
`bash agoss -f tap` permet de lancer le test avec le détail d'exécution
|
||
|
||
### Mise à jour des fichiers de test goss
|
||
|
||
Les modifications diverses apportées aux playbooks et les changements de version de paquets peuvent nécessiter l'adaption des fichiers de test goss : <host.yaml>
|
||
|
||
La commande `more goss/s-infra.yaml` permet d'afficher la contenu du fichier de test de la machine **s-infra** et de déterminer les modifications à apporter.
|
||
|
||
On utilisera la commande `goss add <test>` en spécifiant le fichier concerné avec l'option `--gossfile` :
|
||
``` shell
|
||
gsb2025> goss --gossfile goss/s-infra.yaml add aa lighttpd
|
||
```
|
||
|