Durchlauf eines Provisionierungsdurchgangs

bericht/chef/chef-comparison.tex

@@ -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
+werden. Roles und Cookbooks werden in eine sogenannte \emph{Run-list} eingefügt.
-Aufgaben in einer Organisation besitzen, zu gruppieren (z.B. webserver).
+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
+  \item[chef-solo] Dies ist die einfachste Ausführungsform. Hierbei werden alle
-    \emph{Chef-client} alle nötigen Daten aus einem lokalen Verzeichnis. Diese
+    nötigen Daten aus einem lokalen Verzeichnis geladen. Im Gegensatz zu den
-    Form wurde für die Umsetzung der Aufgabenstellung.
+    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
+    \emph{REST-Api} zu einem \emph{chef-server} mittels eines privaten RSA-Keys.
-    wird das Chef-repo zentral verwaltet. Der Chef-client bekommt von diesem
+    Auf diesem wird das Chef-repo zentral verwaltet. Der Chef-client bekommt von
-    alle nötigen für die zu provisionierende \emph{node}. Chef-server bietet
+    diesem alle nötigen für die zu provisionierende \emph{node}. Chef-server
-    eine Weboberfläche für die Administrierung an. Die Attribute aller Nodes sind
+    bietet eine Weboberfläche für die Administrierung an. Die Attribute aller
-    über die eingebaute Suchemaschine \emph{Solr} durchsuchbar.
+    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}
+\textbf{Ablauf einer Provisonierung}
-\label{durchlauf_eines_recipes}
+\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}

bericht/chef/chef-tests.tex

@@ -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
+bei der Ausführung von Chef. Bei Chefspec wird Provisionierungsprozess nur bis
-\$Phase)-phase, durchlaufen und danach die eigenen Tests ausgeführt. Dies hat
+zur Convergingphase, durchlaufen. Die eigenen Tests überprüfen nur die erzeugten
-den Vorteil, das Tests sehr schnell durchlaufen werden, da keine Änderungen an
+Resourcen. Dies hat den Vorteil, das Tests sehr schnell durchlaufen werden, da
-einem System vorgenommen werden müssen. Dies hat Vorteile beim Entwickeln, weil
+keine Änderungen an einem System vorgenommen werden müssen. Dies hat Vorteile
-man auf diese Weise schnell Feedback bekommt. Das Zusammenspiel mehrerer
+beim Entwickeln, weil man auf diese Weise schnell Feedback bekommt. Das
-Cookbooks lässt sich dadurch gut testen. Außerdem ermöglicht es verschiedene
+Zusammenspiel mehrerer Cookbooks lässt sich dadurch gut testen. Außerdem
-Konfigurationen/Betriebssysteme durchzutesten, ohne das diese aufwendig
+ermöglicht es verschiedene Konfigurationen/Betriebssysteme durchzutesten, ohne
-aufgesetzt werden müssen. Da Chefspec allerdings nicht wirklich Code auf dem
+das diese (zeit)aufwendig aufgesetzt werden müssen. Da Chefspec allerdings nicht
-System ausführt, sind Integrationstest unerlässlich.
+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

bericht/sources.bib

@@ -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]"
+}