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>
132 lines
4.8 KiB
ReStructuredText
132 lines
4.8 KiB
ReStructuredText
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 :doc:`configuration`).
|
|
|
|
.. list-table::
|
|
:header-rows: 1
|
|
:widths: 28 32 40
|
|
|
|
* - Unit
|
|
- Instance ``%i``
|
|
- Rôle
|
|
* - ``agent.service``
|
|
- —
|
|
- processus principal : API, dispatcher, exécution, watchdog
|
|
* - ``dnsmasq@.service``
|
|
- ``<netns>_<bridge>``
|
|
- dnsmasq lancé dans le netns du VPC, un par subnet — backend ``dnsmasq``
|
|
* - ``dhcp@.service``
|
|
- ``<netns>_<bridge>``
|
|
- serveur DHCP intégré, un par subnet — backend ``two``
|
|
* - ``metadata@.service``
|
|
- ``<nom de la VM>``
|
|
- 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.
|
|
|
|
.. code-block:: bash
|
|
|
|
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 :
|
|
|
|
.. list-table::
|
|
:widths: 40 60
|
|
|
|
* - Configuration
|
|
- ``/etc/dnsmasq.d/<netns>_<bridge>.conf``
|
|
* - Baux
|
|
- ``/run/dnsmasq-<netns>_<bridge>.leases``
|
|
* - Journal
|
|
- ``/var/log/dnsmasq-<netns>_<bridge>.log``
|
|
* - PID
|
|
- ``/run/dnsmasq-<netns>_<bridge>.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 :
|
|
|
|
.. code-block:: bash
|
|
|
|
/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
|
|
|
|
.. list-table::
|
|
:widths: 40 60
|
|
|
|
* - Socket de contrôle
|
|
- ``/run/two/dhcp/<netns>_<bridge>.sock``
|
|
* - État
|
|
- ``/run/two/dhcp/<netns>_<bridge>.state``
|
|
* - Journal
|
|
- ``journalctl -u 'dhcp@<netns>_<bridge>'``
|
|
|
|
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 :doc:`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
|
|
--------------
|
|
|
|
.. code-block:: text
|
|
|
|
/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)
|
|
|
|
.. code-block:: bash
|
|
|
|
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.
|