chef: weitere TODOs erledigt

bericht/chef/chef-comparison.tex

@@ -44,7 +44,8 @@ Es gibt mehrere Möglichkeiten \emph{Chef} zu betreiben:
 \textbf{Aufbau eines Cookbook}
 \label{aufbau_eines_cookbook}
 
-Hier ist die Ordnerstruktur des Cookbook apt (TODO Link) dargestellt:
+Hier ist die Ordnerstruktur des Cookbook
+\href{https://github.com/opscode-cookbooks/apt}{apt} dargestellt:
 
 \begin{lstlisting}
 > apt-2.3.4/
@@ -138,16 +139,16 @@ dieser stehen beispielsweise Informationen mit welchen Chef-Server der Client
 verbinden soll, an welcher Stelle temporäre Daten gespeichert werden soll und
 der Name der Node. Letzteres ist wichtig um die Node richtig von Chef einordnen
 zu können und die richtigen Einstellungen zuzuweisen.  Alternativ kann der Name
-auch von der der Bibliothek \emph{Ohai} (TODO - Link) gesetzt werden, in dem auf
-den Hostnamen oder der FQDN (Fully Qualified Domain Name) zurück gegriffen wird.
-Ohai sammelt noch andere systemrelevante Daten wie Details über
-Hardwarekomponenten (Anzahl der CPUs, Größe und Art des RAMs, Netzwerkanbindung,
-Festplatten/SSDs, \dots), Informationen über die Plattform (Art des
-Betriebssystems und Version, installierte Software) und die laufenden Prozesse.
-Diese Informationen sind durch eigene Ohai-Plugins erweiterbar und können dann
-im Provisionierungsprozess genutzt werden um weitere Entscheidungen zu treffen.
-Sie sind darüber hinaus auch auf dem Server gespeichert und für andere Clients
-abrufbar.
+auch von der 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ück gegriffen wird.  Ohai sammelt noch andere systemrelevante Daten wie
+Details über Hardwarekomponenten (Anzahl der CPUs, Größe und Art des RAMs,
+Netzwerkanbindung, Festplatten/SSDs, \dots), Informationen über die Plattform
+(Art des Betriebssystems und Version, installierte Software) und die laufenden
+Prozesse.  Diese Informationen sind durch eigene Ohai-Plugins erweiterbar und
+können dann im Provisionierungsprozess genutzt werden um weitere Entscheidungen
+zu treffen.  Sie sind darüber hinaus auch auf dem Server gespeichert und für
+andere Clients abrufbar.
 
 Nach dem alle Einstellungen eingelesen sind, folgte im Falle von Chef-Server,
 die Authentifizierung mit diesem über den vorher auf der Node abgelegten
@@ -191,4 +192,5 @@ Monitoringssystem oder per Email verschicken. In letzten Abschnitt
 \textbf{Vergleich mit puppet}
 \label{vergleich_mit_puppet}
 
+
 % vim: set spell spelllang=de_de

bericht/chef/chef-services.tex

@@ -2,20 +2,23 @@
 \label{ssub:einrichtung-der-netzwerkdienste}
 
 Für die Provisionierung der Netzwerkdienste wurde
-\href{http://vagrantup.com}{\emph{vagrant}} verwendet. Dies ein Programm um auf
+\href{http://vagrantup.com}{Vagrant} verwendet. Dies 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
+in der datei \emph{Vagrantfile} geschrieben, welches Vagrant beim Start
 einliest. Vagrant bietet eine gute Integration für Chef. Es kann direkt
 eingestellt werden, mit welchen Einstellungen neue virtuelle Maschinen
 provisioniert werden sollen. Zum Einsatz kam das Betriebssystem Ubuntu 12.04
 LTS. Das Basisimage hierfür wurde von \emph{opscode}, der 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 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.
+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 Optioen. 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.
 
 Gestartet wird die VM mit dem Befehl:
 
@@ -28,9 +31,9 @@ folgenden Befehl gestartet werden:
 
 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 vorhanden, die es für vagrant gibt. Allerdings muss die
+vielen Images vorhanden, die es für Vagrant gibt. Allerdings muss die
 Virtualboxversion des Host mit dem der VM übereinstimmen. Abhilfe schafft das
-Vagrantplugin \emph{vagrant-vbguest} (TODO link). Dieses überprüft beim
+Vagrantplugin \href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}. Dieses überprüft beim
 Start die Versionen und installiert gegebenfalls eine Andere in der VM.
 
 Als Netzwerkdienste wurden die Protokolle DHCP, DNS und NTP gewählt. Die
@@ -55,14 +58,14 @@ Für das Deployment wurden fünf Cookbooks geschrieben:
     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
     festgelegt werden.
-  \item[lctp-network]
-    Dieses Cookbook ist ein Wrappercoobook um das network\_interfaces
-    (TODO link) Cookbook. Wrappercookbook 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. Auf den Headnodes wird eine statische IPadresse gesetzt,
-    der DNS-Server auf localhost festgelegt und Ipforwarding sowie
-    Masquerading via iptables für den Routerbetrieb aktiviert.
+  \item[lctp-network] Dieses Cookbook ist ein Wrappercoobook um das
+    \href{https://github.com/redguide/network_interfaces}{network\_interfaces}
+    Cookbook. Wrappercookbook 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.
+    Auf den Headnodes wird eine statische IPadresse gesetzt, der DNS-Server auf
+    localhost festgelegt und Ipforwarding sowie Masquerading via iptables für
+    den Routerbetrieb aktiviert.
   \item[ntp]
     Dieses Cookbook richtet den NTP-Deamon ein, welcher die Zeit zwischen den
     einzelnen Knoten synchron halten soll.
@@ -82,7 +85,7 @@ Es wurden folgende externen Cookbooks verwendet:
   \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{chef_minitest_handler})
+    nach der Provisionierung aus (siehe~\ref{minitest_handler})
 \end{description}
 
 Zur Verwaltung der externen und internen Cookbooks wurde die
@@ -90,8 +93,9 @@ Abhängigkeitsverwaltung \href{http://berkshelf.com}{Berkshelf} verwendet. Bei
 diesem gibt man die Abhängigkeiten und die gewünschte Version in einer Datei
 namens Berkssfile an (vergleichbar mit Gemfile in Ruby). Berkshelf lädt diese
 Abhängigkeiten aus verschiedenen Quellen herunter. (per Api von der
-Communityseite von Opscode, git, lokal) Für das Zusammenspiel mit vagrant gibt
-es das Plugin vagrant-berkshelf (TODO link), so dass die von Berkshelf verwalten
-Cookbooks auch in vagrant zur Verfügung stehen.
+Communityseite von Opscode, git, lokal) Für das Zusammenspiel mit Vagrant gibt
+es das Plugin
+\href{https://github.com/berkshelf/vagrant-berkshelf}{vagrant-berkshelf}, so
+dass die von Berkshelf verwalten Cookbooks auch in Vagrant zur Verfügung stehen.
 
 % vim: set spell spelllang=de_de

bericht/chef/chef-tests.tex

@@ -23,14 +23,22 @@ man durch eigene Regeln erweitern.
 \textbf{Chefspec}
 \label{chefspec}
 
-Chefspec baut auf das in Ruby verbreitete Testframework Rspec auf. Dies ist ein
-Vertreter des BDD (TODO mehr Infos zu BDD, Integration von Chefspec). Wie
-bereits in Abschnitt ~\ref{durchlauf_eines_recipes} erwähnt, gibt es 2 Phasen
-bei der Ausführung von Chef. Bei Chefspec wird Provisionierungsprozess nur bis
-zur Convergingphase, durchlaufen. Die eigenen Tests überprüfen nur die erzeugten
-Resourcen. Dies hat den Vorteil, das Tests sehr schnell durchlaufen werden, da
-keine Änderungen an einem System vorgenommen werden müssen. Dies hat Vorteile
-beim Entwickeln, weil man auf diese Weise schnell Feedback bekommt. Das
+Chefspec baut auf das in Ruby verbreitete Testframework \emph{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 wieso 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 nicht
@@ -68,9 +76,14 @@ Die Tests werden mit dem Befehl \emph{rspec} ausgeführt. Wenn keine weiteren Ar
 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, gibt es
-eine Rakefile (das in Ruby geschriebene Äquivalent zu GNU Make). Mithilfe des
-Befehls: TODO
+Um alle drei obgenannten Testmethoden gleichzeitig ausführen zu lassen, wurde
+ein Rakefile geschrieben. \href{http://rake.rubyforge.org/}{Rake} 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:
+
+\shellcmd{rake test}
+
+Dieser muss innerhalb Projektverzeichnis aufgerufen werden.
 
 \textbf{Minitest Handler}
 \label{minitest_handler}