🌐Автоматизируем увеличение EBS-объёма без даунтайма

Всем DevOps! Сегодня разберём, как упростить жизнь, если диск внезапно “упирается” в предел.

Когда EBS-том на AWS почти заполняется, большинство команд обновляют размер вручную — через консоль или CLI. Это рутинно, медленно и иногда приводит к задержкам в проде. Автор одного из свежих гайдов показал, как полностью автоматизировать процесс расширения.

Вот ключевые шаги, которые он предлагает:

• Использовать CloudWatch для отслеживания порогового заполнения тома
• С помощью Lambda вызывать скрипт, который увеличивает EBS-объём
• Прописать событие в EventBridge для регулярной проверки
• После изменения размера инициировать расширение на уровне файловой системы
• Настроить уведомления (SNS), чтобы команда знала о срабатывании

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

🗄Если хотите внедрить у себя:
• Не полагайтесь на device names — используйте VolumeId. CloudWatch его не даёт, поэтому лучше резолвить через SSM.
• Выберите один интеграционный паттерн и настройте его корректно (например, Alarm → SNS → Lambda).
• Держите курс на безопасность: уберите “first volume” fallback, добавьте идемпотентность, чёткие алармы и логи.

Итог: автоматизация EBS через алармы работает стабильно. Если правильно продумать интеграцию и добавить защитные проверки, у решения нет минусов — только ускорение и предсказуемость.

#devops #aws #infrastructure

Legacy vs прогресс: как работать с системами прошлого

👤На Reddit обсудили боль DevOps-инженеров: как работать с системами, которые устарели пять лет назад и блокируют внедрение новых решений.
Каждое обновление с Legacy-системами превращается в квест: старые решения не интегрируются с современными процессами, руководство действует по правилу "не чини, если не сломано", инженеры тратят силы на сопровождение устаревшей инфраструктуры вместо развития.

Что предлагают коллеги?

jbandinixx:если не можешь уничтожить, заставь их работать на тебя. Оберни в API, автоматизируй рутину и устраняй проблемы по частям. Для повторяющихся задач (ввод данных, создание аккаунтов, планирование и т.д.) инструменты вроде Cyberdesk реально помогают снять часть нагрузки.

sysadmintemp: старое редко умирает, потому что всё ещё используется, а новое ПО не покрывает все сценарии. Автоматизируй процессы. У нас была C++ .exe программа, мы обернули её в Python API и загрузили рабочую версию в артефакт-репозиторий. Это позволило разворачивать ПО с актуальным Python-кодом и часто обновлять хост.

elucify: мне понадобилось 3 года, чтобы убедить руководство поменять систему. Менеджменту не нужны проблемы, им нужны решения с цифрами.

sschueller: по-нашему “модернизация” — это упаковать умирающий сервер в Docker и кинуть его в облако.

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

С какими сложностями вы сталкиваетесь при работе с legacy системами?

#devops #reddit #legacy

👩‍💻 Автоматическое восстановление служб в Kubernetes — контроль, прозрачность и спокойный сон

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

Что внедрить первым?
- Экспорт метрик и базовые алерты в тестовом namespace.
- Оператор расширения дискового пространства в dry-run с трассировкой действий.
- Сценарии отказов в staging: full-disk, failed-resize, node-failure.

🤝После базовой настройки включаем контроль.
Что проверить?
- Snapshots перед изменениями.
- Ограничение параллельных операций.
- Метрики эффективности: MTTR, число автопочиненных инцидентов, вмешательств оператора.

📎 Совет: встраивайте автоматизацию с runbooks и audit-логами рядом — так автоматические действия остаются прозрачными и воспроизводимыми. Читайте весь гайд по ссылке.

👩‍💻 Делимся репозиториями:
• Draino — оператор от Planet Labs, который автоматически изолирует и очищает (cordon/drain) узлы Kubernetes, когда они переходят в неработоспособное состояние.
• Volume Expander Operator — проект от Red Hat COP для автоматического расширения Persistent Volumes при достижении порога заполнения.

#devops #kubernetes #storage #autoremediation

Авто-ресурсы в Kubernetes, Pulumi NEO и Google MCP: инфраструктура на автопилоте

🔔Всем срединедельный DevOps! Обсудим свежие апдейты авто-выделения ресурсов в K8s и инструментов GitOps. Полезно тем, кто хочет меньше крутить кластеры вручную.

🟡 Kubernetes 1.34 и динамическое выделение ресурсов
В версии Kubernetes 1.34 кластер сам подбирает ресурсы GPU, CPU и I/O под конкретные задачи — без необходимости заранее прописывать лимиты в PodSpec. Теперь через API можно запрашивать устройства с нужными параметрами (тип GPU, версия CUDA, объём памяти) — и Kubernetes подберёт подходящее оборудование.
Это снижает долю простаивающих ресурсов, особенно при ML- и AI-нагрузках, где требования к железу меняются на лету.

