Paillasse/docs/runbooks/openstack.md

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.

Surcharges de configuration et projet des labs (étape 13)

• kolla/config/nova/nova-compute.conf (déposé par le rôle kolla dans /etc/kolla/config/nova/) :
  • resume_guests_state_on_host_boot = true : les VM redémarrent avec l'hôte (défaut Nova : elles restaient éteintes) ;
  • reserved_host_memory_mb = 15000 : Nova refuse au-delà de 22 VM eleve.petit (voir docs/capacite.md). Après modification : kolla-ansible reconfigure -i /etc/kolla/all-in-one --tags nova (les VM en cours ne sont pas arrêtées). Le lancer comme service pour survivre à une coupure SSH :

  sudo systemd-run --unit=kolla-reconfigure-nova --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 reconfigure -i /etc/kolla/all-in-one --tags nova > /var/log/kolla-reconfigure-nova.log 2>&1'
  

• Gabarit eleve.petit et quota du projet paillasse (40 instances, 40 vCPU, 30 Go) : rôle openstack-projet (ansible-playbook openstack-projet.yml).
• Vérifier ce que Placement accepte réellement : inventaire MEMORY_MB du fournisseur de ressources (total, reserved, allocation_ratio), par l'API Placement (le client osc-placement n'est pas installé).
• Services désactivés après un premier déploiement : leur unité systemd kolla-<service>-container est retirée par le rôle kolla (liste kolla_services_retires, aujourd'hui proxysql) et rangée dans /root/unites-retirees/.

Redémarrage de l'hôte (testé le 2026-10-09)

Tout revient seul : les 46 conteneurs Kolla sont relancés par leurs unités systemd (et non par Docker, politique no), les VM par Nova, le reste par systemd. SSH en ≈ 3 min, services Kolla et VM ACTIVE en moins de 10 min.

Avant : sauvegarde récente et restauration testée, accord d'Adam, aucune modification réseau ou pare-feu en attente. Relevé comparable avant/après : sudo /root/etat-serveur.sh (services, unités Kolla, conteneurs, pare-feu, écoutes, réseau OpenStack, VM, socket du correcteur, Horizon, HTTPS, statut).

Juste après le démarrage, la table nftables f2b-table est absente : fail2ban ne la crée qu'à son premier bannissement (normal).