Ошибка Docker: недопустимый формат ссылки: имя репозитория должно быть в нижнем регистре

Попался в эту ошибку Docker с одним из моих проектов:

invalid reference format: repository name must be lowercase

Каковы различные причины этого общего сообщения?

Я уже понял это после некоторых усилий, поэтому я собираюсь ответить на свой вопрос, чтобы задокументировать его здесь, поскольку решение не появляется сразу при выполнении веб-поиска, а также потому, что это сообщение об ошибке не описывает прямая проблема, с которой сталкивается Докер.

«Ссылка» в докере - это указатель на изображение. Это может быть имя образа, идентификатор образа, включить в имя сервер реестра, использовать тег sha256 для закрепления образа и все остальное, что можно использовать для указания на образ, который вы хотите запустить.

Сообщение invalid reference formatоб ошибке означает, что докер не может преобразовать указанную вами строку в изображение. Это может быть недопустимое имя или это может быть из-за ошибки синтаксического анализа ранее в docker runкомандной строке, если вы запускаете образ именно так. Если в файле компоновки развернуть переменную в имени изображения, эта переменная может расширяться неправильно.

В docker runкомандной строке это часто приводит к тому, что параметры не заключаются в кавычки с пробелами и неправильно порядок командной строки. Командная строка имеет следующий порядок:

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

Наиболее распространенная ошибка при передаче аргументов в запуск - это отображение тома, расширяющее имя пути, которое включает в себя пробел, а не цитирование пути или экранирование пробела. Например

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

И исправить это так же просто, как:

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

Позвольте мне подчеркнуть, что Docker не допускает даже смешанных символов.

Хороший: docker build -t myfirstechoimage:0.1 .

Плохой: docker build -t myFirstEchoImage:0.1 .

имеет место в текущем рабочем каталоге и используется $(pwd)для сопоставления томов. Не любит пробелы в именах каталогов.

В моем случае это было -eдо параметров для mysql docker

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

Также проверьте, нет ли пробелов

В моем случае имя изображения, определенное в виде docker-compose.ymlпрописных букв. Тот факт, что repositoryвместо сообщения об ошибке упоминается image, не помогает описать проблему, и потребовалось время, чтобы разобраться.

В моем случае проблема была в расстановке параметров. Первоначально у меня был --nameпараметр после параметров среды, а затем объем и attach_dbs параметры и изображение в конце команды, как показано ниже.

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

После изменения параметров, как показано ниже, все работало нормально (в основном --nameпараметр, за которым следует имя изображения).

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']}]"

В MacOS, когда вы работаете на диске iCloud, ваш $ PWD будет содержать каталог «Мобильные документы». Кажется, не нравится пространство!

В качестве обходного пути я скопировал свой проект на локальный диск, где нет места в пути к моей папке проекта.

Я не вижу способа обойтись без изменения пути к iCloud по умолчанию, который ~/Library/Mobile Documents/com~apple~CloudDocs

Пробел в пути в «Мобильных документах» кажется тем, что docker run не нравится.

Замена image: ${DOCKER_REGISTRY}notificationsapi с image:notificationsapi или image: ${docker_registry}notificationsapi в Докер-compose.yml сделал решает проблему

файл с ошибкой

  version: '3.4'

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

файл без ошибок

version: '3.4'

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

Поэтому я думаю, что ошибка была связана с нестрочными буквами, которые у нее были

Для меня проблема заключалась в том, что пространство в отображении тома не было экранировано. В задании jenkins, которое запускало команду docker run, было пробел, и в результате движок докеров не смог понять команду docker run.

Действительно, реестр докеров на сегодняшний день (sha 2e2f252f3c88679f1207d87d57c07af6819a1a17e22573bcef32804122d2f305) не обрабатывает пути, содержащие символы верхнего регистра. Очевидно, что это плохой выбор дизайна, вероятно, из-за желания поддерживать совместимость с определенными операционными системами, которые не различают регистр на уровне файлов (например, Windows ).

