кто-нибудь юзает docker с init, как полноценную виртуалку?

Есть большой шанс плодить defunct и zombie процессы - тут дядя более детально описывает.

Возиться с каждым контейнером индивидуально - идея плохая, лучше сразу использовать Swarm/Meson/Kubernetes, чтобы всё дело сразу стало scalable

Можешь не пользоваться докером — не пользуйся. Если уже умеешь удобно управлять виртуалками (OpenVZ/LXC/KVM), то докер нафиг не сдался.

Единственное, где он на 100% на своем месте — попробовать новый софт, у которого есть свой образ на докерхабе. Этакий пакетный менеджер, не гадящий в основную систему: не надо ни париться с версиями gcc и проч., и в хосте ничего не отвалится.

На продакшене я вообще не слышал про него добрых слов, главная претензия даже не в том, удобно/неудобно микросервисы использовать, а в обновлениях.

На рабочий сервер в норме нужно постоянно (раз в неделю и чаще) накатывать security-fix-ы, тогда никакой шеллшок и хартблид не страшны, и это делается средствами дистрибутива.

А с докером как? Каждая виртуалка — свой статически собранный образ. Микрообновление в libc? Изволь пересобрать все свои как-бы-виртуалки. Никого не забудь, удостоверься, что никто после обновы не отвалился, скушай еще места на диске (образы-то версионные, старая версия на месте). Мрак, в общем.

Если тебе интересны контейнеры с init и без пересоздания при изменениях, смотри в сторону lxc. Докер всё-таки больше заточен под неизменяемые контейнеры без инита.

Единственное куда я смог приткнуть докер - это «одноразовые виртуалки». Поясняю - есть CI. Прилетает коммит - запускается виртуалка, собирается новая версия софта, запускаются тесты.

Новые коммит - запускается новая виртуалка, кеш чистится, всё по новой.

Так докер для таких кейсов как раз идеален.

Ну так в этом всё и дело. Мне кажется ТС пытается использовать ужа как ежа :-)

Не, может есть надстройки над докером, которые позволяют им рулить почти как LXC. Но тут уже высказывали мысль, что если ты постоянно лезешь внутрь виртуалки докера - значит ты что-то делаешь не так.

лучше сразу использовать Swarm/Meson/Kubernetes

Это я и пытаюсь делать с salt... Я очень-очень долго гуглил пытаясь найти какое-то сравнение между этими всеми вещами, но нигде не было ничего кроме бла-бла-бла. Я пока остановился на salt.

Если тебе интересны контейнеры с init и без пересоздания при изменениях, смотри в сторону lxc

С lxc знаком, у меня нет добрых слов в его пользу. Это какое-то бажное недоразумение в обмнимку с исходниками которого я провёл много времени. На фоне lxc докер просто венец творения — удобное управление, готовые образы и много-много чего ещё. Или, может, ты имеешь в виду какую-то надстрочку над lxc/libcgroup?

Но, да, суть верная — я пытаюсь использовать докер как lxc. И у меня получается. Теперь детали.

Как anonymous (26.02.2016 19:30:32) правильно заметил, с обновлениями какой-то трешак выходит если делать всё как докер велит. Я же пока делаю так: минимальный образ поверх которого я запускаю контейнер и в нём уже ставлю всё ПО. При таком раскладе «базовый» образ бесполезен потому что через месяц обновлений разница будет практически 100%.

Если уже умеешь удобно управлять виртуалками (OpenVZ/LXC/KVM)

