Docker engine stopped что делать
Устранение неполадок при разработке с Docker в Visual Studio
Используя средства Visual Studio для работы с контейнерами, вы можете столкнуться с некоторыми проблемами при создании или отладке приложения. Далее приведены некоторые распространенные действия по устранению неполадок.
Совместное использование тома не включено. Включите совместное использование тома в параметрах Docker CE для Windows (только для контейнеров Linux)
Управление общим доступом к файлам необходимо только при использовании Hyper-V с Docker. Если используется WSL 2, приведенные ниже действия можно опустить, а параметр общего доступа к файлам не будет отображатся. Для разрешения этой проблемы:
Щелкните правой кнопкой мыши Docker for Windows (Docker для Windows) в области уведомлений, а затем выберите Параметры.
Выберите Ресурсы > Общий доступ к файлам и предоставьте общий доступ к нужной папке. Вы также можете предоставить доступ ко всему системному диску, однако мы не рекомендуем делать это.
В версиях, выпущенных позднее Visual Studio 2017 15.6, если общие диски не настроены, поступает предупреждение.
Невозможно начать отладку
Одна из причин может быть связана с наличием устаревших компонентов отладки в папке профиля пользователя. Чтобы последние компоненты отладки скачались при следующем сеансе отладки, выполните следующие команды для удаления папок:
Ошибки, характерные для сетей при отладке приложения
Попробуйте выполнить сценарий, который можно скачать из репозитория GitHub для очистки сетей узлов контейнера, который обновит связанные с сетью компоненты на вашем хост-компьютере.
Отказ в подключении
При использовании Docker для macOS может появиться ошибка со ссылкой на папку /usr/local/share/dotnet/sdk/NuGetFallbackFolder. Добавьте папку на вкладку общего доступа к файлам в Docker.
Группа пользователей Docker
При работе с контейнерами в Visual Studio может возникнуть следующая ошибка.
Для работы с контейнерами Docker требуются разрешения, предоставляемые участникам группы docker-users. Чтобы добавить себя в эту группу в Windows 10 или более поздней версии, сделайте следующее:
Добавлять пользователей в группы можно также с помощью команды net localgroup в командной строке администратора.
В PowerShell используйте командлет Add-LocalGroupMember.
Недостаточно места на диске
Нажмите Применить и перезагрузить. Эти действия изменяют файл конфигурации: %ProgramData%\docker\config\daemon.json. Ранее созданные образы не перемещаются.
Несоответствие типов контейнеров
При добавлении в проект поддержки Docker выберите контейнер Windows или Linux. Если узел сервера Docker не настроен на запуск того же типа контейнера, что и целевой объект проекта, то, скорее всего, появится сообщение об ошибке, аналогичное приведенному ниже:
Для разрешения этой проблемы:
Репозиторий GitHub Microsoft/DockerTools
При возникновении других проблем дополнительные сведения см. в репозитории Microsoft/DockerTools.
Исправление проблем под 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 всё сохраняет). Чудес не бывает — надо понять, где всё-таки появились изменения. В проде вручную запускаю команды подключения к шарам — так до перезапуска сервисы будут работать нормально и иду спать. Утро вечера мудренее.
Наутро приходит идея — что пора, видимо, узнать, а что собственно говоря не нравится скрипту при выполнении.
Начинаем отладку внутри 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».
Полный вариант тоже работает:
Меняю последний параметр на vers=2.1 — ура, работает!
Похоже, что Docker в последней версии сделал свою собственную имплементацию SMB сервера с блекджеком, но без поддержки 2.0. Ерунда, конечно, по сравнению с другими новостями.
Еще одна причина, почему тормозят Docker контейнеры
Ранее мы запускали серии операций, связанных с разработкой b CI/CD, во внутренем кластере Kubernetes. Все бы ничего, да при запуске «докеризированного» приложения неожиданно сильно падала производительность. Мы не скупились: в каждом из контейнеров стояли ограничения по вычислительной мощности и памяти (5 CPU / 30 ГБ RAM), заданные через конфигурацию Pod. На виртуальной машине с такими параметрами все наши запросы из крошечного набора данных (10 Кб) для тестов летали бы. Однако в Docker & Kubernetes на 72 CPU / 512 ГБ RAM мы успевали запустить 3–4 копии продукта, а потом начинались тормоза. Запросы, которые раньше завершались за пару миллисекунд, теперь висели по 1–2 секунде, и это вызывало всевозможные сбои в CI-конвейере задач. Пришлось вплотную заняться отладкой.
Как правило, под подозрением — всевозможные ошибки конфигурации при упаковке приложения в Docker. Однако мы не нашли ничего, что могло бы вызвать хоть какое-либо замедление (если сравнивать с установками на голом железе или виртуальных машинах). С виду все правильно. Далее мы опробовали всевозможные тесты из пакета Sysbench. Проверили производительность ЦП, диска, памяти — все было таким же, как и на голом железе. Некоторые сервисы нашего продукта хранят подробную информацию обо всех действиях: ее потом можно использовать в профилировании производительности. Как правило, при нехватке какого-либо ресурса (ЦП, оперативной памяти, диска, сети) в некоторых вызовах отмечается значительный провал во времени — так мы обнаруживаем, что именно тормозит и где. Однако в данном случае ничего такого не произошло. Временные пропорции не отличались от исправной конфигурации — с той лишь разницей, что каждый вызов был значительно медленнее, чем на голом железе. Ничто не указывало на настоящий источник проблемы. Мы уже были готовы сдаться, как вдруг нашли вот это.
В этой статье автор анализирует похожий загадочный случай, когда два, по идее, легких процесса убивали друг друга при запуске внутри Docker на одной и той же машине, причем ограничения ресурсов выставлялись на весьма скромные значения. Мы сделали два важных вывода:
perf (иногда его называют perf_events или perf-инструменты; ранее был известен как Performance Counters for Linux, PCL) — это инструмент анализа производительности в Linux, доступный с версии ядра 2.6.31. Утилита управления пользовательским пространством, perf, доступна с командной строки и представляет собой набор подкоманд.
Она осуществляет статистическое профилирование целой системы (ядра и пространства пользователя). Данное средство поддерживает счетчики производительности аппаратной и программной (например, hrtimer) платформы, точки трассировки и динамические пробы (скажем, kprobes или uprobes). В 2012 году два инженера IBM признали perf (наряду с OProfile) одним из двух наиболее используемых инструментов профилирования счетчиков производительности в Linux.
Ниже приведены записи perf первых 10 секунд ThoughtSpot, работающего на здоровой (быстрой) машине (слева) и внутри контейнера (справа).
Программы используют posix_fadvise(), заявляя о намерении доступа к данным файла по определенному шаблону в будущем. Это дает ядру возможность провести необходимую оптимизацию.
Вызов используется для любых ситуаций, поэтому явно на источник проблемы не указывает. Однако, покопавшись в коде, я нашел лишь одно место, которое, теоретически, затрагивал каждый процесс в системе:
что мы, конечно же, сделали и… в яблочко!
То, что раньше отнималло пару секунд, теперь выполняется за 8 (восемь!) миллисекунд. Немножко погуглив, мы нашли вот что: https://issues.apache.org/jira/browse/MESOS-920 и еще это: https://github.com/google/glog/pull/145, что в очередной раз подтвердило нашу догадку об истинной причине торможения. Скорее всего, то же самое происходило и на виртуальной машине/голом железе, но так как у нас было по 1 копии процесса на каждую машину/ядро, то интенсивность вызова fadvise была значительно ниже, чем и объяснялось отсутствие дополнительного потребления ресурсов. Увеличив процессы логирования в 3–4 раза и выделив им одно общее ядро, мы увидели, что это действительно застопорило fadvise.
Самые распространённые ошибки при работе с Docker
Docker позволяет заключать приложения и сервисы в контейнеры. Однако во время создания образа или объединения слоев иногда возникают ошибки. Причиной ошибки может быть опечатка, проблемы библиотек поддержки, конфликт имен, сбой взаимодействия между контейнерами.
Данное руководство по устранению неполадок предназначено для новичков Docker. Руководство поможет вам устранить проблемы при сборке образов и настройке соединений между контейнерами.
Требования
Для выполнения руководства нужно предварительно установить приложение Docker. Инструкции по установке можно найти по ссылкам:
1: Ошибки в Dockerfile
Наибольшее количество ошибок обычно сосредоточено в Dockerfile.
Прежде чем приступить к исправлению ошибок, нужно понять разницу между образом и контейнером.
Образ Docker – это ресурс, предназначенный только для чтения, который создаётся с помощью файла под названием Dockerfile. Образы можно выкладывать на Docker Hub.
Контейнер – это экземпляр приложения, который создаётся с помощью образа.
Dockerfile подробно описывает пошаговый процесс, с помощью которого Docker создаёт образ. Каждая строка в Dockerfile описывает один из этапов процесса. Таким образом, если Docker переходит на новый этап, значит, предыдущие этапы выполнены без ошибок.
Создайте небольшой проект, чтобы на его примере рассмотреть несколько общих ошибок Dockerfile. Создайте каталог docker_image в домашнем каталоге. Затем создайте в нём Dockerfile.
Добавьте в файл такие строки:
В этом файле специально сделана опечатка. Можете её найти? Попробуйте создать образ с помощью этого файла и посмотрите, что скажет Docker.
Из этого сообщения об ошибке следует, что во второй команде допущена ошибка. Как уже говорилось, это сделано намеренно: вместо команды apt-get в файле указана команда aapt-get. Первый этап выполнен без ошибок, а на втором Docker обнаруживает опечатку.
Исправьте опечатку в Dockerfile:
Снова запустите docker build:
Теперь процесс проходил немного быстрее: Docker кэширует удачно выполненные этапы, чтобы потом не перевыполнять их. Однако потом возникла новая ошибка.
Дистрибутив Debian, на котором основан образ, не может найти текстовый редактор nano, хотя он точно доступен в репозитории Debian. Базовый образ собирается из кэшированных метаданных: репозиториев и списков доступных пакетов. Вероятно, при кэшировании произошла ошибка.
Чтобы исправить её, отредактируйте Dockerfile и добавьте в него чистку и обновление исходных файлов перед установкой новых пакетов:
Добавьте в файл такую строку:
Сохраните и закройте файл. Запустите docker build:
Теперь процесс будет выполнен успешно:
Добавьте в образ Python 3 и базу данных PostgreSQL. Откройте Dockerfile:
Вставьте такие строки:
Сохраните и закройте файл. Соберите образ.
Как видите, все пакеты установлены без ошибок. Кроме того, процесс выполняется очень быстро, поскольку большинство его этапов помещено в кэш.
Примечание: Docker кэширует процесс сборки. Потому иногда при сборке образа используются устаревшие исходные файлы. Чтобы избежать этого, добавьте в Dockerfile чистку и обновление исходников. Если при установке или обновлении пакетов возникает ошибка, запустите внутри контейнера команду:
apt-get clean && apt-get update
Внимательно читайте вывод Docker, чтобы отследить опечатки. Своевременно обновляйте исходные файлы, чтобы избежать ошибок, вызванных кэшированными списками пакетов.
Синтаксические ошибки и ошибки кэширования – наиболее распространенные проблемы, с которыми вы можете столкнуться при создании образа Docker. Теперь давайте рассмотрим проблемы, которые могут возникнуть при работе с контейнерами, созданными на основе этих образов.
2: Конфликты имён
Чем больше вы запускаете контейнеров, тем выше вероятность возникновения конфликта имён.
К примеру, иногда при создании контейнера пользователи пытаются использовать имя, которое ранее было присвоено другому контейнеру в этой системе. Данный раздел научит вас выбирать имена для контейнеров, переименовывать и удалять их, чтобы устранить конфликт имён.
Используйте созданный ранее образ, чтобы запустить контейнер. Затем, чтобы протестировать его работу, запустите интерактивный интерпретатор bash внутри этого контейнера.
После запуска контейнера вы увидите командную строку root:
Теперь давайте рассмотрим проблемы, которые могут возникнуть в контейнере.
Запуская контейнер так, как показано выше, не указывая имя, Docker присваивает ему случайное имя. Чтобы просмотреть список запущенных контейнеров, запустите на хосте Docker команду:
Примечание: Команду нужно запускать вне контейнера.
Откройте терминал хоста Docker и запустите:
Эта команда выведет список запущенных контейнеров:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
80a0ca58d6ec my_image «bash» 22 seconds ago Up 28 seconds loving_brahmagupta
Как видите, Docker выбрал для только что запущенного контейнера случайное имя, и в данном случае это loving_brahmagupta (вероятно, в вашем случае имя будет отличаться). Позволять Docker присваивать контейнерам случайные имена можно в некоторых простых случаях. Однако это может повлечь серьёзные проблемы. При развёртывании объемного проекта нужно присвоить контейнерам имена самостоятельно, чтоб иметь возможность ссылаться на них и автоматизировать их работу.
Чтобы задать имя контейнера, используйте при запуске аргумент –name. Также вы можете переименовать запущенный контейнер. Имя контейнера должно быть описательным.
Запустите следующую команду в терминале хоста Docker:
docker rename your_container_name python_box
Запросите список контейнеров:
Теперь контейнер loving_brahmagupta называется python_box:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
80a0ca58d6ec my_image «bash» 24 minutes ago Up 24 minutes python_box
Чтобы закрыть контейнер, введите exit в командную строку:
Также контейнер можно остановить с помощью команды kill из другого терминала хоста Docker:
docker kill python_box
В таком случае Docker возвращает имя остановленного контейнера:
Чтобы убедиться, что контейнер python_box остановлен, запросите список контейнеров:
Контейнер python_box в списке нет:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Вы думаете, что теперь можно запустить другой контейнер с именем python_box? Что ж, попробуйте сделать это:
Если вы собираете образ, а затем хотите повторно использовать имя существующего образа, этот образ будет переписан. Контейнеры работают немного сложнее: вы не можете переписать существующий контейнер.
Итак, Docker говорит, что контейнер python_box уже существует, хотя только что этот контейнер был остановлен. Его даже нет в списке команды docker ps. Да, на данный момент он не запущен, но он всё ещё доступен. Вы остановили, но не удалили его. Команда docker ps показывает не все доступные, а только запущенные контейнеры.
Чтобы запросить список всех контейнеров, нужно добавить флаг –а:
Как видите, python_box всё-таки в списке:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
80a0ca58d6ec my_image «bash» 12 minutes ago Exited (137) 6 minutes ago python_box
Контейнер существует, его состояние – Exited (137). Потому пока что вы не можете создать контейнер с таким же именем: для этого нужно удалить контейнер.
Чтобы сделать это, введите в терминал:
docker rm python_box
Docker выведет на экран имя удалённого контейнера.
Примечание: Если контейнер, который нужно удалить, всё ещё запущен, команда не сможет удалить его и вернёт ошибку.
Теперь попробуйте снова создать контейнер по имени python_box:
Процесс будет успешно выполнен, а на экране появится оболочка root:
Теперь остановите и удалите этот контейнер, чтобы избежать ошибок при дальнейшей работе. Откройте новый терминал на хосте Docker и выполните команду:
docker kill python_box && docker rm python_box
Эта команда состоит из двух команд, потому Docker выведет имя контейнера дважды:
Самостоятельно присваивая имена контейнерам, вы можете легко управлять инфраструктурой. Кроме того, так гораздо проще устанавливать взаимодействие между контейнерами.
3: Проблемы взаимодействия контейнеров
Докер может легко обрабатывать несколько контейнеров, благодаря чему вы можете запускать различные сервисы и даже дублировать сервисы в контейнерах. Если с одним из сервисов случился сбой или его взломали, вы можете просто заменить его другим, сохраняя при этом остальную часть инфраструктуры нетронутой. Но вы можете столкнуться с проблемами при настройке взаимодействия между этими контейнерами.
Создайте два взаимодействующих между собой контейнера: пусть первый будет контейнером Python на основе уже существующего образа, а второй будет запускать PostgreSQL.
Примечание: Официальный образ для контейнера PostgreSQL можно найти на Docker Hub.
Сначала создайте контейнер PostgreSQL. Присвойте ему имя с помощью аргумента –name (например, postgres_box).
Прежде контейнеры запускались на переднем плане, занимая терминал. Теперь нужно запустить контейнер PostgreSQL в фоновом режиме. Для этого используется флаг –detach.
Вместо команды bash запустите в контейнере команду postgres, которая запустит сервер баз данных PostgreSQL.
Docker загрузит образ с Docker Hub и создаст контейнер. Затем он вернёт полный ID контейнера, запущенного в фоновом режиме:
Unable to find image ‘postgres:latest’ locally
latest: Pulling from library/postgres
6a5a5368e0c2: Already exists
193f770cec44: Pull complete
.
484ac0d6f901: Pull complete
Digest: sha256:924650288891ce2e603c4bbe8491e7fa28d43a3fc792e302222a938ff4e6a349
Status: Downloaded newer image for postgres:latest
f6609b9e96cc874be0852e400381db76a19ebfa4bd94fe326477b70b8f0aff65
Просмотрите список запущенных контейнеров:
В списке вы увидите запущенный в фоновом режиме контейнер postgres_box, который использует порт 5432 (стандартный порт PostgreSQL)
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7a230b56cd64 postgres_box «/docker-entrypoint.s» Less than a second ago Up 2 seconds 5432/tcp postgres
Теперь запустите контейнер Python. Чтобы программы внутри контейнера Python могли видеть сервисы внутри контейнера postgres_box, нужно вручную связать эти контейнеры с помощью флага –link.
Чтобы создать ссылку, нужно указать имя контейнера, а затем, после флага –link, задать имена контейнеров, которые нужно связать. В данном случае команда будет выглядеть так:
Попробуйте подключиться к PostgreSQL из контейнера python_box.
Ранее вы установили nano в python_box. Используйте этот текстовый редактор, чтобы создать простой сценарий Python и подключиться к PostgreSQL. В терминал контейнера python_box введите:
root@3053f74c8c13: / # nano pg_test.py
«»»Test PostgreSQL connection.»»»
import psycopg2
conn = psycopg2.connect(user=’postgres’)
print(conn)
Сохраните и закройте файл. Попробуйте подключиться к БД с помощью этого сценария:
root@3053f74c8c13: / # python3 pg_test.py
В выводе говорится о том, что во время подключения произошла ошибка:
Traceback (most recent call last):
File «pg_test.py», line 5, in
conn = psycopg2.connect(database=»test», user=»postgres», password=»secret»)
File «/usr/lib/python3/dist-packages/psycopg2/__init__.py», line 164, in connect
conn = _connect(dsn, connection_factory=connection_factory, async=async)
psycopg2.OperationalError: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket «/var/run/postgresql/.s.PGSQL.5432»?
Итак, контейнер postgres_box запущен и связан с python_box. В чём же проблема? Дело в том, что во время соединения не был указан хост БД, потому Python пытается подключиться к ней локально. Но это не сработает, так как сервис запущен не локально – он работает в другом контейнере, а это то же самое, что на другом компьютере.
Вы можете получить доступ к связанным контейнерам, указав имя, использованное в ссылке. В данном случае мы используем postgres для ссылки на контейнер postgres_box, который запускает сервер базы данных. Вы можете убедиться в этом, просмотрев файл /etc/hosts внутри контейнера python_box:
root@3053f74c8c13: / # cat /etc/hosts
Вы увидите все доступные хосты, их имена и IP. Сервер postgres тоже в списке:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.2 postgres f6609b9e96cc postgres_box
172.17.0.3 3053f74c8c13
Отредактируйте сценарий Python и добавьте в него имя хоста. Откройте файл:
root@3053f74c8c13: / # nano pg_test.py
«»»Test PostgreSQL connection.»»»
import psycopg2
conn = psycopg2.connect(host=’postgres’, user=’postgres’)
print(conn)
Сохраните и закройте файл. Снова запустите сценарий:
root@3053f74c8c13: / # python3 pg_test.py
Теперь сценарий выполнен успешно:
Запоминайте имена контейнеров, чтобы иметь возможность подключаться к сервисам внутри этих контейнеров.
Заключение
В данном руководстве мы рассмотрели наиболее распространенные проблемы, с которыми можно столкнуться при работе с контейнерами Docker: от создания образов и до развертывания сетей контейнеров.
Docker предоставляет флаг –debug. В основном этим флагом пользуются разработчики Docker. Однако если вы хотите узнать больше о внутреннем строении Docker, попробуйте запустить команды Docker в режиме отладки (это вернёт более подробный вывод):
Контейнеры программного обеспечения существуют уже некоторое время, а сама система Docker – всего три года, потому иногда с ней бывает сложно. Чем чаще вы будете работать с Docker, тем больше у вас будет опыта: вы будете знать подводные камни, научитесь быстро справляться с рутинными задачами и устранять ошибки.