Сборка Docker "Не удалось разрешить" archive.ubuntu.com "" apt-get не может ничего установить

Я пытался запустить сборку Docker для различных файлов, которые раньше работали раньше, а теперь уже не работают.

Как только в файле Docker будет указана строка для установки программного обеспечения, произойдет сбой с сообщением о том, что пакет не найден.

RUN apt-get -y install supervisor nodejs npm

Общее сообщение, которое появилось в журналах было

Could not resolve 'archive.ubuntu.com'

Любая идея, почему любое программное обеспечение не будет установлено?

20 ответов

Решение

После сильной головной боли я нашел ответ. Could not resolve 'archive.ubuntu.com' можно исправить, внеся следующие изменения:

  1. Раскомментируйте следующую строку в /etc/default/docker
    DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4"

  2. Перезапустите сервис Dockersudo service docker restart

  3. Удалите все изображения, которые кэшировали неверные настройки DNS.

  4. Построить снова и проблема должна быть решена.

Кредит идет Андрею С.Б.

Раскомментировав DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4" в /etc/default/docker как предположил Matt Carrier, НЕ работает для меня. Также не поместил DNS-серверы моей корпорации в этот файл. Но есть и другой способ (читай дальше).

Сначала давайте проверим проблему:

$ docker run --rm busybox nslookup google.com   # takes a long time
nslookup: can't resolve 'google.com'   # <--- appears after a long time
Server:    8.8.8.8
Address 1: 8.8.8.8

Если кажется, что команда зависает, но в итоге выдает ошибку "не удается разрешить" google.com ", то у вас та же проблема, что и у меня.

nslookup Команда запрашивает сервер DNS 8.8.8.8, чтобы превратить текстовый адрес "google.com" в IP-адрес. По иронии судьбы, 8.8.8.8 является общедоступным DNS-сервером Google. Если nslookup не удается, общедоступные DNS-серверы, такие как 8.8.8.8, могут быть заблокированы вашей компанией (что я предполагаю по соображениям безопасности).

Можно подумать, что добавление DNS-серверов вашей компании в DOCKER_OPTS в /etc/default/docker должен сделать свое дело, но по какой-то причине, это не сработало для меня. Я опишу, что сработало для меня ниже.

РЕШЕНИЕ:

На хосте (я использую Ubuntu 16.04) узнайте адреса основного и дополнительного DNS-серверов:

$ nmcli dev show | grep 'IP4.DNS'
IP4.DNS[1]:              10.0.0.2
IP4.DNS[2]:              10.0.0.3

Используя эти адреса, создайте файл /etc/docker/daemon.json:

$ sudo su root
# cd /etc/docker
# touch daemon.json

Поместите это в /etc/docker/daemon.json:

{                                                                          
    "dns": ["10.0.0.2", "10.0.0.3"]                                                                           
}     

Выход из корня:

# exit

Теперь перезапустите докер:

$ sudo service docker restart

ПРОВЕРКА:

Теперь проверьте, что добавление /etc/docker/daemon.json файл позволяет преобразовать google.com в IP-адрес:

$ docker run --rm busybox nslookup google.com
Server:    10.0.0.2
Address 1: 10.0.0.2
Name:      google.com
Address 1: 2a00:1450:4009:811::200e lhr26s02-in-x200e.1e100.net
Address 2: 216.58.198.174 lhr25s10-in-f14.1e100.net

ССЫЛКИ:

Я основал свое решение на статье Робина Уинслоу, которая заслуживает всяческих похвал за это решение. Спасибо, Робин!

Msgstr "Исправить сетевую конфигурацию DNS Докера." Робин Уинслоу Получено 2016-11-09. https://robinwinslow.uk/2016/06/23/fix-docker-networking-dns/

Я сталкиваюсь с той же проблемой, но мне не нужно ни комментировать записи / etc / default / docker dns, ни редактировать /etc/resolv.conf в контейнере сборки или /etc/docker/daemon.json.

Но после того, как я собрал опцию --network=host, разрешение снова было в порядке.

docker build --network=host -t my-own-ubuntu-like-image .

Может быть, это поможет кому-то снова.

Я считаю, что ответ Мэтта Кэрриера является правильным решением этой проблемы. Однако после его реализации я все еще наблюдал такое же поведение: could not resolve 'archive.ubuntu.com',

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

Как я споткнулся:

  1. Поскольку я работал с документацией по Docker, у меня уже был пример образа, установленного на моей машине. Я смог запустить новый контейнер для запуска этого образа и создать новый сеанс bash в этом контейнере: docker run -it docker/whalesay bash
  2. Контейнер имеет подключение к Интернету?: ping 172.217.4.238 (Google.com)
  3. Может ли контейнер разрешать имена хостов? ping google.com

В моем случае первый ping привели к ответам, второго нет.

