chef: Rechtschreibung und Ausdruck Teil II

This commit is contained in:
Jörg Thalheim 2014-03-27 08:24:39 +01:00
parent 95c5463398
commit f22ca9ba3c
7 changed files with 298 additions and 235 deletions

View File

@ -1,58 +1,60 @@
\subsubsection{Funktionsweise von Chef} \subsubsection{Funktionsweise von Chef}
\label{ssub:funktionsweise_von_chef} \label{ssub:funktionsweise_von_chef}
\href{http://www.getchef.com/chef/}{Chef} ist ein Framework, welches es \href{http://www.getchef.com/chef/}{Chef} ist ein Framework, welches eine
ermöglicht automatisiert Server zu konfigurieren und zu verwalten. Der automatisierte Serverkonfiguration und -verwaltung ermöglicht. (TODO -
Endanwender beschreibt hierbei die Systemresourcen und ihre Zustände in der Provisionierung und Deployment) Der Endanwender
beschreibt hierbei die Systemressourcen und ihre Zustände in der
Programmiersprache \href{https://www.ruby-lang.org/}{Ruby}. Diese Definitionen Programmiersprache \href{https://www.ruby-lang.org/}{Ruby}. Diese Definitionen
werden von dem Program \emph{Chef-client} eingelesen und in notwendige Aktionen werden von dem Program \emph{Chef-Client} eingelesen und in notwendige Aktionen
übersetzt, welche ausgeführt werden müssen, um den beschriebenen Zustand übersetzt, welche ausgeführt werden müssen, um den beschriebenen Zustand
umzusetzen. umzusetzen.
Die Gesamtheit aller Definitionen/Einstellungen nennt man das \emph{Chef-repo}. Die Gesamtheit aller Definitionen/Einstellungen nennt man das \emph{Chef-repo}.
Diese untergliedert sich in mehrere \emph{Cookbooks}\label{cookbook}, welche die Ein solches untergliedert sich in mehrere \emph{Cookbooks}\label{cookbook}. Ein
Grundverwaltungseinheit darstellt. Jedes dieser Cookbooks, erfüllt einen Cookbook ist die Grundverwaltungseinheit in Chef. Es erfüllt einen bestimmten
bestimmten Teilaspekt des Systems, (z.B. die Einrichtung eines Webservers Teilaspekt des Systems (z.B. die Einrichtung eines Webservers
\href{https://github.com/opscode-cookbooks/apache2}{Apache}). Cookbooks \href{https://github.com/opscode-cookbooks/apache2}{Apache}). Cookbooks können
können versioniert werden. Es können Abhängigkeiten zwischen mehreren versioniert werden. Es können Abhängigkeiten zwischen mehreren Cookbooks
Cookbooks angegeben werden. angegeben werden.
Eine physikalische oder virtuelle Maschine wird als \emph{node} bezeichnet. Physikalische oder virtuelle Maschinen werden als \emph{Nodes} bezeichnet.
Einer Node können \emph{Attributes}, \emph{Roles} und Cookbooks zugewiesen Einer Node können \emph{Attributes}, \emph{Roles} und Cookbooks zugewiesen
werden. Roles und Cookbooks werden dazu in die sogenannte \emph{Run-list} der werden. Roles und Cookbooks werden dazu in die sogenannte \emph{Run-List} der
Node eingefügt. Diese gibt die Reihenfolge angibt, in welche Roles und Node eingefügt. Diese gibt die Reihenfolge an, in welcher Roles und Cookbooks
Cookbooks angewendet werden. Roles bieten eine Möglichkeit Nodes, welche die angewendet werden. Roles bieten eine Möglichkeit, Nodes zu gruppieren, welche die
gleiche Aufgaben in einer Organisation besitzen, zu gruppieren (z.B. Webserver). gleichen Aufgaben in einer Organisation erfüllen (z.B. Webserver).
Es gibt mehrere Möglichkeiten \emph{Chef} zu betreiben: Es gibt mehrere Möglichkeiten \emph{Chef} zu betreiben:
\begin{description} \begin{description}
\item[Chef-solo] Dies ist die einfachste Ausführungsform. Hierbei werden alle \item[Chef-Solo] Chef-Solo ist die einfachste Ausführungsform. Alle nötigen
nötigen Daten aus einem lokalen Verzeichnis geladen. Im Gegensatz zu den Daten werden aus einem lokalen Verzeichnis geladen. Im Gegensatz zu
anderen Methoden heißt bei dieser das auszuführende Programm \emph{Chef-Server} und \emph{Enterprise Chef} wird bei Chef-Solo das
\emph{chef-solo} statt \emph{chef-client}. Diese Form wurde für die Programm \emph{chef-solo} an Stelle von \emph{chef-client} ausgeführt. Diese
Umsetzung der Aufgabenstellung in Form wurde für die Umsetzung der Aufgabenstellung in
Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} gewählt. Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} gewählt.
\item[Chef-server] Hierbei authentifiziert sich \emph{Chef-client} über eine \item[Chef-Server] Hierbei authentifiziert sich \emph{Chef-Client} über eine
\emph{REST-Api} zu einem \emph{Chef-server} mittels eines privaten RSA-Keys. \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 Auf diesem wird das Chef-repo zentral verwaltet. Der Chef-Client bekommt von
diesem alle nötigen Informationen für die zu provisionierende \emph{Node}. diesem alle nötigen Informationen für die zu provisionierende \emph{Node}.
Chef-server bietet eine webbasierte GUI für die Administration an. Die Chef-Server bietet eine webbasierte GUI für die Administration an. Die
Attribute aller Nodes sind über die eingebaute Suchemaschine \emph{Solr} Attributes aller Nodes sind über die eingebaute Suchmaschine
durchsuchbar. \href{https://lucene.apache.org/solr/}{\emph{Solr}} durchsuchbar.
\item[Enterprise Chef/Hosted Enterprise Chef] Ähnlich wie Chef-server bietet \item[Enterprise-Chef/Hosted-Enterprise-Chef] Enterprise-Chef bietet
aber eine bessere Skalierbarkeit, rolenbasierte Benutzerverwaltung, bessere zusätzlich zu den Funktionen der Opensource-Version Chef-Server eine
Überwachung, eine verbesserte Weboberfläche sowie Push-Deployment an. rollenbasierte Benutzerverwaltung, bessere Überwachung, eine verbesserte
Während Hosted Enterprise Chef die Firma Chef den Serverteil betreibt, ist Weboberfläche sowie Push-Deployment an. Während bei Hosted-Enterprise-Chef
bei Enterprise Chef der Server in der eigenen die Firma Chef den Serverteil betreibt und die Skalierung des Dienstes
Organisation~\cite{chefenterprise} übernimmt, ist bei Enterprise-Chef der Server in der eigenen
Organisation~\cite{chefenterprise}.
\end{description} \end{description}
\textbf{Aufbau eines Cookbook} \textbf{Aufbau eines Cookbooks}
\label{aufbau_eines_cookbook} \label{aufbau_eines_cookbook}
Hier ist die Ordnerstruktur eines Cookbooks am Beispiel von Nachfolgend ist die Ordnerstruktur eines Cookbooks am Beispiel von
\href{https://github.com/opscode-cookbooks/apt}{apt} dargestellt: \href{https://github.com/opscode-cookbooks/apt}{apt} dargestellt.
\begin{tikzpicture} \begin{tikzpicture}
\treeroot{apt-2.3.4} \treeroot{apt-2.3.4}
@ -92,43 +94,52 @@ Funktion. Dies hat den Vorteil, das man sich schnell in neuen Cookbooks zurecht
findet. Hier nochmal die einzelnen Verzeichnisse im Überblick: findet. Hier nochmal die einzelnen Verzeichnisse im Überblick:
\begin{description} \begin{description}
\item[attributes] setzt Standardwerte (Attribute) für das Cookbook. Dies \item[attributes] Attributes sind einfache Schlüssel-Wert-Beziehungen und
können Strings, Zahlen oder Arrays sein. Die gesetzten Attribute können in setzen Standardwerte für das Cookbook. Die Schlüssel sind hierarchisch
Roles, Nodes oder von anderen Cookbooks überschrieben werden. Hierfür gibt organisiert. In der Regel ist die höchste Ebene der Name des Cookbooks (z.B.
es die Prioritäten default, force\_default, normal und override um die \emph{normal.mysql.client.packages}). Werte können Strings, Zahlen oder
Reihenfolge zu beeinflussen. Attributes sind hierarchisch organisiert. In Arrays sein. Die gesetzten Attributes können in Roles, Nodes oder von
der Regel ist die höchste Ebene der Name des Cookbooks. (z.B. anderen Cookbooks überschrieben werden. Hierfür werden die Attributes mit
\emph{normal.mysql.client.packages}) den verschiedenen Prioritäten default, force\_default, normal und override
\item[files] Hier können statische Dateien eingefügt werden, welche dann auf gesetzt (aufsteigender Wertigkeit) gesetzt, wobei eine höhere Priorität eine
dem Zielsystem in das entsprechende Verzeichnis kopiert werden können. Niedrigere überschreibt.
\item[libraries] In diesem Verzeichnis können Hilfsfunktionen und \item[files] In diesem Verzeichnis können statische Dateien eingefügt werden,
welche auf dem Zielsystem in das entsprechende Verzeichnis kopiert werden
können.
\item[libraries] In diesem Pfad können Hilfsfunktionen und
Spracherweiterungen definiert werden. Spracherweiterungen definiert werden.
\item[resources] Ressourcen beschreiben, die Bestandteile eines Systems. Eine \item[resources] Ressourcen beschreiben die Bestandteile eines Systems. Eine
Ressource kann z.B. eine Datei, ein Prozess oder ein Packet sein. Man Resource kann z.B. eine Datei, ein Prozess oder ein Paket sein. Man
beschreibt, welchen Zustand (Action in Chef genannt) diese Ressource haben beschreibt, welchen Zustand (Action in Chef genannt) diese Ressource haben
soll und Chef versucht diesen Zustand herzustellen. Chef liefert von Haus soll und Chef versucht, diesen Zustand herzustellen. Chef liefert bereits
viele wichtige Ressourcen mit. In Cookbooks können man darüber hinaus eigene viele wichtige Ressourcen mit. In Cookbooks können darüber hinaus eigene
Ressourcen definiert werden. Resources definiert werden.
\item[providers] Während Ressourcen nur die Schnittstelle mit allen Attributes \item[providers] Während Ressourcen nur die Schnittstelle mit allen Attributes
beschreiben, die gesetzt werden können, ist der Provider eine konkrete beschreiben, die gesetzt werden können, ist der Provider eine konkrete
Implementierung. Deswegen muss für jede Ressource mindestens ein Provider Implementierung. Deswegen muss für jede Ressource mindestens ein Provider
existieren. Es kann mehrere Provider für eine Ressource geben, um zum existieren. Es kann mehrere Provider für eine Ressource geben, um zum
Beispiel um mehrere Plattformenvarianten oder Betriebssysteme abdecken zu Beispiel um mehrere Plattformenvarianten oder Betriebssysteme abdecken zu
können (z.B. bei Packetmanagern oder Initsystemen). können (z.B. bei Paketmanagern oder Initsystemen TODO - Initsystemen
\item[recipes] In Recipes werden Ressourcen instantiiert, welche nötig sind erklären). In eigenen Cookbooks erstellte Resources/Provider nennt man LWRP
um die gewünschte Aufgabe zu erreichen. Dabei können Abhängigkeiten zwischen (Lightweight-Resource/Provider).
diesen angegeben werden. \item[recipes] In Recipes werden Ressourcen instanziiert, welche nötig sind,
\item[definitions] Ressourcen, welche häufiger in verschiedenen Recipes auf um die gewünschte Ziel zu erreichen. Dabei können Abhängigkeiten zwischen
ähnliche Art und Weise benötigt werden, können in eine \emph{Definition} Recipes angegeben werden.
ausgelagert werden. \item[definitions] Ressources, welche häufiger in verschiedenen Recipes in
ähnlicher Form benötigt werden, können in eine \emph{Definition}
ausgelagert werden. Ein Beispiel ist das Generieren eines SSH-Schlüssels
für verschiedene Nutzer auf dem System. Für komplexere Konstrukte sollten
jedoch LWRPs (siehe oben) bevorzugt werden.
\item[templates] Häufig werden dynamisch generierte Dateien benötigt, um zum \item[templates] Häufig werden dynamisch generierte Dateien benötigt, um zum
Beispiel Konfigurationsdateien zu erzeugen. Chef bindet hierfür die Beispiel Konfigurationsdateien zu erzeugen. In Chef wird für diesen Zweck
Templatesprache eRuby (Embedded Ruby) ein. Diese führt in den Templates die Templatesprache eRuby (Embedded Ruby) verwendet. In ERB-Templates wird
Rubycode, der sich zwischen den Tags \emph{<\%} und \emph{\%>} befindet, aus. Rubycode ausgeführt, der sich zwischen den Tags \emph{<\%} und \emph{\%>}
Dies erlaubt es Variablen zu interpolieren, sowie If-Statements und befindet. Dies erlaubt es einerseits den Inhalt von Variablen oder den
Schleifen. Rückgabewert von Methoden zu interpolieren, andererseits können in Templates
\item[metadata.rb] In dieser Datei kann der Name des Cookbook, die Version, Kontrollstrukturen wie If-Statements und Schleifen verwendet werden.
eine Beschreibung sowie Abhängigkeiten zu anderen Cookbooks angeben werden. \item[metadata.rb] In der Datei \emph{metadata.rb} kann der Name des Cookbook,
die eigene Version, eine Beschreibung sowie Abhängigkeiten zu anderen
Cookbooks angegeben werden.
\end{description} \end{description}
Beispiel ERB-Template: Beispiel ERB-Template:
@ -151,73 +162,98 @@ Beispiel ERB-Template:
\end{lstlisting} \end{lstlisting}
\textbf{Ablauf einer Provisonierung} \textbf{Ablauf einer Provisonierung}
\label{ablauf_einer_provisionierung} \label{ablauf_einer_provisionierung}\\
Der genaue Ablauf wurde der Onlinedokumentation (\cite{chefrun}) von Chef
Der genaue Ablauf wurde der Onlinedokumentation (~\cite{chefrun}) von Chef entnommen. Wie schon zu Beginn erwähnt, wird die Provisonierung von einem
entnommen. Wie schon zu Beginn erwähnt wird die Provisonierung von einem Programm namens \emph{Chef-Client} durchgeführt. Je nach gewählter Umgebung kann
Programm namens \emph{Chef-client} durchgeführt. Je nach Umgebung kann dieser dieser periodisch vom Scheduler \emph{Cron} gestartet, permanent als
periodisch vom Scheduler \emph{Cron} gestartet, permanent als Systemdienst Systemdienst laufen (z.B. bei Enterprise Chef) oder manuell gestartet werden
laufen (z.B. bei Enterprise Chef) oder manuell gestartet werden (z.B. bei (z.B. bei Vagrant - siehe~\ref{ssub:einrichtung-der-netzwerkdienste}).
Vagrant - siehe~\ref{ssub:einrichtung-der-netzwerkdienste}).
Als erstes lädt dieser Prozess seine Konfiguration aus der Datei Als erstes lädt dieser Prozess seine Konfiguration aus der Datei
\emph{client.rb}. In dieser stehen beispielsweise Informationen mit welchen \emph{client.rb}. In dieser stehen beispielsweise die URL des Chef-Server, in
Chef-Server der Client sich verbinden soll, an welcher Stelle temporäre Daten welchem Pfad temporäre Dateien gespeichert werden und der Name der Node.
gespeichert werden soll und der Name der Node. Letzteres ist wichtig um die Node Letzteres ist wichtig, um die Node in Chef einordnen zu können und die richtigen
richtig von Chef einordnen zu können und die richtigen Einstellungen zuzuweisen. Einstellungen zuzuweisen. Alternativ kann der Name auch von der Bibliothek
Alternativ kann der Name auch von der der Bibliothek
\href{http://docs.opscode.com/ohai.html}{Ohai} gesetzt werden, in dem auf den \href{http://docs.opscode.com/ohai.html}{Ohai} gesetzt werden, in dem auf den
Hostnamen oder der FQDN (Fully Qualified Domain Name) zurückgegriffen wird. Hostnamen oder der FQDN (Fully Qualified Domain Name) zurückgegriffen wird.
Ohai sammelt noch andere systemrelevante Daten wie Details über Ohai sammelt systemrelevante Daten wie Details über Hardwarekomponenten (Anzahl
Hardwarekomponenten (Anzahl der CPUs, Größe und Art des RAMs, Netzwerkanbindung, der CPUs, Größe und Art des RAMs, Netzwerkanbindung, Festplatten/SSDs, \dots),
Festplatten/SSDs, \dots), Informationen über die Plattform (Art des Informationen über die Plattform (Art des Betriebssystems und sowie dessen Version,
Betriebssystems und Version, installierte Software) und die laufenden Prozesse. installierte Anwendungssoftware) und die laufenden Prozesse. Diese Informationen sind
Diese Informationen sind durch eigene Ohai-Plugins erweiterbar und können im durch eigene Ohai-Plugins erweiterbar und können im Provisionierungsprozess
Provisionierungsprozess genutzt werden, um weitere Entscheidungen zu treffen. genutzt werden, um weitere Entscheidungen zu treffen. Sie sind darüber hinaus
Sie sind darüber hinaus auch auf dem Server gespeichert und für andere Clients auch auf dem Server gespeichert und für andere Clients abrufbar.
abrufbar.
Nach dem alle Einstellungen eingelesen sind, folgt im Falle von Chef-Server, die Nach dem alle Einstellungen eingelesen sind, verbindet sich Chef-Client mit
Authentifizierung mit diesem über den vorher auf der Node abgelegten Chef-Server. Die Authentifizierung erfolgt über den vorher auf der Node
RSA-Schlüssel. Für Adminstratoren gibt es für den abgelegten RSA-Schlüssel. Für Administratoren gibt es einen Validator-Key. Im
\href{http://docs.opscode.com/knife\_bootstrap.html}{Bootstraprozess}, in \href{http://docs.opscode.com/knife\_bootstrap.html}{Bootstraprozess}, in
welchem Chef initial auf der Node installiert wird, dafür einen Validatorkey. welchem Chef initial auf der Node installiert, kann mit diesem eine Node auf dem
Mit diesem kann eine Node auf dem Server registriert werden, umso einen Server registriert werden und ein Clientkey generiert werden.
Clientkey zu generieren.
Anschließend werden alte gesetzte Attributes und die Run-list vom Server 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 übertragen. Im 1. Durchlauf oder bei Verwendung von Chef-Solo sind diese Daten
vorhanden (ausgenommen der voreingestellten Run-list von Chef-Server). nicht vorhanden. Stattdessen kann eine Datei im JSON-Format angegeben werden,
Stattdessen kann eine Datei im JSON-Format angegeben werden, um die Attributes um die Attributes und der Run-List für die Node zu spezifizieren. Außerdem ist
und der Run-list für diese Node zu spezifizieren. es möglich eine Run-List auf dem Chef-Server einzustellen, welche ausgeführt
wird, wenn die Node keine eigene Run-List besitzt.
Durch Auswertung der eingebunden Rollen und Recipes wird eine Liste der Durch Auswertung der eingebunden Rollen und Recipes werden die benötigen
benötigen Cookbooks ermittelt. Der Client fordert für diese eine Liste aller Cookbooks ermittelt. Der Client fordert eine Liste aller darin enthaltenen
Dateien und deren Checksumme an. Alle geänderten oder neuen Dateien werden Dateien und deren Checksumme an. Alle geänderten oder neuen Dateien werden
darauf hin heruntergeladen und im lokalen Cache gespeichert. heruntergeladen und im lokalen Cache gespeichert.
Nun werden die Attribute zurückgesetzt und aus den Cookbooks, Roles und der Node 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 neu generiert und entsprechend ihrer Priorität gesetzt. Die, in den Cookbooks
definierten Resources werden geladen und mit den von Chef mitgelieferten definierten, Resources werden geladen und mit den, von Chef mitgelieferten,
Resources in der Resourcecollection zusammengefasst. Nachdem alle Definitions Resources in der Resource-Collection zusammengefasst. Nachdem alle Definitions
und Libraries geladen wurden, werden schließlich die Recipes verarbeitet. In und Libraries geladen wurden, werden schließlich die Recipes verarbeitet. Die
diesen werden Resourcen des Systems beschrieben und durch Actions deren Zustand darin erstellten Resources beschreiben das System. Für jede Resource wird eine
festgelegt. Action festgelegt, was gleichbedeutend mit deren Zustand ist.
Im nächsten Schritt folgt das sogenannte Converging. Es werden alle Resources in Im nächsten Schritt folgt das sogenannte Converging (englisch für
der Reihenfolge abgearbeitet. Dabei wird für jede Resource der für die Plattform \emph{Angleichen}). Es werden alle Resources Schritt für Schritt abgearbeitet.
zugehörige Provider ausgewählt. Dieser überprüft den aktuellen Zustand der Dabei wird für jede Resource, der für die Plattform zugehörige, Provider
Resource und verändert wenn notwendig das System um den Sollzustand zu ausgewählt. Dieser überprüft den aktuellen Zustand der Resource und verändert,
erreichen. Zum Schluss überträgt Chef-client die aktualisierten Attributes auf wenn notwendig, das System, um den Sollzustand zu erreichen. Zum Schluss überträgt
den Server, von welchem sie in Solr indexiert werden. 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. Es besteht die Möglichkeit Handler vor oder nach dem Provisioning auszuführen.
Diese können beispielsweise im Fehlerfall Benachrichtigungen an das Diese können im Fehlerfall Benachrichtigungen an das Monitoringssystem oder per
Monitoringssystem oder per Email verschicken. In letzten Abschnitt Email verschicken. In letzten Abschnitt (\ref{minitest_handler}) wird dieser
(\ref{minitest_handler}) wird dieser Mechanismus genutzt um Tests auszuführen. Mechanismus genutzt um Tests auszuführen.
\textbf{Vergleich mit puppet} \textbf{Vergleich mit puppet}
\label{vergleich_mit_puppet} \label{vergleich_mit_puppet}\\
Ein anderes weiteres verbreitetes Konfigurationsmanagmentsystem ist Puppet. Es
ist das ältere der beiden Projekte. Während die erste Puppetrelease bereits im
Jahr 2005 von den Puppet Labs veröffentlicht wurde, erschien Chef erst 4 Jahre
später im Jahre 2009. Chef wurde stark beeinflusst von Puppet. Der Erfinder von
Chef Adam Jacob war selbst langjähriger Puppetnutzer bevor er Chef oder wie es
in den 1. Versionen hieß <TODO>, schrieb.
- Konsultantfirma: Infrastruktur bis zum Deployment
- mangelnde Abstraktionsmöglichkeiten
\cite{chefhistory}.
%- bei beiden Projekte ist Clientkomponente in Ruby geschrieben.
%- Chef: Konfigurations in Ruby
%- Puppet: eine auf Puppet optimierte, vereinfachte Sprache
% -> einfacher für Einsteiger und Nicht-Programmieren
% -> Grund für manche Firmen -> wird um Umschulung zu sparen
% -> weniger flexible als Ruby (Grund bei Facebook, TODO youtube-Link, mehre Cluster mit mehr als 10.000 Nodes mit Chef provisionier)
%- Während die Regeln und Beschreibung in Chef standartmäßig in der Reihenfolge abgearbeitet
% wird in der sie geladen werden, sortiert Puppet diese um. In beiden kann die
% Reihenfolge durch Spezifikation von Abhängigkeiten umsortiert werden (Später
% ein Beispiel)
%
%Note:
%- Puppet: eigene Sprache -> komplexere Codebasis
%- Um die Größe der Community abzuschätzen (schwierig): Suchtreffer für Repositories bei Github
%- Alter(Puppet) > Alter(Chef)
%- Chef Enterprise vs Puppet Enterprise: Hinter beiden Projekten stehen Firmen, Weiterentwicklung des Produkt, bieten Support und Hosting an
%- Resume: Ähnliche Projekte, lösen das gleiche Problem auf unterschiedliche
% Weise
% vim: set spell spelllang=de_de % vim: set spell spelllang=de_de

View File

@ -2,33 +2,35 @@
\label{ssub:einrichtung-der-netzwerkdienste} \label{ssub:einrichtung-der-netzwerkdienste}
Für die Provisionierung der Netzwerkdienste wurde Für die Provisionierung der Netzwerkdienste wurde
\href{http://vagrantup.com}{Vagrant} verwendet. Dies ist ein Programm um auf der \href{http://vagrantup.com}{Vagrant} verwendet. Dies ist ein Programm, um auf
Basis von Virtualbox und anderen Virtualisierungslösungen schnell und der Basis von Virtualbox und anderen Virtualisierungslösungen schnell und
reproduzierbar virtuelle Maschinen zu starten. Die Einstellungen hierfür werden reproduzierbar virtuelle Maschinen zu starten. Die Einstellungen hierfür werden
in der Datei \emph{Vagrantfile} geschrieben, welches Vagrant beim Start in der Datei \emph{Vagrantfile} hinterlegt, welche Vagrant beim Start einliest.
einliest. Vagrant bietet eine gute Integration für Chef. Es bietet Optionen, mit Vagrant kann Chef beim Erstellen von virtuellen Maschinen integrieren. Es
welchen Einstellungen neue virtuelle Maschinen provisioniert werden sollen. Zum bietet Optionen, mit welchen Einstellungen neue virtuelle Maschinen
Einsatz kam das Betriebssystem Ubuntu in der Version 12.04. Das Basisimage provisioniert werden sollen. Zum Einsatz kam das Betriebssystem Ubuntu in der
hierfür wurde von \emph{Chef}, der gleichnamigen Firma hinter Chef, Version 12.04. Das Basisimage hierfür wurde von \emph{Chef}, der gleichnamigen
bereitgestellt. Es wurde ein Netzwerkinterface konfiguriert für die Firma, bereitgestellt. Für die Kommunikation mit Vagrant wurde das
Kommunikation mit Vagrant und ein weiteres Internes für ein virtuelles Netzwerk Netzwerkinterface \emph{eth0} konfiguriert. Ein weiteres Netzwerkinterface
zwischen den VMs zum Betreiben der Netzwerkdienste. Vagrant bietet für diese (\emph{eth1}) wird für das interne virtuelle Netzwerk zwischen den VMs zum
erweiterten Einstellungen keine Optionen. Um diese dennoch zu übernehmen, waren Betreiben der Netzwerkdienste benötigt. Vagrant bietet für diese erweiterten
spezielle Kommandozeilenargumente an den Befehl \emph{VBoxManage} nötig, welches Einstellungen keine Optionen. Um diese dennoch zu übernehmen, waren spezielle
von Vagrant für Virtualbox genutzt wird. Dies schränkt Nutzung allerdings auf Kommandozeilenargumente an den Befehl \emph{VBoxManage} nötig, welches von
die Visualisierung Virtualbox ein. Vagrant bietet die Möglichkeit neben Vagrant für Virtualbox genutzt wird. Dies schränkt die Nutzung allerdings auf
Provisionierungsystemen auch Shellskripte auszuführen. Diese wurde genutzt um den Hypervisor Virtualbox ein. Vagrant bietet die Möglichkeit, neben
Chef auf die zum damaligen Zeitpunkt aktuellste Version 11.8.2 upzudaten. Provisionierungsystemen auch Shellskripte auszuführen. Diese wurde genutzt, um
Chef auf die, zum damaligen Zeitpunkt, aktuellste Version 11.8.2 zu
aktualisieren.
Desweiteren wird Ruby auf dem Host benötigt um beispielsweise die Tests Desweiteren wird Ruby auf dem Host benötigt, um beispielsweise die Tests
ausführen zu können. Auf Unix-basierten Systemen kann dies mit dem Befehl: ausführen zu können. Auf Unix-Ähnlichen Systemen kann dies mit dem Befehl:
\shellcmd{curl -sSL https://get.rvm.io | bash -s stable} \shellcmd{curl -sSL https://get.rvm.io | bash -s stable}
installiert werden. Auf Windows kann der installiert werden. Auf dem Betriebssystem Windows kann auf den
\href{http://rubyinstaller.org/}{RubyInstaller} genutzt werden. Um die nötigen \href{http://rubyinstaller.org/}{RubyInstaller} zurückgegriffen werden. Um die
Abhängigkeiten zu installieren, müssen folgende Befehle ausgeführt im benötigten Ruby-Bibliotheken zu installieren, müssen folgende 2 Befehle im
Projektverzeichnis werden: Projektverzeichnis ausgeführt werden:
\shellcmd{gem install bundler} \shellcmd{gem install bundler}
@ -41,7 +43,7 @@ Datei namens Berkssfile angegeben (vergleichbar mit
\href{http://bundler.io/}{Gemfiles} in Ruby). Berkshelf unterstützt dabei \href{http://bundler.io/}{Gemfiles} in Ruby). Berkshelf unterstützt dabei
verschiedene Quellen (per Api von der Communityseite von Opscode, Git, lokal) verschiedene Quellen (per Api von der Communityseite von Opscode, Git, lokal)
und kann Abhängigkeiten zu anderen Cookbooks auflösen. Um die Cookbooks initial und kann Abhängigkeiten zu anderen Cookbooks auflösen. Um die Cookbooks initial
zu laden muss der Befehl: zu laden, muss der Befehl:
\shellcmd{berks install} \shellcmd{berks install}
@ -52,56 +54,65 @@ Für das Zusammenspiel mit Vagrant gibt es das Plugin
dass die von Berkshelf verwalteten Cookbooks auch in Vagrant zur Verfügung dass die von Berkshelf verwalteten Cookbooks auch in Vagrant zur Verfügung
stehen. stehen.
Für bestimmte Funktionen wie geteilte Ordner zwischen VM und Host müssen die Für bestimmte Funktionen, wie geteilte Ordner zwischen VM und Host, müssen die
\emph{virtualbox-client-modules} in der VM installiert sein. Diese sind zwar in \emph{virtualbox-client-modules} in der VM installiert sein. Diese sind in
vielen Images, die es für Vagrant gibt, vorhanden. Allerdings muss die meisten vielen Images vorhanden, die es für Vagrant gibt. Allerdings muss die
Virtualboxversion des Host mit Dem in der VM übereinstimmen. Abhilfe schafft das Virtualboxversion des Host mit der Version in der VM übereinstimmen. Abhilfe
Vagrantplugin \href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}. schafft das Vagrantplugin
Dieses vergleicht beim Start die Versionen und installiert gegeben falls eine \href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}. Beim
Andere in der VM. Start installiert das Plugin die die gleiche Version des Modules in der VM.
Wenn Virtualbox mit Linux als Hostsystem ausgeführt wird, sollte das
Kernelmodule \emph{vboxdrv} geladen sein. Manche Linux-Distributionen
installieren dieses Module bereits während der Installation von Virtualbox.
Auf MacOS X und Windows sind keine weiteren Schritte notwendig.
Beide Plugins werden diesen Befehlen installiert: Beide Plugins werden den Befehlen:
\shellcmd{vagrant plugin install vagrant-vbguest} \shellcmd{vagrant plugin install vagrant-vbguest}
\shellcmd{vagrant plugin install vagrant-berkshelf} \shellcmd{vagrant plugin install vagrant-berkshelf}
installiert.
Gestartet wird die VM mit dem Befehl: Gestartet wird die VM mit dem Befehl:
\shellcmd{vagrant up} \shellcmd{vagrant up}
Beim 1. Start wird die VM mit Chef provisioniert. Später kann Chef erneut mit Während des ersten Starts wird die VM mit Chef provisioniert. Später kann Chef
folgenden Befehl gestartet werden: erneut mit Befehl:
\shellcmd{vagrant provision} \shellcmd{vagrant provision}
Als Netzwerkdienste wurden die Protokolle DHCP, DNS und NTP gewählt. Die gestartet werden:
VMs wurden in 2 Gruppen geteilt, \emph{Headnodes}, die die genannten Dienste anbieten
und \emph{Computenodes}. Die Computenodes fordern auf dem internen Netzwerk per
DHCP eine IP-Adresse an und nutzen den DNS- und NTP-Dienst des jeweiligen
Headnode.
Die Attribute der Roles und Node wurden in JSON-Dateien abgelegt in den Ordnern Als Netzwerkdienste wurden die Protokolle DHCP, DNS und NTP gewählt. Die VMs
\emph{roles/} und \emph{nodes}. Es gibt je eine Role für die Computenode und wurden in die zwei Gruppen \emph{Headnodes}und \emph{Computenodes} geteilt. Die
Headnode. In der aktuellen Konfiguration erzeugt Vagrant eine Headnode Headnode bietet die genannten Dienste an. Die Computenodes fordern auf dem
mit dem Hostnamen \emph{node0.lctp} und zwei Computenodes (\emph{node1.lctp} und internen Netzwerk per DHCP eine IP-Adresse an und nutzen den DNS- und NTP-Dienst
\emph{node2.lctp}). der jeweiligen Headnode.
Die Attributes der Roles und der Node wurden in JSON-Dateien in den
Verzeichnissen \emph{roles/} und \emph{nodes/} abgelegt. Es gibt je eine
Role-Datei für Computenodes und Headnodes. In der aktuellen Konfiguration
erzeugt Vagrant eine Headnode mit der FQDN \emph{node0.lctp} und zwei
Computenodes (\emph{node1.lctp} und \emph{node2.lctp}).
Für das Deployment wurden fünf Cookbooks geschrieben: Für das Deployment wurden fünf Cookbooks geschrieben:
\begin{description} \begin{description}
\item[bind] \item[bind]
Als DNS-Server wurde bind gewählt. Dieses Cookbook richtet diesen Dienst ein Als DNS-Server wurde bind gewählt. Das Cookbook richtet diesen Dienst ein
und fügt die in den Attributen konfigurierten DNS-Einträge hinzu zu den und fügt, die in den Attributes konfigurierten, DNS-Einträge zu den
entsprechenden Zonen hinzu. entsprechenden Zonen hinzu.
\item[dhcp] \item[dhcp]
Dieses Cookbook richtet den ISC DHCP-Server ein. Neben der Zuordnung von Dieses Cookbook richtet den ISC-DHCP-Server (TODO Link) ein. Neben der
festen IP-Adressen zu Nodes, kann ein DNS-Server und ein NTP-Server Zuordnung von festen IP-Adressen zu Nodes, kann ein DNS-Server und ein
NTP-Server
festgelegt werden. festgelegt werden.
\item[lctp-network] Dieses Cookbook ist ein Wrappercookbook um das \item[lctp-network] Dieses Cookbook ist ein Wrappercookbook um das
\href{https://github.com/redguide/network_interfaces}{network\_interfaces} \href{https://github.com/redguide/network_interfaces}{network\_interfaces}
Cookbook. Wrappercookbooks werden häufig dazu benutzt um bestehende Cookbooks Cookbook. Wrappercookbooks werden häufig dazu benutzt um bestehende Cookbooks
aus anderen Quellen um Funktionalität zu erweitern. In diesem Fall aktiviert aus anderen Quellen um Funktionalität zu erweitern. In diesem Fall aktiviert
das Cookbook für die Computenodes dhcp auf dem interen Netzwerkinterface. das Cookbook für die Computenodes DHCP auf dem interen Netzwerkinterface.
Auf den Headnodes wird eine statische IP-Adresse gesetzt, der DNS-Server auf Auf den Headnodes wird eine statische IP-Adresse gesetzt, der DNS-Server auf
localhost festgelegt und IP-Forwarding sowie Masquerading via iptables für localhost festgelegt und IP-Forwarding sowie Masquerading via iptables für
den Routerbetrieb aktiviert. den Routerbetrieb aktiviert.
@ -109,22 +120,22 @@ Für das Deployment wurden fünf Cookbooks geschrieben:
Dieses Cookbook richtet den NTP-Deamon ein, welcher die Zeit zwischen den Dieses Cookbook richtet den NTP-Deamon ein, welcher die Zeit zwischen den
einzelnen Knoten synchron halten soll. einzelnen Knoten synchron halten soll.
\item[main] \item[main]
Dieses Cookbook fast alle oben genannten Cookbooks für Compute- und Dieses Cookbook fasst alle oben genannten Cookbooks für Compute- und
Headnode zusammen. Man könnte dies prinzipiell auch in den jeweiligen Headnode zusammen. Man könnte dies prinzipiell auch in den jeweiligen
Rollen erledigen. Rollen in Chef haben allerdings den Nachteil, dass diese Rollen erledigen. Rollen in Chef haben allerdings den Nachteil, dass diese
nicht versionierbar und (bei Chef-server) über alle Umgebungen gleich nicht versionierbar und (bei Chef-Server) über alle Umgebungen identisch
sind. Somit ist eine Trennung zwischen Test- und Produktivumgebung sind. Somit ist eine Trennung zwischen Test- und Produktivumgebung
schwierig. schwierig.
\end{description} \end{description}
Es wurden folgende externen Cookbooks verwendet: Es wurden folgende externen Cookbooks verwendet:
\begin{description} \begin{description}
\item[apt] bringt die lokalen Packetquellen auf den aktuellen Stand und \item[apt] bringt die lokalen Paketquellen auf den aktuellen Stand und
aktualisiert den Packetcache. aktualisiert den Paketcache.
\item[network\_interfaces] verwaltet Debians Netzkonfiguration \item[network\_interfaces] verwaltet Debians Netzkonfiguration
/etc/network/interfaces /etc/network/interfaces.
\item[minitest-handler] Sammelt alle Tests in den Cookbooks führt diese \item[minitest-handler] Sammelt alle Tests in den Cookbooks und führt diese
nach der Provisionierung aus (siehe~\ref{minitest_handler}) nach der Provisionierung aus (siehe~\ref{minitest_handler}).
\end{description} \end{description}
% vim: set spell spelllang=de_de % vim: set spell spelllang=de_de

View File

@ -3,11 +3,11 @@
\begin{itemize} \begin{itemize}
\item Analysieren Sie die Funktionsweise von Chef und gehen Sie auf \item Analysieren Sie die Funktionsweise von Chef und gehen Sie auf
Unterschiede zwischen Chef und Puppet ein Unterschiede zwischen Chef und Puppet ein.
\item Wählen Sie zwei Netzwerkdienste aus die während der Lehrveranstaltung \item Wählen Sie zwei Netzwerkdienste aus, die während der Lehrveranstaltung
besprochen wurden und erstellen Sie Provisionierungsvorlagen für diese besprochen wurden und erstellen Sie Provisionierungsvorlagen für diese.
\item Beschreiben Sie wie die Verifikation von Provisionierungsvorlagen \item Beschreiben Sie, wie die Verifikation von Provisionierungsvorlagen
bei der Bereitstellung von HPC-Software verwendet werden kann bei der Bereitstellung von HPC-Software verwendet werden kann.
\end{itemize} \end{itemize}
% vim: set spell spelllang=de_de % vim: set spell spelllang=de_de

View File

@ -1,49 +1,51 @@
\subsubsection{Verifikation} \subsubsection{Verifikation}
\label{ssub:verifikation} \label{ssub:verifikation}
Wie auch Software müssen auch Provisionierungsskripte getestet werden. Dies Wie auch in der Softwareentwicklung müssen Konfigurationssysteme getestet
gestaltet sich oft als schwierig, weil nicht immer eine exakte Kopie des werden. Dies gestaltet sich oft als schwierig, weil nicht immer eine exakte
aktuellen Produktionssystem zur Verfügung steht. Mit steigender Komplexität Kopie des aktuellen Produktionssystem zur Verfügung steht. Mit steigender
steigt der Aufwand geschriebene Cookbooks manuell zu testen. Im Folgenden werden Komplexität steigt der Aufwand, geschriebene Cookbooks manuell zu testen. Im
verschiedene Möglichkeiten aufgeführt, wie dies automatisiert werden kann. Folgenden werden verschiedene Möglichkeiten aufgeführt, wie dies automatisiert
werden kann.
Die erste und einfachste Methode ist der Befehl: Die erste und einfachste Methode ist der Befehl:
\shellcmd{knife cookbook test [COOKBOOKS...]} \shellcmd{knife cookbook test [COOKBOOKS...]}
Dieser überprüft den Rubyquellcode und die Templates des Cookbooks auf Syntaxfehler. Das Kommandozeilenprogramm \emph{knife} ist Teil von Chef. Es ist das primäre
Allerdings treten viele Fehler erst zur Laufzeit auf, insbesonderen da Ruby Verwaltungsprogramm für Adminstratoren. Der Unterbefehl \emph{cookbook test}
eine dynamische Programmiersprache. Ein anderes Programm ist foodcritic. Dies überprüft den Rubyquellcode und die Templates des Cookbooks auf Syntaxfehler.
ist eine statische Codeanalyse ähnlich \href{http://www.jslint.com/}{JSlint} Allerdings treten viele Fehler erst zur Laufzeit auf, insbesonderes da Ruby eine
oder \href{http://perl-critic.stacka.to/}{Perl::Critic}. Dabei wird der dynamische Programmiersprache ist. Ein anderes Programm ist foodcritic. Es führt
Rubycode gegen einen Regelsatz getestet, um so schlechten Stil zu erkennen oder eine statische Codeanalyse ähnlich \href{http://www.jslint.com/}{JSlint} oder
um Codingstandards innerhalb eines Projekts einzuhalten. Dieser Regelsatz kann \href{http://perl-critic.stacka.to/}{Perl::Critic} auf der eigenen Codebasis
durch eigene Regeln erweitern werden. durch. Dabei wird der Rubycode gegen einen Regelsatz getestet, um so häufige
Programmierfehler zu erkennen oder um Codingstandards innerhalb eines Projekts
einzuhalten. Dieser Regelsatz kann durch eigene Regeln erweitern werden.
\textbf{Chefspec} \textbf{Chefspec}
\label{chefspec} \label{chefspec}
Chefspec baut auf das in Ruby verbreitete Testframework Chefspec baut auf das, in Ruby verbreitete, Testframework
\href{http://rspec.info/}{RSpec} auf. Rspec ist ein Testframework, welches auf \href{http://rspec.info/}{RSpec} auf. Rspec ist ein Testframework, welches auf
\href{http://dannorth.net/2012/05/31/bdd-is-like-tdd-if/}{Behavior Driven \href{http://dannorth.net/2012/05/31/bdd-is-like-tdd-if/}{Behavior Driven
Development} (kurz BDD) basiert. Hierbei werden die Testcases in derartiger Form Development} (kurz BDD) basiert. Hierbei dokumentieren sich Testcases selbst
auf geschrieben, dass sie sich selbst dokumentieren. RSpec kann aus den durch Einfügen von Beschreibungen. RSpec kann Sätze aus diesen Beschreibungen
Beschreibungen Sätze bilden und so im Falle eines fehlgeschlagen Tests schnell bilden und so im Falle eines fehlgeschlagen Tests schnell darüber Auskunft
darüber Auskunft zu geben, was der Test getestet hat und aus welchen Grund geben, was der Test getestet hat und aus welchen Grund dieser fehlgeschlagen
dieser fehlgeschlagen ist. Chefspec erweitert dabei RSpec um die Möglichkeit ist. Chefspec erweitert dabei RSpec um die Funktion, Cookbooks zu laden und
Cookbooks zu laden und stellt spezielle Matcher (RSpec-Terminologie für stellt spezielle Matcher (RSpec-Terminologie für Assertions) bereit, um diese zu
Assertions) bereit, um diese zu testen. Wie bereits in testen. Wie bereits in Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt,
Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt, gibt es 2 Phasen bei der gibt es zwei Phasen bei der Ausführung von Chef. Bei Chefspec wird der
Ausführung von Chef. Bei Chefspec wird Provisionierungsprozess nur bis zur Provisionierungsprozess nur bis zur Convergingphase durchlaufen. Die eigenen
Convergingphase durchlaufen. Die eigenen Tests überprüfen nur die erzeugten Tests überprüfen nur die erzeugten \emph{Resources}. Dies hat den Vorteil, das
Resources. Dies hat den Vorteil, das Tests sehr schnell durchlaufen werden, da Tests sehr schnell durchlaufen werden, da keine Änderungen an einem System
keine Änderungen an einem System vorgenommen werden müssen. Dies hat Vorteile vorgenommen werden müssen. Dies hat Vorteile beim Entwickeln, weil man auf diese
beim Entwickeln, weil man auf diese Weise schnell Feedback bekommt. Das Weise schnell Feedback bekommt. Das Zusammenspiel mehrerer Cookbooks lässt sich
Zusammenspiel mehrerer Cookbooks lässt sich dadurch gut testen. Außerdem dadurch gut testen. Außerdem ermöglicht es, verschiedene
ermöglicht es verschiedene Konfigurationen/Betriebssysteme durchzutesten, ohne Konfigurationen/Betriebssysteme durchzutesten, ohne das diese (zeit)aufwendig
das diese (zeit)aufwendig aufgesetzt werden müssen. Da Chefspec allerdings zu aufgesetzt werden müssen. Da Chefspec allerdings zu keinen Zeitpunkt Code auf
keinen Zeitpunkt Code auf dem System ausführt, sind weitere Integrationstest dem System ausführt, sind weitere Integrationstest unerlässlich.
unerlässlich.
Der folgende Test wurde aus dem selbst geschriebenen NTP-Cookbook Der folgende Test wurde aus dem selbst geschriebenen NTP-Cookbook
(\ref{ssub:einrichtung-der-netzwerkdienste}) entnommen. (\ref{ssub:einrichtung-der-netzwerkdienste}) entnommen.
@ -68,39 +70,42 @@ end
Im \emph{chef\_run}-Block wird der fiktiven Node Attribute zugewiesen und das zu Im \emph{chef\_run}-Block wird der fiktiven Node Attribute zugewiesen und das zu
testende Cookbook ausgeführt. Das Ergebnis wird in diesem Beispiel in dem Objekt testende Cookbook ausgeführt. Das Ergebnis wird in diesem Beispiel in dem Objekt
\emph{chef\_run} gespeichert. Gegen dieses Objekt wird getestet, ob bestimmte \emph{chef\_run} gespeichert. Gegen dieses Objekt wird getestet, ob bestimmte
Resourcen korrekt initialisiert wurden. In diesem Fall wird überprüft, ob das \emph{Resources} korrekt initialisiert wurden. In diesem Fall wird überprüft, ob
Packet "ntp" installiert werden soll und ob das Subnetz in dem Template für das Paket \emph{ntp} installiert werden soll und ob das Subnetz in dem Template
Konfigurationsdatei \emph{/etc/ntp.conf} richtig gesetzt wird. in der Konfigurationsdatei \emph{/etc/ntp.conf} richtig gesetzt wird.
Die Tests werden mit dem Befehl \emph{rspec} ausgeführt. Wenn keine weiteren Argumente Die Tests werden mit dem Befehl \emph{rspec} ausgeführt. Wenn keine weiteren Argumente
angegeben sind, führt dieses Programm alle Dateien unterhalb des Ordners \emph{spec} angegeben sind, führt dieses Programm alle Dateien unterhalb des Ordners \emph{spec}
aus, dessen Dateinamen auf \emph{\_spec.rb} enden. aus, dessen Dateinamen auf \emph{\_spec.rb} enden.
Um alle drei obgenannten Testmethoden gleichzeitig ausführen zu lassen, wurde Um alle drei oben genannten Testmethoden gleichzeitig ausführen zu lassen, wurde
ein Rakefile geschrieben. \href{http://rake.rubyforge.org/}{Rake} ist das in Ruby ein Rakefile geschrieben. \href{http://rake.rubyforge.org/}{Rake} ist das, in
geschriebene Äquivalent zu Make, welches ein verbreitetes Buildprogramm auf Ruby geschriebene Äquivalent, zu Make, welches ein verbreitetes Buildprogramm
UNIX-Basierten Plattformen ist. Die Ausführung der Tests geschieht mit dem Befehl: auf Unix-Ähnlichen Plattformen ist. Die Tests werden durch den Task \emph{test}
ausgeführt:
\shellcmd{rake test} \shellcmd{rake test}
Dieser muss innerhalb Projektverzeichnis aufgerufen werden. Dieser muss innerhalb Projektverzeichnises aufgerufen werden.
\textbf{Minitest Handler} \textbf{Minitest-Handler}
\label{minitest_handler} \label{minitest_handler}
\href{https://github.com/btm/minitest-handler}{Minitest Handler} hingegen wird nach jedem Provisionierungsdurchgang \href{https://github.com/btm/minitest-handler}{Minitest-Handler} hingegen wird
ausgeführt. Im Gegensatz zu Chefspec nutzt es das Minitest Framework, welches nach jedem Provisionierungsdurchgang ausgeführt. Im Gegensatz zu Chefspec nutzt
schon mit Ruby mitgeliefert wird. Allerdings kann man durch einbinden, der Zeile: es das Minitest-Framework, welches schon mit Ruby mitgeliefert wird. Allerdings
kann man durch einbinden, der Zeile:
\begin{lstlisting} \begin{lstlisting}
require "minitest/spec" require "minitest/spec"
\end{lstlisting} \end{lstlisting}
eine RSpec sehr ähnliche Syntax benutzen. Um Minitest Handler zu nutzen, muss eine Syntax benutzen, die RSpec sehr ähnliche ist. Um Minitest-Handler zu
das Recipe aus minitest-handler-cookbook als erstes Recipe in der node geladen nutzen, muss das Recipe aus \emph{Minitest-Handler-Cookbook} als erstes Recipe
werden. Minitest Handler durchsucht beim Durchlauf in jedem anderen cookbook, in in der node geladen werden. Minitest-Handler durchsucht beim Durchlauf in jedem
den Unterordnern in \emph{files/} nach dem Verzeichnis \emph{test} und lädt anderen Cookbook, in den Unterordnern in \emph{files/} nach dem Verzeichnis
alle Tests aus diesem Verzeichnis. Über die Beschreibungszeile: \emph{test} und lädt alle Tests aus diesem Verzeichnis. Über die
Beschreibungszeile:
\begin{lstlisting}[language=Ruby] \begin{lstlisting}[language=Ruby]
describe_recipe "ntp::default" do # describe_recipe "ntp::default" do #
@ -108,11 +113,11 @@ describe_recipe "ntp::default" do #
end end
\end{lstlisting} \end{lstlisting}
wird angeben für, welches Recipe der Test gedacht ist (In diesem Fall das wird angeben, für welches Recipe der Test gedacht ist (In diesem Fall das
Defaultrecipe aus dem NTP-Cookbook). Wenn das entsprechende Recipe von der Node Defaultrecipe aus dem NTP-Cookbook). Wenn das entsprechende Recipe von der Node
ausgeführt wird, wird der dazugehörige Test nach dem Provisionierunsdurchlauf ausgeführt wird, wird der dazugehörige Test nach dem Provisionierungsdurchlauf
ebenfalls ausgeführt. Minitest Handler erweitert RSpec um nützliche Methoden um ebenfalls ausgeführt. Minitest-Handler erweitert RSpec um nützliche Methoden, um
den Status des Systems zu überprüfen. Hier ein Beispiel aus dem Bindcookbook, den Status des Systems zu überprüfen. Nachfolgend ein Beispiel aus dem Bind-Cookbook,
welches in Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} erwähnt wurde: welches in Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} erwähnt wurde:
\begin{lstlisting}[language=Ruby] \begin{lstlisting}[language=Ruby]
@ -128,10 +133,12 @@ end
Die Methode \emph{assert\_sh} überprüft den Exitstatus eines Befehls und schlägt 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 fehl, wenn dieser ungleich Null ist, während die \emph{service}-Methode den
Status eines Systemdienst sicherstellt. Es gibt noch weitere Testmethoden, wie Status eines Systemdienst sicherstellt. Weitere Testmedhoden sind zum Beispiel
das Überprüfen von Verzeichnissen, Inhalte von Dateien oder Mountpoints. Viele das Überprüfen von Verzeichnissen, Inhalte von Dateien oder Mountpoints. Viele
Fehler werden in der Regel schon von den Provider erkannt und festgestellt. Fehler werden in der Regel schon von den Provider erkannt und festgestellt.
Mit Minitest Handler kann dies Erweitern um zum Beispiel protokollspezifische Minitest-Handler kann dies Erweitern um protokollspezifische Tests durchzuführen
Tests durchzuführen. oder das Testen von Funktionalität bestimmter Dienste.
TODO Resume und Ausblick
% vim: set spell spelllang=de_de % vim: set spell spelllang=de_de

View File

@ -15,3 +15,12 @@
year = {2014} year = {2014}
note = "[Online, 20.03.2014]" note = "[Online, 20.03.2014]"
} }
@online{chefhistory,
author = {chef}
title = {{History of Chef: What's in a Name? }}
howpublished =
"\url{http://www.youtube.com/watch?v=Ia2ItmjRsw8&feature=plcp}",
year = {2014}
note = "[Online, 24.03.2014]"
}