Что отменит 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

Сколько раз выполнится handler после двух notify в Ansible?

Один play, один host, обычные последовательные tasks. Две задачи завершились с changed: true и обе уведомили один и тот же handler Restart app. Handler с этим именем определён только один раз.

Нет pre_tasks, post_tasks, meta: flush_handlers, ошибок, других plays и повторных фаз обработки. Раньше handler не выполнялся. Сколько запусков будет при обычной обработке handlers после этих tasks?

👾 Ноль, два уведомления отменят друг друга
👍 Два, сразу после каждой changed-задачи
🥰 Один, повторные уведомления объединятся
⚡️ Один или два, в зависимости от порядка notify

Разбор:
🥰 Handler выполнится один раз после tasks. В этой фазе повторные уведомления одного handler не вызывают дополнительных запусков. После отдельной обработки handlers его можно уведомить заново, но flush_handlers и повторные фазы исключены условиями.

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

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

Запустит ли After=db.service саму db.service?

Linux с systemd. Обычные app.service и db.service валидны и доступны, оба сейчас inactive. У app.service в секции [Unit] задано только:

After=db.service

Нет Wants, Requires, BindsTo, других зависимостей или путей активации db.service. Выполняется только команда systemctl start app.service, параллельных запросов старта нет. Запустится ли db.service?

👾 Да, systemd сначала запустит db.service
👍 Да, одновременно с app.service
🥰 Нет, а app.service обязательно завершится ошибкой зависимости
⚡️ Нет, After задаёт порядок, но не запрашивает запуск db.service

Разбор:
⚡️ db.service останется inactive. After задаёт порядок, если оба unit участвуют в запуске, но сам не добавляет второй unit в транзакцию. Зависимости Wants и Requires решают отдельную задачу: включают другой unit в запуск. Одного After для этого недостаточно.

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

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

Что останется от истории Deployment с revisionHistoryLimit: 0 после успешного завершения rollout и очистки истории?

👾 — Предыдущие ReplicaSet сохранятся без ограничения
👍 — Deployment автоматически вернётся к предыдущему образу
🥰 — Сохранится ReplicaSet текущей ревизии, старые будут удалены
⚡ — Удалится сам Deployment вместе с Pod

Разбор:
🥰. Старые ReplicaSet хранят ревизии для отката. При нулевом лимите контроллер удаляет их после завершения rollout. Очистка идёт в фоне. По условию она уже завершилась. Текущая ревизия продолжает работать, а откат к удалённым ревизиям по истории Deployment недоступен.

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

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

Когда при первоначальном запуске Docker Compose создаст web, если для его зависимости db задано condition: service_healthy и у db настроен healthcheck?

👾 — После того как healthcheck db сообщит healthy
👍 — Сразу после запуска процесса db
🥰 — Только после остановки db
⚡ — После первого запроса от web к db

Разбор:
👾. Compose ждёт успешной проверки healthcheck у зависимости с service_healthy и затем создаёт зависимый сервис. Самого запуска процесса db недостаточно. Условие относится к начальному запуску и не задаёт автоматическую остановку web, если db позднее станет unhealthy.

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

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

Что сделает Terraform 1.5 или новее, если условие в assert внутри блока check окажется ложным (false)?

👾 — Остановит текущую операцию с ошибкой
👍 — Удалит ресурс, который проверяет check
🥰 — Автоматически применит обратный план
⚡ — Выдаст предупреждение и продолжит текущую операцию

Разбор:
⚡. Неуспешный assert в check выдаёт предупреждение и сам по себе не останавливает plan или apply. Блоки precondition и postcondition могут блокировать выполнение. Ошибки провайдера здесь не рассматриваются.

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

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

Алерт Prometheus уже в состоянии firing. Что даёт keep_firing_for: 5m, если его условие больше не выполняется?

👾 — Немедленно переведёт алерт в inactive
👍 — Сохранит firing на пять минут после последнего выполнения условия
🥰 — Задержит первое срабатывание на пять минут
⚡ — Увеличит scrape timeout на пять минут

Разбор:
👍. keep_firing_for удерживает уже сработавший алерт в firing в течение указанного времени после того, как условие выполнялось в последний раз. За ожидание перед первым срабатыванием отвечает for. Настройка не меняет тайм-аут сбора метрик.

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

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

Какое действие создаёт риск выполнения недоверенного кода в привилегированном workflow на pull_request_target для PR из fork?

👾 — Запустить доверенную проверку метаданных PR
👍 — Прочитать только номер и автора PR
🥰 — Получить код из PR и исполнить его в контексте базового репозитория
⚡ — Добавить комментарий без запуска кода из PR

Разбор:
🥰. pull_request_target запускает workflow в контексте базового репозитория. Если workflow получает и исполняет недоверенный код из PR, этот код может воспользоваться секретами или правами записи, доступными workflow. Конкретные права зависят от конфигурации. Само событие не исполняет присланный код автоматически.

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

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