Как я исправил:

Когда я обнаружил, что DNS не работает внутри контейнера, я убедился, что могу дублировать такое же поведение на хосте. nslookup google.com решено просто отлично на хосте. Но, nslookup google.com 8.8.8.8 или же nsloookup google.com 8.8.4.4 время вышло.

Затем я нашел сервер (ы) имен, который использовал мой хост, запустив nm-tool (на Ubuntu 14.04). В духе быстрой обратной связи я снова запустил пример изображения и добавил IP-адрес сервера имен в файл resolv.conf контейнера: sudo vi /etc/resolv.conf, После сохранения я снова попытался пинговать (ping google.com) и на этот раз это сработало!

Обратите внимание, что изменения, внесенные в файл resolv.conf контейнера, не являются постоянными и будут потеряны при перезапуске контейнера. В моем случае более подходящим решением было добавить IP-адрес сервера имен моей сети к хосту /etc/default/docker файл.

Для тех, у кого также есть эта проблема, я решил ее, отредактировав /etc/default/docker файл, как подсказывают другие ответы и вопросы. Однако я понятия не имел, какой IP использовать в качестве DNS.

Только через некоторое время я понял, что мне нужно бежать ifconfig docker на хосте, чтобы показать IP для сетевого интерфейса докера.

docker0   Link encap:Ethernet  Endereço de HW 02:42:69:ba:b4:07  
          inet end.: 172.17.0.1  Bcast:0.0.0.0  Masc:255.255.0.0
          endereço inet6: fe80::42:69ff:feba:b407/64 Escopo:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Métrica:1
          pacotes RX:8433 erros:0 descartados:0 excesso:0 quadro:0
          Pacotes TX:9876 erros:0 descartados:0 excesso:0 portadora:0
          colisões:0 txqueuelen:0 
          RX bytes:484195 (484.1 KB) TX bytes:24564528 (24.5 MB)

это было 172.17.0.1 в моем случае. Надеюсь, что это помогает любому, кто также имеет эту проблему.

После добавления локального DNS DNS в файл Docker по умолчанию он начал работать для меня... пожалуйста, найдите следующие шаги...

$ nm-tool # (will give you the dns IP)

DNS: 172.168.7.2

$ vim /etc/default/docker # (uncomment the DOCKER_OPTS and add DNS IP)
DOCKER_OPTS="--dns 172.168.7.2 --dns 8.8.8.8 --dns 8.8.4.4"

$ rm `docker ps --no-trunc -aq` # (remove all the containers to avoid DNS cache)

$ docker rmi $(docker images -q) # (remove all the images)

$ service docker restart #(restart the docker to pick up dns setting)

А теперь иди и построй докер...:)

Я нашел этот ответ после некоторого Googleing. Я использую Windows, поэтому некоторые из приведенных выше ответов не относятся к моей файловой системе.

В основном запустить:

docker-machine ssh default
echo "nameserver 8.8.8.8" > /etc/resolv.conf

Который просто перезаписывает существующий сервер имен, используемый с 8.8.8.8 Я верю. Это сработало для меня!

Я просто хотел добавить поздний ответ для всех, кто сталкивался с этой проблемой из поисковых систем.

НЕ делайте этого: у меня была опция в /etc/default/docker для установки iptables=false, Это было потому, что UFW не работал (все было открыто, хотя было разрешено только 3 порта), поэтому я слепо следовал за ответом на этот вопрос: Uncomplicated Firewall (UFW) ничего не блокирует при использовании Docker, и это было связано в Комментарии

Я очень плохо понимаю правила iptables / nat / routing в целом, поэтому я мог бы сделать что-то иррациональное.

Оказывается, я, вероятно, неправильно настроил его и убил разрешение DNS внутри своих контейнеров. Когда я запустил интерактивный контейнерный терминал: docker run -i -t ubuntu:14.04 /bin/bash

У меня были такие результаты:

root@6b0d832700db:/# ping google.com
ping: unknown host google.com

root@6b0d832700db:/# cat /etc/resolv.conf
search online.net
nameserver 8.8.8.8
nameserver 8.8.4.4

root@6b0d832700db:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=1.76 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=1.72 ms

Возврат всей моей конфигурации ufw (before.rules), отключение ufw и удаление iptables=false из /etc/default/docker восстановили функциональность разрешения DNS контейнеров.

Я с нетерпением жду, чтобы снова включить функциональность UFW, следуя этим инструкциям.

Я тоже некоторое время боролся с этим сейчас, но вот что решило это для меня на Ubuntu 16.04 x64. Надеюсь, это тоже сэкономит чье-то время.

  1. В /etc/NetworkManager/NetworkManager.conf: закомментируйте#dns=dnsmasq

  2. Создать (или изменить) /etc/docker/daemon.json:

