Несколько инженеров иногда одновременно запускают terraform apply, рискуя повредить state. Как это правильно предотвратить?

👾 — Хранить state локально у каждого разработчика
👍 — Использовать удалённый backend с блокировкой (S3 + DynamoDB lock / GCS / Az Blob) и -lock=true
🥰 — Поставить git-hook, запрещающий git push во время apply
⚡️ — Перед каждым apply делать terraform refresh

Библиотека задач DevOps

Что делает команда kubectl describe?

👾 — Предоставляет подробную информацию о ресурсе Kubernetes
👍 — Создает новый узел
🥰 — Автоматически развертывает приложения
⚡️ — Удаляет под

Библиотека задач по DevOps

На ноде есть Pods под управлением DaemonSet. Что означает флаг --ignore-daemonsets в kubectl drain?

👾 — Удаляет DaemonSet из кластера
👍 — Переносит все DaemonSet Pods на соседнюю ноду
🥰 — Игнорирует PodDisruptionBudget для всех Pods
⚡️ — Пропускает их, а не удаляет

Разбор: DaemonSet Pods пропускаются и продолжают работать на ноде. Флаг не удаляет DaemonSet и не отменяет PodDisruptionBudget для других Pods.

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

Библиотека задач по DevOps

У Job заданы activeDeadlineSeconds=100 и backoffLimit=5. Дедлайн истёк, но лимит повторов ещё не достигнут. Что произойдёт?

👾 — Job автоматически начнётся заново с нуля
👍 — Job станет Complete, потому что повторов осталось меньше пяти
🥰 — Job завершится Failed с DeadlineExceeded
⚡️ — Job продолжит работу до пяти повторов

Разбор: Job завершится Failed с reason DeadlineExceeded. Общий дедлайн имеет приоритет над backoffLimit. Он не ждёт исчерпания повторов и не запускает Job заново.

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

Библиотека задач по DevOps

Terraform вернул код 2. План провалился?

В CI команда terraform plan -detailed-exitcode завершилась с кодом 2. Что он означает?

👾 — План построен успешно и содержит изменения
👍 — Terraform уже применил два изменения
🥰 — Возникла ошибка построения плана
⚡️ — План построен успешно, изменений нет

Разбор: Верно 👾. С флагом -detailed-exitcode код 0 означает успех без изменений, 1 — ошибку, 2 — успех с изменениями. Команда plan их не применяет. Проверка CI «любой ненулевой код — ошибка» в этом режиме даст ложное падение.

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

Библиотека задач по DevOps

Что отменит cancel-in-progress: true?

В GitHub.com Actions на уровне workflow задано:

concurrency:
  group: deploy-main
  cancel-in-progress: true

Предыдущий запуск ещё выполняется. В том же репозитории появился новый запуск с той же группой. Что произойдёт с предыдущим?

👾 — Продолжится, а новый запуск будет отклонён
👍 — Продолжится параллельно с новым
🥰 — Будет отменён
⚡️ — Дойдёт до конца, отменяются только pending-запуски

Разбор: Верно 🥰. Флаг включает отмену уже выполняющегося запуска с той же concurrency group. Без него concurrency ограничивает параллельность, но не отменяет running-запуск. Отмена не означает откат уже выполненных внешних действий, например деплоя.

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

Библиотека задач по DevOps

Что вернёт absent() при значении метрики 0?

В момент запроса серия up{job="api",instance="a:9100"} существует и имеет значение 0. Других серий с job="api" нет. Каков результат absent(up{job="api"})?

👾 — Одна серия со значением 1
👍 — Исходная серия со значением 0
🥰 — Ошибка из-за нулевого значения
⚡️ — Пустой вектор

Разбор: Верно ⚡️. absent() проверяет наличие элементов во входном векторе, а не их значения. Серия со значением 0 всё равно существует, поэтому результат пуст. Одноэлементный вектор со значением 1 функция возвращает при пустом входе.

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

Библиотека задач по DevOps

Станет ли | конвейером в Ansible command?

Обычный запуск задачи в ansible-core 2.18 на POSIX-узле, где доступна внешняя программа echo:

ansible.builtin.command: echo hello | wc -c

Как будет обработан символ |?

👾 — Соединит echo с wc, результатом станет число 6
👍 — Попадёт в аргументы echo вместе с wc и -c
🥰 — Разделит echo и wc на две отдельные команды
⚡️ — Вызовет ошибку YAML, задача не запустится

Разбор: Верно 👍. command запускает программу без shell. Здесь |, wc и -c станут аргументами echo, а wc не запустится. Для shell-конвейера нужен ansible.builtin.shell. Подставляемые значения при этом требуют корректного экранирования.

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

Библиотека задач по DevOps

Что останется после rm открытого файла?

В Linux у обычного файла в локальной файловой системе одно имя, других жёстких ссылок нет. Процесс открыл файл для чтения. Затем rm успешно удалил его имя, но дескриптор ещё открыт. Какое утверждение верно?

👾 — Имя исчезло, а через открытый дескриптор ещё можно читать
👍 — rm закрыл дескриптор в другом процессе
🥰 — Имя останется в каталоге до завершения процесса
⚡️ — Любое чтение через дескриптор теперь завершится ENOENT

Разбор: Верно 👾. Удаляется имя файла, а открытый файл продолжает существовать. Процесс может читать через свой дескриптор. При отсутствии других ссылок файл удаляется окончательно после закрытия последнего открытого дескриптора. Поэтому удаление имени и завершение работы с файлом — разные события.

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

Библиотека задач по DevOps

Какой CPU request получит Pod с init-контейнерами?