⚫️ Pulumi NEO упрощает GitOps
Pulumi NEO читает IaC-код, сам формирует план изменений инфраструктуры, проверяет его через Policy as Code и применяет. Он понимает зависимости, окружения и может откатывать изменения без ручного kubectl apply. Полезен, когда GitOps-потоки разрастаются, а ручное управление окружениями тормозит релизы.

🟡 Google MCP для баз данных
Google представил MCP Toolbox — серверный набор инструментов, который реализует MCP для безопасной автоматизации доступа к базам данных. SQL-операции задаются декларативно в tools.yaml , а MCP управляет подключениями, пулами и правами доступа. Поддерживает Cloud SQL, AlloyDB, Spanner, PostgreSQL и MySQL. Система следит за нагрузкой, масштабирует кластеры и перестраивает схемы без ручного вмешательства DBA. Ещё один шаг к инфраструктуре, где всё крутится само.

#DevOps #Kubernetes #SRE

Kubernetes под микроскопом: как SPO видит действия пользователей

👩‍💻Всем DevOps! Сегодня поговорим о том, как отслеживать, что происходит внутри контейнеров в Kubernetes. В стандартной конфигурации Kubernetes аудит фиксирует только действия на уровне API: кто применил kubectl exec или kubectl debug. Что именно происходило внутри pod’а после входа в контейнер увидеть нельзя. Эту проблему решает Security Profiles Operator (SPO) — отслеживайте действия пользователей и процессов внутри pod’ов и на узлах.

🔄Принцип работы
SPO использует системные источники данных — например, /var/log/audit/audit.log и /proc/<pid>. Каждое событие записывается в JSON-формате, а JSON Enricher связывает его с соответствующим API-запросом через request UID. Это позволяет восстановить полную цепочку: API-запрос → контейнер → процесс → результат

🔓Как включить Security Profiles Operator?
- Установите cert-manager
Он нужен для автоматического управления сертификатами, используемыми SPO.
- Разверните Security Profiles Operator
Используйте официальный манифест из подборки репозиториев.
- Настройте хранение логов
SPO может сохранять логи: локально на узле (по умолчанию в /var/log/security-profiles-operator/ ), в общем томе (PVC), или выводить в stdout — удобно для интеграции с системами сбора логов вроде Loki или Elasticsearch;
- Включите JSON Enricher
Он обогащает события дополнительной информацией о процессе.
- Настройте seccomp-профиль для отслеживания системных вызовов
Он фиксирует вызовы вроде execve и clone, а объект ProfileBinding применяет профиль ко всем pod’ам в выбранном пространстве имён ( namespace ).

📎Репозитории с инструкциями по установке:
audit-logging-guide — описывает, как включить аудит действий внутри pod’ов и узлов через Security Profiles Operator.
installation-usage — показывает, как установить Security Profiles Operator и применить seccomp-профили к pod’ам.

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

#devops #kubernetes #spo

Пятничная подборка подкастов: от AI в инфраструктуре до архитектурных решений

🗣В эту пятницу будет, что послушать DevOps-инженеру. Делимся свежей подборкой подкастов.

⏺Готова ли инфраструктура к AI? Разбираем на практике — DevOps Paradox #319
Ведущие Дарин Поуп и Виктор Фарчик подчеркивают, разницу между ожиданиями разработчиков AI-платформ и реальностью на примере кейсов. Главным барьером в работе они называют отсутствие опыта взаимодействия с агентами и векторными базами данных.

⏺Workload identity: меньше ручного контроля, больше прозрачности — Day Two DevOps #284
Ведущий Нед Беллаванс и гость Кристиан Поста обсуждают, как сервисы и агенты взаимодействуют между собой без участия человека. Разбирают, как работают workload identities — цифровые удостоверения, по которым системы подтверждают подлинность и права доступа друг к другу.

⏺Лидерство и инженерные решения — Azure & DevOps Podcast
Джимас Стейли беседует с Джонатаном Джей Тауэром, Microsoft MVP и основателем Trailhead Technology Partners о том, как техническим лидерам принимать осознанные решения, исходя из целей продукта. Говорят о кейсе, в котором отказ от микросервисов в пользу простой архитектуры ускорил релизы и снизил затраты на поддержку.

👍Пусть сервисы не падают, а кофе не заканчивается! Хороших выходных и приятного прослушивания.

#devops #подкаст #AI #лидерство

Макросы в коде: что стоит учитывать при ревью и CI/CD

👩‍💻Линус Торвальдс прошёлся по коду, где был предложен макрос make_u32_from_two_u16()— инструмент для объединения двух 16-битных чисел в одно 32-битное. На первый взгляд, решение удобно, но Линус назвал реализацию "мусорной": такая абстракция усложняет понимание и сопровождение кода.

Как улучшить код и ревью
⏺Используйте явную запись
Прямое выражение показывает порядок и логику:



((uint32_t)a << 16) | (uint32_t)b

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

⏺Следите за переносимостью
Добавляйте приведения типов и маскирование, чтобы избежать ошибок на разных архитектурах:

#define MAKE_U32_FROM_TWO_U16(high, low) \
    (((uint32_t)(high) << 16) | ((uint32_t)(low) & 0xFFFF))



