- Go 95.2%
- Shell 4.7%
GnomeZworc
cbf580e91e
La bibliothèque DHCP retenue pour #46 (github.com/insomniacslk/dhcp) déclare go 1.25.0. Relèvement de la directive et de la toolchain ; go.sum est inchangé, la bibliothèque n'entrant qu'avec le code qui l'importe. Vérifié : build darwin, build linux/amd64 en CGO_ENABLED=0 des trois binaires, go vet, et trois passes de go test ./... sans échec. Signed-off-by: GnomeZworc <nicolas.boufidjeline@g3e.fr> |
||
|---|---|---|
| .forgejo/workflows | ||
| api | ||
| cmd | ||
| conf/agent | ||
| internal | ||
| pkg | ||
| release_notes | ||
| scripts | ||
| systemd | ||
| .gitignore | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| README.md | ||
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@ 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.