oliverlorenz.com

Wie oft habe ich schon vor tollen Docker Containern gesessen und mich dann doch dagegen entschieden diese zu benutzen, weil nicht zu erkennen war, wie das ganze Setup funktioniert, oder welche Dienste ggf. noch ohne mein Wissen gestartet werden.

Seit einiger Zeit gibt es nun auf DockerHub die Automated Builds. Diese schaffen einen deutlichen Transparenzsprung, denn die Quelle des Containers ist klar ersichtlich und die bereitgestellten Container basieren auch zwangsläufig auf dieser Quelle. Bei Containern, die diesen Flag nicht haben, würde ich immer vorsichtig sein!

So, jetzt aber Butter bei die Fische!

Schritt 1: Ein öffentliches Repository

Von Haus aus bringt DockerHub eine Unterstützung für GitHub und Bitbucket mit. Wir arbeiten in diesem Tutorial mit einem meiner Repositories, welches auf GitHub gehostet ist:

https://github.com/oliverlorenz/docker-node-red-extra

Warum noch ein NodeRed-Image? Nun ja: Erstens handelt es sich nur um ein Beispiel. Außerdem ist dieser Use Case für mich selbst von Relevanz, da mir in den üblichen Containern immer die entsprechenden Tools fehlen, die ich brauche.

2. Einen Automated build anlegen

Loggt euch bei DockerHub ein und wählt im Menü oben rechts Create > Create Automated Build. Das ist wichtig, denn ihr könnt die Art des Repositories nicht mehr ändern

Folgt dann einfach den Anweisungen der folgenden Masken. Solange ihr die Visibility auf "public" lasst ist alles gut :)

3. Zusätzliche Einstellungen

Build-Settings

Als erstes sehen wir uns mal den Menüpunkt "Build-Settings" an.

Die Standard-Einstellungen sind garnicht schlecht. Immer wenn es eine Änderungen auf dem master-Branch innerhalb eures Code-Repositories gibt, wird DockerHub einen neuen Build für euch starten. Ihr könnt natürlich jeden beliebigen Branch bzw. Tag in die Übersicht eintragen.

Ich empfehle euch, an dieser Stelle mit Tags und dem master-Branch als "latest" zu arbeiten. Das hat den Vorteil, dass sich eure Nutzer explizit auf eine Version pinnen können und damit die Kontrolle behalten wann sie updaten wollen. Besonders bei Projekten die in Production-Umgebungen laufen, solltet ihr euren Nutzern zuliebe nicht darauf verzichten.

Falls es nötig werden sollte, könnt ihr mit dem rechten Button "Trigger" zusätzlich einen manuellen Build des entsprechenden Branches/Tags ausführen.

Repository Links

Repository Links sind unglaublich praktisch! Eigentlich setzt man immer auf ein Base-Image auf. Oft macht es Sinn die Änderungen dieses Base-Images gleich in das eigene Projekt zu übertragen. Dabei hilft uns DockerHub hervorragend, denn durch das verlinken auf das Base-Image wird automatisch ein Build unseres Projektes ausgeführt, sobald es Änderungen im Base-Image gab. In unserem Fall habe ich auf "cpswan/node-red" verlinkt, welches meine Basis darstellt.

4. Build Details

Zusätz zu den Build-Settings gibt es noch den Menüpunkt Build-Details. Diese lassen euch einen tieferen Einblick in eure Build-Logs zu. Grundsätzlich kann man aber sagen, dass es vom Informationsgehalt 1:1 dem entsprechen was ihr bei eurem lokalen Build sehen würdet.

Fazit

Docker Builds sind eine klasse Sache! Endlich kann man erkennen welchen Containern man vertrauen kann und bei welchen man vielleicht etwas vorsichtig sein sollte. Die lose Kopplung zwischen GitHub/Bitbucket und DockerHub bringt neben Transparenz auch noch einiges an Komfort.

Leider ist es derzeit nicht möglich Container auf ARM-Basis erstellen zu lassen. Bei meinen zahlreichen Diensten die auf meinen Raspberry Pis laufen, würde ich mir wünschen diese nicht immer direkt auf dem Raspberry selbst bauen lassen zu müsse. Aber was nicht ist kann ja noch werden!