Контейнер докеров, похоже, не работает /etc/hosts до запуска _interactive_ docker
Если я «запускаю службу создания докеров» в интерактивном терминале (не -it, а bash, работающий на хосте в интерактивном режиме), моя служба успешно инициализируется.
Но если я вставлю ту же команду в сценарий оболочки, она не сработает.
Я подозреваю, что проблема в разрешении имен через /etc/hosts; кажется, он работает интерактивно, но по какой-то причине не в сценарии. Я хочу, чтобы контейнеры могли видеть имена, определенные в файле хоста /etc/hosts. И хотя я использую Linux Mint 19.1, мне нужно, чтобы он работал на Windows, Mac и Linux.
Вещи, которые я пробовал, которые не работали:
- Добавление сна - до 10 минут
- Проверка различий переменных среды
- Запуск команды под tcsh вместо bash
- Запуск команды в псевдотерминале с использованием /usr/bin/script -c
Но если я добавлю /bin/bash -i в свой сценарий с эхом, говорящим, какую команду вводить, это сработает!
Я использую:
docker version 18.09.6, build 481bc77
docker-compose version 1.24.0, build 0aa59064
Я должен был бы получить разрешение от своего руководства, чтобы поделиться чем-то большим, чем просто небольшими фрагментами кода.
Я хочу, чтобы служба запускалась через docker-compose up -d или хотя бы docker-compose start — в скрипте, ради автоматизации.
Сообщение об ошибке внутри контейнера (из docker logs -f service) выглядит так: elasticsearch.exceptions.ConnectionTimeout: ConnectionTimeout, вызванный - ReadTimeoutError (HTTPConnectionPool (host = u'elasticsearch', port = 9200): время ожидания чтения истекло. (время ожидания чтения = 10))
Иногда я вижу высокую нагрузку в elasticsearch, что кажется немного странным. Под высоким я подразумеваю до 490% на 8-ядерном процессоре (вероятно, с учетом гиперпоточности). Чаще всего он снижается примерно на 5-15%.
Вот SSCCE:
#!/bin/bash
set -eu
set -o pipefail
set -x
docker stop elasticsearch || true
docker-compose start elasticsearch
# Give elasticsearch some time to come up.
# Normally I use a small REST client that calls ES until it starts responding - but that wouldn't be self-contained.
sleep 120
docker stop service || true
docker-compose start service
Сам скрипт работает до завершения нормально, но затем «сервис» завершает работу раньше, чем должен.
Спасибо!
Спасибо. Я работаю над SSCCE.
Я не уверен, что правильно понял проблему, но я думаю, что вы хотите использовать docker-compose up -d elasticsearch вместо docker-compose start elasticsearch
Я думаю, что эта проблема связана с этим один
@user7440787 user7440787 Я использую «вверх» при первом запуске контейнера и «старт» при последующих запусках контейнера.
@ user7440787 Вопрос 31746182 действительно выглядит несколько уместным, хотя я подозреваю, что мне нужно подождать чего-то внутри контейнера, особенно для появления псевдо-DNS, чтобы он мог разрешить проблемы в /etc/hosts хоста.
Ответы 2
Если я правильно понял, вы хотите, чтобы контейнер elasticsearch обслуживал ваш контейнер service (т. е. оба контейнера связывались друг с другом), следовательно, контейнер service должен знать IP-адрес elasticsearch.
В этом случае docker-compose будет управлять адресами контейнеров, вам нужно будет сохранить эту информацию в сервисном контейнере как переменную среды. Плюсом этого является то, что вы можете запустить оба контейнера с помощью одной и той же команды (просто docker-compose up -d). Например:
services:
elasticsearch:
image: YOUR_ELASTICSEARCH_IMAGE
ports:
- 9200:9200
service:
image: YOUR_SERVICE_IMAGE
environment:
- ELASTICSEARCH_HOST=elasticsearch
Если между контейнерами существует зависимость и контейнеру elasticsearch требуется некоторое время для запуска, вы можете либо поместить оператор сна в service при запуске, либо использовать решение в 31746182.
Да, «сервис» зависит от elasticsearch. Что касается переменных окружения: нам нужно об этом подумать. У нас есть системы разработки, в которых есть elasticsearch на 127.0.0.1, и наши производственные среды, где elasticsearch — это что-то другое. Поэтому, если мы можем установить разные значения переменных среды для разных систем, это может сработать, особенно если это означает частое изменение нашего yaml в докере.
Еще странно, что иногда разрешение имен работает, а иногда нет. :-С
Похоже, что docker-compose иногда действительно хочет запускаться на pty, а не из скрипта напрямую/обычно. Я предполагаю, что это может быть как-то связано с содержимым контейнеров, которые я запускаю, а не с самим докером.
Во всяком случае, хотите верьте, хотите нет, но у меня работает как (например):
script -q -c "docker-compose up -d \"elasticsearch\"" /dev/null
... решил проблему.
Странно, я знаю, но пока не планирую выяснять, почему. Я просто счастлив, что это работает.
Сценарий и точное сообщение об ошибке могут помочь другим людям помочь вам. Если вы не можете поделиться конкретным кодом, почти всегда есть решение создать минимальный воспроизводимый пример