chef: verschiedenes

bericht/chef/chef-services.tex

@@ -12,7 +12,10 @@ 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.
+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.
 
 Gestartet wird die VM mit dem Befehl:
 
@@ -36,6 +39,12 @@ und \emph{Computenodes}. Die Computenodes fordern auf dem internen Netzwerk per
 DHCP eine IP-Adresse an und nutzen den DNS- und NTP-Dienst des jeweiligen
 Headnode.
 
+Die Attribute der Roles und Node wurden in JSON-Dateien abgelegt in den Ordnern
+\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}).
+
 Für das Deployment wurden fünf Cookbooks geschrieben:
 \begin{description}
   \item[bind]
@@ -76,15 +85,13 @@ Es wurden folgende externen Cookbooks verwendet:
     nach der Provisionierung aus (siehe~\ref{chef_minitest_handler})
 \end{description}
 
-Zur Verwaltung der externen und internen Cookbooks wurde
-\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.
-
-TODO Roles und Nodes json
+Zur Verwaltung der externen und internen Cookbooks wurde die
+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.
 
 % vim: set spell spelllang=de_de

bericht/chef/chef-task.tex

@@ -4,7 +4,7 @@
 \begin{itemize}
 \item Analysieren Sie die Funktionsweise von Chef und gehen Sie auf
   Unterschiede zwischen Chef und Puppet ein
-\item WählenSie zwei Netzwerkdienste aus die während der Lehrveranstaltung
+\item Wählen Sie zwei Netzwerkdienste aus die während der Lehrveranstaltung
   besprochen wurden und erstellen Sie Provisionierungsvorlagen für diese
 \item Beschreiben Sie wie die Verifikation von Provisionierungsvorlagen
   bei der Bereitstellung von HPC-Software verwendet werden kann

bericht/chef/chef-tests.tex

@@ -59,11 +59,17 @@ 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
+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.
 
-TODO Ausführung
+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.
 
-TODO rake test
+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
 
 \textbf{Minitest Handler}
 \label{minitest_handler}
@@ -79,22 +85,21 @@ require "minitest/spec"
 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 von \emph{files/} nach dem Verzeichnis \emph{test} und lädt
+den Unterordnern in \emph{files/} nach dem Verzeichnis \emph{test} und lädt
 alle Tests aus diesem Verzeichnis. Über die Beschreibungszeile:
 
 \begin{lstlisting}
-describe_recipe "ntp::default" do # 
+describe_recipe "ntp::default" do #
 #...
 end
 \end{lstlisting}
 
 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 nach der entsprechende 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 bind cookbook, welches in
-Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} erwähnt wurde:
+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 bind cookbook,
+welches in Abschnitt~\ref{ssub:einrichtung-der-netzwerkdienste} erwähnt wurde:
 
 \begin{lstlisting}
 describe_recipe 'bind::default' do
@@ -108,8 +113,8 @@ end
 \end{lstlisting}
 
 Die Methode \emph{assert\_sh} überprüft den Exitstatus eines Befehls und schlägt
-fehl, wenn dieser ungleich null ist, während der \emph{service} den Status eines
-Systemdienst sicherstellt. Es gibt noch weitere Testmethoden, wie das Überprüfen
-von Verzeichnissen, Inhalte von Dateien oder Mountpoints.
+fehl, wenn dieser ungleich Null ist, während die \emph{service}-Methode den
+Status eines Systemdienst sicherstellt. Es gibt noch weitere Testmethoden, wie
+das Überprüfen von Verzeichnissen, Inhalte von Dateien oder Mountpoints.
 
 % vim: set spell spelllang=de_de