У Pod два контейнера приложения с CPU requests 200m и 300m. У двух обычных init-контейнеров — 800m и 100m. Это итоговые requests после admission. Sidecar нет, Pod-level requests не заданы, overhead равен нулю. Какой эффективный CPU request учитывается при размещении Pod?

👾 — 500m
👍 — 900m
🥰 — 800m
⚡️ — 1400m

Разбор: Верно 🥰. Обычные init-контейнеры идут последовательно, их эффективный request — максимум: 800m. У приложений requests складываются: 200m + 300m = 500m. Для Pod берётся большее: max(800m, 500m) = 800m. Это запрос ресурсов для размещения, а не фактическая загрузка CPU.

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

Библиотека задач по DevOps

Останется ли разрешён вход на TCP/80 после добавления NetworkPolicy с ingress: []?

В Kubernetes используется networking.k8s.io/v1, CNI применяет NetworkPolicy. Первая Ingress-политика разрешает вход на TCP/80 к целевому Pod от Pod с app=frontend. Затем к тому же целевому Pod добавляют вторую Ingress-политику с ingress: []. Других политик для цели нет.

Обе политики уже действуют. Подключается обычный Pod с app=frontend, а не нода. Его egress и остальные сетевые настройки соединению не мешают.

👾 Нет, последняя политика отменит предыдущее разрешение
👍 Да, разрешения применимых Ingress-политик складываются
🥰 Нет, две политики для одного Pod заблокируют весь вход
⚡️ Да, и вместе с TCP/80 откроются все остальные порты

Разбор:
👍 Разрешение TCP/80 сохранится. В каждом направлении объединяются разрешения всех применимых NetworkPolicy. Пустой ingress не добавляет разрешений и не отменяет разрешения другой политики. Порядок создания здесь не задаёт приоритет. Остальные порты от этого не откроются.

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

Библиотека задач по DevOps

Какой файл исключений выберет docker build -f build.Dockerfile .?

Используется современный Docker BuildKit с поддержкой отдельных ignore-файлов для Dockerfile. Из корня проекта выполняют:

docker build -f build.Dockerfile .

В том же корне лежат .dockerignore со строкой secrets/ и build.Dockerfile.dockerignore со строкой logs/. Оба каталога существуют, других правил нет. Какие исключения применятся к контексту сборки?

👾 Только правила корневого .dockerignore
👍 Объединение правил обоих файлов
🥰 Только правила build.Dockerfile.dockerignore
⚡️ Никакие, потому что указан флаг -f

Разбор:
🥰 Применится build.Dockerfile.dockerignore. Отдельный ignore-файл для выбранного Dockerfile имеет приоритет над корневым, а не дополняет его. Поэтому logs/ будет исключён, а правило secrets/ из корневого .dockerignore в этой сборке не сработает.

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

Библиотека задач по DevOps

Что запланирует Terraform, если удалить resource-блок вместе с prevent_destroy?

Ресурс существует в state и в инфраструктуре. В его конфигурации был блок:

lifecycle {
  prevent_destroy = true
}

Теперь целиком удалили resource-блок, включая lifecycle, и запускают обычный terraform plan. Блок removed не добавляли, terraform state rm не выполняли. Внешней защиты от удаления и других ограничений нет.

👾 Удаление инфраструктурного объекта
👍 Ошибку, потому что prevent_destroy сохранён в state
🥰 Только удаление записи из state, с сохранением объекта
⚡️ Создание второго объекта взамен прежнего

Разбор:
👾 План будет содержать удаление объекта. prevent_destroy защищает его, пока это правило есть в конфигурации. После удаления всего resource-блока правило исчезает вместе с ним. Сам plan объект ещё не удаляет. Удаление произойдёт при применении плана.

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

Библиотека задач по DevOps

Миграция с 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 и дождитесь письма-подтверждения.

Какие значения вернут сравнения PromQL без bool и с bool?

В момент instant query существует ровно одна float-серия queue_depth{job="worker"} со значением 7. Native histogram нет. Выполняют два запроса:

queue_depth{job="worker"} > 5
queue_depth{job="worker"} > bool 5

Нужны только числовые значения единственного элемента каждого результата, в указанном порядке. Имена метрик и labels не рассматриваем.

👾 1 и 1
👍 1 и 7
🥰 Пустой вектор и 1
⚡️ 7 и 1

Разбор:
⚡️ Получатся 7 и 1. Без bool сравнение работает как фильтр: 7 > 5 истинно, поэтому серия остаётся со своим значением 7. С bool истинное сравнение даёт 1, ложное дало бы 0. Модификатор также убирает имя метрики, но вопрос только о числах.

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

Библиотека задач по DevOps

Какой доступ к issues останется у GITHUB_TOKEN при permissions: { contents: read }?

GitHub.com Actions, обычный push в свой репозиторий. Используется стандартный GITHUB_TOKEN, без PAT и токена GitHub App. На уровне workflow задано:

permissions:
  contents: read

У job собственного permissions нет. Какой эффективный уровень issues получит токен этой job? Анонимное чтение публичных данных и служебное разрешение metadata не рассматриваем.

👾 read, потому что contents: read даёт чтение всех API
👍 none, потому что неуказанные permissions получают none
🥰 write, если push сделал администратор репозитория
⚡️ Прежний default репозитория без изменений

Разбор:
👍 У issues будет none. Если явно задать хотя бы одно разрешение в permissions, остальные неуказанные разрешения получают none. contents: read даёт чтение содержимого репозитория, но не issues. Права пользователя, сделавшего push, не добавляются к GITHUB_TOKEN автоматически.

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

Библиотека задач по DevOps