Деплоим мы все же с помощью капистрано. Под него много готовых гемов есть на все случаи жизни. А переписывать на плейбуки лень.

Но вообще я рад, что хотябы кто-то разделяет мое мнение по докеру ?

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

Ощутимо проще в плане Get Started

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

Не совсем понял где сложность в интеграции сервисов между собой?

Если все сделано через ансибль то он легко впихивает обновленные конфиги в нужные ноды на основе inventory файла

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

ОКРП - это все же не из психологии, а из нейробиологии скорей ;)

У нас нигде в репозитории ансибля не встретится захардкоженый IP адрес. Все вычисляется через роли и т.д.

И это я считаю залог успеха. Просто добавил в inventory Хосты. Запустил плейбук и готово

Все тоже самое с AWS.

кто хорошо знает баш? )))

я не очень хорошо, но иногда пишу на оном. может помогу?

У нас нигде в репозитории ансибля не встретится захардкоженый IP адрес. Все вычисляется через роли и т.д.

Прям сразу захотелось посмотреть, магия ;)

Так а что магия? Просто все поделено на группы и все.

В nginx апстрим составляется через j2 шаблон

И все везде в том же духе.

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

А т.к. при использовании aws нет смысла хардкодить IP т.к. запвришься менять, то их у нас там действительно нет

> Dmitrii Не совсем понял где сложность в интеграции сервисов между собой? я про взаимозависимость, когда для изменения параметра в одном серивсе надо поменять еще в 7ми, тогда в ансибле надо мутить абстракции для этого, которые вначале терпимые, а потом начинают требовать все больше и больше внимания

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

Вот тут бы как раз докер и помог :)

А у меня наоборот, в переменных на хост заданы и накатка ip-адресов и маршруты и имена хостов (своя виртуализация/изоляция, не aws/digitalocean/azure)

> Dmitrii Не совсем понял где сложность в интеграции сервисов между собой? я про взаимозависимость, когда для изменения параметра в одном серивсе надо поменять еще в 7ми, тогда в ансибле надо мутить абстракции для этого, которые вначале терпимые, а потом начинают требовать все больше и больше внимания

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

да, я в курсе

А если еще использовать теги, то как я писал выше - обновление параметра будет занимать 10 секунд

Вот тут бы как раз докер и помог :)

Это чем же?

и это мейнтейнить сложно, когда проект большой

накатить везде docker и наступит счастье?

но пока у вас проект не большой, то мне можно верить только на слово :)

но пока у вас проект не большой, то мне можно верить только на слово :)

Большой и небольшой довольно расплывчатые понятия

я там ввел критерий - больше 7ми сервисов завязанных серьезно друг на друга

не MVC приложение -> кэш -> база а что-то понавороченней

Так это. Может это проблема "микоосервисной архитектуры" и кто то "переупоролся" ею?)

Если одни хосты в openvz, другие в lxc, третьи в azure, четвёртые в железе, пятые на винде, то какой профит тут от докера? К пример?

у

Это чем же?

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

нифига он не изолирует, как минимум он упарывается на openvz и lxc

ядра разные

> Dmitrii Может это проблема "микоосервисной архитектуры" да и именно поэтому Докер и сделали, как решение этой проблемы

не MVC приложение -> кэш -> база а что-то понавороченней

Ну вот есть у нас приложение, докогенкратор, редис, генератор формул, база, балансер.

Уже 6 сущностей

нифига он не изолирует, как минимум он упарывается на openvz и lxc

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

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

под сервисом я имею в виду отдельную изолированную сущность

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

а потом у них случился контроль версий окружения, а потом они захотели страшно - 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

Вспомнил

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