От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую

В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете helm template и парсите YAML – рекомендуем сменить подход. В ConfigHub реализуется модель «конфигурация как данные»: вместо того чтобы каждый раз генерировать YAML из шаблонов по запросу, вы создаёте готовый манифест один раз.

Как внедрить подход?
⏺Развертывание базового окружения (Infra Space)

1. Добавляем репозиторий Helm:

helm repo update

2. Разворачиваем базовое окружение для инфраструктуры:

cub space create infra

3. Устанавливаем Helm-чарт через ConfigHub:

cub helm install --space infra \
  --use-placeholder=false \
  --namespace monitoring \
  prometheus prometheus-community/kube-prometheus-stack \
  --version 79.6.1

• ConfigHub использует движок Helm для однократного рендеринга чарта.
• Результат сохраняется как материализованный, версионируемый и индексируемый артефакт (Config Unit).

⏺Создание пространств для окружений (Spaces)
1. Создаем пространства для каждого целевого окружения:
cub space create dev
cub space create prod
2. В качестве альтернативы – создаем пространства через UI ConfigHub, используем кнопку [Add] на странице списка Spaces.
3. Каждое пространство будет содержать копии базовых конфигураций для конкретного окружения.

⏺Клонирование и создание Вариантов (Variants)
Variant – это копия Config Unit, которая создается через операцию Clone.

1. Создаем Dev Variant из базового окружения:
2. Выбираем чарты в infra space.
3. Выбираем dev space как цель.
4. Нажимаем [Clone Units].
5. Создаем Prod Variant из Dev Variant аналогично.

