Развертывание стека докеров приводит к ошибке "Нет такой ошибки изображения"

Я использую докеры и хочу развернуть службу с помощью docker-compose. Моя служба использует настраиваемый образ под названием myuser/myrepo:mytag, который я успешно развертываю в Docker-Hub в частном репозитории.

My docker-compose выглядит следующим образом:

version: "3.3"

services:

  myservice:
    image: myuser/myrepo:mytag
    ports:
      - "8080:8080"

Перед выполнением я успешно вытащил изображение с помощью: docker pull myuser/myrepo:mytag

Когда я запускаю docker stack deploy -c docker-compose.yml myapp, я всегда получаю ошибку: "No such image: myuser/myrepo:mytag".

Интересно, что запустив тот же файл, используя только: docker-compose up (т.е. без режима роя), все работает отлично, и сервис запускается.

Я действительно не понимаю, почему это терпит неудачу? Я уже пробовал очистить докер с помощью docker system prune, а затем оттолкнул изображение, не получив успеха.

Ответы

Ответ 1

Уже нашел решение. Мое изображение размещено в частном хранилище. Помимо менеджера роя (где я выполнял команды), у меня был работающий работник роя.

Когда я запустил docker stack deploy -c docker-compose.yml myapp, докер развернул сервис на рабочем узле (а не на диспетчере, как я думал). На рабочем узле у докера не было учетных данных для извлечения образа из частного хранилища. Следовательно, чтобы исправить это, либо передайте флаг --with-registry-auth (который передает учетные данные для хранилища на рабочий узел), либо убедитесь, что служба развернута на узле, где присутствует изображение.

Видеть: https://docs.docker.com/engine/reference/commandline/deploy/

Ответ 2

У меня была похожая проблема на Mac за корпоративным брандмауэром.

Я смог решить только после подключения непосредственно к Интернету.

Просто для обновления, пока я нахожусь в VPN, я могу получить доступ к Интернету без каких-либо настроек прокси-сервера, и я могу загружать (докер) образы просто отлично с docker run. Проблема только с docker-compose.

Я попытался изменить сервер имен на 8.8.8.8 в resolv.conf на своих виртуальных машинах, но проблема не была решена.