Błąd platformy Docker: nieprawidłowy format odniesienia: nazwa repozytorium musi być zapisana małymi literami

Napotkałem ten błąd Dockera w jednym z moich projektów:

invalid reference format: repository name must be lowercase

Jakie są różne przyczyny tej ogólnej wiadomości?

Po pewnym wysiłku już to rozgryzłem, więc odpowiem na własne pytanie, aby to udokumentować, ponieważ rozwiązanie nie pojawia się od razu podczas wyszukiwania w Internecie, a także dlatego, że ten komunikat o błędzie nie opisuje bezpośredni problem, na jaki napotyka Docker.

„Odwołanie” w oknie dokowanym to wskaźnik do obrazu. Może to być nazwa obrazu, identyfikator obrazu, uwzględnienie serwera rejestru w nazwie, użycie znacznika sha256 do przypięcia obrazu i wszystko inne, co może być użyte do wskazania obrazu, który chcesz uruchomić.

Komunikat o invalid reference formatbłędzie oznacza, że ​​docker nie może przekonwertować podanego ciągu na obraz. Może to być nieprawidłowa nazwa lub może wynikać z błędu analizowania wcześniejszego w docker runwierszu poleceń, jeśli w ten sposób uruchamiasz obraz. W przypadku pliku redagowania, jeśli rozwiniesz zmienną w nazwie obrazu, ta zmienna może nie rozwijać się poprawnie.

W przypadku docker runwiersza poleceń często skutkuje to brakiem cytowania parametrów ze spacjami i błędną kolejnością wiersza poleceń. Linia poleceń jest uporządkowana jako:

docker ${args_to_docker} run ${args_to_run} image_ref ${cmd_to_exec}

Najczęstszym błędem w przekazywaniu argumentów do uruchomienia jest mapowanie woluminu rozszerzające nazwę ścieżki, która zawiera spację, a nie cytowanie ścieżki ani jej unikanie. Na przykład

docker run -v $(pwd):/data image_ref

Rozwiązanie jest tak proste, jak:

docker run -v "$(pwd):/data" image_ref

Podkreślę, że Docker nie pozwala nawet na mieszane postacie.

Dobry: docker build -t myfirstechoimage:0.1 .

Zły: docker build -t myFirstEchoImage:0.1 .

miał miejsce w bieżącym katalogu roboczym i służył $(pwd)do mapowania woluminów. Nie lubi spacji w nazwach katalogów.

W moim przypadku było -ewcześniej parametry dokera mysql

docker run --name mysql-standalone -e MYSQL_ROOT_PASSWORD=hello -e MYSQL_DATABASE=hello -e MYSQL_USER=hello -e MYSQL_PASSWORD=hello -d mysql:5.6

Sprawdź również, czy brakuje spacji

W moim przypadku nazwa obrazu jest zdefiniowana za pomocą docker-compose.ymlwielkich liter. Fakt, że komunikat o błędzie wymienionych repositoryzamiast imagenie pomogło opisać problem i zajęło to trochę czasu, aby dowiedzieć się.

W moim przypadku problem polegał na ustawieniu parametrów. Początkowo miałem --nameparametr po parametrach środowiska, a następnie głośność i attach_dbs parametry oraz obraz na końcu polecenia, jak poniżej.

docker run -p 1433:1433 -e sa_password=myComplexPwd -e ACCEPT_EULA=Y --name sql1 -v c:/temp/:c:/temp/ attach_dbs="[{'dbName':'TestDb','dbFiles':['c:\\temp\\TestDb.mdf','c:\\temp\\TestDb_log.ldf']}]" -d microsoft/mssql-server-windows-express

Po przestawieniu parametrów jak poniżej wszystko działało dobrze (w zasadzie wstawienie --nameparametru, a następnie nazwa obrazu).

docker run -d -p 1433:1433 -e sa_password=myComplexPwd -e ACCEPT_EULA=Y --name sql1 microsoft/mssql-server-windows-express -v C:/temp/:C:/temp/ attach_dbs="[{'dbName':'TestDb','dbFiles':['C:\\temp\\TestDb.mdf','C:\\temp\\TestDb_log.ldf']}]"

