Пятничная подборка подкастов: от 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 #лидерство
⏺Готова ли инфраструктура к AI? Разбираем на практике — DevOps Paradox #319
Ведущие Дарин Поуп и Виктор Фарчик подчеркивают, разницу между ожиданиями разработчиков AI-платформ и реальностью на примере кейсов. Главным барьером в работе они называют отсутствие опыта взаимодействия с агентами и векторными базами данных.
⏺Workload identity: меньше ручного контроля, больше прозрачности — Day Two DevOps #284
Ведущий Нед Беллаванс и гость Кристиан Поста обсуждают, как сервисы и агенты взаимодействуют между собой без участия человека. Разбирают, как работают workload identities — цифровые удостоверения, по которым системы подтверждают подлинность и права доступа друг к другу.
⏺Лидерство и инженерные решения — Azure & DevOps Podcast
Джимас Стейли беседует с Джонатаном Джей Тауэром, Microsoft MVP и основателем Trailhead Technology Partners о том, как техническим лидерам принимать осознанные решения, исходя из целей продукта. Говорят о кейсе, в котором отказ от микросервисов в пользу простой архитектуры ускорил релизы и снизил затраты на поддержку.
#devops #подкаст #AI #лидерство
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5🔥5❤3
Макросы в коде: что стоит учитывать при ревью и CI/CD
👩💻 Линус Торвальдс прошёлся по коду, где был предложен макрос
Как улучшить код и ревью
⏺ Используйте явную запись
Прямое выражение показывает порядок и логику:
⏺ Добавляйте абстракции только при необходимости
Макросы и функции избавляют от дублирования или повышают безопасность, а не просто «упаковывают» очевидные выражения.
⏺ Следите за переносимостью
Добавляйте приведения типов и маскирование, чтобы избежать ошибок на разных архитектурах:
⏺ Сохраняйте ясность и локальность изменений
Если нужна общая утилита — поместите её в отдельный модуль и документируйте назначение. Так, вы снижаете вероятность конфликтов и улучшаете читаемость кода.
⏺ Используйте ИИ-инструменты осознанно
Генераторы кода (ChatGPT, Gemini и пр.) могут предложить готовое решение, но итоговый вариант важно проверять: читаемость, переносимость, соответствие стилю проекта — всё это остаётся задачей разработчика.
Даже небольшие абстракции требуют осознанного подхода.
Если операция проста, прозрачна и понятна, лучше записать её явно. Так, код становится надёжнее, ревью — быстрее, а CI/CD-процессы — стабильнее.
#DevOps #Linux #CICD
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
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍4🔥3❤2
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
Идея родилась во время хакатона: за полтора дня Мэтт Бутчер создал CLI-утилиту для взаимодействия с Kubernetes, Джэк Норман разработал серверный прототип менеджера пакетов k8space, а Римантас Моцевичюс подготовил первый чарт — набор шаблонов YAML.
19 октября 2015 года был сделан первый коммит. Так появился внутренний проект Helm Classic, который объединили с Google Deployment Manager. После этого появился Helm, знакомый нам сегодня.
За десять лет инструмент прошёл путь от прототипа до полноценной экосистемы с поддержкой:
• чартов (пакетов с шаблонами YAML)
• системы репозиториев и версионирования
• шаблонизации и параметров конфигурации
• управления релизами и откатами
• интеграции в CI/CD
В 2018 году проект вошёл в состав CNCF и продолжил развиваться как одно из ключевых решений для cloud-native инфраструктур.
О названии.
Для тех, кто любит погружаться в историю – советуем прочесть очерк сооснователя, путь от альфы до v4 Beta Glory.
Хороших выходных и спокойного дежурства! ⚓️
#devops #kubernetes #helm
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍9❤5
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
Контейнер запускает приложение как отдельный процесс: отдельный сетевой стек (IP, интерфейсы и маршруты), своё PID-пространство и управление ресурсами через cgroups (CPU и память). Эти механизмы изолируют и сохраняют предсказуемость работы — один процесс, один контейнер.
На практике несколько процессов работают параллельно, обмениваются данными и используют общие ресурсы. Например, основной контейнер выполняет приложение, а вспомогательный (sidecar) собирает логи, проксирует трафик или ведёт метрики.
Спойлер: можно, если вручную подключить сетевые и IPC namespace, но не всё получится — UTS, например, остаётся изолированным.
Полный разбор здесь
• 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
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍4🔥4
От 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
Срединедельный 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤3👍2
Какие призраки прячутся в API?
В прошлом мы рассказывали о зомби-ресурсах, сегодня поговорим о приведениях.
👻 Призрачные API — это эндпоинты, о которых команда уже не помнит: устаревшие версии API, тестовые и предрелизные окружения, временные debug -эндпоинты, внутренние маршруты, неиспользуемые SDK-колбэки или микросервисы без владельца. Такие точки входа остаются живыми, но не попадают в мониторинг и тесты — поэтому злоумышленники ищут их в первую очередь.
Как обнаружить:
• анализ кода и скрытых маршрутов;
• перебор и сравнение версий API;
• следы в логах, документации и старых тестах.
Как изгнать:
• Инвентаризация: централизованный каталог API (Swagger/OpenAPI, Postman).
• Политика «Убей, не прячь»: полностью удаляйте ненужные маршруты, не переименовывайте.
• Владение: у каждого эндпойнта — владелец и SLA; без владельца — автоматическое выключение.
👀 Подробности читайте в статье Medium
Делимся подборкой инструментов-охотников:
Pluto — CLI-утилита для обнаружения устаревших/удалённых версий API в Kubernetes-манифестах или кластере
Kubent — аналогично Pluto, CLI-инструмент для K8s. Проверяет кластер и исходники на использование Ghost=deprecated API
👻 Пусть ваши релизы проходят без мёртвого кода и призрачных эндпойнтов
#DevOps #Security #API
В прошлом мы рассказывали о зомби-ресурсах, сегодня поговорим о приведениях.
Как обнаружить:
• анализ кода и скрытых маршрутов;
• перебор и сравнение версий API;
• следы в логах, документации и старых тестах.
Как изгнать:
• Инвентаризация: централизованный каталог API (Swagger/OpenAPI, Postman).
• Политика «Убей, не прячь»: полностью удаляйте ненужные маршруты, не переименовывайте.
• Владение: у каждого эндпойнта — владелец и SLA; без владельца — автоматическое выключение.
Делимся подборкой инструментов-охотников:
Pluto — CLI-утилита для обнаружения устаревших/удалённых версий API в Kubernetes-манифестах или кластере
Kubent — аналогично Pluto, CLI-инструмент для K8s. Проверяет кластер и исходники на использование Ghost=deprecated API
#DevOps #Security #API
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍8❤6🔥6
mypy в Python: типизация и контроль скриптов
👩💻 Сегодня обсудим, как встроить ad-hoc скрипты из ~/bin в предсказуемую и проверяемую автоматизацию. В статье Simple Thread Джо Понд дал руководство по снижению риска ошибок.
В чем кроется проблема?
• Скрипт удобен, но непредсказуем: ошибки типов проявляются только во время выполнения.
• Без явных контрактов функций рефакторинг становится рискованным, растёт технический долг.
• Чем больше людей правят код, тем выше риск регресса и скрытых багов в проде.
Какие решения?
Пошаговое улучшение надежности кода: добавьте статическую типизацию через mypy, управляйте зависимостями через Poetry и запускайте проверки в CI. Так, вы постепенно укрепляете код и минимизируете риски, когда проект расширяется и подключаются новые разработчики.
Как внедрить?
Проверка типов на старте — один файл за раз
• Добавьте в dev-dependencies:
• Запустите проверку для конкретного файла:
Так, вы находите баги до запуска и спокойно приступаете к следующему шагу.
Добавьте mypy в CI/CD
• Создайте окружение через Poetry и проверьте проект mypy
Типы проверяются в пайплайне: ошибки останавливают merge и защищают main branch от багов.
Мигрируйте постепенно
• Переносите типизацию модуль за модулем, начинайте с ключевых утилит и точек входа.
• Нет необходимости переписывать весь проект сразу — можно внедрять статическую проверку там, где она реально нужна.
Для желающих узнать историю развития Python рекомендуем прочесть статью здесь👈
Делимся подборкой репозиториев:
👩💻 python/mypy — анализирует типы для Python, реализует PEP 484. Нужен как эталонный инструмент для проверки контрактов и постепенной типизации кода.
👩💻 tsuyoshicho/action-mypy — готовая GitHub Action для запуска mypy в CI; поддерживает вывод в формате JSON, удобно для интеграции с reviewdog и системами агрегации ошибок
#devops #python #mypy
В чем кроется проблема?
• Скрипт удобен, но непредсказуем: ошибки типов проявляются только во время выполнения.
• Без явных контрактов функций рефакторинг становится рискованным, растёт технический долг.
• Чем больше людей правят код, тем выше риск регресса и скрытых багов в проде.
Какие решения?
Пошаговое улучшение надежности кода: добавьте статическую типизацию через mypy, управляйте зависимостями через Poetry и запускайте проверки в CI. Так, вы постепенно укрепляете код и минимизируете риски, когда проект расширяется и подключаются новые разработчики.
Как внедрить?
Проверка типов на старте — один файл за раз
• Добавьте в dev-dependencies:
poetry add --group dev mypy
• Запустите проверку для конкретного файла:
poetry run mypy main.py
Так, вы находите баги до запуска и спокойно приступаете к следующему шагу.
Добавьте mypy в CI/CD
• Создайте окружение через Poetry и проверьте проект mypy
poetry run mypy .
Типы проверяются в пайплайне: ошибки останавливают merge и защищают main branch от багов.
Мигрируйте постепенно
• Переносите типизацию модуль за модулем, начинайте с ключевых утилит и точек входа.
• Нет необходимости переписывать весь проект сразу — можно внедрять статическую проверку там, где она реально нужна.
Для желающих узнать историю развития Python рекомендуем прочесть статью здесь
Делимся подборкой репозиториев:
#devops #python #mypy
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥10👍5❤4
Что нового в релизах и инструментах: Vitess, Copilot и Monarch
🚀 Традиционно публикуем срединедельный дайджест новостей, чтобы оставаться в курсе важных обновлений.
⚫️ Vitess 23.0.0 — операционная наблюдаемость и стабильное масштабирование
Команда Vitess представила новую основную версию популярного CNCF-проекта для масштабируемых MySQL-кластеров. Релиз Vitess 23.0.0 продолжает линию версии 22 и направлен на упрощение развертывания, повышение стабильности и наблюдаемости в больших инфраструктурах: переход на MySQL 8.4.6; TransactionsProcessed для VTGate, SkippedRecoveries для VTOrc. Подробности обновления читайте в статье блога CNCF.
🟡 GitHub Copilot CLI: ускорение работы с репозиториями
В Copilot добавлена поддержка CLI с доступом к репозиториям, возможностью редактировать файлы, запускать команды и интеграцией с GitHub через учётную запись. Параллельно представлены Copilot Spaces Copilot Spaces — контекстные «пространства» с документацией, примерами и задачами, которые дают агенту релевантный контекст для команды и ускоряют онбординг; CLI и Spaces поддерживают MCP-серверы и смену модели. Всё про GitHub Copilot CLI и Spaces здесь.
⚫️ PyTorch — Monarch упрощает разработку распределённых ML-программ
PyTorch представила Monarch — фреймворк для распределённого программирования, который позволяет работать с целыми кластерами GPU. Monarch упрощает разработку распределённых ML-программ: код остаётся похожим на обычный Python/PyTorch-скрипт, при этом масштабируется на тысячи GPU, облегчая написание распределённых алгоритмов, обработку сбоев и управление ресурсами. Читайте статью здесь.
Стабильных кластеров и эффективного онбординга команды!🤝
#Vitess #Observability #Copilot
⚫️ Vitess 23.0.0 — операционная наблюдаемость и стабильное масштабирование
Команда Vitess представила новую основную версию популярного CNCF-проекта для масштабируемых MySQL-кластеров. Релиз Vitess 23.0.0 продолжает линию версии 22 и направлен на упрощение развертывания, повышение стабильности и наблюдаемости в больших инфраструктурах: переход на MySQL 8.4.6; TransactionsProcessed для VTGate, SkippedRecoveries для VTOrc. Подробности обновления читайте в статье блога CNCF.
🟡 GitHub Copilot CLI: ускорение работы с репозиториями
В Copilot добавлена поддержка CLI с доступом к репозиториям, возможностью редактировать файлы, запускать команды и интеграцией с GitHub через учётную запись. Параллельно представлены Copilot Spaces Copilot Spaces — контекстные «пространства» с документацией, примерами и задачами, которые дают агенту релевантный контекст для команды и ускоряют онбординг; CLI и Spaces поддерживают MCP-серверы и смену модели. Всё про GitHub Copilot CLI и Spaces здесь.
⚫️ PyTorch — Monarch упрощает разработку распределённых ML-программ
PyTorch представила Monarch — фреймворк для распределённого программирования, который позволяет работать с целыми кластерами GPU. Monarch упрощает разработку распределённых ML-программ: код остаётся похожим на обычный Python/PyTorch-скрипт, при этом масштабируется на тысячи GPU, облегчая написание распределённых алгоритмов, обработку сбоев и управление ресурсами. Читайте статью здесь.
Стабильных кластеров и эффективного онбординга команды!
#Vitess #Observability #Copilot
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥6👍5❤3
Когда стоит внедрять mypy в Python-проект?
👤 В продолжении темы поста о типизации и контроле скриптов, публикуем обсуждение на Reddit: имеет ли смысл подключать type hints и mypy или проще с самого начала выбрать язык со статической типизацией?
Что говорят коллеги?
💬 Итак, никаких категоричных решений, только прагматичный подход: продолжайте использовать Python из-за широкой экосистемы и доступности специалистов, а type hints и mypy внедряйте по случаю, когда проект масштабируется, растёт команда и требуется предсказуемость.
На каких этапах вы внедряете type hints и mypy?
#Python #mypy #reddit
Что говорят коллеги?
Tinche_: Невозможно свести всё к одному аргументу — слишком много переменных. Python — не только про динамическую типизация. Был у меня случай, руководил крупным проектом с десятками миллионов долларов прибыли. В ходе работы я мигрировал от неаннотированного кода к почти полной типизации на уровне аннотаций с mypy. Получил с этого плюшки, но для такого перехода опыт и план обязательны
IWasGettingThePaper: Типы не устраняют баги навсегда и не заменяют тесты. MyPy помогает выявить часть ошибок, не так много, как хотелось бы, и улучшает читаемость кода, но статическая проверка — не серебряная пуля
DadAndDominant: Как человек не рождается взрослым, так и компании развиваются постепенно. На старте важнее всего быстрое прототипирование, пусть даже что-то работает лишь в 90% случаев — это всё равно позволяет выпускать продукт.
Когда проект разрастается, увеличивается кодовая база, нанимаются новые люди, а технический долг начинает съедать время разработчиков, приходят автоматические тесты, гайды по стилю и mypy — без них уже сложнее нормально релизить.
Ну и есть другие факторы при выборе языка, так что всё зависит от контекста.
На каких этапах вы внедряете type hints и mypy?
#Python #mypy #reddit
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤6👍5🔥4
В гостях хорошо, а дома Astra Linux
⌨️ Мир меняется, и мы уже наблюдаем переход с зарубежного софта на российские программные разработки. Сегодня поговорим об одной из альтернатив: отечественная ОС Astra Linux.
В чём особенность?
Astra Linux – первая в топ-5 ОС по результатам рейтинга cnews. Из параметров оценки у Астры высокое количество партнерских совместимых программных продуктов, максимальный уровень безопасности (ФСТЭК), что обеспечивает стабильность работы ИТ-структур. Ключевая особенность Astra Linux — она сертифицирована как СЗИ в достаточно свежей версии, что выгодно отличает её от других отечественных вендоров, у которых сертификация обычно отстаёт.
❔ В каких вариантах представлена?
Важно отметить, что Astra Linux Common Edition — это ОС общего пользования, которая всё ещё доступна для физических лиц, но уже неактуальна и не получает обновлений: она основана на Debian 9. Эта версия больше не поддерживается официально и сегодня может служить инструментом для ознакомления с экосистемой Astra Linux .
Astra Linux Special Edition, ОС специального назначения, актуальный коммерческий вариант. Для желающих узнать об установке, настройке и сопровождении – справочная здесь. Ниже речь пойдет именно об этом варианте ОС.
📎Что дальше?
Как осуществить индивидуальную настройку пользователей читайте тут
Данные о настройке модемного подключения найдёте здесь
Что думаете об отечественных ОС? Насколько интересны обзоры Альта, Ред ОС и ОСновы?
#AstraLinux #обзор #отечественнаяОС
В чём особенность?
Astra Linux – первая в топ-5 ОС по результатам рейтинга cnews. Из параметров оценки у Астры высокое количество партнерских совместимых программных продуктов, максимальный уровень безопасности (ФСТЭК), что обеспечивает стабильность работы ИТ-структур. Ключевая особенность Astra Linux — она сертифицирована как СЗИ в достаточно свежей версии, что выгодно отличает её от других отечественных вендоров, у которых сертификация обычно отстаёт.
Важно отметить, что Astra Linux Common Edition — это ОС общего пользования, которая всё ещё доступна для физических лиц, но уже неактуальна и не получает обновлений: она основана на Debian 9. Эта версия больше не поддерживается официально и сегодня может служить инструментом для ознакомления с экосистемой Astra Linux .
Astra Linux Special Edition, ОС специального назначения, актуальный коммерческий вариант. Для желающих узнать об установке, настройке и сопровождении – справочная здесь. Ниже речь пойдет именно об этом варианте ОС.
📎Что дальше?
Как осуществить индивидуальную настройку пользователей читайте тут
Данные о настройке модемного подключения найдёте здесь
Что думаете об отечественных ОС? Насколько интересны обзоры Альта, Ред ОС и ОСновы?
#AstraLinux #обзор #отечественнаяОС
Please open Telegram to view this post
VIEW IN TELEGRAM
1👎23👍11❤6🤣6🔥5
Инфраструктура для ИИ-сервисов: Linkerd получает MCP, Европа — свою LLM, GitHub — центр управления агентами
Всем DevOps! По традиции, делимся новостями. В прошлый раз у нас сработал алерт: часть источников устарела. Починили, обновили, задеплоили новую срединедельную подборку — свежие релизы и актуальные данные.
⏺ Linkerd — поддержка MCP
Buoyant (BTI) объявила о планах добавить в Linkerd поддержку протокола MCP, чтобы сервис-меш управлял агентским ИИ трафиком: обеспечивал наблюдаемость (метрики использования ресурсов, инструментов и запросов), детальную политику авторизации для всех вызовов MCP, и защиту через идентификаторов рабочей нагрузки. По словам компании, это снизит потребность в отдельных прокси и инструментах мониторинга, а больше деталей об анонсе можете найти здесь.
⏺ EuroLLM: шаг ЕС к независимой цифровой среде
В Европе появился EuroLLM — открытая языковая модель многоязычной (multilingual) LLM, рассчитанная на 24 официальные языка ЕС. EuroLLM подходит для локальных экспериментов, кастомизации и повышенной прозрачности, необходимых в рамках политики повышения цифровой автономности. Подробнее об особенностях здесь.
⏺ Agent HQ от GitHub: единый инструмент для работы с ИИ-агентами
GitHub запустил Agent HQ – инструмент для работы с ИИ-агентами. Идея проста: вместо работы с каждым агентом отдельно, теперь можно назначать задачи, отслеживать их выполнение и управлять поведением ИИ из одного интерфейса. В ближайшие месяцы на GitHub станут доступны агенты от OpenAI, Google, Anthropic, Cognition и других, всё это в рамках подписки Copilot Pro+. Про формат подписки здесь.
#Linkerd #EuroLLM #AgentHQ #DevOps
Всем DevOps! По традиции, делимся новостями. В прошлый раз у нас сработал алерт: часть источников устарела. Починили, обновили, задеплоили новую срединедельную подборку — свежие релизы и актуальные данные.
Buoyant (BTI) объявила о планах добавить в Linkerd поддержку протокола MCP, чтобы сервис-меш управлял агентским ИИ трафиком: обеспечивал наблюдаемость (метрики использования ресурсов, инструментов и запросов), детальную политику авторизации для всех вызовов MCP, и защиту через идентификаторов рабочей нагрузки. По словам компании, это снизит потребность в отдельных прокси и инструментах мониторинга, а больше деталей об анонсе можете найти здесь.
В Европе появился EuroLLM — открытая языковая модель многоязычной (multilingual) LLM, рассчитанная на 24 официальные языка ЕС. EuroLLM подходит для локальных экспериментов, кастомизации и повышенной прозрачности, необходимых в рамках политики повышения цифровой автономности. Подробнее об особенностях здесь.
GitHub запустил Agent HQ – инструмент для работы с ИИ-агентами. Идея проста: вместо работы с каждым агентом отдельно, теперь можно назначать задачи, отслеживать их выполнение и управлять поведением ИИ из одного интерфейса. В ближайшие месяцы на GitHub станут доступны агенты от OpenAI, Google, Anthropic, Cognition и других, всё это в рамках подписки Copilot Pro+. Про формат подписки здесь.
#Linkerd #EuroLLM #AgentHQ #DevOps
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤6👍5🔥5
Пятничная подборка: Jupyter, оптимизация ИИ-нагрузок в Kubernetes и облачные тренды
Сегодня в эфире подборка подкастов, в которых эксперты обсуждают эволюцию Project Jupyter, распределение расходов ИИ-сервисов в новой версии Kubernetes, тренды ИИ в облаке.
⏺ DOP 324:Kubernetes Resource Right-Sizing and Scaling with Zesty
Приглашенный гость Омар Хамерман, IT-архитектор Zesty.co, совместно с ведущими Дарином Поупом и Виктором Фарциком говорят о возможностях управления нагрузками ИИ в Kubernetes версии 1.33. Основное внимание уделяют автоматическому масштабированию. Послушать можно здесь.
⏺ From Physics to the Future: Brian Granger on Project Jupyter in the Age of AI
Брайн Грэнджер совместно с главным редактором издания The New Stack (TNS) рассмотрели развитие архитектуры Jupyter, построенной на модульных и расширяемых компонентах, роль ИИ-агентов в разработке приложения. Больше подробностей тут.
⏺ The CloudCast: AI & Cloud Trends for October 2025
Брайн Грэйсли и Брэндон Уичард разобрали тренды за последний месяц: анонсы от провайдеров, изменения в экосистемах OpenAI и вопросы безопасности облачной инфраструктуры. Подробнее здесь.
🔈 Желаем приятного прослушивания и дежурств без алертов!
#kubernetes #jupyter #cloud #подкасты
Сегодня в эфире подборка подкастов, в которых эксперты обсуждают эволюцию Project Jupyter, распределение расходов ИИ-сервисов в новой версии Kubernetes, тренды ИИ в облаке.
Приглашенный гость Омар Хамерман, IT-архитектор Zesty.co, совместно с ведущими Дарином Поупом и Виктором Фарциком говорят о возможностях управления нагрузками ИИ в Kubernetes версии 1.33. Основное внимание уделяют автоматическому масштабированию. Послушать можно здесь.
Брайн Грэнджер совместно с главным редактором издания The New Stack (TNS) рассмотрели развитие архитектуры Jupyter, построенной на модульных и расширяемых компонентах, роль ИИ-агентов в разработке приложения. Больше подробностей тут.
Брайн Грэйсли и Брэндон Уичард разобрали тренды за последний месяц: анонсы от провайдеров, изменения в экосистемах OpenAI и вопросы безопасности облачной инфраструктуры. Подробнее здесь.
#kubernetes #jupyter #cloud #подкасты
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥6❤4👍4
Как работать с Docker Networking: концепции и применение
👩💻 Автор статьи описывает классический случай из практики с Docker: разработчик запускает контейнер, подключается к нему через
На деле Docker уже делает всю работу – ниже расскажем об основном, подробнее найдете в статье.
👀 Почему проблема возникла?
При установке Docker создает дефолтный сетевой мост (network-bridge), где он выстраивает коммуникацию по временным IP таким образом, что многоконтейнерные приложения становятся неудобными: разработчик не находит сервисы по имени, и каждый перезапуск меняет адреса контейнеров.
⏺ Как решать?
Для устранения проблемы автор предлагает использовать user-defined bridge сети. При создании такой сети Docker автоматически включает внутренний DNS, и контейнеры получают постоянные hostname. Всё, что потребуется от разработчика – запустить контейнеры и подключить их к одной сети, чтобы приложение могло обращаться к базе по имени к БД, независимо от IP и рестарта контейнера.
Контейнеры с user-defined bridge
Контейнер со статическим IP и объявленная сеть
Для выполнения данного решения разработчик создает пользовательскую bridge-сеть с объявленным пулом адресов (subnet) и назначением контейнеру фиксированного IPv4 через ipv4_address. Так, мы обеспечиваем предсказуемую адресацию, полезную для интеграции с системой, которая зависит от IP. При этом сеть сохраняет встроенный DNS Docker, позволяющий обращаться к контейнерам по имени.
🚀 Вывод: для многоконтейнерных приложений не стоит использовать дефолтный bridge. Создавайте собственные сети или пользуйтесь Docker Compose, чтобы надёжно связать сервисы по их именам, а не по временным IP-адресам.
#devops #docker #dockercompose #networking #containers
localhost и…возникает проблема. Веб-сервис развёрнут в одном контейнере, БД — в отдельном. Как настроить сетевое взаимодействие между ними? На деле Docker уже делает всю работу – ниже расскажем об основном, подробнее найдете в статье.
При установке Docker создает дефолтный сетевой мост (network-bridge), где он выстраивает коммуникацию по временным IP таким образом, что многоконтейнерные приложения становятся неудобными: разработчик не находит сервисы по имени, и каждый перезапуск меняет адреса контейнеров.
Для устранения проблемы автор предлагает использовать user-defined bridge сети. При создании такой сети Docker автоматически включает внутренний DNS, и контейнеры получают постоянные hostname. Всё, что потребуется от разработчика – запустить контейнеры и подключить их к одной сети, чтобы приложение могло обращаться к базе по имени к БД, независимо от IP и рестарта контейнера.
Контейнеры с user-defined bridge
services:
app2:
image: nginx
networks:
- mybridge
app3:
image: alpine
command: ["sh", "-c", "while true; do sleep 3600; done"]
networks:
- mybridge
networks:
mybridge:
driver: bridge
Контейнер со статическим IP и объявленная сеть
Для выполнения данного решения разработчик создает пользовательскую bridge-сеть с объявленным пулом адресов (subnet) и назначением контейнеру фиксированного IPv4 через ipv4_address. Так, мы обеспечиваем предсказуемую адресацию, полезную для интеграции с системой, которая зависит от IP. При этом сеть сохраняет встроенный DNS Docker, позволяющий обращаться к контейнерам по имени.
services:
app:
image: nginx
networks:
custom_net:
ipv4_address: 172.20.0.10
networks:
custom_net:
driver: bridge
ipam:
config:
- subnet: 172.20.0.0/24
#devops #docker #dockercompose #networking #containers
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤9👍9🔥6
Сбой Cloudflare, EOL Ingress NGINX и релиз Sprout
Свежий новостной дайджест от DevOps FM.
⏺ Масштабный сбой в облаке – Cloudflare
Cloudflare объявила, что сбой 18 ноября, из-за которого частично не работали ChatGPT, Claude, Spotify, X и другие сервисы, был вызван latent bug в компоненте, который отвечает за защиту от ботов. Пользователи по всему миру наблюдали ошибки 500 Internal Server Error при попытке зайти на сайт. Подробнее о проблеме здесь.
⏺ Ingress NGINX уходит в прошлое: что нас ждёт
В настоящий момент проект находится на best-effort-поддержке, а уже в марте 2026 года поддержка Ingress NGINX будет остановлена, дальнейшие релизы, исправление багов прекращаются. Репозитории GitHub сохранятся в режиме read-only. SIG Network и Security Response Committee рекомендуют всем пользователям немедленно начать миграцию на Gateway API или другой Ingress-контроллер. Почему – читайте здесь.
⏺ Edera выпускает open-source версию Sprout
Edera, компания известная своими решениями в области безопасности, такими как Protect Kubernetes, анонсировала выход open-source версии Sprout, загрузчика ОС на базе Rust. По словам Edera, Sprout обеспечивает высокий уровень безопасности, запуск системы за <50 мс и простой механизм управления для любой ОС, про особенности читайте здесь.
#Cloudflare #Sprout #Rust #NGINX
Свежий новостной дайджест от DevOps FM.
Cloudflare объявила, что сбой 18 ноября, из-за которого частично не работали ChatGPT, Claude, Spotify, X и другие сервисы, был вызван latent bug в компоненте, который отвечает за защиту от ботов. Пользователи по всему миру наблюдали ошибки 500 Internal Server Error при попытке зайти на сайт. Подробнее о проблеме здесь.
В настоящий момент проект находится на best-effort-поддержке, а уже в марте 2026 года поддержка Ingress NGINX будет остановлена, дальнейшие релизы, исправление багов прекращаются. Репозитории GitHub сохранятся в режиме read-only. SIG Network и Security Response Committee рекомендуют всем пользователям немедленно начать миграцию на Gateway API или другой Ingress-контроллер. Почему – читайте здесь.
Edera, компания известная своими решениями в области безопасности, такими как Protect Kubernetes, анонсировала выход open-source версии Sprout, загрузчика ОС на базе Rust. По словам Edera, Sprout обеспечивает высокий уровень безопасности, запуск системы за <50 мс и простой механизм управления для любой ОС, про особенности читайте здесь.
#Cloudflare #Sprout #Rust #NGINX
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9❤4🔥3 2
DevOps FM празднует!
🎙 Завтра, 22.11.25, исполняется 4 года с тех пор, как мы делимся с вами свежими релизами и подборками из мира DevOps и администрирования!
Спасибо, что читаете нас, даёте обратную связь в комментариях, ставите реакции и репостите актуальные материалы💟 А мы продолжим совершенствоваться: делать посты еще полезнее и увлекательнее :)
Мы всегда рады услышать ваше мнение: по всем пожеланиям и предложениям пишите в комментарии или напрямую → @b_vls.
Cделаем DevOps FM лучше вместе🤝
Спасибо, что читаете нас, даёте обратную связь в комментариях, ставите реакции и репостите актуальные материалы
Мы всегда рады услышать ваше мнение: по всем пожеланиям и предложениям пишите в комментарии или напрямую → @b_vls.
Cделаем DevOps FM лучше вместе
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍11🔥7❤3 1
Что вам больше всего запомнилось?
Anonymous Poll
30%
Статьи на habr: настройки LEMP-сервера, безопасность кластера k8s (олдскулы свело 👀 )
29%
Полезные разборы и подборки репозиториев на GitHub 👩💻
30%
Свежие новостные дайджесты: от падений до релизов 👩💻
12%
Пятничное чтиво, подкасты и чилл-аут 🟡
❤6👍4🔥4
Логирование и мониторинг — топ-3 инструмента для DevOps в 2025
🗣 Несложно представить ситуацию: трафик на пике, API выдает 500-е ошибки. Вы заходите на сервер по SSH, суматошно переходите из директории в директорию, пытаетесь разобраться в веренице логов микросервисов и в конце находите виновника. Спустя время сбой устранили, но вопрос остался – «неужели нельзя проще?». Отвечаем – можно, с инструментами observability.
🚀 Топ-3 инструмента для логирования и мониторинга:
1.Grafana Loki
Плюсы:
• Минимальные расходы: Loki не индексирует содержимое логов, используя только метки (labels) — как в Prometheus. Это снижает потребление CPU, RAM и дискового пространства.
• Тесная интеграция с Prometheus и Grafana: Если вы уже используете Grafana или Prometheus, например в рамках KubePrometheusStack, то вам может быть полезна возможность просматривать логи там же, где и метрики.
• Простота развёртывания и масштабирования: monolithic mode идеально подходит для старта, так как объединяет в рамках одно бинарного файла все компоненты Loki. Но как только вам его не хватает, советуем перейти на микросервисный режим, разделив Distributor, Ingester, Querier и Compactor на отдельные сервисы
• Гибкий язык запросов: LogQL похож на PromQL, что позволяет проводить агрегаций и подсчёт ошибок за период времени, а затем выводить панели с количеством ошибок, рейтами и распределениями в Grafana.
💬 Что учесть
Однако, Loki разработан для фильтрации логов на основе меток и регулярных выражений, а не для глубокого полнотекстового поиска и не позволяет справляться со сложным анализом логов.
2. Elastic Stack
Плюсы:
• Настройка на всех уровнях: от сбора данных с помощью Logstash или Beats до запросов и дашбордов в Kibana — почти все можно настроить
• Мощный поиск и аналитика: Elasticsearch обеспечивает быстрый полнотекстовый поиск и агрегацию в больших масштабах
• Работа в реальном времени: данные индексируются и становятся доступны для поиска почти мгновенно
Гибкость индексации и управления данными: в Elasticsearch есть возможность настраивать ILM (Index Lifecycle Management) - автоматически перемещать "тёплые" и "холодные" данные между нодами, удалять старые индексы по политике.
💬 Что учесть:
Операционные затраты могут быть высокими, а расходы на облачные услуги быстро растут при производственном масштабе.
3. OpenSearch
Плюсы:
• Полный open-source: OpenSearch является решением с открытым кодом без лицензионных рисков.
• Гибкость в сборе и анализе логов: поддерживает SQL и PPL, а также обладает встроенным observability-стеком
• Alerting-plugin — в отличие от ElasticSearch, OpenSearch из коробки позволяет строить гибкие триггеры и уведомления.
• Активное сообщество и поддержка AWS: он поддерживается AWS, Capital One, Red Hat, SAP и другими.
👩💻 Подборки репозиториев:
https://github.com/grafana/grafana – интеграция с Grafana с дашбордами и алертингом;
https://github.com/grafana/loki – репозиторий для агрегации логов
https://github.com/elastic – у Elastic на GitHub свыше 800 репозиториев, включая ядро Elasticsearch и множество интеграций и плагинов.
#DevOps #Observability #Grafana #Elastic
1.Grafana Loki
Плюсы:
• Минимальные расходы: Loki не индексирует содержимое логов, используя только метки (labels) — как в Prometheus. Это снижает потребление CPU, RAM и дискового пространства.
• Тесная интеграция с Prometheus и Grafana: Если вы уже используете Grafana или Prometheus, например в рамках KubePrometheusStack, то вам может быть полезна возможность просматривать логи там же, где и метрики.
• Простота развёртывания и масштабирования: monolithic mode идеально подходит для старта, так как объединяет в рамках одно бинарного файла все компоненты Loki. Но как только вам его не хватает, советуем перейти на микросервисный режим, разделив Distributor, Ingester, Querier и Compactor на отдельные сервисы
• Гибкий язык запросов: LogQL похож на PromQL, что позволяет проводить агрегаций и подсчёт ошибок за период времени, а затем выводить панели с количеством ошибок, рейтами и распределениями в Grafana.
Однако, Loki разработан для фильтрации логов на основе меток и регулярных выражений, а не для глубокого полнотекстового поиска и не позволяет справляться со сложным анализом логов.
2. Elastic Stack
Плюсы:
• Настройка на всех уровнях: от сбора данных с помощью Logstash или Beats до запросов и дашбордов в Kibana — почти все можно настроить
• Мощный поиск и аналитика: Elasticsearch обеспечивает быстрый полнотекстовый поиск и агрегацию в больших масштабах
• Работа в реальном времени: данные индексируются и становятся доступны для поиска почти мгновенно
Гибкость индексации и управления данными: в Elasticsearch есть возможность настраивать ILM (Index Lifecycle Management) - автоматически перемещать "тёплые" и "холодные" данные между нодами, удалять старые индексы по политике.
Операционные затраты могут быть высокими, а расходы на облачные услуги быстро растут при производственном масштабе.
3. OpenSearch
Плюсы:
• Полный open-source: OpenSearch является решением с открытым кодом без лицензионных рисков.
• Гибкость в сборе и анализе логов: поддерживает SQL и PPL, а также обладает встроенным observability-стеком
• Alerting-plugin — в отличие от ElasticSearch, OpenSearch из коробки позволяет строить гибкие триггеры и уведомления.
• Активное сообщество и поддержка AWS: он поддерживается AWS, Capital One, Red Hat, SAP и другими.
https://github.com/grafana/grafana – интеграция с Grafana с дашбордами и алертингом;
https://github.com/grafana/loki – репозиторий для агрегации логов
https://github.com/elastic – у Elastic на GitHub свыше 800 репозиториев, включая ядро Elasticsearch и множество интеграций и плагинов.
#DevOps #Observability #Grafana #Elastic
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍10🔥6❤3
Релизы недели: Opus 4.5, OpenAI Chats и Log Analytics Query Builder
В традиционной подборке три ключевых релиза: групповые чаты ChatGPT меняют сценарии совместной работы, Opus 4.5 составит конкуренцию Google Gemini 3, Log Analytics Query Builder для извлечения данных из BigQuery.
⏺ Групповые чаты в ChatGPT
OpenAI объявила о глобальном запуске групповых чатов в ChatGPT для пользователей планов Free, Go, Plus и Pro; ранее пилот представили в Японии и Новой Зеландии. Функция объединяет совместную беседу с участием до 20 человек (при принятии приглашения) и нужна для совместного планирования и принятия решений при поддержке ChatGPT как ассистента. Подробности тут.
⏺ Релиз Opus 4.5 от Anthropic
Anthropic выпустила Opus 4.5, новейшую языковую модель, конкурент OpenAI GPT-5.1 и Google Gemini 3. Opus 4.5 стала первой моделью, которая продемонстрировала более 80 % точности на SWE-Bench Verified и получила улучшенные способности к работе с вычислениями и электронными таблицами. Anthropic расширяет доступ к продуктам Claude for Chrome для пользователей Max и Claude for Excel для Max, Team и Enterprise. Что нового в версии – читайте здесь.
⏺ Log Analytics Query Builder от Google
Google представила Log Analytics Query Builder – инструмент для упрощённого доступа к данным в Google Cloud и автоматической генерации SQL-запросов к логам, другим типам телеметрии и таблицам в BigQuery. Конструктор поддерживает поиск по всем полям, автоматическое обнаружение JSON-схем. Подключен Log Analytics Query Builder и результаты работы можно визуализировать, сохранить на дашборд. Подробнее о релизе здесь.
#claude #claudeexcel #chatgpt #opus
В традиционной подборке три ключевых релиза: групповые чаты ChatGPT меняют сценарии совместной работы, Opus 4.5 составит конкуренцию Google Gemini 3, Log Analytics Query Builder для извлечения данных из BigQuery.
OpenAI объявила о глобальном запуске групповых чатов в ChatGPT для пользователей планов Free, Go, Plus и Pro; ранее пилот представили в Японии и Новой Зеландии. Функция объединяет совместную беседу с участием до 20 человек (при принятии приглашения) и нужна для совместного планирования и принятия решений при поддержке ChatGPT как ассистента. Подробности тут.
Anthropic выпустила Opus 4.5, новейшую языковую модель, конкурент OpenAI GPT-5.1 и Google Gemini 3. Opus 4.5 стала первой моделью, которая продемонстрировала более 80 % точности на SWE-Bench Verified и получила улучшенные способности к работе с вычислениями и электронными таблицами. Anthropic расширяет доступ к продуктам Claude for Chrome для пользователей Max и Claude for Excel для Max, Team и Enterprise. Что нового в версии – читайте здесь.
Google представила Log Analytics Query Builder – инструмент для упрощённого доступа к данным в Google Cloud и автоматической генерации SQL-запросов к логам, другим типам телеметрии и таблицам в BigQuery. Конструктор поддерживает поиск по всем полям, автоматическое обнаружение JSON-схем. Подключен Log Analytics Query Builder и результаты работы можно визуализировать, сохранить на дашборд. Подробнее о релизе здесь.
#claude #claudeexcel #chatgpt #opus
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤7👍4🔥4
Лучшие из худших сообщений коммитов
⏺ Всем DevOps! Хорошие новости – сегодня пятница, значит скоро нас ждет перерыв от дейликов. Плохие – всё еще нужно писать сообщения коммитов после деплоя и релизов. Представляем зал славы лучших из худших сообщений коммитов, где собраны нестандартные варианты из рабочих репозиториев. Расширенный сборник найдёте здесь.
👀 Вот сейчас точно исправил
Именно так выглядели коммиты DevOps-инженера автора статьи каждый раз, когда нужно было «быстренько что-нибудь установить».
👀 Всё, что надо было, сделал
Классическое сообщение тиммейтов при поступлении срочной задачи, которую закрыть надо было ещё вчера.
👀 Хроники борьбы с билдом
Попыток было в разы больше.
👀 Пожалуйста, работай…
Признайтесь, были и такие моменты в работе.
👀 Эпоха до ESLint
Кто бы что ни говорил, а проблема «казнить нельзя помиловать» актуальна.
Какие находки из коммитов помните вы?
#git #commits #commitmessages #devops
"fix"
"fix-final"
"ok final fix"
"fix final final"
"fixed previous fix"
Именно так выглядели коммиты DevOps-инженера автора статьи каждый раз, когда нужно было «быстренько что-нибудь установить».
"did the needful"
Классическое сообщение тиммейтов при поступлении срочной задачи, которую закрыть надо было ещё вчера.
"attempt to fix the build"
"ok, fix the build"
Попыток было в разы больше.
"please work"
Признайтесь, были и такие моменты в работе.
"added a coma, now works fine"
Кто бы что ни говорил, а проблема «казнить нельзя помиловать» актуальна.
Какие находки из коммитов помните вы?
#git #commits #commitmessages #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤15👍10🔥6
Good practices: конфигурации в Kubernetes
Конфигурации – основа рабочей нагрузки Kubernetes. Опытные инженеры знают, что достаточно пропущенной кавычки, неактуальной API-версии или смещённого отступа в YAML для возникновения проблемы при деплое. Представляем подборку good practices с советами по стабилизации кластера — для новичков и опытных пользователей. Подробнее читайте здесь.👀
Общие practices:
⏺ Используйте актуальную версию API
Kubernetes быстро развивается и обновляется. Менее актуальные API не работают корректно и приводят к сбоям при деплое. Проверяйте версию API, используя следующую команду:
⏺ Храните конфиги под версионным контролем
Не применяйте файлы манифеста с десктопа, храните их в системе контроля версий, например, в Git. Если что-то сломается – вы быстро откатитесь к прошлому коммиту.
⏺ Пишите конфиги в YAML, не в JSON
Технически работают оба формата для обмена и хранения данных, но YAML более удобен, по словам автора. В YAML используйте только true/false, т.к. yes/no/on/off могут парситься по-разному. Для надёжности берите в кавычки всё, что похоже на булево значение (например, "yes").
⏺ Группируйте связанные объекты
Если ресурсы – часть одного сервиса, храните их в одном файле YAML-манифеста. Так легче отслеживать, ревьювить и разворачивать изменения.
Применяйте эту команду, чтобы задеплоить всё в папке:
🚀 Стандартизированные конфигурации упрощают управление кластером и берегут нервы администратора. Следуйте базовым принципам: контроль версий, единая система меток, отказ от использования отдельных Pod-ов без контроллеров. Так, вы значительно сократите время на диагностику и устранение ошибок.
#kubernetes #k8s #clustermanagment #devops
Конфигурации – основа рабочей нагрузки Kubernetes. Опытные инженеры знают, что достаточно пропущенной кавычки, неактуальной API-версии или смещённого отступа в YAML для возникновения проблемы при деплое. Представляем подборку good practices с советами по стабилизации кластера — для новичков и опытных пользователей. Подробнее читайте здесь.
Общие practices:
Kubernetes быстро развивается и обновляется. Менее актуальные API не работают корректно и приводят к сбоям при деплое. Проверяйте версию API, используя следующую команду:
kubectl api-resources
Не применяйте файлы манифеста с десктопа, храните их в системе контроля версий, например, в Git. Если что-то сломается – вы быстро откатитесь к прошлому коммиту.
Технически работают оба формата для обмена и хранения данных, но YAML более удобен, по словам автора. В YAML используйте только true/false, т.к. yes/no/on/off могут парситься по-разному. Для надёжности берите в кавычки всё, что похоже на булево значение (например, "yes").
Если ресурсы – часть одного сервиса, храните их в одном файле YAML-манифеста. Так легче отслеживать, ревьювить и разворачивать изменения.
Применяйте эту команду, чтобы задеплоить всё в папке:
kubectl apply -f configs/
#kubernetes #k8s #clustermanagment #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍4🔥3
Приглашаем к коллегам на Kuber Conf
Всем DevOps!🚀
Разыгрываем 15 билетов на Kuber Conf – первую некоммерческую конференцию по k8s в России.
Организаторы "Ассоциации облачно-ориентированных технологий" – VK Cloud, Yandex Cloud и Флант.
📅 Когда: 4 декабря, Москва.
⏺ Что представлено? Доклады от мейнтейнеров Open Source-проектов, лидеров продуктовых команд и основателей инфраструктурных компаний. Участникам будут доступны два трека:
1. Основной: эволюция Managed Kubernetes от "лодки" до "крейсера", кейс по построению расширяемой платформы деплоя от Т-Банка, полный путь кастомизации Talos Linux deep-dive по CNI и прочие кейсы. Концентрация пользы и опыта специалистов Beget, Т-Банка, Фланта, Yandex Cloud и Avito.
2. Второй, интригующий: Cluster API и её новая версия v1beta2, кейс Vitastor о преимуществах и недостатках разных способов подключения блочных устройств к контейнерам (nbd, vduse, ublk), развертывание Gatekeeper в k8s-in-k8s, Talos-подобная Базальт СПО.
Регистрируйтесь и смотрите полную программу здесь.
Чтобы участвовать:
1. Убедитесь, что вы на нас подписаны, @DevOps_FM.
2. Нажмите «Участвую!» под этим постом.
🗓 Итоги мы подведём случайным образом, а результаты объявим уже сегодня!
Важно: один билет = один гость.
Успейте принять участие!🚀
#партнёрский_пост
Всем DevOps!
Разыгрываем 15 билетов на Kuber Conf – первую некоммерческую конференцию по k8s в России.
Организаторы "Ассоциации облачно-ориентированных технологий" – VK Cloud, Yandex Cloud и Флант.
1. Основной: эволюция Managed Kubernetes от "лодки" до "крейсера", кейс по построению расширяемой платформы деплоя от Т-Банка, полный путь кастомизации Talos Linux deep-dive по CNI и прочие кейсы. Концентрация пользы и опыта специалистов Beget, Т-Банка, Фланта, Yandex Cloud и Avito.
2. Второй, интригующий: Cluster API и её новая версия v1beta2, кейс Vitastor о преимуществах и недостатках разных способов подключения блочных устройств к контейнерам (nbd, vduse, ublk), развертывание Gatekeeper в k8s-in-k8s, Talos-подобная Базальт СПО.
Регистрируйтесь и смотрите полную программу здесь.
Чтобы участвовать:
1. Убедитесь, что вы на нас подписаны, @DevOps_FM.
2. Нажмите «Участвую!» под этим постом.
🗓 Итоги мы подведём случайным образом, а результаты объявим уже сегодня!
Важно: один билет = один гость.
Успейте принять участие!
#партнёрский_пост
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤4👍3🔥3