Installation d’un hyperviseur#
Cette page installe l’agent sur un hyperviseur. Le réseau du cluster — routage entre nœuds, plan de contrôle — est traité à part : voir Déploiement d’un cluster.
Prérequis#
Un host Linux avec KVM, sur lequel vous avez root. Les opérations réseau (network
namespaces, netlink, VXLAN, ebtables, iptables) et QEMU ne fonctionnent que sous Linux.
Déploiement#
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 avant toute action — s’il diffère, il se
réécrit et demande d’être relancé. Il télécharge ensuite binaires, units systemd et scripts
depuis la release, et les vérifie contre le manifeste SHA256SUMS.
Option |
Effet |
Défaut |
|---|---|---|
|
déployer une release donnée |
dernière |
|
branche utilisée pour l’auto-mise à jour du script |
|
|
profil d’host ; seul |
|
|
préparer l’host : paquets, noyau, réseau |
désactivé |
|
interface physique d’uplink |
|
|
bridge principal, auquel l’uplink est rattaché |
|
|
bridge supplémentaire, créé vide et réservé |
|
|
délai avant le redémarrage de secours pendant la migration réseau |
|
|
dry-run : affiche les commandes sans les exécuter |
désactivé |
Les options booléennes actives par défaut se désactivent par leur forme longue négative :
--nopackages, --nonetwork, --noverify, --noup_script.
Avertissement
--noverify désactive la seule vérification d’intégrité des artefacts téléchargés. Ne
l’utiliser que pour diagnostiquer un manifeste cassé, jamais en déploiement courant.
Ce que fait -i#
Paquets — qemu-system-x86, ovmf, dnsmasq, ebtables, iptables,
nfs-common, jq, curl. Le service dnsmasq du système est ensuite désactivé et
masqué : il prendrait le port 53 en concurrence des instances dnsmasq@ que l’agent lance
dans les netns.
dnsmasq reste installé même avec dhcp.backend: two : le backend intégré ne le remplace que
pour les subnets créés après la bascule, et le paquet est nécessaire tant qu’un hyperviseur peut
revenir en arrière. Voir Configuration.
Noyau — chargement de br_netfilter, puis net.ipv4.ip_forward = 1 et
net.bridge.bridge-nf-call-iptables = 1. Cette dernière clé est requise par la DNAT vers
le serveur de metadata : sans elle, iptables ne voit pas le trafic bridgé des VM et cloud-init
ne se provisionne pas. Contrepartie assumée : tout le trafic inter-VM traverse les tables NAT.
Réseau — création du bridge réservé, puis rattachement de l’uplink au bridge principal, l’adresse et la route par défaut étant déplacées de l’interface physique vers le bridge.
Danger
La migration réseau coupe le réseau de l’host si elle échoue à mi-parcours, sans console
de secours. Deux garde-fous sont en place : un redémarrage de secours armé avant l’opération
(-R, 120 s par défaut) qui ramène la configuration d’origine puisque rien n’est écrit sur
disque, et l’exécution de la séquence sous systemd plutôt que dans la session SSH, pour
qu’une coupure de SSH ne l’interrompe pas.
Le désarmement n’a lieu qu’après un ping réussi vers la passerelle. Prévoir un accès
physique ou console avant de lancer un -i à distance sur un host de production.
Host sans état#
L’hyperviseur est stateless : sa racine est en tmpfs, rien de ce que pose -i ne survit à
un redémarrage. deploy.sh --bootstrap est donc rejoué à chaque démarrage — c’est le
mécanisme normal, pas une réparation.
Binaires installés#
Binaire |
Rôle |
Drapeau de config |
|---|---|---|
|
processus principal : API, dispatcher, exécution, watchdog |
|
|
serveur de metadata cloud-init, une instance par VM dans le netns du VPC |
|
|
inspection de la base clé-valeur en ligne de commande |
|
|
serveur DHCP intégré, une instance par subnet dans le netns du VPC ; démarré uniquement
avec |
|
Les quatre partagent le même fichier, /etc/two/agent.yml — voir
Configuration. dhcp reçoit en plus son bridge et ses deux chemins de
fichiers en paramètres, posés par son script d’enrobage.
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.
Vérifier l’installation#
systemctl status agent
curl -s http://127.0.0.1:8080/vpcs
Une liste JSON — vide au premier démarrage — signifie que l’API répond. Passez à Premier VPC, premier subnet, première VM.
Important
L’API de l’agent n’a aucune authentification. Avant d’ouvrir le port au-delà de la boucle locale, lisez l’avertissement de Configuration : quiconque atteint ce port pilote la totalité de l’hyperviseur.