Na MacOS, kiedy pracujesz na dysku iCloud, twój $ PWD będzie zawierał katalog „Dokumenty mobilne”. Wygląda na to, że przestrzeń nie lubi!

Aby obejść ten problem, skopiowałem swój projekt na dysk lokalny, na którym nie ma miejsca w ścieżce do mojego folderu projektu.

Nie widzę sposobu na obejście zmiany domyślnej ścieżki do iCloud, którą jest ~/Library/Mobile Documents/com~apple~CloudDocs

Przestrzeń na ścieżce w „Dokumentach mobilnych” wydaje się być tym, czego nie lubi docker.

Wymiana image: ${DOCKER_REGISTRY}notificationsapi z image:notificationsapi lub image: ${docker_registry}notificationsapi w Docker-compose.yml nie rozwiązuje problemu

plik z błędem

  version: '3.4'

services:
  notifications.api:
    image: ${DOCKER_REGISTRY}notificationsapi
    build:
      context: .
      dockerfile: ../Notifications.Api/Dockerfile

plik bez błędów

version: '3.4'

services:
 notifications.api:
    image: ${docker_registry}notificationsapi
    build:
      context: .
      dockerfile: ../Notifications.Api/Dockerfile

Myślę więc, że błąd wynikał z braku małych liter

Dla mnie problem polegał na tym, że miejsce w mapowaniu woluminów nie zostało usunięte. Zadanie Jenkinsa, które uruchamiało polecenie docker run, miało w sobie spację, w wyniku czego silnik dockera nie był w stanie zrozumieć polecenia docker run.

Rzeczywiście, dzisiejszy rejestr Dockera (sha 2e2f252f3c88679f1207d87d57c07af6819a1a17e22573bcef32804122d2f305) nie obsługuje ścieżek zawierających wielkie litery. Jest to oczywiście zły wybór projektowy, prawdopodobnie ze względu na chęć zachowania zgodności z niektórymi systemami operacyjnymi, które nie rozróżniają wielkości liter na poziomie plików (np. Windows ).

Jeśli ktoś uwierzytelnia się dla zakresu i próbuje pobrać nieistniejące repozytorium ze wszystkimi małymi literami, dane wyjściowe to

(auth step not shown)
curl -s -H "Authorization: Bearer $TOKEN" -X GET https://$LOCALREGISTRY/v2/test/someproject/tags/list
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"test/someproject","Action":"pull"}]}]}

Jeśli jednak spróbuje się to zrobić ze składnikiem pisanym wielkimi literami, zwracany jest tylko 404:

(authorization step done but not shown here)
$ curl -s -H "Authorization: Bearer $TOKEN" -X GET https://docker.uibk.ac.at:443/v2/test/Someproject/tags/list

404 page not found

czasami pomijasz flagę -e, gdy w tekście znajduje się kilka zmiennych env

np. zły: docker run --name somecontainername -e ENV_VAR1=somevalue1 ENV_VAR2=somevalue2 -d -v "mypath:containerpath" <imagename e.g. postgres>

dobry: docker run --name somecontainername -e ENV_VAR1=somevalue1 -e ENV_VAR2=somevalue2 -d -v "mypath:containerpath" <imagename e.g. postgres>

A referencew Dockerze wskazuje na obraz. Może to być rejestr zdalny lub rejestr lokalny. Pozwól, że najpierw opiszę komunikat o błędzie, a następnie pokażę rozwiązania tego problemu.

nieprawidłowy format odniesienia

Oznacza to, że odwołanie, którego użyliśmy, nie jest prawidłowym formatem. Oznacza to, że odniesienie (wskaźnik), którego użyliśmy do identyfikacji obrazu, jest nieprawidłowe. Na ogół następuje następujący opis. Dzięki temu błąd będzie znacznie wyraźniejszy.

nieprawidłowy format odniesienia: nazwa repozytorium musi być zapisana małymi literami

