\subsubsection{Einrichtung der Netzwerkdienste} \label{ssub:einrichtung-der-netzwerkdienste} Für die Provisionierung der Netzwerkdienste wurde \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 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{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 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. 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: \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: \shellcmd{gem install bundler} \shellcmd{bundle install} Zur Verwaltung der externen und internen Cookbooks wurde die Abhängigkeitsverwaltung \href{http://berkshelf.com}{Berkshelf} verwendet. Bei diesem werden die zu ladenden Cookbooks und die gewünschte Version in einer Datei namens Berkssfile angegeben (vergleichbar mit \href{http://bundler.io/}{Gemfile} 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: \shellcmd{berks install} im Projektverzeichnis ausgeführt werden. 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. 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 Virtualboxversion des Host mit dem der VM übereinstimmen. Abhilfe schafft das Vagrantplugin \href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}. Dieses überprüft beim Start die Versionen und installiert gegeben falls eine Andere in der VM. Beide Plugins werden diesen Befehlen installiert: \shellcmd{vagrant plugin install vagrant-vbguest} \shellcmd{vagrant plugin install vagrant-berkshelf} Gestartet wird die VM mit dem Befehl: \shellcmd{vagrant up} Beim 1. Start wird die VM mit Chef provisioniert. Spätere kann Chef erneut mit folgenden Befehl gestartet werden: \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. 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] Als DNS-Server wurde bind gewählt. Dieses Cookbook diesen Dienst ein und fügt die in den Attributen konfigurierten DNS-Einträge hinzu 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 festgelegt werden. \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. \item[main] Dieses Cookbook fast 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 sind und (bei Chef-server) über alle Umgebungen gleich 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[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}) \end{description} % vim: set spell spelllang=de_de