Kuber Community Day возвращается: 30 июля, Москва 😀

30 июля во второй раз состоится конференция Kuber Community Day. В этом году участников ждут новые доклады, форматы и площадка.

Будут два пространства с техническим контентом от практиков из X5 Tech, MWS, «Райффайзенбанка», «СберЗдоровья», «Лаборатории Числитель», «Инфосистемы Джет», Hilbert Team, OpsMaster и других компаний.

Среди заявленных тем:

- Не Argo CD единым живы: комплексная автоматизация на стеке Argo Project
- Неидемпотентный мир победил, AI оказался сильней
- NixOS вместо Talos: когда хочется Kubernetes, но не хочется терять Linux
- Kubernetes — это всего пять сертификатов
- Мониторинг здоровья Kubernetes

◽️ Форматы: офлайн и онлайн (трансляция предусмотрена для обоих залов).

Участие бесплатное, но места на офлайн ограничены площадкой.

Регистрация уже идет по ссылке.

We’re excited to introduce opensource vmestimator, a new component in the VictoriaMetrics ecosystem.

vmestimator measures metrics cardinality across arbitrary label dimensions and exposes the results as Prometheus-compatible metrics. It helps to understand where cardinality comes from, track how it evolves over time, and build early-warning alerts before cardinality becomes a problem.

If you’re operating Prometheus-compatible monitoring systems and want realtime visibility into metric cardinality, give vmestimator a try. We’d love to hear your feedback and learn more about your use cases.

Read more about its design and configuration in the documentation, or explore it yourself in the playground.

PII-Shield — open-source инструмент для защиты логов и данных от утечки персональной информации прямо в Kubernetes . Он работает как sidecar контейнер, перехватывает stdout/stderr, находит секреты и чувствительные данные до того, как они попадут в лог-системы.

Сочетание Shannon Entropy для поиска неизвестных секретов (токены, API-ключи, пароли) и O(1) regex для точного детектирования известных паттернов снижает false positive и позволяет находить даже то, что не было заранее описано правилами.

PII-Shield работает полностью локально, без API вызовов наружу, с почти нулевой нагрузкой на GC. Интересный проект, чтобы попробовать безопасно коррелировать логи между сервисами, не раскрывая реальные данные.

PEP 810: Explicit lazy imports 2

Как я уже писал, в Python 3.15 нас ждут lazy imports.
В первом посте я описал основные фичи. Прочитайте его перед продолжением.

Во втором посте настало время посмотреть на плохие части.

Детали PEP, которые мы не осветили прошлый раз

Во-первых, из очевидного: lazy import может быть использован только на уровне модуля, в других местах - он будет вызывать ошибку синтаксиса. Но, что забавно, lazy import не может быть использован внутри даже try блоков.

Во-вторых, я не уточнил, как будет работать __lazy_modules__, а там дичь.
Мы можем указывать __lazy_modules__ = ['os', 'typing'] в любой версии питона. Очевидно, что работать как ленивые они будут только в 3.15+, в остальных - будет просто неиспользуемый атрибут. Но штука в том, что в разных версиях питона библиотеки будут работать по-разному. Но! Он будет ленивым, только если он может быть ленивым. То есть, если он находится внутри класса, функции, try, тд - он не станет ленивым. Удачи в дебаге, короче.

Ну и самое забавное, мы можем управлять глобальным стейтом всех импортов через -X lazy_imports=none|normal|all и так же через переменную окружения PYTHON_LAZY_IMPORTS. Что оно значит? Отключаем все lazy импорты | все работает так, как написано | все импорты ленивые. Мы можем управлять тем, как работают импорты через переменную окружения!! Перечитайте, если вы тоже не поняли. Я вот не сразу понял.

Внедрение в питон

В stdlib питона уже активно используют lazy импорты. Однако, внутри уже появились циклические импорты. Потому что теперь так можно сделать случайно. И специально. Да, ленивые импорты могут помогать избегать циклических импортов. В некоторых режимах работы.
Теперь stdlib больше не работает в режиме -X lazy_imports=none.

О чем развернулась жаркая дискуссия, прочитать которую я всем советую: https://github.com/python/cpython/issues/149321