Oznacza to, że odwołanie, którego używamy, nie powinno mieć wielkich liter. Spróbuj uruchomić docker run Ubuntu( źle ) vs docker run ubuntu( poprawnie ). Docker nie zezwala na żadne wielkie litery jako odniesienia do obrazu. Proste kroki rozwiązywania problemów.

1) Dockerfile zawiera wielkie litery jako obrazy.

FROM Ubuntu (wrong)
FROM ubuntu (correct)

2) Nazwa obrazu zdefiniowana w docker-compose.yml miała wielkie litery

3) Jeśli używasz Jenkinsa lub GoCD do wdrażania kontenera Docker, sprawdź polecenie uruchomienia, czy nazwa obrazu zawiera wielką literę.

Przeczytaj ten dokument napisany specjalnie dla tego błędu.

Miałem ten sam błąd iz jakiegoś powodu wydaje się, że był on spowodowany dużymi literami w zadaniu Jenkinsa, które uruchomiło docker runpolecenie.

Dzieje się tak z powodu spacji w bieżącym katalogu roboczym, które pochodzą z $(pwd)woluminów map. Więc docker-composezamiast tego użyłem .

docker-compose.ymlPlików.

version: '3'
services:
  react-app:
    build:
      context: .
      dockerfile: Dockerfile.dev
    ports:
      - "3000:3000"
    volumes:
      - /app/node_modules
      - .:/app

„Docker build -f Dockerfile -t SpringBoot-Docker”. Jak w powyższym poleceniu tworzymy plik obrazu dla kontenera docker. commend mówi, że utwórz plik użycia obrazu ( -f odnosi się do pliku dockera ) i -t dla celu pliku obrazu, który zamierzamy wypchnąć do dockera. „.” reprezentuje bieżący katalog

rozwiązanie powyższego problemu: podaj nazwę obrazu docelowego małymi literami

Docker może automatycznie tworzyć obrazy, odczytując instrukcje z pliku Dockerfile. Plik Dockerfile to dokument tekstowy zawierający wszystkie polecenia, które użytkownik może wywołać w wierszu poleceń, aby złożyć obraz. przykład: FROM python: 3.7-alpine Słowo „python” powinno być zapisane małymi literami

W moim przypadku próbowałem uruchomić postgres przez docker. Początkowo biegałem jako:

docker run -d -p 5432:5432 -e POSTGRES_PASSWORD=test_password POSTGRES_USER=test_user POSTGRES_DB=test_db --rm -v ~/docker/volumes/postgres:/var/lib/postgresql/data --name pg-docker postgres

Brakowało mi -e po każdej zmiennej środowiskowej. Zmiana powyższego polecenia na poniższe zadziałała

docker run -d -p 5432:5432 -e POSTGRES_PASSWORD=test_password -e POSTGRES_USER=test_user -e POSTGRES_DB=test_db --rm -v ~/docker/volumes/postgres:/var/lib/postgresql/data --name pg-docker postgres

Chciałbym, aby komunikat o błędzie wyświetlał ciąg problemu. Otrzymywałem to z powodu dziwnego problemu z kopiowaniem i wklejaniem w poleceniu „docker run”. Czasoprzestrzeni jak znak był używany przed nazwą repo i obrazu.

Większość powyższych odpowiedzi nie zadziałała w moim przypadku, więc udokumentuję to na wypadek, gdyby ktoś uznał to za pomocne. Pierwsza linia w pliku dockerfile FROM node:10dla mojego przypadku, słowo node nie powinno być wielkie, tj FROM NODE:10. Dokonałem tej zmiany i zadziałało.

W moim przypadku DockerFile zawierał nazwę obrazu w mieszanej wielkości zamiast małych liter.

Wcześniejszy wiersz w moim pliku DockerFile

FROM CentOs

a kiedy zmieniłem powyżej FROM centos, działało gładko.

W moim przypadku miałem nagi --envprzełącznik, czyli taki bez rzeczywistej nazwy lub wartości zmiennej, np .:

docker run \
   --env \       <----- This was the offending item
   --rm \
   --volume "/home/shared:/shared" "$(docker build . -q)"

Spróbuj użyć małych liter w swoim pliku DockerFile

Na przykład użyj:

openjdk:8

zamiast

openJDK:8