Полезная таблица инструментов DevSecOps

Если ты учишься с нуля, устраняешь пробелы или заменяешь существующие инструменты, начни с Периодической таблицы, чтобы подобрать оптимальные решения для своей DevOps-пайплайна.

#devops #девопс

@devopsitsec

#машины_разное

Я думаю, все и так достаточно рассосали падение Гугла, поэтому давайте расскажу в нескольких постах подробнее про feature flag’и, и какие у них есть полезности.

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

Если в релизный цикл попадет баг, и нужно будет откатиться, то вы откатите не только свое изменение, но и другие (а там могли быть критические фиксы!), и будете делать это долго: плохие экземпляры потуши, старые релизные подними, трафик перенаправь, а если это делается глобально, то и сам релиз откатываться начнет не сразу (смотря как быстро алерт сработает), да и возвращаться будет долго.

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

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

Более того, выкатку флага тоже можно и нужно контролировать с таким же усердием, как и сам релиз. Например, повесить на флаг те же алерты, что и на сервис, включить флаг для 1% запросов в canary, и смотреть как та пищит. Если у нас выстрелил алерт по SLO доступности, то дело скорее всего в фиче, и система выкатки так же умно его откатит назад.

Инженеру остается проанализировать логи, написать фикс и повторить итерацию.

Позже расскажу про как флаги позволяют контролировать выполнение кода, но пока поспекулирую, что флаги пропускают либо когда очень спешат (а в нынешней экономике все очень спешат), либо когда риск изменения низкий. А ваш покорный прилично инцидентов просмотрел, триггерами которых являлись «низкорисковые» изменения. :)

#машины_разное

Само понятие «флаг» может произвести впечатление, что это какой-то тумблер «вкл/выкл», который захотел включил, захотел выключил.

Самый простой флажок будет выглядеть именно так, но ✨настоящая магия ✨ прячется за условиями выполнения, которые могут быть статическими и динамическими! Давайте на примере расскажу про Configuration Driven Development (далее CDD).

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

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

default: prod-db
flags:
- test:
if:
- env = testing
then: test-db
- prod:
if:
- env = production
then: prod-db

Опытный инженер увидит подозрительное default, которое может нагнать страх, и этот страх вполне оправдан. Выбирая между «передаем по умолчанию прод, и возможно не тот енв получит доступ» и «передаем null, и приложение упадет», я бы выбрал второ- исходя из ситуации.

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

default: prod-db
flags:
- test:
if-one-of:
- env = testing
- req-tenancy = test
then: test-db
- prod:
if-one-of:
- env = production
- req-tenancy = prod
then: prod-db

А что, если нам нужно обеспечить теневой трафик, который живет в рамках теста, но нуждается в "живых" данных? Тогда можно использовать использовать логическое умножение:

default: prod-db
flags:
- shadow:
if-all-of:
- env = testing
- req-tenancy = shadow
then: prod-db

Тут вы наверняка скажите: «Карен, ты упоролся, connection string к базе инициализируется на старте приложения, а ты предлагаешь это делать на каждый запрос?!», а я вам отвечу: «Не душните, взял самый наглядный пример, чтоб всем было понятно!»

У CDD очевидно есть и бизнес применение, например решать в какой PSP передать платеж на базе параметров платежного поручения. Представьте себе такое:

flags:
- dest1:
if-all-of:
- country-code = BR
- payment-method = payment_card
- card-type = debit
then: psp1

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

Я не зря оговорился о разношерстных параметрах, ведь диверсификация параметров это необходимая составляющая экспериментов!

У вас бывало такое, что вы запускаете любое мобильное приложение, а оно ПОЧЕМУ-ТО ведет себя иначе? А потом точно так же ПОЧЕМУ-ТО ведет себя как раньше?

