⚡️ DevOps Digest #26 | 03.08.2026
🔥 Главное за неделю:
1. Homelab дорос до прода: SQLite уронил control plane k3s – k3s по умолчанию хранит состояние в SQLite (через kine). Десятки операторов с leader-election раздули базу: WAL 13.8 ГБ не чекпоинтился, CPU в потолок, load 79 на 8 ядрах. Разбор инцидента + миграция на встроенный etcd (7.5 ГБ SQLite → 313 МБ etcd, load 79 → 5). Гоняешь k3s не только для тестов – закладывай etcd заранее.
🔗 https://dev.to/tomaszwostal/when-your-homelab-grows-up-how-sqlite-took-down-my-k3s-control-plane-1kdp
2. GitHub бьёт по supply-chain-атакам на npm и GitHub Actions – разбор, как устроены цепочки атак через пакеты и CI/CD (кража токенов, саморазмножение по сотням проектов) и какие защиты GitHub уже включил. Читать всем, у кого пайплайны тянут внешние экшены и пакеты.
🔗 https://github.blog/security/supply-chain-security/disrupting-supply-chain-attacks-on-npm-and-github-actions/
3. DNS – это инфраструктура. Управляй ей как кодом – домены и DNS-записи всё ещё правят руками в дашборде регистратора, без истории "кто что менял". Тезис простой: заводи их в Terraform/Ansible, как и остальную инфру. Напоминание – 1.1.1.1 от Cloudflare лежал 62 минуты не из-за атаки, а из-за misconfiguration.
🔗 https://thenewstack.io/dns-domain-management-automation/
4. Почему логи – недостающее звено в разборе инцидентов – метрики показывают, ЧТО сломалось, но первопричина чаще в логах, а прыжки между тремя инструментами (метрики → логи → трейсы) съедают время. У трети команд 5+ инструментов observability, у двух третей время до устранения больше 4 часов.
🔗 https://devops.com/why-log-monitoring-is-the-missing-link-in-most-incident-response-workflows/
5. gluetun – VPN-клиент в лёгком Docker-контейнере – один контейнер заворачивает трафик других сервисов в OpenVPN/WireGuard, с DNS-over-TLS и парой прокси из коробки. Удобно для self-hosted: прячешь исходящий трафик контейнеров за VPN, не трогая сами сервисы.
🔗 https://github.com/passteque/gluetun
6. SRE Weekly #528: контринтуитивно про инциденты – подборка недели: если гнаться за снижением ЧИСЛА инцидентов – система станет менее надёжной; цель – больше инцидентов, отработанных хорошо. Плюс новая роль incident tech lead и постмортем Spotify по сбою публикации подкастов.
🔗 https://sreweekly.com/sre-weekly-issue-528/
🛠 Команда недели:
Показывает, через какой интерфейс и с каким исходным IP реально уйдёт пакет к адресу. Мгновенно отвечает на вопрос "с какой NIC на самом деле выходит трафик" на multi-homed хосте – когда есть несколько сетей и подозреваешь асимметричный роутинг.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. Homelab дорос до прода: SQLite уронил control plane k3s – k3s по умолчанию хранит состояние в SQLite (через kine). Десятки операторов с leader-election раздули базу: WAL 13.8 ГБ не чекпоинтился, CPU в потолок, load 79 на 8 ядрах. Разбор инцидента + миграция на встроенный etcd (7.5 ГБ SQLite → 313 МБ etcd, load 79 → 5). Гоняешь k3s не только для тестов – закладывай etcd заранее.
🔗 https://dev.to/tomaszwostal/when-your-homelab-grows-up-how-sqlite-took-down-my-k3s-control-plane-1kdp
2. GitHub бьёт по supply-chain-атакам на npm и GitHub Actions – разбор, как устроены цепочки атак через пакеты и CI/CD (кража токенов, саморазмножение по сотням проектов) и какие защиты GitHub уже включил. Читать всем, у кого пайплайны тянут внешние экшены и пакеты.
🔗 https://github.blog/security/supply-chain-security/disrupting-supply-chain-attacks-on-npm-and-github-actions/
3. DNS – это инфраструктура. Управляй ей как кодом – домены и DNS-записи всё ещё правят руками в дашборде регистратора, без истории "кто что менял". Тезис простой: заводи их в Terraform/Ansible, как и остальную инфру. Напоминание – 1.1.1.1 от Cloudflare лежал 62 минуты не из-за атаки, а из-за misconfiguration.
🔗 https://thenewstack.io/dns-domain-management-automation/
4. Почему логи – недостающее звено в разборе инцидентов – метрики показывают, ЧТО сломалось, но первопричина чаще в логах, а прыжки между тремя инструментами (метрики → логи → трейсы) съедают время. У трети команд 5+ инструментов observability, у двух третей время до устранения больше 4 часов.
🔗 https://devops.com/why-log-monitoring-is-the-missing-link-in-most-incident-response-workflows/
5. gluetun – VPN-клиент в лёгком Docker-контейнере – один контейнер заворачивает трафик других сервисов в OpenVPN/WireGuard, с DNS-over-TLS и парой прокси из коробки. Удобно для self-hosted: прячешь исходящий трафик контейнеров за VPN, не трогая сами сервисы.
🔗 https://github.com/passteque/gluetun
6. SRE Weekly #528: контринтуитивно про инциденты – подборка недели: если гнаться за снижением ЧИСЛА инцидентов – система станет менее надёжной; цель – больше инцидентов, отработанных хорошо. Плюс новая роль incident tech lead и постмортем Spotify по сбою публикации подкастов.
🔗 https://sreweekly.com/sre-weekly-issue-528/
🛠 Команда недели:
ip route get 1.1.1.1
Показывает, через какой интерфейс и с каким исходным IP реально уйдёт пакет к адресу. Мгновенно отвечает на вопрос "с какой NIC на самом деле выходит трафик" на multi-homed хосте – когда есть несколько сетей и подозреваешь асимметричный роутинг.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
DEV Community
When Your Homelab Grows Up: How SQLite Took Down My k3s Control Plane
Originally published at wostal.eu. TL;DR: My Hetzner k3s lab quietly became a platform. Dozens of...
❤2🔥1
iptables -j DROP не в той строке
SSH отвалился, а до сервера уже не достучишься, пока не доберёшься до консоли.
Файрвол – это не набор правил, а алгоритм: он читает их сверху вниз и останавливается на первом совпадении.
Поставил общий DROP выше, чем ACCEPT на порт 22 и твой SSH попал под запрет раньше, чем под разрешение. Правило верное, порядок нет. На удалённом сервере это уже не отладка, а квест через управляющую консоль или через звонок админу с просьбой ребутнуть железку.
Тот же принцип белого списка кусает и в Kubernetes. Одна NetworkPolicy с default-deny на namespace и поды перестают резолвить имена: забыл открыть egress на DNS (UDP 53). По всему кластеру "Name or service not known", дежурный час копает CoreDNS, а DNS жив, его просто перестали выпускать. Обычно "виноват всегда DNS", а тут его полномочия как бы всё.
Firewall – это не стена, а фильтр: на каждый пакет решение "пропустить / отбросить молча / отказать явно" по правилам, которые читаются по порядку.
📺 Networking 20/80, шестой пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Слои, адреса, имена, соединения и HTTP уже разобрали – сегодня как этот трафик фильтровать и не отстрелить себе ногу или чего ещё 🫠
В посте:
– iptables как фундамент: таблицы, цепочки и почему их ПОРЯДОК решает – одно правило не на своём месте открывает или рубит всё;
– DROP против REJECT: почему один клиент висит до таймаута, а другой сразу ловит "refused" – и когда что выбирать;
– Kubernetes NetworkPolicy: почему в кластере по умолчанию всё открыто и как закрыть по белому списку, не уронив DNS;
– Security Groups в облаках – тот же файрвол, но для виртуалок, и чем stateful отличается от stateless;
– чеклист "почему после правила перестало работать".
Плюс три подвоха с собеса и код-челлендж: написать NetworkPolicy, которая пускает только откуда надо.
Полная версия с iptables, NetworkPolicy и Security Groups 👇
https://devopsway.ru/posts/networking-05-firewall/
#networking #security #devops
SSH отвалился, а до сервера уже не достучишься, пока не доберёшься до консоли.
Файрвол – это не набор правил, а алгоритм: он читает их сверху вниз и останавливается на первом совпадении.
Поставил общий DROP выше, чем ACCEPT на порт 22 и твой SSH попал под запрет раньше, чем под разрешение. Правило верное, порядок нет. На удалённом сервере это уже не отладка, а квест через управляющую консоль или через звонок админу с просьбой ребутнуть железку.
Тот же принцип белого списка кусает и в Kubernetes. Одна NetworkPolicy с default-deny на namespace и поды перестают резолвить имена: забыл открыть egress на DNS (UDP 53). По всему кластеру "Name or service not known", дежурный час копает CoreDNS, а DNS жив, его просто перестали выпускать. Обычно "виноват всегда DNS", а тут его полномочия как бы всё.
Firewall – это не стена, а фильтр: на каждый пакет решение "пропустить / отбросить молча / отказать явно" по правилам, которые читаются по порядку.
📺 Networking 20/80, шестой пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Слои, адреса, имена, соединения и HTTP уже разобрали – сегодня как этот трафик фильтровать и не отстрелить себе ногу или чего ещё 🫠
В посте:
– iptables как фундамент: таблицы, цепочки и почему их ПОРЯДОК решает – одно правило не на своём месте открывает или рубит всё;
– DROP против REJECT: почему один клиент висит до таймаута, а другой сразу ловит "refused" – и когда что выбирать;
– Kubernetes NetworkPolicy: почему в кластере по умолчанию всё открыто и как закрыть по белому списку, не уронив DNS;
– Security Groups в облаках – тот же файрвол, но для виртуалок, и чем stateful отличается от stateless;
– чеклист "почему после правила перестало работать".
Плюс три подвоха с собеса и код-челлендж: написать NetworkPolicy, которая пускает только откуда надо.
Полная версия с iptables, NetworkPolicy и Security Groups 👇
https://devopsway.ru/posts/networking-05-firewall/
#networking #security #devops
🔥4❤1
⚡️ DevOps Digest #27 | 10.08.2026
🔥 Главное за неделю:
1. KubeVirt: живая миграция VM между кластерами упирается не в KubeVirt, а в сеть – децентрализованная live-migration приехала в v1.6, но VM должна сохранить IP и MAC на новом кластере, а значит нужен растянутый L2 между площадками. Разбор, как это закрыть через EVPN без новых VLAN, тикетов и change-window. Актуально всем, кто переносит VM в Kubernetes взамен VMware.
🔗 https://thenewstack.io/kubevirt-evpn-vm-migration/
2. Dependabot теперь ловит вредоносные пакеты не только в npm, а в 8 экосистемах – malware-предупреждения расширены на PyPI, Maven, RubyGems, NuGet, Go, crates.io и PHP Composer (на базе открытых данных OpenSSF malicious-packages). Если тянете зависимости из публичных реестров – теперь алерты приходят и по Go, Rust, Python, а не только по JS.
🔗 https://github.blog/security/supply-chain-security/how-we-took-malware-advisories-beyond-npm/
3. Docker-песочницы в 2026: как изолировать недоверенный код и где это ломается – практический разбор границ безопасности контейнера через namespaces, cgroups и capabilities, и когда их уже мало (нужен gVisor). Главная мысль для легаси-контуров: ядро у контейнера и хоста общее, побег из контейнера = доступ к хосту.
🔗 https://dev.to/kaixintelligence/docker-sandboxes-in-2026-the-evolution-of-secure-code-isolation-55b8
4. Microsoft выложил open-source агент для генерации юнит-тестов – code-testing-generator (в репозитории dotnet/skills) полезен не столько кодом, сколько уроком про тихий отказ: AI-тесты часто компилируются и проходят локально, но никогда не запускаются в CI, потому что их забыли подключить к решению или тест-команде. Проверьте, что ваши тесты реально гоняются в пайплайне, а не только на ноутбуке.
🔗 https://devops.com/microsofts-new-testing-agent-tackles-the-trust-gap-in-ai-generated-code/
5. Ansible на русском: настройка серверов с нуля (часть 7.1 серии "С нуля до Junior DevOps") – пошагово про автоматизацию рутины после создания сервера: пакеты, пользователи, службы, Docker, Nginx. Хороший вход в IaC для джунов и тех, кто до сих пор настраивает серверы руками.
🔗 https://habr.com/ru/articles/1068460/
6. SRE Weekly #529: процесс инцидентов – это не документ, а программа – подборка недели: почему процесс управления инцидентами загнивает без поддерживающей его программы, кейс с route cache ядра как скрытым убийцей надёжности и как LLM-агенты меняют паттерны запросов к системам наблюдаемости. Пища для тех, кто выстраивает культуру эксплуатации, а не только графики.
🔗 https://sreweekly.com/sre-weekly-issue-529/
🛠 Команда недели:
Показывает счётчики ошибок и потерь по каждому интерфейсу (errors, dropped, overrun) – первый шаг, когда подозреваешь потерю пакетов или флапающий линк, прежде чем винить приложение или сеть.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное за неделю:
1. KubeVirt: живая миграция VM между кластерами упирается не в KubeVirt, а в сеть – децентрализованная live-migration приехала в v1.6, но VM должна сохранить IP и MAC на новом кластере, а значит нужен растянутый L2 между площадками. Разбор, как это закрыть через EVPN без новых VLAN, тикетов и change-window. Актуально всем, кто переносит VM в Kubernetes взамен VMware.
🔗 https://thenewstack.io/kubevirt-evpn-vm-migration/
2. Dependabot теперь ловит вредоносные пакеты не только в npm, а в 8 экосистемах – malware-предупреждения расширены на PyPI, Maven, RubyGems, NuGet, Go, crates.io и PHP Composer (на базе открытых данных OpenSSF malicious-packages). Если тянете зависимости из публичных реестров – теперь алерты приходят и по Go, Rust, Python, а не только по JS.
🔗 https://github.blog/security/supply-chain-security/how-we-took-malware-advisories-beyond-npm/
3. Docker-песочницы в 2026: как изолировать недоверенный код и где это ломается – практический разбор границ безопасности контейнера через namespaces, cgroups и capabilities, и когда их уже мало (нужен gVisor). Главная мысль для легаси-контуров: ядро у контейнера и хоста общее, побег из контейнера = доступ к хосту.
🔗 https://dev.to/kaixintelligence/docker-sandboxes-in-2026-the-evolution-of-secure-code-isolation-55b8
4. Microsoft выложил open-source агент для генерации юнит-тестов – code-testing-generator (в репозитории dotnet/skills) полезен не столько кодом, сколько уроком про тихий отказ: AI-тесты часто компилируются и проходят локально, но никогда не запускаются в CI, потому что их забыли подключить к решению или тест-команде. Проверьте, что ваши тесты реально гоняются в пайплайне, а не только на ноутбуке.
🔗 https://devops.com/microsofts-new-testing-agent-tackles-the-trust-gap-in-ai-generated-code/
5. Ansible на русском: настройка серверов с нуля (часть 7.1 серии "С нуля до Junior DevOps") – пошагово про автоматизацию рутины после создания сервера: пакеты, пользователи, службы, Docker, Nginx. Хороший вход в IaC для джунов и тех, кто до сих пор настраивает серверы руками.
🔗 https://habr.com/ru/articles/1068460/
6. SRE Weekly #529: процесс инцидентов – это не документ, а программа – подборка недели: почему процесс управления инцидентами загнивает без поддерживающей его программы, кейс с route cache ядра как скрытым убийцей надёжности и как LLM-агенты меняют паттерны запросов к системам наблюдаемости. Пища для тех, кто выстраивает культуру эксплуатации, а не только графики.
🔗 https://sreweekly.com/sre-weekly-issue-529/
🛠 Команда недели:
ip -s link
Показывает счётчики ошибок и потерь по каждому интерфейсу (errors, dropped, overrun) – первый шаг, когда подозреваешь потерю пакетов или флапающий линк, прежде чем винить приложение или сеть.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
The New Stack
Why your KubeVirt VMs can’t move between clusters — and how EVPN fixes it
Migrate KubeVirt VMs between clusters seamlessly with EVPN/VXLAN overlays and OpenPERouter CRDs. No network tickets required.
🔥6❤1
kubectl get pods – всё Running, казалось бы.
Service есть. А в ответ – 503.
Потому что selector в Service разошёлся с labels пода на один символ, и список endpoint-ов пустой. Кубер сделал ровно что просили: слать трафик туда, где никого нет.
Service – это вам не сервер. Это правило "куда слать": совпали labels – есть endpoint-ы, не совпали, пока пока, 503 при живых подах. И так на каждом слое: снаружи Ingress (L7, роутинг по Host/URL) → Service (L4, стабильный IP) → iptables/kube-proxy → pod. Пять мест, где "всё выглядит правильно", а трафик не идёт.
📺 Networking 20/80, седьмой и последний пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Модель, адреса, DNS, TCP, HTTP и файрволы уже разобрали – сегодня собираем всё вместе: как запрос снаружи долетает до пода и делится между репликами.
В посте:
– L4 против L7: почему Service балансирует по IP:порту, а маршрутизация по URL и Host – это уже Ingress;
– четыре типа Service (ClusterIP / NodePort / LoadBalancer / ExternalName) – что где открывается наружу;
– Ingress и nginx как обратный прокси: терминация TLS, upstream, алгоритмы балансировки – и почему их нельзя смешивать в одном upstream;
– service mesh на пальцах: что даёт sidecar (Envoy) и почему джуну не надо настраивать Istio;
– чеклист диагностики: Service → Endpoints → DNS → Ingress, где именно рвётся.
И да – контроллер ingress-nginx ушёл на пенсию в марте 2026. Поэтому разбираем принципы L4/L7, а не один тул: они переносятся на любой контроллер.
Плюс три подвоха с собеса (в том числе "почему kube-proxy – вовсе не proxy") и финальный код-челлендж: описать весь путь запроса от https://… до пода по слоям.
Финал мини-курса. Полная версия 👇
https://devopsway.ru/posts/networking-06-lb-k8s/
#networking #kubernetes #devops
Service есть. А в ответ – 503.
Потому что selector в Service разошёлся с labels пода на один символ, и список endpoint-ов пустой. Кубер сделал ровно что просили: слать трафик туда, где никого нет.
Service – это вам не сервер. Это правило "куда слать": совпали labels – есть endpoint-ы, не совпали, пока пока, 503 при живых подах. И так на каждом слое: снаружи Ingress (L7, роутинг по Host/URL) → Service (L4, стабильный IP) → iptables/kube-proxy → pod. Пять мест, где "всё выглядит правильно", а трафик не идёт.
📺 Networking 20/80, седьмой и последний пост. Те самые 20% сетей, что закрывают 80% работы DevOps. Модель, адреса, DNS, TCP, HTTP и файрволы уже разобрали – сегодня собираем всё вместе: как запрос снаружи долетает до пода и делится между репликами.
В посте:
– L4 против L7: почему Service балансирует по IP:порту, а маршрутизация по URL и Host – это уже Ingress;
– четыре типа Service (ClusterIP / NodePort / LoadBalancer / ExternalName) – что где открывается наружу;
– Ingress и nginx как обратный прокси: терминация TLS, upstream, алгоритмы балансировки – и почему их нельзя смешивать в одном upstream;
– service mesh на пальцах: что даёт sidecar (Envoy) и почему джуну не надо настраивать Istio;
– чеклист диагностики: Service → Endpoints → DNS → Ingress, где именно рвётся.
И да – контроллер ingress-nginx ушёл на пенсию в марте 2026. Поэтому разбираем принципы L4/L7, а не один тул: они переносятся на любой контроллер.
Плюс три подвоха с собеса (в том числе "почему kube-proxy – вовсе не proxy") и финальный код-челлендж: описать весь путь запроса от https://… до пода по слоям.
Финал мини-курса. Полная версия 👇
https://devopsway.ru/posts/networking-06-lb-k8s/
#networking #kubernetes #devops
🔥4
⚡️ DevOps Digest #28 | 17.08.2026
🔥 Главное:
1. Flux выпустил Flux Mirror – плагин CLI, который по декларативной конфигурации зеркалирует образы, Helm-чарты и OCI-артефакты между реестрами с проверкой политик прямо при синхронизации. Для закрытого контура это способ убрать чужие реестры из своей прод-архитектуры (привет rate limits Docker Hub и заморозке каталога Bitnami).
🔗 https://fluxcd.io/blog/2026/08/flux-mirror/
2. GitLab Secrets Manager (на движке OpenBao) получил поддержку External Secrets Operator и Terraform/OpenTofu. Один секрет-стор с Vault-совместимым KV v2 API для рабочих нагрузок Kubernetes, IaC и CI/CD – меньше рассинхрона моделей доступа и разрозненных журналов аудита.
🔗 https://about.gitlab.com/blog/gitlab-secrets-manager-add-eso-terraform-api-support/
3. ProjectDiscovery выпустила Neo 1.0 – открытую платформу автономного тестирования уязвимостей на базе Nuclei, Subfinder, httpx, Katana и Naabu. Есть интеграции с GitHub, Jira и Model Context Protocol; ядро полностью open-source, что удобно для self-hosted обвязки.
🔗 https://devops.com/projectdiscovery-brings-open-source-ai-testing-to-vulnerability-discovery/
🔍 Неподписанные образы – это отложенная мина
Сканер отвечает на вопрос "что лежит внутри образа", но не на главный: "кто его собрал и не подменили ли его после сборки". Это разные гарантии, и вторую даёт только криптографическая подпись. В закрытом контуре с внутренними реестрами подпись через cosign плюс проверка на этапе синхронизации (та же Flux Mirror) и на admission (Kyverno/policy-controller) – это не роскошь, а базовая гигиена цепочки поставки, особенно с учётом наследования от базовых образов.
🔗 https://thenewstack.io/unsigned-container-images-ai/
🛠 Команда дня:
Показывает самые тяжёлые слои образа – сразу видно, какой шаг сборки раздувает вес и где резать.
#дайджест #security #devops
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное:
1. Flux выпустил Flux Mirror – плагин CLI, который по декларативной конфигурации зеркалирует образы, Helm-чарты и OCI-артефакты между реестрами с проверкой политик прямо при синхронизации. Для закрытого контура это способ убрать чужие реестры из своей прод-архитектуры (привет rate limits Docker Hub и заморозке каталога Bitnami).
🔗 https://fluxcd.io/blog/2026/08/flux-mirror/
2. GitLab Secrets Manager (на движке OpenBao) получил поддержку External Secrets Operator и Terraform/OpenTofu. Один секрет-стор с Vault-совместимым KV v2 API для рабочих нагрузок Kubernetes, IaC и CI/CD – меньше рассинхрона моделей доступа и разрозненных журналов аудита.
🔗 https://about.gitlab.com/blog/gitlab-secrets-manager-add-eso-terraform-api-support/
3. ProjectDiscovery выпустила Neo 1.0 – открытую платформу автономного тестирования уязвимостей на базе Nuclei, Subfinder, httpx, Katana и Naabu. Есть интеграции с GitHub, Jira и Model Context Protocol; ядро полностью open-source, что удобно для self-hosted обвязки.
🔗 https://devops.com/projectdiscovery-brings-open-source-ai-testing-to-vulnerability-discovery/
🔍 Неподписанные образы – это отложенная мина
Сканер отвечает на вопрос "что лежит внутри образа", но не на главный: "кто его собрал и не подменили ли его после сборки". Это разные гарантии, и вторую даёт только криптографическая подпись. В закрытом контуре с внутренними реестрами подпись через cosign плюс проверка на этапе синхронизации (та же Flux Mirror) и на admission (Kyverno/policy-controller) – это не роскошь, а базовая гигиена цепочки поставки, особенно с учётом наследования от базовых образов.
🔗 https://thenewstack.io/unsigned-container-images-ai/
🛠 Команда дня:
docker history --human --format '{{.Size}}\t{{.CreatedBy}}' nginx:latest | sort -rh | headПоказывает самые тяжёлые слои образа – сразу видно, какой шаг сборки раздувает вес и где резать.
#дайджест #security #devops
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
fluxcd.io
Introducing Flux Mirror
Declarative mirroring for container images, Helm charts, and OCI artifacts, with signature verification, provenance policies, and minimum artifact age.
❤1👍1🥰1
Раньше как было? Берешь железку, операционную систему, шаманский бубен, собираешь систему с нуля и получаешь ровно то, что нужно.
Ничего лишнего, только железобетонная стабильность.
Прошло энцать лет.
Как встроенный беспроводной интернет положил сервер на 6 часов
9 августа мой главный рабочий компухтер, на котором крутится ЛЛМка, ушел в глухой зависон. Без предупреждений, без нормального завершения работы, журнал просто обрывается.
Первая мысль, наверное, питание, в июле уже было похожее. Но нет, соседний бокс на том же порту пахал 25 дней без единого чиха. Сеть жива.
Лезем в системные журналы за прошлый сеанс. За 6 минут до смерти видим каскад системных ошибок. Виновник? Встроенный модуль беспроводной связи MediaTek. Прошивка потеряла связь, драйвер пошел в перезагрузку, зацепил оперативную память и всё завертелось, система встала намертво.
Самое обидное: этот беспроводной модуль вообще никогда не включался. Сервер подключен к интернету через обычный провод, беспроводная сеть не использовалась. Программа управления просто болталась в памяти и померла от скуки.
Что сделал:
Прописал в системе жесткий запрет на запуск драйверов этой беспроводной платы.
Пересобрал загрузочный образ, чтобы эта зараза даже не пыталась грузиться на старте.
Включил аппаратный сторожевой таймер. Если опять повиснет — перезагрузится сам за полминуты, а не будет лежать тушкой до ручного перезапуска.
Мораль сей басни такова:
Неиспользуемая часть системы, не "пусть висит", а готовая точка отказа. Особенно всякие беспроводные чипы на платах, которые мы берем с запасом.
Удаляйте всё, что не нужно. Запрещайте то, чем не пользуетесь. И ставьте автоматическую перезагрузку на всё, к чему не хочется ездить ногами.
#DevITWay #ProductionStories #Linux
Ничего лишнего, только железобетонная стабильность.
Прошло энцать лет.
Как встроенный беспроводной интернет положил сервер на 6 часов
9 августа мой главный рабочий компухтер, на котором крутится ЛЛМка, ушел в глухой зависон. Без предупреждений, без нормального завершения работы, журнал просто обрывается.
Первая мысль, наверное, питание, в июле уже было похожее. Но нет, соседний бокс на том же порту пахал 25 дней без единого чиха. Сеть жива.
Лезем в системные журналы за прошлый сеанс. За 6 минут до смерти видим каскад системных ошибок. Виновник? Встроенный модуль беспроводной связи MediaTek. Прошивка потеряла связь, драйвер пошел в перезагрузку, зацепил оперативную память и всё завертелось, система встала намертво.
Самое обидное: этот беспроводной модуль вообще никогда не включался. Сервер подключен к интернету через обычный провод, беспроводная сеть не использовалась. Программа управления просто болталась в памяти и померла от скуки.
Что сделал:
Прописал в системе жесткий запрет на запуск драйверов этой беспроводной платы.
Пересобрал загрузочный образ, чтобы эта зараза даже не пыталась грузиться на старте.
Включил аппаратный сторожевой таймер. Если опять повиснет — перезагрузится сам за полминуты, а не будет лежать тушкой до ручного перезапуска.
Мораль сей басни такова:
Неиспользуемая часть системы, не "пусть висит", а готовая точка отказа. Особенно всякие беспроводные чипы на платах, которые мы берем с запасом.
Удаляйте всё, что не нужно. Запрещайте то, чем не пользуетесь. И ставьте автоматическую перезагрузку на всё, к чему не хочется ездить ногами.
#DevITWay #ProductionStories #Linux
👍4❤1🔥1
⚡️ DevOps Digest #29 | 24.08.2026
🔥 Главное:
1. Radar – open-source UI для Kubernetes от Skyhook: один Go-бинарник без регистрации, топология кластера, timeline событий, менеджер Helm-релизов, GitOps для FluxCD и встроенный read-only MCP-сервер для ИИ-агентов. Разворачивается через Helm, замена связке Lens/Headlamp без тяжёлого десктоп-стека, разумный дефолт "только чтение".
🔗 https://habr.com/ru/articles/1073566/
2. Критический RCE в Serena, одном из популярных ИИ-агентов для кода: вредоносный .serena/project.yml выполняет произвольный код в момент открытия проекта, обходя защиту trusted_project_path_patterns. Обновляйтесь до 1.7.0 – и это первый пример нового класса угроз через MCP-серверы.
🔗 https://about.gitlab.com/blog/critical-rce-in-serena/
3. Flux Mirror – новый плагин Flux CLI зеркалит образы, Helm-чарты и OCI-артефакты между реестрами по декларативной конфигурации с проверкой политик при синхронизации. Прямое лекарство для закрытых контуров: заморозка бесплатного каталога Bitnami и лимиты Docker Hub перестают быть частью вашей прод-архитектуры.
🔗 https://fluxcd.io/blog/2026/08/flux-mirror/
4. Практический разбор Node NotReady: это два инцидента в одном – больной узел и осиротевшие поды. Kubelet жив и жалуется (сломанный runtime/CNI/PLEG) – чинишь на узле через journalctl -u kubelet; kubelet молчит – это мёртвый узел, протухший сертификат или сетевой разрыв, и через 5 минут поды выселяются по NoExecute-taint.
🔗 https://dev.to/devtocash/kubernetes-node-notready-how-to-debug-and-fix-it-5cda
5. Kubernetes v1.37 sneak peek: депрекация режима ipvs у kube-proxy, статичные поды больше не могут ссылаться на Secrets/ConfigMaps (feature gate удалён), депрекация kubectl run -f. Проверьте манифесты заранее, особенно если держите kube-proxy в режиме ipvs.
🔗 https://kubernetes.io/blog/2026/07/31/kubernetes-v1-37-sneak-peek/
🔍 Подпись образов: сканер говорит что внутри, но не кто собрал
Сканирование отвечает на вопрос "какие уязвимости в образе", но не на "кто его собрал и не подменили ли его после сборки" – а это важнее, когда каждый образ наследует базовый по цепочке. Практический минимум за пару часов: заморозить непроверенные зависимости с периодом выдержки и отключить lifecycle-скрипты, собирать через multi-stage, генерировать SBOM с провенансом и блокировать в CI исправимые Critical-CVE по точному digest образа. Подпись – это проактивное доказательство происхождения, а не реактивное сканирование постфактум.
🔗 https://thenewstack.io/unsigned-container-images-ai/
🛠 Команда дня:
Показывает файловые системы, где израсходовано больше 80% inode – частая причина "No space left on device", когда df -h показывает свободное место.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное:
1. Radar – open-source UI для Kubernetes от Skyhook: один Go-бинарник без регистрации, топология кластера, timeline событий, менеджер Helm-релизов, GitOps для FluxCD и встроенный read-only MCP-сервер для ИИ-агентов. Разворачивается через Helm, замена связке Lens/Headlamp без тяжёлого десктоп-стека, разумный дефолт "только чтение".
🔗 https://habr.com/ru/articles/1073566/
2. Критический RCE в Serena, одном из популярных ИИ-агентов для кода: вредоносный .serena/project.yml выполняет произвольный код в момент открытия проекта, обходя защиту trusted_project_path_patterns. Обновляйтесь до 1.7.0 – и это первый пример нового класса угроз через MCP-серверы.
🔗 https://about.gitlab.com/blog/critical-rce-in-serena/
3. Flux Mirror – новый плагин Flux CLI зеркалит образы, Helm-чарты и OCI-артефакты между реестрами по декларативной конфигурации с проверкой политик при синхронизации. Прямое лекарство для закрытых контуров: заморозка бесплатного каталога Bitnami и лимиты Docker Hub перестают быть частью вашей прод-архитектуры.
🔗 https://fluxcd.io/blog/2026/08/flux-mirror/
4. Практический разбор Node NotReady: это два инцидента в одном – больной узел и осиротевшие поды. Kubelet жив и жалуется (сломанный runtime/CNI/PLEG) – чинишь на узле через journalctl -u kubelet; kubelet молчит – это мёртвый узел, протухший сертификат или сетевой разрыв, и через 5 минут поды выселяются по NoExecute-taint.
🔗 https://dev.to/devtocash/kubernetes-node-notready-how-to-debug-and-fix-it-5cda
5. Kubernetes v1.37 sneak peek: депрекация режима ipvs у kube-proxy, статичные поды больше не могут ссылаться на Secrets/ConfigMaps (feature gate удалён), депрекация kubectl run -f. Проверьте манифесты заранее, особенно если держите kube-proxy в режиме ipvs.
🔗 https://kubernetes.io/blog/2026/07/31/kubernetes-v1-37-sneak-peek/
🔍 Подпись образов: сканер говорит что внутри, но не кто собрал
Сканирование отвечает на вопрос "какие уязвимости в образе", но не на "кто его собрал и не подменили ли его после сборки" – а это важнее, когда каждый образ наследует базовый по цепочке. Практический минимум за пару часов: заморозить непроверенные зависимости с периодом выдержки и отключить lifecycle-скрипты, собирать через multi-stage, генерировать SBOM с провенансом и блокировать в CI исправимые Critical-CVE по точному digest образа. Подпись – это проактивное доказательство происхождения, а не реактивное сканирование постфактум.
🔗 https://thenewstack.io/unsigned-container-images-ai/
🛠 Команда дня:
df -i | awk 'NR==1 || ($5+0)>80'
Показывает файловые системы, где израсходовано больше 80% inode – частая причина "No space left on device", когда df -h показывает свободное место.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
👍2❤1🔥1
Вот лето пролетело, но мы-то знаем, что лучшее впереди
Прошлой весной я всерьёз залез в LLM. Читал про очередную модель и думал: да они же скоро всё смогут. Ещё годик, и кодить будет нейросеть, а я – элегантно ей дирижировать.
Прошло чуть больше года.
Есть такой киноприём: первый кадр – герой висит над пропастью или горит в машине, всё вокруг летит к чёрту, картинка замирает, и голос за кадром: "Вам, наверное, интересно, как я сюда попал". Вот это самое я чувствую каждое утро, вставая к компу. Да, теперь не дом – работа – дом, а кровать – комп – кровать, ибо пришлось помарафонить.
До этого я много лет работал в энтерпрайзе, где у каждой ручки сидел специально обученный человек. Хочешь релиз – заявка, согласование, окно. Медленно, бюрократично, зато крайний – никогда не ты.
Мне бы убрать к чёрту все эти преграды, дайте рычаги – сам сделаю быстро и как надо. И тут подвернулся ровно такой шанс. Правда, теперь всё чаще ловлю себя на мысли, что надо было в сантехники.
Мечта сбылась. Преград не осталось. Крайний теперь всегда один.
На текущем проекте я не абы кто, не разработчик, не девопс, а тот чувак с ЛЛМками. Задача на словах простая: перенести двухлетнее легаси. На деле – раскопки. Археологические слои, по которым читается смена поколений: вот код, который писали руками; вот место, где в проект зашли LLM; вот костыли и самокаты, наваленные лишь бы закрыть задачу к дедлайну. И теперь всё это моё. 🤪
Как говорится, "бойтесь своих желаний" (с). Человек-оркестр – мечта идиота: я хотел мир без бюрократии и без специально обученного человека на каждой ручке, и получил его целиком. Вместе со всеми ручками. Команду ещё предстоит набрать и обучить.
Так что это новая рубрика – записки сумасшедшего девопса. Что горело, что я потушил, что поджёг сам. Часто это один и тот же пожар.
Дальше буду показывать и рассказывать, из каких ролей этот оркестр собран на самом деле и на какие грабли я в каждой напоролся. Может, чего и вам пригодится.
#devops #LLM #человек_оркестр
Прошлой весной я всерьёз залез в LLM. Читал про очередную модель и думал: да они же скоро всё смогут. Ещё годик, и кодить будет нейросеть, а я – элегантно ей дирижировать.
Прошло чуть больше года.
Есть такой киноприём: первый кадр – герой висит над пропастью или горит в машине, всё вокруг летит к чёрту, картинка замирает, и голос за кадром: "Вам, наверное, интересно, как я сюда попал". Вот это самое я чувствую каждое утро, вставая к компу. Да, теперь не дом – работа – дом, а кровать – комп – кровать, ибо пришлось помарафонить.
До этого я много лет работал в энтерпрайзе, где у каждой ручки сидел специально обученный человек. Хочешь релиз – заявка, согласование, окно. Медленно, бюрократично, зато крайний – никогда не ты.
Мне бы убрать к чёрту все эти преграды, дайте рычаги – сам сделаю быстро и как надо. И тут подвернулся ровно такой шанс. Правда, теперь всё чаще ловлю себя на мысли, что надо было в сантехники.
Мечта сбылась. Преград не осталось. Крайний теперь всегда один.
На текущем проекте я не абы кто, не разработчик, не девопс, а тот чувак с ЛЛМками. Задача на словах простая: перенести двухлетнее легаси. На деле – раскопки. Археологические слои, по которым читается смена поколений: вот код, который писали руками; вот место, где в проект зашли LLM; вот костыли и самокаты, наваленные лишь бы закрыть задачу к дедлайну. И теперь всё это моё. 🤪
Как говорится, "бойтесь своих желаний" (с). Человек-оркестр – мечта идиота: я хотел мир без бюрократии и без специально обученного человека на каждой ручке, и получил его целиком. Вместе со всеми ручками. Команду ещё предстоит набрать и обучить.
Так что это новая рубрика – записки сумасшедшего девопса. Что горело, что я потушил, что поджёг сам. Часто это один и тот же пожар.
Дальше буду показывать и рассказывать, из каких ролей этот оркестр собран на самом деле и на какие грабли я в каждой напоролся. Может, чего и вам пригодится.
#devops #LLM #человек_оркестр
🔥5👍3❤2😁2
⚡️ DevOps Digest #30 | 31.08.2026
🔥 Главное:
1. Вышел Kubernetes v1.37 "Garhwal" – 67 изменений, из них 16 в Stable. Ключевое для эксплуатации: Metrics API (
🔗 https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/
2. Критическая уязвимость в Redis (CVE-2026-81934): use-after-free при обработке TLS-данных, аутентифицированный атакующий потенциально получает удалённое выполнение кода. Патч уже вышел – если Redis смотрит наружу с TLS, обновляйтесь не откладывая.
🔗 https://redis.io/blog/security-advisory-cve-2026-81934/
3. Практика экономии на нодах Kubernetes: паттерн node overprovisioning через PriorityClass и placeholder-поды. KEDA схлопывает кластер ночью, а утром пустые capacity-поды мгновенно отдают место бизнес-нагрузке – никакого ожидания, пока Cluster Autoscaler поднимет новую ноду. Готовый демо-стенд в статье.
🔗 https://habr.com/ru/articles/1076538/
4. Cloudflare переупаковала DNS-кэш 1.1.1.1: пять изменений раскладки в памяти срезали размер записи более чем на 50% и освободили около 100 ТБ RAM по флоту. Бонусом +43% на вставку и −19% к задержке чтения – редкий случай, когда экономия памяти ещё и ускоряет.
🔗 https://blog.cloudflare.com/dns-cache-memory-optimization-1111/
5. GitLab показал next-gen SCM: Git проектировался под людей, а не под флот агентов. Клон ради одного файла = 5–10 ГБ трафика и 30+ секунд на старт; переписывают бэкенд под изоляцию сессий и concurrency. Разработчикам с автоматизацией под сотни агентов стоит следить.
🔗 https://about.gitlab.com/blog/gitlab-next-gen-scm/
🔍 Обновление сертификата – это деплой-процесс, а не задача в cron:
Успешная ACME-транзакция доказывает лишь, что сертификат выпущен, – но не то, что нужный сервис отдаёт его пользователям. Между выпуском и рабочим состоянием ломается всё: файл не скопировался на хост, контейнер не перемонтировал секрет, nginx/HAProxy не сделал reload. Правильная модель – это цепочка renew → deploy → reload → verify → recover, где каждый шаг проверяется, а не считается выполненным по факту зелёного джоба. Если руками надоело – посмотрите на self-hosted certimate: полный цикл выпуска, деплоя, продления и мониторинга ACME-сертификатов визуально.
🔗 https://github.com/certimate-go/certimate
🛠 Команда дня:
Показывает текущее число отслеживаемых соединений и лимит conntrack – если первое подбирается ко второму, ядро начнёт дропать пакеты (nf_conntrack: table full), и это одна из любимых причин "загадочных" таймаутов на нодах Kubernetes.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное:
1. Вышел Kubernetes v1.37 "Garhwal" – 67 изменений, из них 16 в Stable. Ключевое для эксплуатации: Metrics API (
metrics.k8s.io, за kubectl top и HPA) доведён до v1, а Pod Certificates и Cluster Trust Bundles стали GA – выдача X.509 для TLS/mTLS встроена прямо в ядро, без внешнего CA для рабочих нагрузок.🔗 https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/
2. Критическая уязвимость в Redis (CVE-2026-81934): use-after-free при обработке TLS-данных, аутентифицированный атакующий потенциально получает удалённое выполнение кода. Патч уже вышел – если Redis смотрит наружу с TLS, обновляйтесь не откладывая.
🔗 https://redis.io/blog/security-advisory-cve-2026-81934/
3. Практика экономии на нодах Kubernetes: паттерн node overprovisioning через PriorityClass и placeholder-поды. KEDA схлопывает кластер ночью, а утром пустые capacity-поды мгновенно отдают место бизнес-нагрузке – никакого ожидания, пока Cluster Autoscaler поднимет новую ноду. Готовый демо-стенд в статье.
🔗 https://habr.com/ru/articles/1076538/
4. Cloudflare переупаковала DNS-кэш 1.1.1.1: пять изменений раскладки в памяти срезали размер записи более чем на 50% и освободили около 100 ТБ RAM по флоту. Бонусом +43% на вставку и −19% к задержке чтения – редкий случай, когда экономия памяти ещё и ускоряет.
🔗 https://blog.cloudflare.com/dns-cache-memory-optimization-1111/
5. GitLab показал next-gen SCM: Git проектировался под людей, а не под флот агентов. Клон ради одного файла = 5–10 ГБ трафика и 30+ секунд на старт; переписывают бэкенд под изоляцию сессий и concurrency. Разработчикам с автоматизацией под сотни агентов стоит следить.
🔗 https://about.gitlab.com/blog/gitlab-next-gen-scm/
🔍 Обновление сертификата – это деплой-процесс, а не задача в cron:
Успешная ACME-транзакция доказывает лишь, что сертификат выпущен, – но не то, что нужный сервис отдаёт его пользователям. Между выпуском и рабочим состоянием ломается всё: файл не скопировался на хост, контейнер не перемонтировал секрет, nginx/HAProxy не сделал reload. Правильная модель – это цепочка renew → deploy → reload → verify → recover, где каждый шаг проверяется, а не считается выполненным по факту зелёного джоба. Если руками надоело – посмотрите на self-hosted certimate: полный цикл выпуска, деплоя, продления и мониторинга ACME-сертификатов визуально.
🔗 https://github.com/certimate-go/certimate
🛠 Команда дня:
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max
Показывает текущее число отслеживаемых соединений и лимит conntrack – если первое подбирается ко второму, ядро начнёт дропать пакеты (nf_conntrack: table full), и это одна из любимых причин "загадочных" таймаутов на нодах Kubernetes.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
Kubernetes
Kubernetes v1.37: Garhwal
Editors: Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor
Similar to previous releases, the release of Kubernetes v1.37 introduces new Stable, Beta, and Alpha features. The consistent delivery of high-quality releases…
Similar to previous releases, the release of Kubernetes v1.37 introduces new Stable, Beta, and Alpha features. The consistent delivery of high-quality releases…
👍3❤1🔥1
Наберут по объявлениям
На собеседовании врут все. И ты, и они – и оба про это знают.
Вакансия обычно пишется как объявление о знакомстве, что-то типа: "Ищу сеньора, амбициозного, стек новейший, команда мечты, печеньки". А спустя какое-то время, уже на проекте, читается как: "нужен хоть кто-нибудь, кто вынесет и не сбежит до конца квартала".
Помнишь это ликование?Или уже прожжённый и понимаешь, что надо снова брать лопату и кирку 🫠? Оффер на руках, тестовое зачли с восторгом, джекпот. А потом открывается дверь онбординга.
Ожидание: микросервисы, чистый GitOps, автотесты, ноль легаси.
Реальность: монолит из две тысячи двенадцатого, бизнес-логика с SQL прямо в контроллерах, деплой руками по пятницам.
Ожидание: ментор на две недели.
Реальность: битая ссылка на Confluence 2021-го и "посмотри код, там всё интуитивно, если что – пиши".
Но если разобраться. Сколько раз это было ударом в спину, а сколько – осознанным заходом в костёр, где ты заранее знал, где рванёт первая мина? На каждое оправдание менеджера ты уже такой: "ха-ха, классика".
Сильный инженер обычно прекрасно понимает, куда идёт. Не вслепую – с открытыми глазами. Смотришь на горящий легаси-лес, на тварь из спагетти и хардкода, хрустишь пальцами: есть где развернуться. А из-за угла за тобой Мёрфи смотрит и улыбается 😝
В резюме у тебя три роли – архитектор, лидер, гуру чистого кода. Три богатыря в одном лице. Из чащи вываливается многоголовая тварь, а у тебя против неё ни команды, ни тормозов: сам себе и жнец, и чтец, и ночной SRE-молодец. У каждой головы своё имя – от "срочно в прод" до "а где документация?".
А теперь поворот. Иногда вакансия не врёт. Иногда там честно написано: "быстрые релизы, агентная разработка". И это уже не ловушка, а прямое приглашение на родео.
Думаете, там всё готовенькое было? Агенты сами пишут, сами катят, а я знай себе дирижирую.
Зато честно. Без иллюзий про неспешные код-ревью. Вот на такую честную вакансию я и полез – сам, с открытыми глазами. Хотел мир без бюрократии, без специально обученного человека на каждой ручке. Получил. Со всеми ручками разом.
А что именно было за той дверью – я и сам толком не знал. Узнал в первые дни, но дно оказалось не одно и не два, а сколько голов у того супостата с картинки. Дальше расскажу про анатомию супостата.
#devops #LLM #человек_оркестр
На собеседовании врут все. И ты, и они – и оба про это знают.
Вакансия обычно пишется как объявление о знакомстве, что-то типа: "Ищу сеньора, амбициозного, стек новейший, команда мечты, печеньки". А спустя какое-то время, уже на проекте, читается как: "нужен хоть кто-нибудь, кто вынесет и не сбежит до конца квартала".
Помнишь это ликование?
Ожидание: микросервисы, чистый GitOps, автотесты, ноль легаси.
Реальность: монолит из две тысячи двенадцатого, бизнес-логика с SQL прямо в контроллерах, деплой руками по пятницам.
Ожидание: ментор на две недели.
Реальность: битая ссылка на Confluence 2021-го и "посмотри код, там всё интуитивно, если что – пиши".
Но если разобраться. Сколько раз это было ударом в спину, а сколько – осознанным заходом в костёр, где ты заранее знал, где рванёт первая мина? На каждое оправдание менеджера ты уже такой: "ха-ха, классика".
Сильный инженер обычно прекрасно понимает, куда идёт. Не вслепую – с открытыми глазами. Смотришь на горящий легаси-лес, на тварь из спагетти и хардкода, хрустишь пальцами: есть где развернуться. А из-за угла за тобой Мёрфи смотрит и улыбается 😝
В резюме у тебя три роли – архитектор, лидер, гуру чистого кода. Три богатыря в одном лице. Из чащи вываливается многоголовая тварь, а у тебя против неё ни команды, ни тормозов: сам себе и жнец, и чтец, и ночной SRE-молодец. У каждой головы своё имя – от "срочно в прод" до "а где документация?".
А теперь поворот. Иногда вакансия не врёт. Иногда там честно написано: "быстрые релизы, агентная разработка". И это уже не ловушка, а прямое приглашение на родео.
Думаете, там всё готовенькое было? Агенты сами пишут, сами катят, а я знай себе дирижирую.
– Пейн, я не чувствую ног!
– У тебя их нет.
Зато честно. Без иллюзий про неспешные код-ревью. Вот на такую честную вакансию я и полез – сам, с открытыми глазами. Хотел мир без бюрократии, без специально обученного человека на каждой ручке. Получил. Со всеми ручками разом.
А что именно было за той дверью – я и сам толком не знал. Узнал в первые дни, но дно оказалось не одно и не два, а сколько голов у того супостата с картинки. Дальше расскажу про анатомию супостата.
#devops #LLM #человек_оркестр
👍7🔥4❤1
⚡️ DevOps Digest #31 | 07.09.2026
🔥 Главное:
1. Kubernetes v1.37 перевёл rootless-режим (KubeletInUserNamespace) в бету: kubelet, CRI/OCI-рантаймы, CNI и kube-proxy теперь могут работать под непривилегированным пользователем в Linux user namespace. Это закрывает целый класс побегов из контейнера (cr8escape, дыры в runc и kubelet) без privileged: true – прямо про bare-metal и закрытые контуры.
🔗 https://kubernetes.io/blog/2026/09/04/kubernetes-v1-37-rootless-beta/
2. Вышел Gotcha 1.0 – self-hosted платформа наблюдаемости на Go (Apache-2.0): ошибки, распределённые трейсы, метрики, профили, логи, мониторинг доступности и статус-страницы в одном. Приём данных совместим с Sentry SDK и OTLP, хранение в PostgreSQL и ClickHouse, минимум 2 vCPU / 2 ГБ, интерфейс на русском. Готовая замена связке из внешних сервисов для закрытого контура.
🔗 https://www.opennet.ru/opennews/art.shtml?num=66220
3. Red Hat анонсировал Satellite 6.20 (ограниченная доступность в ноябре): переход на контейнерную поставку самого Satellite и включение постквантовой криптографии. Платформа управляет патчами и стандартами RHEL в отключённых от интернета инсталляциях – обе новинки бьют прямо в задачи закрытых контуров.
🔗 https://www.redhat.com/en/blog/red-hat-satellite-620-limited-availability-early-access-containerized-management-and-post-quantum-cryptographic-enablement
🔍 Наблюдаемость: "отправляйте меньше данных" – это не стратегия
Когда телеметрия дорожает, дефолтный совет один: семплировать сильнее, меньше хранить, резать кардинальность. Проблема в том, что вас просят снизить детализацию раньше, чем вы поняли, какая детализация вообще нужна. Ценность лога или трейса меняется в момент инцидента – то, что выглядит мусором в норме, становится единственной уликой при разборе редкого сбоя. Вывод: решайте, что выкидывать, осознанно – по режимам отказа и реальной стоимости хранения, а не по принципу "данных стало много".
https://devops.com/observabilitys-gaslighting-problem-send-less-data-isnt-a-strategy/
🛠 Команда дня:
Одномоментный снимок cgroup-ов, отсортированных по памяти – сразу видно, какой сервис или контейнер съедает RAM на узле, ещё до того как прилетит OOMKilled.
#дайджест #security #kubernetes
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное:
1. Kubernetes v1.37 перевёл rootless-режим (KubeletInUserNamespace) в бету: kubelet, CRI/OCI-рантаймы, CNI и kube-proxy теперь могут работать под непривилегированным пользователем в Linux user namespace. Это закрывает целый класс побегов из контейнера (cr8escape, дыры в runc и kubelet) без privileged: true – прямо про bare-metal и закрытые контуры.
🔗 https://kubernetes.io/blog/2026/09/04/kubernetes-v1-37-rootless-beta/
2. Вышел Gotcha 1.0 – self-hosted платформа наблюдаемости на Go (Apache-2.0): ошибки, распределённые трейсы, метрики, профили, логи, мониторинг доступности и статус-страницы в одном. Приём данных совместим с Sentry SDK и OTLP, хранение в PostgreSQL и ClickHouse, минимум 2 vCPU / 2 ГБ, интерфейс на русском. Готовая замена связке из внешних сервисов для закрытого контура.
🔗 https://www.opennet.ru/opennews/art.shtml?num=66220
3. Red Hat анонсировал Satellite 6.20 (ограниченная доступность в ноябре): переход на контейнерную поставку самого Satellite и включение постквантовой криптографии. Платформа управляет патчами и стандартами RHEL в отключённых от интернета инсталляциях – обе новинки бьют прямо в задачи закрытых контуров.
🔗 https://www.redhat.com/en/blog/red-hat-satellite-620-limited-availability-early-access-containerized-management-and-post-quantum-cryptographic-enablement
🔍 Наблюдаемость: "отправляйте меньше данных" – это не стратегия
Когда телеметрия дорожает, дефолтный совет один: семплировать сильнее, меньше хранить, резать кардинальность. Проблема в том, что вас просят снизить детализацию раньше, чем вы поняли, какая детализация вообще нужна. Ценность лога или трейса меняется в момент инцидента – то, что выглядит мусором в норме, становится единственной уликой при разборе редкого сбоя. Вывод: решайте, что выкидывать, осознанно – по режимам отказа и реальной стоимости хранения, а не по принципу "данных стало много".
https://devops.com/observabilitys-gaslighting-problem-send-less-data-isnt-a-strategy/
🛠 Команда дня:
systemd-cgtop -n1 --order=memory
Одномоментный снимок cgroup-ов, отсортированных по памяти – сразу видно, какой сервис или контейнер съедает RAM на узле, ещё до того как прилетит OOMKilled.
#дайджест #security #kubernetes
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
Kubernetes
Kubernetes v1.37: KubeletInUserNamespace (aka Rootless mode) Graduates to Beta
Kubernetes v1.37 promotes the KubeletInUserNamespace feature gate to beta. With this feature enabled, all of the node components (kubelet, CRI and OCI runtimes, CNI plugins, and kube-proxy) can run as a non-root user on the host, using a Linux user namespace.…
🔥3❤1
Записки сумасшедшего девопса. Анатомия супостата
Продолжение моих записок. Предыдущий пост.
Перед погружением в проект я запросил ответы по моему чек-листу: что есть, что будет и вообще как оно там всё до меня.
На бумаге задача звучала почти празднично: возглавить разработку на AI-агентах и этой автоматикой дорабатывать и обновлять текущий портал. Настроить конвейер, роли агентов, критерии готовности – и вперёд. Пара недель – показать метод в деле. Планы особо не раскрывали.Напомню, документации как таковой не было, только дымящийся ЯТрекер, где когда-то кипела работа по эпикам и подэпикам.
Дорабатывать. Обновлять. Текущий портал.
А портал – на Битриксе.
Битрикс. Ну, вы знаете: PHP, коробка, агенты на кроне, инфоблоки. Битрикс.
Открываю капот. И лёгким движением руки "доработать" превращается… превращается "доработать"…в "переписать с нуля" 😝 . За будничным "обновлять текущий портал" просыпается тот самый супостат с эннацтью головами. Кладу тварь на стол и считаю головы.
– Дамп базы. Прямо в гите. Кто-то из прошлых архитекторов зачем-то закоммитил дамп боевой базы в репозиторий. В гит. Навсегда в историю коммитов. Отсюда и полтора гигабайта: думаешь, что тянешь код, а тянешь дамп базы с персданными. Встречаться с автором я не стал – git log нас уже познакомил.
– База без ключей. Больше семисот таблиц – и ни одного внешнего ключа. Что с чем бьётся, следит только код: вспомнил проверить – повезло, забыл – получай кашу. И сущность лежит не строкой с колонками, а десятками строк "ключ-значение", раскиданных по общей куче. Нормальную схему соберу заново позднее в Postgres.
– Хостинг-зоопарк. Разрозненные виртуалки на дешёвом хостинге. Мой первый вопрос на любом проекте: как у вас выдаются доступы? Тут ответили – руками. Ни ключей, ни SSO. По одному ответу уже понятно, что там дальше. И светомузыка из открытых наружу портов, заходи кто хочешь на огонёк.
– Дев и прод в одной реанимации. Дев-стенд циклично уходит в ребут – забивается диск. Прод рядом, в том же состоянии, только на грани: дышит, пока не трогаешь.
– GitLab как услуга. Пара репозиториев, арендован где-то там же, тормозит так, что мерж-реквест едет минут энцать. Пайплайны красные почти все. Под замену.
– И единственное приятное – облако. На нём уже жил кусок нового функционала. Одна беда: он перевязан пуповиной с базой Битрикса и его же авторизацией. Да и прод-базу с дев зачем-то посадили на один кластер, аля сиамские близнецы. ВМ под Supabase и приложение развели по-человечески, а базы нет; ну и ладно, всё равно придётся и это переделывать. Вроде бы уже в будущем, а пуповину не перерезать – умрёт.
И вот этот зоопарк надо было аккуратно мигрировать в облако. Целиком, без простоя. По плану – полгода; по факту, как оказалось, шесть недель. Соло. Двадцать сервисов, за две сотни функций, семь сотен подфункций – и добрую часть не перенести, а переписать заново, на React Native и Supabase. Больше двадцати тысяч пользователей, оплата, юрики, физики. Всё как мы любим 😎
Главное – на входе я получил полный карт-бланш: разворачивать инфраструктуру под разработку и всё остальное с нуля, в облаке. Наивно рассчитывал обойтись парой новых серверов к уже развёрнутому – ещё не подозревая, какие приключения впереди.
Идея была навести порядок со входом сразу на двух фронтах: для внутренних тулов – единый identity-aware шлюз, аля BeyondCorp; пользовательскую регистрацию – увести с Битрикса. Но об этом уже в следующем посте.
#devops #человек_оркестр
Продолжение моих записок. Предыдущий пост.
Перед погружением в проект я запросил ответы по моему чек-листу: что есть, что будет и вообще как оно там всё до меня.
На бумаге задача звучала почти празднично: возглавить разработку на AI-агентах и этой автоматикой дорабатывать и обновлять текущий портал. Настроить конвейер, роли агентов, критерии готовности – и вперёд. Пара недель – показать метод в деле. Планы особо не раскрывали.
Дорабатывать. Обновлять. Текущий портал.
А портал – на Битриксе.
Битрикс. Ну, вы знаете: PHP, коробка, агенты на кроне, инфоблоки. Битрикс.
Открываю капот. И лёгким движением руки "доработать" превращается… превращается "доработать"…
– Дамп базы. Прямо в гите. Кто-то из прошлых архитекторов зачем-то закоммитил дамп боевой базы в репозиторий. В гит. Навсегда в историю коммитов. Отсюда и полтора гигабайта: думаешь, что тянешь код, а тянешь дамп базы с персданными. Встречаться с автором я не стал – git log нас уже познакомил.
– База без ключей. Больше семисот таблиц – и ни одного внешнего ключа. Что с чем бьётся, следит только код: вспомнил проверить – повезло, забыл – получай кашу. И сущность лежит не строкой с колонками, а десятками строк "ключ-значение", раскиданных по общей куче. Нормальную схему соберу заново позднее в Postgres.
– Хостинг-зоопарк. Разрозненные виртуалки на дешёвом хостинге. Мой первый вопрос на любом проекте: как у вас выдаются доступы? Тут ответили – руками. Ни ключей, ни SSO. По одному ответу уже понятно, что там дальше. И светомузыка из открытых наружу портов, заходи кто хочешь на огонёк.
– Дев и прод в одной реанимации. Дев-стенд циклично уходит в ребут – забивается диск. Прод рядом, в том же состоянии, только на грани: дышит, пока не трогаешь.
– GitLab как услуга. Пара репозиториев, арендован где-то там же, тормозит так, что мерж-реквест едет минут энцать. Пайплайны красные почти все. Под замену.
– И единственное приятное – облако. На нём уже жил кусок нового функционала. Одна беда: он перевязан пуповиной с базой Битрикса и его же авторизацией. Да и прод-базу с дев зачем-то посадили на один кластер, аля сиамские близнецы. ВМ под Supabase и приложение развели по-человечески, а базы нет; ну и ладно, всё равно придётся и это переделывать. Вроде бы уже в будущем, а пуповину не перерезать – умрёт.
И вот этот зоопарк надо было аккуратно мигрировать в облако. Целиком, без простоя. По плану – полгода; по факту, как оказалось, шесть недель. Соло. Двадцать сервисов, за две сотни функций, семь сотен подфункций – и добрую часть не перенести, а переписать заново, на React Native и Supabase. Больше двадцати тысяч пользователей, оплата, юрики, физики. Всё как мы любим 😎
Главное – на входе я получил полный карт-бланш: разворачивать инфраструктуру под разработку и всё остальное с нуля, в облаке. Наивно рассчитывал обойтись парой новых серверов к уже развёрнутому – ещё не подозревая, какие приключения впереди.
Идея была навести порядок со входом сразу на двух фронтах: для внутренних тулов – единый identity-aware шлюз, аля BeyondCorp; пользовательскую регистрацию – увести с Битрикса. Но об этом уже в следующем посте.
#devops #человек_оркестр
🔥7⚡1❤1👍1🤣1
⚡️ DevOps Digest #32 | 14.09.2026
🔥 Главное:
1. Kubernetes v1.37 по умолчанию включил Prometheus native histograms для метрик задержек и длительностей своих компонентов (стадия Beta). Границы бакетов больше не задаются статично и не плодят отдельный временной ряд на каждую границу le – точность по хвостам выше, а хранение и нагрузка на сбор метрик ниже. Что делать: убедиться, что ваш Prometheus умеет принимать native histograms, и включить их – меньше кардинальности при большей детализации.
🔗 https://kubernetes.io/blog/2026/09/11/kubernetes-v1-37-native-histograms-beta/
2. Полевой справочник по статусам подов в k3d/k3s, которые ловишь каждую неделю. Главная ловушка ImagePullBackOff: ноды k3d работают на containerd и изолированы от твоего Docker-демона – образ собран и лежит у Docker, но кластер его не видит (лечится k3d image import или локальным реестром k3d-registry.localhost:5000 в манифесте). Плюс CrashLoopBackOff (ключ – logs --previous), Pending/FailedScheduling и OOMKilled (137) – всё диагностируется тремя командами.
🔗 https://dorokhovich.com/blog/local-k8s-troubleshooting
3. Grafana показывает переиспользуемый приём наблюдаемости: результаты короткоживущих задач (в примере – прогоны тестов Cypress, но подход годится для любой CI-задачи) прямо в хуке превращаются в метрики Prometheus, уходят в Pushgateway, а Alloy собирает их со шлюза и шлёт в Grafana. Так видно тренды: нестабильные тесты и общее замедление, которые в логе одного прогона не разглядеть.
🔗 https://grafana.com/blog/how-to-monitor-cypress-tests-with-grafana-cloud/
4. Разбор пяти августовских сбоев GitHub: почти все инциденты – упор в ёмкость, а не баги новых фич. Рутинный деплой срезал ёмкость подов в одном дата-центре → насыщение service mesh → каскад отказов по кластерам примерно на 9 часов. Вывод для своих кластеров: держать запас по лимитам concurrency у раннеров и по лимитам балансировщиков, sidecar service mesh обязан масштабироваться под пик, а приоритет – "доступность, потом ёмкость, потом фичи".
🔗 https://devops.com/githubs-august-outages-show-growth-is-outpacing-infrastructure/
🔍 ИИ гасит инциденты – а инженеры теряют контакт с системами
Тезис из свежего SRE Weekly: чем лучше автоматика закрывает рутинные инциденты, тем меньше практики у дежурных, и в момент неоднозначной аварии, которую машина решить не может, отвечающий оказывается без насмотренности. Автор называет это накоплением долга понимания. Практический вывод: не отдавайте автоматике весь триаж молча – заставляйте её объяснять, что и почему она сделала, и держите ротацию on-call на реальных разборах, а не только на подтверждении зелёных прогонов.
🛠 Команда дня:
PSI (Pressure Stall Information, ядро 4.20+): показывает, сколько % времени задачи реально простаивали из-за нехватки CPU, диска или памяти за 10/60/300 c – честный сигнал насыщения там, где load average врёт (some = ждала часть задач, full = стояли все).
#дайджест #kubernetes #monitoring
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное:
1. Kubernetes v1.37 по умолчанию включил Prometheus native histograms для метрик задержек и длительностей своих компонентов (стадия Beta). Границы бакетов больше не задаются статично и не плодят отдельный временной ряд на каждую границу le – точность по хвостам выше, а хранение и нагрузка на сбор метрик ниже. Что делать: убедиться, что ваш Prometheus умеет принимать native histograms, и включить их – меньше кардинальности при большей детализации.
🔗 https://kubernetes.io/blog/2026/09/11/kubernetes-v1-37-native-histograms-beta/
2. Полевой справочник по статусам подов в k3d/k3s, которые ловишь каждую неделю. Главная ловушка ImagePullBackOff: ноды k3d работают на containerd и изолированы от твоего Docker-демона – образ собран и лежит у Docker, но кластер его не видит (лечится k3d image import или локальным реестром k3d-registry.localhost:5000 в манифесте). Плюс CrashLoopBackOff (ключ – logs --previous), Pending/FailedScheduling и OOMKilled (137) – всё диагностируется тремя командами.
🔗 https://dorokhovich.com/blog/local-k8s-troubleshooting
3. Grafana показывает переиспользуемый приём наблюдаемости: результаты короткоживущих задач (в примере – прогоны тестов Cypress, но подход годится для любой CI-задачи) прямо в хуке превращаются в метрики Prometheus, уходят в Pushgateway, а Alloy собирает их со шлюза и шлёт в Grafana. Так видно тренды: нестабильные тесты и общее замедление, которые в логе одного прогона не разглядеть.
🔗 https://grafana.com/blog/how-to-monitor-cypress-tests-with-grafana-cloud/
4. Разбор пяти августовских сбоев GitHub: почти все инциденты – упор в ёмкость, а не баги новых фич. Рутинный деплой срезал ёмкость подов в одном дата-центре → насыщение service mesh → каскад отказов по кластерам примерно на 9 часов. Вывод для своих кластеров: держать запас по лимитам concurrency у раннеров и по лимитам балансировщиков, sidecar service mesh обязан масштабироваться под пик, а приоритет – "доступность, потом ёмкость, потом фичи".
🔗 https://devops.com/githubs-august-outages-show-growth-is-outpacing-infrastructure/
🔍 ИИ гасит инциденты – а инженеры теряют контакт с системами
Тезис из свежего SRE Weekly: чем лучше автоматика закрывает рутинные инциденты, тем меньше практики у дежурных, и в момент неоднозначной аварии, которую машина решить не может, отвечающий оказывается без насмотренности. Автор называет это накоплением долга понимания. Практический вывод: не отдавайте автоматике весь триаж молча – заставляйте её объяснять, что и почему она сделала, и держите ротацию on-call на реальных разборах, а не только на подтверждении зелёных прогонов.
🛠 Команда дня:
head -v /proc/pressure/*
PSI (Pressure Stall Information, ядро 4.20+): показывает, сколько % времени задачи реально простаивали из-за нехватки CPU, диска или памяти за 10/60/300 c – честный сигнал насыщения там, где load average врёт (some = ждала часть задач, full = стояли все).
#дайджест #kubernetes #monitoring
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
Kubernetes
Kubernetes v1.37: Native Histograms Graduates to Beta
I'm excited to announce that native histogram support for Kubernetes metrics is graduating to Beta and is enabled by default in Kubernetes v1.37!
Native histograms (previously introduced as Alpha in Kubernetes v1.36 under KEP-5808) bring high-resolution,…
Native histograms (previously introduced as Alpha in Kubernetes v1.36 under KEP-5808) bring high-resolution,…
❤2👍1🔥1
Выражение лица, когда приходишь на проект, а там как везде 🤣
Продолжаю записки. В прошлый раз обещал показать, как наводил порядок со входом, держите пост
Разобрал, почему "просто поставь SSO" – это на самом деле два разных вопроса, почему не подошли Keycloak, Cloudflare Access и даже nginx с oauth2-proxy, и как в итоге легли Zitadel + Pomerium (оба на Go, конфиг в гите). Ну и грабельки, куда без них, redirect_uri в localhost, "No data" в Grafana из-за CSRF за прокси, серт, не выписавшийся после смены DNS.
Читать: https://devopsway.ru/posts/beyondcorp-pomerium-zitadel/
#devops #человек_оркестр
Продолжаю записки. В прошлый раз обещал показать, как наводил порядок со входом, держите пост
Разобрал, почему "просто поставь SSO" – это на самом деле два разных вопроса, почему не подошли Keycloak, Cloudflare Access и даже nginx с oauth2-proxy, и как в итоге легли Zitadel + Pomerium (оба на Go, конфиг в гите). Ну и грабельки, куда без них, redirect_uri в localhost, "No data" в Grafana из-за CSRF за прокси, серт, не выписавшийся после смены DNS.
Читать: https://devopsway.ru/posts/beyondcorp-pomerium-zitadel/
#devops #человек_оркестр
❤5👍1🔥1
Записки сумасшедшего девопса. Планы – ничто, планирование – всё
В прошлые разы я разложил супостата по органам и показал, как начал наводить порядок со входом для своих. Сейчас про то, с чего всё началось, – про план.
Есть у нас особенности национального планирования. Три кита: надо было вчера, всё и сразу, и можно без хлеба. План при этом просят не как гипотезу, а как обязательство: подпишись под полугодом, которого ты ещё в глаза не видел.
Мне дали пару дней осмотреться и один недельный спринт, а на выходе шестимесячный план. То есть сесть, как Доктор Стрэндж, уйти в транс, просмотреть четырнадцать миллионов вариантов будущего, открыть глаза и назвать тот единственный, где прод не горит. И пройти по нему канатоходцем на высоте двести метров. Без сетки – крайний-то один.
Только Камня Времени мне конечно же выдать забыли. Так что план, написанный за неделю по чужой карте – такое себе пророчество.
И пыль на него осела недели через две, потому что написан он был против чужой формулировки задачи, закопанной в головах бизнеса. На входе, как мы помним, она звучала почти невинно: собери AI-конвейер и дорабатывай им портал. А под капотом оказалась немного другой. Уйти с Битрикса целиком. Допилить мобилку на андроиде. Вырастить подразделение продактов и операторов этого самого конвейера. Обучить персонал тестировать. А, ну и выстроить процессы, про которые тут отродясь не слышали. Свежий слой чужих решений поверх старого ядра – копился он не первый год. Неделя на план, полгода на исполнение, минимум два года боли. И детальный план "дорабатывать портал" натягивался на всё это, как сова на глобус.
Сейчас, три месяца спустя, я смотрю на тот июньский план и на то, что вышло по факту. Разошлись, да, местами сильно. И тянет сказать: вот тут надо было иначе, тут не так поставить. Но это говорит послезнание – с сентябрьской картой в руках судить июньское решение проще простого. По июньским данным план был норм. И опыт – сын ошибок трудных, другого способа добыть эту карту не было. Уверенность в плане я, кстати, ещё не потерял.
Потому что понял, за что план-то на самом деле отвечает. Не за то, чтобы угадать. За то, чтобы сделать ставку явной: вот во что я верю, вот где, по-моему, рванёт первая мина, вот порядок, который не оставит людей без входа. Ближние недели – детально, как обязательство. Дальше уже вектором: необратимый выбор, сносить целиком или подменять по кусочку, лучше держать открытым до последнего момента, когда ждать станет дороже, чем решить.
А спокойно идти по канату помогает не то, что ты видишь его на двести метров вперёд, – ну нифига не видишь. Помогает сетка внизу. Моей сеткой должна была стать обратимость: стейдж, фичефлаги, откат, миграция как транзакция, которую можно отменить целиком. И должен был появиться балансир в руках – контракты и гейты: каждый шаг проверяется до того, как перенёс на него вес. Когда падать не смертельно, планировать можно смело, а не трусливо.
Эйзенхауэр спланировал высадку в Нормандии – и всё равно сказал: планы – ничто, планирование – всё. Сам план устаревает в ту секунду, когда реальность бьёт, – а бьёт она по определению не по расписанию. Остаётся то, что планирование в тебя вложило: карта местности, найденные мины и названная наконец настоящая задача.
Одна из тех мин – самая страшная, необратимая – называлась авторизация. Больше двадцати тысяч живых аккаунтов сидели на битриксовой авторизации: кто через Google (который теперь нельзя), кто через Яндекс ID, кто просто по номеру телефона. И увести их надо было так, чтобы никого не разлогинить и не потерять ни одного пароля. Как я резал эту пуповину без простоя – расскажу на следующей неделе.
#devops #человек_оркестр
В прошлые разы я разложил супостата по органам и показал, как начал наводить порядок со входом для своих. Сейчас про то, с чего всё началось, – про план.
Есть у нас особенности национального планирования. Три кита: надо было вчера, всё и сразу, и можно без хлеба. План при этом просят не как гипотезу, а как обязательство: подпишись под полугодом, которого ты ещё в глаза не видел.
Мне дали пару дней осмотреться и один недельный спринт, а на выходе шестимесячный план. То есть сесть, как Доктор Стрэндж, уйти в транс, просмотреть четырнадцать миллионов вариантов будущего, открыть глаза и назвать тот единственный, где прод не горит. И пройти по нему канатоходцем на высоте двести метров. Без сетки – крайний-то один.
Только Камня Времени мне конечно же выдать забыли. Так что план, написанный за неделю по чужой карте – такое себе пророчество.
И пыль на него осела недели через две, потому что написан он был против чужой формулировки задачи, закопанной в головах бизнеса. На входе, как мы помним, она звучала почти невинно: собери AI-конвейер и дорабатывай им портал. А под капотом оказалась немного другой. Уйти с Битрикса целиком. Допилить мобилку на андроиде. Вырастить подразделение продактов и операторов этого самого конвейера. Обучить персонал тестировать. А, ну и выстроить процессы, про которые тут отродясь не слышали. Свежий слой чужих решений поверх старого ядра – копился он не первый год. Неделя на план, полгода на исполнение, минимум два года боли. И детальный план "дорабатывать портал" натягивался на всё это, как сова на глобус.
Сейчас, три месяца спустя, я смотрю на тот июньский план и на то, что вышло по факту. Разошлись, да, местами сильно. И тянет сказать: вот тут надо было иначе, тут не так поставить. Но это говорит послезнание – с сентябрьской картой в руках судить июньское решение проще простого. По июньским данным план был норм. И опыт – сын ошибок трудных, другого способа добыть эту карту не было. Уверенность в плане я, кстати, ещё не потерял.
Потому что понял, за что план-то на самом деле отвечает. Не за то, чтобы угадать. За то, чтобы сделать ставку явной: вот во что я верю, вот где, по-моему, рванёт первая мина, вот порядок, который не оставит людей без входа. Ближние недели – детально, как обязательство. Дальше уже вектором: необратимый выбор, сносить целиком или подменять по кусочку, лучше держать открытым до последнего момента, когда ждать станет дороже, чем решить.
А спокойно идти по канату помогает не то, что ты видишь его на двести метров вперёд, – ну нифига не видишь. Помогает сетка внизу. Моей сеткой должна была стать обратимость: стейдж, фичефлаги, откат, миграция как транзакция, которую можно отменить целиком. И должен был появиться балансир в руках – контракты и гейты: каждый шаг проверяется до того, как перенёс на него вес. Когда падать не смертельно, планировать можно смело, а не трусливо.
Эйзенхауэр спланировал высадку в Нормандии – и всё равно сказал: планы – ничто, планирование – всё. Сам план устаревает в ту секунду, когда реальность бьёт, – а бьёт она по определению не по расписанию. Остаётся то, что планирование в тебя вложило: карта местности, найденные мины и названная наконец настоящая задача.
Одна из тех мин – самая страшная, необратимая – называлась авторизация. Больше двадцати тысяч живых аккаунтов сидели на битриксовой авторизации: кто через Google (который теперь нельзя), кто через Яндекс ID, кто просто по номеру телефона. И увести их надо было так, чтобы никого не разлогинить и не потерять ни одного пароля. Как я резал эту пуповину без простоя – расскажу на следующей неделе.
#devops #человек_оркестр
🔥4❤1
⚡️ DevOps Digest #33 | 21.09.2026
🔥 Главное:
1. Kubernetes 1.37 разрешает задавать noexec, nosuid, nodev прямо для bind-mount томов и режимы прав для emptyDir. Теперь запрет на запуск бинарников из записываемых томов и на удаление чужих файлов делается штатно, без костылей с initContainer – включайте на чувствительных подах уже на этой неделе.
🔗 https://kubernetes.io/blog/2026/09/16/kubernetes-v1-37-hardening-container-storage/
2. Ваш конвейер CI/CD – самая незащищённая система в инфраструктуре: он выполняет произвольный код сторонних действий с привилегированными кредами и доступом внутрь контура. В статье – чек-лист защищённого конвейера: изоляция раннеров, минимальные права токенов, запрет секретов в логах, пиннинг зависимостей.
🔗 https://devops.com/why-your-ci-cd-pipeline-is-your-most-unprotected-attack-surface/
4. Классическая боль: уязвимость починили в базовом образе, а через неделю прод всё ещё на дырявом – никто не пересобрал. Buildpacks дают единый путь сборки, где платформенная команда централизованно управляет базовыми образами, SBOM и пересборкой вместо зоопарка индивидуальных Dockerfile.
🔗 https://thenewstack.io/buildpacks-container-security-scale/
5. Cloudflare сэкономил 100 ТБ памяти, оптимизировав кэш DNS в 1.1.1.1 – на их масштабе каждый срезанный с записи байт даёт 250 ГБ по флоту. Наглядный разбор о том, как охота за размером структуры кэша окупается, когда записей миллиарды.
🔗 https://sreweekly.com/sre-weekly-issue-535/
🔍 eBPF стал стандартной инфраструктурой, а не экзотикой ядра
По данным CNCF за 2026 год, 67% команд уже гоняют в проде хотя бы один инструмент на eBPF, а Cilium де-факто стал стандартным CNI. Практический смысл: eBPF даёт наблюдаемость и сетевые политики почти без накладных расходов, потому что программы проходят проверку верификатором ядра и работают в его пространстве без модулей. Если вы всё ещё на CNI поверх iptables и ставите отдельные агенты сбора трафика – пора смотреть на Cilium/Hubble как на замену сразу обоим.
🛠 Команда дня:
Находит записываемые каталоги без флага noexec – потенциальные точки запуска чужих бинарников; закройте их noexec,nosuid.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
🔥 Главное:
1. Kubernetes 1.37 разрешает задавать noexec, nosuid, nodev прямо для bind-mount томов и режимы прав для emptyDir. Теперь запрет на запуск бинарников из записываемых томов и на удаление чужих файлов делается штатно, без костылей с initContainer – включайте на чувствительных подах уже на этой неделе.
🔗 https://kubernetes.io/blog/2026/09/16/kubernetes-v1-37-hardening-container-storage/
2. Ваш конвейер CI/CD – самая незащищённая система в инфраструктуре: он выполняет произвольный код сторонних действий с привилегированными кредами и доступом внутрь контура. В статье – чек-лист защищённого конвейера: изоляция раннеров, минимальные права токенов, запрет секретов в логах, пиннинг зависимостей.
🔗 https://devops.com/why-your-ci-cd-pipeline-is-your-most-unprotected-attack-surface/
4. Классическая боль: уязвимость починили в базовом образе, а через неделю прод всё ещё на дырявом – никто не пересобрал. Buildpacks дают единый путь сборки, где платформенная команда централизованно управляет базовыми образами, SBOM и пересборкой вместо зоопарка индивидуальных Dockerfile.
🔗 https://thenewstack.io/buildpacks-container-security-scale/
5. Cloudflare сэкономил 100 ТБ памяти, оптимизировав кэш DNS в 1.1.1.1 – на их масштабе каждый срезанный с записи байт даёт 250 ГБ по флоту. Наглядный разбор о том, как охота за размером структуры кэша окупается, когда записей миллиарды.
🔗 https://sreweekly.com/sre-weekly-issue-535/
🔍 eBPF стал стандартной инфраструктурой, а не экзотикой ядра
По данным CNCF за 2026 год, 67% команд уже гоняют в проде хотя бы один инструмент на eBPF, а Cilium де-факто стал стандартным CNI. Практический смысл: eBPF даёт наблюдаемость и сетевые политики почти без накладных расходов, потому что программы проходят проверку верификатором ядра и работают в его пространстве без модулей. Если вы всё ещё на CNI поверх iptables и ставите отдельные агенты сбора трафика – пора смотреть на Cilium/Hubble как на замену сразу обоим.
🛠 Команда дня:
findmnt -rno TARGET,OPTIONS | grep -vE 'noexec' | grep -E '/tmp|/dev/shm|/var/tmp'
Находит записываемые каталоги без флага noexec – потенциальные точки запуска чужих бинарников; закройте их noexec,nosuid.
#дайджест #kubernetes #security
💬 Переслал коллегам? Пусть подпишутся: @DevITWay
Kubernetes
Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions
Kubernetes v1.37 brings important storage security features: emptyDir permission modes and bind mount options. They help application programmers and security professionals implement rigorous security policies, for example, prohibiting deletion of files across…
🔥2❤1
Записки сумасшедшего девопса. Двадцать тысяч чужих паролей
Не у каждого есть опыт переноса базы с живыми пользователями. Тем более между разными типами баз. И между разными типами криптографии.
Bitrix, MySQL, вся авторизация внутри. Уводим на новый стек: PostgreSQL, логин на GoTrue – движок авторизации Supabase. Двадцать с лишним тысяч живых аккаунтов. Условие одно: люди входят как раньше.
Полез смотреть, кто эти двадцать тысяч. Картина была пёстрая. Половина заходит вообще без пароля, кнопкой: тысяч семь через Яндекс, тысяч пять через Google. Остальные – телефон плюс пароль.
Пароль с телефоном переедет тихо. Казалось бы. С кнопками сложнее. Яндекс поднял через Zitadel – кнопка живёт, человек входит как раньше. Google убираем совсем. Кто заходил только им – на почту с паролем, сброс по ссылке. А у кого и почты нет, только соцвход, – звонить некуда. Несколько сотен таких. Выцепили заранее, пока Bitrix живой, вытянули почту руками. Иначе на переключении они бы просто исчезли.
Теперь пароли. Скопировал хэши из MySQL в Postgres. Думал, вечер работы.
Bitrix держит их в $6$. Это sha512crypt, тот самый crypt из /etc/shadow. GoTrue проверяет bcrypt, argon2, firebase scrypt. Всё. Что не из этих трёх – молча уходит в bcrypt-ветку и не сходится. Родные хэши не подходят вообще. Ни один. Все, кто входит паролем, – мимо.
pgcrypto? Не знает $6$, только bcrypt да остальную труху. И тупик тут по другой причине: GoTrue сверяет пароль не в базе, а у себя, в Go. В исходнике форматы прошиты константами – sha512crypt там нет. Плагин к Postgres ни при чём.
Ставлю перед GoTrue прослойку: знает старый формат, сама сверяет пароль со старым хэшем, на первом успешном входе перехеширует в bcrypt. Дальше ведёт сам GoTrue. Старый формат вытекает по мере входов, до нуля. Кому пароль не вернуть – ссылка на почту.
Написал, прогнал тесты, зелено. Утром вешаю заглушку с обратным отсчётом – замораживаю записи. Чтобы за время переключения базы не разъехались и не пришлось потом разгребать дубли. Режу ленточку: меняю домены местами, юзеры идут через Zitadel и GoTrue.
Убираю заглушку, смотрю в логи. Пошли входы. Работает? Ну работает же?!
А потом – то тут, то там – закапали входы с ошибками. Из тех, что указывают на самое неприятное: часть людей не пускает в их собственные аккаунты. Прослойка на моке считала $6$ верно, на живых – мимо: готовая библиотека sha512crypt врала на реальных хэшах, верно считал только системный crypt. Кого-то движок вообще роняет в 500 ещё до пароля – миграция оставила пустые технические поля, а он читает их как непустые строки. Сверху публичные страницы местами отдают permission denied: рестор снёс табличные гранты.
Пытался чинить на ходу, прямо на проде. Ну, такое. Каждая правка вслепую, под капающими юзерами.
План Б: откат на старые настройки. Флип DNS назад, Bitrix живой, ловит всех. Выдохнуть. Заглушка тут и оправдалась – запись была заморожена, базы не разъехались, дедупликации ноль. Никто ничего не потерял, кроме моего вечера.
Сутки пересматриваю алгоритм. Прослойку переписываю на системный crypt. Добиваю пустые поля. Восстанавливаю гранты по эталону стенда. Второй заход – взлетело!
Как устроена прослойка и весь список грабель – отдельно, может быть, опишу с кодом.
Пишите в комментах, у кого такое было приключение?
#devops #человек_оркестр
Не у каждого есть опыт переноса базы с живыми пользователями. Тем более между разными типами баз. И между разными типами криптографии.
Bitrix, MySQL, вся авторизация внутри. Уводим на новый стек: PostgreSQL, логин на GoTrue – движок авторизации Supabase. Двадцать с лишним тысяч живых аккаунтов. Условие одно: люди входят как раньше.
Полез смотреть, кто эти двадцать тысяч. Картина была пёстрая. Половина заходит вообще без пароля, кнопкой: тысяч семь через Яндекс, тысяч пять через Google. Остальные – телефон плюс пароль.
Пароль с телефоном переедет тихо. Казалось бы. С кнопками сложнее. Яндекс поднял через Zitadel – кнопка живёт, человек входит как раньше. Google убираем совсем. Кто заходил только им – на почту с паролем, сброс по ссылке. А у кого и почты нет, только соцвход, – звонить некуда. Несколько сотен таких. Выцепили заранее, пока Bitrix живой, вытянули почту руками. Иначе на переключении они бы просто исчезли.
Теперь пароли. Скопировал хэши из MySQL в Postgres. Думал, вечер работы.
Bitrix держит их в $6$. Это sha512crypt, тот самый crypt из /etc/shadow. GoTrue проверяет bcrypt, argon2, firebase scrypt. Всё. Что не из этих трёх – молча уходит в bcrypt-ветку и не сходится. Родные хэши не подходят вообще. Ни один. Все, кто входит паролем, – мимо.
pgcrypto? Не знает $6$, только bcrypt да остальную труху. И тупик тут по другой причине: GoTrue сверяет пароль не в базе, а у себя, в Go. В исходнике форматы прошиты константами – sha512crypt там нет. Плагин к Postgres ни при чём.
Ставлю перед GoTrue прослойку: знает старый формат, сама сверяет пароль со старым хэшем, на первом успешном входе перехеширует в bcrypt. Дальше ведёт сам GoTrue. Старый формат вытекает по мере входов, до нуля. Кому пароль не вернуть – ссылка на почту.
Написал, прогнал тесты, зелено. Утром вешаю заглушку с обратным отсчётом – замораживаю записи. Чтобы за время переключения базы не разъехались и не пришлось потом разгребать дубли. Режу ленточку: меняю домены местами, юзеры идут через Zitadel и GoTrue.
Убираю заглушку, смотрю в логи. Пошли входы. Работает? Ну работает же?!
А потом – то тут, то там – закапали входы с ошибками. Из тех, что указывают на самое неприятное: часть людей не пускает в их собственные аккаунты. Прослойка на моке считала $6$ верно, на живых – мимо: готовая библиотека sha512crypt врала на реальных хэшах, верно считал только системный crypt. Кого-то движок вообще роняет в 500 ещё до пароля – миграция оставила пустые технические поля, а он читает их как непустые строки. Сверху публичные страницы местами отдают permission denied: рестор снёс табличные гранты.
Пытался чинить на ходу, прямо на проде. Ну, такое. Каждая правка вслепую, под капающими юзерами.
План Б: откат на старые настройки. Флип DNS назад, Bitrix живой, ловит всех. Выдохнуть. Заглушка тут и оправдалась – запись была заморожена, базы не разъехались, дедупликации ноль. Никто ничего не потерял, кроме моего вечера.
Сутки пересматриваю алгоритм. Прослойку переписываю на системный crypt. Добиваю пустые поля. Восстанавливаю гранты по эталону стенда. Второй заход – взлетело!
Как устроена прослойка и весь список грабель – отдельно, может быть, опишу с кодом.
Пишите в комментах, у кого такое было приключение?
#devops #человек_оркестр
🔥6❤1
⚡️ DevOps Digest #34 | 28.09.2026
🔥 Главное:
1. Сертификаты истекают и при установленном cert-manager. Он продлевает сертификат на 2/3 срока, поэтому 90-дневный сертификат Let's Encrypt попадает в окно продления за 30 дней до истечения, и весь этот месяц продление может падать молча. Автор разбирает пять классов сбоев и собирает проверку из метрик cert-manager, разбора всех Secret типа kubernetes.io/tls (включая те, которыми cert-manager не управляет) и сверки с сертификатом, который отдаёт Ingress. ИИ-обвязка в статье необязательна: детерминированную часть можно забрать отдельно.
🔗 https://dev.to/devtocash/build-a-tls-certificate-expiry-agent-catch-cert-manager-renewal-failures-unmanaged-secrets-and-1ifd
2. В Kubernetes 1.37 функция PersistentVolumeClaimUnusedSinceTime перешла в бету и включена по умолчанию. Контроллер защиты PVC теперь ставит на каждый PVC условие Unused, которое показывает, монтирует ли его хоть один запущенный под. Сводить поды и PVC самописными скриптами больше не нужно: после обновления достаточно выбрать PVC с Unused=True и по времени перехода условия решить, какие забытые тома чистить.
🔗 https://kubernetes.io/blog/2026/09/21/kubernetes-v1-37-pvc-last-used-time/
3. Coroot – открытая платформа наблюдаемости с непрерывным профилированием без правки кода. eBPF снимает CPU-профили всех процессов на ноде, для Go и Java добавляются память и блокировки, а флеймграф показывает нагрузку вплоть до строки кода. В статье – установка Community Edition через coroot-operator и четыре намеренно сломанных приложения на Node.js, Python, Go и Java: можно повторить у себя и посмотреть, что Coroot найдёт.
🔗 https://habr.com/ru/articles/1087316/
4. Вышел M-Commander 6.1.0 – форк Midnight Commander с панельными плагинами. В панелях открываются контейнеры Docker, ресурсы Kubernetes, Git-репозитории, SFTP, S3 и SQLite, а subshell заменён встроенным PTY-терминалом. Пакеты есть для Debian 13, Ubuntu 24.04/26.04 и Fedora 44, так что его можно поставить на бастион и ходить по кластеру привычными F-клавишами.
🔗 https://www.opennet.ru/opennews/art.shtml?num=66348
🔍 «Установлено» не значит «работает»
Метрики cert-manager показывают, что происходит внутри кластера: заявка создана, Secret обновлён. Клиенту важно другое – какой сертификат он получает на порту 443. Между этими точками стоят Ingress-контроллер, балансировщик и CDN, и на любом из них может остаться старый сертификат. Минимум на эту неделю – проба blackbox_exporter по каждому хосту Ingress с алертом на probe_ssl_earliest_cert_expiry. Как сверить руками – в команде дня.
🛠 Команда дня:
Сравнивает сертификат на порту 443 с тем, что лежит в Secret. Если серийные номера совпадают, Ingress отдаёт содержимое Secret, и остаётся посмотреть на дату истечения. Если различаются, cert-manager продлил сертификат, но до клиентов он не дошёл. Обычно причин три:
- Ingress-контроллер не перечитал Secret;
- в Ingress указано другое имя Secret или неверный namespace;
- TLS завершается раньше, на балансировщике или CDN, и там свой сертификат.
#дайджест #kubernetes #monitoring
🔥 Главное:
1. Сертификаты истекают и при установленном cert-manager. Он продлевает сертификат на 2/3 срока, поэтому 90-дневный сертификат Let's Encrypt попадает в окно продления за 30 дней до истечения, и весь этот месяц продление может падать молча. Автор разбирает пять классов сбоев и собирает проверку из метрик cert-manager, разбора всех Secret типа kubernetes.io/tls (включая те, которыми cert-manager не управляет) и сверки с сертификатом, который отдаёт Ingress. ИИ-обвязка в статье необязательна: детерминированную часть можно забрать отдельно.
🔗 https://dev.to/devtocash/build-a-tls-certificate-expiry-agent-catch-cert-manager-renewal-failures-unmanaged-secrets-and-1ifd
2. В Kubernetes 1.37 функция PersistentVolumeClaimUnusedSinceTime перешла в бету и включена по умолчанию. Контроллер защиты PVC теперь ставит на каждый PVC условие Unused, которое показывает, монтирует ли его хоть один запущенный под. Сводить поды и PVC самописными скриптами больше не нужно: после обновления достаточно выбрать PVC с Unused=True и по времени перехода условия решить, какие забытые тома чистить.
🔗 https://kubernetes.io/blog/2026/09/21/kubernetes-v1-37-pvc-last-used-time/
3. Coroot – открытая платформа наблюдаемости с непрерывным профилированием без правки кода. eBPF снимает CPU-профили всех процессов на ноде, для Go и Java добавляются память и блокировки, а флеймграф показывает нагрузку вплоть до строки кода. В статье – установка Community Edition через coroot-operator и четыре намеренно сломанных приложения на Node.js, Python, Go и Java: можно повторить у себя и посмотреть, что Coroot найдёт.
🔗 https://habr.com/ru/articles/1087316/
4. Вышел M-Commander 6.1.0 – форк Midnight Commander с панельными плагинами. В панелях открываются контейнеры Docker, ресурсы Kubernetes, Git-репозитории, SFTP, S3 и SQLite, а subshell заменён встроенным PTY-терминалом. Пакеты есть для Debian 13, Ubuntu 24.04/26.04 и Fedora 44, так что его можно поставить на бастион и ходить по кластеру привычными F-клавишами.
🔗 https://www.opennet.ru/opennews/art.shtml?num=66348
🔍 «Установлено» не значит «работает»
Метрики cert-manager показывают, что происходит внутри кластера: заявка создана, Secret обновлён. Клиенту важно другое – какой сертификат он получает на порту 443. Между этими точками стоят Ingress-контроллер, балансировщик и CDN, и на любом из них может остаться старый сертификат. Минимум на эту неделю – проба blackbox_exporter по каждому хосту Ingress с алертом на probe_ssl_earliest_cert_expiry. Как сверить руками – в команде дня.
🛠 Команда дня:
H=app.example.com
echo | openssl s_client -connect $H:443 -servername $H 2>/dev/null | openssl x509 -noout -serial -enddate
kubectl get secret app-tls -n prod -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -serial -enddate
Сравнивает сертификат на порту 443 с тем, что лежит в Secret. Если серийные номера совпадают, Ingress отдаёт содержимое Secret, и остаётся посмотреть на дату истечения. Если различаются, cert-manager продлил сертификат, но до клиентов он не дошёл. Обычно причин три:
- Ingress-контроллер не перечитал Secret;
- в Ingress указано другое имя Secret или неверный namespace;
- TLS завершается раньше, на балансировщике или CDN, и там свой сертификат.
#дайджест #kubernetes #monitoring
🔥4❤1
Записки сумасшедшего девопса. Пара новых серверов
В Анатомии супостата проскочило наивное: обойдусь парой новых серверов к уже развёрнутому. Вот во что эта пара выросла.
На входе всё собиралось на арендованном GitLab на reg ru. Почти все пайплайны на основной ветке красные, а изменение вливалось в среднем через шесть минут после открытия – поверх красного и без ревью. Фронт уезжал на прод rsync'ом рабочей папки раннера, зависимости докачивались прямо на проде в момент деплоя. В вики предыдущая команда написала первой строкой "работаем по Trunk Based Development", то есть мелкими изменениями в одну основную ветку. Ниже был описан GitFlow: долгие ветки и релизы пачками через релиз-менеджера, а в git – сотня веток и основная, мёртвая больше двух месяцев.
Свой контур начинался по принципу "не до жиру, быть бы живу". Агенты писали код, и собирать его нужно было уже вчера. Поэтому самое простое: свой GitLab в облаке и раннер рядом. Даже это завелось не сразу: раннер ходил к своему GitLab через публичный адрес, и пайплайны висели, пока не докрутил внутреннюю DNS-зону.
Простая схема прожила ровно до того момента, как агенты пошли параллельно. В начале июля было ещё под девяносто пайплайнов в неделю, к концу месяца уже за пятьсот. Однажды один мерж сломал сборку всем сразу: она гонялась уже после слияния. Назавтра слабый раннер захлебнулся: задач навалилось в восемь раз больше, чем он тянет, нагрузка в потолок, деплой встал. А соседний, вдвое мощнее, холера, в это время простаивал. Железа хватало, плохо раскладывалась работа.
Дальше шаг за шагом. Лёгкие проверки отдельно от тяжёлых сборок. Андроид на своей машине, потому что он тупо кладёт хост вместе со всем остальным. Общий кэш в S3 вместо холодного на каждом раннере. Стадии, которые зря ждали друг друга, развязаны, и путь до деплоя сократился с двадцати пяти минут до двенадцати. Сборка теперь идёт до слияния, а в main изменения попадают через поезд слияний (merge train): встают в очередь, и каждое проверяется вместе с теми, что едут перед ним. Так ловятся два изменения, зелёные по отдельности и красные вместе.
С экономией так же. Простое решение – гасить стенды кроном на ночь. Первая же ночь показала, что крон в убунте не понимает, в каком часовом поясе ему велели жить, и живёт по поясу сервера. А сервер жил по Нью-Йорку. Через неделю парковщик погасил заодно и сам GitLab, и мониторинг. Сейчас машины под сборку просыпаются, когда в очереди есть задачи, и засыпают после пятнадцати минут тишины. То, на чём стоит всё остальное, не спит никогда: однажды припарковали зеркало NORA, и краснело всё подряд, хотя код был ни при чём.
Отдельная история – доверие к индикаторам. Строгий линтер числился зелёным и при этом ни разу не отработал: падал на кривых флагах раньше, чем доходил до кода, а allow_failure в настройках разрешал ему падать, не краснея. GitLab показывал раннер online, хотя виртуалка под ним была выключена. Проверка, которая не умеет покраснеть, ничего не проверяет, и смотреть приходится в источник. Лампочке верить нельзя.
Сейчас всё это вышло на плато. Сто с небольшим влитых изменений в неделю, поезд зелёный почти всегда, ответ пайплайна – минут за семь. На пике перед переключением было в разы больше, но то был марафон, долго в таком режиме не живут.
И про TBD. Изменение и сейчас живёт меньше часа от открытия до слияния. Только вливает его поезд и только зелёным. За три месяца так прошло под тысячу восемьсот изменений в одну живую основную ветку. Та самая первая строка из вики, только теперь её видно в git.
Расти есть куда: чтобы GitLab сам не давал влить мимо поезда, а зеркало (NORA), на котором держится весь CI, было не в единственном экземпляре.
Каждое простое решение было правильным в свой день – без него не случилось бы ни одной сборки. И каждое становилось легаси, как только менялась нагрузка. Правильное получилось из простого слоями, по одному на каждую боль.
Пара новых серверов. Одних под сборку теперь пять, и большую часть суток они спят.
Почему база, функции и фронт катятся по отдельности – в следующий раз.
#devops #человек_оркестр
В Анатомии супостата проскочило наивное: обойдусь парой новых серверов к уже развёрнутому. Вот во что эта пара выросла.
На входе всё собиралось на арендованном GitLab на reg ru. Почти все пайплайны на основной ветке красные, а изменение вливалось в среднем через шесть минут после открытия – поверх красного и без ревью. Фронт уезжал на прод rsync'ом рабочей папки раннера, зависимости докачивались прямо на проде в момент деплоя. В вики предыдущая команда написала первой строкой "работаем по Trunk Based Development", то есть мелкими изменениями в одну основную ветку. Ниже был описан GitFlow: долгие ветки и релизы пачками через релиз-менеджера, а в git – сотня веток и основная, мёртвая больше двух месяцев.
Свой контур начинался по принципу "не до жиру, быть бы живу". Агенты писали код, и собирать его нужно было уже вчера. Поэтому самое простое: свой GitLab в облаке и раннер рядом. Даже это завелось не сразу: раннер ходил к своему GitLab через публичный адрес, и пайплайны висели, пока не докрутил внутреннюю DNS-зону.
Простая схема прожила ровно до того момента, как агенты пошли параллельно. В начале июля было ещё под девяносто пайплайнов в неделю, к концу месяца уже за пятьсот. Однажды один мерж сломал сборку всем сразу: она гонялась уже после слияния. Назавтра слабый раннер захлебнулся: задач навалилось в восемь раз больше, чем он тянет, нагрузка в потолок, деплой встал. А соседний, вдвое мощнее, холера, в это время простаивал. Железа хватало, плохо раскладывалась работа.
Дальше шаг за шагом. Лёгкие проверки отдельно от тяжёлых сборок. Андроид на своей машине, потому что он тупо кладёт хост вместе со всем остальным. Общий кэш в S3 вместо холодного на каждом раннере. Стадии, которые зря ждали друг друга, развязаны, и путь до деплоя сократился с двадцати пяти минут до двенадцати. Сборка теперь идёт до слияния, а в main изменения попадают через поезд слияний (merge train): встают в очередь, и каждое проверяется вместе с теми, что едут перед ним. Так ловятся два изменения, зелёные по отдельности и красные вместе.
С экономией так же. Простое решение – гасить стенды кроном на ночь. Первая же ночь показала, что крон в убунте не понимает, в каком часовом поясе ему велели жить, и живёт по поясу сервера. А сервер жил по Нью-Йорку. Через неделю парковщик погасил заодно и сам GitLab, и мониторинг. Сейчас машины под сборку просыпаются, когда в очереди есть задачи, и засыпают после пятнадцати минут тишины. То, на чём стоит всё остальное, не спит никогда: однажды припарковали зеркало NORA, и краснело всё подряд, хотя код был ни при чём.
Отдельная история – доверие к индикаторам. Строгий линтер числился зелёным и при этом ни разу не отработал: падал на кривых флагах раньше, чем доходил до кода, а allow_failure в настройках разрешал ему падать, не краснея. GitLab показывал раннер online, хотя виртуалка под ним была выключена. Проверка, которая не умеет покраснеть, ничего не проверяет, и смотреть приходится в источник. Лампочке верить нельзя.
Сейчас всё это вышло на плато. Сто с небольшим влитых изменений в неделю, поезд зелёный почти всегда, ответ пайплайна – минут за семь. На пике перед переключением было в разы больше, но то был марафон, долго в таком режиме не живут.
И про TBD. Изменение и сейчас живёт меньше часа от открытия до слияния. Только вливает его поезд и только зелёным. За три месяца так прошло под тысячу восемьсот изменений в одну живую основную ветку. Та самая первая строка из вики, только теперь её видно в git.
Расти есть куда: чтобы GitLab сам не давал влить мимо поезда, а зеркало (NORA), на котором держится весь CI, было не в единственном экземпляре.
Каждое простое решение было правильным в свой день – без него не случилось бы ни одной сборки. И каждое становилось легаси, как только менялась нагрузка. Правильное получилось из простого слоями, по одному на каждую боль.
Пара новых серверов. Одних под сборку теперь пять, и большую часть суток они спят.
Почему база, функции и фронт катятся по отдельности – в следующий раз.
#devops #человек_оркестр
👍4🔥2❤1
⚡️ DevOps Digest #35 | 05.10.2026
🔥 Главное за прошедшую неделю:
1. OPA Gatekeeper в продакшене: 18 месяцев, 47 политик, ни одного обхода. Больше всего нарушений ловят четыре правила, и первые два – запрет
🔗 https://dev.to/scsoi/opa-gatekeeper-in-production-50-policies-that-caught-real-misconfigurations-4d0p
2. Crossplane CLI v2.3 добавил понятие Project – единую структуру каталогов для платформенного API. Команды CLI создают заготовку проекта, генерируют код, тестируют его и запускают локально. Платформа на Crossplane теперь собирается и тестируется как обычное ПО, а не как набор YAML-файлов. Если у вас самописная обвязка для сборки Configuration-пакетов, пора сравнить её со штатной.
🔗 https://blog.crossplane.io/introducing-the-new-crossplane-cli-developer-experience/
3. Git 2.56:
🔗 https://about.gitlab.com/blog/whats-new-in-git-2-56-0/
4. SRE Weekly #537 собрал два сильных разбора. Cloudflare сэкономил ещё 100 ТБ оперативной памяти за счёт математики и Rust и показал, как поменять схему хеширования в распределённом кеше, не обнулив его. Netflix рассказал об автоматическом подборе ресурсов для контейнеров с ограничителями и откатом при ошибке. Оба приёма переносятся на ваш кластер: менять схему кеша постепенно, а лимиты подбирать автоматически, но с запасом и защитой.
🔗 https://sreweekly.com/sre-weekly-issue-537/
5. У Anthropic за полгода число CI-задач выросло в 25 раз, у Linear тестовый набор почти вчетверо – агенты пишут код быстрее, чем конвейер успевает его проверить. Anthropic начал запускать только те тесты, которые может затронуть изменение. Автор считает, что ускорять сам конвейер – решение не на том уровне. Если число MR от агентов у вас растёт, начните с выборочного запуска тестов, прежде чем докупать раннеры.
🔗 https://thenewstack.io/ci-bottleneck-agent-verification/
🔍 Git 3.0: готовиться пора уже сейчас
SHA-256 и reftable уже есть в текущих версиях Git, но поддержка в библиотеках, форжах и CI-скриптах пока неравномерная. Проверьте свой контур: на какой версии ваш GitLab, какие библиотеки (libgit2, go-git, JGit) используют пайплайны, и где в скриптах регулярные выражения рассчитаны ровно на 40-символьный хеш. Заведите тестовый репозиторий с
🛠 Команда дня:
Индексирует только файлы, где был конфликт слияния, и отказывается это делать, если в них остались маркеры
#дайджест #kubernetes #cicd
🔥 Главное за прошедшую неделю:
1. OPA Gatekeeper в продакшене: 18 месяцев, 47 политик, ни одного обхода. Больше всего нарушений ловят четыре правила, и первые два – запрет
privileged: true и образы только из разрешённого реестра. Автор приводит готовые ConstraintTemplate на Rego. Режим "запрещено всё, что не разрешено" с исключениями только для kube-system и gatekeeper-system – хорошая отправная точка для своего кластера.🔗 https://dev.to/scsoi/opa-gatekeeper-in-production-50-policies-that-caught-real-misconfigurations-4d0p
2. Crossplane CLI v2.3 добавил понятие Project – единую структуру каталогов для платформенного API. Команды CLI создают заготовку проекта, генерируют код, тестируют его и запускают локально. Платформа на Crossplane теперь собирается и тестируется как обычное ПО, а не как набор YAML-файлов. Если у вас самописная обвязка для сборки Configuration-пакетов, пора сравнить её со штатной.
🔗 https://blog.crossplane.io/introducing-the-new-crossplane-cli-developer-experience/
3. Git 2.56:
git branch научился удалять уже слитые ветки, git history получил команду drop, а через git refs теперь можно изменять ссылки. Главное в выпуске – определился состав Git 3.0: SHA-256 станет форматом хешей по умолчанию, reftable – хранилищем ссылок, а Rust – обязательной зависимостью.🔗 https://about.gitlab.com/blog/whats-new-in-git-2-56-0/
4. SRE Weekly #537 собрал два сильных разбора. Cloudflare сэкономил ещё 100 ТБ оперативной памяти за счёт математики и Rust и показал, как поменять схему хеширования в распределённом кеше, не обнулив его. Netflix рассказал об автоматическом подборе ресурсов для контейнеров с ограничителями и откатом при ошибке. Оба приёма переносятся на ваш кластер: менять схему кеша постепенно, а лимиты подбирать автоматически, но с запасом и защитой.
🔗 https://sreweekly.com/sre-weekly-issue-537/
5. У Anthropic за полгода число CI-задач выросло в 25 раз, у Linear тестовый набор почти вчетверо – агенты пишут код быстрее, чем конвейер успевает его проверить. Anthropic начал запускать только те тесты, которые может затронуть изменение. Автор считает, что ускорять сам конвейер – решение не на том уровне. Если число MR от агентов у вас растёт, начните с выборочного запуска тестов, прежде чем докупать раннеры.
🔗 https://thenewstack.io/ci-bottleneck-agent-verification/
🔍 Git 3.0: готовиться пора уже сейчас
SHA-256 и reftable уже есть в текущих версиях Git, но поддержка в библиотеках, форжах и CI-скриптах пока неравномерная. Проверьте свой контур: на какой версии ваш GitLab, какие библиотеки (libgit2, go-git, JGit) используют пайплайны, и где в скриптах регулярные выражения рассчитаны ровно на 40-символьный хеш. Заведите тестовый репозиторий с
--object-format=sha256, прогоните через него свой CI и узнайте, что сломается, до того как это случится в продакшене.🛠 Команда дня:
git add --resolved
Индексирует только файлы, где был конфликт слияния, и отказывается это делать, если в них остались маркеры
<<<<<<< (нужен Git 2.56+).#дайджест #kubernetes #cicd
DEV Community
OPA Gatekeeper in Production: 50 Policies That Caught Real Misconfigurations
OPA Gatekeeper in Production: 18 Months, 47 Policies, Zero Bypass Incidents We adopted OPA...
🔥4❤1
Записки сумасшедшего девопса. База, функции, фронт
Сколько копий одного и того же конфига лежит у вас в репозитории? В доставшемся в наследство их было три, и каждая выглядела главной. Человека это раздражает, а агент уверенно берёт первую попавшуюся.
Почему база, серверные функции (небольшие куски бэкенда рядом с базой) и фронт теперь катятся по отдельности. Цель простая: выкатывать чаще, без простоя и с меньшим числом ошибок.
Сначала в одной монорепе жило всё: приложение, миграции, полсотни функций, а заодно конфиг nginx, docker-compose, скрипты деплоя, перенос данных со старого сайта и публикация Android-сборки. Пока изменений мало, это удобно. Когда их около сотни в неделю, выясняется, что у всего этого разный ритм и разная цена ошибки. Фронт откатывается за минуту, а схему базы так уже не вернёшь.
Те самые три копии – конфиг nginx: шаблон, собранный файл и запасной вариант прямо внутри скрипта деплоя. Копии разъехались, и в августе это дало ошибку 502 на части страниц и пропавшие на проде заголовки. В конце августа инфраструктура уехала в свой репозиторий и стала кодом, в сентябре следом разъехались база и функции, у каждого свой путь до прода.
После распила в приложении остался старый каталог миграций. С виду настоящий, но уже не обновлялся и отстал на десяток миграций. Агент находил его первым и отвечал по нему, а новая миграция, положенная туда, не применилась бы никогда. Для автоматики и модели неоднозначность опаснее явной ошибки, потому что всё выглядит рабочим. Сейчас часто пишут, что агенту удобнее в монорепе, там он видит весь код, но и устаревшие копии тоже.
Отсюда главное наблюдение про разработку с агентами: если нужны и скорость, и качество, гигиеной приходится заниматься каждый день. Агенты пишут быстро и много, и любую неоднозначность они размножат. Поэтому нужны ограждения (guardrails): проверки, которые краснеют, когда что-то пошло не туда, и заметки для агентов, сверенные с живым кодом. Чистота и простота работают так же: если у конфига один источник, а у выкатки один путь, агенту не из чего выбрать неправильное.
Порядок выкатки всегда один: база, функции, фронт. Пока новый фронт не доехал, на проде крутится старый, и он обязан работать на новой схеме. Только так выкатка идёт без простоя: колонки не удаляются и не переименовываются сразу, таблица не встаёт под долгую блокировку, это ловит линтер ещё до слияния. На каждом окружении одно и то же: прогон вхолостую, применение, сверка с эталоном. Функции и фронт собираются один раз на коммит, и на прод уезжает ровно то, что проверили на деве. В каждую сборку вшиты коммит и дата, и в прогонах функционального и нефункционального тестирования (ФТ и НФТ) сразу указано, какая сборка проверялась. Вместе с этим внедряется культура тестирования и контроля качества, о ней в следующий раз.
История про незаметную ошибку. Цены на товары сайт держит в отдельной таблице-кэше. Таблицу добавили миграцией ещё в мае, и с тех пор бэкенд пытался в неё писать, получал отказ и шёл дальше: кэш необязательный, сайт работает и без него. Нашлось это только в сентябре, при разборе логов.
Причина в RLS (Row-Level Security), правилах прямо в базе: кто какие строки может читать и писать. Миграция включила RLS, а правил не завела, и доступ закрылся для всех. Автор рассчитывал на служебную роль Supabase, которая обычно ходит мимо правил. Но здесь Supabase стоит на управляемом Postgres облака, роли там заводит облако, и такого права у служебной роли нет ни на одном окружении.
Починилось одной миграцией: явное правило для служебной роли на этой и ещё двух внутренних таблицах. Выключить RLS было бы проще, но нельзя: у публичных ролей бывают лишние права на таблицы, и RLS для них последний барьер. Через пару дней кэш заполнился. Такой отказ должен попадать в мониторинг, даже если часть необязательная.
По отдельности каждый шаг медленнее, чем руками. В сумме выходит быстрее, потому что сайт работает без остановки и по сборке всегда видно, что именно уехало.
А у вас база и фронт едут одним релизом или порознь?
#devops #человек_оркестр
Сколько копий одного и того же конфига лежит у вас в репозитории? В доставшемся в наследство их было три, и каждая выглядела главной. Человека это раздражает, а агент уверенно берёт первую попавшуюся.
Почему база, серверные функции (небольшие куски бэкенда рядом с базой) и фронт теперь катятся по отдельности. Цель простая: выкатывать чаще, без простоя и с меньшим числом ошибок.
Сначала в одной монорепе жило всё: приложение, миграции, полсотни функций, а заодно конфиг nginx, docker-compose, скрипты деплоя, перенос данных со старого сайта и публикация Android-сборки. Пока изменений мало, это удобно. Когда их около сотни в неделю, выясняется, что у всего этого разный ритм и разная цена ошибки. Фронт откатывается за минуту, а схему базы так уже не вернёшь.
Те самые три копии – конфиг nginx: шаблон, собранный файл и запасной вариант прямо внутри скрипта деплоя. Копии разъехались, и в августе это дало ошибку 502 на части страниц и пропавшие на проде заголовки. В конце августа инфраструктура уехала в свой репозиторий и стала кодом, в сентябре следом разъехались база и функции, у каждого свой путь до прода.
После распила в приложении остался старый каталог миграций. С виду настоящий, но уже не обновлялся и отстал на десяток миграций. Агент находил его первым и отвечал по нему, а новая миграция, положенная туда, не применилась бы никогда. Для автоматики и модели неоднозначность опаснее явной ошибки, потому что всё выглядит рабочим. Сейчас часто пишут, что агенту удобнее в монорепе, там он видит весь код, но и устаревшие копии тоже.
Отсюда главное наблюдение про разработку с агентами: если нужны и скорость, и качество, гигиеной приходится заниматься каждый день. Агенты пишут быстро и много, и любую неоднозначность они размножат. Поэтому нужны ограждения (guardrails): проверки, которые краснеют, когда что-то пошло не туда, и заметки для агентов, сверенные с живым кодом. Чистота и простота работают так же: если у конфига один источник, а у выкатки один путь, агенту не из чего выбрать неправильное.
Порядок выкатки всегда один: база, функции, фронт. Пока новый фронт не доехал, на проде крутится старый, и он обязан работать на новой схеме. Только так выкатка идёт без простоя: колонки не удаляются и не переименовываются сразу, таблица не встаёт под долгую блокировку, это ловит линтер ещё до слияния. На каждом окружении одно и то же: прогон вхолостую, применение, сверка с эталоном. Функции и фронт собираются один раз на коммит, и на прод уезжает ровно то, что проверили на деве. В каждую сборку вшиты коммит и дата, и в прогонах функционального и нефункционального тестирования (ФТ и НФТ) сразу указано, какая сборка проверялась. Вместе с этим внедряется культура тестирования и контроля качества, о ней в следующий раз.
История про незаметную ошибку. Цены на товары сайт держит в отдельной таблице-кэше. Таблицу добавили миграцией ещё в мае, и с тех пор бэкенд пытался в неё писать, получал отказ и шёл дальше: кэш необязательный, сайт работает и без него. Нашлось это только в сентябре, при разборе логов.
Причина в RLS (Row-Level Security), правилах прямо в базе: кто какие строки может читать и писать. Миграция включила RLS, а правил не завела, и доступ закрылся для всех. Автор рассчитывал на служебную роль Supabase, которая обычно ходит мимо правил. Но здесь Supabase стоит на управляемом Postgres облака, роли там заводит облако, и такого права у служебной роли нет ни на одном окружении.
Починилось одной миграцией: явное правило для служебной роли на этой и ещё двух внутренних таблицах. Выключить RLS было бы проще, но нельзя: у публичных ролей бывают лишние права на таблицы, и RLS для них последний барьер. Через пару дней кэш заполнился. Такой отказ должен попадать в мониторинг, даже если часть необязательная.
По отдельности каждый шаг медленнее, чем руками. В сумме выходит быстрее, потому что сайт работает без остановки и по сборке всегда видно, что именно уехало.
А у вас база и фронт едут одним релизом или порознь?
#devops #человек_оркестр
🔥4❤2