Ein Docker Image kann man gleich beim Bauen einen “Tag” mitgeben, also eine Bezeichnung.
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:
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
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:
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
oderpull
-Versuch wird sauber fehlschlagen, unabhängig davon, ob es einen gleichnamigen Tag imdocker.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 vondocker.io
Hinweise zu geben, dass im eigenen Netzwerk an einem Docker-Projekt “foo” gearbeitet wird.