#docker #docker-compose
#docker #docker-compose
Вопрос:
Я хочу создать контейнер docker, работающий как демон для разработки моей программы Go, и смонтировать в него исходный код с помощью volume
. Итак, любые go
инструменты запускаются внутри контейнера. Я запускаю контейнер с помощью docker-compose с tty: true
, stdin_open: true
и переопределяю entrypoint: /bin/sh
.
Все работает хорошо, за исключением того, что для остановки контейнера потребовалось 10 секунд. После некоторого поиска проблема, вызванная /bin/sh
, выполняется как PID 1 и не обрабатывается SIGTERM
должным образом. Я нашел такие инструменты, как dumb-init и tini, которые запускаются как PID 1.
Теперь мой файл Dockerfile содержит
ENTRYPOINT ["/usr/bin/dumb-init", "--"]
CMD ["/bin/sh"]
Я думаю, что я что-то пропустил, потому что для остановки контейнера все еще потребовалось 10 секунд. Кто-нибудь может помочь с этим?
Комментарии:
1. Как вы останавливаете контейнер? Ввод Ctrl-D в командной строке немедленно остановит оболочку.
2. Я запускаю контейнер с помощью
docker-compose up -d
и ввожу контейнер с помощьюdocker-compose exec <service> sh
, да, Ctrl-D завершит работу оболочки, но контейнер все еще запущен. Я останавливаю контейнер с помощьюdocker-compose stop
.3. На самом деле это не большая проблема, поскольку изменение
Dockerfile
иdocker-compose.yml
происходит не так часто, поэтому вызовdocker-compose up -d
выполняется всего несколько раз, и моя повседневная команда — этоgo
tools внутри контейнера.4. Таким образом, вы фактически запускаете две оболочки в контейнере, одна запускается при запуске контейнера, а вторая — при запуске в него.
5. Я не знаю, но, насколько я понимаю, запуск
docker-compose
не дает вам оболочку в контейнере, только после запуска в нее я получаю оболочку. Так что я думаю, что это всего лишь 1 оболочка.
Ответ №1:
Попробуйте добавить свой собственный entry-point
скрипт, который может обрабатывать все signals
и передавать дочерним процессам внутри контейнера. Таким образом, вы можете корректно остановить свои службы и, более того, позаботиться о zombie
процессах при неожиданном завершении работы контейнеров. https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem