Docker proxy не работает

Configure Docker to use a proxy server

Estimated reading time: 2 minutes

If your container needs to use an HTTP, HTTPS, or FTP proxy server, you can configure it in different ways:

In Docker 17.07 and higher, you can configure the Docker client to pass proxy information to containers automatically.

In Docker 17.06 and earlier versions, you must set the appropriate environment variables within the container. You can do this when you build the image (which makes the image less portable) or when you create or run the container.

Configure the Docker client

On the Docker client, create or edit the file

/.docker/config.json in the home directory of the user that starts containers. Add JSON similar to the following example. Substitute the type of proxy with httpsProxy or ftpProxy if necessary, and substitute the address and port of the proxy server. You can also configure multiple proxy servers simultaneously.

You can optionally exclude hosts or ranges from going through the proxy server by setting a noProxy key to one or more comma-separated IP addresses or hosts. Using the * character as a wildcard for hosts and using CIDR notation for IP addresses is supported as shown in this example:

When you create or start new containers, the environment variables are set automatically within the container.

Use environment variables

Set the environment variables manually

When you build the image, or using the —env flag when you create or run the container, you can set one or more of the following variables to the appropriate value. This method makes the image less portable, so if you have Docker 17.07 or higher, you should configure the Docker client instead.

Источник

Исправление проблем под Docker. Казалось бы, при чём здесь GIT?

Докер под Windows — это постоянные приключения. То ему нужно обновить операционку, иначе последние версии не ставятся, то он забывает, как подключаться к сети. В общем, каждый день от него новости. «Поставил и забыл» — это не про Docker Desktop for Windows. Особенно, когда он используется не совсем так, как рекомендуют его разработчики. А они почему-то не одобряют подключение внешних windows сетевых дисков в качестве локальных. И совсем не одобряют доступ к к таким сетевым папкам, которые расположены ещё и на host машине. Пишут, что это ужас-ужас с точки зрения безопасности, требуют всяких ключей типа:

cap_add:
— SYS_ADMIN
— DAC_READ_SEARCH

для работы команды mount в контейнере и прочая, и прочая.

В общем, когда в очередной раз после выгрузки контейнеров на сервер заказчика сервисы перестали видеть сетевые диски, я не особо удивился. Так уже бывало, и даже была написана пошаговая инструкция для группы поддержки, как и что перезагружать, когда ломаются сетевые настройки докера.

Так что я открываю свою инструкцию и начинаю действовать. Перезапускаю контейнеры — не помогает. Перезапускаю через docker-compose с пересозданием инфраструктуры — не помогает. Сбрасываю настройки Docker к заводским, восстанавливаю параметры виртуалки, загружаю заново образы, запускаю через docker-compose — опять всё по старому — не видит сеть. Точнее не подключается к сетевым шарам, хотя пинг из контейнера до SMB сервера проходит нормально. Последний пункт — перезагрузку сервера и переустановку Docker, пока пропускаю, так как перезагружать сервер очень не хочется. На этом инструкция кончилась.

Ок, перехожу на свою домашнюю машину, тут у меня тоже Docker под Windows, но чуть более новой версии. Проверяю на нём. Те же яйца:

Ага. Ну неужели, думаю, Docker накатил обновление с какой-то безопасностью и теперь мои скрипты из-за этого не запускаются? Последняя проверка — начисто удалить Docker с машины, и поставить заново. Это должно быть круче сброса к заводским настройкам. Проделываю весь перечень из предыдущего шага, только в дополнение к этому ещё и перезагружаю свою машину, чтобы уж совсем железно. Ставлю Docker c нуля, заливаю образы, запускаю docker-compose — ёпрст! Все сервисы как не видели сетевых шар, так и продолжают писать при загрузке «mount error(22): Invalid argument»

Пробую запустить скрипт по строкам из командной строки: подключаюсь к контейнеру, запускаю по очереди команды и вижу, что всё подключается и работает как надо:

