chake – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

Chake – serverlose Konfiguration mit Chef

EINFÜHRUNG

Chake ist ein Tool, mit dem Sie mehrere Hosts verwalten können, ohne dass Sie einen Koch benötigen
Server. Die Konfiguration wird in einem lokalen Verzeichnis verwaltet, das sich wahrscheinlich unter befinden sollte
Versionskontrolle mit git(1) oder irgendetwas anderes. Die Konfiguration wird normalerweise über rsync bereitgestellt
über SSH übertragen und durch Aufruf angewendet Koch-Solo(1) über SSH auf jedem Host.

ERSTELLEN REPOSITORY

$ chake init
[erstellen] nodes.yaml
[ mkdir] nodes.d/
[erstellen] config.rb
[ mkdir] config/roles
[ mkdir] Kochbücher/Grundlagen/Rezepte/
[create]cookbooks/basics/recipes/default.rb
[erstellen] Rakefile

Eine kurze Erklärung der erstellten Dateien:

· nodes.yaml: Hier werden die Hosts aufgelistet, die Sie verwalten, und welche Rezepte verwendet werden sollen
gelten für jeden von ihnen.

· nodes.d: ein Verzeichnis mit mehreren Dateien im gleichen Format wie nodes.yaml. Alle Dateien
Die darin enthaltene *.yaml-Datei wird der Liste der Knoten hinzugefügt.

· config.rb: enthält die Chef-Solo-Konfiguration. Sie können es ändern, aber normalerweise tun Sie es
wird nicht nötig sein.

· config/roles: Verzeichnis, in dem Sie Ihre Rollendefinitionen ablegen können.

· Kochbücher: Verzeichnis, in dem Sie Ihre Kochbücher speichern. Ein Beispielkochbuch namens
„Grundlagen“ wurde erstellt, Sie können es aber auch entfernen und aktuelle Kochbücher hinzufügen.

· Rakefile: Enthält nur die erforderliche „Chake“-Zeile. Sie können es mit anderen Aufgaben ergänzen
spezifisch für Ihre Infrastruktur.

Nachdem das Repository erstellt wurde, können Sie entweder Chake oder Rake aufrufen, da diese vollständig sind
gleichwertig.

VERWALTUNG KNOTEN

Unmittelbar nach der Erstellung Ihres Repositorys lautet der Inhalt von nodes.yaml wie folgt:

host1.mycompany.com:
run_list:
- Rezept[Grundlagen]

Sie können Ihre Hosts mit Rake-Knoten auflisten:

$ Rake-Knoten
host1.mycompany.com ssh

Um weitere Knoten hinzuzufügen, hängen Sie einfach an nodes.yaml an:

host1.mycompany.com:
run_list:
- Rezept[Grundlagen]
host2.mycompany.com:
run_list:
- Rezepte[Grundlagen]

Und Chake weiß jetzt von Ihrem neuen Knoten:

$ Rake-Knoten
host1.mycompany.com ssh
host2.mycompany.com ssh

VORBEREITUNG KNOTEN TO BE MANAGED

Knoten haben nur sehr wenige anfängliche Anforderungen, um mit Chake verwaltet zu werden:

· Der Knoten muss über SSH erreichbar sein.

· Der Benutzer, den Sie mit dem Knoten verbinden, muss entweder Root sein oder berechtigt sein, sudo auszuführen (in
In diesem Fall muss sudo installiert werden).

A beachten on Passwort Aufforderungen: Jedes Mal, wenn Chake SSH auf einem Knoten aufruft, werden Sie möglicherweise dazu aufgefordert
Geben Sie Ihr Passwort ein. Jedes Mal, wenn Chake Sudo auf dem Knoten aufruft, müssen Sie möglicherweise etwas eingeben
in Ihrem Passwort. Für die Verwaltung von ein oder zwei Knoten ist dies wahrscheinlich in Ordnung, für größere jedoch
Anzahl der Knoten ist es nicht praktikabel. Um Passwortabfragen zu vermeiden, können Sie:

· Konfigurieren Sie die schlüsselbasierte SSH-Authentifizierung. Dies ist sicherer als die Verwendung von Passwörtern.
Wenn Sie schon dabei sind, möchten Sie wahrscheinlich auch die Passwortauthentifizierung deaktivieren
vollständig und erlauben nur die schlüsselbasierte Authentifizierung

