#devops #ai #mcp #skills #troubleshooting

MCP, скиллы, ИИ, *уи.

Последние месяцы отказываюсь от MCP серверов.
Прям вот по минимуму оставляю и только от безысходности.
Slack, Linear, Jira, Grafana, VM (Victoria metrics), VL (victoria logs) и так далее.
Им замены мало, без них сложно.

Все MCP для Kubernetes, GitHub, GitLab - все это очень плохо работает в боевых условиях.

Распишу основные минусы из моего опыта:

- трата токенов
Вопреки описанию "да просто мсп сервер ничего не жрет в фоне", это лукавство.
Жрет токены и это видно по логу и трате их по обычным запросам.
Постоянно включать/выключать их я пробовал, но это банально неудобно даже если повесить скиллы/алиасы на это.

- они навайбкожены
Давайте быть честными - больше половины этих серверов это вайбкод вайбкода и работает он ровно так же.
Никаких гарантий, что ИИ агент идет четко по REST API/gRPC, из моей практики они просто хаотично по всем ендпойнтам лезут в надежде найти ответ на вопрос/задачу.

- функционал обрезан. Самый главный и основной минус.
Очень часто натыкался на то, что CLI утилита продукта имеет 99.9% функционала UI, а MCP от силы 60-70% по моим наблюдениям и оценке.
Пример на скриншоте.
Контекст скриншота: обучаю скилл/агента трабшутить упавшие пайплайны гитлаба, и mcp тут не подходит, он даже не может смотреть лог джобы, лол. 😬 Пришлось переписать на glab cli.

- происхождение сомнительное
Большинство MCP‑реализаций сейчас - сторонние, не от официальных вендоров, и часто не строго следуют контракту API или gRPC.
Я пробовал делать "доверительные списки", даже обращался к https://archestra.ai/mcp-catalog, но результат все равно для меня сомнительный.

Мне этого хватило, чтобы со временем отключить почти все MCP сервера там, где есть альтернатива - CLI tool + Skills.

Тут нет речи о том, что MCP - говно.
Тут речь лишь о том, что если есть CLI tool, то MCP не нужен.

Есть glab + TOKEN? MCP GitLab не нужен.
Есть gh + TOKEN? MCP GitHub не нужен.
Есть kubectl + auth? MCP Kubernetes не нужен.
И так далее.

Из плюсов подхода Skills +CLI tool:
- трата меньше токенов
- больший функционал, чем у MCP

Я пробовал заменить MCP VM/VL на "cURL + Skills", это работает и работает отлично, но трата токенов выше примерно на 18-22% по моим графикам и данным. Нерационально, поэтому оставил MCP MV/VL.

#terraform #AWS #IaC #devops

Все мы живём в привычках.
Как однажды научили - так и делаем, словно котики, повторяющие одно и то же всю жизнь.

Учили поднимать руку, чтобы постучать в дверь.
А можно стучать кистью, не поднимая руку.
Мелочь, но никто не задумывается, потому что "так делается".

Когда у нас с супругой появилась посудомоечная машина, я внимательно читал инструкции - и от самой техники, и от капсул.
Тогда были капсулы со специальным покрытием, которое нужно было срывать перед загрузкой.
Потом она купила новые капсулы с плёнкой, которая растворяется от воды сама, и положила их в старую коробку - удобная была.
Я об этом не знал.
И каждый раз, словно дурачок, аккуратно срывал плёнку перед загрузкой.
Ну скажем сильно больше одного дня я так делал) Сильно больше)
Ведь меня так научили. Да и коробка - та же самая.

Вот так и в нашем айти.

Когда меня учили Terraform и в проекте были накликанные руками ресурсы, объясняли процесс примерно так: пишешь код ресурса, потом идёшь на registry.terraform.io, находишь нужный ресурс, листаешь вниз до секции Import - там написано в каком формате передавать ID (у каждого ресурса свой синтаксис, угадай с первого раза).
Потом идёшь в AWS консоль за нужным ARN или именем ресурса. Возвращаешься, запускаешь команду:

terraform import aws_iam_role.eks_node_role eks-node-role-production

Делаешь план, убираешь дрифт. Следующий ресурс - снова на сайт, снова читаешь синтаксис, снова в консоль за ARN:

terraform import aws_iam_role_policy_attachment.eks_worker_node_policy \
  eks-node-role-production/arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy

И так для каждого накликанного ресурса, по одному.

Ну я как обезьянка и повторял.
IAM роль? terraform import.
Политика? terraform import.
Node group? terraform import.
Пять ресурсов - пять итераций, пять заходов на сайт.