То есть, это что же, какая-то хрень с передачей параметров в скрипт при запуске контейнера?

Ищем ещё идеи. Все варианты с перезагрузкой докера отмели, остались варианты с возможными изменениями в родительском образе. У меня образ собирается на основе openjdk:8-jdk-alpine, конкретной версии не указано, так что какие-нибудь улучшения безопасности могли сломать мои скрипты. Может поменяли что-то в OpenJDK или дочернем Alpine?

Проверяю логи проекта, пробую выбрать более старые openjdk:8-jdk-alpine-3.8, openjdk:8-jdk-alpine-3.7 и т.д. — каждый раз пересобираю контейнер, проверяю — всё по-старому.

Чёрт подери! Может я что-то всё-таки поменял в своей сборке? Выгружаю из GIT’а версию проекта месячной давности, собираю — те же глюки. Трёхмесячной давности — проблема всё ещё тут. Как же так? Что изменилось? Конфигурация докера к настоящему моменту гарантировано рабочая, конфигурация образа — тоже не поменялась, исходники проекта те же самые (GIT всё сохраняет). Чудес не бывает — надо понять, где всё-таки появились изменения. В проде вручную запускаю команды подключения к шарам — так до перезапуска сервисы будут работать нормально и иду спать. Утро вечера мудренее.

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

Сообщение «mount error(22): Invalid argument» — это не сильно информативно. Нахожу, что есть волшебный ключик -х для баша с которой он выводит отладочную инфу при выполнениии скриптов.

Начинаем отладку внутри sh:

И тут появляются какие-то непонятные моменты — строка начинается с кавычек, потом кавычки в конце… Откуда кавычки?

Идея — может запуск с помощью настоящего bash будет информативнее?

Инсталлирую в контейнер BASH:

Блин, тут вроде, когда строка начинается с плюса — это хорошо, но появились какие-то \r и параметры $’. ‘

Ставим Midnight Commander, чтобы уж экспериментировать с удобствами apk add mc и открываем скрипт на редактирование, а там:

Оппа! ^M в конце каждой строки. Ну-ка, ну-ка, смотрим в локальном проекте — а что у нас с окончаниями строк. CRLF. Работаем под Windows, однако.

Меняем в этом конкретно файле CRLF на LF (да здравствует Notepad++!), собираем проект — бинго! Работает как надо.

Почему раньше было ок, а сейчас всё полетело? Смотрю по коммитам — не было никаких перемен. И тут вспоминаю, что GIT умеет на лету править символы перевода строк текстовых файлов. А я на днях подключил новый репозитарий, и возможно выгрузил оттуда все файлы с конвертацией в CRLF.

В итоге добавляем в проект файл .gitattributes, с указанием, что в отдельных файлах надо-таки сохранять символы конца строк как в UNIX:

Мораль — иногда виновник даже не попадает в круг первоначальных подозреваемых.

Постскриптум

DockerNAT has been removed from Docker Desktop 2.2.0.0 as using an IP address to communicate from the host to a container is not a supported feature. To communicate from a container to the host, you must use the special DNS name host.docker.internal.

Ок, поправил конфиги для тестового окружения, база данных подцепилась, пинг из контейнера до host.docker.internal проходит, а вот сетевые диски не подключаются. Пробую запустить mount вручную из шелла, и получаю знакомую ошибку «mount error(22): Invalid argument».

Убираю по очереди аргументы — запускаю просто «mount -t cifs //host.docker.internal/playground /pipeline» — вроде работает, но стучится от пользователя «root».

Добавляю пользователя: mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser — спрашивает пароль и подключается!

Полный вариант тоже работает:

а вот «mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser,password=smbpassword,vers=2.0» не пашет.

Меняю последний параметр на vers=2.1 — ура, работает!

Похоже, что Docker в последней версии сделал свою собственную имплементацию SMB сервера с блекджеком, но без поддержки 2.0. Ерунда, конечно, по сравнению с другими новостями.

Источник

Не могу скачать образы Docker за прокси

