91 lines
4.4 KiB
TeX
91 lines
4.4 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.
|
||
|
|
||
|
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.
|
||
|
|
||
|
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
|
||
|
\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
|
||
|
|
||
|
% vim: set spell spelllang=de_de
|