Container-Images mit buildah

Als Container dank Docker vor einigen Jahren den großen Durchbruch geschafft haben, war die Welt noch einfach. Die Docker-Engine kümmerte sich um alle Aufgaben rund um das Container-Management. Dazu zählte auch das Erzeugen von Container-Images. Mit Hilfe von Dockerfiles ließen sich leicht eigene Images erzeugen. Seitdem hat sich jedoch viel getan und unterschiedliche Container-Runtimes und Container-Image-Formate haben das Licht der Welt erblickt. Auch die Docker-Engine selbst besteht mittlerweile aus unterschiedlichen Komponenten, auch wenn sich an dem eigentlichen Prozess zum Erzeugen eines neuen Docker-Images nicht viel verändert hat. So ist beispielsweise immer noch ein aktiver Docker-Daemon notwendig, damit sich aus einem Dockerfile ein neues Container-Image erzeugen lässt.

Alternativen zu Docker

In manchen Umgebungen kommt mittlerweile aber eine alternative Container-Runtime zum Einsatz, sodass dort gar kein Docker-Daemon mehr läuft. Auch Docker selbst setzt seit Version 1.11 und der damit einhergehenden Modularisierung der Engine auf den Container-Manager containerd [1] und die Container-Runtime runC – benötigt allerdings immer noch den Docker-Daemon als Master-Daemon für die Docker-Engine.

Zum eigentlichen Betrieb von Containern reicht allerdings eine Runtime (beispielsweise runC) und ein Tool, das sich um die Verwaltung der Container-Images kümmert (beispielsweise skope oder atomic). Auf diese Komponenten greift auch das CRI-O-Projekt zurück, um dem Container-Orchestrierungsframework Kubernetes eine OCI-konforme Schnittstelle zum Verwalten von Containern zur Verfügung zu stellen. Die Open-Container-Initiative (OCI) hat hierfür zwei Spezifikationen herausgebracht. Sie beschreiben im Detail, wie eine Container-Runtime [2] und das Image-Format [3] auszusehen haben, damit sie als OCI-konform gelten. Die Image-Spezifikation umfasst allerdings lediglich das Format und gibt keine näheren Auskünfte darüber, wie der Prozess aussehen soll, um ein entsprechendes Image in diesem Format zu erzeugen.

Zwar stellt die OCI unter [4] eine Sammlung von Tools zur Verfügung, mit denen sich OCI-konforme Images erzeugen lassen, allerdings sind diese Tools sehr low-level und eher nicht für den Endanwender geeignet. Stattdessen wollen wir an dieser Stelle das Tool buildah vorstellen, das unabhängig von der Docker-Engine OCI-konforme Container-Images erzeugen kann. Die Software steht unter [5] im Source-Code zur Verfügung und unter [6] befinden sich Pakete für RPM-basierte Distributionen [6]. Für Fedora und Cent-OS ist das Tool auch über die regulären Software-Repositories der beiden Distributionen erhältlich.

Buildah greift zum Management der Container-Images auf die beiden Bibliotheken containers/image [7] und containers/storage [8] zurück. Diese kommen ebenfalls im Tool skopeo zum Einsatz. Hiermit ist auch eine Interaktion mit unterschiedlichen Image-Repositories möglich. Als Container-Runtime setzt buildah auf runC [10] und ist somit komplett unabhängig von der Docker-Engine.

Basis-Image als Grundlage

Nachdem das Tool installiert wurde, lässt sich ein neues Image entweder auf Basis eines anderen Images erzeugen oder es wird zuerst ein leeres Image erzeugt, das im Anschluß bearbeitet wird. Das folgende Beispiel beschreibt zuerst die erste Variante. Hierbei soll ein neues Image auf Basis eines Fedora-Images entstehen. Im ersten Schritt müssen wir hierfür zunächst das passende Basis-Image aus dem Fedora-Image-Repository laden (Listing 1).

# fedora=$(buildah from registry.fedoraproject.org/fedora)
Getting image source signatures
Copying blob sha256:04331e646521ddb577d113f3c103aef620cc4451641452c347864298669f8572
    86.07 MiB / 86.07 MiB [===================================================] 17s
Copying config sha256:6f45e9bcf5cce33bab555b2b87eb8409ca662ed57358b75ad082aebb9f222c7c
    1.27 KiB / 1.27 KiB [======================================================] 0s
Writing manifest to image destination
# echo $fedora
fedora-working-container
# buildah containers
CONTAINER ID      BUILDER      IMAGE ID           IMAGE NAME                                           CONTAINER NAME
5a30546bba73               *              3151bb6e8739     registry.fedoraproject.org/fedora:latest    fedora-working-container
# buildah images
IMAGE ID              IMAGE NAME                                            CREATED                    AT SIZE
3151bb6e8739        registry.fedoraproject.org/fedora:latest     Nov 10, 2017 12:15     240.1 MB
# buildah run $fedora -- cat /etc/redhat-release
Fedora release 27 (Twenty Seven)

Nun lassen sich die gewünschten Modifikationen an dem Container vornehmen. Beispielsweise könnte ein neues Paket installiert werden:

# buildah run $fedora -- dnf install -y httpd

Oder aber es werden neue Dateien in den Container kopiert. Hierfür bietet buildah die nützliche "mount"-Option an, mit der sich das Image (das aus einzelnen Layern besteht) im Dateisystem des Hosts einbinden lässt:

# fedoramount=$(buildah mount $fedora)

# echo $fedoramount

/var/lib/containers/storage/overlay/1268145b023cc2a2f69dc702c3930141666597957b5b39704986708b946c930c/merged

# echo "hello world..." > $fedoramount/var/www/html/hello.txt

Wenn sämtliche Änderungen erledigt sind, können wir ein neues Image erzeugen und im Anschluss den alten Container unmounten:

# buildah commit $fedora fedora-new-image

# buildah umount $fedora

Und schließlich lässt sich nun ein neuer Container auf Basis des soeben erzeugten Images starten, in dem die vorgenommenen Modifikationen nun sichtbar sind:

# fedoraweb=$(buildah from fedora-new-image)

# buildah run $fedoraweb -- rpm -q --last httpd

httpd-2.4.29-1.fc27.x86_64 Thu Jan 4 11:58:35 2018

# buildah run $fedoraweb -- cat /var/www/html/index.html

hello world...