Доставка приложения в Kubernetes предполагает его контейнеризацию (сборку одного или нескольких образов) для последующего развёртывания в кластере.
Для сборки пользователю необходимо описать сборочные инструкции в виде Dockerfile’а или альтернативного сборочного синтаксиса stapel, а остальное werf возьмёт на себя:
- оркестрация одновременной/параллельной сборки образов приложения;
- кроссплатформенная и мультиплатформенная сборка образов;
- общий кеш промежуточных слоёв и образов в container registry, доступный с любых раннеров;
- оптимальная схема тегирования, основанная на содержимом образа, предотвращающая лишние пересборки и время простоя приложения при выкате;
- система обеспечения воспроизводимости и неизменности образов для коммита: однажды собранные образы для коммита более не будут пересобраны.
Парадигма сборки и публикации образов в werf отличается от парадигмы, предлагаемой сборщиком Docker, в котором есть несколько команд: build, tag и push. werf собирает, тегирует и публикует образы в один шаг. Данная особенность связана с тем, что werf по сути не собирает образы, а синхронизирует текущее состояние приложения (для текущего коммита) с container registry, дособирая недостающие слои образов и синхронизируя работу параллельных сборщиков.
В общем случае сборка образов в werf предполагает наличие container registry (--repo), поскольку образ не только собирается, но и сразу публикуется. При этом ручной вызов команды werf build не требуется, так как сборка выполняется автоматически при запуске всех верхнеуровневых команд werf, в которых требуются образы (например, werf converge).
Однако ручной запуск команды werf build может быть полезным во время локальной разработки. В этом случае сборку можно запускать отдельно и без участия container registry.
