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.
|