diff --git a/bericht/chef/chef-comparison.tex b/bericht/chef/chef-comparison.tex index 8f63935..cbb16eb 100644 --- a/bericht/chef/chef-comparison.tex +++ b/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 -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} diff --git a/bericht/chef/chef-tests.tex b/bericht/chef/chef-tests.tex index 0dc679c..6f99b57 100644 --- a/bericht/chef/chef-tests.tex +++ b/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 -\$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 diff --git a/bericht/sources.bib b/bericht/sources.bib index 9e654e2..f536b4c 100644 --- a/bericht/sources.bib +++ b/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]" +}