f-50: lab: cycle de vie du serveur de lab Scaleway #50
Signed-off-by: GnomeZworc <nicolas.boufidjeline@g3e.fr>
This commit is contained in:
parent
01c67bd0f9
commit
28ce00cfa3
GPG key ID:
4406BBBF8845D632
5 changed files with 1347 additions and 0 deletions
10
docs/developpement/index.rst
Normal file
10
docs/developpement/index.rst
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
Développement
|
||||
=============
|
||||
|
||||
Outillage réservé au développement de two : il ne s'installe sur aucun hyperviseur et ne sert
|
||||
pas à exploiter un cluster.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
lab
|
||||
247
docs/developpement/lab.rst
Normal file
247
docs/developpement/lab.rst
Normal file
|
|
@ -0,0 +1,247 @@
|
|||
Lab de test multi-nœud
|
||||
======================
|
||||
|
||||
Ce qui fait l'intérêt de two ne se voit qu'à partir de **deux hyperviseurs** : sur un nœud isolé,
|
||||
le trafic reste sur le bridge local et l'absence de plan de contrôle passe inaperçue (voir
|
||||
:doc:`/deploiement/architecture-cluster`). Le lab reproduit la topologie du cluster —
|
||||
hyperviseurs, route reflector, switch L3 — sous forme de VM, sur un serveur physique loué à
|
||||
l'heure.
|
||||
|
||||
Le pourquoi des choix (serveur physique plutôt que VM cloud, câbles QEMU, MTU 9000, versions) est
|
||||
consigné sur le ticket `#50 <https://git.g3e.fr/syonad/two/issues/50>`_. Cette page décrit
|
||||
comment s'en servir.
|
||||
|
||||
.. note::
|
||||
|
||||
État actuel : seule l'étape **E0** est livrée — le cycle de vie du serveur qui portera le lab,
|
||||
avec ``scripts/lab-host.sh``. La description de la topologie et le lancement des VM viendront
|
||||
avec les étapes suivantes, et cette page avec elles.
|
||||
|
||||
Le serveur de lab
|
||||
-----------------
|
||||
|
||||
Un serveur **Scaleway Elastic Metal**, créé pour une campagne de tests puis supprimé.
|
||||
|
||||
.. list-table::
|
||||
:widths: 25 75
|
||||
|
||||
* - Offre
|
||||
- ``EM-B212X-SSD``, zone ``fr-par-1``, **facturation horaire** : 0,321 € HT de l'heure, sans
|
||||
frais de mise en service
|
||||
* - Matériel
|
||||
- 2 × Xeon E5-2620 v4 *or equivalent*, 256 Go, 2 × 1 To SSD
|
||||
* - Système
|
||||
- Debian 12, installé par Scaleway à la création
|
||||
* - Pourquoi Intel
|
||||
- lab3 est en Intel : two lance ses VM en ``-cpu host``, et KVM a deux implémentations
|
||||
distinctes (``kvm_intel``, ``kvm_amd``)
|
||||
|
||||
*Or equivalent* n'est pas une clause de style : le premier serveur livré était un
|
||||
**Xeon E5-2640 v3** (Haswell, la génération de lab3), pas le E5-2620 v4 annoncé. Relever
|
||||
``lscpu`` au début de chaque campagne.
|
||||
|
||||
Prérequis côté Scaleway
|
||||
-----------------------
|
||||
|
||||
#. **Un projet dédié au lab**, séparé de toute autre ressource. ``lab-host.sh down`` supprime
|
||||
tout serveur de lab du projet : il ne doit rien y avoir d'autre.
|
||||
#. **Une clé d'API limitée à ce projet**, avec les droits Elastic Metal et la lecture des clés SSH
|
||||
du projet. Rien d'autre.
|
||||
#. **Les clés SSH publiques enregistrées dans le projet**, injectées à l'installation : sans elle,
|
||||
le serveur serait facturé sans que personne puisse s'y connecter, et ``plan`` refuse de
|
||||
continuer.
|
||||
#. **Le quota Elastic Metal.** L'``EM-B212X-SSD`` exige un compte dont le moyen de paiement *et*
|
||||
l'identité sont validés ; le quota est alors de 2. Vérifier dans la console : Organisation →
|
||||
Quotas → Elastic Metal. Voir `les quotas Scaleway
|
||||
<https://www.scaleway.com/en/docs/organizations-and-projects/organization/organization-quotas/>`_.
|
||||
|
||||
Fichiers locaux
|
||||
---------------
|
||||
|
||||
Tout ce dont le script a besoin vit sous ``~/.config/two-lab/``, hors du dépôt.
|
||||
|
||||
``~/.config/two-lab/scaleway.env``
|
||||
Identifiants Scaleway, une ligne ``CLÉ=valeur`` chacun :
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
SCW_SECRET_KEY=<clé secrète>
|
||||
SCW_DEFAULT_PROJECT_ID=<identifiant du projet de lab>
|
||||
SCW_DEFAULT_ZONE=fr-par-1
|
||||
|
||||
* le fichier doit être en ``0600`` : le script refuse de s'en servir s'il est lisible par
|
||||
d'autres que son propriétaire ;
|
||||
* il est **lu, jamais exécuté** — pas de ``source`` ; seules ces trois clés sont reconnues ;
|
||||
* une variable d'environnement du même nom l'emporte sur le fichier ;
|
||||
* la clé d'accès (``SCW…``) n'est pas nécessaire : l'API REST n'authentifie que par la clé
|
||||
secrète, dans l'en-tête ``X-Auth-Token``.
|
||||
|
||||
Pour changer de clé, remplacer la ligne ``SCW_SECRET_KEY=`` ; rien d'autre à modifier.
|
||||
|
||||
``~/.config/two-lab/ssh/lab_ed25519``
|
||||
Clé SSH dédiée au lab, **sans phrase de passe**, pour que les sessions tournent sans
|
||||
intervention. Sa partie publique doit être enregistrée dans le projet. Quand elle existe, le
|
||||
script l'utilise **seule** (``IdentitiesOnly``, agent désactivé) ; sinon il retombe sur
|
||||
l'agent SSH.
|
||||
|
||||
Elle ne doit ouvrir que les serveurs éphémères du projet de lab : **ne jamais l'installer sur
|
||||
lab3 ni sur une machine durable**. En cas de doute, la retirer du projet et en générer une
|
||||
autre :
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mkdir -p ~/.config/two-lab/ssh && chmod 700 ~/.config/two-lab ~/.config/two-lab/ssh
|
||||
ssh-keygen -t ed25519 -N '' -C two-lab-automation -f ~/.config/two-lab/ssh/lab_ed25519
|
||||
|
||||
``~/.cache/two-lab/``
|
||||
État de la session en cours : adresse et utilisateur du serveur, ``known_hosts`` dédié. Vidé
|
||||
par ``down``.
|
||||
|
||||
Commandes
|
||||
---------
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
usage: lab-host.sh <commande> [arguments]
|
||||
|
||||
plan résout l'offre horaire, l'OS et les clés SSH, affiche la requête de création
|
||||
et le prix ; ne crée rien
|
||||
up crée le serveur de lab, attend la fin de son installation et son SSH
|
||||
status liste les serveurs de lab du projet
|
||||
ssh [commande] se connecte au serveur de lab
|
||||
down supprime tous les serveurs de lab du projet et attend leur disparition
|
||||
session [cmd] up, puis la commande distante (ou un shell), puis down quoi qu'il arrive
|
||||
|
||||
``plan`` et ``status`` sont **gratuits** ; ``up`` et ``session`` **créent un serveur facturé**.
|
||||
|
||||
Toujours commencer par ``plan``. Il valide la clé d'API, le quota d'offre, l'OS et les clés SSH,
|
||||
et montre exactement ce qui serait commandé :
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
$ scripts/lab-host.sh plan
|
||||
== offre : EM-B212X-SSD (ddaf8ba6-b2b2-4279-8af3-51930fb602f8), facturation hourly, stock available
|
||||
== prix : 0.321 EUR HT par heure, frais de mise en service 0 EUR
|
||||
== os : Debian 12 (Bookworm) (83640d93-a0b8-45ad-9c9f-30cae48380a4), utilisateur root
|
||||
== clés : 2 clé(s) SSH du projet
|
||||
== requête : POST /baremetal/v1/zones/fr-par-1/servers
|
||||
|
||||
``session`` est la forme normale d'usage : le serveur est supprimé à la fin, que la commande
|
||||
réussisse, échoue, ou que la session soit interrompue (Ctrl-C, ``TERM``, fermeture du terminal).
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
$ scripts/lab-host.sh session 'uname -a; lscpu | grep -E "Model name|^CPU\(s\)|Virtualization"; free -g | head -2; echo "nested=$(cat /sys/module/kvm_intel/parameters/nested)"; ls -l /dev/kvm'
|
||||
== création de two-lab (EM-B212X-SSD, 0.321 EUR/h HT)
|
||||
== serveur 2ecc1e6a-0de8-48c0-a198-93857eee5957 créé, facturé jusqu'à 'lab-host.sh down'
|
||||
== serveur 2ecc1e6a-0de8-48c0-a198-93857eee5957 : ordered, installation to_install
|
||||
== serveur 2ecc1e6a-0de8-48c0-a198-93857eee5957 : ready, installation installing
|
||||
…
|
||||
== serveur 2ecc1e6a-0de8-48c0-a198-93857eee5957 : ready, installation completed
|
||||
== SSH pas encore joignable, nouvel essai dans 20s
|
||||
…
|
||||
== prêt : root@<adresse>
|
||||
Linux two-lab 6.1.0-53-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.187-1 (2026-09-07) x86_64 GNU/Linux
|
||||
CPU(s): 32
|
||||
Model name: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
|
||||
…
|
||||
Virtualization: VT-x
|
||||
total used free shared buff/cache available
|
||||
Mem: 251 1 250 0 0 249
|
||||
nested=Y
|
||||
crw-rw---- 1 root kvm 10, 232 Oct 3 17:23 /dev/kvm
|
||||
== session terminée (code 0), suppression du serveur
|
||||
== suppression de 2ecc1e6a-0de8-48c0-a198-93857eee5957
|
||||
== aucun serveur de lab ne reste dans le projet
|
||||
|
||||
Extrait de la première campagne (lignes répétées remplacées par ``…``). Compter **environ 15 minutes** entre la création et le SSH disponible : 13 min 30 à la première
|
||||
campagne, suppression comprise. SSH ne répond pas tout de suite après la fin de l'installation —
|
||||
environ 100 secondes la première fois — d'où l'attente intégrée à ``up``. Le code de sortie de
|
||||
``session`` est celui de la commande distante.
|
||||
|
||||
``up``, ``ssh`` et ``down`` séparément servent au debug interactif — et laissent la suppression
|
||||
à la charge de l'utilisateur.
|
||||
|
||||
Facturation
|
||||
-----------
|
||||
|
||||
.. warning::
|
||||
|
||||
Un serveur Elastic Metal est facturé **de sa création à sa suppression, éteint compris**.
|
||||
Éteindre ne suffit pas : il faut supprimer. La granularité n'est pas documentée par Scaleway —
|
||||
compter chaque heure entamée comme une heure pleine.
|
||||
|
||||
Ce que le script garantit :
|
||||
|
||||
* il ne commande **jamais** d'offre mensuelle : il exige une seule offre au nom demandé, en
|
||||
facturation horaire, en stock et sans frais de mise en service, sinon il refuse avant toute
|
||||
création. La CLI ``scw`` n'est pas utilisée pour cette raison : son ``server create type=…``
|
||||
choisit l'offre par son seul nom et peut tomber sur la mensuelle, qui engage un mois ;
|
||||
* il refuse de créer un second serveur si un serveur de lab existe déjà ;
|
||||
* ``down`` agit sur **tous** les serveurs portant le tag ``two-lab`` dans le projet, et
|
||||
``session`` y ajoute l'identifiant reçu à la création : un serveur créé juste avant une
|
||||
interruption est rattrapé ;
|
||||
* une suppression refusée pendant la livraison ou l'installation est réessayée tant qu'elle dure,
|
||||
dans la limite du délai d'installation augmenté du délai de suppression ;
|
||||
* le serveur n'est déclaré supprimé qu'au 404 de l'API, jamais sur une erreur passagère ;
|
||||
* un échec de suppression se termine par ``SERVEUR(S) DE LAB TOUJOURS FACTURÉ(S)`` et un code
|
||||
d'erreur.
|
||||
|
||||
Ce qu'il ne peut pas garantir : un ``SIGKILL``, une coupure de courant ou une mise en veille du
|
||||
poste qui lance la session. En cas de doute, toujours :
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
scripts/lab-host.sh status
|
||||
scripts/lab-host.sh down
|
||||
|
||||
Diagnostic
|
||||
----------
|
||||
|
||||
``aucune clé SSH active dans le projet``
|
||||
Aucune clé SSH n'est enregistrée dans le projet de lab. En ajouter une dans la console (projet
|
||||
→ Clés SSH).
|
||||
|
||||
``offre horaire EM-B212X-SSD : 0 correspondance(s)``
|
||||
L'offre n'existe pas dans la zone en facturation horaire. Vérifier ``SCW_DEFAULT_ZONE``.
|
||||
|
||||
``création incertaine``
|
||||
La création a échoué ou n'a pas rendu d'identifiant. Le serveur a pu être créé malgré tout —
|
||||
cas typique : le quota (identité non validée), ou une réponse perdue. Le script indique s'il
|
||||
voit un serveur de lab ; dans tous les cas, lancer ``status`` puis ``down``.
|
||||
|
||||
``SSH injoignable``
|
||||
L'installation est terminée mais SSH ne répond pas après 10 minutes. Avec une clé matérielle
|
||||
(Yubikey), chaque connexion demande un PIN ou un toucher : utiliser la clé dédiée du lab. Le
|
||||
serveur est toujours facturé : ``down``.
|
||||
|
||||
``SERVEUR(S) DE LAB TOUJOURS FACTURÉ(S)``
|
||||
La suppression n'a pas abouti dans les délais. Relancer ``down`` ; si l'erreur persiste,
|
||||
supprimer depuis la console Scaleway.
|
||||
|
||||
``HTTP 403 insufficient permissions``
|
||||
La clé d'API est authentifiée mais n'a pas le droit demandé — en général la lecture des clés
|
||||
SSH du projet. Compléter la politique de la clé, limitée au projet.
|
||||
|
||||
Sécurité
|
||||
--------
|
||||
|
||||
* La clé secrète n'apparaît ni dans les arguments des processus (elle est passée à ``curl`` par
|
||||
un descripteur de fichier), ni dans les journaux, ni dans l'environnement de ``ssh``.
|
||||
* **Ne jamais lancer le script sous** ``bash -x`` : la trace afficherait la clé.
|
||||
* Le serveur n'expose que SSH, par clé. Le lab n'a aucune donnée personnelle ni secret de
|
||||
production.
|
||||
* Une clé secrète qui a circulé ailleurs que dans ``scaleway.env`` (conversation, terminal
|
||||
partagé, capture d'écran) se régénère.
|
||||
|
||||
Tests
|
||||
-----
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
bash scripts/lab-host_test.sh
|
||||
|
||||
Environ une minute et demie, sans réseau : la suite remplace ``curl`` par une fausse API Scaleway
|
||||
qui se place dans le pire cas (offre mensuelle listée avant l'horaire, serveurs d'autres projets,
|
||||
suppressions refusées, erreurs 503, serveur qui tarde à disparaître) et ``ssh`` par un faux client.
|
||||
Elle tourne sous bash 5 comme sous le bash 3.2 de macOS.
|
||||
|
|
@ -40,6 +40,9 @@ Par où commencer
|
|||
:doc:`/exploitation/index`
|
||||
Configuration, services, API de l'agent, métriques et diagnostic sur un nœud en service.
|
||||
|
||||
:doc:`/developpement/index`
|
||||
Outillage de développement de two, dont le lab de test multi-nœud sur serveur loué à l'heure.
|
||||
|
||||
:doc:`/concepts/index`
|
||||
Comment les éléments fonctionnent entre eux : modèle de données, modes réseau, cycle de vie,
|
||||
metadata. À lire avant de diagnostiquer un comportement inattendu.
|
||||
|
|
@ -57,6 +60,12 @@ Par où commencer
|
|||
|
||||
exploitation/index
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: Développement
|
||||
|
||||
developpement/index
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:caption: Interne
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue