chef: Rechtschreibung und Ausdruck Teil II
This commit is contained in:
parent
95c5463398
commit
f22ca9ba3c
@ -1,58 +1,60 @@
|
||||
\subsubsection{Funktionsweise von Chef}
|
||||
\label{ssub:funktionsweise_von_chef}
|
||||
|
||||
\href{http://www.getchef.com/chef/}{Chef} ist ein Framework, welches es
|
||||
ermöglicht automatisiert Server zu konfigurieren und zu verwalten. Der
|
||||
Endanwender beschreibt hierbei die Systemresourcen und ihre Zustände in der
|
||||
\href{http://www.getchef.com/chef/}{Chef} ist ein Framework, welches eine
|
||||
automatisierte Serverkonfiguration und -verwaltung ermöglicht. (TODO -
|
||||
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
|
||||
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
|
||||
umzusetzen.
|
||||
|
||||
Die Gesamtheit aller Definitionen/Einstellungen nennt man das \emph{Chef-repo}.
|
||||
Diese untergliedert sich in mehrere \emph{Cookbooks}\label{cookbook}, welche die
|
||||
Grundverwaltungseinheit darstellt. Jedes dieser Cookbooks, erfüllt einen
|
||||
bestimmten Teilaspekt des Systems, (z.B. die Einrichtung eines Webservers
|
||||
\href{https://github.com/opscode-cookbooks/apache2}{Apache}). Cookbooks
|
||||
können versioniert werden. Es können Abhängigkeiten zwischen mehreren
|
||||
Cookbooks angegeben werden.
|
||||
Ein solches untergliedert sich in mehrere \emph{Cookbooks}\label{cookbook}. Ein
|
||||
Cookbook ist die Grundverwaltungseinheit in Chef. Es erfüllt einen bestimmten
|
||||
Teilaspekt des Systems (z.B. die Einrichtung eines Webservers
|
||||
\href{https://github.com/opscode-cookbooks/apache2}{Apache}). Cookbooks können
|
||||
versioniert werden. Es können Abhängigkeiten zwischen mehreren Cookbooks
|
||||
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
|
||||
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
|
||||
Cookbooks angewendet 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 dazu in die sogenannte \emph{Run-List} der
|
||||
Node eingefügt. Diese gibt die Reihenfolge an, in welcher Roles und Cookbooks
|
||||
angewendet werden. Roles bieten eine Möglichkeit, Nodes zu gruppieren, welche die
|
||||
gleichen Aufgaben in einer Organisation erfüllen (z.B. Webserver).
|
||||
|
||||
Es gibt mehrere Möglichkeiten \emph{Chef} zu betreiben:
|
||||
|
||||
\begin{description}
|
||||
\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 heißt bei dieser das auszuführende Programm
|
||||
\emph{chef-solo} statt \emph{chef-client}. Diese Form wurde für die
|
||||
Umsetzung der Aufgabenstellung in
|
||||
\item[Chef-Solo] Chef-Solo ist die einfachste Ausführungsform. Alle nötigen
|
||||
Daten werden aus einem lokalen Verzeichnis geladen. Im Gegensatz zu
|
||||
\emph{Chef-Server} und \emph{Enterprise Chef} wird bei Chef-Solo das
|
||||
Programm \emph{chef-solo} an Stelle von \emph{chef-client} ausgeführt. Diese
|
||||
Form wurde für die Umsetzung der Aufgabenstellung in
|
||||
Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} gewählt.
|
||||
\item[Chef-server] Hierbei authentifiziert sich \emph{Chef-client} über eine
|
||||
\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
|
||||
\item[Chef-Server] Hierbei authentifiziert sich \emph{Chef-Client} über eine
|
||||
\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 Informationen für die zu provisionierende \emph{Node}.
|
||||
Chef-server bietet eine webbasierte GUI für die Administration an. Die
|
||||
Attribute aller Nodes sind über die eingebaute Suchemaschine \emph{Solr}
|
||||
durchsuchbar.
|
||||
\item[Enterprise Chef/Hosted Enterprise Chef] Ähnlich wie Chef-server bietet
|
||||
aber eine bessere Skalierbarkeit, rolenbasierte Benutzerverwaltung, bessere
|
||||
Überwachung, eine verbesserte Weboberfläche sowie Push-Deployment an.
|
||||
Während Hosted Enterprise Chef die Firma Chef den Serverteil betreibt, ist
|
||||
bei Enterprise Chef der Server in der eigenen
|
||||
Organisation~\cite{chefenterprise}
|
||||
Chef-Server bietet eine webbasierte GUI für die Administration an. Die
|
||||
Attributes aller Nodes sind über die eingebaute Suchmaschine
|
||||
\href{https://lucene.apache.org/solr/}{\emph{Solr}} durchsuchbar.
|
||||
\item[Enterprise-Chef/Hosted-Enterprise-Chef] Enterprise-Chef bietet
|
||||
zusätzlich zu den Funktionen der Opensource-Version Chef-Server eine
|
||||
rollenbasierte Benutzerverwaltung, bessere Überwachung, eine verbesserte
|
||||
Weboberfläche sowie Push-Deployment an. Während bei Hosted-Enterprise-Chef
|
||||
die Firma Chef den Serverteil betreibt und die Skalierung des Dienstes
|
||||
übernimmt, ist bei Enterprise-Chef der Server in der eigenen
|
||||
Organisation~\cite{chefenterprise}.
|
||||
\end{description}
|
||||
|
||||
\textbf{Aufbau eines Cookbook}
|
||||
\textbf{Aufbau eines Cookbooks}
|
||||
\label{aufbau_eines_cookbook}
|
||||
|
||||
Hier ist die Ordnerstruktur eines Cookbooks am Beispiel von
|
||||
\href{https://github.com/opscode-cookbooks/apt}{apt} dargestellt:
|
||||
Nachfolgend ist die Ordnerstruktur eines Cookbooks am Beispiel von
|
||||
\href{https://github.com/opscode-cookbooks/apt}{apt} dargestellt.
|
||||
|
||||
\begin{tikzpicture}
|
||||
\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:
|
||||
|
||||
\begin{description}
|
||||
\item[attributes] setzt Standardwerte (Attribute) für das Cookbook. Dies
|
||||
können Strings, Zahlen oder Arrays sein. Die gesetzten Attribute können in
|
||||
Roles, Nodes oder von anderen Cookbooks überschrieben werden. Hierfür gibt
|
||||
es die Prioritäten default, force\_default, normal und override um die
|
||||
Reihenfolge zu beeinflussen. Attributes sind hierarchisch organisiert. In
|
||||
der Regel ist die höchste Ebene der Name des Cookbooks. (z.B.
|
||||
\emph{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 und
|
||||
\item[attributes] Attributes sind einfache Schlüssel-Wert-Beziehungen und
|
||||
setzen Standardwerte für das Cookbook. Die Schlüssel sind hierarchisch
|
||||
organisiert. In der Regel ist die höchste Ebene der Name des Cookbooks (z.B.
|
||||
\emph{normal.mysql.client.packages}). Werte können Strings, Zahlen oder
|
||||
Arrays sein. Die gesetzten Attributes können in Roles, Nodes oder von
|
||||
anderen Cookbooks überschrieben werden. Hierfür werden die Attributes mit
|
||||
den verschiedenen Prioritäten default, force\_default, normal und override
|
||||
gesetzt (aufsteigender Wertigkeit) gesetzt, wobei eine höhere Priorität eine
|
||||
Niedrigere überschreibt.
|
||||
\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.
|
||||
\item[resources] Ressourcen beschreiben, die Bestandteile eines Systems. Eine
|
||||
Ressource kann z.B. eine Datei, ein Prozess oder ein Packet sein. Man
|
||||
\item[resources] Ressourcen beschreiben die Bestandteile eines Systems. Eine
|
||||
Resource kann z.B. eine Datei, ein Prozess oder ein Paket sein. Man
|
||||
beschreibt, welchen Zustand (Action in Chef genannt) diese Ressource haben
|
||||
soll und Chef versucht diesen Zustand herzustellen. Chef liefert von Haus
|
||||
viele wichtige Ressourcen mit. In Cookbooks können man darüber hinaus eigene
|
||||
Ressourcen definiert werden.
|
||||
soll und Chef versucht, diesen Zustand herzustellen. Chef liefert bereits
|
||||
viele wichtige Ressourcen mit. In Cookbooks können darüber hinaus eigene
|
||||
Resources definiert werden.
|
||||
\item[providers] Während Ressourcen nur die Schnittstelle mit allen Attributes
|
||||
beschreiben, die gesetzt werden können, ist der Provider eine konkrete
|
||||
Implementierung. Deswegen muss für jede Ressource mindestens ein Provider
|
||||
existieren. Es kann mehrere Provider für eine Ressource geben, um zum
|
||||
Beispiel um mehrere Plattformenvarianten oder Betriebssysteme abdecken zu
|
||||
können (z.B. bei Packetmanagern oder Initsystemen).
|
||||
\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, welche häufiger in verschiedenen Recipes auf
|
||||
ähnliche Art und Weise benötigt werden, können in eine \emph{Definition}
|
||||
ausgelagert werden.
|
||||
können (z.B. bei Paketmanagern oder Initsystemen TODO - Initsystemen
|
||||
erklären). In eigenen Cookbooks erstellte Resources/Provider nennt man LWRP
|
||||
(Lightweight-Resource/Provider).
|
||||
\item[recipes] In Recipes werden Ressourcen instanziiert, welche nötig sind,
|
||||
um die gewünschte Ziel zu erreichen. Dabei können Abhängigkeiten zwischen
|
||||
Recipes angegeben 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
|
||||
Beispiel Konfigurationsdateien zu erzeugen. Chef bindet hierfür die
|
||||
Templatesprache eRuby (Embedded Ruby) ein. Diese führt in den Templates
|
||||
Rubycode, der sich zwischen den Tags \emph{<\%} und \emph{\%>} befindet, aus.
|
||||
Dies erlaubt es Variablen zu interpolieren, sowie If-Statements und
|
||||
Schleifen.
|
||||
\item[metadata.rb] In dieser Datei kann der Name des Cookbook, die Version,
|
||||
eine Beschreibung sowie Abhängigkeiten zu anderen Cookbooks angeben werden.
|
||||
Beispiel Konfigurationsdateien zu erzeugen. In Chef wird für diesen Zweck
|
||||
die Templatesprache eRuby (Embedded Ruby) verwendet. In ERB-Templates wird
|
||||
Rubycode ausgeführt, der sich zwischen den Tags \emph{<\%} und \emph{\%>}
|
||||
befindet. Dies erlaubt es einerseits den Inhalt von Variablen oder den
|
||||
Rückgabewert von Methoden zu interpolieren, andererseits können in Templates
|
||||
Kontrollstrukturen wie If-Statements und Schleifen verwendet 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}
|
||||
|
||||
Beispiel ERB-Template:
|
||||
@ -151,73 +162,98 @@ Beispiel ERB-Template:
|
||||
\end{lstlisting}
|
||||
|
||||
\textbf{Ablauf einer Provisonierung}
|
||||
\label{ablauf_einer_provisionierung}
|
||||
|
||||
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 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 - siehe~\ref{ssub:einrichtung-der-netzwerkdienste}).
|
||||
\label{ablauf_einer_provisionierung}\\
|
||||
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 gewählter Umgebung 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 - siehe~\ref{ssub:einrichtung-der-netzwerkdienste}).
|
||||
|
||||
Als erstes lädt dieser Prozess seine Konfiguration aus der Datei
|
||||
\emph{client.rb}. In dieser stehen beispielsweise Informationen mit welchen
|
||||
Chef-Server der Client sich 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{client.rb}. In dieser stehen beispielsweise die URL des Chef-Server, in
|
||||
welchem Pfad temporäre Dateien gespeichert werden und der Name der Node.
|
||||
Letzteres ist wichtig, um die Node in Chef einordnen zu können und die richtigen
|
||||
Einstellungen zuzuweisen. Alternativ kann der Name auch von der Bibliothek
|
||||
\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.
|
||||
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 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.
|
||||
Ohai sammelt 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 sowie dessen Version,
|
||||
installierte Anwendungssoftware) und die laufenden Prozesse. Diese Informationen sind
|
||||
durch eigene Ohai-Plugins erweiterbar und können 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, folgt 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
|
||||
Nach dem alle Einstellungen eingelesen sind, verbindet sich Chef-Client mit
|
||||
Chef-Server. Die Authentifizierung erfolgt über den vorher auf der Node
|
||||
abgelegten RSA-Schlüssel. Für Administratoren gibt es einen Validator-Key. Im
|
||||
\href{http://docs.opscode.com/knife\_bootstrap.html}{Bootstraprozess}, in
|
||||
welchem Chef initial auf der Node installiert wird, dafür einen Validatorkey.
|
||||
Mit diesem kann eine Node auf dem Server registriert werden, umso einen
|
||||
Clientkey zu generieren.
|
||||
welchem Chef initial auf der Node installiert, kann mit diesem eine Node auf dem
|
||||
Server registriert werden und ein Clientkey generiert werden.
|
||||
|
||||
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.
|
||||
Anschließend werden alte gesetzte Attributes und die Run-List vom Server
|
||||
übertragen. Im 1. Durchlauf oder bei Verwendung von Chef-Solo sind diese Daten
|
||||
nicht vorhanden. Stattdessen kann eine Datei im JSON-Format angegeben werden,
|
||||
um die Attributes und der Run-List für die Node zu spezifizieren. Außerdem ist
|
||||
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
|
||||
benötigen Cookbooks ermittelt. Der Client fordert für diese eine Liste aller
|
||||
Durch Auswertung der eingebunden Rollen und Recipes werden die benötigen
|
||||
Cookbooks ermittelt. Der Client fordert eine Liste aller darin enthaltenen
|
||||
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
|
||||
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.
|
||||
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 Resource-Collection zusammengefasst. Nachdem alle Definitions
|
||||
und Libraries geladen wurden, werden schließlich die Recipes verarbeitet. Die
|
||||
darin erstellten Resources beschreiben das System. Für jede Resource wird eine
|
||||
Action festgelegt, was gleichbedeutend mit deren Zustand ist.
|
||||
|
||||
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.
|
||||
Im nächsten Schritt folgt das sogenannte Converging (englisch für
|
||||
\emph{Angleichen}). Es werden alle Resources Schritt für Schritt 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.
|
||||
Es besteht die Möglichkeit Handler vor oder nach dem Provisioning auszuführen.
|
||||
Diese können 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}
|
||||
\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
|
||||
|
||||
@ -2,33 +2,35 @@
|
||||
\label{ssub:einrichtung-der-netzwerkdienste}
|
||||
|
||||
Für die Provisionierung der Netzwerkdienste wurde
|
||||
\href{http://vagrantup.com}{Vagrant} verwendet. Dies ist ein Programm um auf der
|
||||
Basis von Virtualbox und anderen Virtualisierungslösungen schnell und
|
||||
\href{http://vagrantup.com}{Vagrant} verwendet. Dies ist ein Programm, um auf
|
||||
der Basis von Virtualbox und anderen Virtualisierungslösungen schnell und
|
||||
reproduzierbar virtuelle Maschinen zu starten. Die Einstellungen hierfür werden
|
||||
in der Datei \emph{Vagrantfile} geschrieben, welches Vagrant beim Start
|
||||
einliest. Vagrant bietet eine gute Integration für Chef. Es bietet Optionen, mit
|
||||
welchen Einstellungen neue virtuelle Maschinen provisioniert werden sollen. Zum
|
||||
Einsatz kam das Betriebssystem Ubuntu in der Version 12.04. Das Basisimage
|
||||
hierfür wurde von \emph{Chef}, der gleichnamigen Firma hinter Chef,
|
||||
bereitgestellt. Es wurde ein Netzwerkinterface konfiguriert für die
|
||||
Kommunikation mit Vagrant und ein weiteres Internes für ein virtuelles Netzwerk
|
||||
zwischen den VMs zum Betreiben der Netzwerkdienste. Vagrant bietet für diese
|
||||
erweiterten Einstellungen keine Optionen. Um diese dennoch zu übernehmen, waren
|
||||
spezielle Kommandozeilenargumente an den Befehl \emph{VBoxManage} nötig, welches
|
||||
von Vagrant für Virtualbox genutzt wird. Dies schränkt Nutzung allerdings auf
|
||||
die Visualisierung Virtualbox ein. Vagrant bietet die Möglichkeit neben
|
||||
Provisionierungsystemen auch Shellskripte auszuführen. Diese wurde genutzt um
|
||||
Chef auf die zum damaligen Zeitpunkt aktuellste Version 11.8.2 upzudaten.
|
||||
in der Datei \emph{Vagrantfile} hinterlegt, welche Vagrant beim Start einliest.
|
||||
Vagrant kann Chef beim Erstellen von virtuellen Maschinen integrieren. Es
|
||||
bietet Optionen, mit welchen Einstellungen neue virtuelle Maschinen
|
||||
provisioniert werden sollen. Zum Einsatz kam das Betriebssystem Ubuntu in der
|
||||
Version 12.04. Das Basisimage hierfür wurde von \emph{Chef}, der gleichnamigen
|
||||
Firma, bereitgestellt. Für die Kommunikation mit Vagrant wurde das
|
||||
Netzwerkinterface \emph{eth0} konfiguriert. Ein weiteres Netzwerkinterface
|
||||
(\emph{eth1}) wird für das interne virtuelle Netzwerk zwischen den VMs zum
|
||||
Betreiben der Netzwerkdienste benötigt. Vagrant bietet für diese erweiterten
|
||||
Einstellungen keine Optionen. Um diese dennoch zu übernehmen, waren spezielle
|
||||
Kommandozeilenargumente an den Befehl \emph{VBoxManage} nötig, welches von
|
||||
Vagrant für Virtualbox genutzt wird. Dies schränkt die Nutzung allerdings auf
|
||||
den Hypervisor Virtualbox ein. Vagrant bietet die Möglichkeit, neben
|
||||
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
|
||||
ausführen zu können. Auf Unix-basierten Systemen kann dies mit dem Befehl:
|
||||
Desweiteren wird Ruby auf dem Host benötigt, um beispielsweise die Tests
|
||||
ausführen zu können. Auf Unix-Ähnlichen Systemen kann dies mit dem Befehl:
|
||||
|
||||
\shellcmd{curl -sSL https://get.rvm.io | bash -s stable}
|
||||
|
||||
installiert werden. Auf Windows kann der
|
||||
\href{http://rubyinstaller.org/}{RubyInstaller} genutzt werden. Um die nötigen
|
||||
Abhängigkeiten zu installieren, müssen folgende Befehle ausgeführt im
|
||||
Projektverzeichnis werden:
|
||||
installiert werden. Auf dem Betriebssystem Windows kann auf den
|
||||
\href{http://rubyinstaller.org/}{RubyInstaller} zurückgegriffen werden. Um die
|
||||
benötigten Ruby-Bibliotheken zu installieren, müssen folgende 2 Befehle im
|
||||
Projektverzeichnis ausgeführt werden:
|
||||
|
||||
\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
|
||||
verschiedene Quellen (per Api von der Communityseite von Opscode, Git, lokal)
|
||||
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}
|
||||
|
||||
@ -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
|
||||
stehen.
|
||||
|
||||
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
|
||||
vielen Images, die es für Vagrant gibt, vorhanden. Allerdings muss die
|
||||
Virtualboxversion des Host mit Dem in der VM übereinstimmen. Abhilfe schafft das
|
||||
Vagrantplugin \href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}.
|
||||
Dieses vergleicht beim Start die Versionen und installiert gegeben falls eine
|
||||
Andere in der VM.
|
||||
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 in
|
||||
meisten vielen Images vorhanden, die es für Vagrant gibt. Allerdings muss die
|
||||
Virtualboxversion des Host mit der Version in der VM übereinstimmen. Abhilfe
|
||||
schafft das Vagrantplugin
|
||||
\href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}. Beim
|
||||
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-berkshelf}
|
||||
|
||||
installiert.
|
||||
|
||||
Gestartet wird die VM mit dem Befehl:
|
||||
|
||||
\shellcmd{vagrant up}
|
||||
|
||||
Beim 1. Start wird die VM mit Chef provisioniert. Später kann Chef erneut mit
|
||||
folgenden Befehl gestartet werden:
|
||||
Während des ersten Starts wird die VM mit Chef provisioniert. Später kann Chef
|
||||
erneut mit Befehl:
|
||||
|
||||
\shellcmd{vagrant provision}
|
||||
|
||||
Als Netzwerkdienste wurden die Protokolle DHCP, DNS und NTP gewählt. Die
|
||||
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.
|
||||
gestartet werden:
|
||||
|
||||
Die Attribute der Roles und Node wurden in JSON-Dateien abgelegt in den Ordnern
|
||||
\emph{roles/} und \emph{nodes}. Es gibt je eine Role für die Computenode und
|
||||
Headnode. In der aktuellen Konfiguration erzeugt Vagrant eine Headnode
|
||||
mit dem Hostnamen \emph{node0.lctp} und zwei Computenodes (\emph{node1.lctp} und
|
||||
\emph{node2.lctp}).
|
||||
Als Netzwerkdienste wurden die Protokolle DHCP, DNS und NTP gewählt. Die VMs
|
||||
wurden in die zwei Gruppen \emph{Headnodes}und \emph{Computenodes} geteilt. Die
|
||||
Headnode bietet die genannten Dienste an. Die Computenodes fordern auf dem
|
||||
internen Netzwerk per DHCP eine IP-Adresse an und nutzen den DNS- und NTP-Dienst
|
||||
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:
|
||||
\begin{description}
|
||||
\item[bind]
|
||||
Als DNS-Server wurde bind gewählt. Dieses Cookbook richtet diesen Dienst ein
|
||||
und fügt die in den Attributen konfigurierten DNS-Einträge hinzu zu den
|
||||
Als DNS-Server wurde bind gewählt. Das Cookbook richtet diesen Dienst ein
|
||||
und fügt, die in den Attributes konfigurierten, DNS-Einträge zu den
|
||||
entsprechenden Zonen hinzu.
|
||||
\item[dhcp]
|
||||
Dieses Cookbook richtet den ISC DHCP-Server ein. Neben der Zuordnung von
|
||||
festen IP-Adressen zu Nodes, kann ein DNS-Server und ein NTP-Server
|
||||
Dieses Cookbook richtet den ISC-DHCP-Server (TODO Link) ein. Neben der
|
||||
Zuordnung von festen IP-Adressen zu Nodes, kann ein DNS-Server und ein
|
||||
NTP-Server
|
||||
festgelegt werden.
|
||||
\item[lctp-network] Dieses Cookbook ist ein Wrappercookbook um das
|
||||
\href{https://github.com/redguide/network_interfaces}{network\_interfaces}
|
||||
Cookbook. Wrappercookbooks werden häufig dazu benutzt um bestehende Cookbooks
|
||||
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
|
||||
localhost festgelegt und IP-Forwarding sowie Masquerading via iptables für
|
||||
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
|
||||
einzelnen Knoten synchron halten soll.
|
||||
\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
|
||||
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
|
||||
schwierig.
|
||||
\end{description}
|
||||
|
||||
Es wurden folgende externen Cookbooks verwendet:
|
||||
\begin{description}
|
||||
\item[apt] bringt die lokalen Packetquellen auf den aktuellen Stand und
|
||||
aktualisiert den Packetcache.
|
||||
\item[apt] bringt die lokalen Paketquellen auf den aktuellen Stand und
|
||||
aktualisiert den Paketcache.
|
||||
\item[network\_interfaces] verwaltet Debians Netzkonfiguration
|
||||
/etc/network/interfaces
|
||||
\item[minitest-handler] Sammelt alle Tests in den Cookbooks führt diese
|
||||
nach der Provisionierung aus (siehe~\ref{minitest_handler})
|
||||
/etc/network/interfaces.
|
||||
\item[minitest-handler] Sammelt alle Tests in den Cookbooks und führt diese
|
||||
nach der Provisionierung aus (siehe~\ref{minitest_handler}).
|
||||
\end{description}
|
||||
|
||||
% vim: set spell spelllang=de_de
|
||||
|
||||
@ -3,11 +3,11 @@
|
||||
|
||||
\begin{itemize}
|
||||
\item Analysieren Sie die Funktionsweise von Chef und gehen Sie auf
|
||||
Unterschiede zwischen Chef und Puppet ein
|
||||
\item Wählen Sie zwei Netzwerkdienste aus die während der Lehrveranstaltung
|
||||
besprochen wurden und erstellen Sie Provisionierungsvorlagen für diese
|
||||
\item Beschreiben Sie wie die Verifikation von Provisionierungsvorlagen
|
||||
bei der Bereitstellung von HPC-Software verwendet werden kann
|
||||
Unterschiede zwischen Chef und Puppet ein.
|
||||
\item Wählen Sie zwei Netzwerkdienste aus, die während der Lehrveranstaltung
|
||||
besprochen wurden und erstellen Sie Provisionierungsvorlagen für diese.
|
||||
\item Beschreiben Sie, wie die Verifikation von Provisionierungsvorlagen
|
||||
bei der Bereitstellung von HPC-Software verwendet werden kann.
|
||||
\end{itemize}
|
||||
|
||||
% vim: set spell spelllang=de_de
|
||||
|
||||
@ -1,49 +1,51 @@
|
||||
\subsubsection{Verifikation}
|
||||
\label{ssub:verifikation}
|
||||
|
||||
Wie auch Software müssen auch Provisionierungsskripte getestet werden. Dies
|
||||
gestaltet sich oft als schwierig, weil nicht immer eine exakte Kopie des
|
||||
aktuellen Produktionssystem zur Verfügung steht. Mit steigender Komplexität
|
||||
steigt der Aufwand geschriebene Cookbooks manuell zu testen. Im Folgenden werden
|
||||
verschiedene Möglichkeiten aufgeführt, wie dies automatisiert werden kann.
|
||||
Wie auch in der Softwareentwicklung müssen Konfigurationssysteme getestet
|
||||
werden. Dies gestaltet sich oft als schwierig, weil nicht immer eine exakte
|
||||
Kopie des aktuellen Produktionssystem zur Verfügung steht. Mit steigender
|
||||
Komplexität steigt der Aufwand, geschriebene Cookbooks manuell zu testen. Im
|
||||
Folgenden werden verschiedene Möglichkeiten aufgeführt, wie dies automatisiert
|
||||
werden kann.
|
||||
|
||||
Die erste und einfachste Methode ist der Befehl:
|
||||
|
||||
\shellcmd{knife cookbook test [COOKBOOKS...]}
|
||||
|
||||
Dieser überprüft den Rubyquellcode und die Templates des Cookbooks auf Syntaxfehler.
|
||||
Allerdings treten viele Fehler erst zur Laufzeit auf, insbesonderen da Ruby
|
||||
eine dynamische Programmiersprache. Ein anderes Programm ist foodcritic. Dies
|
||||
ist eine statische Codeanalyse ähnlich \href{http://www.jslint.com/}{JSlint}
|
||||
oder \href{http://perl-critic.stacka.to/}{Perl::Critic}. Dabei wird der
|
||||
Rubycode gegen einen Regelsatz getestet, um so schlechten Stil zu erkennen oder
|
||||
um Codingstandards innerhalb eines Projekts einzuhalten. Dieser Regelsatz kann
|
||||
durch eigene Regeln erweitern werden.
|
||||
Das Kommandozeilenprogramm \emph{knife} ist Teil von Chef. Es ist das primäre
|
||||
Verwaltungsprogramm für Adminstratoren. Der Unterbefehl \emph{cookbook test}
|
||||
überprüft den Rubyquellcode und die Templates des Cookbooks auf Syntaxfehler.
|
||||
Allerdings treten viele Fehler erst zur Laufzeit auf, insbesonderes da Ruby eine
|
||||
dynamische Programmiersprache ist. Ein anderes Programm ist foodcritic. Es führt
|
||||
eine statische Codeanalyse ähnlich \href{http://www.jslint.com/}{JSlint} oder
|
||||
\href{http://perl-critic.stacka.to/}{Perl::Critic} auf der eigenen Codebasis
|
||||
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}
|
||||
\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://dannorth.net/2012/05/31/bdd-is-like-tdd-if/}{Behavior Driven
|
||||
Development} (kurz BDD) basiert. Hierbei werden die Testcases in derartiger Form
|
||||
auf geschrieben, dass sie sich selbst dokumentieren. RSpec kann aus den
|
||||
Beschreibungen Sätze bilden und so im Falle eines fehlgeschlagen Tests schnell
|
||||
darüber Auskunft zu geben, was der Test getestet hat und aus welchen Grund
|
||||
dieser fehlgeschlagen ist. Chefspec erweitert dabei RSpec um die Möglichkeit
|
||||
Cookbooks zu laden und stellt spezielle Matcher (RSpec-Terminologie für
|
||||
Assertions) bereit, um diese zu testen. Wie bereits in
|
||||
Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt, gibt es 2 Phasen bei der
|
||||
Ausführung von Chef. Bei Chefspec wird Provisionierungsprozess nur bis zur
|
||||
Convergingphase durchlaufen. Die eigenen Tests überprüfen nur die erzeugten
|
||||
Resources. 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 zu
|
||||
keinen Zeitpunkt Code auf dem System ausführt, sind weitere Integrationstest
|
||||
unerlässlich.
|
||||
Development} (kurz BDD) basiert. Hierbei dokumentieren sich Testcases selbst
|
||||
durch Einfügen von Beschreibungen. RSpec kann Sätze aus diesen Beschreibungen
|
||||
bilden und so im Falle eines fehlgeschlagen Tests schnell darüber Auskunft
|
||||
geben, was der Test getestet hat und aus welchen Grund dieser fehlgeschlagen
|
||||
ist. Chefspec erweitert dabei RSpec um die Funktion, Cookbooks zu laden und
|
||||
stellt spezielle Matcher (RSpec-Terminologie für Assertions) bereit, um diese zu
|
||||
testen. Wie bereits in Abschnitt~\ref{ablauf_einer_provisionierung} erwähnt,
|
||||
gibt es zwei Phasen bei der Ausführung von Chef. Bei Chefspec wird der
|
||||
Provisionierungsprozess nur bis zur Convergingphase durchlaufen. Die eigenen
|
||||
Tests überprüfen nur die erzeugten \emph{Resources}. 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 zu keinen Zeitpunkt Code auf
|
||||
dem System ausführt, sind weitere Integrationstest unerlässlich.
|
||||
|
||||
Der folgende Test wurde aus dem selbst geschriebenen NTP-Cookbook
|
||||
(\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
|
||||
testende Cookbook ausgeführt. Das Ergebnis wird in diesem Beispiel in dem Objekt
|
||||
\emph{chef\_run} gespeichert. Gegen dieses Objekt wird getestet, ob bestimmte
|
||||
Resourcen korrekt initialisiert wurden. In diesem Fall wird überprüft, ob das
|
||||
Packet "ntp" installiert werden soll und ob das Subnetz in dem Template für
|
||||
Konfigurationsdatei \emph{/etc/ntp.conf} richtig gesetzt wird.
|
||||
\emph{Resources} korrekt initialisiert wurden. In diesem Fall wird überprüft, ob
|
||||
das Paket \emph{ntp} installiert werden soll und ob das Subnetz in dem Template
|
||||
in der Konfigurationsdatei \emph{/etc/ntp.conf} richtig gesetzt wird.
|
||||
|
||||
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}
|
||||
aus, dessen Dateinamen auf \emph{\_spec.rb} enden.
|
||||
|
||||
Um alle drei obgenannten Testmethoden gleichzeitig ausführen zu lassen, wurde
|
||||
ein Rakefile geschrieben. \href{http://rake.rubyforge.org/}{Rake} ist das in Ruby
|
||||
geschriebene Äquivalent zu Make, welches ein verbreitetes Buildprogramm auf
|
||||
UNIX-Basierten Plattformen ist. Die Ausführung der Tests geschieht mit dem Befehl:
|
||||
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 geschriebene Äquivalent, zu Make, welches ein verbreitetes Buildprogramm
|
||||
auf Unix-Ähnlichen Plattformen ist. Die Tests werden durch den Task \emph{test}
|
||||
ausgeführt:
|
||||
|
||||
\shellcmd{rake test}
|
||||
|
||||
Dieser muss innerhalb Projektverzeichnis aufgerufen werden.
|
||||
Dieser muss innerhalb Projektverzeichnises aufgerufen werden.
|
||||
|
||||
\textbf{Minitest Handler}
|
||||
\textbf{Minitest-Handler}
|
||||
\label{minitest_handler}
|
||||
|
||||
\href{https://github.com/btm/minitest-handler}{Minitest Handler} hingegen wird nach jedem Provisionierungsdurchgang
|
||||
ausgeführt. Im Gegensatz zu Chefspec nutzt es das Minitest Framework, welches
|
||||
schon mit Ruby mitgeliefert wird. Allerdings kann man durch einbinden, der Zeile:
|
||||
\href{https://github.com/btm/minitest-handler}{Minitest-Handler} hingegen wird
|
||||
nach jedem Provisionierungsdurchgang ausgeführt. Im Gegensatz zu Chefspec nutzt
|
||||
es das Minitest-Framework, welches schon mit Ruby mitgeliefert wird. Allerdings
|
||||
kann man durch einbinden, der Zeile:
|
||||
|
||||
\begin{lstlisting}
|
||||
require "minitest/spec"
|
||||
\end{lstlisting}
|
||||
|
||||
eine RSpec sehr ähnliche Syntax benutzen. Um Minitest Handler zu nutzen, muss
|
||||
das Recipe aus minitest-handler-cookbook als erstes Recipe in der node geladen
|
||||
werden. Minitest Handler durchsucht beim Durchlauf in jedem anderen cookbook, in
|
||||
den Unterordnern in \emph{files/} nach dem Verzeichnis \emph{test} und lädt
|
||||
alle Tests aus diesem Verzeichnis. Über die Beschreibungszeile:
|
||||
eine Syntax benutzen, die RSpec sehr ähnliche ist. Um Minitest-Handler zu
|
||||
nutzen, muss das Recipe aus \emph{Minitest-Handler-Cookbook} als erstes Recipe
|
||||
in der node geladen werden. Minitest-Handler durchsucht beim Durchlauf in jedem
|
||||
anderen Cookbook, in den Unterordnern in \emph{files/} nach dem Verzeichnis
|
||||
\emph{test} und lädt alle Tests aus diesem Verzeichnis. Über die
|
||||
Beschreibungszeile:
|
||||
|
||||
\begin{lstlisting}[language=Ruby]
|
||||
describe_recipe "ntp::default" do #
|
||||
@ -108,11 +113,11 @@ describe_recipe "ntp::default" do #
|
||||
end
|
||||
\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
|
||||
ausgeführt wird, wird der dazugehörige Test nach dem Provisionierunsdurchlauf
|
||||
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,
|
||||
ausgeführt wird, wird der dazugehörige Test nach dem Provisionierungsdurchlauf
|
||||
ebenfalls ausgeführt. Minitest-Handler erweitert RSpec um nützliche Methoden, um
|
||||
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:
|
||||
|
||||
\begin{lstlisting}[language=Ruby]
|
||||
@ -128,10 +133,12 @@ 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
|
||||
Status eines Systemdienst sicherstellt. Weitere Testmedhoden sind zum Beispiel
|
||||
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.
|
||||
Minitest-Handler kann dies Erweitern um protokollspezifische Tests durchzuführen
|
||||
oder das Testen von Funktionalität bestimmter Dienste.
|
||||
|
||||
TODO Resume und Ausblick
|
||||
|
||||
% vim: set spell spelllang=de_de
|
||||
|
||||
@ -15,3 +15,12 @@
|
||||
year = {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]"
|
||||
}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user