12.16 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".

Größe

Ein Digital-Ocean-„Size Slug“ (Größenkürzel), zum Beispiel "s-1vcpu-1gb"

enable-ipv6?

Ob das Droplet mit IPv6-Netzanbindung erzeugt werden soll.