Suivant: Exécuter Guix sur une machine virtuelle, Précédent: Invoquer guix system, Monter: Configuration du système [Table des matières][Index]
guix deployNous 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.
C’est le type de données représentant une seule machine dans un déploiement Guix hétérogène.
operating-systemL’objet de la configuration du système d’exploitation à déployer.
environmentUn 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.
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-namebuild-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.
systemLe 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 !
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-keyLe 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.
tagsUne 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.
regionLe nom d’une région de Digital Ocean, comme "nyc3".
sizeLe nom d’une taille de Digital Ocean, comme "s-1vcpu-1gb"
enable-ipv6?Indique s’il faut créer une IPv6 pour le droplet.
This is the data type describing the server that should be created for a
machine with an environment of hetzner-environment-type. It
allows you to configure deployment to a VPS (virtual private
server) hosted by Hetzner.
allow-downgrades? (par défaut : #f)Autoriser ou non d’éventuels déclassements.
authorize? (par défaut : #t)If true, the public signing key "/etc/guix/signing-key.pub" of the
machine that invokes guix deploy will be added to the operating
system ACL keyring of the target machine.
build-locally? (par défaut : #t)If true, system derivations will be built on the machine that invokes
guix deploy, otherwise derivations are build on the target
machine. Set this to #f if the machine you are deploying from has a
different architecture than the target machine and you can’t build
derivations for the target architecture by other means, like offloading
(voir Utiliser le dispositif de déchargement) or emulation
(voir Transparent Emulation with QEMU).
delete? (default: #t)If true, the server will be deleted when an error happens in the provisioning phase. If false, the server will be kept in order to debug any issues.
labels (default: '())A user defined alist of key/value pairs attached to the SSH key and the
server on the Hetzner API. Keys and values must be strings,
e.g. '(("environment" . "development")). For more information, see
Labels.
location (default: "fsn1")The name of a location to create the server in. For example, "fsn1" corresponds
to the Hetzner site in Falkenstein, Germany, while "sin" corresponds
to its site in Singapore.
server-type (default: "cx42")The name of the
server
type this virtual server should be created with. For example,
"cx42" corresponds to a x86_64 server that has 8 VCPUs, 16 GB of
memory and 160 GB of storage, while "cax31" to the AArch64
equivalent. Other server types and their current prices can be found
here.
ssh-keyThe file name of the SSH private key to use to authenticate with the remote host.
When deploying a machine for the first time, the following steps are taken to provision a server for the machine on the Hetzner Cloud service:
Once the server has been provisioned and SSH is available, deployment
continues by delegating it to the managed-host-environment-type.
Servers on the Hetzner Cloud service can be provisioned on the AArch64
architecture using UEFI boot mode, or on the x86_64 architecture using BIOS
boot mode. The (gnu machine hetzner) module exports the
%hetzner-os-arm and %hetzner-os-x86 operating systems that are
compatible with those two architectures, and can be used as a base for
defining your custom operating system.
The following example shows the definition of two machines that are deployed
on the Hetzner Cloud service. The first one uses the %hetzner-os-arm
operating system to run a server with 16 shared vCPUs and 32 GB of RAM on
the aarch64 architecture, the second one uses the
%hetzner-os-x86 operating system on a server with 16 shared vCPUs and
32 GB of RAM on the x86_64 architecture.
(use-modules (gnu machine) (gnu machine hetzner)) (list (machine (operating-system %hetzner-os-arm) (environment hetzner-environment-type) (configuration (hetzner-configuration (server-type "cax41") (ssh-key "/home/charlie/.ssh/id_rsa")))) (machine (operating-system %hetzner-os-x86) (environment hetzner-environment-type) (configuration (hetzner-configuration (server-type "cpx51") (ssh-key "/home/charlie/.ssh/id_rsa")))))
Passing this file to guix deploy with the environment variable
GUIX_HETZNER_API_TOKEN set to a valid Hetzner
API key should provision two machines for you.
Suivant: Exécuter Guix sur une machine virtuelle, Précédent: Invoquer guix system, Monter: Configuration du système [Table des matières][Index]