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}
\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

View File

@ -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

View File

@ -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

View File

@ -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

View File

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