LINUX.ORG.RU

Релиз Kubernetes 1.15

 , ,


0

3

Kubernetes — открытое программное обеспечение для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. Поддерживает основные технологии контейнеризации, включая Docker, rkt, также возможна поддержка технологий аппаратной виртуализации.

Kubernetes 1.15 состоит из 25 улучшений, из основного: большой упор сделан на стабильность работы и увеличение поддержки расширяемости в частности это CRD и API Machinery.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

никак

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

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

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

И в чём же она?

anonymous
()
Ответ на: комментарий от anonymous

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

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

И в чём же она?

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

то придешь к тому что из заббикса можно убрать примерно половину функциональности и 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.

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

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

mx__ ★★★★★
() автор топика
Ответ на: комментарий от mx__

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

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

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

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

...

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

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

mx__ ★★★★★
() автор топика
Ответ на: комментарий от alpha

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от alpha

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

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

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

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

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

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

PunkoIvan ★★★★
()
Ответ на: комментарий от PunkoIvan

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

Во-вторых, в принципе в 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 минуты.

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

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

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

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

PunkoIvan ★★★★
()
Ответ на: комментарий от PunkoIvan

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.