При деплое в Kubernetes часто требуется выкатывать ресурсы в определённом порядке, а иногда и дожидаться готовности сторонних ресурсов. Например, сначала нужно запустить БД, дождаться создания динамического Secret’а сторонним оператором, потом выполнить инициализацию/миграции БД, а уже затем запустить само приложение.  Рассмотрим, как решать такие задачи с помощью Helm, а также сравним с более быстрым и удобным вариантом, который предлагает Open Source-утилита werf. Когда возникает необходимость указать порядок, в котором должны быть запущены приложения в кластере, встает вопрос: как это правильно сделать? В Helm задать последовательность выката ресурсов довольно сложно: в основном это делается либо через самодельные проверки готовности требуемых ресурсов в initContainers/containers, либо через разделение одного Helm-релиза на несколько частей и их последовательный выкат. Оба способа неудобны и требуют лишних действий.  Рассмотрим развертывание ресурсов в произвольном порядке. Для этого возьмем простой пример с базой данных и реализуем ожидание БД с помощью initContainers: В этом примере реализован такой порядок:  развертывание БД; инициализация или миграции БД; развертывание приложения. Здесь есть особенность: перед тем, как начинать деплой, нам необходимо убедиться, что динамически создающийся (например, оператором на основе секретов из Vault) Secret my-dynamic-secret присутствует в кластере. Поэтому сначала дождемся его создания, а затем начнем деплой приложения: Теперь посмотрим, как можно решить эту задачу с werf. Более удобно реализовать упорядоченный выкат можно с утилитой werf. Недавно у нее появилась возможность задать порядок выката ресурсов с помощью аннотаций, через которые указывается «вес» ресурса. По умолчанию (если ничего не указано) все ресурсы имеют вес 0, поэтому разворачиваются и отслеживаются одновременно. Но если задать им разные веса, то при выкате werf сгруппирует ресурсы в соответствии с их весом и будет разворачивать их от группы с меньшим весом к группе с большим весом, ожидая, пока каждая группа не придет в состоянии полной готовности. Задать вес ресурсов можно через аннотацию werf.io/weight (по аналогии с helm.sh/hook-weight для Helm-хуков). Решим предыдущую задачу уже с использованием весов: Запустить развертывание теперь можно одной командой: Первыми задеплоятся база данных и Redis, затем произойдет инициализация или миграции БД, и только потом запустится приложение. Обратите внимание на аннотацию secret.external-dependency.werf.io/resource: "secret/my-dynamic-secret". Она добавлена к Deployment’у приложения и указывает, что перед созданием Deployment'а надо также дождаться готовности внешней зависимости — Secret’а my-dynamic-secret. При этом Secret может разворачиваться либо как часть другого релиза werf, либо вообще создаваться без werf (например, сторонним оператором).  Как видно, чарт приложения стал гораздо меньше и удобнее для чтения, а для запуска требуется выполнить одну команду. Мы рассмотрели управление порядком развертывания ресурсов в кластере Kubernetes с помощью новой функции утилиты werf. Она позволяет упростить сложный выкат приложений и быстрее писать чарты приложения, так как теперь нет необходимости реализовывать сложные проверки готовности его составных частей или внешних зависимостей. Читайте также в нашем блоге: «werf vs. Helm: корректно ли их вообще сравнивать?»; «Первые шаги с werf: собираем и деплоим простое приложение в Kubernetes»; «Новые возможности werf: CI/CD на основе werf и Argo CD».  Technical writer, Linux-user