А как факт наследия препятствует использовать этот подход?

никак

но пара кликов в веб интерфейсе - это вообще никак не infrastructure as a code

В infra as a code важен не формат в котором хранится информация, важен процесс который вокруг этого формата построен. Тесты например, или code-review.

но пара кликов в веб интерфейсе - это вообще никак не infrastructure as a code

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

Тот же CFEngine - это 1993.

от это вот всё точно так же было

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

Но достаточно сравнить развертывание и конфигурацию prometheus c alert-manager vs какой-нибудь zabbix чтобы понять что разница в подходах есть и существенна.

Ты пытаешься доказать что бывают хорошие legacy-приложения?

Нет, я хочу сказать, что IaC применялось гораздо раньше, чем появился весь этот новомодный хайп, я уже писал: тот же cfengine - 1993 год. И что автоматом присваивать подход iac к новому этапу развития инфры в виде облаков и прочей шушеры, мягко говоря, неправильно.

Но достаточно сравнить развертывание и конфигурацию prometheus c alert-manager vs какой-нибудь zabbix чтобы понять что разница в подходах есть и существенна.

И в чём же она?

Нет, я хочу сказать, что IaC применялось гораздо раньше

Осталось понять зачем ты это хочешь сказать.

И в чём же она?

Попробуй и сравни.

Осталось понять зачем ты это хочешь сказать.

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

Попробуй и сравни.

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

Ну ты же зачем-то сопоставила легаси и то, что про iac люди и не в курсе.

Я не сопоставила, а добавила уточняющие характеристики.

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

Оно настолько очевидно, что если так не зашло, значит у нас непонимание на самом базовом уровне. Залезать в такие дебри в понедельник чревато.

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

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

В Prometheus тупо нет веб-интерфейса в котором надо было бы что-то кликать каждому юзеру в своем профиле. И базы которую стоило бы бекапить тоже нет. И спасибо им за это.

Не магия. Обычный web-интерфейс, обычная бд, клик туда клик сюда,

Казалось бы, при чём здесь ансибл. Алё, речь про IaC была или что? Заббикс точно так же раскатывается CM системами. Зачем ты начинаешь вилять задом.

В Prometheus тупо нет веб-интерфейса в котором надо было бы что-то кликать каждому юзеру в своем профиле. И базы которую стоило бы бекапить тоже нет. И спасибо им за это.

И IaC тут при том, что. Что?

Казалось бы, при чём здесь ансибл.

Ты с какими-то голосами в голове разговариваешь по-видимому. Я ansible ни разу не упомянула.

И IaC тут при том, что. Что?

При том что система мониторинга - это infrastructure. Возможность хранить её состояние целиком в виде пары yaml-файлов в системе контроля версий, а не в полных бекапах сервера - это as a Code.

Я ansible ни разу не упомянула.

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

При том что система мониторинга - это infrastructure. Возможность хранить её состояние целиком в виде пары yaml-файлов в системе контроля версий, а не в полных бекапах сервера - это as a Code.

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

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

Можешь попробовать. Если осилишь, то придешь к тому что из заббикса можно убрать примерно половину функциональности и 90% кодовой базы. Поскольку для задачи развертывания и управления с точки зрения IaC это всё не нужно.

какая разница легаси это или, прости хоспаде, микросервисы с точки зрения IaC?

Какая разница делать ежедневные бекапы состояния или хранить состояние в читаемом формате в системе контроля версий? Ну в принципе никакой, и там и там всё к ноликам и единичкам сводится в конечном итоге.

На практике - существенная.

Можешь попробовать. Если осилишь

Ты там совсем мозги потеряла со своими дайверсити и икволити? Сколько тебе раз писать, что я так давно уже делаю и с заббиксом в том числе(хоть он и говно, и его уже давно не видел)?

то придешь к тому что из заббикса можно убрать примерно половину функциональности и 90% кодовой базы. Поскольку для задачи развертывания и управления с точки зрения IaC это всё не нужно.

что ты опять несёшь? что и зачем нужно убрать?

Какая разница делать ежедневные бекапы состояния или хранить состояние в читаемом формате в системе контроля версий?

и тут мне прилетел фейспалм.jpg.tgz на 35TB. я уже устал спрашивать, понимаю, что по существу тебе ответить нечего, но я всё же попробую ещё раз: «что мне должно помешать сделать это?». wait, ohshit, я же уже храню это в гите, что же делать, как быть?!

я просто оставлю определение иац с педевикии:

Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.[1] The IT infrastructure managed by this comprises both physical equipment such as bare-metal servers as well as virtual machines and associated configuration resources. The definitions may be in a version control system. It can use either scripts or declarative definitions, rather than manual processes, but the term is more often used to promote declarative approaches.

а всё остальное какие-то твои выдумки.

«что мне должно помешать сделать это?»

Наличие БД с конфигурацией и того факта что пользователь заббикса залогинившийся через web может менять конфигурацию системы в обход Infra as a code-процедур.

а всё остальное какие-то твои выдумки.

Ну что и требовалось показать. Полное непонимание.

Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files

Это плохое определение, пустое и формальное, поскольку говорит только об инструментах, а не о сути явления.

Наличие БД с конфигурацией

оно через yaml/json тоже может.

и того факта что пользователь заббикса залогинившийся через web может менять конфигурацию системы в обход Infra as a code-процедур.

это вопрос дисциплины. точно так же, в обход iac процедур, можно поменять параметры где угодно.

