Aufruf von guix deploy (Referenzhandbuch zu GNU Guix)

11.17 `guix deploy` aufrufen

Wir haben bereits gesehen, wie die Konfiguration einer Maschine mit operating-system-Deklarationen lokal verwaltet werden kann. Doch was ist, wenn Sie mehrere Maschinen konfigurieren möchten? Vielleicht kümmern Sie sich um einen Dienst im Web, der über mehrere Server verteilt ist. Mit guix deploy können Sie ebensolche operating-system-Deklarationen verwenden, um mehrere entfernte Rechner („Hosts“) gleichzeitig in einer logischen Bereitstellung (einem „Deployment“) zu verwalten.

Anmerkung: Die in diesem Abschnitt beschriebenen Funktionalitäten befinden sich noch in der Entwicklung und können sich ändern. Kontaktieren Sie uns auf guix-devel@gnu.org!

guix deploy Datei

Mit einem solchen Aufruf werden diejenigen „Maschinen“ bereitgestellt, zu denen der Code in der Datei ausgewertet wird. Zum Beispiel könnte die Datei eine solche Definition enthalten:

;; Dies ist eine Guix-Bereitstellung einer minimalen Installation ohne
;; X11-Anzeigeserver auf eine Maschine, auf der ein SSH-Daemon auf
;; localhost:2222 lauscht. So eine Konfiguration kann für virtuelle
;; Maschinen geeignet sein, deren Ports an die Loopback-Schnittstelle
;; ihres Wirtssystems weitergeleitet werden.