Но и режим -X lazy_imports=all все сломал. Теперь с ним некоторые библиотеки начали работать по-другому. Например:

$ PYTHON_LAZY_IMPORTS=normal ./python -c "import shutil; print(shutil._BZ2_SUPPORTED)"
False
$ PYTHON_LAZY_IMPORTS=all ./python -c "import shutil; print(shutil._BZ2_SUPPORTED)"
True

Так как импорт становится ленивым, он больше не проверяет есть ли на самом деле библиотека _bz2 у вас. А просто всегда возвращает True. Что делать - пока никто не знает: https://github.com/python/cpython/issues/150167

Вот в такой ситуации мы все оказались. Зато теперь некоторые скрипты будут запускаться быстрее, потому что импорты в некоторых местах стали ленивыми. Иногда, не точно. Почему нельзя было использовать импорт внутри функции? Я не знаю.

Мое отношение к данной фиче можно только охарактеризовать словами вечного инструмента wemake-python-styleguide: https://github.com/wemake-services/wemake-python-styleguide/issues/3639

Обсуждение: я даже не знаю, честно. Давайте просто обнимемся в комментах.

| Поддержать | YouTube | GitHub | Чат |

Редкий Docker-трюк для баз данных: отдельный volume под WAL

У Postgres есть место, куда он пишет журнал изменений: WAL.

Если база активно пишет данные, WAL может стать узким местом. В Docker его можно вынести в отдельный volume:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_INITDB_WALDIR: /var/lib/postgresql/wal
    volumes:
      - pg_data:/var/lib/postgresql/data
      - pg_wal:/var/lib/postgresql/wal

volumes:
  pg_data:
  pg_wal:

Зачем это нужно:

1. данные базы лежат отдельно
2. журнал транзакций лежит отдельно
3. проще мониторить рост WAL
4. меньше риска забить основной volume логами

Особенно полезно для staging, pet-проектов с нагрузкой и локальных стендов, где внезапно «почему Postgres сожрал весь диск».

Мелочь, но уже уровень не “я просто поднял базу в Docker”, а нормальная инженерная привычка.

Зацените какую штуку тут товарищ написал:
https://github.com/crust-gather/crust-gather

Она сохраняет стейт Kubernetes кластера в OCI-имадж (со всеми CRD, статусами, ивентами, подами и их логами)

Потом его можно запустить локально и в нем покопаться обычным kubectl. Можно клода натравить, можно k9s, и т.п.

Идеально подходит чтобы интегрировать в свой пайплайн. Написано на rust'е.

Завтра будет рассказывать о ней на KCD
https://kcd-czech-slovak-2026.sessionize.com/session/1195463

(есть прямая трансляция)

mvm

#golang #tools

mvm - быстрая стековая виртуальная машина для Go, позволяющая запускать программы напрямую из исходников без компиляции. Целиком совместима с Go, поддерживает встраивание в Go/C-приложения, имеет встроенный REPL, отладчик и тестовый движок. Распространяется как единый статический бинарник со стандартной библиотекой внутри

https://kodikapusta.ru/tools/1-mvm

Поддержать проект на boosty и читать в MAX

Зеркало PyPI

На нескольких проектах последние несколько дней сталкиваемся с проблемами с доступом к PyPI: как локально, так и в CI. Печально.

All attempts to connect to pypi.org failed.

Probable Causes:
- the server is not responding to requests at the moment
- the hostname cannot be resolved by your DNS
- your network is not connected to the internet

Если у вас есть такая же проблема, можете воспользоваться PyPI зеркалом от GitVerse: https://gitverse.ru/docs/artifactory/registry-mirrors/pypi-mirror?utm_source=tg&utm_medium=fix&utm_campaign=bloggers&utm_content=post&utm_term=nikitasobolev&utm_erid=2VfnxxwjcVp

Все пакеты и все версии, которые есть на PyPI - оттуда тоже доступны. Перевел консалтинговые проекты - заработало.

Как настроить?

pip, документация:

# Установка одного пакета:
pip install attrs --extra-index-url https://pypi-mirror.gitverse.ru/simple/