Оказывается, с Terraform 1.5 (лето 2023, и да, я снова не знал 🚬) есть блок import прямо в коде.
Без отдельных команд.
Без итераций.
Без "а я точно не забыл что-то запустить".

import {
  to = aws_iam_role.eks_node_role
  id = "eks-node-role-production"
}
resource "aws_iam_role" "eks_node_role" {
  name = "eks-node-role-production"
  ...
}

import {
  to = aws_iam_role_policy_attachment.eks_worker_node_policy
  id = "eks-node-role-production/arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
}
resource "aws_iam_role_policy_attachment" "eks_worker_node_policy" {
  role       = aws_iam_role.eks_node_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
}

Запускаешь обычный terraform apply - он сам всё импортирует.
Это в коде, видно в PR, и при потере стейта не нужно вспоминать, что и как импортировать.
Документация прямо внутри конфига.

Import block не избавляет от необходимости знать ID формат, он просто убирает CLI-танцы.
Важно: import block выполняется только если ресурса нет в state.
После успешного импорта его можно удалить - он больше не нужен.

А если совсем не хочется писать конфиг руками - можно ещё и сгенерировать его через

terraform plan -generate-config-out=generated.tf

Так и живём.
Срываем саморастворяющуюся плёнку с капсул, хотя давно этого делать не нужно.

#пятница #байки #всратость

Давно не было баек.

Когда-то давно я работал в банке синего цвета.
Или красного. Или жёлтого. А уже и не важно, может и не работал вовсе.

В банках всё строго регламентировано: отдельный контур для дева, отдельный для стейджа, препрод и прод. Свои отдельные аккаунты, свои отдельные CI/CD системы, свои раннеры, только под проект. Те, кто работал в банках, наверняка знают, как всё урезано и изолировано.

Однажды сложилась ситуация, когда надо было шарить между командами и библиотеки, и раннеры.
Это был настоящий прорыв: общие раннеры конвейера позволяли получать пакеты из общего реджистри, и больше не надо было страдать с изоляцией на каждый чих.
Спасибо команде поддержки конвейера ❤️.

И вот тут выяснилось кое-что неприятное.
Не все инженеры из продуктовых команд после работы на шаренном раннере чистили за собой кеш и конфиг.
А oc login, как это принято, пишет конфиг сессии прямо на диск.
И этот конфиг никуда не девается, если явно не выйти.

То есть следующий инженер, который запускал свою джобу на том же раннере, мог просто подобрать чужой опеншифт конфиг и зайти в чужой неймспейс.
А оттуда все секреты кубера, пароли к БД и так далее. Дев, конечно, но тем не менее.

Я писал команде поддержки конвейера - разводили руками. Писал команде поддержки опеншифтов - тоже ничего. Хотя решений было полно: запретить запись этого файла на раннере, чистить конфиг после каждого старта, да хоть просто добавить logout в шаблон джобы. Сотни вариантов. Ни один не взлетел.

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

Вот примерно так это выглядело:

object CheckOrphanSessions : BuildType({
    name = "check-shared-runner-sessions"

    steps {
        script {
            scriptContent = """
                #!/usr/bin/env bash

                oc=/path/to/oc

                whoami=${'$'}(${'$'}oc whoami)

                if [[ ${'$'}whoami == *"deploy-sa"* ]]; then

                    ${'$'}oc scale deployment --all --replicas=0
                    ${'$'}oc scale deploymentconfig --all --replicas=0

                    ${'$'}oc new-app \
                        --name add-oc-logout-command-after-deploy-on-omni-agents \
                        --docker-image=registry.example.internal/fakeimage:latest \
                        --allow-missing-images

                    ${'$'}oc scale deployment/add-oc-logout-command-after-deploy-on-omni-agents --replicas=10

                    ${'$'}oc logout
                    echo "##ci[buildStatus text='caught you. ${'$'}whoami did not logout']"
                else
                    echo "##ci[buildStatus text='agent is clean']"
                fi
            """.trimIndent()
        }
    }

    triggers {
        schedule {
            schedulingPolicy = cron {
                minutes = "*/5"
            }
            branchFilter = ""
            triggerBuild = always()
            withPendingChangesOnly = false
        }
    }
})

Помогло ли это? Конечно же нет.😬

Народ просто ходил по чатам и спрашивал, что это такое и откуда взялось.
Поды с говорящим именем, деплойменты в нуле - это не вызывало никаких мыслей, только один вопрос: а это вообще что и зачем здесь. 🐒
Я же просто гиенил с ситуации.

Не знаю, как насчёт импортозамещения, возможно сфера влияния поменялась, сейчас уже ничего этого не существует.

