Динозавр держится за ВМ и снапшоты по расписанию, Археолог давно не помнит, что и где у него крутится, а Повелителю облаков уютно до первого кругленького счёта. Это три из десяти типов инфраструктуры в тесте от команды Deckhouse.
Ответьте на 5 вопросов, узнайте свой тип и отправьте ссылку на результат команде. Посмотрим, совпадёт ли он у коллег.
Какой контейнер вернётся после перезапуска Docker?
Два отдельных контейнера Docker Engine успешно работали больше десяти секунд. У одного политика always, у другого unless-stopped. Оба остановили через docker stop, затем перезапустили Docker daemon. Кто запустится автоматически?
Ответ:
Контейнер с always запустится, с unless-stopped останется остановленным. Ручной docker stop подавляет автоматический рестарт, поэтому always не заставит контейнер немедленно ожить. Но после перезапуска daemon эта политика снова запустит его. У unless-stopped ручная остановка сохраняется и после перезапуска daemon. Это поведение отдельных контейнеров, не политик Swarm services.
В одном репозитории запуски A, B и C используют одну concurrency group. A выполняется, B ожидает, затем в группу приходит C. Указано cancel-in-progress: false, свойство queue не задано. Выполнятся ли все три?
Ответ:
Нет. По умолчанию queue: single оставляет только один ожидающий запуск. C заменит B, а B будет отменён. A продолжит работу: cancel-in-progress: false защищает выполняющийся запуск, но не ожидающий. В текущей документации GitHub Actions есть queue: max для очереди до 100 ожидающих запусков. Его нельзя сочетать с cancel-in-progress: true.
Авторитетный DNS-сервер уже возвращает новую A-запись. Рекурсивный резолвер, к которому обращались до её создания, продолжает отвечать NXDOMAIN. Что проверить?
Ответ:
Отрицательный DNS-кеш: резолвер мог сохранить ответ об отсутствии имени. По RFC 2308 исходный TTL такого ответа равен меньшему из SOA.MINIMUM и TTL самой SOA. Короткий TTL новой A-записи уже сохранённый NXDOMAIN не обновляет. Сравните ответы авторитетного сервера и нужного резолвера, посмотрите оставшийся TTL SOA в секции authority. У самого резолвера могут быть дополнительные ограничения времени кеширования.
Forbid у CronJob гарантирует выполнение ровно один раз?
Расчёт запускается каждые пять минут через CronJob. Вы указали concurrencyPolicy: Forbid. Достаточно ли этого, чтобы каждый расчёт выполнился ровно один раз?
Ответ:
Нет. Forbid запрещает перекрытие Jobs одного CronJob. Если предыдущий Job ещё работает, новый в этот момент не запускается. После завершения возможен отложенный запуск с учётом startingDeadlineSeconds. Сам CronJob не гарантирует exactly-once: для одного времени расписания могут появиться два Job или ни одного. Обработку нужно делать идемпотентной, а внешние эффекты защищать от повторов. На Jobs других CronJob эта политика не распространяется.