Docker Registry
Last updated
Was this helpful?
Last updated
Was this helpful?
Die wohl bekanntest Docker-Reistry ist . Allerdings gibt es viele andere ... privat wie public. Die Cloud-Anbieter AWS (ECR), Google (GCR) und Azure (ACR) bieten alle ihre eigene Docker-Registry an.
Der Zugriff auf die Docker Registries ist häufig durch eine beschränkt, d. h. man kann nur x mal in y Minuten Images downloaden. Hier erfolgt eine Abstufung nach
nicht authentifzierte User
authentifizierte User (login erforderlich)
bezahlter Plan
In vielen Use-Cases ist das weniger dramatisch, da ein einmal runtergeladenes Docker Image in der lokalen Docker Registry gecacht wird.
In CI/CD Szenarien wird das allerdings schnell zum Problem, weil man hier i. a. Jobs auf ephemeral Workers laufen lässt, die keine Persistenz haben. Es erfolgt also kein dauerhaftes Caching. Hier kann man schnell an Grenzen stoĂen.
AWS repliziert (vielleicht ist es technisch auch ein On-Demand-Pull-Thorugh) Public-Docker-Images von hub.docker.com (getagged mit PUBLIC DOCKER IMAGE
) in seine eigene Registry und bietet seinen AWS-Kunden deutlich hÜhere Quotas (teilweise unbeschränkt) an. AWS selbst hat mit DockerHub entsprechende Freikontingente.
AWS ECR enthält dann allerdings nur die PUBLIC DOCKER IMAGES ...
Bei einem
Man kann die Default-Domain allerdings auch im Docker Daemon konfigurieren:
Als anonymer User hat man häufig weniger Downloads zur Verfßgung - Docker Images hochladen kann man i. a. nicht. Aus diesem Grund muss man sich i. a. authentifizieren.
Ganz naiv geht das so:
Allerdings landet das Passwort dann in der Shell-History (kann man vermeiden indem man nur docker login
verwendet und den Rest interaktiv eingibt) UND in ~/.docker/config.json
. Keine gute Idee.
Das Secret in
~/.docker/config.json
(z. B."auth": "YWJjOnh5eg=="
) ist nur Base64 encoded und kann leicht mitecho YWJjOnh5eg== | base64 -d -
decodiert werden. Heraus kommt dannabc:xyz
, d. h. die Userid istabc
und das Passwortxyz
.
eine Anwendung (sog. Docker-Credential-Helper), die auf dem Rechner installiert ist (im PATH
)
eine Hook-Konfiguration, um den Docker-Authentifizierungsprozess anzupassen (konfiguriert in ~/.docker/config.json#credsStore
)
Schritte
in ~/.docker/config.json
(oder auch fĂźr alle User in /etc/docker/daemon.json
): "credsStore": "pass"
hinzufĂźgen
restart des Docker Daemons
AnschlieĂend kann man den Login interaktiv per
durchfĂźhren und das Password landet verschlĂźsselt im ~/.password-store
.
Normalerweise wĂźrde man ein explizites docker login
per (die Authentifizierung erfolgt entweder Ăźber Environment Variablen oder IAM Roles bereitgestellt)
ausfĂźhren, um anschlieĂend per docker pull 1234567890.dkr.ecr.eu-central-1.amazonaws.com/myimage
ein Docker Image zu ziehen. In manchen Use-Cases ist das "programmatisch" aber gar nicht mĂśglich.
Ăber einen Credential-Helper-Ansatz kann man auch das explitzite Login verzichten, weil das komplett im Docker-Workflow versteckt wird. Die Authentifizierungsmethoden bleiben die gleichen wie bei einem docker login
(~/.aws/credentials
, AWS_ACCESS_KEY_ID
/AWS_SECRET_ACCESS_KEY
, IAM Roles). Auf diese Weise kann man beispielsweise einer EC2 Instanz (z. B. im Nomad Worker) die Authentifzierung konfigurieren ... ausgefĂźhrt wird sie dann im Docker-Lifecycle.
Variante 1: in ~/.docker/config.json
diese Konfiguration hinzufĂźgen
Der credsStore=ecr-login
kann ausschlieĂlich bei der AWS-ECR-Docker-Registry verwendet werden. Zieht man bei dieser Konfiguration eine Docker-Image von DockerHub (z. B. docker pull hello-world
), dann bekommt man folgende Warning in ~/.ecr/log/ecr-login.log
:
Dennoch wird das Image erfolgreich runtergeladen.
Variante 2: in ~/.docker/config.json
diese Konfiguration hinzufĂźgen
diese Variante hat den Vorteil, dass man die Authentifizierungsmethode Registry-Spezifisch konfigurieren kann
Das sollte ohne Restart des Docker Daemons funktionieren. Alternativ kann man die Ănderung auch in
/etc/docker/daemon.json
machen ... dann benĂśtigt man aber einen Restart des Docker Daemons.
AnschlieĂend kann man ohne explizites docker login
ein docker pull ##########.dkr.ecr.########.amazonaws.com/myimage
ausfĂźhren.
Das funktioniert dann auch im angesprochenen Nomad-Job, der auf dem Nomad-Worker gestartet wird.
Sollte es nicht funktionieren, dann helfen die Logfiles unter ~/.ecr/log/ecr-login.log
und /var/log/syslog
sicherlich weiter.
wird das Image per default von geladen. Will man ein Image von einer anderen Regsitry laden, so muss man die Domain voranstellen
Aus diesem Grund sollte man besser einen verwenden, der das Passwort verschlĂźsselt speichern kann. Ich verwende gerne pass
als sicheren Secret-Store () ... man kann aber auch andere verwenden. Nun benĂśtigt man allerdings folgendes
sehr schĂśn beschrieben.
Installation des docker-credential-pass
in den PATH
Installation und Initialisierung von pass
()
Beispiel: Verwendet man in Nomad kann man den , dann zieht der Nomad-Worker im Nomad-Lifecycle das Image. In diesem Fall entscheidet der Nomad-Broker darßber welcher Nomad-Worker geeignet ist den Service to hosten. Die gesamte Kommunikation verläuft Nomad-intern. Hier hat man keine Chance, auf dem Nomad-Worker ein docker login
zu triggern. Ich wollte hier aber verwenden, sondern AWS-IAM-Roles verwenden, die an die AWS-EC2-Instanz attached sind.
ACHTUNG: als ich es zum ersten mal verwenden wollte verwirrte mich, dass das Package in Amazonlinux, Ubuntu und Arch Linux amazon-ecr-credential-helper
heisst ... das Binary dann aber docker-credential-helper-ecr
(Package in Brew). Sollte fĂźr Deine Distribution kein Package zur VerfĂźgung stehen, kannst man es sich aus dem bauen oder eins der verwenden.
Schritte ():
Installation des docker-credential-ecr-login
in den PATH