Не умею :( Щупал vagrant и ещё парочку вещей, не видел ничего удобного чтобы можно было подключать стораджы, управлять пробросом портами итп. Но да, чёрт возьми, я хочу полноценную виртуалку! У меня salt всё отлично делает — установка, настройка, обновления, ввод новых виртуалок. Так же есть функционал по мониторингу и управлением всякими haproxy итп. Т.е. проброс трафика, автоматическое масштабирование приложений итд итп.

Ребята, спасибо что ответили, я хотя бы убедился что мне не «хочется чего-то странного».

Я очень-очень долго гуглил пытаясь найти какое-то сравнение между этими всеми вещами, но нигде не было ничего кроме бла-бла-бла.

вот вроде неплохо расписано. Salt, похоже, немного не для того - оно ими управлять умеет, но, к примеру, разносить по разным нодам и квоты устанавливать не умеет, верно?

Это какое-то бажное недоразумение в обмнимку с исходниками которого я провёл много времени.

Тут важно насколько давно. Ничего не стоит на месте.

Или, может, ты имеешь в виду какую-то надстрочку над lxc/libcgroup?

На самом деле мы таки используем надстройку, но она написана внутри компании и её нет (возможно пока, тут не могу ничего сказать) в опенсорсе. Кроме того вся инфраструктура крутится на zfs(ZOL), а это подойдёт не всем.

С lxc знаком, у меня нет добрых слов в его пользу. Это какое-то бажное недоразумение в обмнимку с исходниками которого я провёл много времени.

Чего? В centos7 держу кучу контейнеров lxc, безбажная, стабильная, удобная штука. Немного непривычно устроено ограничение ресурсов, но это дело привычки.

systemd-nspawn пробовал?

разносить по разным нодам и квоты устанавливать не умеет, верно?

Эм, смотря как к этому относится. С точки зрения разработчиков salt «всё умеет, вот тебе куча модулей, вот message bus, вот документация, недостающий функционал дописывается очень просто!». На сколько оно из коробки готово я не знаю. Скорее всего, нужен большой конфиг (который я сейчас и пишу) в котором определяешь события, триггеры этих событий и реакцию на них. Там есть ещё встроенная БД (pillar) из которой можно брать данные для принятия решений. А-ля «дай мне тачку в таком-то датацентре с таким-то процом и чтобы с ssd». Я за неделю даже близко не разобрался как это работает :(

А что имеешь в виду под «квотами»?

У тебя недостаток смузи в организме? Возьми обычный lxc и не мучай себя и других.

systemd-nspawn пробовал?

А была такая идея... Просто как бы докер делает тоже самое, но уже с готовыми образами и даёт удобный CLI по работе с ними. Надо ли изобретать велосипед?

Я же пока делаю так: минимальный образ поверх которого я запускаю контейнер и в нём уже ставлю всё ПО.

Удачи, чо. Докер же не про это. Вообще наконец-то народ начал трезветь и понимать что докер им не нужен. И джвух лет не прошло.

Я за неделю даже близко не разобрался как это работает :(

То есть, по уровню поддержки это как тот «докер на баше в 100 строк».

Не знаю, уместно ли здесь тащить «дай мне тачку в таком-то датацентре» - зачем в это вообще влазить? В кубернетесе можно сделть тег ноде и далее по тегам фильтровать подходящий ресурс (и совершенно неважно, где эти ноды и как они называются)

А что имеешь в виду под «квотами»?

Не жрать более 100 Мб памяти, иначе рестарт, к примеру.

То есть, по уровню поддержки это как тот «докер на баше в 100 строк».

Не очень понял мысль. Ты про мои навыки? Новый для меня инструмент, нужно время на изучение. Но это не значит что моя поддержка плохая. Я пока не разберусь и не оттестирую в продакшн не пущу.

и совершенно неважно, где эти ноды и как они называются

Я тут не согласен, часто важно чтобы ноды были, к примеру, в разных ДЦ или на разных континентах и трафик роутился на ближайший инстанс.

Не жрать более 100 Мб памяти, иначе рестарт, к примеру.

Легко, причём, силами самого докера :).

А что тебе нужно от такого управления? Я ненастоящий сварщик, пользовался Ansible, и у меня только простые задачи были: создать виртуалку и накатить на нее приложение.

1) Создать виртуалку, строго вручную, lxc-create / lxc-start.

2) Поставить mysql/php/git, создать каталоги для логов, добавить пользователя и создать схему базы (выполнить cat init.sql | mysql), скачать исходники (вызвать git pull), перезапустить веб-сервер. Для каждого действия есть строчка в конфиге Ansible, т.е. получается небольшой playbook, как именно настраиваются внутренности образа. Добавляем машину в список хостов, запускаем Ansible, приложение работает. Если понадобится сделать второй такой же образ, то тот же самый конфиг используется второй раз, только с другим адресом виртуалки, больше ничего менять не понадобится.

Проброс портов на уже готовой системе тоже делается через ansible, судя по докам, просто. Обновления тоже идут отдельной периодической задачей.

Так что если уже есть доступные машины, Ansible (и, видимо, Salt) хорошо ладят с их содержимым.

А вот как автоматизированно запускать и гасить виртуалки, и перекидывать нагрузки с одной на другую — понятия не имею, если нужно именно это, то ничего не подскажу. По идее, похоже на Amazon-овское облако, только в локальной сети. На эту роль позиционируется OpenShift Origin, только его я так и не осилил. Кроме того, Red Hat сперва создали эту штуковину, а теперь скрещивают ее с докером, так что все совсем запутано, как оно работает.

