Evgeny
сорри
Evgeny
легко поднимать\опускать контейнеры и ничего перенастраивать не надо. честная докер идеология мс
Dmitrii
Хороший юз кейс имхо это си демоны
Dmitrii
И сколько времени у вас уходит на полный цикл замены старого контейнера на новый?
Dmitrii
Включая его сборку, подготовку, замену, изменения в апстриме?
Evgeny
до стейджа в зависимости от массовости коммита до 30 минут
Evgeny
самое быстрое - 4 минуты
Dmitrii
Это все очень долго. Если вся конфигурация зафиксирована в ансмбле или где-то еще, то я так же как и вы имею идентичный стейт везде. Только сделать я могу это за 10 секунд потому что таски у меня протегированы и нет смысла запускать их все.
Evgeny
10 секунд вместе со всеми тестами?
Evgeny
Но как?
Evgeny
у меня только юниттесты прогоняются до минуты. потом еще интеграционные и шорт-бизнес-кейс лист
Anton
Он про изменение конфигурации онли
Evgeny
Тогда я не совсем понимаю. Изменение конфигурации != замена старого контейнера на новый
Evgeny
Я говорю про цикл который отрабатывает при коммите нового кода в ветку
Anton
Если я правильно понимаю, то он утверждает, что обновление контейнера на куче машин занимает больше времени, чем просто обновление конфигурации через ансибл
Anton
Но я не уверен
Anton
:D
Evgeny
само по себе обновление контейнера на куче машин (без всякой фигни типа тестирования, да и кому она нужна) тоже укладывается в 10 секунд.
Alexey
Я не понимаю, что мешает в контейнере подправить конфигурации через ansible? Это, конечно, немного противоречит философии docker'а, но это детали же ;)
Alexey
подправили конфиг, параллельно подправили image, в следующий раз разлилось все как нало
Evgeny
просто непонятно зачем
Evgeny
когда гораздо проще выполнть blue-green и ничего не сломать
Aleksey
господа, кто нить мониторит influx telegraf-ом ?
Anton
Я не понимаю, что мешает в контейнере подправить конфигурации через ansible? Это, конечно, немного противоречит философии docker'а, но это детали же ;)
Ага. Я тоже всегда думал, что ансибл нужен для того, чтобы докер поднимать, а дальше уже пусть всё на стороне докера крутится :)
Anton
(У меня эта идея была ещё до появления сварма, а его я так и не протестировал, поэтому сильно не бейте)
Roman
https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/
Dmitrii
Сорри, отвлекся. Да я имел ввиду замену конфигурации только
Dmitrii
Да, никто не запрещает еще и имидж подправить. Но ведь можно и без имеджа жить. Я об этом. Убирается лишняя сущность
Dmitrii
При сохранении консистентности конфигурации
Dmitrii
Меньше сущностей - проект проще и дешевле в поддержке.
Dmitrii
Те же LXC контейнеры сетпятся тем же ансимблем в том числе
Dmitrii
В итоге имеем 1 репозиторий со всем и ничего лишнего
Dan
кто хорошо знает баш? )))
Alibek
"И я, и я - того-же мнения"! На предыдущей работе с трудом, но вбивал, что конфигурации ansible в git это всё что нужно для управления.
Magistr
а как же красивые морды kubernetes и dcos ? )))
Alibek
и капистрано идёт под бритву Окама, и оверхед docker'а нивелируется перед lxc\
Dmitrii
Деплоим мы все же с помощью капистрано. Под него много готовых гемов есть на все случаи жизни. А переписывать на плейбуки лень.
Dmitrii
Но вообще я рад, что хотябы кто-то разделяет мое мнение по докеру 😁
Anton
На мой субъективный взгляд, докер просто дал сильную популярность контейнеризации и заставил довольно ощутимую часть бэкендеров думать не только о приложении, но и о целостности окружения. У него есть оверхед, но в сравнении с остальными инструментами - он ощутимо проще (ну или возможно, что мне просто так кажется).
Anton
Ощутимо проще в плане Get Started
Alexander
Докер очень нужен, когда есть больше чем 7 сервисов, которые интегрируются друг с другом (7 - число из психологии, число сущностей которое человек может держать во внимании). Если сервисов мало или они не особо интегрированы, то и не нужен вовсе
Dmitrii
Не совсем понял где сложность в интеграции сервисов между собой?
Dmitrii
Если все сделано через ансибль то он легко впихивает обновленные конфиги в нужные ноды на основе inventory файла
Alexey
Докер очень нужен, когда есть больше чем 7 сервисов, которые интегрируются друг с другом (7 - число из психологии, число сущностей которое человек может держать во внимании). Если сервисов мало или они не особо интегрированы, то и не нужен вовсе
ОКРП - это все же не из психологии, а из нейробиологии скорей ;)
Dmitrii
У нас нигде в репозитории ансибля не встретится захардкоженый IP адрес. Все вычисляется через роли и т.д.
Dmitrii
И это я считаю залог успеха. Просто добавил в inventory Хосты. Запустил плейбук и готово
Dmitrii
Все тоже самое с AWS.
Alexey
У нас нигде в репозитории ансибля не встретится захардкоженый IP адрес. Все вычисляется через роли и т.д.
Прям сразу захотелось посмотреть, магия ;)
Dmitrii
Так а что магия? Просто все поделено на группы и все.
Dmitrii
В nginx апстрим составляется через j2 шаблон
Dmitrii
И все везде в том же духе.
Dmitrii
Настоящие проблемы начинаются когда прод в амазоне а стейджинги в хетцнер. Но и здесь я тоже нашел как сделать единый плейбук на все окружения
Dmitrii
А т.к. при использовании aws нет смысла хардкодить IP т.к. запвришься менять, то их у нас там действительно нет
Alexander
> Dmitrii
Не совсем понял где сложность в интеграции сервисов между собой?
я про взаимозависимость, когда для изменения параметра в одном серивсе надо поменять еще в 7ми, тогда в ансибле надо мутить абстракции для этого, которые вначале терпимые, а потом начинают требовать все больше и больше внимания
Anton
Настоящие проблемы начинаются когда прод в амазоне а стейджинги в хетцнер. Но и здесь я тоже нашел как сделать единый плейбук на все окружения
Вот тут бы как раз докер и помог :)
Alibek
А у меня наоборот, в переменных на хост заданы и накатка ip-адресов и маршруты и имена хостов (своя виртуализация/изоляция, не aws/digitalocean/azure)
Dmitrii
> Dmitrii
Не совсем понял где сложность в интеграции сервисов между собой?
я про взаимозависимость, когда для изменения параметра в одном серивсе надо поменять еще в 7ми, тогда в ансибле надо мутить абстракции для этого, которые вначале терпимые, а потом начинают требовать все больше и больше внимания
Если в ансибле все организовать через роли, то можно создать плейбук который будет знать обо всех сервисах и их параметрах
Alexander
да, я в курсе
Dmitrii
А если еще использовать теги, то как я писал выше - обновление параметра будет занимать 10 секунд
Alexander
и это мейнтейнить сложно, когда проект большой
Alibek
накатить везде docker и наступит счастье?
Alexander
но пока у вас проект не большой, то мне можно верить только на слово :)
Dmitrii
но пока у вас проект не большой, то мне можно верить только на слово :)
Большой и небольшой довольно расплывчатые понятия
Alexander
я там ввел критерий - больше 7ми сервисов завязанных серьезно друг на друга
Alexander
не MVC приложение -> кэш -> база а что-то понавороченней
Dmitrii
Так это. Может это проблема "микоосервисной архитектуры" и кто то "переупоролся" ею?)
Alibek
Если одни хосты в openvz, другие в lxc, третьи в azure, четвёртые в железе, пятые на винде, то какой профит тут от докера? К пример?
Alibek
у
Anton
Это чем же?
Ну докер тебя вообще изолирует от окружения вендора, поэтому тебе пофиг на всё, лишь бы докер поднялся.
Alibek
нифига он не изолирует, как минимум он упарывается на openvz и lxc
Alibek
ядра разные
Alexander
> Dmitrii
Может это проблема "микоосервисной архитектуры"
да и именно поэтому Докер и сделали, как решение этой проблемы
Dmitrii
не MVC приложение -> кэш -> база а что-то понавороченней
Ну вот есть у нас приложение, докогенкратор, редис, генератор формул, база, балансер.
Dmitrii
Уже 6 сущностей
Anton
нифига он не изолирует, как минимум он упарывается на openvz и lxc
А можно поподробнее? Я что-то не очень понял кейс.
Alexander
вам тогда не надо беспокоится, у вас почти классическая трехзвенка, ей не надо докер
Alexander
под сервисом я имею в виду отдельную изолированную сущность