From f97df85084dda1a0c60b4d1492e0fc2e3947f431 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= Date: Wed, 19 Mar 2014 08:59:20 +0100 Subject: [PATCH] chef: verschiedenes --- bericht/chef/chef-services.tex | 29 ++++++++++++++++++----------- bericht/chef/chef-task.tex | 2 +- bericht/chef/chef-tests.tex | 31 ++++++++++++++++++------------- 3 files changed, 37 insertions(+), 25 deletions(-) diff --git a/bericht/chef/chef-services.tex b/bericht/chef/chef-services.tex index d6329ac..4b3e818 100644 --- a/bericht/chef/chef-services.tex +++ b/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 diff --git a/bericht/chef/chef-task.tex b/bericht/chef/chef-task.tex index b96dfa2..8932106 100644 --- a/bericht/chef/chef-task.tex +++ b/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 diff --git a/bericht/chef/chef-tests.tex b/bericht/chef/chef-tests.tex index 737642f..0dc679c 100644 --- a/bericht/chef/chef-tests.tex +++ b/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