déploie OpenStack 2025.2 avec Kolla-Ansible (tout-en-un, API sur dummy0)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 15:50:54 +02:00 · 2026-10-07 15:50:54 +02:00 · db2842689a
commit db2842689a
parent 87c8aac5f5
12 changed files with 978 additions and 3 deletions
--- a/docs/adr/0001-kolla-2025-2-sur-debian-12.md
+++ b/docs/adr/0001-kolla-2025-2-sur-debian-12.md
@ -0,0 +1,43 @@
+# ADR 0001 — Kolla-Ansible 2025.2 sur Debian 12, sans HAProxy ni Cinder
+
+- **Date** : 2026-10-07
+- **Statut** : accepté
+
+## Contexte
+
+Le serveur Syllabus (Dedibox Start-2-L) est installé en Debian 12 (bookworm),
+avec une seule IP publique et deux SSD entièrement utilisés par un RAID 1
+logiciel pour `/`. Il faut un OpenStack tout-en-un, maintenu, dont aucune API
+n'est exposée sur l'IP publique.
+
+## Décision
+
+1. **Kolla-Ansible série 2025.2 (Flamingo).** C'est la plus récente qui
+   supporte encore Debian 12 comme hôte : 2026.1 ne supporte plus que
+   Debian 13. 2025.1 n'est plus maintenue depuis le 2 octobre 2026, alors
+   que 2025.2 l'est jusqu'en avril 2027 (fin de vie estimée).
+   Sources : support matrix 2025.2 et 2026.1, releases.openstack.org.
+2. **Images `debian` (`2025.2-debian-bookworm`)**, cohérentes avec l'hôte.
+3. **Pas de HAProxy ni de keepalived** : un seul nœud, donc aucune VIP à faire
+   flotter. Toutes les API écoutent sur `dummy0` (10.10.0.1).
+4. **Neutron OVN**, réseau externe sur une paire veth NATée (étape 4), jamais
+   sur `eno1`.
+5. **Pas de Cinder pour l'instant.** Il n'y a aucun espace disque libre pour
+   un groupe de volumes LVM. Une alternative (fichier en loopback sur `/`)
+   serait fragile et lente pour un gain nul : les labs n'ont besoin que de
+   disques éphémères Nova.
+6. **Kolla ne gère pas le pare-feu.** Il est écrit dans le rôle Ansible
+   `durcissement`, et Docker est configuré pour ne créer aucune règle.
+
+## Conséquences
+
+- Il faudra passer à Debian 13 pour suivre les séries suivantes (2026.1 et
+  au-delà) : c'est un sujet de la montée de version (semaine 7 du bloc A),
+  à prévoir avant avril 2027.
+- Kolla est installé depuis la branche `stable/2025.2` (version
+  `21.3.1.dev4` au moment de l'installation), comme le recommande la
+  documentation. Pour une reproductibilité stricte, il faudra figer un tag
+  de version.
+- Pas de volumes persistants pour les VM tant que Cinder (ou Ceph, bloc C)
+  n'est pas en place. Les travaux des élèves devront donc être sauvegardés
+  ailleurs (S3, bloc B).
--- a/docs/journal.md
+++ b/docs/journal.md
@ -149,3 +149,43 @@ OpenStack a besoin de deux réseaux en plus de l'accès public : un réseau inte
 **Suite**

 Étape 5 : Kolla-Ansible 2025.2 tout-en-un. `bootstrap-servers` peut toucher au pare-feu et à Docker : vérifier avant, rejouer `durcissement` après, et demander l'accord d'Adam pour ce qui touche au pare-feu.
+
+## 2026-10-07 — Étape 5 : OpenStack avec Kolla-Ansible 2025.2
+
+**Fait**
+
+- Rôle Ansible `kolla` + playbook `ansible/kolla.yml` : dépendances système, venv `/opt/kolla-venv` (Kolla-Ansible `stable/2025.2`, version `21.3.1.dev4`, ansible-core 2.19, client `openstack` 8.2.0, SDK `docker` et `dbus-python`), `/etc/kolla/globals.yml` et `all-in-one` copiés depuis le dépôt (`kolla/`), `passwords.yml` généré par `kolla-genpwd` **sur le serveur uniquement** (`600 root:root`, jamais dans Git), `install-deps`.
+- `kolla/globals.yml` : images Debian bookworm (tag vérifié sur quay.io), API sur `dummy0`, réseau externe `veth-ext-ovs`, OVN, sans HAProxy, keepalived, ProxySQL, Horizon ni Cinder ; avec Heat, console série, KVM, Prometheus, Grafana. `disable_firewall: false`. Docker sans iptables ni ip6tables.
+- Avant de lancer `bootstrap-servers`, j'ai lu son code installé localement pour savoir s'il touchait au pare-feu. Sur Debian, il ne fait qu'essayer de désactiver `ufw` (absent) et ne touche ni à nftables ni à l'heure.
+- `bootstrap-servers`, `prechecks`, `deploy` (lancé comme service `systemd-run` pour survivre à une coupure SSH, 22 min), `post-deploy`.
+- ADR `docs/adr/0001-kolla-2025-2-sur-debian-12.md`, runbook `docs/runbooks/openstack.md`.
+- Correction fail2ban validée par Adam à l'étape 4 : le handler `recharger nftables` relance aussi fail2ban (handler `listen`), et une option `-e durcissement_forcer_rechargement=true` force un rechargement du pare-feu.
+
+**Problèmes rencontrés et solution**
+
+1. `install-deps` : `No such file or directory: 'ansible-galaxy'` → le `bin` du venv doit être dans le `PATH`.
+2. **`bootstrap-servers` a modifié le pare-feu** (arrêt et accord d'Adam). Docker 29 a créé des tables `ip6 nat` et `ip6 filter` malgré `iptables: false` : depuis Docker 27, l'IPv6 a son propre réglage. Aucun impact sur la sécurité, car notre chaîne `forward` en `drop` l'emporte. Correction : `docker_custom_config: {ip6tables: false}`, puis un rechargement forcé du pare-feu sous filet anti-coupure. J'ai vérifié qu'un redémarrage de Docker ne recrée plus les tables.
+3. `prechecks` : `No module named 'docker'` → Kolla utilise le Python du venv ; `docker` et `dbus-python` ajoutés au venv.
+4. **1er `deploy` en échec** : MariaDB `Bind on TCP/IP port. Got error: 98: Address already in use`. ProxySQL écoute sur la VIP:3306, et sans HAProxy la VIP est l'IP du nœud, donc il occupait le port de MariaDB. Correction : `enable_proxysql: "no"`. Le conteneur et le volume `proxysql` ont été supprimés avec l'accord d'Adam. Le volume `proxysql_socket` est encore présent (non validé, à supprimer avec son accord). Au 2ᵉ `deploy`, MariaDB a démarré sans qu'il faille réinitialiser son volume.
+
+**Critère vérifié**
+
+- `openstack service list` : keystone, glance, nova, neutron, placement, heat, heat-cfn.
+- `openstack compute service list` : nova-scheduler, nova-conductor, nova-compute `up`. Agents OVN (Controller Gateway, Metadata) vivants.
+- `nmap` depuis le Mac sur les ports OpenStack (5000, 8774, 8775, 8778, 9292, 9696, 6080-6083, 3000, 9090, 9091, 9093, 9100, 3306, 5672, 15672, 11211, 6641, 6642, 16509…) + 1-1024 : **seul 22 est ouvert**.
+- Pare-feu identique à la référence ; seule `f2b-table` (fail2ban) en plus.
+- Correction fail2ban testée : bannissement de l'adresse de test `192.0.2.10` (plage réservée à la documentation), rechargement forcé du pare-feu ; `f2b-table` recréée et le bannissement toujours en place. Adresse débannie ensuite.
+- 46 conteneurs ; RAM utilisée 11 Gio sur 31 (19 Gio disponibles) avant toute VM.
+
+**Dettes notées**
+
+- Les bases OVN (`ovsdb-server`, 6641/6642) écoutent sur `0.0.0.0`. Le pare-feu les bloque, mais il faudrait les restreindre à `10.10.0.1` (défense en profondeur).
+- Kolla est installé depuis une branche, pas un tag : figer la version pour la reproductibilité (ADR 0001).
+
+**Comprendre**
+
+Kolla-Ansible déploie OpenStack sous forme de conteneurs Docker : chaque service (Keystone, Nova, Neutron…) tourne dans son propre conteneur, configuré par Ansible à partir d'un seul fichier, `globals.yml`. Les deux incidents de cette étape viennent de valeurs par défaut prévues pour un vrai cluster de plusieurs serveurs. Docker crée des règles de pare-feu IPv6 pour ses réseaux, et ProxySQL suppose une adresse virtuelle distincte de celle du serveur. Sur un seul nœud, ces mécanismes ne servent à rien et se gênent entre eux. La leçon : lire le code de l'outil avant de le lancer, et comparer le pare-feu avant et après, plutôt que de faire confiance aux options. C'est ce qui a permis de repérer les tables Docker en quelques secondes.
+
+**Suite**
+
+Étape 6 : projet `paillasse`, utilisateur de service avec application credentials, image `paillasse-debian` (virt-customize), flavor `eleve.petit`, première VM et console série par WebSocket.
--- a/docs/runbooks/openstack.md
+++ b/docs/runbooks/openstack.md
@ -0,0 +1,88 @@
+# Runbook — OpenStack (Kolla-Ansible 2025.2, tout-en-un)
+
+## Où sont les choses
+
+| Élément | Emplacement |
+|---|---|
+| venv Kolla-Ansible + client `openstack` | `/opt/kolla-venv` (liens dans `/usr/local/bin`) |
+| Configuration | `/etc/kolla/globals.yml` (copie de `kolla/globals.yml` du dépôt) |
+| Inventaire | `/etc/kolla/all-in-one` (copie de `kolla/all-in-one`) |
+| Mots de passe | `/etc/kolla/passwords.yml` — **serveur uniquement**, `600 root:root`, jamais dans Git |
+| Accès admin | `/etc/kolla/clouds.yaml`, `/etc/kolla/admin-openrc.sh` (générés par `post-deploy`) |
+| Collections Ansible de Kolla | `/root/.ansible/collections/` (installées par `install-deps`) |
+| Journaux des déploiements | `/var/log/kolla-*.log` |
+
+Tout ce qui précède (sauf les mots de passe et les fichiers générés) est
+préparé par le playbook `ansible/kolla.yml` depuis le Mac :
+
+```
+cd ansible && script -q /dev/null ansible-playbook kolla.yml -i inventory.ini
+```
+
+## Choix de configuration (résumé de `kolla/globals.yml`)
+
+- Images `debian` (tag `2025.2-debian-bookworm`).
+- Toutes les API sur `dummy0` (10.10.0.1), jamais sur `eno1`. Pas de HAProxy ni keepalived (un seul nœud).
+- Réseau externe Neutron : `veth-ext-ovs` (paire veth de l'étape 4), OVN.
+- Heat, console série (`nova-serialproxy`), KVM, Prometheus, Grafana activés. Horizon désactivé.
+- Cinder désactivé : pas de place pour un groupe de volumes LVM (disques entièrement en RAID 1).
+- `disable_firewall: false` et Docker en `iptables: false`, `ip6tables: false`, `bridge: none`, `ip-forward: false` : **ni Kolla ni Docker ne touchent au pare-feu**, géré uniquement par le rôle `durcissement`.
+
+## Déployer / redéployer
+
+Sur le serveur, en root :
+
+```
+sudo -i
+export PATH=/opt/kolla-venv/bin:$PATH
+cd /etc/kolla
+kolla-ansible bootstrap-servers -i all-in-one   # installe Docker, /etc/hosts…
+kolla-ansible prechecks -i all-in-one
+kolla-ansible deploy -i all-in-one              # 20 à 60 min la première fois
+kolla-ansible post-deploy -i all-in-one         # génère clouds.yaml et admin-openrc.sh
+```
+
+Pour un `deploy` long, le lancer comme service pour survivre à une coupure SSH :
+
+```
+sudo systemd-run --unit=kolla-deploy \
+  --setenv=PATH=/opt/kolla-venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
+  --setenv=HOME=/root --working-directory=/etc/kolla \
+  bash -c 'kolla-ansible deploy -i /etc/kolla/all-in-one > /var/log/kolla-deploy.log 2>&1'
+journalctl -fu kolla-deploy   # ou : tail -f /var/log/kolla-deploy.log
+```
+
+## Après chaque opération Kolla : vérifier le pare-feu
+
+Kolla et Docker ne doivent créer aucune table nftables. Référence enregistrée
+dans `/tmp/nft-reference.txt` (à refaire après un changement voulu) :
+
+```
+sudo nft list tables          # attendu : table inet filter, table ip nat
+```
+
+Si une table étrangère apparaît, comprendre d'où elle vient, puis recharger le
+pare-feu depuis le Mac (sous filet anti-coupure) :
+
+```
+cd ansible && script -q /dev/null ansible-playbook reseau-openstack.yml -i inventory.ini \
+  -e durcissement_forcer_rechargement=true
+```
+
+## Utiliser le client openstack
+
+```
+sudo -i
+export OS_CLOUD=kolla-admin
+export OS_CLIENT_CONFIG_FILE=/etc/kolla/clouds.yaml
+openstack service list
+openstack compute service list
+openstack network agent list
+```
+
+## Pièges rencontrés
+
+- `kolla-ansible install-deps` : `No such file or directory: 'ansible-galaxy'` si le `bin` du venv n'est pas dans le `PATH`.
+- `prechecks` : `No module named 'docker'` — Kolla utilise le Python du venv, il faut `docker` et `dbus-python` **dans le venv** (fait par le rôle `kolla`).
+- Docker 29 crée des tables `ip6 nat` / `ip6 filter` malgré `iptables: false` : ajouter `ip6tables: false` (`docker_custom_config` dans `globals.yml`).
+- `kolla-genpwd` réécrit `passwords.yml` en `640` : le rôle remet `600`.