{
    "dns": ["8.8.8.8"]
}
  1. Перезагрузите докер:sudo service docker restart

У меня та же проблема, и я попробовал упомянутые шаги, но, кажется, ни один не работает, пока не обновите настройки сети.

Шаги:

  1. Как уже упоминалось, добавить DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4 --ip-masq=true" в /etc/default/docker,
  2. Вручную очистите содержимое таблицы PREROUTING, используя iptables -t nat -F POSTROUTING, После запуска перезапустите docker, и он инициализирует таблицу nat с новым диапазоном IP-адресов.

Та же проблема для меня (на Ubuntu Xenial).

  • docker run --dns ... для контейнеров работал.
  • Обновление параметров демона Docker для docker build (docker-compose и т. д.) не сработало.

После анализа логов докера (journalctl -u docker.service) если найдено какое-либо предупреждение о неправильном применении resolvconf.

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

Применил это решение Как мне настроить мой статический DNS в интерфейсах? (askubuntu), т.е. добавление серверов имен в /etc/resolvconf/resolv.conf.d/tail

После обновления resolvconf (или перезагрузки).

bash docker run --rm busybox nslookup google.com

работал мгновенно.

Все мои сборки docker-compose теперь работают.

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

Решил проблему для меня, используя Docker Desktop для Windows на Windows 10.

У меня сегодня та же проблема, я только что добавил строку ниже в /etc/default/docker

DOCKER_OPTS="--dns 172.18.20.13 --dns 172.20.100.29 --dns 8.8.8.8"

и затем я перезапустил свой ноутбук.

В моем случае перезапуск демона docker мне не подходит, мне нужно перезагрузить ноутбук, чтобы он заработал.

В моем случае проблема заключалась в брандмауэре. Отключение на данный момент решило проблему. я использую nftables. Остановка службы сделала свое дело.

      sudo systemctl stop nftables.service 

С последними обновлениями следующая строка в ( /etc/docker/daemon.json) была причиной проблемы:

      {
    "bridge": "none"
}

Удалите его и перезапустите службу докеров с помощью: sudo systemctl restart docker

ОПЕРАЦИОННЫЕ СИСТЕМЫ ( Ubuntu 20.04.3 LTS) и Докер ( version 20.10.11, build dea9396)

В моем случае, поскольку мои контейнеры находились в облачной среде, MTU интерфейсов не было обычным 1500, а было примерно 1450, поэтому мне пришлось настроить мой демон docker, чтобы установить MTU на 1450 для контейнеров.

{  
"mtu": 1454 
}

посмотрите на это: https://mlohr.com/docker-mtu/

При запуске сборки Docker используйте любой из следующих вариантов:

      --network=host
--network=bridge
--network={your_own}   #ensure that driver is either bridge or host

Значение сети по умолчанию не позволяет подключаться к внешней сети.

        --network string          Set the networking mode for the RUN instructions during build (default "default")

В моей системе (macOS High Sierra 10.13.6 с участием Docker 2.1.0.1) это было связано с корпоративным прокси.

Я решил это двумя шагами:

  1. Вручную настройте параметры прокси в Preferences>Proxies
  2. Добавьте те же настройки в ваш config.json внутри ~/.docker/config.json любить:

     "proxies":
    {
      "default":
      {
        "httpProxy": "MYPROXY",
        "httpsProxy": "MYPROXY",
        "noProxy": "MYPROXYWHITELIST"
      }
    }
    

Я столкнулся с этим по очень глупой причине. Несколько недель назад я настроил Docker для отправки трафика через прокси-сервер, который я потом удалил и забыл сказать Docker, чтобы тот прекратил его использовать.

Возможно, стоит проверить, делали ли вы что-то подобное.

Идти к~/.docker/config.jsonи проверьте, что там нет ничего подобного :

      {
 "proxies":
 {
   "default":
   {
     "httpProxy": "http://192.168.1.12:3128",
     "httpsProxy": "http://192.168.1.12:3128",
     "noProxy": "*.test.example.com,.example2.com,127.0.0.0/8"
   }
 }
}

Если есть, попробуйте удалить его, перезапустить docker deamon/рабочий стол и повторить попытку. Это решило для меня.

Небольшое примечание: после закрытия и Docker Desktop (на Mac) он больше не открывался, и мне пришлось принудительно завершить работу вот так , но после этого все заработало как положено).

у меня есть dnsmasqв моей системе для разрешения DNS, у которой были серверы имен для разрешения URL. Docker копирует хост-систему в том виде, в котором она находится в контейнере, и поэтому не имеет нужных серверов имен. Из документов:

По умолчанию контейнер наследует настройки DNS хоста, как определено в файле конфигурации.

Добавление серверов имен в /etc/resolv.conf хоста исправил проблему.

Другие вопросы по тегам