· Konfigurieren Sie den passwortlosen Sudo-Zugriff für den Benutzer, den Sie zum Herstellen einer Verbindung zu Ihren Knoten verwenden.

ÜBERPRÜFUNG CONNECTIVITY UND URSPRÜNGLICHE HOST SETUP

Um zu überprüfen, ob Hosts korrekt konfiguriert sind, können Sie die Prüfaufgabe verwenden:

$ Rake-Scheck

Dadurch wird der Befehl sudo true auf jedem Host ausgeführt. Wenn das passiert, ohne dass Sie es müssen
Passwörter, da sind Sie sicher

· Sie haben SSH-Zugriff auf jeden Host; Und

· Der Benutzer, mit dem Sie eine Verbindung herstellen, hat Sudo ohne Passwort korrekt eingerichtet.

$ Rake-Scheck

BEWIRBT SICH KOCHBÜCHER

Um die Konfiguration auf alle Knoten anzuwenden, führen Sie Folgendes aus:

$ Rake konvergieren

Um die Konfiguration auf einen einzelnen Knoten anzuwenden, führen Sie Folgendes aus:

$ Rake konvergieren:$NODE

Um ein einzelnes Rezept auf alle Knoten anzuwenden, führen Sie Folgendes aus:

$ Rake anwenden[mein Rezept]

Um ein einzelnes Rezept auf einen bestimmten Knoten anzuwenden, führen Sie Folgendes aus:

$ rake apply:$NODE[myrecipe]

Wenn Sie in der Befehlszeile kein Rezept angeben, werden Sie zur Eingabe eines Rezepts aufgefordert.

Um einen Shell-Befehl auf allen Knoten auszuführen, führen Sie aus

$ Rake Run[Befehl]

Wenn der Befehl, den Sie ausführen möchten, Leerzeichen oder andere Sonderzeichen enthält, tun Sie dies
die Shell, man muss sie zitieren.

Um einen Shell-Befehl auf einem bestimmten Knoten auszuführen, führen Sie aus

$ rake run:$NODE[Befehl]

Wenn Sie in der Befehlszeile keinen Befehl angeben, werden Sie zur Eingabe eines Befehls aufgefordert.

Um die vorhandenen Aufgaben zu überprüfen, führen Sie Folgendes aus

$ Rechen -T

SCHREIBEN KOCHBÜCHER

Da Chake eigentlich eine Verpackung für Chef Solo ist, sollten Sie die [Chef-Dokumentation] lesen.
).
Schauen Sie sich insbesondere die [Chef Solo-Dokumentation](
chef_solo.html>).

KNOT BOOTSTRAPPING PROZESSE

Wenn Chake zum ersten Mal auf einen Knoten einwirkt, muss er diesen booten. Das Bootstrapping
Der Prozess umfasst Folgendes:

· Chef und Rsync installieren

· Deaktivierung des Chef-Client-Daemons

· Einrichten des Hostnamens

KNOT URLs

Die Schlüssel im Hash, der in nodes.yaml dargestellt wird, sind eine Knoten-URL. Alle Komponenten von
Die URL, aber der Hostname sind optional, daher ist die einfache Auflistung von Hostnamen die einfachste Form
Angabe Ihrer Knoten. Hier sind alle Komponenten der Knoten-URLs:

[backend://][username@]hostname[:port][/path]

· Backend: Backend, das zur Verbindung mit dem Host verwendet wird. ssh oder lokal (Standard: ssh)

· Benutzername: Benutzername, mit dem eine Verbindung hergestellt werden soll (Standard: der Benutzername auf Ihrer lokalen Workstation)

· Hostname: der Hostname, zu dem eine Verbindung hergestellt werden soll (Standard: keine)

· Port: Portnummer, zu der eine Verbindung hergestellt werden soll (Standard: 22)

· /path: Speicherort der Kochbücher am Knoten (Standard: /var/tmp/chef.$USERNAME)

EXTRA MERKMALE

# HAKEN

Sie können Rake-Aufgaben definieren, die vor dem Bootstrapping von Knoten ausgeführt werden
Hochladen von Konfigurationsmanagementinhalten auf Knoten und vor der Konvergenz. Um dies zu tun,
Sie müssen lediglich die entsprechenden Aufgaben erweitern:

· bootstrap_common: wird vor dem Bootstrapping von Knoten ausgeführt (auch wenn Knoten bereits gebootet wurden).
Bootstrapping)

· upload_common: Wird vor dem Hochladen von Inhalten auf den Knoten ausgeführt

· converge_common: wird vor der Konvergenz ausgeführt (d. h. Chef ausführen)

Beispiel:

Aufgabe :bootstrap_common tun
sh './scripts/pre-bootstrap-checks'
Ende

# VERSCHLÜSSELT DATEIEN

Alle Dateien mit übereinstimmender Endung .gpg und .asc wird vor dem Senden mit GnuPG entschlüsselt
der Knoten. Sie können sie zum Speichern von Passwörtern und anderen vertraulichen Informationen (SSL-Schlüssel,
usw.) im Repository zusammen mit dem Rest der Konfiguration.

# REPOSITORY-LOKAL SSH CONFIGURATION

Wenn Sie spezielle SSH-Konfigurationsparameter benötigen, können Sie eine Datei namens .ssh_config erstellen
(oder welcher Dateiname auch immer Sie in der Umgebungsvariablen $CHAKE_SSH_CONFIG haben, siehe unten).
für Details) im Stammverzeichnis Ihres Repositorys, und Chake verwendet es beim Aufruf von ssh.

# LOGGING IN TO A HOST

Um sich einfach bei einem Ihrer Hosts anzumelden, führen Sie einfach rake login:$HOSTNAME aus. Dieser Wille
Verwenden Sie automatisch die Repository-lokale SSH-Konfiguration wie oben, sodass Sie dies nicht tun müssen
Geben Sie ständig -F .ssh_config ein.

# LAUFEN ALLER SSH ANRUFE MIT ETWAS PRÄFIX COMMAND

Manchmal möchten oder müssen Sie Ihren SSH-Aufrufen auch ein Präfix voranstellen
Befehl, um es beispielsweise durch einen zentralen Ausgangsknoten zu tunneln. Sie können dies tun, indem Sie
Setzen Sie $CHAKE_SSH_PREFIX in Ihrer Umgebung. Beispiel:

CHAKE_SSH_PREFIX=tsocks Rake konvergieren

Dadurch werden alle SSH-Aufrufe an alle Hosts als tsocks ssh aufgerufen, [...]

# KONVERGIEREND LOCAL HOST

Wenn Sie Ihre lokale Workstation mit Chake verwalten möchten, können Sie einen lokalen Knoten wie z
dies in nodes.yaml:

local://thunderbolt:
run_list:
- Rolle[Arbeitsplatz]

Um die Konfiguration auf den lokalen Host anzuwenden, können Sie den herkömmlichen Rake verwenden
Converse: Thunderbolt oder das spezielle Ziel Rake Local.

Bei der Konvergenz aller Knoten überspringt Chake Knoten, die mit „local://“ deklariert sind.
Backend und dessen Hostname nicht mit dem Hostnamen in der Deklaration übereinstimmt. Zum Beispiel:

local://desktop:
run_list:
- Rolle[Arbeitsplatz]
local://laptop:
run_list:
- Rolle[Arbeitsplatz]

Wenn Sie Rake Converge auf dem Desktop ausführen, wird der Laptop übersprungen und umgekehrt.

VARIABLEN

· $CHAKE_SSH_CONFIG: Lokale SSH-Konfigurationsdatei. Standardmäßig ist .ssh_config.

· $CHAKE_SSH_PREFIX: Befehl zum Präfixieren von SSH-Aufrufen (und Rsync über SSH).

· $CHAKE_RSYNC_OPTIONS: zusätzliche Optionen zur Übergabe an rsync. Nützlich, um z. B. große auszuschließen
verhindert, dass Dateien auf die einzelnen Server hochgeladen werden.

· $CHAKE_NODES: Datei mit der Liste der zu verwaltenden Server. Standard: nodes.yaml.

· $CHAKE_NODES_D: Verzeichnis mit den zu verwaltenden Servern mit Knotendefinitionsdateien.
Standard: nodes.d.

· $CHAKE_TMPDIR: Verzeichnis zum Speichern temporärer Cache-Dateien. Standard: tmp/chake.

· $CHAKE_CHEF_CONFIG: Chef-Konfigurationsdatei, relativ zum Stammverzeichnis des Repositorys.
Standard: config.rb.

Nutzen Sie Chake online über die Dienste von onworks.net