🎙 Что послушать на выходных: Kubernetes и энергопотребление
В пятницу делимся свежим выпуском Kubernetes Podcast про Project Kepler — open-source проект для наблюдения за энергопотреблением Kubernetes-нагрузок.
В гостях Ники Маноледаки, Staff Platform Engineer в Grafana Labs и мейнтейнер Project Kepler. Вместе с ведущими она обсуждает, как оценивать энергопотребление рабочих нагрузок, какие метрики для этого можно собирать и почему получить реально точные данные не так просто.
Отдельно поговорили о том, зачем Kepler недавно переписали, как проект использует eBPF и Prometheus и при чём здесь растущие вычислительные нагрузки AI.
🎧 Выпуск «Measuring Sustainability via Project Kepler» послушать можно здесь.
Желаем приятного прослушивания и хороших выходных! А тем, кто дежурит🛡, — спокойных смен 🙌🏼
#подкаст #devops #kubernetes #observability #opensource
В пятницу делимся свежим выпуском Kubernetes Podcast про Project Kepler — open-source проект для наблюдения за энергопотреблением Kubernetes-нагрузок.
В гостях Ники Маноледаки, Staff Platform Engineer в Grafana Labs и мейнтейнер Project Kepler. Вместе с ведущими она обсуждает, как оценивать энергопотребление рабочих нагрузок, какие метрики для этого можно собирать и почему получить реально точные данные не так просто.
Отдельно поговорили о том, зачем Kepler недавно переписали, как проект использует eBPF и Prometheus и при чём здесь растущие вычислительные нагрузки AI.
🎧 Выпуск «Measuring Sustainability via Project Kepler» послушать можно здесь.
Желаем приятного прослушивания и хороших выходных! А тем, кто дежурит🛡, — спокойных смен 🙌🏼
#подкаст #devops #kubernetes #observability #opensource
2🔥5❤2👍2
KYAML vs YAML: зачем усложнять простое?
YAML давно стал привычным инструментом для DevOps. Но у него есть обратная сторона: неявные типы, зависимость структуры от отступов и множество возможностей, которые Kubernetes на самом деле не использует.
Kubernetes предлагает более строгий подход к конфигурациям — KYAML и описывает его преймущества в своем блоге. Идея в том, чтобы оставить от YAML только то, что действительно нужно Kubernetes, и убрать неоднозначности.
Что получает DevOps?
🟡 меньше зависимости от отступов;
🟡 более предсказуемую работу со строками и типами;
🟡 явное обозначение списков [] и структур {};
🟡 более удобную работу с генерацией, шаблонами и автоматизацией;
🟡 KYAML остаётся валидным YAML и рассчитан на совместимость с существующими YAML-парсерами.
Но есть и другая сторона. Среди обсуждений инженеров можно встретить мнение, что KYAML не избавляет Kubernetes-конфиги от сложности, объясняя это тем, что:
🟡 KYAML не уберёт Helm-шаблоны, огромные манифесты и десятки взаимосвязанных параметров. А значит, вместо решения основной проблемы можно получить ещё один формат, который команде придётся изучать и поддерживать;
🟡YAML уже встроен практически во всю DevOps-экосистему — от IDE и линтеров до CI/CD-инструментов. KYAML — новый подход, а значит, не все инструменты одинаково хорошо его поддерживают.
И здесь возникает главный вопрос:
KYAML действительно решает проблемы YAML — или просто вводит более строгие правила там, где и так всё работало?
👀 А вы бы использовали KYAML в своих проектах, либо же обычного YAML вам вполне хватает? Поделитесь мыслями.
YAML давно стал привычным инструментом для DevOps. Но у него есть обратная сторона: неявные типы, зависимость структуры от отступов и множество возможностей, которые Kubernetes на самом деле не использует.
Kubernetes предлагает более строгий подход к конфигурациям — KYAML и описывает его преймущества в своем блоге. Идея в том, чтобы оставить от YAML только то, что действительно нужно Kubernetes, и убрать неоднозначности.
Что получает DevOps?
🟡 меньше зависимости от отступов;
🟡 более предсказуемую работу со строками и типами;
🟡 явное обозначение списков [] и структур {};
🟡 более удобную работу с генерацией, шаблонами и автоматизацией;
🟡 KYAML остаётся валидным YAML и рассчитан на совместимость с существующими YAML-парсерами.
Но есть и другая сторона. Среди обсуждений инженеров можно встретить мнение, что KYAML не избавляет Kubernetes-конфиги от сложности, объясняя это тем, что:
🟡 KYAML не уберёт Helm-шаблоны, огромные манифесты и десятки взаимосвязанных параметров. А значит, вместо решения основной проблемы можно получить ещё один формат, который команде придётся изучать и поддерживать;
🟡YAML уже встроен практически во всю DevOps-экосистему — от IDE и линтеров до CI/CD-инструментов. KYAML — новый подход, а значит, не все инструменты одинаково хорошо его поддерживают.
И здесь возникает главный вопрос:
KYAML действительно решает проблемы YAML — или просто вводит более строгие правила там, где и так всё работало?
👀 А вы бы использовали KYAML в своих проектах, либо же обычного YAML вам вполне хватает? Поделитесь мыслями.
2❤5👍4🔥3
В эфире DevOps FM – срединедельный дайджест новостей и статей!
⏺ 10 августа Docker выпустил обновление Docker VMM, переведя технологию в статус Public Beta.
Docker VMM — новый уровень виртуализации для Docker Desktop, который сделает работу контейнеров на Mac и Windows быстрее и стабильнее. Среди заявленных улучшений — более быстрый запуск контейнеров, ускоренный файловый I/O и более эффективное управление памятью. Сейчас технология доступна в Docker Desktop 4.86, а финальный релиз по имеющейся информации запланирован на конец октября.
Подробнее о том, что изменилось и как попробовать новый VMM — в блоге Docker.
⏺ После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 7.2.
Новая версия ядра традиционно приносит изменения в подсистемах, драйверах и производительности. Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.
⏺ Debian обсуждают использование AI при разработке.
Debian объявили о начале общего голосования разработчиков по вопросу использования больших языковых моделей и AI-инструментов при разработке дистрибутива.
Прием голосов будет осуществляться до 28 августа. Как проходит голосование и какие позиции обсуждаются — читайте в OpenNET.
⏺ GitHub пережил масштабный сбой.
17 августа проблемы затронули сразу несколько ключевых сервисов платформы: Web и API показывали около 20% ошибок, а количество неудачных запросов к архивам и Raw-контенту доходило до 50%. Были затронуты Actions, Pull Requests, Issues, Webhooks, Copilot и другие сервисы.
GitHub постепенно восстановил сервисы. В качестве причины сбоев эксперты предположили сетевые инциденты в Amazon Web Services. Подробнее о масштабах сбоя — в статье.
#новостная_подборка #devops #github #docker #linux #debian
Docker VMM — новый уровень виртуализации для Docker Desktop, который сделает работу контейнеров на Mac и Windows быстрее и стабильнее. Среди заявленных улучшений — более быстрый запуск контейнеров, ускоренный файловый I/O и более эффективное управление памятью. Сейчас технология доступна в Docker Desktop 4.86, а финальный релиз по имеющейся информации запланирован на конец октября.
Подробнее о том, что изменилось и как попробовать новый VMM — в блоге Docker.
Новая версия ядра традиционно приносит изменения в подсистемах, драйверах и производительности. Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.
Debian объявили о начале общего голосования разработчиков по вопросу использования больших языковых моделей и AI-инструментов при разработке дистрибутива.
Прием голосов будет осуществляться до 28 августа. Как проходит голосование и какие позиции обсуждаются — читайте в OpenNET.
17 августа проблемы затронули сразу несколько ключевых сервисов платформы: Web и API показывали около 20% ошибок, а количество неудачных запросов к архивам и Raw-контенту доходило до 50%. Были затронуты Actions, Pull Requests, Issues, Webhooks, Copilot и другие сервисы.
GitHub постепенно восстановил сервисы. В качестве причины сбоев эксперты предположили сетевые инциденты в Amazon Web Services. Подробнее о масштабах сбоя — в статье.
#новостная_подборка #devops #github #docker #linux #debian
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤4🔥3👍2
Пятничное чтиво от DevOps FM
📚AI-агенты постепенно заходят в DevOps: получают доступ к коду, инфраструктуре, CI/CD и production. Сегодня читаем о том, как безопасно управлять системами, которые умеют действовать самостоятельно.
⏺ 12 августа Docker представил Agent Baseline — набор практических рекомендаций для безопасного внедрения AI-агентов. В центре внимания — least privilege, наблюдаемость, аудит и возможность остановить агента, а не просто надеяться, что модель будет вести себя правильно. Подробнее читайте в статье.
⏺ CNCF смотрит на проблему с другой стороны: если AI становится частью production, то где проходит граница между ML-командой, DevOps и Platform Engineering? И кто в итоге отвечает за надёжность всей этой системы? Подробнее читайте здесь.
⏺ В разборе кейса Hugging Face хорошо показывает, почему вопрос контроля уже не теоретический. В ходе инцидента исследователи восстановили около 17 600 действий агента, объединённых примерно в 6 280 цепочек.
⏺ GitLab, в свою очередь, показывает, как можно встроить AI-агентов в существующую инфраструктуру с учётом требований безопасности. В новой статье компания рассказывает об AI Gateway для GitLab Dedicated, который позволяет контролировать используемые модели и сохранять AI-обработку внутри выбранного региона. Подробнее читайте в статье.
👀Получается интересный сдвиг: раньше DevOps автоматизировал процессы, а теперь ему предстоит ещё и управлять AI-агентами.
И теперь главный вопрос — какие права мы готовы дать AI и насколько быстро сможем его остановить, если что-то пойдет не так? Пишите свое мнение в комментариях.
Желаем приятного чтения и хороших выходных!
#пятничноечтиво #devops #ai
📚AI-агенты постепенно заходят в DevOps: получают доступ к коду, инфраструктуре, CI/CD и production. Сегодня читаем о том, как безопасно управлять системами, которые умеют действовать самостоятельно.
👀Получается интересный сдвиг: раньше DevOps автоматизировал процессы, а теперь ему предстоит ещё и управлять AI-агентами.
И теперь главный вопрос — какие права мы готовы дать AI и насколько быстро сможем его остановить, если что-то пойдет не так? Пишите свое мнение в комментариях.
Желаем приятного чтения и хороших выходных!
#пятничноечтиво #devops #ai
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤6👍3🔥1
DevOps через Git: насколько реально управлять всей инфраструктурой и deployment из Git?
Что, если от создания VPC до выката приложения в Kubernetes вообще не заходить в AWS руками? Именно такой сценарий GitLab разбирает в статье — и он хорошо показывает, куда движется современный DevOps.
Если сильно упростить, схема примерно такая:
Git → GitLab CI/CD → OpenTofu → AWS/EKS → Argo CD → приложение
OpenTofu создаёт и изменяет инфраструктуру, GitLab CI/CD управляет процессом и сборкой, а Argo CD следит за состоянием Kubernetes и синхронизирует его с Git.
Вместо привычного сценария:
Получаем:
И вот это уже интереснее, чем просто очередная связка инструментов.
IaC + CI/CD + GitOps постепенно превращаются в единую декларативную цепочку, где Git становится источником истины не только для кода, но и для окружения.
Плюсы очевидны:
⏺ меньше ручных действий;
⏺ изменения проходят review;
⏺ инфраструктура воспроизводима;
⏺ rollback часто превращается в git revert;
⏺ окружение можно восстановить из кода.
Но ведь чем больше production мы передаём автоматизации, тем важнее становится надёжность самого control plane.
Отсюда возникают следующие вопросы:
⏺ Что делать, если GitLab недоступен?
⏺ Как внести emergency change?
⏺ Кто имеет break-glass доступ?
⏺ Можно ли восстановить инфраструктуру, если недоступны инструменты, которые ей управляют?
И, пожалуй, это один из интересных вопросов современного DevOps — что важнее: полностью исключить ручные изменения или сохранить возможность быстро обойти автоматизацию в аварийной ситуации? Делитесь своим мнением в комментариях💬
Желаем продуктивной недели и спокойных дежурных смен!
Что, если от создания VPC до выката приложения в Kubernetes вообще не заходить в AWS руками? Именно такой сценарий GitLab разбирает в статье — и он хорошо показывает, куда движется современный DevOps.
Если сильно упростить, схема примерно такая:
Git → GitLab CI/CD → OpenTofu → AWS/EKS → Argo CD → приложение
OpenTofu создаёт и изменяет инфраструктуру, GitLab CI/CD управляет процессом и сборкой, а Argo CD следит за состоянием Kubernetes и синхронизирует его с Git.
Вместо привычного сценария:
> Зайди в AWS, поправь вот это.
> Потом сделай kubectl apply.
> А почему staging теперь отличается от production?
Получаем:
> Изменение инфраструктуры — commit.
> Изменение приложения — commit.
> Дальше автоматика сама приводит окружение к нужному состоянию.
И вот это уже интереснее, чем просто очередная связка инструментов.
IaC + CI/CD + GitOps постепенно превращаются в единую декларативную цепочку, где Git становится источником истины не только для кода, но и для окружения.
Плюсы очевидны:
Но ведь чем больше production мы передаём автоматизации, тем важнее становится надёжность самого control plane.
Отсюда возникают следующие вопросы:
И, пожалуй, это один из интересных вопросов современного DevOps — что важнее: полностью исключить ручные изменения или сохранить возможность быстро обойти автоматизацию в аварийной ситуации? Делитесь своим мнением в комментариях
Желаем продуктивной недели и спокойных дежурных смен!
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤8🔥4👍2
Новостной дайджест от DevOps FM!
⌨️ Делимся свежими новостями и релизами за прошедшую неделю.
⏺ Kubeflow получил статус CNCF Graduated.
Kubeflow получил высший статус зрелости в CNCF. Проект объединяет инструменты для построения AI/ML-платформ на Kubernetes — от подготовки данных и обучения моделей до inference.
Для DevOps это ещё один сигнал: Kubernetes всё активнее становится инфраструктурой для AI — от обучения моделей до inference и serving. Детали читайте в статье.
⏺ AWS продолжает развивать Argo CD в EKS.
В понедельник мы разбирали сценарий, где Git становится control plane для инфраструктуры и deployment. Теперь AWS расширяет возможности настройки управляемой Argo CD Capability в EKS — в частности, добавляет поддержку кастомных health checks и параметров сравнения ресурсов.
Похоже, AWS постепенно углубляет интеграцию GitOps с EKS, беря на себя всё больше операционных задач по управлению Argo CD. Подробнее — в блоге AWS.
⏺ IncidentRelay 2.0 — новый релиз self-hosted incident management.
Open-source проект для управления дежурствами, маршрутизации алертов и incident response получил новый major-релиз.
IncidentRelay ориентирован на SRE и DevOps-команды, которым нужна self-hosted альтернатива облачным платформам управления инцидентами.
Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.
⏺ GitHub опубликовал разбор масштабного сбоя 17 августа.
Напомним, тогда GitHub был недоступен или работал с ошибками почти 8 часов. Теперь компания раскрыла детали: проблема с autoscaling Istio sidecar-подов привела к перегрузке сети и каскаду отказов.
Ситуацию дополнительно усугубили агрессивные retry: нагрузка на отдельные сервисы выросла многократно.
Получился отличный пример того, как ошибка в автоматическом масштабировании + retry storm могут превратить локальную проблему в большой outage.
Подробнее — в разборе GitHub.
#devops #инциденты #gitlab #kubeflow
Kubeflow получил высший статус зрелости в CNCF. Проект объединяет инструменты для построения AI/ML-платформ на Kubernetes — от подготовки данных и обучения моделей до inference.
Для DevOps это ещё один сигнал: Kubernetes всё активнее становится инфраструктурой для AI — от обучения моделей до inference и serving. Детали читайте в статье.
В понедельник мы разбирали сценарий, где Git становится control plane для инфраструктуры и deployment. Теперь AWS расширяет возможности настройки управляемой Argo CD Capability в EKS — в частности, добавляет поддержку кастомных health checks и параметров сравнения ресурсов.
Похоже, AWS постепенно углубляет интеграцию GitOps с EKS, беря на себя всё больше операционных задач по управлению Argo CD. Подробнее — в блоге AWS.
Open-source проект для управления дежурствами, маршрутизации алертов и incident response получил новый major-релиз.
IncidentRelay ориентирован на SRE и DevOps-команды, которым нужна self-hosted альтернатива облачным платформам управления инцидентами.
Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.
Напомним, тогда GitHub был недоступен или работал с ошибками почти 8 часов. Теперь компания раскрыла детали: проблема с autoscaling Istio sidecar-подов привела к перегрузке сети и каскаду отказов.
Ситуацию дополнительно усугубили агрессивные retry: нагрузка на отдельные сервисы выросла многократно.
Получился отличный пример того, как ошибка в автоматическом масштабировании + retry storm могут превратить локальную проблему в большой outage.
Подробнее — в разборе GitHub.
#devops #инциденты #gitlab #kubeflow
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍4❤3🔥2
Подборка интерактивных тренажеров для DevOps
⌨️ В эту пятницу собрали тренажеры, где можно на практике разбирать нетривиальные сценарии Kubernetes, networking и troubleshooting.
⏺ Deadnodes — тренировка в формате production-инцидента: получаем сломанное окружение, ищем root cause и восстанавливаем систему. Есть сценарии по Linux, Kubernetes, networking и базам данных.
⏺ iximiuz Labs — набор hands-on лабораториий с Linux, контейнерами и Kubernetes. Можно самостоятельно разбирать networking, container internals и troubleshooting-сценарии разной сложности.
⏺ Anycast и BGP — меняем маршруты и отключаем PoP, чтобы посмотреть, что происходит с трафиком и TCP-соединениями. Можно разобрать проблемы с long-lived connections и capacity при отказе части инфраструктуры.
⏺ Kubernetes Scheduler Simulator — практика работы с Filter/Score, resource requests, taints и tolerations. Можно посмотреть, почему Pod оказывается Pending, и сравнить стратегии размещения.
Сохраняйте подборку, чтобы попробовать эти сценарии на практике и проверить свои навыки troubleshooting.
Хорошей практики и приятных выходных! Делитесь своими любимыми тренажерами в комментариях.
#девопс #тренажеры
Сохраняйте подборку, чтобы попробовать эти сценарии на практике и проверить свои навыки troubleshooting.
Хорошей практики и приятных выходных! Делитесь своими любимыми тренажерами в комментариях.
#девопс #тренажеры
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍14❤5🔥2
А что, если AI посмотрит ваш Kubernetes?
AI-помощники для Kubernetes — уже далеко не новость.
Но становится интереснее, когда AI работает прямо в OpenShift Console и при включённом Cluster Interaction может получать актуальный контекст работающего кластера.
Red Hat в своем блоге показывает 5 сценариев для OpenShift Lightspeed — AI-помощника, который помогает работать с OpenShift и Kubernetes.
Собрали самое интересное 👇
1. Спросить вместо поиска по документации
Например:
Lightspeed использует официальную документацию Red Hat и учитывает версии OpenShift и Lightspeed в вашем окружении.
2. Сгенерировать YAML
Можно попросить AI подготовить конфигурацию:
Или:
Получаем черновик манифеста, который дальше, конечно, нужно проверить перед применением.
3. Разобраться с проблемой
Здесь уже можно использовать AI не только для генерации конфигурации, но и для troubleshooting.
Например:
Lightspeed может анализировать проблему и проводить через диагностические шаги, помогая понять, куда смотреть дальше.
4. Разобраться с виртуализацией
Для OpenShift Virtualization можно задавать вопросы вроде:
Удобный вариант, чтобы разобраться с Kubernetes-based virtualization и сопоставить её с уже знакомыми подходами.
5. А теперь самое интересное — live-кластер
При включённом Cluster Interaction Lightspeed может получать актуальный контекст активного кластера через OpenShift API.
Например:
То есть вопрос можно сформулировать не только как: «Как сделать X в OpenShift? Но и как: «Что сейчас происходит с моим кластером?»
Сам сценарий AI-assisted troubleshooting для Kubernetes уже существует. Интерес Lightspeed — в его интеграции с OpenShift и доступе к контексту работающего кластера.
При этом Cluster Interaction сейчас имеет статус Technology Preview, поэтому воспринимать его как готовую замену привычным инструментам мониторинга и диагностики точно не стоит.
👀 А когда такая возможность выйдет из Technology Preview — дали бы вы AI read-only доступ к production-кластеру? Делитесь своим мнением в комментариях 💬
#DevOps #Kubernetes #OpenShift #AI
AI-помощники для Kubernetes — уже далеко не новость.
Но становится интереснее, когда AI работает прямо в OpenShift Console и при включённом Cluster Interaction может получать актуальный контекст работающего кластера.
Red Hat в своем блоге показывает 5 сценариев для OpenShift Lightspeed — AI-помощника, который помогает работать с OpenShift и Kubernetes.
Собрали самое интересное 👇
1. Спросить вместо поиска по документации
Например:
How do I configure a custom ingress controller?
What are the prerequisite network requirements for setting up an OpenShift cluster?
Lightspeed использует официальную документацию Red Hat и учитывает версии OpenShift и Lightspeed в вашем окружении.
2. Сгенерировать YAML
Можно попросить AI подготовить конфигурацию:
Generate a YAML file for a deployment running a basic NGINX server with 3 replicas.
Или:
Create a NetworkPolicy that limits traffic to pods in the production namespace.
Получаем черновик манифеста, который дальше, конечно, нужно проверить перед применением.
3. Разобраться с проблемой
Здесь уже можно использовать AI не только для генерации конфигурации, но и для troubleshooting.
Например:
Why is my application pod stuck in ImagePullBackOff?
I am getting a CrashLoopBackOff error on my frontend pod. What is happening there?
Lightspeed может анализировать проблему и проводить через диагностические шаги, помогая понять, куда смотреть дальше.
4. Разобраться с виртуализацией
Для OpenShift Virtualization можно задавать вопросы вроде:
Is there a storage vMotion equivalent?
How do I import a VMware virtual machine into OpenShift Virtualization?
Удобный вариант, чтобы разобраться с Kubernetes-based virtualization и сопоставить её с уже знакомыми подходами.
5. А теперь самое интересное — live-кластер
При включённом Cluster Interaction Lightspeed может получать актуальный контекст активного кластера через OpenShift API.
Например:
Show me all degraded pods running in the payment-processing namespace.
Are there any active security alerts or failed deployments on my cluster right now?
То есть вопрос можно сформулировать не только как: «Как сделать X в OpenShift? Но и как: «Что сейчас происходит с моим кластером?»
Сам сценарий AI-assisted troubleshooting для Kubernetes уже существует. Интерес Lightspeed — в его интеграции с OpenShift и доступе к контексту работающего кластера.
При этом Cluster Interaction сейчас имеет статус Technology Preview, поэтому воспринимать его как готовую замену привычным инструментам мониторинга и диагностики точно не стоит.
#DevOps #Kubernetes #OpenShift #AI
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤4👍4🔥3🤣1
В новой версии добавили 67 изменений: 16 функций перешли в Stable, 23 — в Beta, ещё 27 получили статус Alpha.
Среди основных изменений — переход Metrics API в Stable, обновления сетевых компонентов, поддержка Pod Certificates и Cluster Trust Bundles, а также изменения в kube-proxy и cgroup. Релиз также включает обновления и улучшения для безопасности, управления ресурсами и работы кластера.
Подробнее об изменениях Kubernetes рассказали в своем блоге.
git.kernel.org получает около 6 млн запросов в день, и около 98% из них — боты, которые массово запрашивают страницы отдельных коммитов, создавая постоянную нагрузку на серверы.
На пяти серверах 14–16 из 90 CPU-ядер постоянно заняты обработкой этих запросов, в результате администраторы начали отключать ресурсоёмкие операции, ограничивать анонимный доступ и сокращать количество доступных для обхода ссылок.
Детали читайте в статье.
Сделка была закрыта 31 августа. Команда DuckDB присоединяется к AWS, при этом проект продолжит развиваться под руководством своих основателей. AWS планирует использовать технологии DuckDB для развития своего аналитического стека.
Подробнее на OpenNET.
31 августа закончился период LTS для Debian 11 Bullseye. Для части пакетов и архитектур доступна Extended LTS от Freexian — она продлевает поддержку до 2031 года.
Подробнее на OpenNET.
Ранее мы писали о голосовании Debian по правилам использования генеративного AI. Теперь голосование завершено: проект выбрал вариант Responsible Generative AI Use.
Подробности читайте в статье.
#новостной_дайджест #devopsfm #kubernetes #debian
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤5👍5🔥4
Тема — производительность, отказоустойчивость и все практики, которые позволяют системам выдерживать высокие нагрузки.
Будет особенно интересно инженерам по нагрузочному тестированию, QA-лидам, DevOps и SRE-специалистам.
Можно прийти лично — пообщаться с коллегами, обменяться опытом и узнать много нового из практик и трендов. А если не получается приехать — конференцию можно смотреть онлайн.
Подробности и регистрация на сайте.
И в канале конференции.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍6❤4🔥4