GnomeZworc
eee15eb68e
Note de version 0.2.0 (Bael), et reprise des huit pages de docs/ qui parlaient de dnsmasq ou du DHCP. Ajouts de fond : la section Backend DHCP de la page de configuration, avec la procédure de bascule manuelle et l'avertissement qu'elle ne migre rien ; la section du serveur intégré dans les services ; et dans la page de diagnostic comment interroger la socket de contrôle, probe étant le point de départ le plus rapide quand une VM n'obtient pas d'adresse. Le nom de version se déduit du rang, pas du numéro : deuxième release, deuxième nom de codenames.md. Construit avec sphinx-build -W --keep-going, sans avertissement. Signed-off-by: GnomeZworc <nicolas.boufidjeline@g3e.fr>
3.6 KiB
syonad/two
Orchestrateur réseau et machines virtuelles mono-nœud, pensé pour être piloté par un logiciel plutôt que par un humain.
Il expose une API HTTP qui crée des VPC — isolés par network namespace —, des subnets — en VXLAN ou attachés à un bridge existant — et des VM QEMU/KVM raccordées à ces subnets, avec DHCP, routage et metadata cloud-init fournis automatiquement.
Installation
curl -O https://git.g3e.fr/syonad/two/raw/branch/main/scripts/deploy.sh
bash ./deploy.sh -t 0.1.0 -i
deploy.sh se met à jour lui-même depuis la branche, télécharge binaires, units systemd et
scripts depuis la release, et les vérifie contre le manifeste SHA256SUMS. Le drapeau -i
prépare l'host : paquets, module br_netfilter, sysctl, et bridges.
Options utiles :
| Option | Effet |
|---|---|
-t <tag> |
déployer une release donnée |
-b <branche> |
déployer depuis une branche au lieu d'une release |
-i |
préparer l'host (paquets, noyau, réseau) |
-u <iface> |
interface physique d'uplink, eno1 par défaut |
-B <bridge> |
bridge principal auquel l'uplink est rattaché |
-d |
dry-run : affiche les commandes sans les exécuter |
-V |
désactiver la vérification des sommes de contrôle |
Un déploiement relève les instances dnsmasq@, dhcp@ et metadata@ actives avant l'arrêt des
services, et les redémarre ensuite — c'est la seule façon de savoir lesquelles relancer.
Configuration
Un seul fichier, /etc/two/agent.yml, partagé par les trois binaires. Voir
conf/agent/config.exemple.yml pour l'ensemble des options :
chemins de la base et des sockets QEMU, pool de workers, correspondance des types d'interface vers
les bridges physiques, watchdog, API d'administration, journalisation.
Prise en main
# Un VPC, avec son CIDR interne
curl -X POST http://127.0.0.1:8080/vpcs \
-d '{"name": "vp-admin", "cidr": "192.168.0.0/16"}'
# Un subnet en VXLAN dans ce VPC
curl -X POST http://127.0.0.1:8080/subnets \
-d '{"name": "sn-000001", "vpc": "vp-admin", "mode": "vxlan", "vxlan_id": 1,
"iface_type": "vms", "interface_ip": "10.1.1.1", "cidr": "10.1.0.0/23"}'
# Une VM, avec une clé SSH et un user-data cloud-init en base64
curl -X POST http://127.0.0.1:8080/vms \
-d '{"name": "i-web", "memory": 2048, "cpus": 2,
"metadata": {"sshkey": "ssh-ed25519 AAAA…",
"user_data": "'"$(base64 -w0 < user-data.yml)"'"},
"interfaces": [{"subnet": "sn-000001", "ip": "10.1.1.2", "primary": true}],
"storage": [{"path": "/data/disks/vms/i-web.qcow2", "dev": "vda"}]}'
Les créations sont asynchrones : l'API répond 202 et l'état de la ressource passe de
creating à running en base. GET /vms/i-web renvoie l'état courant.
Une VM peut porter plusieurs interfaces, dans un même VPC ; exactement une doit être marquée
primary — elle porte la route par défaut et le serveur de metadata.
La spécification complète est dans api/agent.yaml.
Composants
| Binaire | Rôle |
|---|---|
agent |
processus principal : API, dispatcher, exécution, watchdog |
metadata |
serveur de metadata cloud-init, une instance par VM dans le netns du VPC |
db |
inspection de la base clé-valeur en ligne de commande |
L'agent prend -config, les deux autres -conf.
Versions
Les notes de version sont dans release_notes/. Chaque version porte un nom de
code, dérivé du rang de sa publication : anges et démons alternés, listés dans
release_notes/codenames.md.