Лишние байты образа можно ловить до деплоя

Dive умеет не только показывать слои. При CI=true он отключает интерфейс и возвращает pass/fail кодом завершения.

Linux/macOS, POSIX shell, установленный Dive и локальный образ myapp:build. Нужен доступ к Docker daemon, он привилегирован:

CI=true dive myapp:build --ci-config .dive-ci.yml

Пример содержимого файла:

rules:
  lowestEfficiency: 0.95
  highestWastedBytes: 20MB
  highestUserWastedPercent: 0.20

Провал: efficiency ниже 95%, лишние байты от 20 MB или доля лишнего от 20%. В последней метрике базовый слой исключён из общего размера. Пороги здесь учебные, подберите свои.

Оценка efficiency экспериментальная. Это проверка лишнего места, а не уязвимостей. В видео — интерактивный разбор слоёв, сам CI-режим работает без этого экрана.

Dive и правила CI
#арсенал_инженера

Миграция с VMware, домашний кластер, выросший из одного ноутбука, и ИИ для работы с инцидентами

Всё это на митапе Deckhouse User Community 12 ноября в Москве.

В программе три доклада:
— опыт НИУ «МИЭТ»: как университет переходит с VMware на виртуализацию Deckhouse — от пилота до миграции ВМ и резервного копирования;
— 13 лет домашней инфраструктуры: от одного ноутбука до геораспределённого кластера из нескольких квартир и дата-центров;
— IncidentGPT на практике: от участия в Open Source-проекте до внедрения в компании, а заодно переход с Prometheus на Deckhouse Prom++ ради экономии памяти.

Нетворкинг после основной программы тоже будет. :)

Где: People Loft, 1-я улица Энтузиастов, д. 12 (метро и D3 «Авиамоторная»).
Когда: 12 ноября, начало в 19:00. Сбор в 18:15, приходите! Возьмите с собой паспорт или водительское удостоверение.

Митап пройдёт только офлайн. Для участия зарегистрируйтесь на Timepad и дождитесь письма-подтверждения.

Зелёный restic check ещё не означает, что прочитаны все данные

Обычный restic check проверяет структуру и целостность репозитория, но по умолчанию не читает все pack-файлы для проверки самих данных. Для этого есть --read-data.

Полная проверка дороговата? Можно читать группами. В Linux/macOS с установленным restic, доступом к существующему репозиторию и штатно настроенными credentials:

restic -r /srv/restic-repo check --read-data-subset=1/5

Замените путь своим. Это первая из пяти групп. Следующие вызовы: 2/5, 3/5, 4/5, 5/5. Для неизменного репозитория они покрывают все группы. Повторять случайные 10% — другая стратегия, полного покрытия она не гарантирует.

Команда не чинит репозиторий. Чтение данных тратит время и трафик, а в облаке может стоить денег. Проверка всё равно не заменяет пробное восстановление.

Документация restic
#root_prompt

Почему memory_limiter ставят перед batch

В OpenTelemetry Collector порядок processors влияет на то, куда вернётся отказ при нехватке памяти. README рекомендует memory_limiter первым, чтобы backpressure дошёл до receiver.

Фрагмент списка processors в своём pipeline:

processors: [memory_limiter, batch]

Оба processor нужно отдельно объявить в конфигурации. Проверьте их наличие в своей версии и сборке Collector.

При превышении soft limit limiter отказывает новым данным с повторяемой, non-permanent ошибкой. Выше hard limit дополнительно вызывает GC. Soft limit = limit_mib − spike_limit_mib. Например, 4000 − 800 = 3200 MiB. Это пример из README, а не размер для любого контейнера.

Receiver должен корректно повторить отправку. Без retry данные теряются, а бесконечно повторять он тоже не сможет. Между проверками память успевает вырасти, поэтому limiter не гарантирует защиту от OOM.

Memory Limiter Processor
#архитектура_на_салфетке

🔐 Высокий score systemd — повод открыть настройки сервиса

У systemd-analyze есть проверка sandboxing-настроек unit. Для Linux с systemd и установленным nginx:

systemd-analyze security --no-pager nginx.service

Подставьте свой service unit и проверьте поддержку команды в установленной версии. Она читает конфигурацию, ничего не меняет. Нужен доступ к system manager.

В ответе будет таблица ограничений и overall exposure от 0.0 до 10.0. Высокое число означает, что применено мало учитываемых ограничений.

Но это не сканер уязвимостей. Оценка не учитывает всю защиту приложения и, например, не даёт полного анализа доступа через IPC. Плохой score не доказывает уязвимость, хороший не доказывает безопасность.

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

Документация systemd-analyze
#root_prompt

Lockfile с ноутбука может не покрывать Linux runner

Если provider впервые установили из mirror, в .terraform.lock.hcl могут остаться checksums только текущей платформы. На другой архитектуре проверка пакета тогда не сойдётся. Это возможный сценарий, не обязательный сбой любого macOS → Linux.

В каталоге корневого модуля Terraform 0.14+ можно заранее добавить суммы для целевых платформ:

terraform providers lock \
  -platform=linux_amd64 \
  -platform=linux_arm64

Нужны сеть до исходного registry и право записи lockfile. Выберите платформы, которые поддерживает ваш provider.

