Services systemd#
Quatre units, installées sous /opt/two/bin par deploy.sh. Les deux units DHCP
s’excluent : celle qui tourne dépend de dhcp.backend (voir Configuration).
Unit |
Instance |
Rôle |
|---|---|---|
|
— |
processus principal : API, dispatcher, exécution, watchdog |
|
|
dnsmasq lancé dans le netns du VPC, un par subnet — backend |
|
|
serveur DHCP intégré, un par subnet — backend |
|
|
serveur de metadata cloud-init, un par VM |
Les instances sont créées et pilotées par l’agent au fil des créations de subnets et de VM : il n’y a pas à les démarrer à la main en fonctionnement normal.
systemctl status agent
systemctl status 'dnsmasq@vp-admin_br-sn000001' # backend dnsmasq
systemctl status 'dhcp@vp-admin_br-sn000001' # backend two
systemctl status 'metadata@i-web'
dnsmasq#
Backend historique. Le script run-dnsmasq-in-netns.sh entre dans le netns puis exécute dnsmasq
avec un fichier de configuration par subnet, généré par l’agent :
Configuration |
|
Baux |
|
Journal |
|
PID |
|
Le fichier de baux et le journal sont les deux premiers endroits à regarder quand une VM n’obtient pas d’adresse.
Serveur DHCP intégré#
Backend two. Le script run-dhcp-in-netns.sh entre dans le netns puis exécute le binaire
dhcp, à qui il passe le bridge à servir et ses deux chemins de fichiers — il ne déduit rien et
ignore le netns dans lequel il tourne :
/opt/two/bin/dhcp -conf /etc/two/agent.yml \
-interface br-sn000001 \
-state /run/two/dhcp/vp-admin_br-sn000001.state \
-socket /run/two/dhcp/vp-admin_br-sn000001.sock
Socket de contrôle |
|
État |
|
Journal |
|
Il n’y a ni fichier de configuration ni fichier de baux. L’agent pousse l’état désiré sur la socket de contrôle : la configuration du subnet à sa création, une réservation par interface à chaque création ou suppression de VM. Les réservations sont statiques — une MAC inconnue n’obtient rien, et le serveur reste silencieux plutôt que de répondre par un refus.
Le fichier d’état appartient au processus, qui l’écrit et le relit à son démarrage. L’agent ne
l’écrit jamais ; il le supprime seulement, à la création du subnet pour écarter un résidu et à sa
suppression après avoir arrêté l’unit. Il vit dans /run parce qu’il n’a aucun sens sans le
netns, qui ne survit pas au redémarrage de l’host.
Diagnostic : voir Diagnostic, qui montre comment interroger la socket.
QEMU n’est pas une unit#
Les processus QEMU sont lancés par systemd-run --scope, jamais en unit transitoire. Un
scope est exécuté par le processus appelant et hérite donc du network namespace posé par
l’agent ; une unit transitoire, forkée par PID 1, démarrerait dans le netns racine et ne verrait
pas le tap de la VM.
Conséquence pratique : les VM n’apparaissent pas dans systemctl list-units mais dans
systemd-cgls, et elles ne survivent pas à un systemctl stop agent suivi d’un
redémarrage — l’agent ne réattache pas les VM existantes.
Sockets par VM#
/run/two/vms/serial/<vm>.sock console série
/run/two/vms/monitor/<vm>.sock monitor QEMU
/run/two/vms/qmp/<vm>.sock QMP (utilisé par l'agent)
socat -,raw,echo=0 UNIX-CONNECT:/run/two/vms/serial/i-web.sock
Arrêt de l’agent#
L’ordre d’arrêt est imposé : 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 — fermer Badger sous un écrivain
concurrent est pire qu’un rejeu du journal au démarrage suivant. Un message à ce sujet dans le
journal au moment d’un stop n’est donc pas une anomalie.
Mise à jour#
deploy.sh relève les instances dnsmasq@, dhcp@ et metadata@ actives avant d’arrêter les
services, et les redémarre ensuite : c’est la seule façon de savoir lesquelles relancer. Arrêter
les services à la main avant de lancer le script fait perdre cette liste.