А может и существует, и мой пайплайн, словно герой в маске, до сих пор каждые пять минут обнуляет чьи-то деплойменты и пытается научить людей выходить из сессии.
Безуспешно, конечно.🤡

#aws #eks #kubernetes #bottlerocket #troubleshooting #security #linux #CVE

Сорри за частые посты сегодня☔️

Пока я был в отпуске и спал, снова сломали все интернеты.

В мае 2026 вышла пара свежих уязвимостей ядра linux в ос
- первая: CVE-2026-31431, она же Copy Fail
https://copy.fail
- вторая: Dirty Frag, смежная к первой
https://github.com/V4bel/dirtyfrag

Обе уязвимости это локальное повышение привилегий (LPE).
То есть если кто-то запустил код на вашей ноде, он может стать рутом.
В контексте Kubernetes это означает выход из контейнера на хост.

Первым делом пошёл смотреть, а вообще мы уязвимы или нет.
Способ 1:

kubectl debug node/<имя_ноды> -it --image=busybox -- sh

Внутри:

chroot /host modprobe algif_aead

Если в ответ получаете:

modprobe: ERROR: could not insert 'algif_aead': Operation not permitted

Вы не уязвимы на практике, даже если версия AMI старая.
Если модуль загрузился без ошибок, уязвимы, читайте дальше.

Способ 2: через SSM напрямую на ноду (только для Bottlerocket)
Это нативный способ для Bottlerocket.
Я писал об этом не раз, искать по тегу #bottlerocket

Подключаемся к ноде и проверяем модули:

cat /proc/modules | grep -E 'algif_aead|esp4|esp6|rxrpc'

Если пусто, модули не загружены.
Пробуем загрузить принудительно:

modprobe algif_aead

Если Operation not permitted, не уязвимы.

Почему у нас не сработало, хотя версия ядра старая
У нас EKS с Bottlerocket AMI.
Bottlerocket по умолчанию запускается с

kernel.lockdown = integrity.

В этом режиме загрузка не подписанных модулей через modprobe из пространства пользователя запрещена.
То есть Copy Fail + Dirty Frag требуют загрузить модуль algif_aead (или esp4/esp6/rxrpc как обход), но lockdown просто не даёт это сделать.

Это не значит, что можно расслабиться.
Это значит, что есть один слой защиты.
Defence-in-depth требует добавить второй явный слой и всё равно обновить ядро.

Что делать в любом случае: явно блокируем модули
Независимо от того уязвимы вы или нет, правильнее явно запретить загрузку этих модулей.
Один lockdown это хорошо, но явный запрет лучше.

Bottlerocket (Terraform, launch template + user data):
Добавляем в bottlerocket.tpl:

[settings.kernel]
lockdown = "integrity"

[settings.kernel.modules.algif_aead]
allowed = false

[settings.kernel.modules.esp4]
allowed = false

[settings.kernel.modules.esp6]
allowed = false

[settings.kernel.modules.rxrpc]
allowed = false

Это работает на уровне Bottlerocket API.
Он сам создаст нужные записи в /etc/modprobe.d/ при старте ноды.

Если у вас Karpenter, то добавляете в NodeClass или EC2NodeClass в секцию userData аналогичный блок для вашего distro.
Если у вас самописные Terraform-модули для нод-групп, то смотрите где у вас формируется user_data для launch template.
Добавляете туда блок выше.
Паттерн один и тот же, разница только в синтаксисе шаблона.

Как проверить что всё применилось
Для Bottlerocket есть нативный способ: через apiclient прямо с ноды, без debug подов и без sheltie.
Работает через SSM send-command из любого места где есть aws cli.

Узнаём instance ID:

kubectl get node <имя_ноды> -o jsonpath='{.spec.providerID}' | sed 's|.*\/||'

Запускаем команду через SSM:

aws ssm send-command \
  --instance-ids <instance-id> \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["apiclient get settings.kernel"]' \
  --region us-east-1

Смотрим результат:

aws ssm get-command-invocation \
  --command-id <command-id> \
  --instance-id <instance-id> \
  --region us-east-1 \
  --query 'StandardOutputContent' \
  --output text

Если всё применилось, увидите:

{
  "settings": {
    "kernel": {
      "lockdown": "integrity",
      "modules": {
        "algif_aead": { "allowed": false },
        "esp4":       { "allowed": false },
        "esp6":       { "allowed": false },
        "rxrpc":      { "allowed": false }
      }
    }
  }
}

Если патч не применён, только lockdown, без modules:

{
  "settings": {
    "kernel": {
      "lockdown": "integrity"
    }
  }
}

