Найти в Дзене
Столкнулся с проблемой: оператор PostgreSQL для Kubernetes CloudNativePG, с плагином бэкапов Barman Cloud генерирует десятки тысяч GET и
LIST запросов к S3 хранилищу. Причина — сайдкар контейнер постоянно проверяет WAL архивы для управления политикой хранения. Что не помогло: - Отключение бекапов WAL — диск 100Гб забился за 2 дня (внезапно это базовая фича плагина, WAL журналы все равно создавались) - Оптимизация размера и периода отправки WAL в S3 - Переход на плагин WAL-G от Yandex с инкрементальными копиями Что помогло: Одна строка в конфиге, которая увеличивает интервал проверки retention политики с нескольких минут до 6 часов: spec: instanceSidecarConfiguration:...
3 недели назад
Подводные камни Kubernetes аннотаций
Подводные камни Kubernetes аннотаций 🤔 Недавно столкнулся с интересной ошибкой при деплое Helm чарта: StatefulSet.apps "pgsql" is invalid: spec.template.annotations: Invalid value: "checksum/secret/pgsql" Оказывается, в Kubernetes есть строгие правила для имён аннотаций. Ключ аннотации может содержать только один слеш /, который разделяет префикс и имя. ❌ Неправильно: annotations:   checksum/secret/pgsql: "..."   checksum/secret/postgres-exporter: "..." ✅ Правильно: annotations:   checksum/secret-pgsql: "..."   checksum/secret-postgres-exporter: "....
4 месяца назад
Словил интересный баг в GitLab CI, делюсь кейсом
Словил интересный баг в GitLab CI, делюсь кейсом. 💡 Пайплайн, который работал годами, внезапно упал с ошибкой об отсутствующем пакете. При этом пакет был на месте в package.json, а Dockerfile давно никто не редактировал. Проблема: Для кэширования и ускорения последующих сборок было две задачи: - в одной задаче создавалась папка node_modules от пользователя root. - в следующей задаче она копировалась в образ, где работа шла от пользователя node. Но папка так и оставалась принадлежать root. Почему это работало несколько лет, а потом перестало — для меня до сих пор загадка. Скорее всего, старая версия Docker (или самого раннера) закрывала на это глаза...
4 месяца назад
YAML кажется простым, пока не наткнёшься на «магические» значения, отступы и странные преобразования типов
YAML кажется простым, пока не наткнёшься на «магические» значения, отступы и странные преобразования типов. Вот быстрый чек-лист, чтобы не попасть: 1. Булевы ловушки # Плохо enabled: yes # станет true answer: No # станет false # Хорошо enabled: true answer: "No" # строка 2. Ведущие нули # Плохо port: 080 # Хорошо port: "080" # строка 3. Даты как строки # Плохо version: 2025-08-16 # Хорошо version: "2025-08-16" 4. Только пробелы, без табов items: - a - b 5. Анкоры и алиасы (DRY) base: &base image: nginx:latest web: <<: *base replicas: 2 6. Многострочные строки: `|` vs `>` | — сохраняет переносы строк...
5 месяцев назад
В YAML списки (массивы) — это «последовательности
В YAML списки (массивы) — это «последовательности». Их пишут двумя способами: Блочный: с дефисами — самый читаемый servers: - web01 - web02 В строку (flow): компактно, но хуже на длинных списках web_servers: [web01, web02] Можно вкладывать списки в словари и наоборот: environments: - name: production servers: - prod-web01 - prod-db01 Длинные элементы удобно хранить как многострочные строки: config_files: - | server { listen 80; } Где это нужно: Ansible (tasks, hosts), Kubernetes (containers, ports), CI/CD (steps). Советы: * Только пробелы, без табов...
5 месяцев назад
Если нравится — подпишитесь
Так вы не пропустите новые публикации этого канала