RedHat приобретает систему управления конфигурацией Ansible

Затем, что когда ты один, делай как хочешь, всем пофиг. А когда рядом с тобой люди, ты задолбаешься всем объяснять что ты там имел ввиду и почему тут нужно посмотреть руками, а там не нужно. Придет падаван и завалит тебе всю систему, когда ты в отпуск уйдешь. Ты будешь портить жизнь себе и падавану, говоря ему куда жать, а куда не жать. При этом он не будет вообще ничего понимать, что происходит.

При этом он не будет вообще ничего понимать, что происходит.

Ну и нахрена мне такой падаван? :)

Думаешь собрать необходимые пакеты это сложнее, чем пересобирать мир ежемесячно?

Ага. Я достаточно хорошо знаю особенности сборки RPM/DEB, чтобы держаться от этого подальше.

Или засунуть самую невероятное окружение в контейнер это хоть как-то сравнимо с замусориванием целого сервера?

Опять ты что-то хочешь куда-то засунуть. Ну нечего мне в контейнеры засовывать, смирись уже. Я не буду засовывать smtp сервер в контейнер. Это бессмысленно.

Ну и нахрена мне такой падаван? :)

Потому что вряд ли тебе попадется умнее, они обычно со второго-третьего курса в более высоких сферах крутятся. А обычного человека не стоит травмировать и заставлять заниматься механической работой, которую он не понимает.

Я достаточно хорошо знаю особенности сборки RPM/DEB, чтобы держаться от этого подальше

Это промышленный стандарт на сегодня и боятся его не стоит

смирись уже

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

Я не буду засовывать smtp сервер в контейнер. Это бессмысленно.

Ахаха, но почему? Ты видимо просто не понимаешь о чем речь.

Это промышленный стандарт на сегодня и боятся его не стоит

Я знаю. Это не отменяет того факта, что от этого стоит держаться подальше.

Ахаха, но почему? Ты видимо просто не понимаешь о чем речь.

Как это сделает мою жизнь лучше?

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

Хотя он даже сырцы качать не умеет, о чем это я тут :D Вместо этого предлагается использовать spectool и yum-builddep. Правда, первый не умеет ничего, кроме http/ftp, а второй не умеет макросы. Но кого это волнует, главное, что бинарный дистрибутив :D

от этого стоит держаться подальше

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

Как это сделает мою жизнь лучше?

Твою не знаю, мою жизнь это улучшает тем, что в докерфайле я всегда вижу конфигурацию с мельчайшими подробностями. Я могу перенести сервис на другой сервер в течении минуты. Я могу в течении 5 минут масштабировать это все на несколько серверов и вернуть обратно за это же самое время. Я могу раскидывать smtp на разные домены тупо указав этот домен в плейбуке, а не ковырять конфиг, боясь попасть на подводные камни. Я никогда не боюсь обновлять версии ПО, потому что откатить назад и протестировать новое это минутное дело. Это все примеры на вскидку, это делает мою жизнь и жизнь коллег проще и веселее.

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

Гм... А я вижу её в git. Какая разница, в какой файл смотреть?

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

У меня нет сотен серверов, так что мне это не особо интересно.

Я могу раскидывать smtp на разные домены тупо указав этот домен в плейбуке, а не ковырять конфиг, боясь попасть на подводные камни.

боясь попасть на подводные камни

Srsly?

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

Я тоже.

Так где выгода от контейнеров-то?

Гм... А я вижу её в git. Какая разница, в какой файл смотреть?

Этот файл и есть в гите, только там еще написано, что там-то нужно создать каталог, а там нужно что-то прописать в /etc/default/ и тд

У меня нет сотен серверов, так что мне это не особо интересно.

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

Srsly?

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

Я тоже.

Тебе так кажется

Так где выгода от контейнеров-то?

Выгода в одноразовом окружении

Тебе так кажется

Бгг.

Ты сам писал, что боишься, что java при обновлении что-то там потянет. А теперь вдруг не боишься. С остальным также, вот и вся история.

Ну вы раскормили.

Мне казалось, ты говорил про то, что можешь откатить, если нужно.

Если у тебя java накатит иксов и прочих ништяков на полсистемы, как быстро ты сможешь это откатить?

Ну вот как-то так:

emerge --oneshot <older-java-package>
emerge --depclean

Вопрос был сколько времени это займет и будут ли при этом работать сервисы? В случае с контейнерами даунтайм будет несколько секунд.

Вопрос был сколько времени это займет

Меньше минуты

и будут ли при этом работать сервисы? В случае с контейнерами даунтайм будет несколько секунд.

Даунтайм - столько, сколько требуется на рестарт сервиса после даунгрейда.

А с установленным барахлом, что будешь делать?

С установленным барахлом разбирается вторая команда :)

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

Ну я какой-то такой реакции и ожидал.

Ну да, только обычно вылезают ньюансы, там либа обновилась, тут конфиг новый подтянулся.

Конфиги берутся из git'а. О какой либе ты говоришь? И чем даунгрейд в контейнере будет отличаться от без контейнера?

я какой-то такой реакции и ожидал

ну видишь, ты и сам все понимаешь

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

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

ну видишь, ты и сам все понимаешь

Да, я понимаю, что после того, как кончились аргументы, ты начал придумывать какие-то странные случаи.

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

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

Да, я понимаю, что после того, как кончились аргументы, ты начал придумывать какие-то странные случаи.

О да, конечно, странные случаи)

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

Какой зоопарк? Ты себя хорошо чувствуешь? Один контейнер, одно приложение. Обновил контейнер, погасил старый, запустил новый. Ты почитай что такое docker и для чего его используют. Почитай best practice по ansible и тебе откроются многие удивительные вещи. Которые, правда, часто не совместимы с подходом навалить всё на один сервак и всем вместе в нем жить, пока он не умрет. Думаю надо закругляться с дискуссией, а то я не могу отделаться от чувства, что уговариваю кого-то есть кашу, потому что она полезная.