Ну что и требовалось показать. Полное непонимание.

девочка, шла бы ты, песочку принесла.

Это плохое определение, пустое и формальное, поскольку говорит только об инструментах, а не о сути явления.
а не о сути явления.

любитель искать тайный смысл?

это вопрос дисциплины. точно так же, в обход iac процедур, можно поменять параметры где угодно.

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

именно поэтому я и говорю о лишней фунцкиональности в legacy-приложениях. Всю часть кода с веб-интерфейсом и управлением ACL можно выкинуть полностью и решить проблему дисциплины просто не создавая её.

любитель искать тайный смысл?

Что ж в нём тайного-то.

А смысл да, ищу.

Всю часть кода с веб-интерфейсом и управлением ACL можно выкинуть полностью

Я тоже люблю алфавитные (не пиксельные) 2х цветные мониторы, но все время себя спрашиваю, зачем то все таки придумали все эти мыши, 10 мегапикселей, 3д, ГУЙ и т.д.

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

Любая GUI-верификация может быт реализована как sanity-check на конфигах в IaC-подходе.

Там нет никакой GUI-магии, это алгоритмическая верификация данных поданных на вход.

При этом в GUI нет главных шагов верификации: 1) показать соседу, 2) прогнать на стенде.

А обмениваться скриншотиками настроек через чатики - ну это просто полная тоска и безысходность.

Любая GUI-верификация может быт реализована как sanity-check на конфигах в IaC-подходе.

...

Доп. проходы :( Вы меня не внимательно читали. Не данные поданные на вход а не возможность подать неправильные данные на вход.

Сейчас скриншотиками уже не обмениваются, 21 век понимашь, обмениваются роликами на ютубе.

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

да причём тут веб-интерфейс. условный админ всия предприятия, имея ключ/сертификат/админский_доступ_в_ад, может точно так же менять инфру со своей рабочей тачки в обход всех процедур, коммитя в мастер, а там уже дальше автоматом в продакшн или напрямую на хостах(ну так же быстрее). всё упирается в дисциплину, процессы и разграничение прав.

Всю часть кода с веб-интерфейсом и управлением ACL можно выкинуть полностью и решить проблему дисциплины просто не создавая её.

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

да и веб-интерфейс этот ваш можно закрыть для неблагонадёжных лиц.

вернее и не открывать.

Какая интересная дискуссия.

Почему нет? Мі Icinga2 используем (вібирали между Prometheus + Alert vs Icinga2)

там как раз полній IaC, можно такие вещи делать, что голова кругом.

при этом есть юайка в виде Icinga Director. Так вот - там есть и «показать соседу» и «прогнать на стенде».

Не можем от него отказаться полностью, потому что у нас Monitoring as a service и надо дать возможность людям конфигурять через юайку, а не конфиг.

В случае Zabbix там всё очень плохо с этим, я согласен. Но часто юайка никак не мешает IaC подходу.

Скажите, а можно сюда, на ЛОР скастовать Stallman as a Service? Чтобы всякий раз, когда тут будут говорить про нужность и важность контейнеров, микросервисной архитектуры и прочего *aaS, постил сюда пасту про Service as a Software Substitute и говорил, чем это закончится и кто те люди, которые этим занимаются.

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

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

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

IaC-подход не просто позволяет вести лог того где что настроено, но и унифицирует процессы вокруг этой настройки.

Monitoring as a service и надо дать возможность людям конфигурять через юайку, а не конфиг.

Значит это не IaC. Разумеется не все задачи можно впихнуть в этот метод, и не все нужно.

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

Но и это иногда можно облегчить.

У меня в графане например есть provisioning-конфиг с фиксированными datasources, и несколькими dashboard-ами которые так же лежат в Git в json-файлах. При этом настроен анонимный доступ в UI (лучше было бы через внешний LDAP конечно сделать). Любой может придти и создать свою временный dashboard с нужными для конкретного случая параметрами, когда нужно отследить какую-то конкретную проблему. Но если нужно изменить или создать новый постоянный dashboard - то его надо прислать коммитом в гит.

В итоге пользователи и ручные правки как бы есть, но управления правами, бекапами и состоянием т.п. - нет. Переналивка сервиса целиком из git-репы за 2 минуты.

Почитай что ли про приватные и гибридные облака.

Может поймешь почему OpenStack и Kubernetes так важны как открытые альтернативы проприетарным облачным сервисам.

А микросервисы и контейнеры - это вообще вопрос архитектуры разработки. KISS на уровне приложений и к проблеме SaaS ортогонален.

Согласен со всем, кроме:

Значит это не IaC. Разумеется не все задачи можно впихнуть в этот метод, и не все нужно.

юайка генерирует код, которій летит на ревью к нам. И мі ревьюваем код, которій біл сгенерироавн третьими лицами через юайку.

Гуй дает преимущество, как минимум в правах - появляется слой абстракции, которій позволяет давать права на измениее одного файла или даже секции файла.

Без него пришлось бі собирать конфиги из разніх веток и/или репозиториев.

Сейчас она тебе скажет, что это не IaC. А права так вообще разделять не надо, чего ещё удумали.

Если не можешь разобраться в вопросике, то может это не твоя тема?

Прочитал комментарии и так грустно стало.

Такая каша у большинства комментаторов в голове, только alpha более менее адекватно рассуждает.

-

Avgust

https://github.com/kelseyhightower/kubernetes-the-hard-way

А есть такой же, но бесплатный?