Michael

Michael#

Première version stable de syonad/two, orchestrateur réseau et VM mono-nœud.

Fonctionnalités#

API et cycle de vie

  • API HTTP /vpcs, /subnets, /vms : création et suppression asynchrones (202 + état en base)

  • États unifiés pour les trois types de ressource : creating → running → deleting → deleted, avec error en cas d’échec d’exécution ; suppression autorisée depuis running et error

  • Migration au démarrage de l’agent : toute ressource restée dans un état transitoire est basculée en error, la file de travail étant en mémoire

  • Arrêt gracieux : serveurs HTTP, puis drainage des workers, puis fermeture de la base. Si le budget d’arrêt est dépassé, la base n’est pas fermée — la rejouer au démarrage suivant vaut mieux que de la fermer sous un écrivain concurrent

Réseau

  • VPC isolés par network namespace, subnets en mode vxlan ou bridge

  • DHCP par subnet via instances dnsmasq@ dédiées, entrées ip→mac en base, fichier de baux propre à chaque instance

  • Toutes les routes sont distribuées par l’option 121 : route vers le serveur de metadata, route du VPC, et route par défaut. L’option 3 reste émise pour les clients qui n’implémentent pas la 121

  • default_route choisit le next-hop de la route par défaut : l”interface_ip du subnet par défaut, sinon la gateway fournie ou celle déduite de l’host

  • gateway optionnelle par subnet, non validée par l’agent

  • Isolation du DHCP par ebtables, redirection du service de metadata par iptables

Machines virtuelles

  • Plusieurs interfaces réseau par VM, dans un même VPC. La position de l’interface détermine son slot PCI, donc son nom dans le guest ; exactement une interface est primaire et porte la route par défaut et le serveur de metadata

  • Démarrage QEMU/KVM avec plusieurs disques et ordre de démarrage explicite

  • Amorçage UEFI optionnel (OVMF), avec magasin de variables par VM

  • Serveur de metadata cloud-init par VM (metadata@), sans base de données dans le processus

  • Les VMs survivent à l’arrêt de l’agent : QEMU est lancé hors de son cgroup via systemd-run

Metadata cloud-init

  • Objet metadata dans la création de VM : password, sshkey, user_data

  • user_data transmis en base64, ce qui autorise les charges gzip+base64 ; un encodage invalide est refusé en 400, jamais servi vide en silence

  • Un document fourni est servi verbatim, un document absent retombe sur le modèle par défaut, et un document explicitement vide est servi vide — les trois cas sont distincts

  • Le compte syonad n’est créé que si un mot de passe ou une clé est fourni, et reste verrouillé quand seule une clé l’est. L’agent n’impose aucune modification du compte root

Exploitation

  • Watchdog de cohérence : vérifie périodiquement que les ressources running existent encore sur le système et signale les écarts. Lecture seule, il ne répare jamais. Désactivé par défaut, activé dans le fichier d’exemple

  • API d’administration en lecture seule sur la boucle locale, pour inspecter la base

  • Métriques Prometheus : nombre de VPC, subnets et VMs par état

  • deploy.sh avec profils d’host (kvm), préparation système déléguée à bootstrap_kvm.sh

  • Units systemd et scripts publiés comme assets de release, avec manifeste SHA256SUMS vérifié au déploiement

Périmètre et limites connues#

  • Un seul nœud : pas d’ordonnanceur ni de placement entre hyperviseurs

  • Pas de rollback en cas d’échec partiel d’une création — les ressources réseau orphelines ne sont pas nettoyées automatiquement

  • API destinée à un appelant logiciel : la validation de cohérence des entrées (CIDR, VXLAN ID, format des noms, joignabilité d’une gateway) est à la charge de l’appelant

  • Le mode de subnet public_ip est accepté par l’API et par la sélection des routes DHCP, mais sa mise en place réseau n’existe pas : créer un tel subnet échoue explicitement

  • Les interfaces multiples d’une VM doivent appartenir au même VPC

  • Le réseau des guests est configuré par le DHCP seul ; le network-config cloud-init servi est sans effet et ne doit pas être « corrigé » sans mesurer l’impact sur les VM existantes

  • Modifier les routes d’une VM déjà démarrée ne prend effet qu’au renouvellement du bail, soit jusqu’à six heures plus tard, ou à son redémarrage

  • vm/<name>/password contient un hash, stocké en clair en base et restitué par l’API d’administration ; celle-ci est désactivée par défaut et n’écoute que sur la boucle locale

  • L’API de l’agent n’a pas d’authentification : son exposition réseau doit être restreinte

  • Les packages internal/netns, netif, qemu, vm, iptables et ebtables ne fonctionnent que sous Linux

Installation#

curl -O https://git.g3e.fr/syonad/two/raw/branch/main/scripts/deploy.sh
bash ./deploy.sh -t 0.1.0 -i    # -i : préparation de l'host (paquets, kernel, bridges)

deploy.sh se vérifie lui-même contre la branche et télécharge les binaires, les units et le manifeste depuis cette release.