Для остановки Docker / bin / sh потребовалось 10 секунд

#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