Durchlauf eines Provisionierungsdurchgangs

This commit is contained in:
Jörg Thalheim 2014-03-22 14:41:48 +01:00
parent 444240ba9c
commit 83de545ee6
3 changed files with 104 additions and 24 deletions

View File

@ -18,21 +18,24 @@ Cookbooks angegeben werden.
Eine physikalische oder virtuelle Maschine wird als \emph{node} bezeichnet.
Einer Node können \emph{Attributes}, \emph{Roles} und Cookbooks zugewiesen
werden. Roles bieten eine Möglichkeit Nodes, welche die gleiche
Aufgaben in einer Organisation besitzen, zu gruppieren (z.B. webserver).
werden. Roles und Cookbooks werden in eine sogenannte \emph{Run-list} eingefügt.
Diese gibt die Reihenfolge angibt, in welche Roles und Cookbooks angewendet
werden. Roles bieten eine Möglichkeit Nodes, welche die gleiche Aufgaben in
einer Organisation besitzen, zu gruppieren (z.B. webserver).
Es gibt mehrere Möglichkeiten \emph{Chef} zu betreiben:
\begin{description}
\item[chef-solo] Dies ist die einfachste Ausführungsform. Hierbei wird lädt
\emph{Chef-client} alle nötigen Daten aus einem lokalen Verzeichnis. Diese
Form wurde für die Umsetzung der Aufgabenstellung.
\item[chef-solo] Dies ist die einfachste Ausführungsform. Hierbei werden alle
nötigen Daten aus einem lokalen Verzeichnis geladen. Im Gegensatz zu den
anderen Methoden wird bei dieser das Programm \emph{chef-solo} gestaret.
Diese Form wurde für die Umsetzung der Aufgabenstellung gewählt.
\item[chef-server] Hierbei authentifiziert sich \emph{Chef-client} über eine
\emph{REST-Api} zu einem \emph{chef-server} mittels Zertifikaten. Auf diesem
wird das Chef-repo zentral verwaltet. Der Chef-client bekommt von diesem
alle nötigen für die zu provisionierende \emph{node}. Chef-server bietet
eine Weboberfläche für die Administrierung an. Die Attribute aller Nodes sind
über die eingebaute Suchemaschine \emph{Solr} durchsuchbar.
\emph{REST-Api} zu einem \emph{chef-server} mittels eines privaten RSA-Keys.
Auf diesem wird das Chef-repo zentral verwaltet. Der Chef-client bekommt von
diesem alle nötigen für die zu provisionierende \emph{node}. Chef-server
bietet eine Weboberfläche für die Administrierung an. Die Attribute aller
Nodes sind über die eingebaute Suchemaschine \emph{Solr} durchsuchbar.
\item[Enterprise Chef/Hosted Enterprise Chef] Ähnlich wie Chef-server aber
bietet bessere Skalierbarkeit, rolenbasierte Benutzerverwaltung, bessere Überwachung,
Push-Deployment und eine verbesserte Weboberfläche~\cite{chefenterprise}
@ -90,7 +93,8 @@ findet. Hier nochmal die einzelnen Verzeichnisse im Überblick:
(z.B. normal.mysql.client.packages)
\item[files] Hier können statische Dateien eingefügt werden, welche dann auf
dem Zielsystem in das entsprechende Verzeichnis kopiert werden können.
\item[libraries] In diesem Verzeichnis können Hilfsfunktionen definiert werden.
\item[libraries] In diesem Verzeichnis können Hilfsfunktionen und
Spracherweiterungen definiert werden.
\item[resources] Ressourcen beschreiben, die Bestandteile eines Systems. Eine
Ressource kann z.B. eine Datei, ein Prozess oder ein Packet sein. Man
beschreibt, welchen Zustand (action in Chef genannt) diese Ressource haben
@ -106,6 +110,9 @@ findet. Hier nochmal die einzelnen Verzeichnisse im Überblick:
\item[recipes] In Recipes werden Ressourcen instantiiert, welche nötig sind
um die gewünschte Aufgabe zu erreichen. Dabei können Abhängigkeiten zwischen
diesen angegeben werden.
\item[definitions] Ressourcen häufiger in verschiedenen Recipies auf
ähnliche Art und Weise benötigt werden, können diese in eine
\emph{Definition} ausgelagert werden.
\item[templates] Häufig werden dynamisch generierte Dateien benötigt, um zum
Beispiel Konfigurationsdateien zu erzeugen. Chef bindet hierfür die
Templatesprache eRuby (Embedded Ruby) ein. Diese führt in den Templates
@ -116,10 +123,70 @@ findet. Hier nochmal die einzelnen Verzeichnisse im Überblick:
eine Beschreibung sowie Abhängigkeiten zu anderen Cookbooks angeben werden.
\end{description}
\textbf{Durchlauf eines Recipes}
\label{durchlauf_eines_recipes}
\textbf{Ablauf einer Provisonierung}
\label{ablauf_einer_provisionierung}
TODO Runlist
Der genaue Ablauf wurde der Onlinedokumentation (~\cite{chefrun}) von Chef
entnommen. Wie schon zu Beginn erwähnt wird die Provisonierung von einem
Programm namens \emph{chef-client} durchgeführt. Je nach Umgebung wieder kann
dieser periodisch vom Scheduler \emph{Cron} gestartet, permanent als
Systemdienst laufen (z.B. bei Enterprise Chef) oder manuell gestartet werden
(z.B. bei Vagrant).
Als erstes lädt dieser seine Konfiguration aus der Datei \emph{client.rb}. In
dieser stehen beispielsweise Informationen mit welchen Chef-Server der Client
verbinden soll, an welcher Stelle temporäre Daten gespeichert werden soll und
der Name der Node. Letzteres ist wichtig um die Node richtig von Chef einordnen
zu können und die richtigen Einstellungen zuzuweisen. Alternativ kann der Name
auch von der der Bibliothek \emph{Ohai} (TODO - Link) gesetzt werden, in dem auf
den Hostnamen oder der FQDN (Fully Qualified Domain Name) zurück gegriffen wird.
Ohai sammelt noch andere systemrelevante Daten wie Details über
Hardwarekomponenten (Anzahl der CPUs, Größe und Art des RAMs, Netzwerkanbindung,
Festplatten/SSDs, \dots), Informationen über die Plattform (Art des
Betriebssystems und Version, installierte Software) und die laufenden Prozesse.
Diese Informationen sind durch eigene Ohai-Plugins erweiterbar und können dann
im Provisionierungsprozess genutzt werden um weitere Entscheidungen zu treffen.
Sie sind darüber hinaus auch auf dem Server gespeichert und für andere Clients
abrufbar.
Nach dem alle Einstellungen eingelesen sind, folgte im Falle von Chef-Server,
die Authentifizierung mit diesem über den vorher auf der Node abgelegten
RSA-Schlüssel. Für Adminstratoren gibt es für den
\href{http://docs.opscode.com/knife\_bootstrap.html}{Bootstraprozess}, in
welchem Chef initial auf der Node installiert wird, einen Validatorkey, mit dem
eine Node auf dem Server registriert werden kann, umso einen Clientkey zu
generieren.
Anschließend werden alte gesetzte Attributes und die Run-list vom Server
übertragen. Beim 1. Durchlauf oder im Falle Chef-Solo sind diese Daten nicht
vorhanden (ausgenommen der voreingestellten Run-list von Chef-Server).
Stattdessen kann eine Datei im JSON-Format angegeben werden, um die Attributes
und der Run-list für diese Node zu spezifizieren.
Durch Auswertung der eingebunden Rollen und Recipes wird eine Liste der
benötigen Cookbooks ermittelt. Der Client fordert für diese eine Liste aller
Dateien und deren Checksumme an. Alle geänderten oder neuen Dateien werden
darauf hin heruntergeladen und im lokalen Cache gespeichert.
Nun werden die Attribute zurückgesetzt und aus den Cookbooks, Roles und der Node
neu generiert und entsprechend ihrer Priorität gesetzt. Die in den Cookbooks
definierten Resources werden geladen und mit den von Chef mitgelieferten
Resources in der Resourcecollection zusammengefasst. Nachdem alle Definitions
und Libraries geladen wurden, werden schließlich die Recipes verarbeitet. In
diesen werden Resourcen des Systems beschrieben und durch Actions deren Zustand
festgelegt.
Im nächsten Schritt folgt das sogenannte Converging. Es werden alle Resources in
der Reihenfolge abgearbeitet. Dabei wird für jede Resource der für die Plattform
zugehörige Provider ausgewählt. Dieser überprüft den aktuellen Zustand der
Resource und verändert, wenn notwendig, das System um den Sollzustand zu
erreichen. Zum Schluss überträgt Chef-client, die aktualisierten Attributes auf
den Server, von welchem sie in Solr indexiert werden.
Es besteht die Möglichkeit vor oder nach dem Provisioning Handler auszuführen.
Diese können beispielsweise im Fehlerfall Benachrichtigungen an das
Monitoringssystem oder per Email verschicken. In letzten Abschnitt
(\ref{minitest_handler}) wird dieser Mechanismus genutzt um Tests auszuführen.
\textbf{Vergleich mit puppet}
\label{vergleich_mit_puppet}

View File

@ -26,15 +26,16 @@ man durch eigene Regeln erweitern.
Chefspec baut auf das in Ruby verbreitete Testframework Rspec auf. Dies ist ein
Vertreter des BDD (TODO mehr Infos zu BDD, Integration von Chefspec). Wie
bereits in Abschnitt ~\ref{durchlauf_eines_recipes} erwähnt, gibt es 2 Phasen
bei der Ausführung von Chef. Bei Chefspec wird die 1. Phase, die (TODO
\$Phase)-phase, durchlaufen und danach die eigenen Tests ausgeführt. Dies hat
den Vorteil, das Tests sehr schnell durchlaufen werden, da keine Änderungen an
einem System vorgenommen werden müssen. Dies hat Vorteile beim Entwickeln, weil
man auf diese Weise schnell Feedback bekommt. Das Zusammenspiel mehrerer
Cookbooks lässt sich dadurch gut testen. Außerdem ermöglicht es verschiedene
Konfigurationen/Betriebssysteme durchzutesten, ohne das diese aufwendig
aufgesetzt werden müssen. Da Chefspec allerdings nicht wirklich Code auf dem
System ausführt, sind Integrationstest unerlässlich.
bei der Ausführung von Chef. Bei Chefspec wird Provisionierungsprozess nur bis
zur Convergingphase, durchlaufen. Die eigenen Tests überprüfen nur die erzeugten
Resourcen. Dies hat den Vorteil, das Tests sehr schnell durchlaufen werden, da
keine Änderungen an einem System vorgenommen werden müssen. Dies hat Vorteile
beim Entwickeln, weil man auf diese Weise schnell Feedback bekommt. Das
Zusammenspiel mehrerer Cookbooks lässt sich dadurch gut testen. Außerdem
ermöglicht es verschiedene Konfigurationen/Betriebssysteme durchzutesten, ohne
das diese (zeit)aufwendig aufgesetzt werden müssen. Da Chefspec allerdings nicht
wirklich Code auf dem System ausführt, sind weitere Integrationstest
unerlässlich.
Der folgende Test wurde aus dem NTP-Cookbook
(~\ref{ssub:einrichtung-der-netzwerkdienste}) entnommen.
@ -115,6 +116,9 @@ end
Die Methode \emph{assert\_sh} überprüft den Exitstatus eines Befehls und schlägt
fehl, wenn dieser ungleich Null ist, während die \emph{service}-Methode den
Status eines Systemdienst sicherstellt. Es gibt noch weitere Testmethoden, wie
das Überprüfen von Verzeichnissen, Inhalte von Dateien oder Mountpoints.
das Überprüfen von Verzeichnissen, Inhalte von Dateien oder Mountpoints. Viele
Fehler werden in der Regel schon von den Provider erkannt und festgestellt.
Mit Minitest Handler kann dies Erweitern um zum Beispiel protokollspezifische
Tests durchzuführen.
% vim: set spell spelllang=de_de

View File

@ -6,3 +6,12 @@
year = {2014},
note = "[Online; 06.03.2014]"
}
@online{chefrun,
author = {chef}
title = {{About the chef-client Run}}
howpublished =
"\url{http://docs.opscode.com/essentials_nodes_chef_run.html}",
year = {2014}
note = "[Online, 20.03.2014]"
}