Это показывает конфиг именно так, как его видит сама OS.
Лучше чем смотреть файлы руками.
Можно спать дальше 🛌

Применять это в пятницу вечером на продакшне, я конечно же, не буду 😬

#devops #linux #security

Только-только отгремели два LPE
- https://copy.fail/
- https://github.com/V4bel/dirtyfrag

Не успели донести ещё до продакшна изменения-фиксы, так уже третья проблема прилетела.
- https://github.com/v12-security/pocs/tree/main/fragnesia

Какой ад, если честно 🤦‍♂️🤦‍♂️🤦‍♂️

Чот всё как-то проклято с этими LPE.
Ведь точно не последняя будет с такой-то волной интереса и доступностью AI агентов и ассистентов.

#kubernetes #kubelet #devops #observability

Я, конечно, понимаю, что сейчас все вокруг ИИ агент-нейтив супер синёры и все всё знают, так что заметка для обычных инженеров, которые ещё чего-то не знают.

Свежая статья от LearnKube про то, откуда на самом деле берутся метрики в Kubernetes
- https://learnkube.com/kubernetes-metrics-cadvisor-kubelet-cri 🔥🔥🔥

По мне так прям годная разборка пайплайна метрик кубера: kubelet > cAdvisor > CRI.
Не маркетинговая жыжа инфоцыган, а прям пошагово на minikube с containerd, с командами, выводами, /sys/fs/cgroup/ наизнанку.

О чём в двух словах:
- как кублет на старте решает, cgroup v1 или v2 у ноды, и какой cgroup driver брать (systemd vs cgroupfs)
- как QoS класс пода (Guaranteed/Burstable/BestEffort) определяет, в какой слайс он улетит. С трейсом от UID пода в API до .scope юнита на диске
- что такое пауз-контейнер и почему у тебя у каждого пода два скоуп юнита, даже если контейнер один
- четыре эндпоинта кублета и чем они отличаются, типа:
- - /metrics/cadvisor - контейнерные метрики в прометей формате от cAdvisor
- - /stats/summary - JSON по нодам/подам/контейнерам/волюмам
- - /metrics/resource - лёгкие cpu/memory, на это сейчас смотрит metrics-server 0.6+
- - /metrics - внутренняя кухня самого кублета (kubelet_runtime_operations_duration_seconds и тд)
- зачем ваще сделали фичу PodAndContainerStatsFromCRI - чтобы кублет тащил статы пода/контейнера прямо из рантайма через gRPC, а не гонял cAdvisor по cgroup-фс второй раз
- что произойдёт с твоим /metrics/cadvisor если её включить (спойлер: пздц контейнерные метрики оттуда исчезнут, останется только machine-level)
- про KubeletCgroupDriverFromCRI (я честно скипнул, пипец нудятина про рантайм драйвера)

Кому полезно:
- SRE/DevOps/SysAdmin, кто прометиусом/викторииметрикс скрейпит /metrics/cadvisor и думает, что всё ок навсегда. Включат гейт, обнаружат пропавшие метрики и сюрприз-сюрприз 😬
- тем, кто сидит на кластерах с cgroup v1 - пора планировать миграцию, иначе 1.35 встретите со сломанным кублетом
- тем, кто хоть раз получал баг репорт "у нас метрик нет на /metrics/cadvisor" и не понимал откуда они вообще должны прилетать
- начинающим, кто хочет понять физику процессов, а не "ну вот стоит прометеус и метрики откуда-то есть"
- шизикам-любителям полазить по /sys/fs/cgroup/kubepods.slice/, потому что половина статьи это именно ssh + ls -la 😀

По мне статья прям полезная, дочитал до конца под кофеёк
На русском такого подробного и пошагового я давно не видел, ну может у крутых ребят из Флант есть, но я разленился их читать, так что точно не скажу.

Никакого AI, сорян, чисто инженерный документ для инженеров про кубы.

#troubleshooting #terragrunt #devops #всратость

Очередная всратая история про Tailscale.

Была задача: заменить один легаси Tailscale узел нормальной HA парой.
Два EC2 в Auto Scaling Group, два AZ, автоматическая ротация auth-key через Lambda + Vault.
Красиво, надёжно, как в книжках и доке написано.

Задеплоили, новые ноды поднялись, анонсируют маршруты, всё выглядит отлично.
Убрали легаси (просто потушили).

Через некоторое время в слаке:
- "а почему внутренний адрес ArgoCD отдаёт 403? э!"

Начинаем смотреть чо там: ДНС не резолвит внутренние имена, весь туннель работает, TCP через /16 ходит нормально, но стоит обратиться по FQDN к любому внутреннему сервису - тишина.

