89 lines
5 KiB
Markdown
89 lines
5 KiB
Markdown
# Varion
|
|
|
|
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.
|