Это означает, что вы попали под эксперимент. Эксперименты это целые наборы флагов, которые принимают в качестве параметров… да вообще что угодно, от страны и устройства до пола, возраста, и последних 10 пролайканных фоток. Эксперименты проверяют жизнеспособность фич и их полезность, поэтому ставятся на длительный период и измеряют бизнес метрики навроде конверсии. Если цифры идут вверх, расширяем поле экспериментов дальше, пока не уйдем на 100%.

Платформа экспериментации - красивая обертка над системой конфигураций, feature flag’ов, мониторинга и механизмов раскатки, и стоит на вооружении у всех больших дядечек и тетечек.

В следующем посте постараюсь собрать для вас подходящие инструменты, с которыми вы можете использовать feature flag’и с минимальным ущербом для здоровья.

Подборка, в которой мы хотим поделиться новыми тулами из мира Kubernetes. Тут Portainer запустила дистрибутив для 200 МБ RAM, k0s попал в CNCF Sandbox, а новые инструменты упрощают управление мультикластерными средами. Смотрите сами.

Портативный Kubernetes для минимальных ресурсов
Portainer представила KubeSolo — ультралегковесный дистрибутив Kubernetes, который работает всего с 200 МБ RAM. Без кластеризации и etcd, идеально подходит для ограниченных сред.

Мультикластерное управление
kubectl-foreach позволяет выполнять kubectl-команды параллельно в нескольких кластерах одновременно.

k0s присоединился к CNCF Sandbox
Легковесный дистрибутив Kubernetes от Mirantis получил официальное признание в CNCF. k0s выделяется единым бинарным файлом со всеми компонентами Kubernetes, а ещё он подходит для edge-вычислений и ресурсоограниченных сред.

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

Как работает DNS в Linux. Часть 1: от getaddrinfo до resolv.conf

Когда мы вводим в браузере имя сервера или доменное имя сайта, выполняем ping или запускаем любое удаленное приложение, операционная система должна преобразовать указанные имена в IP-адреса. Этот процесс называется разрешением доменного имени. На первый взгляд он может показаться весьма прозрачным, однако за ним скрывается многослойный механизм.

Данная статья — начало серии, посвященной низкоуровневой архитектуре разрешения имен. Поговорим о том, как устроен этот процесс в Linux на уровне ядра, различных библиотек C и системных вызовов.

Migrating to ClickStack from Elastic

В этом руководстве описан подход к миграции с Elastic Stack на ClickStack. Фокус сделан на стратегии параллельной работы, которая минимизирует риск, используя сильные стороны ClickHouse в рабочих нагрузках наблюдаемости. Документация ClickHouse.

Новое исследование Google: 65 % времени разработчиков тратится впустую без платформенного подхода

Google и ESG опросили 500 ИТ-специалистов. Коротко о главном в исследовании состояния платформенной инженерии:
• 65 % времени разработчиков уходит на задачи, которые может решать внутренняя платформа
• 55 % компаний уже поддерживают внедрение platform engineering
• Только 27 % полноценно интегрировали платформенный подход во все команды
• 84 % компаний признают, что внутренней экспертизы не хватает для эффективного развития платформ

Разработчики продолжают тратить бо́льшую часть времени не на продукт, а на инфраструктуру. Platform engineering — ответ на эту историю.

Именно здесь DevOps-команды играют ключевую роль, превращают разрозненные процессы в работающую платформу и интегрируют её в максимальное количество команд.

🛠️ Awesome DevOps MCP Servers

MCP (Model Context Protocol) — открытый протокол, который позволяет AI-моделям безопасно взаимодействовать с локальными и удалёнными ресурсами через стандартизированные серверы. В этом списке собраны лучшие MCP-серверы для DevOps-задач:

• Инфраструктура как код (IaC)
– Terraform: dulltz/mcp-server-hcp-terraform, jashkahar/Terraform-MCP-Server, nwiizo/tfmcp
– Pulumi: pulumi/mcp-server

