98 lines
5.0 KiB
TeX
98 lines
5.0 KiB
TeX
\subsubsection{Einrichtung der Netzwerkdienste}
|
|
\label{ssub:einrichtung-der-netzwerkdienste}
|
|
|
|
Für die Provisionierung der Netzwerkdienste wurde
|
|
\href{http://vagrantup.com}{\emph{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 kann direkt
|
|
eingestellt werden, mit welchen Einstellungen neue virtuelle Maschinen
|
|
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. 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:
|
|
|
|
\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}
|
|
|
|
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 \emph{vagrant-vbguest} (TODO link). Dieses überprüft beim
|
|
Start die Versionen und installiert gegebenfalls eine Andere in der VM.
|
|
|
|
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 network\_interfaces
|
|
(TODO link) 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{chef_minitest_handler})
|
|
\end{description}
|
|
|
|
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
|