#devops #certificate
Простая напоминалка (в том числе и себе) на 2026-2027 годы про TLS‑сертификаты.
Надеюсь, все избегут инцидентов с "протухшими" сертификатами в продакшене:
сроки жизни постепенно режут, и первая большая итерация начинается уже сейчас.
Кратко по таймлайну (публичные TLS, CA/B Forum):
Параллельно сокращают сроки повторного DCV, к 2029 остаётся до ~10 дней на переиспользование проверки домена.
CA (официальные анонсы и FAQ):
- DigiCert - переход на 199‑дневные сертификаты:
https://knowledge.digicert.com/alerts/public-tls-certificates-199-day-validity
- DigiCert - FAQ по срокам валидности:
https://www.digicert.com/faq/tls-ssl-certificate-validity
- Sectigo - про риски и 200‑дневную валидность:
https://www.sectigo.com/blog/200-day-ssl-certificate-expiration-risk
- GlobalSign - 199‑дневные сертификаты с марта 2026:
https://www.nicsrs.com/blog/globalsign-199-day-ssl-certificate-validity-2026
ACME / Let’s Encrypt и короткоживущие серты (думаю такое у многих):
- Let’s Encrypt: с 90 до 45 дней, общий план:
https://letsencrypt.org/2025/12/02/from-90-to-45.html
- Разбор перехода на 45‑дневные серты:
https://www.certkit.io/blog/45-day-certificates
- Let’s Encrypt: 6‑дневные и IP‑сертификаты (интересно в контексте мира с 47 днями):
https://www.helpnetsecurity.com/2026/01/20/lets-encrypt-6-day-tls-certificates
https://letsencrypt.org/2026/03/11/shorter-certs-certbot
Инструменты и автоматизация:
- cert-manager (релизы, где можно отслеживать поддержку коротких сроков, ACME и т.д.):
https://cert-manager.io/docs/releases/
Хорошие обзоры по общему таймлайну 398 > 47 дней и подготовке:
- Гайд по адаптации к 47‑дневным сертификатам:
https://www.centralnicreseller.com/47-day-ssl-certificates-validity-adaptation-guide-for-businesses
- Обзор сокращения сроков и влияния на процессы:
https://www.eginnovations.com/blog/ssl-tls-certificate-lifetimes-to-reduce-to-47-days
Эпоха "раз в год продлил и забыл" заканчивается.
Владельцам приватных внутренних УЦ в изолированных контурах можно пока расслабиться 😬 - эти правила касаются именно публичных TLS.
Простая напоминалка (в том числе и себе) на 2026-2027 годы про TLS‑сертификаты.
Надеюсь, все избегут инцидентов с "протухшими" сертификатами в продакшене:
сроки жизни постепенно режут, и первая большая итерация начинается уже сейчас.
Кратко по таймлайну (публичные TLS, CA/B Forum):
398 > 200 дней (с марта 2026) > 100 дней (с 2027) > 47 дней (с 2029).
Параллельно сокращают сроки повторного DCV, к 2029 остаётся до ~10 дней на переиспользование проверки домена.
CA (официальные анонсы и FAQ):
- DigiCert - переход на 199‑дневные сертификаты:
https://knowledge.digicert.com/alerts/public-tls-certificates-199-day-validity
- DigiCert - FAQ по срокам валидности:
https://www.digicert.com/faq/tls-ssl-certificate-validity
- Sectigo - про риски и 200‑дневную валидность:
https://www.sectigo.com/blog/200-day-ssl-certificate-expiration-risk
- GlobalSign - 199‑дневные сертификаты с марта 2026:
https://www.nicsrs.com/blog/globalsign-199-day-ssl-certificate-validity-2026
ACME / Let’s Encrypt и короткоживущие серты (думаю такое у многих):
- Let’s Encrypt: с 90 до 45 дней, общий план:
https://letsencrypt.org/2025/12/02/from-90-to-45.html
- Разбор перехода на 45‑дневные серты:
https://www.certkit.io/blog/45-day-certificates
- Let’s Encrypt: 6‑дневные и IP‑сертификаты (интересно в контексте мира с 47 днями):
https://www.helpnetsecurity.com/2026/01/20/lets-encrypt-6-day-tls-certificates
https://letsencrypt.org/2026/03/11/shorter-certs-certbot
Инструменты и автоматизация:
- cert-manager (релизы, где можно отслеживать поддержку коротких сроков, ACME и т.д.):
https://cert-manager.io/docs/releases/
Хорошие обзоры по общему таймлайну 398 > 47 дней и подготовке:
- Гайд по адаптации к 47‑дневным сертификатам:
https://www.centralnicreseller.com/47-day-ssl-certificates-validity-adaptation-guide-for-businesses
- Обзор сокращения сроков и влияния на процессы:
https://www.eginnovations.com/blog/ssl-tls-certificate-lifetimes-to-reduce-to-47-days
Эпоха "раз в год продлил и забыл" заканчивается.
Please open Telegram to view this post
VIEW IN TELEGRAM
😢8👍4🙏4❤1
#devops #github
GitHub объявил, что с 24 апреля 2026 года данные взаимодействий Copilot (prompts, ответы, сниппеты и контекст) начинают использоваться для обучения моделей по умолчанию, если пользователь явно не отключит это в настройках для тарифов Copilot Free/Pro/Pro+.
https://github.blog/news-insights/company-news/updates-to-github-copilot-interaction-data-usage-policy/
Как и водится в маленьких инди компаниях, даже сроки они не стали соблюдать, залепили раньше, нарушая сроки объявленого дедлайна. Сейчас 7 апреля и у меня уже стоит эта галочка.
Возможно уже и данные коллектят, кто знает, верить уже тяжело.
Кто-то может, конечно, возразить, что "галочка включена != сбор данных", но я не очень согласен с этим.
Галочка стоит, текст честно написан, значит так оно и есть.
Кто еще боится в век AI утилит лишиться приватности или заставляют условия работы в компаниях, спешите снять галочку:
- Идите по ссылке на свой профиль https://github.com/settings/copilot/features
-
GitHub объявил, что с 24 апреля 2026 года данные взаимодействий Copilot (prompts, ответы, сниппеты и контекст) начинают использоваться для обучения моделей по умолчанию, если пользователь явно не отключит это в настройках для тарифов Copilot Free/Pro/Pro+.
https://github.blog/news-insights/company-news/updates-to-github-copilot-interaction-data-usage-policy/
Как и водится в маленьких инди компаниях, даже сроки они не стали соблюдать, залепили раньше, нарушая сроки объявленого дедлайна. Сейчас 7 апреля и у меня уже стоит эта галочка.
Возможно уже и данные коллектят, кто знает, верить уже тяжело.
Кто-то может, конечно, возразить, что "галочка включена != сбор данных", но я не очень согласен с этим.
Галочка стоит, текст честно написан, значит так оно и есть.
Allow GitHub to collect and use my Inputs, Outputs, and associated context to train and improve AI models.
Кто еще боится в век AI утилит лишиться приватности или заставляют условия работы в компаниях, спешите снять галочку:
- Идите по ссылке на свой профиль https://github.com/settings/copilot/features
-
Settings -> Copilot -> Features -> Privacy -> Allow GitHub to use my data for AI model training,❤9
#opensource #alertmanager #devops
Новости opensource мира.
У продукта Alertmanager есть неприятная недоработка.
Все уведомления в Slack он отправляет двумя сообщениями:
- проблема (firing)🔴
- проблема решена (resolved)🟢
Наверняка видели.
В мире шумных уведомлений даже этого много.
По сути 100 алертов порождают 200 сообщений (после их решения), что не очень удобно.
API самого Slack позволяет изменять сообщения, но алертменеджер не умел в это.
Это происходит прежде всего потому, что алертменеджер не хранит стейт алертов, чтобы "запоминать" куда слать обновление по алерту.
При этом аналоги умеют менять сообщение (меняя красный firing на зелёный resolved):
- grafana oncall / IRM
- pagerduty
С появлением GenAI инструментов я захотел исправить эту досадную оплошность, сделал форк алертменеджера, локально всё потестировал и примерно с полгода гонял у себя - работает идеально. (Март 2025)
Затем осмелился и запилил пулл реквест:
https://github.com/prometheus/alertmanager/pull/4682 (Ноябрь 2025)
Не скрою, пользовался GenAI, но основная идея была моя.
Я на 90% понимаю изменённый код и поведение.
После вялого обсуждения другие, более активные участники, реализовали это в два пулл реквеста:
- https://github.com/prometheus/alertmanager/pull/4899 (Январь 2026)
- https://github.com/prometheus/alertmanager/pull/5007 (Февраль 2026)
Само собой после этого мой PR не имеет смысла, я закрыл его. (Февраль 2026)
Вчера, 8 апреля 2026 выпущен новый релиз v0.32.0.
https://github.com/prometheus/alertmanager/releases/tag/v0.32.0
Теперь алертменеджер умеет хранить стейт алертов для слака и менять сообщения - что очень удобно. 🎉
Всех, кто использует алертменеджер, поздравляю.
Можете обновлять и радоваться меньшему количеству сообщений и меньшему шуму алертов.
---
Но вам же интересно глянуть, как это работает перед обновлением прода?
Нужен Bot Token Slack (
Важно: работает только с токеном, не с webhook URL.
Положить конфиг в
Запустить alertmanager v0.32.0 через Docker:
Стрельнуть алертом:
Подождать ~10–15 секунд - в Slack появится сообщение с 🔴.
Зарезолвить:
Подождать ~10 секунд - то же самое сообщение изменится на 🟢.
Нового сообщения не будет!
Поздравляю всех с таким мелким, но приятным обновлением.
Новости opensource мира.
У продукта Alertmanager есть неприятная недоработка.
Все уведомления в Slack он отправляет двумя сообщениями:
- проблема (firing)🔴
- проблема решена (resolved)🟢
Наверняка видели.
В мире шумных уведомлений даже этого много.
По сути 100 алертов порождают 200 сообщений (после их решения), что не очень удобно.
API самого Slack позволяет изменять сообщения, но алертменеджер не умел в это.
Это происходит прежде всего потому, что алертменеджер не хранит стейт алертов, чтобы "запоминать" куда слать обновление по алерту.
При этом аналоги умеют менять сообщение (меняя красный firing на зелёный resolved):
- grafana oncall / IRM
- pagerduty
С появлением GenAI инструментов я захотел исправить эту досадную оплошность, сделал форк алертменеджера, локально всё потестировал и примерно с полгода гонял у себя - работает идеально. (Март 2025)
Затем осмелился и запилил пулл реквест:
https://github.com/prometheus/alertmanager/pull/4682 (Ноябрь 2025)
Не скрою, пользовался GenAI, но основная идея была моя.
Я на 90% понимаю изменённый код и поведение.
После вялого обсуждения другие, более активные участники, реализовали это в два пулл реквеста:
- https://github.com/prometheus/alertmanager/pull/4899 (Январь 2026)
- https://github.com/prometheus/alertmanager/pull/5007 (Февраль 2026)
Само собой после этого мой PR не имеет смысла, я закрыл его. (Февраль 2026)
Вчера, 8 апреля 2026 выпущен новый релиз v0.32.0.
https://github.com/prometheus/alertmanager/releases/tag/v0.32.0
Теперь алертменеджер умеет хранить стейт алертов для слака и менять сообщения - что очень удобно. 🎉
Всех, кто использует алертменеджер, поздравляю.
Можете обновлять и радоваться меньшему количеству сообщений и меньшему шуму алертов.
---
Но вам же интересно глянуть, как это работает перед обновлением прода?
Нужен Bot Token Slack (
xoxb-...) со скоупами chat:write и chat:update.Важно: работает только с токеном, не с webhook URL.
Положить конфиг в
/tmp/am-test/alertmanager.ymlglobal:
resolve_timeout: 1m
route:
receiver: slack
group_by: [alertname]
group_wait: 10s
group_interval: 10s
repeat_interval: 12h
receivers:
- name: slack
slack_configs:
- send_resolved: true
api_url: https://slack.com/api/chat.postMessage
http_config:
authorization:
credentials: xoxb-YOUR-BOT-TOKEN
channel: '#your-channel'
update_message: true # <-- вот эта опция
title: '{{ .GroupLabels.alertname }} - {{ .Status | toUpper }}'
text: |
{{ if eq .Status "firing" }}🔥 *{{ .Alerts.Firing | len }} alert(s) FIRING*{{ else }}✅ *All alerts RESOLVED*{{ end }}
{{ range .Alerts }}• {{ if .Annotations.summary }}{{ .Annotations.summary }}{{ else }}{{ .Labels.alertname }}{{ end }}
{{ end }}
color: '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}'
Запустить alertmanager v0.32.0 через Docker:
mkdir -p /tmp/am-test
docker run -d \
--name am-test \
-p 9093:9093 \
-v /tmp/am-test/alertmanager.yml:/etc/alertmanager/alertmanager.yml \
-v /tmp/am-test/data:/alertmanager \
prom/alertmanager:v0.32.0
Стрельнуть алертом:
curl -X POST http://localhost:9093/api/v2/alerts \
-H 'Content-Type: application/json' \
-d '[{
"labels": {"alertname": "TestAlert", "severity": "warning"},
"annotations": {"summary": "This is a test alert - will resolve in the same message"}
}]'
Подождать ~10–15 секунд - в Slack появится сообщение с 🔴.
Зарезолвить:
curl -X POST http://localhost:9093/api/v2/alerts \
-H 'Content-Type: application/json' \
-d '[{
"labels": {"alertname": "TestAlert", "severity": "warning"},
"annotations": {"summary": "This is a test alert - will resolve in the same message"},
"endsAt": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"
}]'
Подождать ~10 секунд - то же самое сообщение изменится на 🟢.
Нового сообщения не будет!
Поздравляю всех с таким мелким, но приятным обновлением.
🔥46❤2
#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 тут не подходит, он даже не может смотреть лог джобы, лол.😬 Пришлось переписать на
- происхождение сомнительное
Большинство MCP‑реализаций сейчас - сторонние, не от официальных вендоров, и часто не строго следуют контракту API или gRPC.
Я пробовал делать "доверительные списки", даже обращался к https://archestra.ai/mcp-catalog, но результат все равно для меня сомнительный.
Мне этого хватило, чтобы со временем отключить почти все MCP сервера там, где есть альтернатива - CLI tool + Skills.
Есть 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.
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.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14❤3
#ai #devops
Совершенно ожидаемо и неожиданно одновременно Nvidia выпустила бесплатные эндпойнты к популярным LLM моделям.
https://build.nvidia.com/models?filters=nimType%3Anim_type_preview&orderBy=weightPopular%3ADESC
А давайте-ка глянем, так ли оно.
- прошел регистрацию (мой
- прошел верификацию (номер телефона НЕ РФ, другие страны не проверял само собой) ✅
- выбрал рандомную модель
https://build.nvidia.com/moonshotai/kimi-k2-instruct
- нажал
- нажал в окошке
- скопировал код к себе локально в файл
- установил пакет опенаи (если нет)
- сохранил код и запустил его
Работает! 🎉
Забирайте себе и тренируйтесь с разными моделями бесплатно. ❤️
- - -
Update для самых быстрых и невнимательных.
Не забывайте, что там:
"Privacy. Your input and output will be recorded to provide you with this trial experience and to improve NVIDIA products and services, including AI models, in accordance with our Privacy Policy.
Do not upload any confidential information or personal data unless expressly permitted. Your use is logged for security, fraud or abuse monitoring and shared with third party service providers for this purpose. If the demo necessarily requires the input of personal data, logging for product development purposes will be turned off."
Совершенно ожидаемо и неожиданно одновременно Nvidia выпустила бесплатные эндпойнты к популярным LLM моделям.
https://build.nvidia.com/models?filters=nimType%3Anim_type_preview&orderBy=weightPopular%3ADESC
А давайте-ка глянем, так ли оно.
- прошел регистрацию (мой
gmail аккаунт) ✅- прошел верификацию (номер телефона НЕ РФ, другие страны не проверял само собой) ✅
- выбрал рандомную модель
https://build.nvidia.com/moonshotai/kimi-k2-instruct
- нажал
view code - нажал в окошке
generate API key- скопировал код к себе локально в файл
1.py , добавил context простой вопрос про хоккуfrom openai import OpenAI
client = OpenAI(
base_url = "https://integrate.api.nvidia.com/v1",
api_key = "nvapi-m3_bqO98rY-а-зачем-вам-мой-токен-BAMIGI-tLbz3VQ20MpwyTbU-"
)
completion = client.chat.completions.create(
model="moonshotai/kimi-k2-instruct",
messages=[{"role":"user","content":"Write a haiku about infrastructure as code."}],
temperature=0.6,
top_p=0.9,
max_tokens=4096,
stream=True
)
for chunk in completion:
if not getattr(chunk, "choices", None):
continue
if chunk.choices and chunk.choices[0].delta.content is not None:
print(chunk.choices[0].delta.content, end="")
- установил пакет опенаи (если нет)
pip3 install openai
- сохранил код и запустил его
python3 1.py
Lines of code define
bridges spun from pure intent—
infrastructure breathes.
Работает! 🎉
Забирайте себе и тренируйтесь с разными моделями бесплатно. ❤️
- - -
Update для самых быстрых и невнимательных.
Не забывайте, что там:
"Privacy. Your input and output will be recorded to provide you with this trial experience and to improve NVIDIA products and services, including AI models, in accordance with our Privacy Policy.
Do not upload any confidential information or personal data unless expressly permitted. Your use is logged for security, fraud or abuse monitoring and shared with third party service providers for this purpose. If the demo necessarily requires the input of personal data, logging for product development purposes will be turned off."
❤8
#terraform #AWS #IaC #devops
Все мы живём в привычках.
Как однажды научили - так и делаем, словно котики, повторяющие одно и то же всю жизнь.
Учили поднимать руку, чтобы постучать в дверь.
А можно стучать кистью, не поднимая руку.
Мелочь, но никто не задумывается, потому что "так делается".
Когда у нас с супругой появилась посудомоечная машина, я внимательно читал инструкции - и от самой техники, и от капсул.
Тогда были капсулы со специальным покрытием, которое нужно было срывать перед загрузкой.
Потом она купила новые капсулы с плёнкой, которая растворяется от воды сама, и положила их в старую коробку - удобная была.
Я об этом не знал.
И каждый раз, словно дурачок, аккуратно срывал плёнку перед загрузкой.
Ну скажем сильно больше одного дня я так делал) Сильно больше)
Ведь меня так научили. Да и коробка - та же самая.
Вот так и в нашем айти.
Когда меня учили Terraform и в проекте были накликанные руками ресурсы, объясняли процесс примерно так: пишешь код ресурса, потом идёшь на registry.terraform.io, находишь нужный ресурс, листаешь вниз до секции Import - там написано в каком формате передавать ID (у каждого ресурса свой синтаксис, угадай с первого раза).
Потом идёшь в AWS консоль за нужным ARN или именем ресурса. Возвращаешься, запускаешь команду:
Делаешь план, убираешь дрифт. Следующий ресурс - снова на сайт, снова читаешь синтаксис, снова в консоль за ARN:
И так для каждого накликанного ресурса, по одному.
Ну я как обезьянка и повторял.
IAM роль?
Политика?
Node group?
Пять ресурсов - пять итераций, пять заходов на сайт.
Оказывается, с Terraform 1.5 (лето 2023, и да, я снова не знал🚬 ) есть блок import прямо в коде.
Без отдельных команд.
Без итераций.
Без "а я точно не забыл что-то запустить".
Запускаешь обычный
Это в коде, видно в PR, и при потере стейта не нужно вспоминать, что и как импортировать.
Документация прямо внутри конфига.
Import block не избавляет от необходимости знать ID формат, он просто убирает CLI-танцы.
Важно: import block выполняется только если ресурса нет в state.
После успешного импорта его можно удалить - он больше не нужен.
А если совсем не хочется писать конфиг руками - можно ещё и сгенерировать его через
Так и живём.
Срываем саморастворяющуюся плёнку с капсул, хотя давно этого делать не нужно.
Все мы живём в привычках.
Как однажды научили - так и делаем, словно котики, повторяющие одно и то же всю жизнь.
Учили поднимать руку, чтобы постучать в дверь.
А можно стучать кистью, не поднимая руку.
Мелочь, но никто не задумывается, потому что "так делается".
Когда у нас с супругой появилась посудомоечная машина, я внимательно читал инструкции - и от самой техники, и от капсул.
Тогда были капсулы со специальным покрытием, которое нужно было срывать перед загрузкой.
Потом она купила новые капсулы с плёнкой, которая растворяется от воды сама, и положила их в старую коробку - удобная была.
Я об этом не знал.
И каждый раз, словно дурачок, аккуратно срывал плёнку перед загрузкой.
Ну скажем сильно больше одного дня я так делал) Сильно больше)
Ведь меня так научили. Да и коробка - та же самая.
Вот так и в нашем айти.
Когда меня учили 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 {
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
Так и живём.
Срываем саморастворяющуюся плёнку с капсул, хотя давно этого делать не нужно.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🫡4👍2👏2
#devops #linux #security
Только-только отгремели два LPE
- https://copy.fail/
- https://github.com/V4bel/dirtyfrag
Не успели донести ещё до продакшна изменения-фиксы, так уже третья проблема прилетела.
- https://github.com/v12-security/pocs/tree/main/fragnesia
Какой ад, если честно🤦♂️ 🤦♂️ 🤦♂️
Чот всё как-то проклято с этими LPE.
Ведь точно не последняя будет с такой-то волной интереса и доступностью AI агентов и ассистентов.
Только-только отгремели два LPE
- https://copy.fail/
- https://github.com/V4bel/dirtyfrag
Не успели донести ещё до продакшна изменения-фиксы, так уже третья проблема прилетела.
- https://github.com/v12-security/pocs/tree/main/fragnesia
Какой ад, если честно
Чот всё как-то проклято с этими LPE.
Ведь точно не последняя будет с такой-то волной интереса и доступностью AI агентов и ассистентов.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
#kubernetes #kubelet #devops #observability
Я, конечно, понимаю, что сейчас все вокруг ИИ агент-нейтив супер синёры и все всё знают, так что заметка для обычных инженеров, которые ещё чего-то не знают.
Свежая статья от LearnKube про то, откуда на самом деле берутся метрики в Kubernetes
- https://learnkube.com/kubernetes-metrics-cadvisor-kubelet-cri 🔥🔥🔥
По мне так прям годная разборка пайплайна метрик кубера: kubelet > cAdvisor > CRI.
Не маркетинговая жыжа инфоцыган, а прям пошагово на minikube с containerd, с командами, выводами,
О чём в двух словах:
- как кублет на старте решает, cgroup v1 или v2 у ноды, и какой cgroup driver брать (
- как QoS класс пода (Guaranteed/Burstable/BestEffort) определяет, в какой слайс он улетит. С трейсом от UID пода в API до .scope юнита на диске
- что такое пауз-контейнер и почему у тебя у каждого пода два скоуп юнита, даже если контейнер один
- четыре эндпоинта кублета и чем они отличаются, типа:
- - /metrics/cadvisor - контейнерные метрики в прометей формате от cAdvisor
- - /stats/summary - JSON по нодам/подам/контейнерам/волюмам
- - /metrics/resource - лёгкие cpu/memory, на это сейчас смотрит metrics-server 0.6+
- - /metrics - внутренняя кухня самого кублета (
- зачем ваще сделали фичу
- что произойдёт с твоимпздц контейнерные метрики оттуда исчезнут, останется только machine-level)
- про
Кому полезно:
- SRE/DevOps/SysAdmin, кто прометиусом/викторииметрикс скрейпит😬
- тем, кто сидит на кластерах с cgroup v1 - пора планировать миграцию, иначе 1.35 встретите со сломанным кублетом
- тем, кто хоть раз получал баг репорт "у нас метрик нет на /metrics/cadvisor" и не понимал откуда они вообще должны прилетать
- начинающим, кто хочет понять физику процессов, а не "ну вот стоит прометеус и метрики откуда-то есть"
- шизикам-любителям полазить по😀
По мне статья прям полезная, дочитал до конца под кофеёк
На русском такого подробного и пошагового я давно не видел, ну может у крутых ребят из Флант есть, но я разленился их читать, так что точно не скажу.
Никакого AI, сорян, чисто инженерный документ для инженеров про кубы.
Я, конечно, понимаю, что сейчас все вокруг ИИ агент-нейтив супер синёры и все всё знают, так что заметка для обычных инженеров, которые ещё чего-то не знают.
Свежая статья от 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 если её включить (спойлер: - про
KubeletCgroupDriverFromCRI (я честно скипнул, пипец нудятина про рантайм драйвера)Кому полезно:
- SRE/DevOps/SysAdmin, кто прометиусом/викторииметрикс скрейпит
/metrics/cadvisor и думает, что всё ок навсегда. Включат гейт, обнаружат пропавшие метрики и сюрприз-сюрприз - тем, кто сидит на кластерах с cgroup v1 - пора планировать миграцию, иначе 1.35 встретите со сломанным кублетом
- тем, кто хоть раз получал баг репорт "у нас метрик нет на /metrics/cadvisor" и не понимал откуда они вообще должны прилетать
- начинающим, кто хочет понять физику процессов, а не "ну вот стоит прометеус и метрики откуда-то есть"
- шизикам-любителям полазить по
/sys/fs/cgroup/kubepods.slice/, потому что половина статьи это именно ssh + ls -la По мне статья прям полезная, дочитал до конца под кофеёк
На русском такого подробного и пошагового я давно не видел, ну может у крутых ребят из Флант есть, но я разленился их читать, так что точно не скажу.
Никакого AI, сорян, чисто инженерный документ для инженеров про кубы.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥32❤12🫡2
#troubleshooting #terragrunt #devops #всратость
Очередная всратая история про Tailscale .
Была задача: заменить один легаси Tailscale узел нормальной HA парой.
Два EC2 в Auto Scaling Group, два AZ, автоматическая ротация auth-key через Lambda + Vault.
Красиво, надёжно, как в книжках и доке написано.
Задеплоили, новые ноды поднялись, анонсируют маршруты, всё выглядит отлично.
Убрали легаси (просто потушили).
Через некоторое время в слаке:
- "а почему внутренний адрес ArgoCD отдаёт 403? э!"
Начинаем смотреть чо там: ДНС не резолвит внутренние имена, весь туннель работает, TCP через
Ну окей, DNS сломался, а почему.
В AWS VPC есть такая штука -
Если мой VPC это
Через него работает сплит-днс: внутренние имена идут в приватные Route53 зоны, всё остальное - наружу.
Чтобы это работало через Tailscale-туннель, клиенты должны уметь достучаться до
Легаси-нода анонсировала два маршрута:
Новые ноды анонсировали только один маршрут
Как оказалось (спасибо нейронкам, документации и коллегам) tailscale работает по принципу
- запрос к
А потом легаси потушили. И tailscale не переключился на
Это не баг, кстати, а документированное поведение, написанное прямо в KB-1019:
Я, конечно, как и коллеги, прочитали это уже после. Ну всё как обычно.
Для работы HA failover у tailscale вообще требуется, чтобы обе ноды анонсировали идентичные префиксы - широкий
Итого: DNS-резолвер 10.72.0.2 видел только легаси через
TCP до других адресов в
Фикс простой: каждая нода должна явно анонсировать
В terra модуле добавили вычисление адреса резолвера через
Плюс в tailscale ACL нужна отдельная запись в😬 .
Теперь при любой замене ноды все HA-пиры анонсируют и
Мораль тут банальная, но всё равно немного обидная: читай документацию до деплоя, а не после инцидента.
Мы предполагали, что Tailscale при отсутствии
Вроде логично же - подсеть включает адрес, значит маршрут есть, но у tailscale другая логика:
Один 32-битный префикс, пропущенный при проектировании нового модуля - и несколько часов дебага всей командой*.
* я только коммиты смотрел, читал доки тейлскейла, AWS по VPC и слушал на митосе как ребята траблшутят.
- - -
В следующий раз, когда мне захочется поныть про "тупые" вопросы о сетях и подсетях на собесе, просто вспомню, как один /32 положил нам DNS😬
Очередная всратая история
Была задача: заменить один легаси 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
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍8🤡1
#mcp #ai #devops #troubleshooting
Есть такое устойчивое выражение
Описывает ситуацию, когда проблема была в другом.
- - -
Сидел вечером, ковырял документацию, чтобы догнать коллег по знаниям AI.
А то стал сильно отставать от них.
Курсор предлагает обновится, я соглашаюсь - ну а чо, вечер, казалось бы, что я могу поломать?
Он обновляется и тут ноут включает режим вертолёта: кулеры на взлёт, корпус тёплый, курсор дёргается.
M5, прости господи, топовое железо планеты, а ведёт себя так, будто я ему майнинг ферму на коленке запустил.
Ну, лезу в htop руками: кто это мне нагружает цпу сейчас.
(кто такие кланг? я вообще не в курсе)
Семьдесят три процесса clang и почти 800% CPU. То есть кто-то прямо сейчас яростно компилирует C++ всеми ядрами сразу. На моей машине. Которую я не просил ничего компилировать.
Дальше по дереву процессов:
Стартануло всё ровно в момент, когда я обновил Курсор.
Не понимаю какого хера вообще апдейт пошёл. Гуглю, читаю, теперь понятно.
Логично: апдейт, рестарт приложения, extension-host поднимает заново все включённые MCP-серверы.
А у меня их там зоопарк. Старые и новые, часть включённые, часть выключены.
Гипотеза номер один, неправильная.
Живым uvx в этот момент висел mcp-grafana, и палец сам потянулся к нему: вот же, Grafana MCP компилирует свои зависимости. Звучит правдоподобно.
Но привычка копать сработала. Проверяем зависимости пакета:
null. То есть у mcp-grafana вообще нет Python-зависимостей. Это сраный го-бинарь, завёрнутый в пип-пакет.
Ему компилировать нечего в принципе. Ну или я чего-то не знаю.
То есть я чуть не повесил вину на невиновного только потому, что он первым попался на глаза.
Обнуляю факты, копаю заново.
И вот тут честно: пока копал, гипотез было заметно больше, чем одна про grafana.
Большую часть я тут не расписываю, потому что они оказались пустышками и только сжирали время.
Просто список того, куда я успел сходить и что отмёл:
- какой-нибудь мой же зависший скрипт или забытый дев-сервер
- фоновая индексация и демоны самого курсор
- сраный докер-полупокер
- прилетевший с апдейтом фоновый апдейтер и его пост-инстал хук
- что это что-то из самого репозитория, terraform, pre-commit и компания
- майнер или малварь, ну а вдруг, паранойя должна быть здоровой
Ни одно не подтвердилось. Поэтому без разбора каждого, чтобы не растягивать.
Что компилировалось на самом деле. Смотрим, какой исходник жуёт clang, чем бы это не было:
Это grpcio. Из исходников, uv скачал sdist, а не колесо.
Под python3.14t. Сотни C/C++ файлов gRPC, вот откуда 70-110 процессов компилятора.
А кто его притащил. mcp-grafana мы исключили. Остаётся второй uvx-сервер в конфиге, opensearch-mcp-server-py. И вот тут вторая засада: прямой зависимости на grpcio у него тоже нет. Цепочка оказалась транзитивной, в три прыжка:
То есть свежий opensearch-py подтянул новый gRPC-транспорт (opensearch-protobufs), а тот тянет grpcio. И всё это в двух экземплярах сразу, потому что в конфиге у меня два opensearch-сервера:
Почему из исходников, а не готовое колесо(wheel). Вот ключевой нюанс, ради которого вся стори. Смотрим, какие колёса есть у grpcio 1.81.0 под Python 3.14:
Колёса под cp314 есть. Но все они cp314-cp314.
А у меня глобальный питон через asdf вот такой:
Да сука, откуда.
Есть такое устойчивое выражение
"дело было не в бобине"
Описывает ситуацию, когда проблема была в другом.
- - -
Сидел вечером, ковырял документацию, чтобы догнать коллег по знаниям AI.
А то стал сильно отставать от них.
Курсор предлагает обновится, я соглашаюсь - ну а чо, вечер, казалось бы, что я могу поломать?
Он обновляется и тут ноут включает режим вертолёта: кулеры на взлёт, корпус тёплый, курсор дёргается.
M5, прости господи, топовое железо планеты, а ведёт себя так, будто я ему майнинг ферму на коленке запустил.
Ну, лезу в htop руками: кто это мне нагружает цпу сейчас.
clang processes: 73, summed %CPU: 778.3
(кто такие кланг? я вообще не в курсе)
Семьдесят три процесса clang и почти 800% CPU. То есть кто-то прямо сейчас яростно компилирует C++ всеми ядрами сразу. На моей машине. Которую я не просил ничего компилировать.
Дальше по дереву процессов:
launchd
└─ Cursor.app (старт 10:02)
└─ Cursor Helper (Plugin): extension-host
└─ uv tool uvx ...
Стартануло всё ровно в момент, когда я обновил Курсор.
Не понимаю какого хера вообще апдейт пошёл. Гуглю, читаю, теперь понятно.
Логично: апдейт, рестарт приложения, extension-host поднимает заново все включённые MCP-серверы.
А у меня их там зоопарк. Старые и новые, часть включённые, часть выключены.
Гипотеза номер один, неправильная.
Живым uvx в этот момент висел mcp-grafana, и палец сам потянулся к нему: вот же, Grafana MCP компилирует свои зависимости. Звучит правдоподобно.
Но привычка копать сработала. Проверяем зависимости пакета:
jq -r '.info.requires_dist' mcp-grafana.json
null
null. То есть у mcp-grafana вообще нет Python-зависимостей. Это сраный го-бинарь, завёрнутый в пип-пакет.
Ему компилировать нечего в принципе. Ну или я чего-то не знаю.
То есть я чуть не повесил вину на невиновного только потому, что он первым попался на глаза.
Обнуляю факты, копаю заново.
И вот тут честно: пока копал, гипотез было заметно больше, чем одна про grafana.
Большую часть я тут не расписываю, потому что они оказались пустышками и только сжирали время.
Просто список того, куда я успел сходить и что отмёл:
- какой-нибудь мой же зависший скрипт или забытый дев-сервер
- фоновая индексация и демоны самого курсор
- сраный докер-полупокер
- прилетевший с апдейтом фоновый апдейтер и его пост-инстал хук
- что это что-то из самого репозитория, terraform, pre-commit и компания
- майнер или малварь, ну а вдруг, паранойя должна быть здоровой
Ни одно не подтвердилось. Поэтому без разбора каждого, чтобы не растягивать.
Что компилировалось на самом деле. Смотрим, какой исходник жуёт clang, чем бы это не было:
src/core/filter/fused_filters.cc
src/core/xds/grpc/xds_http_rbac_filter.cc
...
-DGRPC_PYTHON_BUILD=1
.../sdists-v9/pypi/grpcio/1.81.0/...
-I/Users/alexk/.asdf/installs/python/3.14.3t/include/python3.14t
Это grpcio. Из исходников, uv скачал sdist, а не колесо.
Под python3.14t. Сотни C/C++ файлов gRPC, вот откуда 70-110 процессов компилятора.
А кто его притащил. mcp-grafana мы исключили. Остаётся второй uvx-сервер в конфиге, opensearch-mcp-server-py. И вот тут вторая засада: прямой зависимости на grpcio у него тоже нет. Цепочка оказалась транзитивной, в три прыжка:
opensearch-mcp-server-py
└─ opensearch-py==3.1.0
└─ opensearch-protobufs==0.19.0
└─ grpcio>=1.68.1 → 1.81.0
То есть свежий opensearch-py подтянул новый gRPC-транспорт (opensearch-protobufs), а тот тянет grpcio. И всё это в двух экземплярах сразу, потому что в конфиге у меня два opensearch-сервера:
homelab и login.linode.com. Два параллельных билда grpcio. Привет, кулеры.Почему из исходников, а не готовое колесо(wheel). Вот ключевой нюанс, ради которого вся стори. Смотрим, какие колёса есть у grpcio 1.81.0 под Python 3.14:
grpcio-1.81.0-cp314-cp314-macosx_11_0_universal2.whl
grpcio-1.81.0-cp314-cp314-manylinux2014_aarch64.whl
...
Колёса под cp314 есть. Но все они cp314-cp314.
А у меня глобальный питон через asdf вот такой:
cat ~/.tool-versions
...
python 3.14.3t
Да сука, откуда.
🔥10👍3
#mcp #ai #devops #troubleshooting
Погулил что за буква t.
Буква t это free-threaded сборка, тот же Python, но без GIL. У неё другой ABI, cp314t. И колёс под cp314t у grpcio нет ни одного. Поэтому uv честно говорит, что готового бинаря под мой экзотический питон не завезли, и идёт собирать из исходников. На всех ядрах. Дважды.
Самое обидное: будь у меня обычный 3.14, взялось бы готовое колесо cp314 и ничего бы не грелось. Меня наказала именно free-threaded сборка, которую я когда-то поставил глобально. Когда и зачем именно её, я вспомнил не сразу, но к этому вернёмся в самом конце.
Лечение. Снёс нагрузку через pkill по билд-процессам, CPU сразу в ноль. Дальше, чтобы не повторялось, пинаю opensearch нормальный, не-free-threaded питон прямо в
Проверяем, что под 3.13 всё ставится из готовых колёс:
107 миллисекунд вместо двадцати минут компиляции. Ни одного clang.
Вот и вся разница между есть колесо под твой ABI и нет колеса под твой ABI.
Маленькая засада на сладкое. После того как я убил билд, курсор его тут же воскресил, но по старому конфигу, потому что новый mcp.json он ещё не перечитал. И я снова увидел компиляцию под 3.14t. Лечится тривиально: выключить-включить MCP-серверы в настройках Cursor или рестартнуть его, чтобы он подхватил python 3.13. После этого opensearch стартует на 3.13 мгновенно, кэш уже тёплый.
Первый подозреваемый, тот, что висит живым и на виду, почти никогда не виновник. mcp-grafana чуть не сел за чужое. Обнуляй факты и иди по цепочке зависимостей до конца.
Транзитивные зависимости умеют больно бить. Ты ставишь MCP для опенсёрча, а получаешь сборку gRPC из исходников через два промежуточных пакета, про которые ты даже не знал. Я вообще блять ничего не понимаю почему такая реализация.
Экзотика в окружении, free-threaded питон глобально, аукается там, где не ждёшь. ABI cp314t это не cp314, и весь мир пакетов, у которых нет колёс под no-GIL, начинает собираться из сорцов прямо у тебя на коленке.
Проблема найдена, объяснена на 100%, пофикшена и закрыта. Кулеры выдохнули.
Но остаётся ворпос: а откуда вообще взялся питон с буквой t.
Раз уж вся боль из-за free-threaded сборки, логичный вопрос: кто и когда вхерачил её мне глобально.
Тут я снова не стал гадать, а пошёл по следам в файловой системе и в истории шелла.
Дата рождения каталога сборки в asdf:
То есть поставлено 17 марта 2026, вечером. А кто. Да я же сам, руками, в своём терминале. Вот честный след из
Последовательность красивая: добавил плагин, поставил latest, а потом отдельной командой явно прибил глобально именно 3.14.3t. Буква t стоит прямо в команде, то есть это был осознанный выбор конкретной no-GIL сборки, а не случайный дефолт. И в asdf с тех пор так и живёт ровно одна версия питона, вот эта.
Почему? Да хер его знает, не удивлюсь, если это агент ставил, а я тупо копипастил.🦍
- - -
Так что же там у нас с бобиной?
А, ну да, там же есть полное продолжение.
Погулил что за буква t.
Буква t это free-threaded сборка, тот же Python, но без GIL. У неё другой ABI, cp314t. И колёс под cp314t у grpcio нет ни одного. Поэтому uv честно говорит, что готового бинаря под мой экзотический питон не завезли, и идёт собирать из исходников. На всех ядрах. Дважды.
Самое обидное: будь у меня обычный 3.14, взялось бы готовое колесо cp314 и ничего бы не грелось. Меня наказала именно free-threaded сборка, которую я когда-то поставил глобально. Когда и зачем именно её, я вспомнил не сразу, но к этому вернёмся в самом конце.
Лечение. Снёс нагрузку через pkill по билд-процессам, CPU сразу в ноль. Дальше, чтобы не повторялось, пинаю opensearch нормальный, не-free-threaded питон прямо в
~/.cursor/mcp.json:"opensearch-homelab": {
"command": "uvx",
"args": [
"--python", "3.13",
"opensearch-mcp-server-py"
],
...
}Проверяем, что под 3.13 всё ставится из готовых колёс:
uvx --python 3.13 --from opensearch-mcp-server-py python -c "import grpc; print(grpc.version)"
Downloaded grpcio
Installed 61 packages in 107ms
grpc 1.81.0 on 3.13.12
107 миллисекунд вместо двадцати минут компиляции. Ни одного clang.
Вот и вся разница между есть колесо под твой ABI и нет колеса под твой ABI.
Маленькая засада на сладкое. После того как я убил билд, курсор его тут же воскресил, но по старому конфигу, потому что новый mcp.json он ещё не перечитал. И я снова увидел компиляцию под 3.14t. Лечится тривиально: выключить-включить MCP-серверы в настройках Cursor или рестартнуть его, чтобы он подхватил python 3.13. После этого opensearch стартует на 3.13 мгновенно, кэш уже тёплый.
Первый подозреваемый, тот, что висит живым и на виду, почти никогда не виновник. mcp-grafana чуть не сел за чужое. Обнуляй факты и иди по цепочке зависимостей до конца.
Транзитивные зависимости умеют больно бить. Ты ставишь MCP для опенсёрча, а получаешь сборку gRPC из исходников через два промежуточных пакета, про которые ты даже не знал. Я вообще блять ничего не понимаю почему такая реализация.
Экзотика в окружении, free-threaded питон глобально, аукается там, где не ждёшь. ABI cp314t это не cp314, и весь мир пакетов, у которых нет колёс под no-GIL, начинает собираться из сорцов прямо у тебя на коленке.
Проблема найдена, объяснена на 100%, пофикшена и закрыта. Кулеры выдохнули.
Но остаётся ворпос: а откуда вообще взялся питон с буквой t.
Раз уж вся боль из-за free-threaded сборки, логичный вопрос: кто и когда вхерачил её мне глобально.
Тут я снова не стал гадать, а пошёл по следам в файловой системе и в истории шелла.
Дата рождения каталога сборки в asdf:
stat -f '%SB' ~/.asdf/installs/python/3.14.3t
Mar 17 20:56:52 2026
То есть поставлено 17 марта 2026, вечером. А кто. Да я же сам, руками, в своём терминале. Вот честный след из
~/.zsh_history того же вечера:asdf plugin add python
asdf install python latest
asdf global python latest
asdf set -u python 3.14.3t
Последовательность красивая: добавил плагин, поставил latest, а потом отдельной командой явно прибил глобально именно 3.14.3t. Буква t стоит прямо в команде, то есть это был осознанный выбор конкретной no-GIL сборки, а не случайный дефолт. И в asdf с тех пор так и живёт ровно одна версия питона, вот эта.
Почему? Да хер его знает, не удивлюсь, если это агент ставил, а я тупо копипастил.
- - -
Так что же там у нас с бобиной?
А, ну да, там же есть полное продолжение.
Мы сидели и вникали,
Разбирали, собирали,
Замеряли, вычисляли,
Днями, сутками, ночами.
Умножали и делили,
Выбирали "или-или",
Но машина всё ж не едет.
Что за козни? Что за бредни?
Мы по новой за расчёты:
Может, там у нас просчёты,
Может, что-то упустили,
Не нашли, не уследили...
Вдруг не то мы вычисляли
Днями, сутками, ночами.
Но машина вновь не едет,
Инженер наш главный бредит.
Снова мы на путь тернистый
Должен быть расчёт уж чистый.
Умножаем, вычисляем,
алгоритмы составляем.
Только было всё напрасно
Лишь потом нам стало ясно:
Дело было не в бобине
Долбоёб сидел в кабине.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁31👍4
#devops #ai
Захотел я тут поставить себе на новую железку локального агента.
Полуавтономного такого, для микрозадач.
Почитал что сейчас есть, посмотрел на модели, харнессы, потыкал всё мышкой. Остановился на Open Interpreter + Ollama + qwen3.5:9b.
Звучало просто, логично и работало в голове идеально.
Запустил установку.
Прошло 25 минут.
Висит, гнида. Начинаю разбираться.
Оказывается TUI завис на онбординге с пустым экраном и жрёт 98% CPU в бесконечном рендер-луп.🤡
Убил, запускаю снова, указываю модель.
Модель не найдена.
Потому что новый standalone использует опенаи респонс апи, который ollama не поддерживает.
Хорошо, ставлю питон-пакет.
Не собирается какой-то tiktoken - python 3.14 слишком новый для pyo3 0.20.3.
Переключаю на 3.12.
Устанавливается. Запускаю - запускается старый standalone из ~/.local/bin, который раньше в PATH. Да бл.
Убираю, запускаю снова.
Падает с pkg_resources not found.
Откатываю setuptools ниже 71 версии.
И так ещё полчаса-час сношений вприсядку в противогазе в гамаке.
В итоге заработало, фуф.
Отличный онбординг для тех, кто хочет в агенты, в первый раз питон и "просто попробовать".😀
Депенденси хелл на каждом шагу, три конфликта версий, два разных бинаря в PATH и одна пустая туи которая молча жрёт процессор.
Сделано збсь, ставлю класс.😬
Ладно, поныл и хватит.
Протестировал на самом деле я несколько локальных моделей, штук 15.
Ну что я могу сказать.
Для конкретно меня, конкретно моих задач, моих хотелок, моих требований и ожиданий.
- всё, что ниже 9В, выбрасывать в помойку
- 9B-30B вполне годный локальный автономный неторопливый агент для рутинных микро задач
- 30В+ потребляет слишком много ресурсов, где-то на грани "братаааан, а нужно ли тебе оно? может лучше сабскрипшн клауд за пять баксов в месяц?"
Выше не тестировал.
Пока оставил
Он, конечно, ну ннннннннникак не может сравниваться с любой облачной моделью, это просто бессмысленно даже думать о сравнении.
Для хоум фан-задач очень даже ок.
Потом поигрался с пи агентом и хермесом.
Без проблем не обошлось, так же депенденси хелл и проблемы с правами, но завелось.
Хермес для меня полная херня,в помойку для меня не подошёл.
Пи агент просто топ для интересных задач, очень понравилось.
Погонял полуавтономно несколько дней - ну ожидания совпали с реальностью.
Пока очень доволен.
Оба агента назвал Бабушка и Вахтёр.
Неторопливые, словно старички, но исправно делающие свою простую работу.
Кому делать нехер, вот ссылки:
- https://www.openinterpreter.com/docs/terminal/quickstart
- https://ollama.com/library/qwen3.5
- https://pi.dev/
- https://github.com/nousresearch/hermes-agent
Захотел я тут поставить себе на новую железку локального агента.
Полуавтономного такого, для микрозадач.
Почитал что сейчас есть, посмотрел на модели, харнессы, потыкал всё мышкой. Остановился на Open Interpreter + Ollama + qwen3.5:9b.
Звучало просто, логично и работало в голове идеально.
Запустил установку.
Прошло 25 минут.
Висит, гнида. Начинаю разбираться.
Оказывается TUI завис на онбординге с пустым экраном и жрёт 98% CPU в бесконечном рендер-луп.
Убил, запускаю снова, указываю модель.
Модель не найдена.
Потому что новый standalone использует опенаи респонс апи, который ollama не поддерживает.
Хорошо, ставлю питон-пакет.
Не собирается какой-то tiktoken - python 3.14 слишком новый для pyo3 0.20.3.
Переключаю на 3.12.
Устанавливается. Запускаю - запускается старый standalone из ~/.local/bin, который раньше в PATH. Да бл.
Убираю, запускаю снова.
Падает с pkg_resources not found.
Откатываю setuptools ниже 71 версии.
И так ещё полчаса-час сношений вприсядку в противогазе в гамаке.
В итоге заработало, фуф.
Отличный онбординг для тех, кто хочет в агенты, в первый раз питон и "просто попробовать".
Депенденси хелл на каждом шагу, три конфликта версий, два разных бинаря в PATH и одна пустая туи которая молча жрёт процессор.
Сделано збсь, ставлю класс.
Ладно, поныл и хватит.
Протестировал на самом деле я несколько локальных моделей, штук 15.
Ну что я могу сказать.
Для конкретно меня, конкретно моих задач, моих хотелок, моих требований и ожиданий.
- всё, что ниже 9В, выбрасывать в помойку
- 9B-30B вполне годный локальный автономный неторопливый агент для рутинных микро задач
- 30В+ потребляет слишком много ресурсов, где-то на грани "братаааан, а нужно ли тебе оно? может лучше сабскрипшн клауд за пять баксов в месяц?"
Выше не тестировал.
Пока оставил
qwen3.5:9b.Он, конечно, ну ннннннннникак не может сравниваться с любой облачной моделью, это просто бессмысленно даже думать о сравнении.
Для хоум фан-задач очень даже ок.
Потом поигрался с пи агентом и хермесом.
Без проблем не обошлось, так же депенденси хелл и проблемы с правами, но завелось.
Хермес для меня полная херня,
Пи агент просто топ для интересных задач, очень понравилось.
Погонял полуавтономно несколько дней - ну ожидания совпали с реальностью.
Пока очень доволен.
Оба агента назвал Бабушка и Вахтёр.
Неторопливые, словно старички, но исправно делающие свою простую работу.
Кому делать нехер, вот ссылки:
- https://www.openinterpreter.com/docs/terminal/quickstart
- https://ollama.com/library/qwen3.5
- https://pi.dev/
- https://github.com/nousresearch/hermes-agent
Please open Telegram to view this post
VIEW IN TELEGRAM
😁16👍5❤1
#всратость #devops #ai
Очередные размышления.
Везде и всюду "ИИ", агенты, и много "ИИ нейтив трансформаций".
Работодатель хочет многого, сокращает издержки, верит в автоматизацию, в несуществующий ИИ, а мы теперь трудимся за пятерых.
Ну вот это вот всё все итак знают.
Однако никто не рассказывает "а чо по процессам?".
Я чот не вижу, чтобы кто-то транформировал процессы.
Во всяком случае у нас на это забили болт, как мне кажется.
Пример:
прилетает девелопер, пишет "не работает релиз в прод".
Стоп. Не так.
А, мы ж теперь ЗА ИИ ТРАНСФОРМАЦИЮ!
пу-пу-пу
а никто не отвечает
тадам
Бл, ну камон.
Два девопса* два часа решают проблему протухшего токена, ну камон.🤡 🤡
Итого: 6 минут на диагностику, 2 часа на согласование токена, 4 часа невозможности задеплоить релиз от момента обнаружения проблемы до фикса.
Много вопросов, мало ответов**:
- почему сразу не дать право создавать деплой/сервис-аккаунт с токеном? В чём проблема? Чем помогает такой вахтеризм?
- в чём проблема быстро выдать PAT на 7 дней с техдолгом переделки вместо двух часов пинг-понга? Мы прод, бл, чиним, алё, ребята.
- мы всё автоматизируем, но час можем не отвечать в слаке. Кто тогда отвечает за аптайм?
- где алерт на экспайред токенов? Где борда?
ИИ инструменты реально помогают
- диагноз за 6 минут это предел мечтаний пару лет назад
- красивенькие понятные сообщения в слаке, чтобы любой быстро понял суть треда
Однако никакой клодкод и ИИ трансофрмация не заменит нормальные процессы , в том числе сакральные тайны ротации секретов и понятную матрицу доступов.
Никакой ИИ не поможет, если час нет ответа.
Пока этого нет – AI трансформация это просто новая обёртка поверх старого бардака.
Мы ускорили всё, кроме принятия простейших, сука, решений.
Мы сделали ответы красивее, но не быстрее.
Мы автоматизировали действия, но не договорённости.
И пока это так - мы ни-хе-ра не становимся эффективнее.
Мы просто делаем тот же самый бардак, только быстрее, дороже и с более красивыми лозунгами.
- - -
* Я девопс на отдельных проектах, есть лишь часть прав.
А есть эээ я хз как называется, ну пусть будут Глобальные девопсы, они и гитлабом управляют и рутом организаций в амазоне/ажуре и многое другое.
Права нам дают как утяткам, не понимаю в чём смысл, если честно.
** все претензии только к процессам, а не к девопсам.
Свою роль в этом бардаке я так же чётко вижу, как и многие слабые места.
Очередные размышления.
Мы автоматизировали общение и написание кода, но не процессы
Везде и всюду "ИИ", агенты, и много "ИИ нейтив трансформаций".
Работодатель хочет многого, сокращает издержки, верит в автоматизацию, в несуществующий ИИ, а мы теперь трудимся за пятерых.
Ну вот это вот всё все итак знают.
Однако никто не рассказывает "а чо по процессам?".
Я чот не вижу, чтобы кто-то транформировал процессы.
Во всяком случае у нас на это забили болт, как мне кажется.
Пример:
прилетает девелопер, пишет "не работает релиз в прод".
Стоп. Не так.
А, мы ж теперь ЗА ИИ ТРАНСФОРМАЦИЮ!
12:28 прилетает мне в слак сообщение, клодом написанное, с красивым форматированием и полной подробной информацией, что перестал работать релиз в прод. С путями, текстом ошибки, предполагаемой проблемой. 12:35 мой агент агента агента агентный агент пишет в ответ "Спасибо за обращение! сейчас вернусь с обеда! Сделаю!" обратно в слак.пу-пу-пу
13:22 возвращаюсь к лэптопу, ныряю в проблему при помощи Claude code ненаглядного, запускаю несколько mcp и cli tools, дергаю там skills, получаю reports - все по ии-трансформационному!13:28 понимаю суть проблемы с пруфами: argocd не может синкнуть git репозиторий - протух токен, при помощи которого он обращается для гит пулл синка13:36 при помощи клода пишу и отправляю не менее красивое отформатированное сообщение в слак канал для девопс команды "парни, проверьте, плиз, в этом проекте/группе есть ли деплой токены? не протухло ли чего?" - планируя, что следующим вопросом попрошу просто рефрешнутьа никто не отвечает
13:41 агентный агент пингует devops duty дежурного в треде "хелп спасити памагити"13:52 девопс отвечает мне, что "PAT у нас почти год уже нет, токенов у тебя тут нет"13:53 агент быстро делает ресёрч, говорит пойдем посмотрим что за токен, иду в волт сам, копирую токен - а там, мать его, glpat- и правда персональный токен. Ну, вероятно, кто-то это сделал год назад, пока было разрешено и это попало в прод и так работало год".14:04 сам пишу девопсу "можешь ли ты создать токен новый?"14:08 получаю ответ "мы не создаем/менеджим токены, расскажи свою боль и мы поможем тебе"14:13 пилю кулстори с подробным пояснением, что тупо токен протух и все подробности проекта/путей и тптадам
15:24 отвечают мне, что могут запилить ssh key, есть ли у нас сервис аккаунт?15:25 разбираюсь чо там настроено (я не основной инженер на этом проекте)15:35 честно отвечаю, что меня устроит любой ПРОСТОЙ и БЫСТРЫЙ вариант без переделок, вообще любой вариант устроит, хоть деплой токен на 7 дней - за неделю успею переделать все нормально по любым вашим требованиям, мне лишь бы прод поднять15:41 мне делают деплой токен - с временем протухания, а так же сервис аккаунт без времени протухания и кладут логин/токен в Vault. Два варианта - что первое подойдёт.15:42 я руками, не доверяя агенту, делаю патч externalsecret, добавляя туда новый логин и новый путь до токена, дергаю форс-рефреш экстерналсекрет, патчу арго аппликейшн на ре-синк - всё руками в терминале15:45 - сервис задеплоен, проблемы нет, синк работает15:46 - агентном создаю в беклог таску, чтобы терра модуль аргошки поменять на новый формат логина/пароля с новыми путями в волтеБл, ну камон.
Два девопса* два часа решают проблему протухшего токена, ну камон.
Итого: 6 минут на диагностику, 2 часа на согласование токена, 4 часа невозможности задеплоить релиз от момента обнаружения проблемы до фикса.
Много вопросов, мало ответов**:
- почему сразу не дать право создавать деплой/сервис-аккаунт с токеном? В чём проблема? Чем помогает такой вахтеризм?
- в чём проблема быстро выдать PAT на 7 дней с техдолгом переделки вместо двух часов пинг-понга? Мы прод, бл, чиним, алё, ребята.
- мы всё автоматизируем, но час можем не отвечать в слаке. Кто тогда отвечает за аптайм?
- где алерт на экспайред токенов? Где борда?
ИИ инструменты реально помогают
- диагноз за 6 минут это предел мечтаний пару лет назад
- красивенькие понятные сообщения в слаке, чтобы любой быстро понял суть треда
Однако никакой клодкод и ИИ трансофрмация не заменит нормальные процессы , в том числе сакральные тайны ротации секретов и понятную матрицу доступов.
Никакой ИИ не поможет, если час нет ответа.
Пока этого нет – AI трансформация это просто новая обёртка поверх старого бардака.
Мы ускорили всё, кроме принятия простейших, сука, решений.
Мы сделали ответы красивее, но не быстрее.
Мы автоматизировали действия, но не договорённости.
И пока это так - мы ни-хе-ра не становимся эффективнее.
Мы просто делаем тот же самый бардак, только быстрее, дороже и с более красивыми лозунгами.
- - -
* Я девопс на отдельных проектах, есть лишь часть прав.
А есть эээ я хз как называется, ну пусть будут Глобальные девопсы, они и гитлабом управляют и рутом организаций в амазоне/ажуре и многое другое.
Права нам дают как утяткам, не понимаю в чём смысл, если честно.
** все претензии только к процессам, а не к девопсам.
Свою роль в этом бардаке я так же чётко вижу, как и многие слабые места.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤14💯7👍3
#apple #devops #tools и снова #всратость
Не так давно я пересел на новые для себя вещи:
- раздельная клавиатура (там ничего нового, минимальные различия с обычной клавиатурой)
- для редких случаев отдельный magic touchpad
- макбук
- дополнительный большой монитор
Потому все свои рабочие процессы строю по принципу "не трогать тачпад, минимум движений". Учу много шоткатов. Пока не всё получается.
Между тем считаю, что операционная система Тахо весьма ужасна.
К сожалению в макбуке нет многих очевидных вещей, которые хотелось бы видеть.
Каждый раз надо что-то менять в настройках через терминал, то ставить какие-то утилиты.
Работа с окошками -
Биндинг клавиш -
Менеджер пакетов -
Ланчеры типа
Ну и так далее, ну в общем штатно мак ну не совсем готов для работы инженера.
И так я привык к этому, что изначально воспринимал, что "в маке многого нет".😬
Идём к моей микрозадачке.
Все стандартные шоткаты всем известны:
- command+tab - между самими программами
- ctrl+tab - между табами внутри программы
А вот если, например, открыто несколько VSCode или несколько окон браузера Кром - такой комбинации нет.
Мишн контрол тут мне просто не очень подходит с дополнительным монитором.
Мне сперва показалось "да кому это надо", но нет, у меня несколько окон браузера открыто - от MCP Developer Tools для разработки до браузера для себя. Редактор кода - под каждую репу (да, иногда мне так удобнее, чем флипать воркспейсы). Такая же фигня с terminal раньше была (сейчас с
Что сделал я? Конечно же спросил какую-то нейронку (не помню уже кто) - какая есть для моей задачи утилита?🤡
Нейронка честно выполнила свою работу и сказала, что есть крутой проект -
Они взяли и навайбкодили (я уверен) новый продукт.
- https://getreef.app/ (тут попросят денежку, но можно поставить 0)
- https://github.com/gouwsxander/reef (сразу бесплатный архив)
Не пересекаются по логике и хоткеяи с ректанглом.
В общем одни плюсы.
Как это работает:
- просто качаешь и ставишь программу
- затем в самой программе биндишь цифру 0, например, на VSCode
- открываешь свои 15 VSCode
- жмёшь ctrl+0
- появляется прозрачное окно посредине экрана и выбираешь нужный экземпляр
- всё
Я недаром говорил, что это "навайбкожено", потому как оно не свичится, если один экземпляр Кром браузера открыт на фуллскрин, а второй нет, но там решается через другие шоткаты и меня это не аффектит.
Подходит только и исключительно для тех, кто одновременно запускает несколько копий браузера/терминала/редактора кода и не хочет прикасаться к тачпаду.
Сижу, значит, уже почти привык к новой утилите и работе, решил затащить статью для моих читателей.
Пишу всё это и думаю, а что у них ещё есть.
Поиск выдал замечательный ролик на ютубе, с чего всё начиналось.
Где, собственно, у автора такие же мысли/проблемы возникли с окошками
https://www.youtube.com/watch?v=niRCi5zJvHU
Думаю вложу-ка я его в этот пост, так как стараюсь каждый раз при каждой публикации, чтобы было интересно.
И тут мои глаза цепляют комменты к видео..
Господи, стыд-то какой.🤡 🤡 🤡 🤡 🤡
Оказывается всё в маке есть для этой задачи.
- command + ` (ноут из Германии, на США раскладке вроде command + >)
- ctrl + стрелка вниз
Прикиньте какая унас меня сейчас деградация.
- двое ребят пилят целое приложение, потому, что не захотели ПОГУГЛИТЬ блд
- я, пользуюсь ответами нейронки по изначально неверно составленному запросу (утилита, а не нативный шоткат), ставлю этот софт и занимаюсь никому не нужной настройкой.
Ну не жопа ли.
Да, конкретно их софт поможет, если открыто 50+ программ с 10+ реплик каждый, но у меня такой задачи и не стоит, лол, мне между 2-3 флапаться.
Ну или нужен строгий альттаб шоткат на конкретное приложение.
Потому пока себе его оставил, вдруг для некоторых случаев нужно будет😬
Что наш ждёт через лет пять..🫣
- - -
Кстати само видео - интересное, слушать чужие размышления при разработке и проблемах это классно.
Деградация и вайбкодинг.
Не так давно я пересел на новые для себя вещи:
- раздельная клавиатура (там ничего нового, минимальные различия с обычной клавиатурой)
- для редких случаев отдельный magic touchpad
- макбук
- дополнительный большой монитор
Потому все свои рабочие процессы строю по принципу "не трогать тачпад, минимум движений". Учу много шоткатов. Пока не всё получается.
Между тем считаю, что операционная система Тахо весьма ужасна.
К сожалению в макбуке нет многих очевидных вещей, которые хотелось бы видеть.
Каждый раз надо что-то менять в настройках через терминал, то ставить какие-то утилиты.
Работа с окошками -
rectangle. Биндинг клавиш -
Karabiner-Elements. Особенно спасает с проклятыми раскладками в ЕС (Германия).Менеджер пакетов -
Homebrew.Ланчеры типа
Raycast. Ну и так далее, ну в общем штатно мак ну не совсем готов для работы инженера.
И так я привык к этому, что изначально воспринимал, что "в маке многого нет".
Идём к моей микрозадачке.
Все стандартные шоткаты всем известны:
- command+tab - между самими программами
- ctrl+tab - между табами внутри программы
А вот если, например, открыто несколько VSCode или несколько окон браузера Кром - такой комбинации нет.
Мишн контрол тут мне просто не очень подходит с дополнительным монитором.
Мне сперва показалось "да кому это надо", но нет, у меня несколько окон браузера открыто - от MCP Developer Tools для разработки до браузера для себя. Редактор кода - под каждую репу (да, иногда мне так удобнее, чем флипать воркспейсы). Такая же фигня с terminal раньше была (сейчас с
cmux неактуально).Что сделал я? Конечно же спросил какую-то нейронку (не помню уже кто) - какая есть для моей задачи утилита?
Нейронка честно выполнила свою работу и сказала, что есть крутой проект -
reef.Они взяли и навайбкодили (я уверен) новый продукт.
- https://getreef.app/ (тут попросят денежку, но можно поставить 0)
- https://github.com/gouwsxander/reef (сразу бесплатный архив)
Не пересекаются по логике и хоткеяи с ректанглом.
В общем одни плюсы.
Как это работает:
- просто качаешь и ставишь программу
- затем в самой программе биндишь цифру 0, например, на VSCode
- открываешь свои 15 VSCode
- жмёшь ctrl+0
- появляется прозрачное окно посредине экрана и выбираешь нужный экземпляр
- всё
Я недаром говорил, что это "навайбкожено", потому как оно не свичится, если один экземпляр Кром браузера открыт на фуллскрин, а второй нет, но там решается через другие шоткаты и меня это не аффектит.
Подходит только и исключительно для тех, кто одновременно запускает несколько копий браузера/терминала/редактора кода и не хочет прикасаться к тачпаду.
Сижу, значит, уже почти привык к новой утилите и работе, решил затащить статью для моих читателей.
Пишу всё это и думаю, а что у них ещё есть.
Поиск выдал замечательный ролик на ютубе, с чего всё начиналось.
Где, собственно, у автора такие же мысли/проблемы возникли с окошками
https://www.youtube.com/watch?v=niRCi5zJvHU
Думаю вложу-ка я его в этот пост, так как стараюсь каждый раз при каждой публикации, чтобы было интересно.
И тут мои глаза цепляют комменты к видео..
Господи, стыд-то какой.
Оказывается всё в маке есть для этой задачи.
- command + ` (ноут из Германии, на США раскладке вроде command + >)
- ctrl + стрелка вниз
Прикиньте какая у
- двое ребят пилят целое приложение, потому, что не захотели ПОГУГЛИТЬ блд
- я, пользуюсь ответами нейронки по изначально неверно составленному запросу (утилита, а не нативный шоткат), ставлю этот софт и занимаюсь никому не нужной настройкой.
Ну не жопа ли.
Да, конкретно их софт поможет, если открыто 50+ программ с 10+ реплик каждый, но у меня такой задачи и не стоит, лол, мне между 2-3 флапаться.
Ну или нужен строгий альттаб шоткат на конкретное приложение.
Потому пока себе его оставил, вдруг для некоторых случаев нужно будет
Что наш ждёт через лет пять..
- - -
Кстати само видео - интересное, слушать чужие размышления при разработке и проблемах это классно.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁29
#devops #troubleshooting #opensource
Понадобилось мне тут на работе проверить есть ли троттлинг ЦПУ.
Причём без создания, тупо взять квери, проверить в explore на графане с датасорса виктории метрикс и всё.
Это новый проект, там ещё обсервабилити не готов, мне чисто проверить.
Зашёл я на свой любимый сайт, откудапиз ворую алерты
https://samber.github.io/awesome-prometheus-alerts/rules/
А там красота - всё зарефактили, всё по-другому.
Зашёл в раздел кубера - а там этого алерта нет.
Command+f тоже не находит по ключевым словам.
Поискал на главной - тоже нет.
Самая большая тупость рефакторинга - нет поля для поиска по сайту.🚬
Это же опенсорс, а давай я это заклонирую, это быстрее, чем искать другие ресурсы.
Клонирую гит репо, ищу поиском - нахожу.
Во-первых, там теперь там теперь рейт вместо инкрис,во-вторых, добавили проверку деления на ноль и в-третьих перенесли в раздел Кадвизор.
Хм, в целом логично, хер ли я в кубере его искал.
Ок, взял квери - проверил на работе по задаче - всё ок, троттлинга не было.
И тут мне стало интересно, а чо поиск не показывал? Чего поиска нет на сайте.
С плейврайт я уже работал, а теперь захотелось поработать с аддоном для браузера Крома.
https://github.com/ChromeDevTools/chrome-devtools-mcp
В конфиге MCP серверов это всё выглядит просто
Со стороны браузера Кром надо просто галочку включить
Как это работает в двух словах:
- запускаю клодкод в терминале
- прошу чот проверить/поменять
- включаю галочку дебаггинга в браузере
- клод спрашивает разрешения, открывает либо отдельную сессию/профиль браузера, либо в моей же сессии (смотря как настроить!!!). У меня это отдельная сессия-профиль, Он открывает вкладку, спрашивает разрешение на управление браузером и работает
- сам через нативный developers tools видит ошибки в консоли, в нетворкинге, латенси запросов, все url бэкенда и всё!
- делает виртуальные скриншоты, ищет поля, и исправляет поля
- он буквально за меня кликает все элементы страницы и видит весь дебаг
- галочку потом можно снять для успокоения паранойи
Буквально за минуты получаю ответ, что "а тут херово навайбкожено в слоях провалился поиск😎 ", пилю исправление, прошу нейронку проверить исправление, проверяется так же через девелопертулс. Потом ещё сам проверяю - поиск работает, несчастный троттлинг показывает, даже по всем разделам. Ого, у опенсерч тоже есть троттлинг.
Прошу запилить МР на гитхаб с минимальнейшими исправлениями и скриншотами "до/после".
https://github.com/samber/awesome-prometheus-alerts/pull/590
На выходных автор смержил, правда потом поправил поиск - не в центре экрана, а аккуратнее в углу справа.
Итоги:
- поправить простые(!) фронт штуки с помощью нейронки, Кром браузера и мсп девелоперс тулс - достаточно легко в 2026. QA, фронтенд - тут не нужны😢 , можно самому делать мелкие исправления БАГОВ. Фичи пилить я бы не решился.
- по токенам подобные мелкие штуки недорогие - специально посчитал, около 7000 токенов вышло
- девелопертулс мне понравился больше, для дебаггинга он прям топ
- для СЕБЯ(!) я определил так:
- - - https://playwright.dev - автоматизированные тесты, кросс браузеры
- - - https://github.com/ChromeDevTools/chrome-devtools-mcp - сила в дебаггинге нативного девелоперс тулс
Это похожие, на первый взгляд, инструменты, но с разными задачами как по мне.
- а, ну да, теперь на сайте снова можно юзать поиск и воровать алерты🤡
Понадобилось мне тут на работе проверить есть ли троттлинг ЦПУ.
Причём без создания, тупо взять квери, проверить в explore на графане с датасорса виктории метрикс и всё.
Это новый проект, там ещё обсервабилити не готов, мне чисто проверить.
Зашёл я на свой любимый сайт, откуда
https://samber.github.io/awesome-prometheus-alerts/rules/
А там красота - всё зарефактили, всё по-другому.
Зашёл в раздел кубера - а там этого алерта нет.
Command+f тоже не находит по ключевым словам.
Поискал на главной - тоже нет.
Самая большая тупость рефакторинга - нет поля для поиска по сайту.
Это же опенсорс, а давай я это заклонирую, это быстрее, чем искать другие ресурсы.
Клонирую гит репо, ищу поиском - нахожу.
Во-первых, там теперь там теперь рейт вместо инкрис,во-вторых, добавили проверку деления на ноль и в-третьих перенесли в раздел Кадвизор.
Хм, в целом логично, хер ли я в кубере его искал.
Ок, взял квери - проверил на работе по задаче - всё ок, троттлинга не было.
И тут мне стало интересно, а чо поиск не показывал? Чего поиска нет на сайте.
С плейврайт я уже работал, а теперь захотелось поработать с аддоном для браузера Крома.
https://github.com/ChromeDevTools/chrome-devtools-mcp
В конфиге MCP серверов это всё выглядит просто
},
"chrome-devtools-my": {
"command": "npx",
"args": [
"-y",
"chrome-devtools-mcp@latest",
"--autoConnect"
]
}
Со стороны браузера Кром надо просто галочку включить
chrome://inspect/#remote-debugging
Как это работает в двух словах:
- запускаю клодкод в терминале
- прошу чот проверить/поменять
- включаю галочку дебаггинга в браузере
- клод спрашивает разрешения, открывает либо отдельную сессию/профиль браузера, либо в моей же сессии (смотря как настроить!!!). У меня это отдельная сессия-профиль, Он открывает вкладку, спрашивает разрешение на управление браузером и работает
- сам через нативный developers tools видит ошибки в консоли, в нетворкинге, латенси запросов, все url бэкенда и всё!
- делает виртуальные скриншоты, ищет поля, и исправляет поля
- он буквально за меня кликает все элементы страницы и видит весь дебаг
- галочку потом можно снять для успокоения паранойи
Буквально за минуты получаю ответ, что "а тут херово навайбкожено в слоях провалился поиск
Прошу запилить МР на гитхаб с минимальнейшими исправлениями и скриншотами "до/после".
https://github.com/samber/awesome-prometheus-alerts/pull/590
На выходных автор смержил, правда потом поправил поиск - не в центре экрана, а аккуратнее в углу справа.
Итоги:
- поправить простые(!) фронт штуки с помощью нейронки, Кром браузера и мсп девелоперс тулс - достаточно легко в 2026. QA, фронтенд - тут не нужны
- по токенам подобные мелкие штуки недорогие - специально посчитал, около 7000 токенов вышло
- девелопертулс мне понравился больше, для дебаггинга он прям топ
- для СЕБЯ(!) я определил так:
- - - https://playwright.dev - автоматизированные тесты, кросс браузеры
- - - https://github.com/ChromeDevTools/chrome-devtools-mcp - сила в дебаггинге нативного девелоперс тулс
Это похожие, на первый взгляд, инструменты, но с разными задачами как по мне.
- а, ну да, теперь на сайте снова можно юзать поиск и воровать алерты
Please open Telegram to view this post
VIEW IN TELEGRAM
🥰14🔥3👍2🤡1
#devops #troubleshooting #база #одинденьизжизни
Иногда появляются проблемы, которые нельзя быстро решить.
Они неожиданные и вступаешь в ступор "а как какать?".
У нас много подключенных SaaS и интеграций.
Время от времени приходят разные коллеги и просят добавить/обновить DNS записи.
Например интеграция с каким-нибудь
В основном задача состоит из двух типов записи:
- добавить новый
- обновить существующий
В общем-то ничего сложного,
Стек на тераформе и легко пилю MR, где добавляю, получаю аппрув, качу в мейн и ..а всё отлично, какие ещё и.
Спустя время прибегают сейлзы/саппорт с большими глазами, говорят не доходят часть почты, а это критикал.
🔥 🔥 🔥
Бежишь смотришь пайплайн - всё ок, тераформ всё раскатал, валидация прошла, все чеки тоже прошли - всё чисто.
Ну магии не существует, пошли на https://mxtoolbox.com/
Пацаны не даром свою зарплату получают (в отличии от меня, лол), и сайт показывает ошибки нарушения контракта.😞
Ошибка, что адресов уже много и пррривет,
Дальнейший поиск меня приводит к неизвестному мне ранее
https://datatracker.ietf.org/doc/html/rfc7208
Оказывается есть лимиты и тут. Сука.
RFC 7208 (спека на SPF) прямо говорит: суммарно можно использовать не больше 10 механизмов, которые дёргают DNS - include, a, mx, ptr, exists, redirect.
И считается это не построчно, а рекурсивно - если внутри одного include спрятан ещё include, он тоже идёт в зачёт. Круто, да? Я сам в охере.
То есть в самой записи можно хоть 100 include понаписать - терраформ смолчит, все валидации пройдут, все провайдеры (клаудфлер в данном случае) скажут ок, MR смержится, ревьюер поставит approve, всё ок. Даже на клаудфлер появится. А хлебнёшь ложку говна уже на проверке письма: получатель досчитывает до 10го lookup и такой "аригато, дальше не считаю" - permerror. Причём не сразу и не у всех - где-то письма улетают в спам, где-то тихо дропаются. Полный рандом, сука. Предполагаю из-за разных политик корректных МТА.
Ок, причину мы нашли, быстро ревертаем коммит, проверяем через https://mxtoolbox.com/ и нам показывают, что всё хорошо.
Ок, мы вернули как было, успокаиваем продажников и саппорт и думаем - "а как быть дальше?" Задачу надо решить.
Вот так сходу есть две мысли
- узнать каким-то образом - все те SPF записи в TXT нужны ли нам - не можем ли мы что-то удалить, чтобы добавить нужное?😏
- как-то эээ по сабдоменам уровнем ниже разнести записи, ну типа того
Слава вселенной - всё в гите и можно узнать по каждому добавлению SPF кто и когда добавлял. Есть название таски, автор. Идём в личку в слак всем людям, спрашиваем "а эта запись ещё нужна? Модем ли мы дропнуть или ещё используем?".
К счастью в этом случае нашли 1 запись, которая 100% не нужна и больше не используется, дропнули её и добавили новую по задаче.
Как быть при следующем добавлении следующей SPF записи и все они нужны?
А хз, я там уже не работаю😬
Я и правда честно - не знаю, варианты те же в голове:
- развести интеграции по поддоменам со своим SPF (типа mail.PARTNER.SOMEDOMAIN.СOM), а не тащить всё в основной домен
Тогда, предполагаю, каждый поддомен считает свои 10, а не делит один лимит на всех, но это надо проверять.
- завести привычку прогонять запись через mxtoolbox перед каждым новым includ
- тупорылые танцы со статикой IP, но это статика, шанс инцидента при смене адреса возрастает в 10 раз
Итоги:
- иногда подстава откуда не ждёшь, никакие штатные валидаторы тебе не покажут потенциальную ошибку. В этом случае нам даже впаяли инцидент😔
- RFC это боль, сколько раз я уже в своей практике упирался в какие-либо лимиты
- если бы не гит-блейм по таскам - чистили бы SPF вслепую.
Инвестируй в IAC - трейсинг "кто и зачем добавил" окупается на все 100% ровно в такие моменты. Git+IaC=❤️
и да, иногда никакого куберентиса😀
Иногда появляются проблемы, которые нельзя быстро решить.
Они неожиданные и вступаешь в ступор "а как какать?".
У нас много подключенных SaaS и интеграций.
Время от времени приходят разные коллеги и просят добавить/обновить DNS записи.
Например интеграция с каким-нибудь
chargebee или hubspot чем бы это не было. Да тысячи их, я даже не знаю чо они делают.В основном задача состоит из двух типов записи:
- добавить новый
CNAME_E2E2BURMALDADZHIGURDA SOMEDOMAIN.COM- обновить существующий
TXT добавив туда новый хост"v=spf1 include:outlook.com include:hubspotemail.net include:chargebee.com ~all\""В общем-то ничего сложного,
Стек на тераформе и легко пилю MR, где добавляю, получаю аппрув, качу в мейн и ..а всё отлично, какие ещё и.
Спустя время прибегают сейлзы/саппорт с большими глазами, говорят не доходят часть почты, а это критикал.
Бежишь смотришь пайплайн - всё ок, тераформ всё раскатал, валидация прошла, все чеки тоже прошли - всё чисто.
nslookup, dig - базовые привычные команды проверки показывают, что всё ок.Ну магии не существует, пошли на https://mxtoolbox.com/
Пацаны не даром свою зарплату получают (в отличии от меня, лол), и сайт показывает ошибки нарушения контракта.
Ошибка, что адресов уже много и пррривет,
RFC, и его лимиты.Дальнейший поиск меня приводит к неизвестному мне ранее
https://datatracker.ietf.org/doc/html/rfc7208
Оказывается есть лимиты и тут. Сука.
RFC 7208 (спека на SPF) прямо говорит: суммарно можно использовать не больше 10 механизмов, которые дёргают DNS - include, a, mx, ptr, exists, redirect.
И считается это не построчно, а рекурсивно - если внутри одного include спрятан ещё include, он тоже идёт в зачёт. Круто, да? Я сам в охере.
То есть в самой записи можно хоть 100 include понаписать - терраформ смолчит, все валидации пройдут, все провайдеры (клаудфлер в данном случае) скажут ок, MR смержится, ревьюер поставит approve, всё ок. Даже на клаудфлер появится. А хлебнёшь ложку говна уже на проверке письма: получатель досчитывает до 10го lookup и такой "аригато, дальше не считаю" - permerror. Причём не сразу и не у всех - где-то письма улетают в спам, где-то тихо дропаются. Полный рандом, сука. Предполагаю из-за разных политик корректных МТА.
Ок, причину мы нашли, быстро ревертаем коммит, проверяем через https://mxtoolbox.com/ и нам показывают, что всё хорошо.
Ок, мы вернули как было, успокаиваем продажников и саппорт и думаем - "а как быть дальше?" Задачу надо решить.
Вот так сходу есть две мысли
- узнать каким-то образом - все те SPF записи в TXT нужны ли нам - не можем ли мы что-то удалить, чтобы добавить нужное?
- как-то эээ по сабдоменам уровнем ниже разнести записи, ну типа того
Слава вселенной - всё в гите и можно узнать по каждому добавлению SPF кто и когда добавлял. Есть название таски, автор. Идём в личку в слак всем людям, спрашиваем "а эта запись ещё нужна? Модем ли мы дропнуть или ещё используем?".
К счастью в этом случае нашли 1 запись, которая 100% не нужна и больше не используется, дропнули её и добавили новую по задаче.
Как быть при следующем добавлении следующей SPF записи и все они нужны?
А хз, я там уже не работаю
Я и правда честно - не знаю, варианты те же в голове:
- развести интеграции по поддоменам со своим SPF (типа mail.PARTNER.SOMEDOMAIN.СOM), а не тащить всё в основной домен
Тогда, предполагаю, каждый поддомен считает свои 10, а не делит один лимит на всех, но это надо проверять.
- завести привычку прогонять запись через mxtoolbox перед каждым новым includ
- тупорылые танцы со статикой IP, но это статика, шанс инцидента при смене адреса возрастает в 10 раз
Итоги:
- иногда подстава откуда не ждёшь, никакие штатные валидаторы тебе не покажут потенциальную ошибку. В этом случае нам даже впаяли инцидент
- RFC это боль, сколько раз я уже в своей практике упирался в какие-либо лимиты
- если бы не гит-блейм по таскам - чистили бы SPF вслепую.
Инвестируй в IAC - трейсинг "кто и зачем добавил" окупается на все 100% ровно в такие моменты. Git+IaC=
и да, иногда никакого куберентиса
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16❤6👍4
#ai #devops
Раз в 2-3 недели гоняю команду
в claude code.
Она парсит все мои сессии за последние дни и выкатывает наглядный html-отчёт без лишней воды: сильные стороны, где я реально эффективен, где просаживаюсь, что можно заавтоматизировать, какие бэд-практисы проскакивают.
Отдельно подскажет, чем обогатить CLAUDE.md, как лучше структурировать контекст, где утекают токены и время, и какие паттерны повторяются из сессии в сессию, какие скиллы новые запилить на повторяющиеся задачи.
Научит новым промптам.
Подсветит боли и фрустрации как на скрине😀 .
Смотрю, где стал лучше, где наоборот деградировал, и по итогу подкручиваю промпты, сетап и подход к работе.
Реально держит систему в тонусе, а не работу по инерции.
Если с английским не очень - гугл-переводчик отчёт нормально осилит.
Рекомендация - 10 из 10.
Для кодекса и курсора есть НЕ нативные аналоги, но я сам их не тестировал, лишь видел в чатах обсуждение:
- https://github.com/tim-hilde/opencode-insights
- https://github.com/rapidrabbit76/OpenCodeInsights
- - -
Всегда стрёмно такое постить - сейчас вокруг все дохера умные, что ни напиши - "я и так знаю".😬
А простейшая нативная фича - никто не в курсе среди моих знакомых (на работе, я уверен, все в курсе).
Тонкая грань между "база-базная" и "о, а я не знал"🦍
Раз в 2-3 недели гоняю команду
/insights в claude code.
Она парсит все мои сессии за последние дни и выкатывает наглядный html-отчёт без лишней воды: сильные стороны, где я реально эффективен, где просаживаюсь, что можно заавтоматизировать, какие бэд-практисы проскакивают.
Отдельно подскажет, чем обогатить CLAUDE.md, как лучше структурировать контекст, где утекают токены и время, и какие паттерны повторяются из сессии в сессию, какие скиллы новые запилить на повторяющиеся задачи.
Научит новым промптам.
Подсветит боли и фрустрации как на скрине
Смотрю, где стал лучше, где наоборот деградировал, и по итогу подкручиваю промпты, сетап и подход к работе.
Реально держит систему в тонусе, а не работу по инерции.
Если с английским не очень - гугл-переводчик отчёт нормально осилит.
Рекомендация - 10 из 10.
Для кодекса и курсора есть НЕ нативные аналоги, но я сам их не тестировал, лишь видел в чатах обсуждение:
- https://github.com/tim-hilde/opencode-insights
- https://github.com/rapidrabbit76/OpenCodeInsights
- - -
Всегда стрёмно такое постить - сейчас вокруг все дохера умные, что ни напиши - "я и так знаю".
А простейшая нативная фича - никто не в курсе среди моих знакомых (на работе, я уверен, все в курсе).
Тонкая грань между "база-базная" и "о, а я не знал"
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥27👍6❤4😁3
#longread #devops #troubleshooting #одинденьизжизни
Пересечения.
У нас на работе много проектов.
На части из них я как выделенный инженер (был), частично могу кого-то заменять на соседних проектах.
Однажды коллега с соседнего проекта ушёл в длительный отпуск.
На время отпуска меня попросили быть заменой:
- мне выделили все доступы к куберам
- перминш сеты к аккаунтам амазона
- добавили в доменные группы гугла
- дали все ключевые url адреса
- ну и гитлаб, куда без него, дали права девелопера ко всему
Провели небольшой онбординг за полчаса, в целом не так сложно быть заменой, проект пока вроде не в проде, так что критикал нет ничего.
Я проверил все адреса, к волту, к UI фронта и так далее - всё ок.
Жизнь несправедлива и человек из отпуска так и не вернулся, прошла волна увольнений, смыв с борта часть команды.
Так бывает😢
Спустя время на этот проект пришёл новый человек (ну его с 2 проектов подвинули сразу на 4 что-ли, лол).
Меня попросили его заонбордить, так как предыдущего инженера уже нет.
Немного странно (я знаю буквально ничего), но ок.
Я просто повторил ровно то, что делали мне - сделал заявки на доменные группы гугла, репозитории гитлаба, куберы - в общем всё то же, тупо скопировав из системы саппорт заявок и джиры.
Приходит этот новый инженер ко мне и говорит:
- сюда есть доступ, сюда есть, туда тоже ок, а вот UI интерфейсы продукта - доступа нет.
Ну странно.
Самое странное, что у меня то есть доступ - мы визуально равны по правам.
Проверяем все группы на https://groups.google.com - у нас одинаковые, связанные с этим проектом.
Рестарт ПК, рестарт тейлскейла - никакого эффекта.
Пишем заявку девопсам:
- так и так, вот ссылки на заявки, вот такие группы у меня и у него, вот такие адреса
Вспоминаю, что была какая-то табличка в гугл докс - прикладываю и её, типа вдруг поможет. Табличка просто содержит подсети по всем проектам - бронь, кому что надо.
Сам почти никогда не пользовался - все подсети по аккаунтам нарезаны были на всех проектах до меня и без меня.
Спустя полчаса девопс пишет - всё исправил - не хватало подсетей в tailscale.
Ещё через пара минут новый инженер пишет, что всё ок (ну и там ещё пара человек заодно, кто пришёл на проект).
В фоне смотрю в гитлаб репозитория - там МР на добавление в конфиг тейлскейла:
Проблема решена.
У всех доступы есть, все довольны.
- - -
Решил все дела на работе и пошёл пить чай. Пью и думаю:
ну ведь магии не бывает, я то имел доступ к этим сайтам по продукту.
Как так-то? Что за бред? У меня был доступ и до и после исправлений. Херня какая-то.
Эта мысль буквально не давала мне покоя до вечера и рано утром я радостным щеночком побежал разбираться.
Я посмотрел конфиг тейлскейла и буквально сразу, поиском, понял, где тут ошибка.
Первые два октета совпадали с одним моим текущим проектом😬
То есть в конфиге тейлскейла было ещё и
Абсолютно те же подсети!
Удивился, полез в историю уволенного инженера - нашел в переписке намёки на то, что он был в курсе пересечений и это надо было сделать.
Вероятно я об этом забыл или невнимательно слушал🤡
Пишу новому инженеру на проект:
- ты только пришёл сюда, а у тебя уже есть техдолг: целым аккаунтом Х в AWS переехать на другие подсети, с полным пересозданием всех ресурсов ))))😂 🤣
- - -
До сих пор не знаю, что реально меня триггенуло разбираться дальше после "проблема решена":
- то, что уволенный инженер месяц-полтора назад намекал/говорил про пересечение подсетей, а я это забыл и где-то в глубине подсознания я всё же знал ответ
- то, у меня большое любопытство и мне неспокойно, когда решение есть, а объяснения нет
Пересечения.
У нас на работе много проектов.
На части из них я как выделенный инженер (был), частично могу кого-то заменять на соседних проектах.
Однажды коллега с соседнего проекта ушёл в длительный отпуск.
На время отпуска меня попросили быть заменой:
- мне выделили все доступы к куберам
- перминш сеты к аккаунтам амазона
- добавили в доменные группы гугла
- дали все ключевые url адреса
- ну и гитлаб, куда без него, дали права девелопера ко всему
Провели небольшой онбординг за полчаса, в целом не так сложно быть заменой, проект пока вроде не в проде, так что критикал нет ничего.
Я проверил все адреса, к волту, к UI фронта и так далее - всё ок.
Жизнь несправедлива и человек из отпуска так и не вернулся, прошла волна увольнений, смыв с борта часть команды.
Так бывает
Спустя время на этот проект пришёл новый человек (ну его с 2 проектов подвинули сразу на 4 что-ли, лол).
Меня попросили его заонбордить, так как предыдущего инженера уже нет.
Немного странно (я знаю буквально ничего), но ок.
Я просто повторил ровно то, что делали мне - сделал заявки на доменные группы гугла, репозитории гитлаба, куберы - в общем всё то же, тупо скопировав из системы саппорт заявок и джиры.
Приходит этот новый инженер ко мне и говорит:
- сюда есть доступ, сюда есть, туда тоже ок, а вот UI интерфейсы продукта - доступа нет.
Ну странно.
Самое странное, что у меня то есть доступ - мы визуально равны по правам.
Проверяем все группы на https://groups.google.com - у нас одинаковые, связанные с этим проектом.
Рестарт ПК, рестарт тейлскейла - никакого эффекта.
Пишем заявку девопсам:
- так и так, вот ссылки на заявки, вот такие группы у меня и у него, вот такие адреса
Вспоминаю, что была какая-то табличка в гугл докс - прикладываю и её, типа вдруг поможет. Табличка просто содержит подсети по всем проектам - бронь, кому что надо.
Сам почти никогда не пользовался - все подсети по аккаунтам нарезаны были на всех проектах до меня и без меня.
Спустя полчаса девопс пишет - всё исправил - не хватало подсетей в tailscale.
Ещё через пара минут новый инженер пишет, что всё ок (ну и там ещё пара человек заодно, кто пришёл на проект).
В фоне смотрю в гитлаб репозитория - там МР на добавление в конфиг тейлскейла:
{ // projectname 111
"src": [
"group:project1-prod@domain.com",
"group:project1-qa@domain.com"
],
"dst": [
"10.******/16",
"10.******/16",
"10.******/16"
],Проблема решена.
У всех доступы есть, все довольны.
- - -
Решил все дела на работе и пошёл пить чай. Пью и думаю:
ну ведь магии не бывает, я то имел доступ к этим сайтам по продукту.
Как так-то? Что за бред? У меня был доступ и до и после исправлений. Херня какая-то.
Эта мысль буквально не давала мне покоя до вечера и рано утром я радостным щеночком побежал разбираться.
Я посмотрел конфиг тейлскейла и буквально сразу, поиском, понял, где тут ошибка.
Первые два октета совпадали с одним моим текущим проектом
То есть в конфиге тейлскейла было ещё и
{ // projectname 222
"src": [
"group:project222-stage@domain.com",
"group:project222-prod@domain.com"
],
"dst": [
"10.******/16",
"10.******/16",
"10.******/16"
],Абсолютно те же подсети!
Удивился, полез в историю уволенного инженера - нашел в переписке намёки на то, что он был в курсе пересечений и это надо было сделать.
Вероятно я об этом забыл или невнимательно слушал
Пишу новому инженеру на проект:
- ты только пришёл сюда, а у тебя уже есть техдолг: целым аккаунтом Х в AWS переехать на другие подсети, с полным пересозданием всех ресурсов ))))
- - -
До сих пор не знаю, что реально меня триггенуло разбираться дальше после "проблема решена":
- то, что уволенный инженер месяц-полтора назад намекал/говорил про пересечение подсетей, а я это забыл и где-то в глубине подсознания я всё же знал ответ
- то, у меня большое любопытство и мне неспокойно, когда решение есть, а объяснения нет
Please open Telegram to view this post
VIEW IN TELEGRAM
👍21❤3
#kubernetes #argocd #ai #agents #devops
Baseline.
С появлением LLM/AI/agent я начал использовать технику baseline.
Я даже не знаю, техника ли это или часть терминологии тестов для CICD, просто использую и всё. Откуда узнал - не знаю, может где вычитал.
Смысл простой: спрашиваю агента*, что он может сделать для бейзлайна
- обновления кубернетис кластера
- обновление аргосиди (недавно бампал 2.14 до 3.4.5)
- изменение количества нод/шардов кластера CNPG
В общем всё то, где есть "состояние ДО изменения/апгрейда" и "состояние ПОСЛЕ изменения/апгрейда".
Чтобы понять как прошёл апдейт и нет ли деградации/ошибок.
Агент фиксирует состояние до апгрейда, затем я вношу изменения через МР, затем прошу агента проверить состояние после изменения.
Пример промпта: "Обновляю арго с 2.14 до 3.4.5, вот ссылка на мой MR на апдейт, сделай бейзлайн Argo, потом я смерджу и ты проверишь после".
Дальше он сам:
- снимает статусы всех Applications (Healthy/Degraded/Unknown/OutOfSync)
- собирает табличку "апп > статус"
- смотрит логи git-сервера Argo
- проверяет RBAC/SSO
- смотрит все релейтед CRD и версии
- фиксирует аномальный рост CPU/memory
- смотрит синк дюрейшны и реконсилейшн лаги
- всё складывает в txt/json в недра /tmp
Мержу МР, апгрейжу, говорю "готово" - агент повторяет то же самое и делает тупой дифф.
Счётчики статусов совпали - говорит "всё ок".
Не совпали - смотрит, какой апп деградировал и почему, сам же лезет смотреть логи git-сервера.
Нюанс: объём проверок - не константа, а то, что написано в промпте.
- если под рукой Grafana/Prometheus/VictoriaMetrics - можно попросить дёрнуть реальные метрики, а не только статусы Applications
- если просто бросил текстом "сделай бейзлайн арго апдейт" - получишь узкий набор: статусы, табличка, логи
- можно сперва спросить агента "какой бейзлайн ты сможешь снять для %операциянейм%?" и после получения большого списка сделать промпт на бейзлайн с нужными тебе проверками
Никакой магии в хуках/скиллах/CLAUDE.md для этого не нужно - модель просто следует тексту запроса.
Артефакт - куча текстовых файлов в недрах /tmp, плюс если отдельно попросишь - тикет в Jira с состоянием до/после для истории.
Можно даже самому глазами/регулярками проверить, если не веришь агенту.
Только фактчекинг, без прогнозов, без галлюцинаций (в моей практике).
Рекомендация 10 из 10.
Начните использовать слово baseline в промптах при подготовке к изменению/апгрейду.
Проверки на деградацию/ошибки при апгрейдах никогда ещё не были столь простыми.
- - -
*Проверялось только на claude code.
Baseline.
С появлением LLM/AI/agent я начал использовать технику baseline.
Я даже не знаю, техника ли это или часть терминологии тестов для CICD, просто использую и всё. Откуда узнал - не знаю, может где вычитал.
Смысл простой: спрашиваю агента*, что он может сделать для бейзлайна
- обновления кубернетис кластера
- обновление аргосиди (недавно бампал 2.14 до 3.4.5)
- изменение количества нод/шардов кластера CNPG
В общем всё то, где есть "состояние ДО изменения/апгрейда" и "состояние ПОСЛЕ изменения/апгрейда".
Чтобы понять как прошёл апдейт и нет ли деградации/ошибок.
Агент фиксирует состояние до апгрейда, затем я вношу изменения через МР, затем прошу агента проверить состояние после изменения.
Пример промпта: "Обновляю арго с 2.14 до 3.4.5, вот ссылка на мой MR на апдейт, сделай бейзлайн Argo, потом я смерджу и ты проверишь после".
Дальше он сам:
- снимает статусы всех Applications (Healthy/Degraded/Unknown/OutOfSync)
- собирает табличку "апп > статус"
- смотрит логи git-сервера Argo
- проверяет RBAC/SSO
- смотрит все релейтед CRD и версии
- фиксирует аномальный рост CPU/memory
- смотрит синк дюрейшны и реконсилейшн лаги
- всё складывает в txt/json в недра /tmp
Мержу МР, апгрейжу, говорю "готово" - агент повторяет то же самое и делает тупой дифф.
Счётчики статусов совпали - говорит "всё ок".
Не совпали - смотрит, какой апп деградировал и почему, сам же лезет смотреть логи git-сервера.
Нюанс: объём проверок - не константа, а то, что написано в промпте.
- если под рукой Grafana/Prometheus/VictoriaMetrics - можно попросить дёрнуть реальные метрики, а не только статусы Applications
- если просто бросил текстом "сделай бейзлайн арго апдейт" - получишь узкий набор: статусы, табличка, логи
- можно сперва спросить агента "какой бейзлайн ты сможешь снять для %операциянейм%?" и после получения большого списка сделать промпт на бейзлайн с нужными тебе проверками
Никакой магии в хуках/скиллах/CLAUDE.md для этого не нужно - модель просто следует тексту запроса.
Артефакт - куча текстовых файлов в недрах /tmp, плюс если отдельно попросишь - тикет в Jira с состоянием до/после для истории.
Можно даже самому глазами/регулярками проверить, если не веришь агенту.
Только фактчекинг, без прогнозов, без галлюцинаций (в моей практике).
Рекомендация 10 из 10.
Начните использовать слово baseline в промптах при подготовке к изменению/апгрейду.
Проверки на деградацию/ошибки при апгрейдах никогда ещё не были столь простыми.
- - -
*Проверялось только на claude code.
1❤21👍12
#security #docker #devops и немного #всратость
Заметка носит скорее исследовательский и развлекательный характер.
Никакого поиска правды, настаивании на этом мнении или призыва к действию.
Однажды приходит алерт от инфобеза: критическая уязвимость, CVE-666lupa666pupa в zlib, надо фиксить.
Смотрю: zlib - это какая-то неизвестная мне хрень.
Возможно и инфобезе, может и никому.
Дебиан букворм держит zlib1g 1.2.13, в которой этот CVE есть.
Триви его видит, алерт красный, белки-истерички кричат и бегают по кругу.
Говорю инфобезу: это нас не касается, камон.
Во-первых, статус в самом триви - will not fix.
Во-вторых, есть флаг --ignore-unfixed, который именно для этого и придуман.
Мы в тот момент работали без этого флага - по какой-то причине, уже не помню.
Поэтому жалобка и прилетела. Поставили флаг + игнор файл для другой неэксплуатируемой штуки и вроде отстали от нас.
В-третьих, сканер это опционально у нас, ну чо ты, какие блокеры, иди чай попей.
Пока я пытался всё это объяснить, у меня в голове крутился вопрос:
а насколько вообще можно доверять тому, что триви находит или не находит?
Решил потом проверить.
- - -
Тест первый.
Пересобрал образ, вручную скомпилировал из сорсов прямо в имадж:
Проверяю внутри контейнера - 1.3.1 там:
Запускаю триви - снова цве критикал😬
Вероятно триви читает /var/lib/dpkg/status - базу пакетного менеджера.
Что реально лежит в /usr/local/lib его не интересует.
Скомпилированная версия для него невидима. Безопасность)
Наверняка это не баг - это архитектурное решение, бинарный анализ каждой библиотеки был бы на порядки дороже. Но это означает, что сканер сообщает о CVE на основе базы пакетного менеджера, а не того, что реально резолвит линкер в рантайме - а это, вообще-то, отдельный вопрос, который одним ldconfig -p не закрыть. Ну не глупость ли, а?
Сканер говорит "уязвимость есть" - а есть ли она реально в работающем процессе, это уже совсем другая история, и я её тут не проверял.
Тест второй.
Раз уж проверяем, проверим до конца.
Берём образ с реальной уязвимостью - log4shell
Триви весело находит три CVE:
log4shell, CVE-biba, CVE-boba. Всё верно.
Теперь берём тот же JAR с уязвимым байткодом и просто меняем строку версии в метаданных внутри архива:
Байткод не тронут, язвимый код на месте.
Только pom.properties теперь говорит версию 2.17.1.
Триви для джавы читает мета pom.properties внутри JAR.
Не байткод, не хэши классов - метаданные, так что поменял строку и тут же сканер доволен😀 .
Сканер говорит "всё чисто" - а уязвимость есть🤣 .
Тест третий.
Проверим ещё - го бинари.
Триви умеет читать зависимости прямо из скомпилированного го бинаря. В каком-то файле есть секция .go.buildinfo, куда компилятор записывает все модули с версиями.
Это реально удобная фича - никаких go.sum в образе не нужно, сканер находит всё сам.
Берём минимальное приложение с намеренно старой версией:
Триви после сборки находит 20 CVE только в го депенденси.
Теперь удаляем секцию билдинфо из бинаря с помощью objcopy:
Бинарь работает и функционально идентичен, проверяю:
скан:
Все 20 гошные CVE исчезли, остались только 9 от Дебиан, которые will not fix. Безопасность😎
На мультистейдже с финальным
Суть та же: все варианты работают, сканер молчит. Безопасность😁
Так что с итогом:
Да ничо, это просто было увлекательно. Изначальная проблема была решена чисто флагом вообще то.
А вопросы остались.
Я не говорю, что CVE сканеры имаджей бесполезны, наоборот - они полезны в штатных сиуациях.
Они находят реальные проблемы, они дают точку отсчёта, они вполне работают как первый фильтр.
Но некоторые сканеры, такие как триви, дают лишь аппроксимацию на основе сигнатур и метаданных.
И в целом они не гарантируют ничего - ни того, что уязвимость есть, ни того, что её нет.
Финальное решение - применимо ли эта CVE к вашей системе, надо ли бежать чинить прямо сейчас или игнорировать месяцами - пока принимает человек.
Это не игнорирование безопасности - как по мне это и есть работа с безопасностью.
- - -
Эта заметка - аккуратно переработанный текст моих старых сообщений в чате куберентис ру, но без обсценной лексики 😬 .
Заметка носит скорее исследовательский и развлекательный характер.
Никакого поиска правды, настаивании на этом мнении или призыва к действию.
Однажды приходит алерт от инфобеза: критическая уязвимость, CVE-666lupa666pupa в zlib, надо фиксить.
Смотрю: zlib - это какая-то неизвестная мне хрень.
Возможно и инфобезе, может и никому.
Дебиан букворм держит zlib1g 1.2.13, в которой этот CVE есть.
Триви его видит, алерт красный, белки-истерички кричат и бегают по кругу.
Говорю инфобезу: это нас не касается, камон.
Во-первых, статус в самом триви - will not fix.
Во-вторых, есть флаг --ignore-unfixed, который именно для этого и придуман.
Мы в тот момент работали без этого флага - по какой-то причине, уже не помню.
Поэтому жалобка и прилетела. Поставили флаг + игнор файл для другой неэксплуатируемой штуки и вроде отстали от нас.
В-третьих, сканер это опционально у нас, ну чо ты, какие блокеры, иди чай попей.
Пока я пытался всё это объяснить, у меня в голове крутился вопрос:
а насколько вообще можно доверять тому, что триви находит или не находит?
Решил потом проверить.
- - -
Тест первый.
Пересобрал образ, вручную скомпилировал из сорсов прямо в имадж:
RUN apt-get update && apt-get install -y build-essential wget \
&& wget https://github.com/madler/zlib/releases/download/v1.3.1/zlib-1.3.1.tar.gz \
&& tar -xf zlib-1.3.1.tar.gz \
&& cd zlib-1.3.1 \
&& ./configure \
&& make \
&& make install \
&& ldconfig \
&& cd .. \
&& rm -rf zlib-1.3.1 zlib-1.3.1.tar.gz \
&& apt-get purge -y build-essential wget \
&& apt-get autoremove -y
Проверяю внутри контейнера - 1.3.1 там:
$ ls -la /usr/local/lib/libz*
lrwxrwxrwx /usr/local/lib/libz.so -> libz.so.1.3.1
lrwxrwxrwx /usr/local/lib/libz.so.1 -> libz.so.1.3.1
-rwxr-xr-x /usr/local/lib/libz.so.1.3.1
$ ldconfig -p | grep libz
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 <- dpkg-пакет, 1.2.13
libz.so.1 => /usr/local/lib/libz.so.1 <- скомпилированная 1.3.1
Запускаю триви - снова цве критикал
Вероятно триви читает /var/lib/dpkg/status - базу пакетного менеджера.
Что реально лежит в /usr/local/lib его не интересует.
Скомпилированная версия для него невидима. Безопасность)
Наверняка это не баг - это архитектурное решение, бинарный анализ каждой библиотеки был бы на порядки дороже. Но это означает, что сканер сообщает о CVE на основе базы пакетного менеджера, а не того, что реально резолвит линкер в рантайме - а это, вообще-то, отдельный вопрос, который одним ldconfig -p не закрыть. Ну не глупость ли, а?
Сканер говорит "уязвимость есть" - а есть ли она реально в работающем процессе, это уже совсем другая история, и я её тут не проверял.
Тест второй.
Раз уж проверяем, проверим до конца.
Берём образ с реальной уязвимостью - log4shell
FROM alpine:3.18
WORKDIR /app
RUN apk add --no-cache openjdk8-jre-base wget
RUN wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar && \
wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.14.1/log4j-api-2.14.1.jar
CMD ["/usr/bin/java", "-version"]
Триви весело находит три CVE:
log4shell, CVE-biba, CVE-boba. Всё верно.
Теперь берём тот же JAR с уязвимым байткодом и просто меняем строку версии в метаданных внутри архива:
RUN mkdir temp && \
unzip log4j-core-2.14.1.jar -d temp && \
sed -i 's/version=2.14.1/version=2.17.1/g' \
temp/META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties && \
cd temp && \
zip -r ../mylog4j-core.jar . && \
cd .. && \
rm -rf temp log4j-core-2.14.1.jar
RUN mv log4j-api-2.14.1.jar mylog4j-api.jar
Байткод не тронут, язвимый код на месте.
Только pom.properties теперь говорит версию 2.17.1.
trivy image test:latest --severity HIGH,CRITICAL
Total: 0 (HIGH: 0, CRITICAL: 0)
Триви для джавы читает мета pom.properties внутри JAR.
Не байткод, не хэши классов - метаданные, так что поменял строку и тут же сканер доволен
Сканер говорит "всё чисто" - а уязвимость есть
Тест третий.
Проверим ещё - го бинари.
Триви умеет читать зависимости прямо из скомпилированного го бинаря. В каком-то файле есть секция .go.buildinfo, куда компилятор записывает все модули с версиями.
Это реально удобная фича - никаких go.sum в образе не нужно, сканер находит всё сам.
Берём минимальное приложение с намеренно старой версией:
golang.org/x/net v0.0.0-20210405180319-a5a99cb37ef4
Триви после сборки находит 20 CVE только в го депенденси.
Теперь удаляем секцию билдинфо из бинаря с помощью objcopy:
RUN go build -o myapp . \
&& apt-get update && apt-get install -y --no-install-recommends binutils \
&& objcopy --remove-section=.go.buildinfo myapp myapp-stripped \
&& apt-get purge -y binutils && apt-get autoremove -y
Бинарь работает и функционально идентичен, проверяю:
$ objdump -s -j .go.buildinfo /myapp-stripped
objdump: section '.go.buildinfo' mentioned in a -j option, but not found in any input file
скан:
trivy image test-go-stripped:latest --severity HIGH,CRITICAL
Total: 9 (HIGH: 6, CRITICAL: 3) только пакеты операционки
Все 20 гошные CVE исчезли, остались только 9 от Дебиан, которые will not fix. Безопасность
На мультистейдже с финальным
FROM scratch это тоже легко обходится - например, через upx, который пакует бинарь в свой формат и триви перестаёт читать билдинфо. Суть та же: все варианты работают, сканер молчит. Безопасность
Так что с итогом:
Да ничо, это просто было увлекательно. Изначальная проблема была решена чисто флагом вообще то.
А вопросы остались.
Я не говорю, что CVE сканеры имаджей бесполезны, наоборот - они полезны в штатных сиуациях.
Они находят реальные проблемы, они дают точку отсчёта, они вполне работают как первый фильтр.
Но некоторые сканеры, такие как триви, дают лишь аппроксимацию на основе сигнатур и метаданных.
И в целом они не гарантируют ничего - ни того, что уязвимость есть, ни того, что её нет.
Финальное решение - применимо ли эта CVE к вашей системе, надо ли бежать чинить прямо сейчас или игнорировать месяцами - пока принимает человек.
Это не игнорирование безопасности - как по мне это и есть работа с безопасностью.
- - -
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16🥰1