11.17 Invoquer guix deploy

Nous avons déjà vu les déclarations de operating-system utilisées pour gérer la configuration d’une machine localement. Supposez que vous ayez besoin de configurer plusieurs machines — peut-être que vous gérez un service web comprenant plusieurs serveurs. guix deploy vous permet d’utiliser les mêmes déclarations de systèmes d’exploitation pour gérer plusieurs hôtes distants en même temps dans le même « déploiement » logique.

Remarque : La fonctionnalité décrite dans cette section est toujours en cours de développement et est sujette à changement. Contactez-nous sur guix-devel@gnu.org !

guix deploy fichier

Une telle invocation déploiera les machines en lesquelles le code de fichier s’évalue. Par exemple, fichier peut contenir une définition comme celle-ci :

;; Ceci est le déploiement Guix d'un système « minimal » sans
;; serveur d'affichage X11, vers une machine dont le démon SSH
;; écoute sur localhost:2222. Une configuration comme celle-ci
;; est appropriée pour les machines virtuelles dont les ports sont relayés
;; vers l'interface de bouclage de l'hôte.

(use-service-modules networking ssh)
(use-package-modules bootloaders)

(define %system
  (operating-system
   (host-name "gnu-deployed")
   (timezone "Etc/UTC")
   (bootloader (bootloader-configuration
                (bootloader grub-bootloader)
                (target '("/dev/vda"))
                (terminal-outputs '(console))))
   (file-systems (cons (file-system
                        (mount-point "/")
                        (device "/dev/vda1")
                        (type "ext4"))
                       %base-file-systems))
   (services
    (append (list (service dhcp-client-service-type)
                  (service openssh-service-type
                           (openssh-configuration
                            (permit-root-login #t)
                            (allow-empty-passwords? #t))))
            %base-services))))

(list (machine
       (operating-system %system)
       (environment managed-host-environment-type)
       (configuration (machine-ssh-configuration
                       (host-name "localhost")
                       (system "x86_64-linux")
                       (user "alice")
                       (identity "./id_rsa")
                       (port 2222)))))

Le fichier devrait s’évaluer en une liste d’objets machine. Cet exemple, lors du déploiement, créera une nouvelle génération sur le système distant en réalisant la déclaration operating-system %system. environment et configuration spécifient comme la machine devrait être provisionnée — c.-à-d. comment les ressources sont créées et gérées. L’exemple ci-dessus ne crée aucune ressource, car un 'managed-host est une machine qui fait déjà tourner le système Guix et est disponible sur le réseau. Cela est un cas particulièrement simple ; un déploiement plus complexe pourrait impliquer, par exemple, le démarrage de machines virtuels chez un fournisseur de serveurs privés virtuels (VPS). Dans ce cas, une type d’environnement différent devrait être utilisé.

Prenez note que vous devez d’abord générer une paire de clés sur la machine coordinatrice pour permettre au démon d’exporter les archives signées des fichiers du dépôt (voir Invoquer guix archive), bien que cette étape soit automatique sur Guix System :

# guix archive --generate-key

Chaque machine cible doit autoriser la clé de la machine maître afin qu’elle accepte les objets de stockage qu’elle reçoit du coordinateur :

# guix archive --authorize < coordinator-public-key.txt

user, dans cet exemple, spécifie le nom du compte utilisateur à utiliser pour se connecter lors du déploiement. Sa valeur par défaut est root, mais la connexion SSH en root peut être interdite dans certains cas. Pour contourner cela, guix deploy peut se connecter en tant qu’utilisateur non-privilégié et utiliser sudo pour récupérer les privilèges. Cela ne fonctionnera que si sudo est actuellement installé sur la machine distante et peut être invoqué de manière non interactive par user. C’est-à-dire que la ligne sudoers permettant à user d’utiliser sudo doit contenir l’attribut NOPASSWD. Cela peut se faire avec le bout de configuration du système d’exploitation suivant :

(use-modules ...
             (gnu system))               ;pour %sudoers-specification

(define %user "username")

(operating-system
  ...
  (sudoers-file
     (plain-file "sudoers"
                 (string-append (plain-file-content %sudoers-specification)
                                (format #f "~a ALL = NOPASSWD: ALL~%"
                                        %user)))))

Pour plus d’informations sur le format du fichier sudoers, consultez man sudoers.

Une fois que vous avez déployé un système sur un ensemble de machines, vous trouverez utile de lancer une commande sur chacune. Les options --execute ou -x vous le permet. L’exemple ci-dessous lance uname -a sur toutes les machines listées dans le fichier de déploiement :

guix deploy fichier -x -- uname -a

Ce que vous devrez souvent faire après un déploiement est de redémarrer les services spécifiques sur toutes les machines, ce qui peut se faire de cette manière :

guix deploy file -x -- herd restart service

La commande guix deploy -x renvoie zéro si et seulement si la commande réussi sur toutes les machines.

Voici les types de données que vous devrez connaitre pour écrire un fichier de déploiement.

Type de données :machine

C’est le type de données représentant une seule machine dans un déploiement Guix hétérogène.

operating-system

L’objet de la configuration du système d’exploitation à déployer.

environment

Un environment-type décrit comment la machine est provisionnée.

configuration (par défaut : #f)

Un objet décrivant la configuration de l’environnement de la machine. Si l’objet environment a une configuration par défaut, vous pouvez utiliser #f. Si vous utilisez #f mais que l’environnement n’a pas de configuration par défaut, une erreur sera renvoyée.

Type de données :machine-ssh-configuration

C’est le type de données représentant les paramètres du client SSH pour une machine qui a pour environment managed-host-environment-type.

host-name

build-locally? (par défaut : #t)

Si la valeur est fausse, les dérivations du système seront construites sur la machine qui est déployée.

system

Le type de système décrivant l’architecture de la machine déployée pour—par exemple, "x86_64-linux".

authorize? (par défaut : #t)

Si la valeur est vraie, la clé de signature du coordinateur sera ajoutée au porteclé des ACL de la machine distante.

port (par défaut : 22)

user (par défaut : "root")

identity (par défaut : #f)

Si spécifié, le chemin d’accès à la clé privée SSH à utiliser pour s’authentifier auprès de l’hôte distant.

host-key (par défaut : #f)

Cela devrait être la clé de l’hôte SSH de la machine, qui ressemble à cela :

ssh-ed25519 AAAAC3Nz… root@example.org

Quand host-key est #f, le serveur est authentifié avec le fichier ~/.ssh/known_hosts, exactement comme le ferait le client ssh OpenSSH.

allow-downgrades? (par défaut : #f)

Autoriser ou non d’éventuels déclassements.

Comme guix sysetm reconfigure, guix deploy compare les commits du canal actuellement déployé sur l’hôte distant (renvoyé par guix system describe) à ceux utilisés (renvoyés par guix describe) pour déterminer si les commits actuellement utilisés descendent de ceux déployés. Lorsque ce n’est pas le cas et que allow-downgrades? est faux, cela lève une erreur. Cela permet de s’assurer que vous ne déployez pas accidentellement une version plus ancienne version les machines distantes.

safety-checks? (par défaut : #t)

Indique s’il faut lancer des « vérifications de cohérence » avant le déploiement. Cela comprend la vérification que les périphériques et les systèmes de fichiers référencés dans la configuration du système d’exploitation existent vraiment sur la machine cible, et la vérification que les modules Linux nécessaires à l’accès aux périphériques de stockage à l’amorçage se trouvent dans le champ initrd-modules du système d’exploitation.

Ces vérification s’assurent que vous ne déployez pas par inadvertance un système qui ne pourra pas démarrer. Soyez prudent avant de les désactiver !

Type de données :digital-ocean-configuration

C’est le type de données décrivant le Droplet qui devrait être créé pour une machine avec un environment valant digital-ocean-environment-type.

ssh-key

Le chemin vers la clé SSH privée à utiliser pour s’authentifier avec l’hôte distant. Dans le futur, le champ pourrait ne plus exister.

tags

Une liste « d’attributs » qui identifient la machine de manière unique. Il faut faire attention à ce que deux machine du déploiement n’aient pas le même ensemble d’attributs.

region

Le nom d’une région de Digital Ocean, comme "nyc3".

taille

Le nom d’une taille de Digital Ocean, comme "s-1vcpu-1gb"

enable-ipv6?

Indique s’il faut créer une IPv6 pour le droplet.