⬆️Так, мы получаем цепочку конфигураций:
[infra's Helm charts] → [dev's Helm charts] → [prod's Helm charts]

Аналогичную концепцию можем использовать в Kustomize. Мы начинаем с базовых ресурсов, а затем добавляем к ним «Dev Overlays».

⏺Мгновенный доступ к конфигурациям
1. После клонирования не требуется повторный рендеринг.
2. Получаем точные манифесты для окружений:

Dev

cub unit get --space dev prometheus --data-only

Prod

cub unit get --space prod prometheus --data-only

Получаем готовый YAML, а не шаблон или переменную.

⏺Решение сценариев «Fire Drill»
1. Так как конфигурации сохранены как данные, можно выполнять поиск и анализ без повторного рендеринга:

Поиск уязвимых образов

cub unit list --space "*" \
  --resource-type monitoring.coreos.com/v1/Prometheus \
  --where-data "spec.image ~ '.*registry.compromised.com.*'"

Поиск образов

cub unit list --space "*" \
  --resource-type monitoring.coreos.com/v1/Prometheus \
  --where-data "spec.image ~ '.*quay.io.*'"

👀Подводные камни и что делать:
• Нативные зависимости и postinstall хуки. При рендере учитывайте, что некоторые чарты рассчитывают поведение во время выполнения. Обязательный этап – прогон тестов в staging.
• Избежание версионных конфликтов Helm чартов, за счет фиксирования версий чарта; используйте lock-файлы чарта или helmfile для управления групповыми релизами.

Делимся полезными ресурсами:
⚙️Интеграция ConfigHub-workflow с CI/CD (build → render → store → apply), примеры для GitHub Actions/GitLab CI и рекомендации по кэшированию здесь.
❕How-to по Variants и GitOps (ArgoCD/Flux) – синхронизация «данных-конфигураций» с Git и кластерами (Kustomize в ArgoCD), подробнее тут.

#confighub #kubernetes #helm #devops

Анонсы и прогнозы: Docker с Dynamic MCP, Rust в Linux, тренды.

Срединедельный DevOps! Обсудим прогнозы и ключевые события уходящего года: развитие DevOps-инструментов, Rust в Linux, рост трафика с ИИ и лучшие кейсы цифровизации.

⏺Docker Desktop 4.5 и Dynamic MCP
Docker Desktop – приложение для локальной разработки, которое позволяет разработчику собирать, запускать и администрировать контейнеризованные приложения. Представили экспериментальную функцию Dynamic MCP в версии Docker Desktop 4.5. При её использовании ИИ-агенты находят и подключают MCP-серверы в реальном времени. Dynamic MCP начинает работу при подключении клиента к MCP Toolkit, а шлюз MCP предоставляет агентам набор инструментов (mcp-find, mcp-add и др.), с помощью которых им удается обнаружить, добавить и управлять серверами в ходе работы. Подробнее об особенностях функции читайте тут, а с примером использования – на GitHub.

⏺Эксперимент признан успешным: Rust в проекте ядра Linux
Эксперимент по внедрению Rust в ядро Linux, начатый в версии 6.1 в 2022 году и в котором приняли участие 173 разработчика, официально завершён. Ведущий разработчик Rust для Linux Мигель Охеда опубликовал патч для удаления из документации к ядру предупреждения о характере поддержки. Язык уже используется в производственной среде, поддерживается рядом крупных дистрибутивов Linux. Стоит учитывать, что поддержка Rust пока не охватывает все возможные конфигурации ядра, архитектуры и инструментальные цепочки. Так, часть сценариев, включая смешанные сборки с GCC и LLVM, полноценная поддержку GCC остаётся экспериментальной. Значительный объём работы предстоит как в самом ядре, так и в смежных проектах – upstream Rust, GCC и других компонентах экосистемы. Ознакомиться с комментарием можно здесь.

⏺Cloudflare: 19% годового роста трафика и растущая доля ИИ-ботов
По результатам отчёта Cloudflare за 2025 год наблюдается рост глобального интернет-трафика на 19%. Из ключевых особенностей выделяем автоматизированных агентов и сервисов ИИ, которые составляют значительную часть прироста. Подобные изменения сказываются на структуре трафика и порождают требования к новой, безопасной инфраструктуре. В отчёте представлена информация по усилению угроз безопасности и снижению устойчивости сервисов. Cloudflare зафиксировала 25 крупных распределённых DDoS-атак, которые привели к сбоям и ограничению доступа сервисов. В качестве оптимального решения компания внедрила постквантовое шифрование для 52% TLS 1.3-трафика. Подготовка к будущему, в котором квантовые компьютеры обойдут системы шифрования, началась уже сейчас. Подробности об интернет сервисах, HTTP версиях, IPv6 можете прочесть здесь.

⏺«Лидеры Цифрофизации – 2025»: номинация лучший кейс
Внедрение цифровых технологий в процессы бизнеса и управления не потеряют актуальности в 2026-м. Портал TECH совместно с бизнес-клубом Global при поддержке «Деловой России» и «Ассоциация "Руссофт"» опубликовал результаты рейтинга «Лидеры Цифрофизации – 2025», задачей которого являлось отображение лидирующих российских IT-компаний в сфере финансовых услуг, научно-исследовательской деятельности, инженерии и разработки. Победителем в лидеры номинации «Лучший кейс» стал проект по внедрению 1С, системы ML Sense в ММНИО. В число лидеров вошёл кейс «TargetADS» IT-интегратора Nixys по разработке сервиса проверки качества инвентаря, антифрода с выявлением неревантных показов, кликов, что позволило оптимизировать расход рекламного бюджета. Ознакомиться с результатами рейтинга TECH можно здесь.

#docker #dynamicmcp #rust #linux #devops

Пятничное чтиво от DevOps FM

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

👀Что могло пойти не так, но с версией Kubernetes 1.35 будет работать корректно
• Под уверенно занял порт на хосте, а потом мы выяснили, что все процессы внутри работали как root. Хорошо, что теперь это можно настроить.
• Для распределённой задачи требуется 10 рабочих подов, а запустилось только 5. Что с этим делает Kubernetes 1.35?
• Образ на узле, ресурсов хватает, но под не стартует – kubelet проверяет наличие imagePullSecrets.
• Кластер не поднялся после обновления узлов. При чём тут cgroup v1 и релиз 1.35? Читайте в статье.

👀5 ошибок DevOps стартапа (версия 2025)
• DevOps как набор инструментов
Контуры процессов, технический стек внедрены, а совместной ответственности и быстрой обратной связи всё ещё нет.
• Команды работают разрозненно
Разработка, эксплуатация и безопасность живут в своих мирах – потом долго ищут виноватых и чинят одно и то же.
• Гонка за скоростью без прозрачности.
Релизы частые, но без мониторинга и логов проблемы находят пользователи, а не команда.
• Ручные операции там, где давно нужна автоматизация.
Деплой «по инструкции», инфраструктура «на память», подборка ошибок – человеческих и повторяющихся.
• Безопасность на «потом»
Сканирование, политики и контроль доступа подключают после инцидента, когда уже поздно.
Подробности читайте здесь.

👀Побойтесь DevOps-а…
Компания искала DevOps-инженера, чтобы навести порядок в инфраструктуре, и наняла специалиста с полными правами на продовые серверы. Прошло время и сотрудничество прекратили: доступы отозвали, пароли сменили, учётки заблокировали. Спустя пять дней прод внезапно упал: сервисы недоступны, логи выглядели «разорванными», массовая утечка данных. В ходе внутреннего расследования выяснили – до увольнения был создан скрытый пользователь с правами root, через VPN добавлена отложенная cron-задача на уничтожение системы, а после срабатывания последовал шантаж с требованием выкупа. Как всё закончилось? Читайте здесь.

🚀Приятного чтения! Пусть все инциденты сегодня будут только на Habr.

#пятничноечтиво #kubernetes #devops #security

🎙️Слушаем пятничную подборку подкастов в DevOps FM!

⏺Flox, Nix, and Reproducible Software Systems от Software Engineering Daily. В новом выпуске затронули проблему воспроизводимости и безопасности в современной разработке ПО и обсудили, как подход Nix к управлению пакетами и зависимостями повышает воспроизводимость и безопасность, а также роль Flox в проектах. Болл предложил варианты деплоя без классических больших Docker-образов, поднял вопросы мультиархитектурных разрешений зависимостей (разрешение «closures» и групп пакетов) и их ограничения на практике. Узнать детали – здесь.

⏺We Broke Our EKS Cluster Autoscaler with the AL2023 Migration от Kube FM. Барт Фарелл разбирает инцидент, который возник при миграции EKS на Amazon Linux 2023. Почему после обновления AMI автоскейлер потерял AWS-права в кластере, как корректно внедрить IRSA (IAM Roles for Service Accounts), проверить зависимость конкретных подов от IAM-ролей нодов и очистить устаревшие IAM-разрешения, чтобы сократить атаки после миграции – слушайте тут.

⏺ Engineering Around Extreme S3 Scale with R. Tyler Croy от Last week in AWS. Р. Тайлер Крой, инженер Scribd, рассуждает с Кори Куинном о проблеме хранения миллиардов объектов в облачном объектном хранилище S3 и. Как организовать работу, когда простые задачи обходятся компании в 100 000 долларов. В подкасте услышите тезисы о распределении бюджета на инфраструктуру в облаке, опыт Scribd, накопленный за 18 лет на рынке. Крой настаивает – стандартные решения больше не работают при большом потоке вводных данных, нужно генерировать новые. Подробности – здесь.

Приятного прослушивания и пятниц без инцидентов🛡

#подкаст #devops #kubernetes #eks

Релизы и безопасность

Срединедельный DevOps! Поговорим о том, как Cozystack 0.41 добавляет MongoDB и улучшает стабильность Kubernetes, а MX Linux 25.1 возвращает поддержку dual-init-a.

⏺Cozystack v0.41.0: MongoDB
Вышел релиз версии Cozystack. В v0.41.0 добавили поддержку системы управления БД MongoDB. Она располагается наряду с PostgreSQL, MySQL и Redis. К ключевым особенностям относим интеграцию с хранилищем бэкэндов Cozystack, настраиваемые CPU, встроенный экспорт метрик для мониторинга. Чтобы развернуть MongoDB через Cozystack дашборд используйте первый и второй workflow. Также, в новой версии представлены улучшения в работы хранилища, патчи для piraeus-server, рефакторинг проверки RWX на уровне года, повышение стабильности работы Kubernetes за счет увеличения значений resourcesPreset apiServer по умолчанию до large и увеличения порог startup-probe для kube-apiserver. Подробнее о релизе – тут.

⏺Опасайтесь VoidLink
На портале Checkpoint Research опубликовали отчёт о мультифункциональном вредоносном ПО китайского происхождения. VoidLink включает 37 плагинов, среди которых есть модули для устранения следов, выхода из контейнеров, сбора SSH-ключей, токенов и API-ключей. Фреймворк ориентирован на cloud- и container-first-среды и способен стабильно работать в Kubernetes и Docker, адаптируя поведение под окружение. Используются LD_PRELOAD, загружаемые модули ядра (LKM) и eBPF. Подробнее - здесь.

⏺Бесконечность не предел: MX Linux 25.1 «Infinity»
Релиз MX Linux 25.1, Debian-based дистрибутива. Все сборки поставляются с ядром Linux 6.12 (Debian-ветка), за исключением Xfce-AHS, где используется ядро 6.18 с патчами liquorix. В AHS-сборках также обновлён Mesa до версии 25.3.3. Включены все обновления Debian до Debian 13.3 и все актуальные обновления из репозиториев MX. В релизе анонсировали возвращение поддержки dual-init (systemd + sysvinit) в едином ISO-образе, что сокращает количество сборок, systemd теперь обновляется через Debian, а не через отдельный MX-пакет, что упрощает поддержку. Для желающих установить – инструкция тут.

#devops #cozystack #mxlinux #kubernetes #platformengineering

Новые Ops-ы: как мы дошли с Dev-а до Fin-a

В эту пятницу закрываем следующие таски: зачиллиться на дежурке (отдыхающим, просьба не завидовать 👨‍💻), не завалить прод и окунуться в историю. Если не задумывались, как от DevOps-а за 18 лет мы дошли до FinOps, зачем нам DevSec и ML – давайте разбираться вместе.

⏺DevOps умер, да здравствует DevOps!
Традиционно, считаем, что DevOps начал свой путь с модели Agile. Но мало кто упоминает пре-DevOps эру Waterfall (1970-1990-е), тёмное время для инженеров. Команды работали изолированно, Dev лишь «передавал» продукт Ops на запуск. Длинные циклы, редкие релизы, а ошибки дорого обнаруживать и ещё дороже исправлять. К счастью, в начале нулевых Agile сократил цикл от идеи до кода и дал возможность быстро тестировать гипотезы. Что было дальше, знаем: этапы роста первого (и основного) Ops-а – тут. Кстати, если вы думаете, что DevOps умирает, прочтите заметку о текущем «здоровье» – здесь.

Когда скорость разработки пришла в норму, появилась новая проблема – безопасность в CI/CD.

⏺Зачем нужна безопасность? Роль Sec-а в DevOps
Если DevOps-инженеры сосредоточены на том, как быстрее вывести приложение на рынок, этап тестирования безопасности, закономерно, уходит в конец рабочего цикла. В десятых годах 21-го века по мере совершенствования инструментов и развития процессов стало ясно – ни один отдел ИБ не успевает проверить все релизы. На помощь пришла методология DevSecOps которая устраняет уязвимости, обнаруженные в быстро меняющихся средах DevOps. В уходящем году мы успели поговорить о мифах DevSecOps, но главный вопрос открыт – что ждет DevSec сегодня? Всё об использовании инструментов 2026 читайте – тут, и там.

Как мы радовались первым чат-ботам и грезили о светлом будущем в мире ИИ. Стоило немного разобраться в его влиянии на воркфлоу и изменения цикла разработки.

⏺MLops – новый этап развития в поставке ПО
Казалось бы, процесс разработки отлажен, безопасность обеспечили, так еще и автоматизированные помощники появились. Около 8-ми лет назад компании радовались новой реальности и внедряли практики машинного обучения в рабочие процессы. Результат довольно предсказуем – около 85% проектов в области AI и ML так и не дошли до продакшена. В 2026 команды сталкиваются с техническими проблемами и сбоями в CI/CD пайплайнах и обновленной инфраструктуре (вектора DBs). Подробнее о развитии MLops – тут, а ТОП-10 инструментов ML в Ops 2026 года – здесь.

Наконец, проблемы решены, можем расслабиться… подумало сообщество, но «слишком хорошо» превратилось в «плохо».

⏺Что такое FinOps-культура и как она полезна команде?
Когда инфраструктура требовала масштабирования, её просто наращивали, и это почти не требовало объяснений. Теперь ресурсы растут соразмерно стоимости, и каждое техническое решение внезапно требует пояснений и обоснований. Оптимизация расходов – не дополнительная опция или задача под звездочкой, а новая реальность. FinOps Foundation отмечает, что компании, которые используют FinOps-практики, экономят 20–30% затрат в облаке и одновременно повышают вовлечённость команд. Team-lead инфраструктурного отдела, DevOps-инженер Nixys Пётр Рукин совместно с Практиками FinOps обозначили, кто должен заниматься внедрением культуры, как это осуществить и что с этого получают инженеры – на Habr.

А вы готовы к следующему Ops? Какие практики, по вашему мнению, станут обязательными в будущем?

#devops #devsecops #mlops #finops

Чем запомнился январь? Релизы Jenkins, Cluster API в Kubernetes и альтернативы Ingress-nginx

Всем DevOps! В эту среду сосредоточимся на изменения в политике безопасности Jenkins, новые сценарии обновлений в Cluster API и обсуждение альтернатив Ingress-nginx.

⏺Jenkins – изменения в политике безопасности, RPM-пакетировании для Red Hat и openSUSE
В релизе Jenkins 2.528.3 добавили поддержку Java 25 для контроллера и агентов, а также образы Windows Server 2022 для контейнеров. Для LTS RPM и DEB репозиториев введён новый GPG-ключ, который администраторам нужно принять при обновлении. Серьёзные изменения версии 2.528.3 коснулись управления Content Security Policy через интерфейс и API для плагинов. Пакеты Jenkins для Red Hat и openSUSE объединены в единый RPM-репозиторий с новым адресом: https://pkg.jenkins.io/rpm-stable/ . Для прошлых LTS-версий Jenkins (2.528.3 и раньше) сохранён отдельный архивный репозиторий: https://pkg.jenkins.io/redhat-stable-legacy/ .Больше о релизе – тут.

⏺Cluster API v1.12 – обновления «на месте» и «в цепочке»
В блоге Kubernetes вышла статья о новой версии Cluster API, инструменте для декларативного управления жизненным циклом кластеров. Подобно тому, как в Kubernetes можно использовать StatefulSets или Deployments для управления группой pod-ов, в Cluster API можно использовать MachineDeployments для управления группой nod-ов. В релизе представлены обновления in-place через update-extensions, теперь изменения применяются к существующим нодам без пересоздания, и chained upgrades для обновления несколько минорных версий без ручного вмешательства. Смотрите на GitHub – подробности о релизе, преимущества обновлений.

⏺Архив Ingress-nginx: какие альтернативы?
В уходящем году команда проекта Ingress-nginx сообщила о прекращении поддержки в марте 2026, подробнее писали тут. В блоге CNCF опубликовали статью о преимуществах и недостатках перехода на другой контроллер входящего трафика (Cilium Ingress, Traefik, HAProxy Ingress), или внедрения Kubernetes Gateway API. На примере Cilium Ingress первый вариант был признан самым быстрым: вы вносите минимальные изменения в манифесты приложений, CI/CD и работаете со встроенной функцией мониторинга. По версии CNCF переход на Gateway API от Cilium – самый оптимальный. Как мигрировать на Cillium Ingress – тут, а подробнее о переходе на Gateway API – здесь.

#devops #kubernetes #cloudnative #opensource

Ingress NGINX: замены нет или миграция возможна?

👤На Reddit-е обсудили прекращение поддержки Ingress NGINX, работу кластеров, которые не получают обновления безопасности, а пользователи поделились своим негодованием и возможностями миграции. Статья CNCF по альтернативам – чуть выше, а полный тред – здесь.

Реакцию пользователей на новость можно уместить в один комментарий:

Kubrador
kubectl apply -f divorce.yaml
ах да, классическая смерть open source: «пожалуйста помогите нам» в течение 4-х лет –> «ладно, с нас хватит» –> «стоп, почему никто не помогает 🙁 » в то время, как 50% кластеров k8s внезапно понимают, что они живут в доме, построенном на фундаменте надежд и молитв.

⏺Теперь перейдем к решениям, инженеры разделились на два лагеря: первый не обновляется, т.к. не видит смысла в «лишней» работе:

32b1b46b6befce6ab149
Да ну конечно, люди используют Ingress NGINX. Я тоже не обновляюсь.
На данный момент никакого аналога с прежним функционалом нет и миграция займет много времени.
Полностью переехать на Gateway API нельзя, многие public чарты всё ещё используют Ingress. Лично я не нашёл такого аналога, чтобы точь-в-точь (если он вообще есть, потому что даже у nginx-ingress немного другие аннотации), поэтому пользуюсь тем, что есть.

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

Rahomka
Всё равно на проблему вообще, мы не обновляемся

⏺Второй – использует Gateway API и дает рекомендации по альтернативам:

mirrax
Вопрос к тем, кто не обновляется, в чем проблема? Что вы такого делаете, что прям зависит от аннотаций NGINX? Вы не сможете разобраться со всем этим у другого провайдера или использовать Gateway?

EpicDan
Вы же не обязаны использовать встроенные Ingress'ы в public чартах, можно для каждого приложения добавить HTTPRoute через Gateway API, работает нормально.

pilchardus_
Мне кажется, больше 50% k8s кластеров на NGINX, лол. Лично я переезжаю на Traefik на этой неделе.

me1337
Я переехал на F5 NGINX Ingress – без проблем, всё завелось.

FluidIdea
Лично мне нравятся Envoy Gateway (EG) или kgateway, по бенчмаркам хороши. Traefik – не единственный вариант.

edeltoaster
Я уже полностью переехал на Gateway API и Envoy Gateway. Плюс собрал свой кастомный образ с расширением Go-native от Coraza. Управление входящим трафиком стало заметно лучше, пока доволен.

👀Из интересного, Кэт Косгров (K8s Steering Committee) и Табита Сэйбл (SIG Security) в подкасте предположили, что не все инженеры в курсе, поддерживаются ли их кластеры Ingress NGINX, на что пользователи справедливо отметили:

Kabrandon
Не так легко узнать, работаете ли вы с Ingress NGINX? Может, вы не мейнтейнер? Если работаете с кластерами напрямую, вы по-любому знаете, на каком ingress контролере. Сомневаюсь, что вы работаете в таком случае.

Uncommon_senze
Легко понять, используете ли вы его, он не развертывается и не настраивается сам. Но да, проблема большая.

💬Что думаете об альтернативах, уже перешли на Gateway API? Делитесь опытом в комментариях.

#devops #reddit #k8s #ingress-nginx

Slash-команды в GitHub Copilot CLI

👩‍💻 Всем DevOps! Сегодня рассмотрим slash-команды, которые помогают быстрее работать с кодом и управлять контекстом прямо в терминале. Так, вы экономите время на тестировании, исправлении багов и переключении между задачами. Обзор команд – ниже.

👀Чем полезен инструмент?
GitHub Copilot CLI доступен в режиме public preview с сентября 2025 года. Инструмент пригодится при работе вне IDE: с серверами через SSH, контейнерами, CI/CD-пайплайнами, репозиториями. GitHub Copilot CLI нужен для взаимодействия внутри GitHub без переключения контекста. Подробнее – тут. Slash-команды обеспечивают быструю установку MCP-сервера, выбор ИИ-модели под текущий запрос. По сути, мы говорим о фиксированных промтах, инструкциях, которые вводим через префикс и / в CLI.

Подборка:
⏺Команды управления сессией:
/clear – очистить контекст текущей сессии. Используется при смене задач, репозиториев или если накопленный контекст начинает влиять на подсказки.
/exit, /quit – завершить сессии, выход из CLI
/session, /usage – посмотреть информацию о сессии и статистика использования. Полезны для аудита активности, мониторинга действий Copilot
⏺Работа с директориями и файлами:
/add-dir <directory> – добавить директорию для доступа Copilot. Ограничивает область видимости и повышает безопасность.
/list-dirs – показать список директорий, доступных Copilot.
/cwd [directory] – показать или сменить рабочую директорию.
⏺Настройки и конфигурация
/model [model] – выбрать модель Copilot для CLI.
/theme [show|set|list] – управлять темой терминала, единый стиль для команды.
/reset-allowed-tools – сбросить разрешения на использование инструментов. Полезна для аудита.
⏺Внешние сервисы
/agent – выбрать Copilot-агента для отдельных задач.
/delegate <prompt> – делегировать задачи агенту с pull-request-ом.
/share [file|gist] – экспортировать сессии в Markdown или GitHub Gist для документации или передачи коллегам.
/login, /logout – войти/выйти из CLI, управлять доступом, сменить пользователя
/mcp [show|add|edit|…] – управлять конфигурацией MCP-серверов, обновить CI/CD прокси-конфигурации и enterprise настройки.
/user [show|list|switch] – управлять пользователями GitHub в терминале.
/help – список всех команд.
/feedback — сообщить об ошибках команде GitHub.

📎Подробнее о каждой команде – здесь и в GitHub Docs.

#devops #github

🔧Чиним кластеры: игра по освоению Kubernetes

В эту пятницу отправляемся в приключение! На GitHub вышел K8sQuest для тех, кто устал читать доки и хочет разобраться, как дебажить в проде на практике. В игре представлены 5 миров и 50 уровней, где предстоит разбираться с реальными проблемами внутри кластера:
⏺Мир 1: CrashLoopBackOff, ImagePullBackOff, pending поды, метки, порты
⏺Мир 2: Deployments, HPA, пробы работспособности и готовности, откаты
⏺Мир 3: Сервисы, DNS, Ingress, Сетевые политики
⏺Мир 4: PVs, PVCs, StatefulSet-ы, ConfigMap-ы, Секреты

На 50-м уровне воцарится хаос: море ошибок, шторм неопределённости :) Будет интересно новичкам и опытным инженерам.

🚀Делитесь в комментариях, до какого уровня дошли! Желаем хороших выходных, а дежурным – спокойных смен.

#devops #k8s #пятница