Комментарии 30
Позволю себе перефразировать последний абзац: есть много способов обойтись без контейнера и оставить SSH-сервер, адекватную архитектуру системы, сохранив при этом время. Ничего УЖАСНОГО, разные ситуации требуют разных решений.
Или даже: смотрите какие костыли можно изобрести, чтобы не ставить ссш.
Банальное: «Когда у тебя в руках молоток, все задачи кажутся гвоздями.».
По делу: ставить ssh сервер внутри контейнера — вот это костыль, поскольку противоречит идеологии докера.
По делу: ставить ssh сервер внутри контейнера — вот это костыль, поскольку противоречит идеологии докера.
Предствьте себе микросервисы в контейнерах и 50-100 контейнеров (однопроцессных) на одном хосте или вируталке…
Зачем вам еще 100-50 супервайзеров и 100-50 ssshd процессов на этой виртуалке? ;)) Статья очень правильная если вы используете docker для написания микросервисов. Истинных Microservices.;)
Но Docker можно использовать и для дургих архитектурных стилей или задачь… тогда нет ничего страшного в sshd
Зачем вам еще 100-50 супервайзеров и 100-50 ssshd процессов на этой виртуалке? ;)) Статья очень правильная если вы используете docker для написания микросервисов. Истинных Microservices.;)
Но Docker можно использовать и для дургих архитектурных стилей или задачь… тогда нет ничего страшного в sshd
Хорошая статья. Отдельное спасибо за то, что не сильно категоричны.
А чем плох способ подключаться через attach, а в качестве начального скрипта контейнера запускать /bin/bash? (это вопроc)
Докер управляет и следит за одним процессом. Если вы хотите управлять несколькими процессами внутри контейнера — вам понадобится что-то типа Monit или Supervisor. Их тоже нужно добавить в контейнер. Таким образом мы превращаем простую концепцию «один контейнер для одной задачи» во что-то сложное, что нужно строить, обновлять, управлять, поддерживать.
Postfix — почтовая система. Сам бог велел его запихать в контейнер. Весь, целиком, со всеми десятками процессов, которые порождает master при подключениях, время от времени и при прочих условиях.
То же самое cyrus imap — master и куча процессов, которые он при необходимости порождает
firebird в режиме classic — опять же, супервизор и куча воркеров
nginx — кому-то надо объяснять?
uwsgi — вообще есть режим императора, в котором процесс-супервизор запускает или убивает мастер, который уже порождает воркеров — мало этого, мастеры могут стартовать от имени разных учётных записей (на супервизоре должна быть капабилити «менять uid»).
Задача != процесс. Задача может быть в виде нескольких процессов, каждый из которых может состоять из нескольких потоков.
nsenter это маленькая утилита, позволяющая вам попадать внутрь пространств имён (namespaces). Строго говоря, она может как входить в уже существующие пространства имён, так и запускать процессы в новых пространствах имён. «Что это вообще за пространства имён, о которых мы тут говорим?». Это важная концепция, связанная с Docker-контейнерами, позволяющая им быть независимыми друг от друга и от родительской операционной системы. Если не углубляться в детали: с помощью nsenter вы можете получить консольный доступ к существующему контейнеру, даже если внутри него нет SSH-сервера.
можно же было сказать прямо: Docker использует для работы Linux Namespaces, а nsenter — это низкоуровневая утилита для взаимодействия с этими namespaces
кстати, это не единственное средство. Например, с netns можно управляться непосредственно с помощью утилиты ip пакета iproute2
Стоило ли писать такую тираду для того, чтобы в статью добавить одно слово? Понятно что должно быть так:
Если вы хотите управлять несколькими независимыми процессами внутри контейнера — вам понадобится что-то типа Monit или Supervisor.Если у вас в контейнере куча процессов, но один из них главный и «следит за порядком», то больших отличий от ситуации, когда у вас там всего один процесс нету. А вот когда их там много и они ничего друг о друге не знают — тогда ой.
Отлично. SSH нам незачем, если можно влезать в чужие namespace. Получается, я таким образом могу влезать в те контейнеры, к внутренностям которых мне изначально никто доступа не давал?
А что вы делаете на чужом сервере с Docker?
Docker не замена виртуалок, а продвинутый чрут, если угодно.
Так что нет, не можете, потому что вас на сервер не пустят.
Docker не замена виртуалок, а продвинутый чрут, если угодно.
Так что нет, не можете, потому что вас на сервер не пустят.
Прошу прощения, но я ни слова не сказал про чужие сервера.
А если вы на сервере с Docker, то это — ваш сервер и какое еще «влезать в те контейнеры, к внутренностям которых мне изначально никто доступа не давал».
Вы просто не понимаете что такое Docker и зачем он нужен.
Вы просто не понимаете что такое Docker и зачем он нужен.
Да и более того, flint, вы можете с таким же успехом в OpenVZ-контейнеры влезать. Собственно, любой хостер может влезть в вашу «виртуалку» на OpenVZ, если вы ее используете, и ничто его не остановит.
Вот это меня и печалит: вроде бы и новое поколение контейнеров (если предыдущими считать OVZ или джейлы FreeBSD), а проблема так и не решена. Даже более того, раз появляются подобные инструменты, то это как бы и не проблема, а фича. Ernillew в общем, прав, я не очень понимаю, почему вокруг Docker стоит такой шум.
Я вам больше скажу, почему столько шума я тоже не понимаю. Правда я все собираюсь посмотреть Docker в варианте CoreOS, пока не собрался, может тогда пойму. Меня самого lxc вполне устраивает, после того ужаса, что был когда-то в OpenVZ(предупреждаю защитников OpenVZ, я его не видел долго и не хочу, мне хватило).
Я вижу применения докера на машинах разработчиков и на тестовых серверах где разрабы развлекаются, по крайней мере пока так вижу.
Я вижу применения докера на машинах разработчиков и на тестовых серверах где разрабы развлекаются, по крайней мере пока так вижу.
Я смотрел на Docker больше как на средство дистрибуции не пакетов даже, а системы из нескольких связанных процессов (не Docker-way, само собой, но как способ упростить нетривиальный деплой). Собственно, мой первый вопрос был вызван тем, что по какой-то причине я был свято убежден, что с приходом libcontainer проблему подключения к любому контейнеру начали каким-то образом решать. Ну окей, не lxc-attach, так nsenter :(
Ну я тоже не особо понимаю, но, в целом, Docker предоставляет возможность распространять ваше приложение, или тестовое окружение, без необходимости «засорять» систему, либо ставить какие-то другие версии библиотек. Лично я вижу в Docker, во-первых, систему, с помощью которой можно изолировать один сервис от другого, причем достаточно умную систему, которая не пожирает память на диске для каждого приложения, во-вторых, это такой удобный chroot, когда вам нужно единоразово что-то запустить типа как в виртуалке, но не в виртуалке, а в-третьих, многие приложения и дистрибутивы (в общем, контейнеры) собраны в онлайн-дистрибутиве, и их не нужно искать и устанавливать вручную.
У меня нет админского опыта (я разработчик), возможно что-то делал неправильно, но в моем случае мне показалось, что так просто избавиться от засорения системы с помощью Docker'а не получается. Такая ситуация: приложение с большим количеством зависимостей, регулярно обновляющихся. Обновить их в одном контейнере — задача несложная. Однако если контейнер нужно разворачивать еще где-то еще (скажем, для масштабирования), то приходится мейнтейнить еще и Dockerfile с реестром, то есть делать одно и то же в разных местах. Если держать эти зависимости в прямо в контейнерах, то при откате версии в случае беды, надо бы накатить пропущенные security-апдейты. После пары таких случаев подмывает держать их на монтируемом томе. А и данные нужно где-то хранить, подключаешь другой том. И сидишь, думаешь, что что-то идет не так: вроде и контейнеризация, а возни только прибавилось.
Ответ на описанные беды — запуск docker из под linux container runtime.
Волшебный ключ "-e lxc" можно добавить в /etc/default/docker
Потом:
Ну а дальше docker_attach <container_name> и вот он полноценный баш.
Плюс, гибкое управление сетью, ресурсами, мониторинг и прочите плюшки lxc.
Волшебный ключ "-e lxc" можно добавить в /etc/default/docker
Потом:
~/.bashrc добавляем алиас:
docker_attach() {
lxc-attach -n `docker inspect $1 | grep -i '"Id"' | sed -r "s/.*([0-9a-z]{64}).*/\1/g"` /bin/bash
}
Ну а дальше docker_attach <container_name> и вот он полноценный баш.
Плюс, гибкое управление сетью, ресурсами, мониторинг и прочите плюшки lxc.
Да, но сам докер больше не сфокусирован на LXC, они больше надеются на свой libcontainer.
libcontainer не что иное как собственная библиотека доступа к Linux Container для уменьшения зависимостей.
И на данном этапе развития проекта я не вижу причин не использовать «родные lxc интерфейсы», а Вы?
Тем более если речь идет про development или testing окружение.
И, повторюсь, lxc — поможет избежать ломки при переходе контейнеризации от систем к службам.
А дальше, как мне кажется, либо человек научиться работать с Докер не заглядывая внутрь контейнера, либо не научиться вообще :)
И на данном этапе развития проекта я не вижу причин не использовать «родные lxc интерфейсы», а Вы?
Тем более если речь идет про development или testing окружение.
И, повторюсь, lxc — поможет избежать ломки при переходе контейнеризации от систем к службам.
А дальше, как мне кажется, либо человек научиться работать с Докер не заглядывая внутрь контейнера, либо не научиться вообще :)
Как это «libcontainer не что иное как собственная библиотека доступа к Linux Container»? Вот же:
blog.docker.com/wp-content/uploads/2014/03/docker-execdriver-diagram.png
blog.docker.com/wp-content/uploads/2014/03/docker-execdriver-diagram.png
Вы ошибаетесь. с последними версиями докера, ваше решение не сработает.
А что есть -e lxc?
Пора уже заводить хаб —
docker.
В docker 1.3 есть exec
docker exec -i -t some-cool-container bash
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему вам не нужен sshd в Docker-контейнере