Open Source im professionellen Einsatz
Linux-Magazin 09/2014
© Anek Suwannaphoom, 123RF

© Anek Suwannaphoom, 123RF

Docker-Container am Beispiel von Owncloud

Intelligenter stapeln

, ,

Dieser Workshop zeigt am Beispiel des Cloudstack Owncloud, wie stark die Entwickler das Integrieren etablierter Linux-Technologien wie LXC und Cgroups in Docker 1.0 abstrahiert und vereinfacht haben und wie Admins komplexe Szenarien in Containerumgebungen zähmen.

1063

Wer sich heute mit Virtualisierung auseinandersetzt, kommt an der Containertechnologie nur schwer vorbei. Doch zu glauben, man müsse dazu Linux Containers (LXC) oder Cgroups studieren, ist falsch: Mit Docker, vor allem in der neuen Version 1.0, liegt ein mächtiges, Enterprise-fähiges Tool vor, das es Admins einfach macht, neue und leichtgewichtige Instanzen ihrer Applikationen auszurollen (siehe auch den Artikel in der Titelstrecke).

Der folgende Workshop zeigt am Beispiel von Owncloud, wie das auch mit komplexen Anwendungen, die einen Webserver und eine Datenbank sowie persistenten Storage verlangen, funktioniert.

Am Anfang war das Image

Es ist ganz egal, ob als Containermanager Docker [1] zum Einsatz kommt oder nicht: Die Basis für jedweden Container bildet immer ein Image, das aus dem Dateisystem einer Distribution besteht. Entweder holt sich der Nutzer fertige Images oder baut sie selbst. Der Eigenbau besitzt Vorteile und es lässt sich auf bereits erstellte oder von Policies vorgeschriebene Images aufbauen.

Im Falle von Docker beschreibt eine Anweisungsdatei, das so genannte Dockerfile, die Arbeitsweise für das Erstellen. Schon vorab ist es wichtig, einige Namenskonvention zu kennen: Der Dateiname jedes Dockerfile muss mit einem Großbuchstaben beginnen. So eine Datei besteht aus mehreren aufeinanderfolgenden Anweisungen, jede Zeile enthält ein Kommando, gefolgt von einem Parameter. Kommandos, zum Beispiel »RUN« , hat der Admin dabei stets und komplett in Großbuchstaben zu schreiben. Beim Parameter ist er freier, dieser kann auch aus mehreren Wörtern bestehen, so wie das typischerweise bei Linux-Kommandozeilen-Befehlen mit eigenen Parametern der Fall ist, etwa »chmod +x ./ Mein_Skript .sh« .

Listing 1 zeigt das Dockerfile für das Image einer MySQL-Datenbank. Die Auswahl des Basis-Image erfolgt über die »FROM« Zeile. Der Name »centos:latest« bezieht sich hier auf das Image »centos« mit dem Tag »latest« als weitere, untergeordnete Spezifizierung. »latest« ist so immer die neueste Revision des Image. Auch Releases lassen sich so markieren, zum Beispiel »ubuntu:12.04« .

Listing 1

Dockerfile für MySQL

01 FROM centos:latest
02 MAINTAINER Tux <info@b1-systems.de>
03 RUN yum install -y mysql mysql-server
04 ADD start.sh /start
05 RUN chmod +x /start
06 EXPOSE 3306
07 CMD ["/start"]

Auf der Suche nach dem Image verbindet sich Docker mit der zentralen Registry beziehungsweise dem Hub (ehemals Index genannt). Über diese öffentlich zugängliche Plattform tauschen Benutzer Images aus, sodass der Admin meist nicht alles komplett neu selbst bauen muss.

Für viele Anwendungsfälle stehen fertige Images bereit, die sich direkt benutzen lassen, bequem auffindbar über die Suchfunktion der Webseite [2] oder den Befehl »docker search Suchmuster « . Ist das angegebene Image nicht lokal verfügbar, wird es Docker automatisch herunterladen. Alternativ ist es möglich, Images mit dem Befehl »docker pull Imagename « zu beziehen.

Beginnt eine Zeile mit »RUN« , wird Docker den nachfolgenden Befehl beim Anlegen des Image ausführen, nicht aber beim Ausführen des Containers. Der angegebene Befehl darf keine Interaktion mit dem Administrator erfordern. Kommandos, die interaktive Eingaben verlangen, muss er entsprechend kapseln – etwa mit »expect« – oder mit einem passenden Parameter konfigurieren, damit Docker sie ohne weitere Eingaben ausführen kann (Beispiel: »yum install -y« ). »RUN« -Befehle können in Dockerfiles beliebig oft auftreten.

Die Zeilen im Dockerfile werden bei der Erstellung eines Image mit »docker build« sequenziell abgearbeitet. Jeder Befehl im Dockerfile erzeugt automatisch ein neues Image, das Docker nur als Differenz (Diff) zu dem vorangegangen ablegt. Erneutes Aufrufen von »docker build« führt nicht zum erneuten Abarbeiten der Befehle, vielmehr liest Docker die Ergebnisse performant aus dem Cache.