(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)
                (targets '("/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)))))

Die Datei sollte zu einer Liste von machine-Objekten ausgewertet werden. Wenn dieses Beispiel aufgespielt wird, befindet sich danach eine neue Generation auf dem entfernten System, die der operating-system-Deklaration %system entspricht. Mit environment und configuration wird die Methode zur Belieferung der Maschine („Provisioning“) angegeben, d.h. wie sie angesteuert werden soll, um dort Rechenressourcen anzulegen und zu verwalten. Im obigen Beispiel werden keine Ressourcen angelegt, weil 'managed-host für eine Maschine mit bereits laufendem Guix-System steht, auf die über das Netzwerk zugegriffen werden kann. Das ist ein besonders einfacher Fall; zu einer komplexeren Bereitstellung könnte das Starten virtueller Maschinen über einen Anbieter für „Virtual Private Servers“ (VPS) gehören. In einem solchen Fall würde eine andere Art von Umgebung als environment angegeben werden.

Beachten Sie, dass Sie zunächst ein Schlüsselpaar auf der Koordinatormaschine erzeugen lassen müssen, damit der Daemon signierte Archive mit Dateien aus dem Store exportieren kann (siehe guix archive aufrufen). Auf Guix System geschieht dies automatisch.

# guix archive --generate-key

Jede Zielmaschine muss den Schlüssel der Hauptmaschine autorisieren, damit diese Store-Objekte von der Koordinatormaschine empfangen kann:

# guix archive --authorize < öffentlicher-schlüssel-koordinatormaschine.txt

In dem Beispiel wird unter user der Name des Benutzerkontos angegeben, mit dem Sie sich zum Aufspielen auf der Maschine anmelden. Der Vorgabewert ist root, jedoch wird eine Anmeldung als root über SSH manchmal nicht zugelassen. Als Ausweg kann guix deploy Sie erst mit einem „unprivilegierten“ Benutzerkonto ohne besondere Berechtigungen anmelden, um danach automatisch mit sudo die Berechtigungen auszuweiten. Damit das funktioniert, muss sudo auf der entfernten Maschine installiert und durch das user-Konto ohne Nutzerinteraktion aufrufbar sein; mit anderen Worten muss die Zeile in sudoers, die das user-Benutzerkonto zum Aufruf von sudo berechtigt, mit dem NOPASSWD-Tag versehen sein. Dazu kann das folgende Schnipsel in die Betriebssystemkonfiguration eingefügt werden:

(use-modules …
             (gnu system))   ;macht %sudoers-specification verfügbar

(define %user "benutzername")

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

Weitere Informationen über das Format der sudoers-Datei erhalten Sie, wenn Sie man sudoers ausführen.

Wenn Sie ein System auf einige Maschinen aufgespielt haben, möchten Sie vielleicht alle genannten Maschinen einen Befehl ausführen lassen. Mit der Befehlszeilenoption --execute oder -x können Sie das bewirken. Folgendes Beispiel zeigt, wie Sie uname -a auf allen in der Bereitstellungsdatei aufgelisteten Maschinen ausführen:

guix deploy Datei -x -- uname -a

Eine Sache, die häufig nach dem Aufspielen zu tun ist, ist, bestimmte Dienste auf allen Maschinen neu zu starten. Das geht so:

guix deploy Datei -x -- herd restart Dienst

Der Befehl guix deploy -x liefert genau dann null zurück, wenn sein Befehl auf allen Maschinen erfolgreich war.

Hier sehen Sie die Datentypen, die Sie kennen müssen, wenn Sie eine Bereitstellungsdatei schreiben.

Datentyp: machine

Dieser Datentyp steht für eine einzelne Maschine beim Bereitstellen auf mehrere verschiedene Maschinen.

operating-system: Das Objekt mit der aufzuspielenden Betriebssystemkonfiguration.
environment: Auf welcher Art von Umgebung die Maschine läuft. Der hier angegebene environment-type steht dafür, wie die Maschine beliefert wird („Provisioning“).
configuration (Vorgabe: #f): Dieses Objekt gibt die bestimmte Konfiguration der Umgebung (environment) der Maschine an. Falls es für diese Umgebung eine Vorgabekonfiguration gibt, kann auch #f benutzt werden. Wenn #f für eine Umgebung ohne Vorgabekonfiguration benutzt wird, wird ein Fehler ausgelöst.

Datentyp: machine-ssh-configuration

Dieser Datentyp repräsentiert die SSH-Client-Parameter einer Maschine, deren Umgebung (environment) vom Typ managed-host-environment-type ist.

host-name

build-locally? (Vorgabe: #t)

Wenn es falsch ist, werden Ableitungen für das System auf der Maschine erstellt, auf die es aufgespielt wird.

system

Der Systemtyp, der die Architektur der Maschine angibt, auf die aufgespielt wird – z.B. "x86_64-linux".

authorize? (Vorgabe: #t)

Wenn es wahr ist, wird der Signierschlüssel des Koordinators zum ACL-Schlüsselbund (der Access Control List, deutsch Zugriffssteuerungsliste) der entfernten Maschine hinzugefügt.

port (Vorgabe: 22)

user (Vorgabe: "root")

identity (Vorgabe: #f)

Wenn dies angegeben wird, ist es der Pfad zum privaten SSH-Schlüssel, um sich beim entfernten Rechner zu authentisieren.

host-key (Vorgabe: #f)

Hierfür sollte der SSH-Rechnerschlüssel der Maschine angegeben werden. Er sieht so aus:

ssh-ed25519 AAAAC3Nz… root@example.org

Wenn #f als host-key angegeben wird, wird der Server gegen die Datei ~/.ssh/known_hosts geprüft, genau wie es der ssh-Client von OpenSSH tut.

allow-downgrades? (Vorgabe: #f)

Ob mögliche Herabstufungen zugelassen werden sollen.

Genau wie guix system reconfigure vergleicht auch guix deploy die Commits auf den momentan eingespielten Kanälen am entfernten Rechner (wie sie von guix system describe gemeldet werden) mit denen, die zurzeit verwendet werden (wie sie guix describe anzeigt), um festzustellen, ob aktuell verwendete Commits Nachfolger der aufgespielten sind. Ist das nicht der Fall und steht allow-downgrades? auf falsch, wird ein Fehler gemeldet. Dadurch kann gewährleistet werden, dass Sie nicht aus Versehen die entfernte Maschine auf eine alte Version herabstufen.

safety-checks? (Vorgabe: #t)

Ob „Sicherheitsüberprüfungen“ vor dem Aufspielen durchgeführt werden. Dazu gehört, zu prüfen, ob die Geräte und Dateisysteme in der Betriebssystemkonfiguration tatsächlich auf der Zielmaschine vorhanden sind und die Linux-Module, die gebrauchy werden, um auf Speichergeräte beim Booten zuzugreifen, auch im Feld initrd-modules des operating-system aufgelistet sind.

Durch die Sicherheitsüberprüfungen wird gewährleistet, dass Sie nicht aus Versehen ein System bereitstellen, dass gar nicht booten kann. Überlegen Sie sich gut, wenn Sie sie ausschalten!

Datentyp: digital-ocean-configuration

Dieser Datentyp beschreibt das Droplet, das für eine Maschine erzeugt werden soll, deren Umgebung (environment) vom Typ digital-ocean-environment-type ist.

ssh-key: Der Pfad zum privaten SSH-Schlüssel, um sich beim entfernten Rechner zu authentisieren. In Zukunft wird es dieses Feld vielleicht nicht mehr geben.
tags: Eine Liste von „Tags“ als Zeichenketten, die die Maschine eindeutig identifizieren. Sie müssen angegeben werden, damit keine zwei Maschinen in der Bereitstellung dieselbe Menge an Tags haben.
region: Ein Digital-Ocean-„Region Slug“ (Regionskürzel), zum Beispiel "nyc3".
size: Ein Digital-Ocean-„Size Slug“ (Größenkürzel), zum Beispiel "s-1vcpu-1gb"
enable-ipv6?: Ob das Droplet mit IPv6-Netzanbindung erzeugt werden soll.

Data Type: hetzner-configuration

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? (Vorgabe: #f): Ob mögliche Herabstufungen zugelassen werden sollen.
authorize? (Vorgabe: #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? (Vorgabe: #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 (siehe Nutzung der Auslagerungsfunktionalität) or emulation (siehe 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-key: The 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:

Create the SSH key of the machine on the Hetzner API.
Create a server for the machine on the Hetzner API.
Format the root partition of the disk using the file system of the machine’s operating system. Supported file systems are btrfs and ext4.
Install a minimal Guix operating system on the server using the rescue mode. This minimal system is used to install the machine’s operating system, after rebooting.
Reboot the server and apply the machine’s operating system on the server.

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.

11.17 guix deploy aufrufen

11.17 `guix deploy` aufrufen