ltcp/bericht/chef/chef-services.tex

\subsubsection{Einrichtung der Netzwerkdienste}
\label{ssub:einrichtung-der-netzwerkdienste}

Für die Provisionierung der Netzwerkdienste wurde
\href{http://vagrantup.com}{Vagrant} verwendet. Dies ist 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} hinterlegt, welche Vagrant beim Start einliest.
Vagrant kann Chef beim Erstellen von virtuellen Maschinen integrieren.  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{Chef}, der gleichnamigen
Firma, bereitgestellt. Für die Kommunikation mit Vagrant wurde das
Netzwerkinterface \emph{eth0} konfiguriert. Ein weiteres Netzwerkinterface
(\emph{eth1}) wird für das interne virtuelle Netzwerk zwischen den VMs zum
Betreiben der Netzwerkdienste benötigt.  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 die Nutzung allerdings auf
den Hypervisor 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 zu
aktualisieren.

Desweiteren wird Ruby auf dem Host benötigt, um beispielsweise die Tests
ausführen zu können. Auf Unix-Ähnlichen Systemen kann dies mit dem Befehl:

\shellcmd{curl -sSL https://get.rvm.io | bash -s stable}

installiert werden. Auf dem Betriebssystem Windows kann auf den
\href{http://rubyinstaller.org/}{RubyInstaller} zurückgegriffen werden. Um die
benötigten Ruby-Bibliotheken zu installieren, müssen folgende 2 Befehle im
Projektverzeichnis ausgeführt 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/}{Gemfiles} 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 verwalteten 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 in
meisten vielen Images vorhanden, die es für Vagrant gibt. Allerdings muss die
Virtualboxversion des Host mit der Version in der VM übereinstimmen. Abhilfe
schafft das Vagrantplugin
\href{https://github.com/dotless-de/vagrant-vbguest}{vagrant-vbguest}. Beim
Start installiert das Plugin die die gleiche Version des Modules in der VM.
Wenn Virtualbox mit Linux als Hostsystem ausgeführt wird, sollte das
Kernelmodule \emph{vboxdrv} geladen sein. Manche Linux-Distributionen
installieren dieses Module bereits während der Installation von Virtualbox.
Auf MacOS X und Windows sind keine weiteren Schritte notwendig.

Beide Plugins werden den Befehlen:

\shellcmd{vagrant plugin install vagrant-vbguest}

\shellcmd{vagrant plugin install vagrant-berkshelf}

installiert.

Gestartet wird die VM mit dem Befehl:

\shellcmd{vagrant up}

Während des ersten Starts wird die VM mit Chef provisioniert. Später kann Chef
erneut mit Befehl:

\shellcmd{vagrant provision}

gestartet werden:

Als Netzwerkdienste wurden die Protokolle DHCP, DNS und NTP gewählt. Die VMs
wurden in die zwei Gruppen \emph{Headnodes}und \emph{Computenodes} geteilt. Die
Headnode bietet die genannten Dienste an. Die Computenodes fordern auf dem
internen Netzwerk per DHCP eine IP-Adresse an und nutzen den DNS- und NTP-Dienst
der jeweiligen Headnode.

Die Attributes der Roles und der Node wurden in JSON-Dateien in den
Verzeichnissen \emph{roles/} und \emph{nodes/} abgelegt. Es gibt je eine
Role-Datei für Computenodes und Headnodes. In der aktuellen Konfiguration
erzeugt Vagrant eine Headnode mit der FQDN \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. Das Cookbook richtet diesen Dienst ein
    und fügt, die in den Attributes konfigurierten, DNS-Einträge zu den
    entsprechenden Zonen hinzu.
  \item[dhcp]
    Dieses Cookbook richtet den ISC-DHCP-Server (TODO Link) 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 Wrappercookbook um das
    \href{https://github.com/redguide/network_interfaces}{network\_interfaces}
    Cookbook. Wrappercookbooks 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 IP-Adresse gesetzt, der DNS-Server auf
    localhost festgelegt und IP-Forwarding 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 fasst 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 und (bei Chef-Server) über alle Umgebungen identisch
    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 Paketquellen auf den aktuellen Stand und
    aktualisiert den Paketcache.
  \item[network\_interfaces] verwaltet Debians Netzkonfiguration
    /etc/network/interfaces.
  \item[minitest-handler] Sammelt alle Tests in den Cookbooks und führt diese
    nach der Provisionierung aus (siehe~\ref{minitest_handler}).
\end{description}

% vim: set spell spelllang=de_de