125 lines
5.4 KiB
TeX
125 lines
5.4 KiB
TeX
\subsubsection{Verifikation}
|
|
\label{ssub:verifikation}
|
|
|
|
Wie auch Software müssen auch Provisionierungsskripte getestet werden.
|
|
Dies gestaltet sich oft als schwierig, weil nicht immer eine 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 jslint oder perlcritics. Dabei wird der
|
|
Rubycode gegen Regelsatz getestet, um so schlechten Stil zu erkennen oder
|
|
um Codeingstandards innerhalb eines Projekts einzuhalten. Diesen Regelsatz kann
|
|
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
|
|
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
|
|
wirklich Code auf dem System ausführt, sind weitere Integrationstest
|
|
unerlässlich.
|
|
|
|
Der folgende Test wurde aus dem NTP-Cookbook
|
|
(~\ref{ssub:einrichtung-der-netzwerkdienste}) entnommen.
|
|
|
|
\begin{lstlisting}
|
|
require_relative '../spec_helper'
|
|
|
|
describe 'ntp::default' do
|
|
let(:chef_run) do
|
|
ChefSpec::Runner.new do |node|
|
|
node.set["ntp"]["subnets"] = ["::1", "127.0.0.1", "172.28.128.0 mask 255.255.255.0 nomodify notrap nopeer"]
|
|
end.converge(described_recipe)
|
|
end
|
|
|
|
it "should setup ntp" do
|
|
chef_run.should install_package("ntp")
|
|
chef_run.should render_file("/etc/ntp.conf").with_content("172.28.128.0")
|
|
end
|
|
end
|
|
\end{lstlisting}
|
|
|
|
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.
|
|
|
|
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, gibt es
|
|
eine Rakefile (das in Ruby geschriebene Äquivalent zu GNU Make). Mithilfe des
|
|
Befehls: TODO
|
|
|
|
\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:
|
|
|
|
\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:
|
|
|
|
\begin{lstlisting}
|
|
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 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
|
|
it "starts the named daemon" do
|
|
service("bind9").must_be_running
|
|
end
|
|
it "should resolve dns" do
|
|
assert_sh("dig localhost @localhost")
|
|
end
|
|
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 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. 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.
|
|
|
|
% vim: set spell spelllang=de_de
|