в docker-entrypoint всякая дичь и софт, который через пакетный менеджер ставится, не всегда ожидает, что он будет запущен, скажем, не от рута.
Это вообще антипатерн, здесь я с вами согласен. Но это проблема не Docker как системы оркестрации контейнеров, а это проблема образов, которые вы используете.
Возможно я смотрю на Docker со своей башни (Kubernetes) где всё хорошо и не замечаю проблем у простых пользователей, которые просто пытаются использовать готовые образы из Docker Hub'а, простите меня за данное допущение.
Чем процесс запущенный в Docker отличается от запуска такого же процесса в системе? — ничем. Чтобы не было проблем с правами достаточно запустить контейнеры с одинаковыми uid/gid. Docker это давно умеет.
По факту я бы советовал рассматривать Docker не как альтернативу LXC, а скорее как альтернативу Systemd.
Обе системы запускают и следят за процессами, то что процесс работает в контейнере — в каком-то смысле второстепенно.
Если честно не знаю как это организованно в docker, но в Kubernetes есть специальная абстракция — Pod, можно сказать это наименьшая единица для запуска workload в кластере. Описать два разных контейнера в одном Pod'е не составляет никакого труда (это всего несколько строк в одном yaml-файле).
Да, работа с Kubernetes ломает привычные принципы и требует определённого уровня сноровки, но научившись "правильно" работать с контейнерами, поверьте, многое становится проще и понятнее.
А в чём проблема запустить php-fpm и nginx в разных контейнерах?
Они всё также могут смотреть в одну директорию и общаться друг с другом через tcp/unix-сокет
Это именно альтернатива докеру и есть, т.е. он предоставляет пользователю знакомый интерфейс для запуска контейнеров в cri-o. В kubernetes тоже есть нативная поддержка cri-o
А как же иммутабельность, автоскейлинг, декларативность, автоматический сбор логов/метрик, возможность создания абстракций для повторяющихся частей вашего деплоймента?
процесс внутри контейнера форкается и плодит потомков
Это не должно быть проблемой, так как в данном случае процесс который форкается как правило без проблем отрабатывает SIGTERM и мочит всех своих потомков.
Ну в Kubernetes эта идея вполне живёт и процветает.
Каждый pod может состоять из нескольких контейнеров работающих в одном сетевом пространстве. Внутри каждого такого контейнера работает отдельный процесс и пишет логи в обычный /dev/stdout и /dev/stderr.
Каждый такой контейнер может быть запущен из отдельного docker image, логи можно посмотреть из любого места: kubectl logs myapp -c nginx.
Это может быть по началу непривычно, но на мой взгляд, очень удобно.
Это сделано намеренно. Контейнеры в linux в т.ч. и LXC, имеют ряд проблем или особенностей (называйте как хотите). Основная причина в том, что если вы убиваете родительский процесс в контейнере, это не означает, что все дочерние процессы завершились правильно, некоторые из них могут продолжать использовать сетевые интерфейсы и блокировать хранилище, в итоге мы имеем повисший в непонятном состоянии контейнер.
Подход "по процессу на контейнер" позволяет избежать данной проблемы и получить всегда гарантированное состояние. Кроме того это позволяет container engine сделить за каждым процессом отдельно, автоматически собирать логи и метрики с него.
для конечного пользователя ничего не изменится
и пошёл играться
да, но он встаёт и работает с Kubernetes без каких либо проблем
Как по мне, нет лучше дашборды чем openshift-console:
Намеренно или нет, но почему-то во всех обзорах её забывают упомянуть.
Это вообще антипатерн, здесь я с вами согласен. Но это проблема не Docker как системы оркестрации контейнеров, а это проблема образов, которые вы используете.
Возможно я смотрю на Docker со своей башни (Kubernetes) где всё хорошо и не замечаю проблем у простых пользователей, которые просто пытаются использовать готовые образы из Docker Hub'а, простите меня за данное допущение.
Почему нет? Разработчик и сам может это сделать.
Времена когда для запуска Kubernetes требовалось потратить половину рабочего дня давно прошли.
Теперь же локальный Kubernetes-кластер можно запустить всего в одну-две команды.
Чем процесс запущенный в Docker отличается от запуска такого же процесса в системе? — ничем. Чтобы не было проблем с правами достаточно запустить контейнеры с одинаковыми uid/gid. Docker это давно умеет.
По факту я бы советовал рассматривать Docker не как альтернативу LXC, а скорее как альтернативу Systemd.
Обе системы запускают и следят за процессами, то что процесс работает в контейнере — в каком-то смысле второстепенно.
Если честно не знаю как это организованно в docker, но в Kubernetes есть специальная абстракция — Pod, можно сказать это наименьшая единица для запуска workload в кластере. Описать два разных контейнера в одном Pod'е не составляет никакого труда (это всего несколько строк в одном yaml-файле).
Да, работа с Kubernetes ломает привычные принципы и требует определённого уровня сноровки, но научившись "правильно" работать с контейнерами, поверьте, многое становится проще и понятнее.
А в чём проблема запустить php-fpm и nginx в разных контейнерах?
Они всё также могут смотреть в одну директорию и общаться друг с другом через tcp/unix-сокет
Это именно альтернатива докеру и есть, т.е. он предоставляет пользователю знакомый интерфейс для запуска контейнеров в cri-o. В kubernetes тоже есть нативная поддержка cri-o
Не смотрели в сторону Nomad?
Не нужно, потому я и говорю что LXC и docker — это два разных инструмента
А как же иммутабельность, автоскейлинг, декларативность, автоматический сбор логов/метрик, возможность создания абстракций для повторяющихся частей вашего деплоймента?
Это не должно быть проблемой, так как в данном случае процесс который форкается как правило без проблем отрабатывает
SIGTERMи мочит всех своих потомков.Кстати, это один из пунктов 12factor app.
Ну в Kubernetes эта идея вполне живёт и процветает.
Каждый pod может состоять из нескольких контейнеров работающих в одном сетевом пространстве. Внутри каждого такого контейнера работает отдельный процесс и пишет логи в обычный /dev/stdout и /dev/stderr.
Каждый такой контейнер может быть запущен из отдельного docker image, логи можно посмотреть из любого места:
kubectl logs myapp -c nginx.Это может быть по началу непривычно, но на мой взгляд, очень удобно.
Я думаю предусмотрели, они просто #противсистемы
Это сделано намеренно. Контейнеры в linux в т.ч. и LXC, имеют ряд проблем или особенностей (называйте как хотите). Основная причина в том, что если вы убиваете родительский процесс в контейнере, это не означает, что все дочерние процессы завершились правильно, некоторые из них могут продолжать использовать сетевые интерфейсы и блокировать хранилище, в итоге мы имеем повисший в непонятном состоянии контейнер.
Подход "по процессу на контейнер" позволяет избежать данной проблемы и получить всегда гарантированное состояние. Кроме того это позволяет container engine сделить за каждым процессом отдельно, автоматически собирать логи и метрики с него.
На самом деле есть вполне бесплатный Katacoda — для любителей сразу потрогать ручками
да это же просто гошный бинарь, обзывайте как хотите:
и проблема решена
Докер и LXC — это всего-лишь два инструмента, которые решают две разные задачи
посмотрите на podman