А их и нет нигде, надо самим все пробовать.

Удачи, чо. Докер же не про это. Вообще наконец-то народ начал трезветь и понимать что докер им не нужен. И джвух лет не прошло.

Народ сразу понял про что докер и пользует его по назначению.

Новый для меня инструмент, нужно время на изучение. Но это не значит что моя поддержка плохая

Не проще ли использовать опыт гугла и его инструменты? Но это риторический вопрос, не камень в огород. Пусть цветут тысячи цветов.

Я тут не согласен, часто важно чтобы ноды были, к примеру, в разных ДЦ

В разных? Это для дополнительной надежности? Ну ок, тогда все равно конкретный ДЦ не очень важен - главное чтобы у ноды лейбл был не region=us-west, к примеру

Да использую, брат жив. Правда для разработки и для CI как кеш, для production докер не нужен.

По идее, похоже на Amazon-овское облако, только в локальной сети. На эту роль позиционируется OpenShift Origin, только его я так и не осилил. Кроме того, Red Hat сперва создали эту штуковину, а теперь скрещивают ее с докером, так что все совсем запутано, как оно работает.

В опеншифте v2 были виртуалки, в v3 - только контейнеры. А работает оно так же как и kubernetes, только приятности всякие типа builds, deployments, imagestreams и прочее.

Мне не нравится концепция одноразовых однозадачных контейнеров. Я поэтому экспериментирую с salt и dumb-init внутри контейнера. Кто-нибудь ещё так делает? Ну, ясен пень, делает, но есть ли какие-либо разумные доводы против этого?

Ну то есть тебе нужна обычная виртуалочка, а ты мучаешься с каким-то модным докером, нафига?! Докер по моему мнению лучше всего себя показывает в облаке с масштабированием и прочими плюшками.

обычно если надо в одном докер много сервисов, их пускают через supervisord.

Ну используй не докер а сразу lxc

Спасибо, тогда попробую еще пару подходов к этому снаряду.

lxc-create

На сколько помню, ему нужно указать образ который надо делать. Но, да, так я и жил до докера и не было у меня проблем ни с lxc, ни с qemu :). Я тупо делал темплейт руками и дальше bash-скриптами натягивал типовые конфиги. Щас за меня это делает salt.

Я понял, я слишком много времени трачу на фигню. Для нашего проекта с двумя серверами не важно брать systemd-nspawn, lxc, docker или что-то более тяжёлое на основе qemu или xen.

какую-то надстрочку над lxc/libcgroup?

libvirt, не? Хотя там поддержка LXC объявлена устаревшей, может быть больно, да...

На сколько помню, ему нужно указать образ который надо делать.

Совсем дурной штоле? В /usr/share/lxc/template давно заглядывал?

$ lxc-create -n test -t debian
$ lxc-create -n test -t centos
$ lxc-create -n test -t gentoo

Алсо есть -t download. А ещё есть lxd для любителей всего блестящего.

Не проще ли использовать опыт гугла и его инструменты?

Я забросил kubernetes очень быстро, когда наткнулся на кривые скрипты с неверными путями от туториала по развёртыванию демо-кластера на локальной тачке. Пропустить такое можно было только вообще не тестируя изменения. Как бы я понимаю что разрабам пофиг на такое, но осадочек-то остался.

Кроме этого, я не понимаю что делает kubernetes и нужно ли к нему что-то ещё. Что он делает? :).В папке kubernetes/cluster/saltbase/ находится конфиги для... salt. Значит ли это что kubernetes чего-то не умеет что умеет salt/ansible/etc? Т.е., kubernetes это продвинутая запускалка докера, но для настройки тачек и построения образов всё равно нужны сторонние средства? Или это просто демо?

libvirt

По какой-то причине я отвергнул это решение. Возможно, потому что много лет назад я ковырялся в этой помойке, это ад. Они, короче, то что решается баш-скриптом засовывали в си-код. И там был секас с форматированием командной строки, вызовов команды, ожиданием завершения, парсингом выхлопа. На сях, мде. Что-то типа systemd, только хуже. Объём лапшекода был феерический. С тех пор недолюбливаю я эту тулзу.

libvirt

По какой-то причине я отвергнул это решение. Возможно, потому что много лет назад я ковырялся в этой помойке, это ад. Они, короче, то что решается баш-скриптом засовывали в си-код. И там был секас с форматированием командной строки, вызовов команды, ожиданием завершения, парсингом выхлопа. На сях, мде. Что-то типа systemd, только хуже. Объём лапшекода был феерический. С тех пор недолюбливаю я эту тулзу.

