„tag ostatnie nie znaleziono” na Döcker ciągnąć z prywatnym rejestrze

Question

Mam kłopoty ciągnięcie obrazów popychany do prywatnego rejestru i dostać:

Tag ostatnie nie znaleziono w repozytorium

używam pojemnik domyślny rejestru dostarczone przez Döcker:

# docker images 
REPOSITORY   TAG     IMAGE ID   CREATED    VIRTUAL SIZE 
registry   latest    7e2db37c6564  8 days ago   411.6 MB 
janos/wheezy  latest    900e813f1fd9  11 months ago  218.6 MB 

Jako test, powiedzmy, że chcę mieć lokalną wersję wheezy:

# docker tag janos/wheezy staging-docker.mysite.nl/myself/wheezy 
# docker push staging-docker.mysite.nl/myself/wheezy 
The push refers to a repository [staging-docker.mysite.nl/myself/wheezy] (len: 1) 
Sending image list 
Pushing repository staging-docker.mysite.nl/myself/wheezy (1 tags) 
7af801e4faa1: Pushing [==================================================>] 226.3 MB/226.3 MB 
2014/11/21 16:06:38 

obraz wydaje się być tam:

# docker images 
REPOSITORY        TAG     IMAGE ID   CREATED    VIRTUAL SIZE 
registry        latest    7e2db37c6564  8 days ago   411.6 MB 
staging-docker.mysite.nl/myself/wheezy latest    900e813f1fd9  11 months ago  218.6 MB 
janos/wheezy       latest    900e813f1fd9  11 months ago  218.6 MB 

I lokalnie mogę go uruchomić:

# docker run -i -t staging-docker.mysite.nl/myself/wheezy /bin/bash 
root@6b5fafe61d88:/# ls 
bin boot dev etc home lib lib64 media mnt opt proc root run sbin selinux srv sys tmp usr var 
root@6b5fafe61d88:/# exit 

Ale gdy próbujesz uruchomić lub wyciągnąć go z innego serwera, otrzymuję „Tag ostatni nie Znaleziono "

# docker pull staging-docker.mysite.nl/myself/wheezy 
Pulling repository staging-docker.mysite.nl/myself/wheezy 
2014/11/21 16:08:15 Tag latest not found in repository staging-docker.mysite.nl/myself/wheezy 

Jawnie dodanie" najnowsze "nie pomaga. Ten sam błąd.

widzę rozmowy przybyć do rejestru, więc nie jestem inadvertedly używając innego:

172.17.42.1 - - [21/Nov/2014:15:08:15 +0000] "GET /v1/_ping HTTP/1.0" 200 1439 "-" "Go 1.1 package http" 
172.17.42.1 - - [21/Nov/2014:15:08:15 +0000] "GET /v1/_ping HTTP/1.0" 200 1439 "-" "Go 1.1 package http" 
21/Nov/2014:15:08:15 +0000 DEBUG: args = {'namespace': u'myself', 'repository': u'wheezy'} 
172.17.42.1 - - [21/Nov/2014:15:08:15 +0000] "GET /v1/repositories/myself/wheezy/images HTTP/1.0" 200 164 "-" "docker/1.3.1 go/go1.3.3 git-commit/4e9bbfa kernel/3.16.0-0.bpo.2-amd64 os/linux arch/amd64" 
21/Nov/2014:15:08:15 +0000 DEBUG: args = {'namespace': u'myself', 'repository': u'wheezy'} 
21/Nov/2014:15:08:15 +0000 DEBUG: [get_tags] namespace=myself; repository=wheezy 
172.17.42.1 - - [21/Nov/2014:15:08:15 +0000] "GET /v1/repositories/myself/wheezy/tags HTTP/1.0" 200 2 "-" "docker/1.3.1 go/go1.3.3 git-commit/4e9bbfa kernel/3.16.0-0.bpo.2-amd64 os/linux arch/amd64" 

I podczas sprawdzania tagów obrazu ręcznie, są one rzeczywiście pusty:

# curl -k https://staging-docker.mysite.nl/v1/repositories/myself/wheezy/tags 
{} 

Pytanie 1: dlaczego jest on pusty w pierwszej kolejności, ponieważ Docker zawsze wykorzystuje najnowsze ...

Pytanie 2: jeśli w jakiś sposób coś się popsuje, a najnowszy tag rzeczywiście zniknął, dlaczego nadal mogę uruchomić go lokalnie?

wersje dokowane są takie same na obu serwerach:

# docker version 
Client version: 1.3.1 
Client API version: 1.15 
Go version (client): go1.3.3 
Git commit (client): 4e9bbfa 
OS/Arch (client): linux/amd64 
Server version: 1.3.1 
Server API version: 1.15 
Go version (server): go1.3.3 
Git commit (server): 4e9bbfa 

Answer 1

pytania 1:

powinno to być problemem w zdalnej prywatnej rejestru, jest to potwierdzone z polecenia

curl -k https://staging-docker.mysite.nl/v1/repositories/myself/wheezy/tags 

Pytanie 2 Znacznik

jest tylko aliasem dla obrazu dokowanego, jeśli uruchomisz lokalnie w innym nazewnictwie, wszystkie są uruchamiane z tych samych obrazów dokowania, bez różnicy.

a znacznik latest nie stracił lokalnie, co jest potwierdzone przez komendę

$ docker images 

Rozwiązanie

Sprawdź Döcker prywatną ustawień rejestru i śledzenia dziennik, aby zobaczyć, co jest problem, jeśli chcesz go całkowicie rozwiązać, musisz dołączyć więcej informacji do debugowania w zdalnym rejestrze prywatnym.

Również konfiguracja zdalnego rejestru przypomina wersję i platformę.

Answer 2

Zauważyłem, że komunikaty o błędach klienta Docker nie zawsze odzwierciedlają główną przyczynę. Widziałem ten warunek, gdy klient dokujacy nie uwierzytelnił się z serwerem, a także, gdy uzgadnianie SSL z jakiegoś powodu się nie powiedzie. Biorąc pod uwagę, że nie używałeś -insecure-registry, to brzmi jak ten drugi.