⏺Сохраняйте ясность и локальность изменений
Если нужна общая утилита — поместите её в отдельный модуль и документируйте назначение. Так, вы снижаете вероятность конфликтов и улучшаете читаемость кода.

⏺Используйте ИИ-инструменты осознанно
Генераторы кода (ChatGPT, Gemini и пр.) могут предложить готовое решение, но итоговый вариант важно проверять: читаемость, переносимость, соответствие стилю проекта — всё это остаётся задачей разработчика.

Даже небольшие абстракции требуют осознанного подхода.
Если операция проста, прозрачна и понятна, лучше записать её явно. Так, код становится надёжнее, ревью — быстрее, а CI/CD-процессы — стабильнее.

#DevOps #Linux #CICD

Helm исполнилось 10 лет!

🔅Это повод вспомнить, как всё начиналось.

Идея родилась во время хакатона: за полтора дня Мэтт Бутчер создал CLI-утилиту для взаимодействия с Kubernetes, Джэк Норман разработал серверный прототип менеджера пакетов k8space, а Римантас Моцевичюс подготовил первый чарт — набор шаблонов YAML.

19 октября 2015 года был сделан первый коммит. Так появился внутренний проект Helm Classic, который объединили с Google Deployment Manager. После этого появился Helm, знакомый нам сегодня.

За десять лет инструмент прошёл путь от прототипа до полноценной экосистемы с поддержкой:
• чартов (пакетов с шаблонами YAML)
• системы репозиториев и версионирования
• шаблонизации и параметров конфигурации
• управления релизами и откатами
• интеграции в CI/CD

В 2018 году проект вошёл в состав CNCF и продолжил развиваться как одно из ключевых решений для cloud-native инфраструктур.

О названии.
🖼️Выбор был сделан не случайно: helm – «штурвал». Kubernetes казался штормовым морем, а инструмент – помощником в управлении.

Для тех, кто любит погружаться в историю – советуем прочесть очерк сооснователя, путь от альфы до v4 Beta Glory.

Хороших выходных и спокойного дежурства! ⚓️

#devops #kubernetes #helm

Docker vs. Kubernetes — от изолированных контейнеров к единой среде

🔄Сегодня разбираем, почему одного контейнера недостаточно для обмена данными между процессами внутри Pod.

Контейнер запускает приложение как отдельный процесс: отдельный сетевой стек (IP, интерфейсы и маршруты), своё PID-пространство и управление ресурсами через cgroups (CPU и память). Эти механизмы изолируют и сохраняют предсказуемость работы — один процесс, один контейнер.

На практике несколько процессов работают параллельно, обмениваются данными и используют общие ресурсы. Например, основной контейнер выполняет приложение, а вспомогательный (sidecar) собирает логи, проксирует трафик или ведёт метрики.

📱В статье от iximiuz Labs дан подробный разбор того, как Kubernetes реализует Pods на уровне Linux и можно ли воспроизвести функциональность Pod в чистом Docker.
Спойлер: можно, если вручную подключить сетевые и IPC namespace, но не всё получится — UTS, например, остаётся изолированным.

Полный разбор здесь ⬅️, а ниже — практика от iximiuz Labs
• Run a Sidecar Container in the Namespace of Another Container— проверь, как контейнеры делят namespace, как в Pod.
• Limit CPU and Memory Usage of a Docker Compose Application — узнай, как задать лимиты CPU и памяти через cgroups.

#devops #kubernetes #containers #pods

От Talos до Vault: обзор обновлений инфраструктуры и секретов

Срединедельный DevOps! Публикуем дайджест релизов и новостей.

⚫️ Talos OS и Kubernetes: операционная выгода и риски
SNCF разворачивает Kubernetes с Talos OS в OpenStack, чтобы повысить безопасность узлов, стандартизировать образы и упростить автоматизированное развертывание. Переход потребовал создания новых облачных команд и внедрения практик GitOps с неизменяемой инфраструктурой. Подробнее в статье.

🟡 Разбираем Vault 1.21 — SPIFFE, VSO и granular recovery в действии
Vault 1.21 добавил SPIFFE-аутентификацию для рабочих нагрузок без участия инженеров, детализированное восстановление секретов (granular secret recovery), настройку TOTP и защищённую выдачу секретов через VSO — доставку данных в поды без сохранения в etcd. Среди улучшений — движение к сертификации FIPS 140-3 уровня 1. Разбираем, как Vault 1.21 меняет подход к управлению идентичностями и секретами.

⚫️ Корпоративная почта — быстрый техобзор и что проверить
Обновлённое руководство: читаем зачем бизнесу доменная почта, как выбрать между облачным сервисом, хостингом и собственным сервером, а также какие настройки помогают избежать попадания писем в спам. Для DevOps-специалистов полезно с точки зрения конфигурации DNS, контроля безопасности и стабильности почтовой инфраструктуры. Что проверить – в статье.

🔓Безопасных запусков и прозрачного управления секретами

#DevOps #Vault #TLS #EmailSecurity