И ловить там 100500 багов, проводить вечера в gdb, оно точно надо?

Что он делает? :)

Он управляет контейнерами и нодами, на которых контейнеры крутятся. Упала нода - перенести на новую. Запустить три апача и повесить на них haproxy как лоад-балансер. Вышел новый таг контейнера - по очереди гасить апачи и выкатывать новую версию. И прочее и прочее и прочее.

но для настройки тачек и построения образов всё равно нужны сторонние средства?

Да, контейнеры он не строит - это оркестратор.
Опеншифт в основном все это перекрывает - например, вместо salt и прочих чудес там source2image

Я просто сомневаюсь что стоит пилить свой оркестратор на salt, их-то уже штук 5 широкоиспользуемых.

Я просто сомневаюсь что стоит пилить свой оркестратор на salt

Я тоже :( Просто хотелось иметь одну тулзу, а не целый зоопарк.

А на освоение kubernetes для простого сценария сколько примерно уйдёт времени? У меня было подозрение что пара недель минимум.

Сценарий: два сервака в разных ДЦ, один мастер, другой hot standby с репликацией базы на него (остальные вещи типа веб-сервера не имеют состояния). В случае недоступности одного переключиться на запасной (у них failover IP адрес, трафик можно переключать скриптом через web api хостера). Когда упавший сервер поднимется то его сделать hot standby и изменить направление репликации.

Ради двух серваков и одного проекта не стоит, вероятно.

Стоит поразмыслить когда ноды перевалят за десятку, а девелоперы попросят prod-staging-test окружения, а там и blue-green на проде понадобится.

prod-staging-test окружения

Оно уже есть, мне его надо с хероку перенести на свой сервак. Причём, часто требуется поднятие новых окружений. Скажем, чтобы стажёр мог поиграться или чтобы обкатать отдельную фичу. Поэтому физических сервака как бы два, а виртуалок на нём хватает. Но репликация и failover нужно только для прода. Плюс будет в том или ином виде третий сервак для мониторинга и управления.

Причём, часто требуется поднятие новых окружений

В том же кубернетесе это удобно сделано в виде namespaces, если что. С их помощью удобно сделано обнаружение сервисов через SkyDNS - например, контейнер backend может обратиться к контейнеру с postgres сразу по DNS, без жонглирования айпишниками - эту фишку тоже можно несложно развернуть в кастомном PaaS

Просто как бы докер делает тоже самое

Если я правильно понял по этому треду - как раз-таки нет :) скорей lxc делает то же самое.

А зачем тебе докер-то? Модно?

А я думал, он под scalability сделан... Пришло к тебе 100000 человек, поднял автоматом 150 nginx нод. Ушли эти люди - опустил не нужные тебе ноды. И не платишь лишнего облачному провайдеру. Как-то так...

Как-то так...

Только с костылями расширениями. Но у него таки дохрена расширений, так что уже, наверно, и нет задач которые бы оно не решало. Вопрос какой ценой :)

Так это к любым контейнерам относится. При таком использовании не обязательно брать именно докер. Удобство конкретно докера в его популярности - вокруг него образовалось большое активное сообщество, которое много полезностей запилило.

скорей lxc делает то же самое.

Окей, я уже поставил lxd и экспериментирую. Удивительно, но оно скачало образо, поставило его, запустило и мне даже ни разу не пришлось пока лезть в исходники чтобы смотреть почему оно не работает... Честно, я удивлён.

Openvz это умело десять лет назад :) Правда, с современными дистрибутивами, по моему опыту, у них все не очень хорошо, поэтому кручу его на шестой центоси.

А уж virtuozo-то сколько лет назад умело... :)

Блин, на последней бете убунте lxc поломан — контейнеры стартуют, но не останавливаются, lxc info --show-log test показывает ошибки типа https://github.com/lxc/lxd/issues/1148 . Причём, в справке оно говорит что --show-log выводит только последние 100 записей, но на самом деле сыпит всеми десятью тысячами. Можно, конечно, говорить, что виновата убунта, но, здаётся мне что просто lxd делали те же люди что и libcgroups.

Обложился сырцами, strace, lsof и прочим :(

Вот почитай http://developerblog.redhat.com/2016/02/24/10-things-to-avoid-in-docker-conta...

многое проясниться