Я установил Docker на свой Ubuntu 13.10 (Saucy Salamander) и когда я набираю в своей консоли:

я получаю следующую ошибку:

Я за прокси-сервером без аутентификации, и это мой :

что я делаю не так?

22 ответов

сначала создайте каталог systemd для службы Docker:

Теперь создайте файл с именем /etc/systemd/system/docker.service.d/http-proxy.conf добавляет HTTP_PROXY переменные среды:

если у вас есть внутренние реестры докеров, которые вам нужно связаться без проксирования можно указать их через NO_PROXY переменные среды:

убедитесь, что конфигурация загружена:

настройки прокси-сервера APT не связаны с Docker.

Docker использует переменную среды HTTP_PROXY, если она присутствует, например:

но вместо этого, я предлагаю вам взглянуть на вашу /etc/default/docker файл конфигурации: у вас должна быть строка для раскомментации (и, возможно, настройки), чтобы автоматически применять настройки прокси-сервера. Затем перезапустите сервер Docker:

на CentOS файл конфигурации для Docker находится по адресу:

добавление приведенной ниже строки помогло мне заставить демона Docker работать за прокси-сервером:

на Ubuntu вам нужно установить http_proxy для демона Docker, а не клиентский процесс. Это делается в /etc/default/docker (см. здесь).

Если вы используете новый Docker для Mac (или Docker для Windows), просто щелкните правой кнопкой мыши значок Docker tray и выберите настройки (Windows: Settings), затем перейдите в раздел Дополнительно и в разделе прокси укажите настройки прокси. Нажмите Apply и перезапустить и дождитесь перезапуска Docker.

чтобы расширить ответ Аруна выше, для этого, чтобы работать в CentOS 7, мне пришлось удалить команды «экспорт». Так редактировать

затем перезапустите Docker:

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

Проблема

если вы используете локально привязанных прокси, например, прослушивание 127.0.0.1:8989 , он не будет работать в настройки для Mac. От документация Docker:

Я хочу подключиться из контейнера к службе на узле

Mac имеет изменяющийся IP-адрес (или нет, если у вас нет доступа к сети). Наш Текущая рекомендация-прикрепить неиспользуемый IP-адрес к lo0 интерфейс на Mac; например: sudo ifconfig lo0 alias 10.200.10.1/24 , и убедитесь, что служба прослушивает этот адрес или 0.0.0.0 (т. е. не 127.0.0.1 ). Затем контейнеры могут подключаться к этому адресу.

аналогично для стороны сервера Docker. (Чтобы понять серверную и клиентскую стороны Docker, попробуйте запустить docker version .) И серверная сторона работает на уровне виртуализации, который имеет свой собственный localhost . Поэтому он не будет подключения к прокси-серверу на localhost хост-ОС.

решение

Итак, если вы используете локальный прокси-сервер, как я, в основном вам придется сделать следующие вещи, чтобы заставить его работать с Docker для Mac:

Сделайте ваш прокси-сервер слушать на 0.0.0.0 вместо 127.0.0.1 . внимание: вам нужна правильная настройка брандмауэра для предотвращения несанкционированного доступа к он.

добавьте псевдоним loopback в lo0 интерфейс, например, 10.200.10.1/24 :

установите HTTP и / или HTTPS прокси в 10.200.10.1:8989 С предпочтения в меню Docker tray (предположим, что прокси-сервер прослушивает порт 8989 ).

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

обратите внимание: псевдоним замыкания на себя, установленный ifconfig не сохраняется после перезагрузки. Сделать его постоянным-это другая тема. Пожалуйста, проверьте этот блог на японском языке (Google Translate может помочь).

это исправление, которое сработало для меня: Ubuntu, Docker версия: 1.6.2

в файле /etc/default/docker добавьте строку:

Источник

Не удается загрузить образы Docker через прокси

Я установил Docker на свой Ubuntu 13.10 (Saucy Salamander), и когда я набираю в консоли:

Я получаю следующую ошибку:

Я нахожусь за прокси-сервером без аутентификации, и это мой файл /etc/apt/apt.conf :

Что я делаю не так?

26 ответов

Сначала создайте подключаемый каталог systemd для службы Docker:

Теперь создайте файл с именем /etc/systemd/system/docker.service.d/http-proxy.conf , который добавляет переменную среды HTTP_PROXY :

Если у вас есть внутренние реестры Docker, с которыми вам нужно связаться без проксирования, вы можете указать их через переменную среды NO_PROXY :

Убедитесь, что конфигурация загружена:

Настройки вашего прокси-сервера APT не связаны с Docker.

Docker использует переменную среды HTTP_PROXY, если она есть. Например:

Но вместо этого я предлагаю вам взглянуть на ваш файл конфигурации /etc/default/docker : у вас должна быть строка для раскомментирования (и, возможно, корректировки), чтобы настройки прокси-сервера применялись автоматически. Затем перезапустите сервер Docker:

В CentOS файл конфигурации для Docker находится по адресу:

Добавление следующей строки помогло мне заставить демон Docker работать за прокси-сервером:

Если вы используете новый Docker для Mac (или Docker для Windows ), просто щелкните правой кнопкой мыши значок Docker на панели задач и выберите Настройки ( Windows: Параметры), затем перейдите в раздел «Дополнительно» и в разделе «Прокси-серверы» укажите настройки прокси-сервера. Нажмите Применить и перезапустить и дождитесь перезапуска Docker.

В Ubuntu вам нужно установить http_proxy для демона Docker, а не для клиентского процесса. Это делается в /etc/default/docker (см. здесь ).

Чтобы расширить ответ Аруна, чтобы это работало в CentOS 7, мне пришлось убрать команды «экспорт». Так что редактировать

Затем перезапустите Docker:

Почему локально привязанный прокси не работает

Проблема

Если вы используете локально привязанный прокси, например при прослушивании 127.0.0.1:8989 он НЕ РАБОТАЕТ в Docker для Mac . Из документации Docker:

Я хочу подключиться из контейнера к службе на хосте

У Mac есть изменяющийся IP-адрес (или его нет, если у вас нет доступа к сети). Наша текущая рекомендация — прикрепить неиспользуемый IP-адрес к интерфейсу lo0 на Mac; например: sudo ifconfig lo0 alias 10.200.10.1/24 , и убедитесь, что ваша служба прослушивает этот адрес или 0.0.0.0 (т. е. не 127.0.0.1 ). Затем контейнеры могут подключаться к этому адресу.

То же самое и на стороне сервера Docker. (Чтобы понять серверную и клиентскую стороны Docker, попробуйте запустить docker version .) А серверная сторона работает на уровне виртуализации, который имеет свой собственный localhost . Следовательно, он не будет подключаться к прокси-серверу на localhost ОС хоста.

Решение

Итак, если вы используете прокси с локальной привязкой, как я, в основном вам нужно будет сделать следующие вещи, чтобы он работал с Docker для Mac:

Сделайте так, чтобы ваш прокси-сервер слушал 0.0.0.0 вместо 127.0.0.1 . lo0 , например 10.200.10.1/24 :

Установите для прокси-сервера HTTP и / или HTTPS значение 10.200.10.1:8989 в Настройки в меню панели Docker (предположим, что прокси-сервер прослушивает порт 8989 ).

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

ifconfig , не сохраняется после перезагрузки. Сделать это настойчивым — другая тема. Пожалуйста, проверьте это сообщение в блоге на японском языке (может помочь Google Translate).

Это исправление, которое сработало для меня: Ubuntu, версия Docker: 1.6.2

В файле /etc/default/docker добавьте строку:

Чтобы настроить Docker для работы с прокси, вам необходимо добавить переменную среды HTTPS_PROXY / HTTP_PROXY в файл Docker sysconfig ( /etc/sysconfig/docker ).

