Умом и сообразительностью

Не знаете, что делать с уведомлениями? Погрязли в Helm-чартах и автоматизации? Всё ещё пишете код сами? Тогда мы идём к вам с нашим июньским DevOps-дайджестом!

CoPilot всем желающим

Птица Говорун с планеты Блук вернулась на Землю и получила имя GitHub CoPilot. Отличаясь умом и сообразительностью, этот AI-driven движок стал своеобразным напарником программиста. Подобно роботам-вершителям CoPilot обещает сделать всех разработчиков счастливыми.

Способность автоматически создавать код потребует скромной платы в виде купюры с Бенджамином Франклином ежегодно. Активным мейнтейнерам популярных Open-source проектов и студентам — вовсе бесплатно. Но так ли этот инструмент хорош в деле?

Ответ есть в статье на Хабре с провокационным названием «Мой опыт с резиновым мужиком. Github Copilot». Вкратце — да, это хороший инструмент для опытных разработчиков. Можно чётко сформулировать задачу и получить вполне работающий код. Но не без забавных ситуаций. Иногда можно на выходе обнаружить «индусский код» или полную фигню.

При работе с CoPilot очень важно уметь передать ему контекст. Если это получилось, то да — «резиновый мужик» вполне выручает и экономит немало времени. А если нет — увы и ах. За ним надо самому всё внимательно перепроверять. 

Разума в этой штуке нет и она точно не заменит разработчиков в ближайшие годы. Хорошо это или плохо, сказать сложно. Зато теперь такая технология общедоступна и может быть именно для вас станет надёжным и удобным рабочим инструментом.

Grafana OnCall OSS сообществу

В очередной раз мир открытого программного обеспечения пополнился хорошим софтом. Изначально продукт Grafana OnCall был только SaaS-сервисом, работающим в облаке. Но многим пользователям это не подходило по требованиям конфиденциальности или ограниченного подключения. Требовалась возможность локальной инсталляции. Поэтому появилась OSS-версия, которая заняла своё достойное место в observability-стеке Grafana Labs.

Дежурства и решение проблем — вечная боль. Идея Grafana OnCall в том, чтобы наладить более тесную связь между DevOps- и SRE-инженерами, обеспечив их единым наблюдательным пунктом. Создатели позаботились и об управлении графиком дежурств, и об оповещениях. Уведомления могут приходить стильно, модно, молодёжно в мессенджеры или по старинке — звонками и SMS.

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

Возможность автоматической эскалации вкупе с гибкой маршрутизацией — ещё одна киллер-фича OnCall. Для создания маршрута используется удобный пользовательский интерфейс. Вместе с этим создаётся логика, базирующаяся на привычных элементах IF / ELSE IF / ELSE. Советуем попробовать.

Flux2 обновился до v0.31.0

Рано или поздно любая компания, внедряющая Kubernetes, начинает смотреть в сторону GitOps. DevOps-практики отлично подходят для автоматизации инфраструктуры. Их внедрение даст возможность управления на более высоком уровне. Это в свою очередь позволит оперативнее реагировать на требования бизнеса.

Переход к GitOps предполагает существование хранилища конфигурации. Чтобы внести изменения в инфраструктуру делается коммит, а далее инфраструктура самостоятельно пытается прийти к конечному состоянию. Следовательно, нужно промежуточное ПО, которое будет смотреть и на Git, и на инфраструктуру. Эту задачу решает flux2.

Обновление до 0.31.0 принесло несколько важных изменений. Теперь можно извлекать Helm-чарты из контейнеров, сконфигурировав Helm-репозиторий с type: oci. Также появилась возможность триггерить GitHub Actions из Flux через конфигурирование провайдера оповещений с type: githubdispatch.

Важный момент — если ваш kubeconfig использует устаревшую версию Credential API client.authentication.k8s.io/v1alpha1, следует выполнить обновление до client.authentication.k8s.io/v1beta1.

Let’s Try Talos

Kubernetes нужна операционная система. Внутри куча абстракций, но на низком уровне всё равно работает ОС со своим ядром и набором софта. В идеальном варианте на всех нодах кластера нужно иметь идентичную ОС. Развернуть такую систему несложно, проблемы начинаются позже: выходят обновления пакетов, изменяются конфигурационные файлы. В процессе таких обновлений ноды со временем начинают несильно, но отличаться друг от друга.

В начале 2019 года была представлена Talos OS. На уровне ядра используется привычный Linux. Но она уникальна своим подходом. Во-первых, rootfs здесь только для чтения и внести туда изменения нельзя. Таким образом, на всех нодах будет идентичная версия, а поведение кластера станет более предсказуемым.

Во-вторых, у неё нету привычного shell. Авторы решили, что вручную подключаться и управлять нодой просто не имеет смысла. Здесь используется Kubernetes-like способ управления через gRPC API. Соединение защищено при помощи mTLS. Этот же принцип играет дополнительную защитную роль — раз нет привычного SSH, то и получить к нему несанкционированный доступ тоже не получится.

В третьих, весь userspace был написан с нуля на Go и предназначен исключительно для работы с Kubernetes. Да, вы не можете запустить на хосте никаких собственных процессов. init и демоны, предоставляющие API, заточены только на Kubernetes. Ещё одним плюсом можно считать, что работает Talos OS практически на чём угодно. Запустить его можно как на «малинке», так и на bare-metal инсталляциях, а также в современных облаках (коммерческих и self-hosted).

Проект активно дорабатывается и несколько дней назад вышла новая версия 1.1.0. Были обновлены компоненты Kubernetes и софт, предоставляющий API. Так что если вы ещё не пробовали Talos OS, самое время его протестировать.

 

Митапы