• Управление Kubernetes
– rohitg00/kubectl-mcp-server — natural language доступ к kubectl, helm, istioctl в безопасном Docker
– manusa/kubernetes-mcp-server — поддержка CRUD для любых ресурсов и OpenShift
– portainer/portainer-mcp — управление контейнерами и мониторинг через Portainer

• Облачные провайдеры
– AWS: awslabs/mcp (официальный), alexei-led/aws-mcp-server
– Alibaba Cloud: aliyun/alibaba-cloud-ops-mcp-server

• Управление проектами и тикетами
– Freshdesk: effytech/freshdesk-mcp
– Jira: nguyenvanduocit/jira-mcp
– Topdesk: dbsanfte/topdesk-mcp

…и многое другое: CI/CD, сервисы мониторинга, управление версиями и безопасность.

🔗 Изучайте и расширяйте:
https://github.com/rohitg00/awesome-devops-mcp-servers

«С вами подкаст DevOps Дефлопе»

После перерыва разогреваемся на теме AI. В эфире — Никита Борзых и Виталий Хабаров, да не одни, а с новыми ведущими.

Ребята расскажут, как ИИ помогает искать ошибки в конфигах и YAML’ах, разбираться с нагрузкой на API-сервер Kubernetes и чинить кластер OpenStack. А ещё порассуждают, какие задачи компании смогут отдать машинам и на какие ИИ-инструменты стоит посмотреть DevOps-инженерам.

Слушайте на удобной площадке
или на нашем YouTube

Облако ITENTIS CLOUD: технологии топов, цена без наценки (и живая поддержка!)

Нашли брендовую вещь в надежном маркете на 30% дешевле? Вот и мы так же. 😉

ITENTIS CLOUD — не "бюджетный" вариант. Это ВСЕ те же технологии, что у Яндекса, Mail или VK (VPC, Kubernetes, S3, снимки, автомасштабирование), но...

🔥 ...ЗНАЧИТЕЛЬНО ДЕШЕВЛЕ! 🔥

Зачем платить за бренд? Получите то же самое (а кое-что лучше) и сэкономьте. Не верите? Сравните тарифы! Надежные дата-центры Tier III, как у всех.

И главное — наша поддержка. Вот где мы их РЕАЛЬНО обходим:

💩 У них: очереди, боты, ответ "в течение 24 часов".
😍 У нас: живой, компетентный специалист 24/7. Не бот! Настоящий человек, который РАЗБЕРЕТСЯ. Ответ за минуты. Сложный Kubernetes? Объясним и поможем. Это наш стандарт.

Что вы получаете за меньшие деньги:

1. Та же "начинка": все ключевые технологии (VPC, Kubernetes, S3 и т.д.) — как у топов.
2. Надежность: Tier III, 2FA, шифрование, брандмауэры.
3. Скорость: запуск кластера быстрее доставки пиццы.
4. Простой контроль: интуитивное управление.
5. ГЛАВНОЕ: цена, от которой улыбнетесь + поддержка, которая реально спасает.

"А подвох?" Да нигде!

14 дней БЕСПЛАТНО: Протестируйте всё.
БЕСПЛАТНАЯ миграция: Перенесем ваши проекты без простоев.
Гарантия возврата: Риск — ноль.

‼️ Понравится? Расскажите друзьям! Реферальная программа: за каждого клиента — бонус или скидка. Без мишуры.

Итог: ITENTIS CLOUD = Технологии топов + Честная цена + Человеческая поддержка 24/7.

Хватит переплачивать и ждать ответа! Получите максимум.

👉 Действуйте выгодно:

1. Сравните тарифы: https://itentis.cloud
2. Пишите:
🤖 Telegram-бот: @itentis_bot (Фраза: "Хочу облако дешевле Яндекса!")
✉️ Почта: [email protected]
3. Скажите: "Читал пост про ЭКОНОМИЮ в облаке!" 🚀 (Получите бонус!)
4. Следите за обновлениями в @itentis

Мощное облако. Честная цена. Люди на связи.