Репозиторий Docker (Docker Hub) поддерживает только HTTPS. Чтобы заставить Docker работать с перехватывающими SSL прокси, вам необходимо добавить корневой сертификат прокси в хранилище доверенных сертификатов системы.

Для CentOS скопируйте файл в /etc/pki/ca-trust/source/anchors/ , обновите хранилище доверенных сертификатов CA и перезапустите службу Docker.

Если ваш прокси-сервер использует аутентификацию NTLMv2 — вам необходимо использовать промежуточные прокси, такие как Cntlm, чтобы связать аутентификацию. Это сообщение в блоге подробно объясняет это .

В новой версии Docker, docker-engine , в дистрибутиве на основе systemd вы должны добавить строку переменной среды в / lib / systemd / system / docker .service , как упоминалось другими:

После установки Docker сделайте следующее:

Затем вы можете тянуть или делать что угодно:

Поскольку мне еще не разрешено комментировать:

Для CentOS 7 мне нужно было активировать EnvironmentFile в docker.service, как описано здесь: Control and настроить Docker с помощью systemd.

Изменить: я добавляю свое решение, как указано Nilesh. Мне нужно было открыть «/etc/systemd/system/docker.service», и мне пришлось добавить в разделе

EnvironmentFile = — / etc / sysconfig / docker

Только после этого в мою систему был загружен файл «etc / sysconfig / docker».

Чтобы решить проблему с curl в сборке Docker, я добавил в Dockerfile следующее:

Обратите внимание, что оператор ENV находится ПЕРЕД оператором RUN.

И чтобы сделать демон Docker доступ в Интернет (я использую Kitematic с boot2docker), я добавил в /var/lib/boot2docker/profile следующее:

Затем я перезапустил Докер с помощью sudo /etc/init.d/docker restart .

Если вы используете прокси socks5, вот мой тест с Docker 17.03.1-ce с настройкой all_proxy, и он сработал:

Полное решение для Windows, для настройки параметров прокси.

Вы можете настроить его напрямую, щелкнув правой кнопкой мыши на настройках, в значке Docker, а затем в Прокси.

Здесь вы можете настроить адрес прокси, порт, имя пользователя и пароль.

Если вы используете Ubuntu, вы должны выполнить эту команду:

И перезагрузите Docker с помощью:

Или перейдите в /etc/docker.io с помощью nano .

Простая установка переменных окружения прокси не помогла мне в версии 1.0.1 . Мне пришлось обновить файл /etc/default/docker.io , указав правильное значение для переменной «http_proxy».

Если вы работаете в Ubuntu, выполните эти команды, чтобы добавить прокси.

И раскомментируйте строки, в которых указано

И замените его соответствующим прокси-сервером и именем пользователя.

Затем перезапустите Docker, используя:

Теперь вы можете запускать команды Docker за прокси:

Возможно, вам нужно установить переменные в нижнем регистре. В моем случае мой файл /etc/systemd/system/docker.service.d/http-proxy.conf выглядит так:

Я также столкнулся с той же проблемой за брандмауэром. Выполните следующие шаги:

Не используйте и не удаляйте файл https_prxoy.conf.

Перезагрузите и перезапустите контейнер Docker:

В Ubuntu 14.04 (Trusty Tahr) с Docker 1.9.1 я просто раскомментировал строку http_proxy , обновил значение, а затем перезапустил службу Docker.

На RHEL6.6 работает только это (обратите внимание на использование export ):

/ и т.д. / sysconfig / Докер

ПРИМЕЧАНИЕ: Оба могут использовать протокол http .)

В моей сети Ubuntu работает за корпоративным прокси-сервером ISA. И это требует аутентификации. Я перепробовал все упомянутые выше решения, и ничего не помогло. Что действительно помогло, так это запись прокси-строки в файле /etc/systemd/system/docker.service.d/https-proxy.conf без имени домена.

И некоторые другие замены, такие как @ -> %40 или \ -> \\ , которые я пытался использовать

Источник