Если кто-то аутентифицируется для области и пытается получить несуществующий репозиторий со всеми строчными буквами, вывод будет

(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"}]}]}

Однако, если кто-то пытается сделать это с компонентом в верхнем регистре, возвращается только 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

иногда вы пропускаете флаг -e, когда в строке указано несколько переменных env

например, плохо: docker run --name somecontainername -e ENV_VAR1=somevalue1 ENV_VAR2=somevalue2 -d -v "mypath:containerpath" <imagename e.g. postgres>

хороший: docker run --name somecontainername -e ENV_VAR1=somevalue1 -e ENV_VAR2=somevalue2 -d -v "mypath:containerpath" <imagename e.g. postgres>

A referenceв Docker - это то, что указывает на изображение. Это может быть удаленный или локальный реестр. Позвольте мне сначала описать сообщение об ошибке, а затем показать решения для этого.

неверный формат ссылки

Это означает, что использованная ссылка не является допустимым форматом. Это означает, что ссылка (указатель), которую мы использовали для идентификации изображения, недействительна. Обычно за этим следует описание. Это сделает ошибку более понятной.

недопустимый формат ссылки: имя репозитория должно быть в нижнем регистре

Это означает, что в используемой ссылке не должно быть заглавных букв. Попробуйте запустить docker run Ubuntu( неправильно ) против docker run ubuntu( правильно ). Docker не позволяет использовать символы верхнего регистра в качестве ссылки на изображение. Простые шаги по устранению неполадок.

1) Dockerfile содержит заглавные буквы в качестве изображений.

FROM Ubuntu (wrong)
FROM ubuntu (correct)

2) Имя изображения, определенное в docker-compose.yml, состояло из заглавных букв

3) Если вы используете Jenkins или GoCD для развертывания контейнера докеров, проверьте команду запуска, содержит ли имя образа заглавную букву.

Пожалуйста, прочтите этот документ, написанный специально для этой ошибки.

У меня была такая же ошибка, и по какой-то причине она, похоже, была вызвана прописными буквами в задании Jenkins, которое запускало docker runкоманду.

Это происходит из-за пробелов в текущем рабочем каталоге, которые были созданы $(pwd)для томов карты. Итак, я использовал docker-composeвместо этого.

docker-compose.ymlФайл.

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". Как указано выше, мы создаем файл образа для контейнера докеров. commend говорит, что создать файл использования образа ( -f относится к файлу докера ) и -t для целевого файла образа, который мы собираемся отправить в докер. символ "." представляет текущий каталог

решение указанной выше проблемы: укажите имя целевого изображения в нижнем регистре

Docker может создавать образы автоматически, читая инструкции из Dockerfile. Dockerfile - это текстовый документ, содержащий все команды, которые пользователь может вызвать в командной строке для сборки изображения. пример: FROM python: 3.7-alpine "python" должен быть в нижнем регистре

В моем случае я пытался запустить postgres через докер. Изначально я работал как:

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

Мне не хватало -e после каждой переменной окружения. Изменение приведенной выше команды на приведенную ниже сработало

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

Я хочу, чтобы сообщение об ошибке выводило строку проблемы. Я получал это из-за странной проблемы копирования и вставки команды «docker run». Пробела , как символ использовались перед именем обратного РЕПО и изображений.

Большинство приведенных выше ответов не сработали в моем случае, поэтому я задокументирую это, если кто-то сочтет это полезным. Первая строка в dockerfile FROM node:10моего случая, слово узел не должен быть в верхнем регистре есть FROM NODE:10. Я внес это изменение, и оно сработало.

В моем случае DockerFile содержал имя изображения в смешанном регистре, а не в нижнем регистре.

Предыдущая строка в моем DockerFile

FROM CentOs

и когда я изменил выше на FROM centos, он работал гладко.

В моем случае у меня был голый --envпереключатель, то есть без фактического имени или значения переменной, например:

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

Попробуйте использовать символы нижнего регистра в вашем DockerFile

Например, используйте:

openjdk:8

вместо того

openJDK:8