ltcp/bericht/chef/chef-services.tex

91 lines
4.4 KiB
TeX
Raw Normal View History

2014-03-12 15:49:23 +00:00
\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