О да, конечно, странные случаи)

Да, весьма странные. Как обновление библиотеки помешает работе жабы?

Какой зоопарк? Ты себя хорошо чувствуешь? Один контейнер, одно приложение. Обновил контейнер, погасил старый, запустил новый. Ты почитай что такое docker и для чего его используют. Почитай best practice по ansible и тебе откроются многие удивительные вещи.

Я читал.

Которые, правда, часто не совместимы с подходом навалить всё на один сервак и всем вместе в нем жить, пока он не умрет.

Зачем валить всё на _один_ сервак? Почему бы просто не поднять _несколько_ виртуальных серверов и положить на каждый что нужно?

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

Я просил тебя привести хоть сколько-нибудь весомые аргументы в пользу контейнеров. Давай, вкратце. Без аппеляций к каким-то проблемам с конфигами.

P.S.

https://www.andreas-jung.com/contents/the-case-against-docker

Почему бы просто не поднять _несколько_ виртуальных серверов и положить на каждый что нужно?

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

весомые аргументы в пользу контейнеров

Виртуалка против контейнера не дает той простоты управления, когда запустить контейнер по времени занимает столько же, сколько запустить демон сервиса. Ты можешь разделить сервис на 100 разных контейнеров с разными компонентами системы и рулить их по отдельности. С обычной виртуализацией ты не сможешь этого сделать. Ты как минимум сразу упрешься в выделение оперативной памяти, которая будет тратится не пойми на что. Контейнер это обертка для системного сервиса, как chroot. Виртуалка это полноценный сервер с рядом ненужных компонентов, которые обязательны для его работы.

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

Ага. А ещё это система с общим ядром. Пару недель назад мы столкнулись с тем, что наш билд-сервер уходил в deadlock из-за кривости снепшотов LVM. Я не хочу хочу повесить всю инфраструктуру из-за бага в ядре.

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

А ты уверен, что это нужно делать? И что это не сделает жизни меня и моих коллег сложнее?

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

Ряд ненужных компонент занимает 75(!) мегабайт. Переживем.

Какие-то страдания, я наискосок посмотрел. Могу попозже почитать внимательнее. Один из основных аргументов, то что докер работает медленнее, чем без него, это не так.

А чувак говорит, что это так. Мб в силу его специфичных условий. Я бы не был столь категоричен.

Я не хочу хочу повесить всю инфраструктуру из-за бага в ядре.

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

А ты уверен, что это нужно делать? И что это не сделает жизни меня и моих коллег сложнее?

Это зависит от вменяемости архитектора инфраструктуры, а не от подхода.

Ряд ненужных компонент занимает 75(!) мегабайт. Переживем.

Я про оперативную память сейчас говорю, покажи мне виртуалку, которая может стартовать с 75 мегабайтами?

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

Начинается...

Это зависит от вменяемости архитектора инфраструктуры, а не от подхода.

Угу.

Я про оперативную память сейчас говорю, покажи мне виртуалку, которая может стартовать с 75 мегабайтами?

Я тоже. Наш smtp сервер (целиком, со всем процессами) сейчас ест 100 мегабайт. Оверхед на сам kvm незначительный. Ну и?

Начинается...

Тут всё как раз хорошо, для подобных конструкций как раз и придумали ansible.

Наш smtp сервер (целиком, со всем процессами) сейчас ест 100 мегабайт.

Ну и как ты его сможешь запустить в отдельной виртуалке, чтобы она занимала 100Мб на хост-системе? Или типа он мало весит, никого не трогает, поэтому подселим его куда-нибудь еще?

Или типа он мало весит, никого не трогает, поэтому подселим его куда-нибудь еще?

Кого куда подселим?

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

satellite ~ spacewalk = puppet + foreman + MQ и + что-то там ещё их собственное

Может быть свежая версия? Более старые совсем не такие.

В RedHat после RHCE все сертификации по отдельным «инструментам», как ты выразился.

В RedHat после RHCE все сертификации по отдельным «инструментам», как ты выразился.

Что там сертифицировать в ansible?

Не удивлюсь, если теперь Ansible войдет в состав systemd...

Только недавно подумал, что было бы неплохо прикрутить ansible к IDM (FreeIPA) что бы получить аналог групповых политик AD. И тут эта новость...

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

В ansible это сделать можно, но не нужно, для хитрой интерактивной логики скорее какой-нибудь fabric подойдёт.

Если заменить вывод emerge на вывод apt получается примерно та же самая история

Если ты сидишь на LTS и не подключаешь в репы что попало - не получится: версии стабильны, зависимости меняются мало, и такого, чтобы openjdk-7-jre-headless после обновления внезапно притащил с собой иксы и альсу, не случается.

Фишка Ansible - в том, что задача выполняется, только если состояние сервера отличается от требуемого. За счёт этого не делается лишней работы, и сразу видно, что изменилось. Плюс удобное применение на группах хостов. Получается гибкий конструктор для конфигурации десятков и сотен серверов: добавили новый сервер в inventory, прокатили по нему плейбук - все роли применились и сервер готов к работе. Или изменили конфиг, применили плейбук - конфиг разлетелся по всем группам серверов с этой ролью, сервис порелоадился, всё ок. Если какие-то сервера уходили на обслуживание ДЦ - применим плейбуку повторно, конфиг будет меняться и сервис релоадится только на тех, где не было нового конфига.

Можно писать плейбуки «как на баше», которые всегда выполняют кучу задач, но это неправильно: правильная плейбука, если её повторно прокатить по хосту, покажет для всех задач changed: False.