# Настройка для всех команд:
pip config --user set global.index-url https://pypi-mirror.gitverse.ru/simple/            
pip config --user set global.trusted-host pypi-mirror.gitverse.ru

Можно настроить как альтернативный, а не главный индекс: вместо global.index-url используйте global.extra-index-url.

poetry, документация:

# pyproject.toml
[[tool.poetry.source]]
name = "pypi"
priority = "primary"

[[tool.poetry.source]]
name = "gitverse"
url = "https://pypi-mirror.gitverse.ru/simple/"
priority = "supplemental"

Сначала пробуем pypi, если не вышло - идем в зеркало.
Можно повернуть priority в зависимости от ваших задач.

uv, документация:

# pyproject.toml
[[tool.uv.index]]
url = "https://pypi.org/simple/"
name = "pypi"
default = true

[[tool.uv.index]]
url = "https://pypi-mirror.gitverse.ru/simple/"
name = "gitverse"

Здесь аналогично, default имеет самый низкий приоритет.

Важно: обратите внимание, чтобы при использовании любых зеркал, у вас были корректные хеши пакетов при установке. poetry и uv делают такое по-умолчанию. А вот pip требует явного --require-hashes параметра. Сам pip тем временем не умеет дампить хеши, но pip-tools умеет 🌚

Пример, корректной работы:

» uv sync --default-index https://pypi-mirror.gitverse.ru/simple/ 
Resolved 171 packages in 20ms
Checked 102 packages in 13ms

Еще есть зеркала для:
- DockerHub
- NPM
- Maven

Обсуждение: вас затронула проблема?

Реклама. ПАО "СБЕРБАНК", ИНН 7707083893. erid: 2VfnxxwjcVp

Большой гайд про диски https://arthurchiao.art/blog/practical-storage-hierarchy/

bhatti

#tools

bhatti - это открытая платформа для запуска легковесных Linux-виртуальных машин на собственном железе. Каждая машина работает как полноценная ВМ с отдельным ядром через Firecracker, а не контейнер. Умеет снэпшотить полное состояние и автоматически приостанавливать простаивающие машины, освобождая ресурсы.

Подходит для изолированных окружений AI-агентов, preview-окружений на PR и любых других сценариев, где нужна полноценная Linux-система по запросу.

Устанавливается одной командой на любой Linux с KVM

https://kodikapusta.ru/tools/3-bhatti

Поддержать проект на boosty и читать в MAX

go tool task

#golang

Я очень люблю Taskfile и в своих петпроектах не пользуюсь Makefile. Это реально супер удобная замена уродского Makefile, но у старичка есть преймущество - он make есть везде.

Но! Теперь для CI стало значительно удобнее использовать Taskfile через go tool task. В статье автор рассказывает как это работает

https://kodikapusta.ru/news/980-go-tool-task

Поддержать проект на boosty: https://boosty.to/kodikapusta

от себя добавлю что сталкивался с таким поведением rsync - он и правда не гарантирует целостность

Почему rsync ≠ гарантия целостности данных. Как я проверяю бэкапы и нахожу расхождения

Работа с rsync и многими другими утилитами для бэкапирования несёт в себе совершенно не очевидную и от этого особенно недооценённую опасность — риск получить рассинхронизацию содержимого файлов, о которой никто и никогда не узнает до того, пока не станет поздно. Статья задумана как рассказ об очень интересной, но малоизвестной утилите precizer. С её помощью можно контролировать целостность данных при синхронизации, бэкапировании или восстановлении файлов. Программа вполне удобно организована и позволяет убедиться, что ни один байт не был утерян в процессе.

Материал разделён на несколько глав, пестрящих избыточными техническими подробностями с целью обосновать, почему было принято именно такое решение, а не иное.

@usr_bin_linux

🗜 Temporary files in Linux - статья, описывающая работу со временными файлами в Linux.

Автор рассматривает и работу в tmpfs, и обработку временных файлов через флаг O_TMPFILE на файловой системе...

https://blogs.oracle.com/linux/temporary-files-in-linux

#tmpfs #напочитать