Workshop: Docker-Container mit Kubernetes managen

Container-Management

Wer im Virtualisierungsmarkt auf das Container-Schiff aufgesprungen ist, hat bald Bedarf nach performanten Lösungen zum Management seiner Docker-Landschaft. Diverse Hersteller bieten hierfür spezielle Betriebssystem-Images mit entsprechenden Management-Tools an. Red Hat setzt in seinem neuen Container-Betriebssystem Atomic auf Kubernetes vom Branchenriesen Google.
Das Monitoring der IT-Umgebung steht im März auf der Agenda des IT-Administrator. So lesen Sie in der Ausgabe, wie sich Open-Source-Tools wie Logstash, ... (mehr)

Die eigenen Applikationen in Containern zu betreiben, wird immer populärer und bietet im Vergleich zum Betrieb auf herkömmlichen virtuellen Maschinen zahlreiche Vorteile. Die Container basieren dabei zumeist auf der Docker-Engine, die nur einen sehr minimalistischen Unterbau zum Betrieb der Container voraussetzt. Daher stellt der Einsatz herkömmlicher Betriebssysteme zumeist einen zu großen Overhead dar, wenn bereits im Vorfeld klar ist, dass auf den betroffenen Systemen ausschließlich Container zum Einsatz kommen sollen. Zwar lassen sich diese ohne weiteres mit dem Docker-eigenen Management-Tool erzeugen, starten und stoppen, jedoch skaliert dieser Ansatz nicht sehr gut.

Gerade in großen Enterprise-Umgebungen möchte sich der IT-Verantwortliche keine Gedanken mehr darüber machen, auf welchem System ein Container läuft und welche Hardware hierfür zum Einsatz kommt. Stattdessen geht es nur noch darum, eine Applikation mit den benötigten Anforderungen zu definieren und diese dann auf den vorhandenen Ressourcen bereitzustellen. Ob die Applikation dann in einem Container auf Hardware A im Rechenzentrum X oder aber auf Hardware B im Rechenzentrum Y abläuft, spielt keine Rolle mehr. Ausnahmen bestehen natürlich, beispielsweise wenn einzelne Anwendungen in einer bestimmten geografischen Lokation bereitgestellt werden müssen. Aber eine solche Information lässt sich natürlich in den Anforderungen hinterlegen und beim Deployment entsprechend berücksichtigen.

Atomare Host-Images

Einige Linux-Distributionen bieten aus diesem Grund spezielle Betriebssystem-Images an, die auf speziell diesen Einsatzzweck zugeschnitten sind. Neben dem heute aktuellen Init-System systemd und einigen grundlegenden Kernel-Komponenten, wie beispielsweise SELinux und CGroups, enthalten diese nur einen sehr kleinen Software-Stack. Dazu gehört natürlich Docker als Container-Engine sowie oftmals Kubernetes [1] von Google als Management- und Orchestrierungs-Tool für die Container.

Ein solches Betriebssystem-Image lässt sich zumeist in unterschiedlichen Umgebungen einsetzen. So existieren Images für den Einsatz auf klassischen Bare-Metal Systemen, aber natürlich auch für den Betrieb in öffentlichen und privaten Cloud-Umgebungen. Dazu zählen beispielsweise Google Cloud Engine (GCE), Red Hat OpenShift, OpenStack, Amazon Web Services oder andere Virtualisierungsumgebungen. Wir verwenden in diesem Artikel beispielsweise eine einfache KVM-Installation.

In dieser Umgebung kommt ein Image aus dem Project Atomic [2] zum Einsatz. Dieses ist speziell für den Einsatz von Containern auf Basis von Docker und Kubernetes ausgelegt. Project Atomic stellt dabei das Upstream-Projekt für diverse andere Images dieser Art dar. So greifen beispielsweise Red Hat [3], Fedora [4] und auch CentOS [5] auf das Project Atomic zurück, um ihre jeweils eigenen Cloud-Images für den Einsatz von Docker Containern zu erzeugen.

Es ist wichtig zu verstehen, dass diese Atomic-Images einen anderen Aufbau besitzen, als man es von solchen RPM-basierten Distributionen gewohnt ist. So kommt beispielsweise kein Paket-Manager zum Verwalten der Software zum Einsatz. Stattdessen greift das Project Atomic hier auf das Tool rpm-ostree zurück. Hiermit lassen sich atomare Updates des Atomic-Hosts durchführen. Das ist deshalb möglich, da sich die komplette Betriebssystem-Instanz in einem einzelnen Dateisystem-Pfad unterhalb des Ordners »/ostree/deploy« befindet. Beim Systemstart wird die aktuelle Version des Betriebssystems dann unterhalb der Dateisystemwurzel eingehängt, wobei lediglich die Ornder »/etc« und »/var« beschreibbar sind. Alle anderen Ordner unterhalb von »/ostree« sind lediglich lesbar.