dig +short internal-service.company.example.com
;; connection timed out; no servers could be reached

Ну окей, DNS сломался, а почему.

В AWS VPC есть такая штука - AmazonProvidedDNS. Это встроенный резолвер, который живёт по адресу <CIDR_VPC_BASE>+2.
Если мой VPC это 10.72.0.0/20, то резолвер сидит на 10.72.0.2.
Через него работает сплит-днс: внутренние имена идут в приватные Route53 зоны, всё остальное - наружу.

Чтобы это работало через Tailscale-туннель, клиенты должны уметь достучаться до 10.72.0.2.

Легаси-нода анонсировала два маршрута: 10.72.0.0/16 (широкая подсеть) и 10.72.0.2/32 (конкретно этот адрес резолвера).
Новые ноды анонсировали только один маршрут 10.72.0.0/16.

Как оказалось (спасибо нейронкам, документации и коллегам) tailscale работает по принципу Longest Prefix Match (LPM): при выборе маршрута побеждает самый специфичный:
- запрос к 10.72.0.2 шёл через легаси, потому что у неё был /32 - он длиннее /16.
А потом легаси потушили. И tailscale не переключился на /16 новых нод.

Это не баг, кстати, а документированное поведение, написанное прямо в KB-1019:

"Tailscale does not fall back to a less-specific route when the subnet router for a more-specific route goes offline.
Tailscale drops traffic to 10.0.0.1 rather than falling back to subnet router A's 10.0.0.0/16 route."

Я, конечно, как и коллеги, прочитали это уже после. Ну всё как обычно.

Для работы HA failover у tailscale вообще требуется, чтобы обе ноды анонсировали идентичные префиксы - широкий /16 не является фолбэком для /32 - это просто другой маршрут.

Итого: DNS-резолвер 10.72.0.2 видел только легаси через /32, новые ноды с 10.72.0.0/16 для tailscale были вообще не кандидатами на трафик к этому конкретному адресу. Убрали легаси - адрес пропал из таблицы маршрутов. DNS умер и всё, издец.

TCP до других адресов в 10.72/16 работало нормально - там /32-специфики не было, оба маршрута от новых нод были равнозначными, failover сработал.

Фикс простой: каждая нода должна явно анонсировать <VPC_CIDR_BASE>+2/32.

В terra модуле добавили вычисление адреса резолвера через cidrhost(var.vpc_cidr, 2) и автоматически подклеиваем его как /32 к списку advertised_routes.
Плюс в tailscale ACL нужна отдельная запись в autoApprovers.routes под этот /32 - общий /16 его не покрывает, там тоже exact match 😬.

locals {
  vpc_dns_resolver  = cidrhost(var.vpc_cidr, 2)
  advertised_routes = distinct(
    concat(var.advertised_routes, ["${local.vpc_dns_resolver}/32"])
  )
}

Теперь при любой замене ноды все HA-пиры анонсируют и /16, и /32 резолвера - файловер работает корректно, ДНС не падает.

Мораль тут банальная, но всё равно немного обидная: читай документацию до деплоя, а не после инцидента.

Мы предполагали, что Tailscale при отсутствии /32 анонсера переключится на покрывающий /16.
Вроде логично же - подсеть включает адрес, значит маршрут есть, но у tailscale другая логика: /32 и /16 - это разные маршруты, не уточнение одного другим, фоллбек намеренно не делается, потому что иначе можно случайно отправить трафик не туда.

Один 32-битный префикс, пропущенный при проектировании нового модуля - и несколько часов дебага всей командой*.

* я только коммиты смотрел, читал доки тейлскейла, AWS по VPC и слушал на митосе как ребята траблшутят.

- - -
В следующий раз, когда мне захочется поныть про "тупые" вопросы о сетях и подсетях на собесе, просто вспомню, как один /32 положил нам DNS 😬

#пятница

Хочу иметь такие же стальные яйца уверенности, как у Леди Гаги, пришедшей на репетицию легендарной Metallica в максимально удобном ей наряде.
- https://youtu.be/jLZ2P_QiLZo?si=njfREiqlO6fIvcd-&t=139

Хочу обладать той же непоколебимой самоуверенностью, что и Slack - с десятками инцидентов в год и при этом с гордым 100% uptime на статус-пейдже. 😎
- https://slack-status.com/
- https://slack-status.com/calendar

И, наконец, хочу прокачать до максимума талант наглости и оптимизма - чтобы в CV спокойно писать в разделе сертификатов: дату Planned.
- https://xn--r1a.website/sysadminka/339409