Tags für Docker Images ohne Registry

Andreas Krüger

Ein Docker Image kann man gleich beim Bauen einen „Tag“ mitgeben, also eine Bezeichnung.

docker build -t foo:latest .

Dieser Tag vereinfacht spätere Zugriffe auf das eben erstellte Docker Image.

Der Tag hat darüber hinaus eine zweite Funktion: Er kann eine Docker Registry und ggf. einen Pfad in dieser Registry als kanonischen Ablageort für push und pull definieren:

docker build -t registry.example.org/path/foo:latest .

Nun kann es Gründe geben, ein Docker Image eben gerade nicht in einer Registry ablegen zu wollen. Vielleicht wird das Docker Image nur einmalig gebaut, für den sofortigen Einsatz. Vielleicht enthält das Docker Image schützenswerte Geheimnisse (die sauber zu extrahieren sich für den konkreten Anwendungsfall nicht lohnt) und soll deshalb nicht in Verkehr geraten.

Man würde in solchen Fällen gerne die Registry-Information einfach weglassen. Also zurück zum ursprünglichen

docker build -t foo:latest .

Das wäre logisch. Registry-Information nicht mitzugeben sollte eigentlich bedeuten, dass es keine Registry gibt. Leider bedeutet es das nicht, sondern durch die Docker-Software ist fest vorgegeben, dass foo:latest eine Abkürzung ist für docker.io/library/foo:latest. (Ein Schelm, wer Böses dabei denkt!)

Die Konsequenz: Wer Tags ohne Registry-Information nutzt, riskiert Konflikte, falls es docker.io/library/foo tatsächlich gibt. Diese Konflikte werden praktisch nicht häufig auftreten, aber irgendwie unschön ist die ganze Geschichte doch.

Glücklicherweise gibt es einen einfachen Workaround, wie man klar und deutlich kommunizieren kann, dass ein Tag keine Registry-Informationen enthalten soll. Dazu nutzt man die Domain .invalid, die seit RFC2606 für solche Zwecke vorgesehen ist. Im einfachsten Fall also:

docker build -t registry.invalid/foo:latest .

• Wer als Mensch den Tag sieht, erkennt problemlos, dass hier „kein Respository“ gemeint ist. Das gilt auch für Personen, denen die Bezeichnung „foo“ weiter nichts sagt.

• Jeder push oder pull-Versuch wird sauber fehlschlagen, unabhängig davon, ob es einen gleichnamigen Tag im docker.io-Repository gibt.

• Paranoide Gemüter werden es vorziehen, lediglich die wenig aussagekräftige DNS-Abfrage registry.invalid nach außen dringen zu lassen, statt dem Server von docker.io Hinweise zu geben, dass im eigenen Netzwerk an einem Docker-Projekt „foo“ gearbeitet wird.