Bei einem Update wird nun einfach eine komplett neue Betriebssystem-Instanz von dem Update-Server nach »/ostree/deploy« kopiert und die Änderungen an den Konfigurationsdateien unterhalb von »/etc« auf die neue Betriebssystem-Instanz angewendet. Das Verzeichnis »/var« wird zwischen allen Instanzen geteilt, da sich hier beispielsweise auch das Home-Verzeichnis der Benutzer befindet. Der Ordner »/home« ist lediglich ein symbolischer Link auf »/var/home« . Um die neue Instanz des Betriebssystems zu starten, ist somit ein Neustart des Host-Systems notwendig. Der ganze Vorgang erinnert ein wenig an das Versionskontroll-System Git und in der Tat basiert ostree (die Basis von rpm-ostree) auf diesem Tool.

Wollen Sie zusätzliche Software auf einem Atomic-Host installieren, klappt das nicht auf die gewohnte Weise mit rpm oder yum. Stattdessen wird empfohlen, die Software entweder in einem eigenen Container auf dem Atomic-Host zu betreiben oder aber sie in einen Ordner unterhalb von »/var« zu kopieren. In diesem Fall sollte es sich um statisch übersetzte Programme handeln. Sämtliche Änderungen an den einzelnen Betriebssystem-Instanzen in diesem Ordner nehmen Sie über das Tool rpm-ostree vor und nicht etwa manuell. Mittels »rpm-ostree update« führen Sie ein Update des Systems durch. Hat dieser nicht so funktioniert, wie Sie es sich vorstellen, versetzen Sie das System mittels rpm-ostree rollback wieder in den ursprünglichen Zustand. Anstelle von rpm-ostree können Sie auch einfach das Tool atomic aufrufen. Es verweist über einen Softlink ebenfalls auf rpm-ostree.

Arbeiten mit Docker-Containern

Wenn Sie mit Docker-Containern vertraut sind, wissen Sie, dass sie ebenfalls auf Images basieren. Diese beziehen Sie entweder von einem zentralen oder lokalen Docker-Registry-Server oder erzeugen Sie mit Hilfe eines Dockerfile selber. Über den Aufruf von »docker run« starten Sie dann die gewünschte Applikation innerhalb eines Containers. Das folgende Beispiel zeigt das bekannte "Hello World" innerhalb eines Fedora-Containers:

docker run fedora /bin/echo "hello world"

Ist das Image mit dem Namen "fedora" zu diesem Zeitpunkt noch nicht lokal vorhanden, lädt docker es selbstständig vom voreingestellten Registry-Server herunter und führt dann das Kommando »/bin/echo "hello world"« innerhalb der Fedora-Instanz aus. Im Anschluss wird der Container beendet. Der Aufruf »docker ps -a« zeigt alle gestarteten Container auf dem Host an.

Anstelle des echo-Befehls könnten Sie an dieser Stelle natürlich auch ein Skript aufrufen, das einen vorkonfigurierten Webserver startet. Nutzt dieser eine Datenbank als Backend, erzeugen Sie einen zusätzlichen Container mit eben dieser Datenbank und verlinken die beiden. In kleinen Umgebungen ist dieser Ansatz sicherlich ausreichend, ab einer gewissen Größe sollte die Lösung aber besser skalieren. Beispielsweise sollte es möglich sein, einen Container oder aber auch ein Set von Containern auf entfernten Hosts zu starten. Auch ist es wünschenswert, einen Status für die Applikationen zu definieren. Starten Sie mittels docker einen Container auf einem Host, so ist nicht sichergestellt, dass im Fehlerfall des Hosts der Container auf einem anderen System wieder neu startet.

Listing 1: Meta-Dateien zur Konfiguration



# mkdir /tmp/atomic/
# cd /tmp/atomic/
# cat > meta-data 
instance-id: Atomic0
local-hostname: atomic-00
_eof
# cat > user-data 
#cloud-config
password: atomic
chpasswd: {expire: False}
ssh_pwauth: True
ssh_authorized_keys:- ssh-rsa AAA...SDvz centos@atomic.example.com
_eof
# genisoimage -output cloud-init-config.iso -volid cidata -joliet -rock user-data meta-data

Listing 2: Kubectl zeigt aktiven Pod



kubectl get pods
NAME            IMAGE(S)            HOST                        LABELS                                 STATUS
apache-dev     fedora/apache      atomic-host-001/      name=apache,stage=dev      Running
comments powered by Disqus

Artikel der Woche

Rechneranalyse mit Microsoft-Sysinternals-Tools

Der Rechner verhält sich eigenartig oder Sie haben eine unbekannte Applikation im Task Manager entdeckt und möchten erfahren, worum es sich dabei genau handelt und ob sie möglicherweise gefährlich ist? In so einem Fall helfen die Sysinternals-Tools von Microsoft. Dieser Beitrag stellt die drei Werkzeuge Autoruns, Process Explorer und TCPView vor. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2018