Ändert sich aber ein im Dockerfile definierter Zwischenschritt, muss Docker auch alle darauf folgenden Schritte erneut ausführen. Den Zusammenhang zwischen verschiedenen Images zeigt eine von der Kommandozeile »docker images -viz | dot -T png -o docker-images.png« erzeugte Grafik ( Abbildung 1 ).

Abbildung 1: Elternschaft und Zusammenhänge zwischen verschiedenen Docker-Images zeigt die grafische Ausgabe des Tools docker images.

Der Befehl »ADD« fügt Dateien und Verzeichnisse in das Image ein. Im MySQL-Dockerfile erledigt dies das Skript »start.sh« , das im Image als Datei »/start« gespeichert ist. Wer viele Dateien zu einem Image hinzufügen möchte, kann sie auch in einem Tar-Archiv bündeln und direkt als Argument an »ADD« übergeben. Auch URLs wie »http:// Webserver .fqdn/myfile.sh« anzugeben ist hier möglich.

ENTRYPOINT vs. CMD

Das Schlüsselwort »CMD« beziehungsweise »ENTRYPOINT« legt fest, welches Kommando standardmäßig bei der Ausführung eines Containers laufen soll. Das ist in den meisten Fällen entweder das Binary eines Dienstes, ein Startskript oder ein Init-Ersatz wie »supervisor« oder »runit« .

Dabei ist ein feiner Unterschied zu beachten: »CMD /start« sorgt dafür, dass »docker« den Befehl mittels »/bin/sh -c« oder genauer mittels »/bin/sh -c '/start'« ausführt. Will der Admin das Kommando direkt aufrufen, muss er es wie eine Liste übergeben, zum Beispiel:

CMD [ 'Programm', '--Argu-ment1', '--Argument2' ]

Der wesentliche Unterschied zwischen »CMD« und »ENTRYPOINT« kommt erst beim Ausführen zum Tragen, Listing 2 zeigt das an einem Beispiel in der interaktiven Docker-Shell. Beide Images führen das Programm »/bin/echo« aus. Bei Angabe von »CMD« lässt sich das im Dockerfile angegebene Kommando überschreiben, bei »ENTRYPOINT« dagegen nicht (siehe Parameter »--entrypoint« bei »docker run« und das Beispiel im Listing 2 ).

Listing 2

Unterschied zwischen ENTRYPOINT und CMD

01 docker run cmd:latest hostname
02 3246bb700a21
03 docker run entrypoint:latest hostname
04 hostname
05 docker run --entrypoint hostname entrypoint:latest
06 57334f13ef76

Der mögliche Befehlssatz für Dockerfiles ist sehr umfangreich, die komplette Dokumentation findet sich unter [2] . Die Website von Michael Crosby [3] bietet weitere nützliche Informationen rund um die vielen Optionen im Dockerfile. Listing 3 zeigt ein komplettes Dockerfile für das Owncloud-Szenario [4] .

Listing 3

Dockerfile für Owncloud

01 FROM hachque/opensuse
02 MAINTAINER Tux <info@b1-systems.de>
03 RUN zypper mr -ae
04 RUN zypper --non-interactive ar
05 'http://download.opensuse.org/repositories/isv:/Owncloud:/community:/6.0/openSuse_13.1/' owncloud
06 RUN zypper --non-interactive --gpg-auto-import-keys ref -f
07 RUN zypper --non-interactive update --auto-agree-with-licenses
08 RUN zypper --non-interactive install --auto-agree-with-licenses apache2 owncloud php5-mysql php5-fileinfo glibc-locale
09 ADD sysconfig /etc/sysconfig/
10 CMD /usr/sbin/start_apache2 -f /etc/apache2/httpd.conf -DFOREGROUND

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Docker

    Docker ist das englische Wort für Hafenarbeiter. Das passt, denn die gleichnamige Software füllt und verschiebt Container – die unter anderem Webanwendungen enthalten.

  • Docker 1.5 unterstützt IPv6 und separate Dockerfiles

    Von Docker gibt es seit gestern eine neue Version. Container kommunizieren nun auch über IPv6, Admins können zur Buildzeit verschiedene Dockerfiles verwenden.

  • Perl-Snapshot

    Wer Programme in der weiten Welt zu verteilen gedenkt, sollte sie vorab fit für fremde Kulturen machen. Um seine selbst verfassten Perl-Module auf mehreren Linux-Distributionen in einem Rutsch zu testen, schnappt sich Perlmeister Schilli die Linux-Containers-Technik und das ressourcenschonende Docker-Projekt.

  • Docker 1.9 unterstützt virtuelle Netzwerke und verbessert Volume-Management

    Docker 1.9 sei eine umfangreiche Release geben die Macher der Containerlösung zu Protokoll. Docker Swarm und Multihost-Networking seien einsatzbereit, zudem wartet ein überarbeitetes Volume-Management-System, um Daten dauerhaft zu speichern.

  • ASP.NET5-Applikationen laufen nun auch unter Linux

    Dank Microsofts ASP.NET 5 Preview Docker Image ist es nun möglich, Applikationen, die in ASP.NET5 geschrieben sind, auch unter Linux laufen zu lassen

comments powered by Disqus