Нашли интересный проект — BLAFS — инструмент для «обезжиривания» Docker-контейнеров, который может сократить их размер на 65-95%.

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

Процесс из трёх этапов: конвертация файловой системы в формат BLAFS, профилирование с реальными нагрузками и финальное удаление неиспользуемых файлов.

Интересно, что подход работает на уровне файловой системы и сохраняет слоистую структуру Docker-образов. Это отличается от других решений вроде SlimToolkit.

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

#мероприятия #штурвал
Регистрируйтесь на K8s Community Day — главную сходку сообщества 😋

31 июля в Москве состоится первая независимая конфа Kubernetes Community Day для открытого сообщества профессионалов по куберу и тех, кто только начинает.

Что ждет участников?

◽️ Два пространства с хардкорными докладами, дискуссиями и воркшопами, интерактивы и IT StandUp.
◽️ Живое общение с комьюнити в уютной атмосфере — без HR-стендов и дорогих билетов.
◽️ Выступления от крутых экспертов из Yandex Cloud, еcom.tеch, VK, Luntry, «Лаборатории Числитель», Lamoda Tech, МКБ, Rebrain, Cloud ru и др.
◽️ Честные истории про кейсы, факапы и «боли».

Формат: офлайн и онлайн.

🤝 Участие бесплатное. Регистрация уже открыта!

Информационные партнеры: Computerra, ICT Online, Cybermedia, Global Digital Space, AM Live, ict2go.

KubeShark: Wireshark for Kubernetes

Wireshark — известный инструмент для захвата пакетов, анализа и устранения неполадок. TCPDump/Wireshark дает возможность визуализировать и понимать, что происходит в сети. Представьте, если бы что-то подобное было возможно в K8s, если бы вы могли видеть, что именно происходит при развертывании кластера, получении подов, создании учетной записи службы и как различные процессы взаимодействуют друг с другом и т. д.

Чтобы увидеть, что именно происходит при запуске команды kubectl, можно просто использовать флаг verbose, например, kubectl get pods -v=6. Уровень вербализации начинается с 0 и заканчивается на 9, где 0 — это минимум, а 9 — максимум вербализации.

Kubectl с флагом -v позволяет видеть вызовы API L7, но не позволяет отслеживать сетевой трафик. Kubeshark захватывает L3 и L7, фактически у него есть доступ ко всему пакету L2. А еще он включает дашборд для визуализации примерно того же самого, как и в Wireshark.

Статья с описанием kubeshark (❗️статья на medium.com)

Репыч на Гитхабе

Несколько интересных утилит Linux, которые могут заменить те, что вы используете каждый день

🚀 Забытые планировщики at и batch, с которыми не нужно редактировать файлы как с cron.

echo "shutdown -h now" | at 11:00 PM

или

echo "updatedb" | batch

🚀 Запуск служб «на лету» с systemd-run. Подходит для тестирования служб или планирования задач по обслуживанию с полной поддержкой systemd. Запуск без создания файла службы:

systemd-run --unit=backup-job tar -czf /backup/home.tar.gz /home

🚀 Автоматическая оптимизация производительности с tuned. Динамически регулирует параметры системы в зависимости от типа рабочей нагрузки (виртуализация, пропускная способность, задержка и т. д.). Предварительно изучите принцип работы утилиты.

dnf install tuned
tuned-adm profile throughput-performance

🚀 Защита от удаления с chattr. Даже root не сможет удалить или изменить файл пока не удалить неизменяемый бит.

chattr +i /etc/passwd

kpatch

kpatch — это утилита для исправления ядра Linux, которая позволяет патчить работающее ядро ​​без перезагрузки или перезапуска каких-либо процессов. Она позволяет системным администраторам немедленно применять критические исправления безопасности к ядру, не дожидаясь завершения длительных задач, выхода пользователей из системы или запланированных окон перезагрузки.

Репыч на Гитхабе