Durchlauf eines Provisionierungsdurchgangs
This commit is contained in:
parent
444240ba9c
commit
83de545ee6
@ -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}
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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]"
|
||||
}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user