в смысле микросервис

а потом у них случился контроль версий окружения, а потом они захотели страшно - cgroups, а потом они поняли, что никакая дедупликация памяти у гипервизора не даст такого профита, как какой-нибудь вариант chroot, а еще встал в всю голову вопрос service dicovery

если приложение монолитное, то там ансибл рулит докер ваще, так что вы все правильно делаете

Так я еще час назад выше писал что многие используют докер, хотя их проекты много проще чем даже наши

это глюк :)

и желание попробовать новую технологию

докер нужен когда у тебя 100 инстансов и их надо утилизировать под 90%

ну или еще что-то из этой серии

А можно поподробнее? Я что-то не очень понял кейс.

Вот пришли вы в новую организацию, а там уже давно используется openvz под прод и прод не абы какой, а постоянный tcp от 130тыс-150тыс клиентов, в котором жить и жить ещё до полного перехода на свежее ядро, и параллельно развёрнута половина хостов в lxc с целью слезть с openvz, в будущем. Там в такой тут докер применим, тут нужна именно система управления конфигурациями или менять всё и вся (в условиях ограниченных ресурсов это не так-то просто сделать, бабло решаетЪ).

"в такой"/какой

докер нужен когда у тебя 100 инстансов и их надо утилизировать под 90%

Какая то проблема утилизировать 100 инстансов в амазоне например? Не вижу связи между утилизацией и докером 😐

Профит докера не столько утилизации (это следстиве функций cgroups, которое наследует lxc, который наследует docker), а в возможности фиксировать состояние (версионность, реализованная по аналогии с git).

Так состояние можно зафиксировать и с помощью Ansible + Git

Какая то проблема утилизировать 100 инстансов в амазоне например? Не вижу связи между утилизацией и докером 😐

в амазоне это проще да с автоскейлом.. но это просто один из юзкейсов

Если честно, до сих пор так и не увидел реальное объяснение или юзкейс для применения докера, где бы он не выглядел как лишняя сущность

Я не докеро-хейтер, просто не привык пихать в продакшен все подряд

запаковать говнокод вот идеальный юзкейс

Так состояние можно зафиксировать и с помощью Ansible + Git

Вот выше сказано - запаковать говнокод, и зафискировать его с нумером. Ансибл не фиксирует состояние, он фиксирует конфигурацию, что-бы зафиксировать с его помощью стостояние, надо всё окружение тоже вести у себя (например, срезы репозиториев (deb,rpm) с пакетами на момент времени).

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

Но можно ли сделать тоже самое без докера?

Ведь LXC контейнер это просто директория с файлами.

Ansible + Git + Tar

хмм надо побольше про lxc почитать

Можно, можно снапшотами на fs можно tar'ом.

Вооот. Так стоит ли тащить целый докер ради куска говнокода?

ну в докере это "conf-managment+git+tar" уже решено, и возможно даже лучшим образом, но под это надо общее окружение (как минимум ядро с cgroups и совместимый lxc).

У вас на каждом проде разное ядро и несовместимые LXC?

🙃

не у меня - у жизни, она такая сука разнообразная ))

Так мы шо, пришли в итоге к тому, что надо только ансибл с гитом?

😀

В идеальном мире с красными велосипедами, я про него

если всё как в жизни - то да ))

или проектировать на века ))

Когда там квантовые пк дома у каждого?

А если смотреть в рамках пары машин с кучей разных приложений, то anisble + lxc + git?

пары машин? Речь о железках с 48core/1TiB/100TiB? Это я к тому, что ресурсы решают

на таких железках может быть за 100 контейнеров

nginx 1.8.x -> 1.10.0

Ага, о здоровых таких машинах с конями. (Я про идеальное средство виртуализации сейчас)

Антон, LXC это не виртуализация как бы

ээээ

Внкзапне

Ага

Добрый день, есть ли еще группы для фронтеншиков

/stat@comstatbot

comstatbot.xyz/chat/-1001030317489

ну если у вас бд под которую надо 1TiB/10TiB и конкуренция будь здоров, то тут вам не до контейнеров будет. ))

/stat@comstatbot

comstatbot.xyz/chat/-1001030317489

/stat@comstatbot

comstatbot.xyz/chat/-1001030317489

Вообще, с точки изоляции процессов lxc начал свою путь на полку истории когда в systemd появился nspawn и скорее всего docker тоже заменить внутри lxc на nspawn

О знаете какие грабли у нас были с LXC

Вспомнил

Ленард уже везде пустил свои корни.

Были у нас контейнеры с php fpm

И на хост машине тоже был. Ну типа легаси

Так вот когда пытались рестартануть fpm на хост машине, оно видело процессы fpm которые были внутри контейнеров но убить их не могло

Ну сразу - ССЗБ ))

Вот это жопа была, песец

Причем стало понятно что именно из-за этого далеко не сразу

ну решается-же просто - отдельный юзер, не?

отдельных юзер для php-fpm на хосте

У нас же ансибл. Везде один пользак 😂

Да мы в итоге костылем залепили - поставили тайм-аут 1 сек в апстарте

У нас же ансибл. Везде один пользак 😂

а как ансибл и один пользователь для fpm связаны?

Потом спустя какое то время избавились от пхп на хосте

а как ансибл и один пользователь для fpm связаны?

Ну роль для раскатки пхп то одна и костылей в ней не хотелось делать

эм... можно было переменной хоста в для php-fpm сделать, это-же template для конфига в pool.d

У нас не предполагалось что это изменяемое значение

Меньше переменных - проще поддержка плейбуков

А то я как то видел плейбуки, это, простите меня, какое то мета программирование

Я за явный декларативный подход

И все плейбуки из galaxy мне напоминают тоже самое

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

У нас тоже есть роль nginx и она его ставит, делает базовые на настройки. Но виртуалхосты не трогает

Слишком разные они могут быть

И как тогда вы виртуалхостами рулите? ручками что-ли?

А это проблема?) 2 команды всего.