Команда получает и проверяет пакеты, обновляет локальный файл, инфраструктуру не меняет. Проверьте источник подписей, signer и diff, затем сохраните lockfile в Git. Удалять его ради исчезновения ошибки checksum — плохое лечение.

Этот файл фиксирует зависимости providers. Версии remote modules и state в нём не хранятся.

Dependency lock file
#арсенал_инженера

Pod уже удаляется, а serving всё ещё true

У endpoint в EndpointSlice есть три условия: serving, terminating и ready. Для Pod поле serving отражает его Ready. Значение terminating становится true, когда Pod получает deletion timestamp, обычно ещё до остановки контейнеров.

Поэтому сочетание serving=true, terminating=true возможно. Значение ready при этом false: оно означает «обслуживает и не завершается». Исключение — Service с publishNotReadyAddresses=true, у него ready всегда true.

Service-прокси обычно исключают завершающиеся endpoints. Если все доступные endpoints завершаются, они могут направлять трафик на те, у которых serving=true. Поведение зависит от потребителя EndpointSlice. Эти флаги сами по себе не гарантируют бесшовный drain.

Условия EndpointSlice
#архитектура_на_салфетке

📍 Вакансии • Задачи • Собесы
Библиотека devops'a

Проверяем HTTPS на другом IP

curl --resolve подменяет адрес только для заданной пары hostname:port. Имя из URL остаётся в SNI и используется для проверки сертификата. Одного заголовка Host для этого недостаточно.

Локальный стенд на карточке: TLS-сервер на 127.0.0.1:8443, сертификат с SAN app.test, тестовый CA в ca.pem. Команда выполнена в zsh на macOS с curl 8.7.1. Сервер получил SNI app.test и Host app.test:8443. Запрос к IP с Host: app.test завершился ошибкой сертификата, код 60.

--noproxy отключает прокси в этом примере, --cacert указывает файл тестового CA. Проверка сертификата включена. Для обычного HTTPS без явного порта в URL пара в --resolve должна содержать 443.

Everything curl
#root_prompt

📍 Вакансии • Задачи • Собесы
Библиотека devops'a

Куда положить pod name в Loki

Имена Pod и process ID дают много уникальных значений. Если сделать их индексными labels в Loki, растёт кардинальность индекса. Structured metadata позволяет прикрепить такие поля к записи без индексации и без добавления в текст лога.

Поля возвращаются с результатами запроса, по ним можно фильтровать. Для этого нужны индекс tsdb, schema ≥13, chunk format V4 и включённый allow_structured_metadata. Старый boltdb-shipper не поддерживается.

Объём metadata учитывается в ingestion rate limit. Есть отдельные ограничения на размер и число полей у записи. Перенос из labels не делает хранение и обработку бесплатными.

Structured metadata в Loki
#архитектура_на_салфетке

📍 Вакансии • Задачи • Собесы
Библиотека devops'a

Опечатку в matrix можно поймать до запуска CI

В матрице workflow объявлен os, а в runs-on указан matrix.arch. actionlint замечает отсутствующее свойство локально, без отправки workflow на GitHub.

В примере на карточке actionlint 1.7.12 для macOS arm64 вернул exit 1 с диагностикой про arch. После единственной замены matrix.arch на matrix.os тот же вызов вернул exit 0 без сообщений. Использован официальный бинарник, checksum архива совпал с указанным в релизе.

Флаги -shellcheck= -pyflakes= отключают внешние ShellCheck и pyflakes. В этом примере проверяется ссылка на свойство матрицы. Успешный lint не подтверждает работу скриптов, секретов или удалённого CI.

Репозиторий actionlint
#арсенал_инженера

📍 Вакансии • Задачи • Собесы
Библиотека devops'a

Запись создана. Почему DNS ещё отвечает NXDOMAIN?

Рекурсивный резолвер мог получить NXDOMAIN ещё до создания записи и сохранить отрицательный ответ. Изменение авторитетной зоны само по себе не стирает этот кэш.

По RFC 2308 TTL такого ответа берут как минимум из SOA.MINIMUM и TTL самой SOA. Пока ответ хранится в кэше, TTL отсчитывается вниз. После нуля использовать этот кэшированный ответ нельзя.

На схеме условный пример: минимум из 900 и 300 секунд — 300. Если запись создать через минуту после NXDOMAIN, в этом кэше может оставаться ещё 240 секунд. Это иллюстрация механизма, а не обещание точного ожидания у любого резолвера.

NXDOMAIN, NODATA и SERVFAIL — разные ответы. Формулу отрицательного TTL нельзя переносить на любую ошибку DNS.

RFC 2308, разделы 3 и 5
#архитектура_на_салфетке

📍 Вакансии • Задачи • Собесы
Библиотека devops'a

Ротация токена не сбрасывает кэш BuildKit

Содержимое build-secret не входит в ключ кэша Docker BuildKit. Если заменить только токен, закэшированный шаг может сохраниться.

Secret ID и путь монтирования участвуют в cache checksum. Их изменение инвалидирует кэш.

Если после ротации нужно выполнить шаг заново, Docker предлагает менять build argument этого шага с произвольной несекретной ревизией. Сам токен передают через secret mount. Его значение нельзя помещать в ARG или ENV.

Повторный запуск шага не гарантирует свежесть скачанного артефакта.

Build cache invalidation
#арсенал_инженера

📍 Вакансии • Задачи • Собесы
Библиотека devops'a