22 января 2016 года в werf был сделан первый коммит, а уже сегодня проекту исполняется 10 лет. В честь юбилея вспомним ключевые даты, события и достижения, похвастаемся отзывами пользователей и клиентов, а ещё поделимся полезными ссылками.
Но начнём с цифр, которых удалось достичь за эти десять лет:
18 000+ активных проектов, использующих werf (5000+ проектов наших клиентов, 13 000+ пользователей в сообществе)
4600+ звёзд на GitHub
1300+ релизов
6000+ закрытых pull requests
15 000+ коммитов
60+ контрибьюторов
Экосистема продуктов werf
Nelm — 1000+ ⭐, 45 релизов, 800+ коммитов
kubedog — 700+ ⭐, 38 релизов, 650+ коммитов
lockgate — 250+ ⭐, 2 релиза, 95+ коммитов
А теперь, если готовы углубиться, впереди подробный рассказ о ключевых событиях и достижениях, которые сформировали werf за десять лет. Главные точки — на таймлайне, а подробности и другие важные даты — в тексте:
v0 (22.01.2016 – 14.12.2018)
22.01.2016 — первый коммит
Проект стартовал под названием dapp и развивался как инструмент для эффективной сборки контейнерных образов в CI/CD-процессах. Изначальный фокус был на инкрементальности, при которой результаты предыдущих сборок переиспользуются.
Первая реализация была написана на Ruby, а конфигурация сборки всех образов описывалась в файле Dappfile, использующем императивный DSL на Ruby — по духу близкий к Vagrantfile:
dimg 'symfony-demo-app' do
docker.from 'ubuntu:16.04'
git do
add '/' do
to '/demo'
stage_dependencies.before_setup 'composer.json', 'composer.lock'
end
end
shell do
before_install do
run 'apt-get update',
'apt-get install -y curl php7.0',
# Пользователь phpapp.
'groupadd -g 242 phpapp',
'useradd -m -d /home/phpapp -g 242 -u 242 phpapp'
end
install do
run 'apt-get install -y php7.0-sqlite3 php7.0-xml php7.0-zip',
# Установка composer.
'curl -LsS https://getcomposer.org/download/1.4.1/composer.phar -o /usr/local/bin/composer',
'chmod a+x /usr/local/bin/composer'
end
before_setup do
# Исходным текстам нужно сменить права и запустить composer install.
run 'chown phpapp:phpapp -R /demo && cd /demo',
"su -c 'composer install' phpapp"
end
setup do
# Используем текущую дату как версию приложения.
run 'echo `date` > /demo/version.txt',
'chown phpapp:phpapp /demo/version.txt'
end
end
# Порт совпадает с портом, указанным в start.sh.
docker.expose 8000
endКлючевой особенностью стала stage-based модель сборки: каждая инструкция приводила к созданию отдельного Docker-образа (stage). Эта модель легла в основу оркестрации сборок и эффективного кеширования. Уже в первой версии поддерживалась сборка произвольного количества образов с общей конфигурацией и параллельным выполнением.
26.06.2016 — продвинутые инструменты отладки сборки
Довольно рано в проекте появились инструменты отладки сборки. Они позволяли интерактивно подключаться к контейнеру на любой стадии сборки — до выполнения инструкций, после них или в момент ошибки. Такой подход значительно упростил разработку и отладку сложных сценариев сборки и стал одной из отличительных черт dapp на тот момент.
29.07.2016 — поддержка Chef для описания сборочных инструкций
По мере роста сложности сборок стало очевидно, что описывать модульную логику на чистом shell неудобно. В ответ на это в dapp была добавлена поддержка Chef, который на тот момент широко использовался у нас в компании. Это позволило применять Chef-рецепты внутри процесса сборки образов, не оставляя в финальном образе следов Chef или cookbook’ов. Так появился мощный механизм модульности и переиспользования логики сборки.
dimg do
docker.from 'ubuntu:16.04'
git.add('/').to('/app')
docker.workdir '/app'
docker.cmd ['/bin/bash', '-lec', 'bundle exec ruby app.rb']
docker.expose 4567
chef do
cookbook 'apt'
cookbook 'rvm'
recipe 'ruby'
recipe 'bundle_gems'
recipe 'app_config'
end
end08.11.2016 — «Собираем Docker-образы быстро и удобно» на конференции HighLoad++ 2016
Это был первый публичный анонс проекта. Доклад тогда посвятили требованиям к Docker-образам в CI/CD: частым сборкам на каждый коммит, управлению размером образов, эффективному использованию места в container registry и важности использования одного и того же образа на всех этапах доставки — от тестовых окружений до production. На этом фоне был представлен подход dapp: на конференции рассказали, почему для решения этих задач был создан собственный сборщик и какие архитектурные принципы легли в его основу.
30.03.2017 — развёртывание в Kubernetes через системный Helm
В 2017 году в dapp появилось развёртывание в Kubernetes. Процесс был реализован через вызов системного Helm и предполагал наличие чарта по зарезервированному пути .helm. При этом dapp не ограничивался простым вызовом Helm: сборка и развёртывание начали связываться на уровне шаблонов за счёт специальных Helm-функций для работы с образами, а также был реализован базовый механизм отслеживания состояния ресурсов во время выката.
Как с помощью dapp (werf) и Helm развернуть Docker-образ приложения в локальном кластере Kubernetes
06.06.2017 — «Наш опыт с Kubernetes в небольших проектах» на конференции RootConf 2017
Доклад был посвящён практическому опыту использования Kubernetes в небольших проектах: как выстроить CI/CD-процесс, организовать сборку Docker-образов, работу с окружениями и развёртывание в кластер. На реальном примере показывалось, как Kubernetes и сопутствующие инструменты, включая dapp, встраиваются в повседневный процесс разработки и выката.
07.11.2017 — «Лучшие практики CI/CD с Kubernetes и GitLab» на конференции HighLoad++ 2017
На примере реальных CI/CD-пайплайнов в Kubernetes и GitLab в докладе разбирались типовые проблемы доставки приложений. В этом контексте показывалось, какую роль играет dapp и как он помогает решать задачи инкрементальной сборки образов, тегирования и управления процессом развёртывания в Kubernetes.
04.12.2017 — умная очистка container registry от неактуальных образов
С ростом числа сборок и тегов встал вопрос очистки container registry. В конце 2017 года в dapp появилась функция очистки container registry. Был реализован механизм очистки по различным политикам (по веткам, коммитам и тегам) с учётом фактического использования образов в Kubernetes (в последующих версиях умная очистка продолжала активно развиваться).
О том, какие вызовы стоят при очистке container registry, и подробнее про наш подход можно почитать здесь.
23.03.2018 — поддержка YAML-конфигурации и Ansible для описания сборочных инструкций (на смену Chef)
На этом этапе dapp эволюционировал в сторону более удобного и привычного для YAML-инженеров подхода: появилась поддержка YAML-формата. Переход от императивного Ruby-DSL к декларативному синтаксису сделал конфигурации более читаемыми, предсказуемыми и удобными для сопровождения, особенно в сложных проектах.
Параллельно произошёл отказ от Chef в пользу Ansible для описания сборочных инструкций. Chef оказался слишком тяжёлым и не оправдал первоначальных ожиданий, тогда как Ansible позволил сохранить модульность и декларативность, но с меньшим порогом входа и более прозрачным исполнением.
dimg: ~
from: alpine:latest
git:
- add: /
to: /app
owner: app
group: app
excludePaths:
- public/assets
- vendor
- .helm
stageDependencies:
install:
- package.json
- Bowerfile
- Gemfile.lock
- "app/assets/*"
- url: https://github.com/kr/beanstalkd.git
add: /
to: /build
ansible:
beforeInstall:
- name: "Create non-root main application user"
user:
name: app
comment: "Non-root main application user"
uid: 7000
shell: /bin/bash
home: /app
- name: "Disable docs and man files installation in dpkg"
copy:
content: |
path-exclude=/usr/share/man/*
path-exclude=/usr/share/doc/*
dest: /etc/dpkg/dpkg.cfg.d/01_nodoc
install:
- name: "Precompile assets"
shell: |
set -e
export RAILS_ENV=production
source /etc/profile.d/rvm.sh
cd /app
bundle exec rake assets:precompile
args:
executable: /bin/bash
О переходе dapp на YAML и добавлении поддержки Ansible — смотрите статью «Дождались: поддержка YAML и Ansible (без коров) в dapp».
03.04.2018 — Linux-дистрибутив from scratch для сборки Docker-образов — наш опыт с dappdeps
Мы поделились деталями внутренней архитектуры сборки, уже сформированной к тому моменту. В публикации рассказывалось, как dapp отделяет сборочную среду от конечного Docker-образа и за счёт этого позволяет использовать Ansible, Chef и другие инструменты сборки независимо от базового образа, включая scratch.
Идея и реализация dappdeps — в этой публикации.
23.11.2018 — поддержка секретных значений и файлов для конфигурации развёртывания
В dapp появилась поддержка секретных значений и секретных файлов для конфигурации развёртывания. Это решало проблему безопасного хранения и использования чувствительных данных — токенов, ключей доступа, TLS-сертификатов и приватных ключей — без их размещения в открытом виде в Git (Helm-чартах). Секреты расшифровывались только на этапе деплоя и использовались в шаблонах и манифестах Kubernetes.
23.01.2018 – 14.12.2018 — бесшовная миграция с Ruby на Go
По мере роста проекта и расширения сценариев использования, а также на фоне запросов от пользователей стало ясно, что текущая реализация на Ruby начинает ограничивать дальнейшее р��звитие — была начата миграция на Go.
Переход выполнялся поэтапно и бесшовно для пользователей, что позволило не останавливать развитие продукта и сохранить его стабильность. В результате удалось снять накопившиеся ограничения и упростить интеграцию с экосистемой Kubernetes.
Подробнее о поэтапной миграции dapp с Ruby на Go — в статье о том, как мы переписали dapp на Golang, не останавливая разработку.
23.10.2018 — вынесение отслеживания при развёртывании в отдельный проект — kubedog
Логика отслеживания развёртывания (статусы, события и логи, а также управление ожиданием готовности ресурсов) была вынесена из dapp в отдельный продукт — kubedog.
Выделение kubedog в самостоятельную библиотеку позволило изолировать эту функциональность, переиспользовать её в других инструментах и развивать механизмы наблюдения независимо от основного продукта. В дальнейшем kubedog стал использоваться как внутри экосистемы werf, так и сообществом в других проектах.
Читайте подробности о библиотеке kubedog для слежения за ресурсами Kubernetes.
v1 (14.12.2018 – 06.03.2020)
14.01.2019 — новое название — werf
В этот момент проект получил новое имя — werf. Процесс выбора нового названия сделали максимально открытым: в обсуждении и голосовании участвовала вся компания, а также внешнее сообщество. Всего было предложено около 100 вариантов — от морской и пиратской тематики до более абстрактных и технических названий.
По итогам голосования сформировались три фаворита:
grog — 32 %;
flimb — 29,7 %;
werf — 27 %.
Несмотря на то, что werf не занял первое место по числу голосов, именно это название было выбрано командой. Оно лучше всего отражало суть проекта и ассоциировалось с местом сборки и создания — верфью, что органично легло в дальнейшее развитие бренда.
Представляем werf 1.0 stable: при чём тут GitOps, статус и планы
22.01.2019 — менеджер обновлений werf (multiwerf)
multiwerf реализовал наш подход к работе с версиями в рамках каналов обновлений. Он отвечал не только за автообновление werf, но и за изоляцию версии в рамках shell-сессии.
Команда $(multiwerf use 1.1 stable --as-file) автоматически обновляет werf в фоне в рамках заданного канала обновлений и «пинит» версию для текущей shell-сессии, позволяя без конфликтов использовать разные версии werf на одном хосте.
23.01.2019 — werf стал доступен на всех основных ОС
С этого момента werf начал тестироваться и распространяться для всех основных операционных систем (Linux, macOS, Windows).
18.04.2019 — начинаем использовать и развивать собственный форк Helm
Одним из архитектурных решений версии v1 стало встраивание Helm непосредственно в бинарник werf. Этот шаг позволил быстрее развивать функциональность и оперативно доносить ценность до пользователей, не дожидаясь изменений в upstream.
Helm client и Tiller выполнялись внутри одного процесса werf во время деплоя — без необходимости установки каких-либо компонентов в Kubernetes-кластер. Это решение обеспечивало полную совместимость с Helm 2, но при этом снимало большинство его эксплуатационных ограничений и повышало безопасность.
Подобная архитектура стала стандартной для Helm лишь позже — с выходом Helm 3 в ноябре 2019 года, когда Tiller был полностью удалён из проекта.
Вместо использования Helm как «чёрного ящика» с флагом --wait и внешней обвязки началась полноценная сквозная интеграция отслеживания ресурсов при выкате на базе kubedog — статусы, события, логи, мгновенное завершение проблемных выкатов.
27.05.2019 — «werf — наш инструмент для CI/CD в Kubernetes» на конференции DevOpsConf 2019
Доклад был посвящён практическому применению GitOps-подхода в CI/CD с Kubernetes и werf. На реальных сценариях разбиралось, как использовать Git в качестве единственного источника истины, организовать декларативное управление состоянием кластера и встроить werf в GitOps-workflow для более предсказуемого и управляемого развёртывания.
15.08.2019 — реализация 3-way merge в рамках нашего форка Helm 2
Реализация 3-way merge в нашем форке Helm 2 позволила более корректно применять изменения к уже существующим ресурсам, учитывая их текущее состояние в кластере. Также для повышения надёжности werf ввёл блокировки параллельного деплоя одного и того же релиза. Это защищало от гонок и неконсистентных состояний, которые могли возникать при одновременных выкатах.
Эта функциональность появилась в werf до выхода Helm 3 и значительно повысила предсказуемость и безопасность обновлений наших пользователей.
Подробности про внедрение поддержки 3-way-merge-патчей в werf
23.08.2019 — первая 1000 звёзд на GitHub
Проект преодолел отметку в 1000 звёзд на GitHub, что стало заметным сигналом роста интереса и признания со стороны Open Source-сообщества.
21.09.2019 — добавлена поддержка Dockerfile
Добавлена поддержка Dockerfile, что стало важным шагом навстречу пользователям и упростило миграцию. werf научился работать как с собственным синтаксисом Stapel, так и с классическими Dockerfile.
Собирать Docker-образы в werf теперь можно и по обычному Dockerfile
13.12.2019 — вынесение распределённых блокировок в отдельный проект
Из werf была вынесена Go-библиотека, предназначенная для реализации распределённых блокировок — lockgate. Она поддерживает как локальные файловые блокировки, так и распределённые механизмы на базе Kubernetes или HTTP-сервера блокировок, что позволяет использовать её в самых разных инфраструктурных сценариях.
Библиотека нашла отклик в сообществе, получила внешние контрибуции и стала использоваться в сторонних проектах (более 250 ⭐ на GitHub), подтвердив свою универсальность за пределами werf.
v1.1 (06.03.2020 – 05.11.2020)
#03.03.2020 — content-based-тегирование
Появилась поддержка content-based-тегов. Это заложило основу для последующего отказа от контекстных стратегий тегирования (ветки, коммиты, CI) и перехода к единому подходу в работе с образами — на уровне конфигурации, очистки и хранения — и к более эффективному использованию container registry.
Релиз werf 1.1: улучшения в сборщике сегодня и планы на будущее
Content-based tagging в сборщике werf: зачем и как это работает?
24.04.2020 — распределённое хранилище слоёв на базе container registry
С этого момента werf взял на себя ответственность за синхронизацию работы параллельных сборщиков, использующих один и тот же container registry. Механизм был построен по аналогии с тем, как Docker работает с локальным хранилищем: при сохранении, подборе и обеспечении иммутабельности слоёв.
Разница заключалась в масштабе: если Docker синхронизирует процессы, работающие с локальным хранилищем на одном хосте, то werf реализовал тот ж�� принцип распределённо, обеспечивая корректную работу нескольких сборщиков, параллельно взаимодействующих с одним container registry.
20.05.2020 — «Introduction to werf: Another view on GitOps» на онлайн-конференции GitOps Days 2020
В докладе werf рассматривался как практический инструмент доставки в Kubernetes с собственным взглядом на GitOps: связка сборки и развёртывания, контроль состояния ресурсов, воспроизводимость выката и ориентация на реальные эксплуатационные сценарии — ещё до того, как термин GitOps окончательно устоялся.
v1.2 (05.11.2020 – 24.04.2024)
15.12.2020 — добавлена поддержка бандлов
Появляется поддержка бандлов — способа дистрибуции Helm-чарта и связанных с ним контейнерных образов как единого артефакта. Бандл упаковывает всё необходимое для развёртывания приложения и может распространяться и использоваться независимо от исходного Git-репозитория.
Опубликованный бандл можно развёртывать с помощью werf или любых инструментов, поддерживающих Helm-чарты из OCI-репозиториев (Helm, Argo CD, Flux и др.). Его можно копировать между container registry, экспортировать в tar-архив, передавать офлайн и использовать в air-gapped-окружениях. При упаковке werf автоматически добавляет в чарт информацию об образах и их тегах, переданные значения, а также глобальные аннотации и лейблы, обеспечивая воспроизводимое и автономное развёртывание — всё как обычно для пользователей werf, но уже без привязки к Git-репозиторию проекта.
werf v1.2 — стабильный релиз Open Source-утилиты для доставки приложений в Kubernetes
#05.04.2021 — безопасный менеджер обновлений на смену multiwerf (trdl)
На смену multiwerf пришёл trdl (true delivery) — менеджер обновлений, ориентированный на безопасную доставку бинарников от Git-репозитория до хоста пользователя. trdl был спроектирован как защищённый канал обновлений, который устраняет целый класс рисков, связанных с подменой, компрометацией или неконтролируемым распространением артефактов.
Безопасность trdl основана на связке Git, TUF-репозитория и HashiCorp Vault. Такая архитектура позволяет предотвращать атаки на цепочку поставки, проверять целостность и подлинность обновлений и минимизировать потенциальный ущерб даже в случае компрометации отдельных компонентов.
trdl не ограничивается werf и может применяться для безопасного выпуска и распространения произвольного ПО. CLI поддерживает широкий набор сценариев, но ключевой подход обновления и использования, знакомый по multiwerf, был полностью унаследован:
. "$(trdl use werf 1.2 stable)"Команда обновляет, верифицирует и активирует нужную версию werf в рамках текущей shell-сессии, позволяя безопасно использовать разные версии на одном хосте без конфликтов.
Подробнее о системе безопасной доставки ПО — в статье про trdl.
22.12.2021 — представляем онлайн-самоучитель по Kubernetes и деплою с werf для разработчиков
Запустили онлайн-самоучитель, ориентированный на разработчиков и DevOps-инженеров, которые хотят освоить Kubernetes и практическую доставку приложений с помощью werf. Материалы совмещают теорию и пошаговые практические руководства — от базовых концепций до более продвинутых сценариев CI/CD.
Самоучитель учитывает специфику популярных языков и фреймворков, включает примеры приложений и инфраструктуры (IaC) и позволяет выбрать технологический стек, наиболее близкий пользователю, для изучения Kubernetes и работы с werf на реальных примерах.
О запуске онлайн-самоучителя по Kubernetes и деплою с werf для разработчиков писали здесь.
07.02.2022 — безопасная сборка без привилегированного демона
В werf появилась экспериментальная поддержка Buildah, позволившая выполнять безопасную сборку образов в rootless-режиме без использования Docker-демона, а также сохранить привычный сценарий сборки через Docker там, где это необходимо.
Одновременно в релизном процессе werf появились готовые к использованию образы для запуска сборок как с Docker, так и непосредственно внутри Kubernetes-кластера. Это упростило интеграцию werf в различные CI/CD-окружения и расширило варианты его использования.
05.08.2022 — появилась телеметрия
В werf была добавлена телеметрия, позволяющая анализировать использование инструмента. Она охватывает версии и каналы обновлений, активность проектов, окружения выполнения, использование CLI-команд и характеристики сборок.
Телеметрия стала основой для лучшего понимания того, как werf используется на практике: оценки стабильности версий и выявления узких мест в процессах доставки.
13.12.2022 — werf стал проектом CNCF
Проект werf был принят в CNCF (Cloud Native Computing Foundation), что означает его признание и поддержку в экосистеме облачно-нативных технологий. Это подтверждает зрелость проекта, его открытость и готовность к широкому использованию в сообществе, а также способствует ещё более активному участию сообщества в развитии werf и интеграции с другими CNCF-инструментами.
Читайте о том, что означает для werf вступление в CNCF и какие у команды были планы на старте этого этапа.
19.03.2023 — «Better CI/CD experience in Kubernetes with werf. Practical cases» на конференции KCD Czech & Slovak 2023
На конференции KCD Czech & Slovak 2023 был представлен доклад «Better CI/CD experience in Kubernetes with werf. Practical cases». В нём werf был показан как Open Source-инструмент (к тому моменту уже проект CNCF), объединяющий Git, контейнеры и Kubernetes для построения эффективной и консистентной доставки.
Доклад посвятили практическим кейсам использования werf в CI/CD: типичным проблемам современной доставки в Kubernetes, наблюдениям из реального опыта внедрения в разных организациях и тому, как существующие Open Source-инструменты и лучшие практики помогают Ops-командам решать эти задачи на практике.
19.04.2023 — участие проекта в KubeCon Europe 2023
Проект werf впервые представлен на главной конференции мирового Cloud Native-сообщества — KubeCon + CloudNativeCon Europe 2023. По любым вопросам об использовании werf можно было проконсультироваться на протяжении трёх дней у его киоска в павильоне CNCF Project Pavilion.
18.05.2023 — отказ от форка Helm и начало разработки Nelm
С первым коммитом Nelm начался новый этап развития механизма развёртывания в werf. К э��ому моменту стало очевидно, что дальнейшее развитие собственного форка Helm ограничено архитектурой самого Helm, поэтому было принято решение отказаться от форка и переписать подсистему развёртывания заново, сохранив при этом обратную совместимость.
28.07.2023 — первая онлайн-встреча с сообществом
Состоялась первая публичная онлайн-встреча с сообществом в формате живого обсуждения и Q&A. На встрече команда рассказала о текущем состоянии проекта, планах развития и ответила на вопросы.
05.03.2024 — «От доработки Helm к разработке Nelm: эволюция развёртывания в werf» на конференции DevOpsConf 2024
На конференции DevOpsConf 2024 был представлен доклад «От доработки Helm к разработке Nelm: эволюция развёртывания в werf». В нём был разобран практический путь, который привёл команду werf от расширения и форка Helm к созданию Nelm — обратно совместимой альтернативы Helm, разработанной с учётом реальных требований к инструменту развёртывания.
В докладе были показаны ключевые улучшения Nelm по сравнению с Helm: отображение плана изменений перед деплоем, более корректное и управляемое обновление ресурсов, продвинутое отслеживание готовности (включая CRD), наглядный вывод статусов, логов и событий, а также устранение классов проблем, приводящих к некорректным обновлениям. Отдельно затронули долгосрочные планы развития и ближайшие направления эволюции механизма развёртывания в werf.
20.03.2024 — участие проекта в KubeCon Europe 2024
Киоск с werf снова был представлен в CNCF Project Pavilion на европейской конференции KubeCon + CloudNativeCon 2024, что проходила в Париже. В этот раз с сообществом встречался Максим Набоких, который не без причин считает себя амбассадором werf.
v2 (24.04.2024 — …)
Вышла werf 2.0: новый движок развёртывания Nelm и 300+ релизов за четыре года
25.02.2025 — You Choose show by two CNCF Ambassadors
werf принял участие в выпуске You Choose! (Ch. 05, Ep. 05), посвящённом теме Specialized Templating, вместе с довольно разнородным набором инструментов (Porter, Radius, Score, PipeCD). Формат был необычный, а продукты — неочевидно сопоставимые, но за отведённые 5 минут удалось рассказать про werf и поучаствовать в дискуссии о подходах к доставке приложений на такой интересной площадке.
13.03.2025 — «werf and its ecosystem: efficient software delivery in Kubernetes and beyond» на FOSSASIA Summit 2025
На конференции FOSSASIA Summit 2025 (Bangkok, Thailand) коллега из Palark представил доклад «werf and its ecosystem: efficient software delivery in Kubernetes and beyond». В нём werf был показан как CNCF Sandbox-проект, реализующий эффективный и консистентный CI/CD в Kubernetes на базе Open Source-технологий.
Доклад охватывал эволюцию werf за почти девять лет: от CLI-инструмента для сборки и деплоя контейнеров до полноценной экосистемы, включающей обучающие материалы по Kubernetes, инструменты для безопасной дистрибуции ПО (trdl), библиотеку для отслеживания Kubernetes-ресурсов (kubedog) и собственную альтернативу Helm — Nelm.
20.03.2025 — релиз Nelm 1.0
Состоялся релиз Nelm 1.0 — стабильной версии обратно совместимой с Helm-чартами альтернативы Helm 3. Nelm поставляется как самостоятельный CLI-инструмент, а также как библиотека для встраивания в другие решения.
27.11.2025 — сравнение Nelm и Helm 4
Рассказали, как Nelm продолжает развиваться даже после релиза Helm 4, оставаясь альтернативой с более широкими возможностями и своей аудиторией.
Nelm vs Helm 4: что изменилось с новым релизом Helm и почему Nelm всё ещё лучше
22.01.2026 — 10 лет werf
Проекту werf исполнилось 10 лет. За это время он прошёл путь от эксперимента со инкрементальной сборкой Docker-образов до зрелой Open Source-экосистемы для доставки приложений в Kubernetes, включающей собственные решения сборки, развёртывания и дистрибуции, а также ряд других самостоятельных проектов.
Наши планы
И на этом наша работа не заканчивается, ведь у нас грандиозные планы:
Новая архитектура сборки на базе глубокой интеграции с BuildKit.
Безопасность цепочки поставки: подпись и верификация, SBOM, работа с уязвимостями.
Nelm-оператор для интеграции с Argo CD, Flux и самостоятельного использования (Issues #494).
Патчинг ресурсов Helm-чарта (Issues #115).
Альтернатива (не замена!) Helm-шаблонам — эксперимент с TypeScript уже вот-вот можно будет попробовать (PR # 502, Issues #54).
…и многое другое.
Слова благодарности от компаний и сообщества
За 10 лет werf вошёл в повседневную практику сотен команд. Среди пользователей есть такие компании, как «Альфа-Лизинг», Lenta-online, «Цифровая Лаборатория», Adapty, «Оператор Газпром ИД», MCN Telecom, AYA Group и другие.
А ниже — приятные слова от компаний и участников сообщества, которые делятся своим опытом, пользой и даже идеями для будущего развития проекта.
Евгений Агеев, СТО из ООО «Премиум Бонус»
Мы используем werf с 2019 года и применяем его во всех проектах для сборки и деплоя приложений. Нам нравится простота конфигурации, удобное хран��ние секретов, подход «всё в одном» и то, что для деплоя не требуются сложные CI/CD-пайплайны — достаточно нескольких понятных команд.
К юбилею проекта хотим поблагодарить компанию «Флант» и команду werf за зрелый и надёжный инструмент, который действительно упрощает работу с продакшеном!
Тимур Попов, CTO из xRocket
С werf я знаком около 5 лет, и за это время он стал моим фаворитом. В xRocket мы используем его примерно 1,5 года, с перехода на Deckhouse. Для бизнеса, и особенно для стартапа, это отличный выбор: один инструмент закрывает сборку и деплой в Kubernetes и избавляет от зоопарка скриптов и утилит.
К юбилею желаю проекту развиваться, сохраняя простоту и стабильность.
Aliaksandr Padrabinkin, Lead DevOps из Godel Technologies Europe
werf используем около 2–3 лет. werf v2 — основной инструмент CI/CD на нашей платформе, работающей на Azure с 6 окружениями. Мы используем его для управления более чем 30 репозиториями в рамках multi-tenant-архитектуры с множеством Kubernetes namespace'ов, а также для сборки Docker-образов (werf build) — все сервисы платформы (.NET 8/10, Node.js 20/22). Благодаря шаблонам один и тот же процесс работает для разных технологий. А ещё с его помощью деплоим в Kubernetes (werf converge) — все 6 окружений нашей платформы.
Ключевые факторы выбора werf:
GitOps и Giterminism — строгий подход, когда вся конфигурация деплоя живёт в Git. Для нашей multi-tenant-платформы с множеством namespace'ов важно, чтобы любое изменение было отслеживаемым и воспроизводимым для соответствия требованиям SOX-аудита.
Интеграция с Helm — Nelm позволяет использовать Helm-чарты без лишних обёрток, с нативным release management. Мы поддерживаем несколько технологий (.NET 8/10 и Node.js 20/22) через единую систему шаблонов, что значительно упрощает поддержку разнородного стека.
Идемпотентный converge — приводит кластер к состоянию Git, что критично для multi-tenant-платформы с десятками namespace'ов. Без этого управление состоянием десятков окружений было бы кошмаром.
Умное кеширование и инкрементальные сборки — Stapel builder экономит время на CI, особенно при частых коммитах. Это особенно важно при работе с более чем 30 репозиториями — без эффективного кеширования сборки занимали бы часы.
Встроенный cleanup — автоматическое управление retention в Container Registry с гибкими политиками. Интеграция с Azure Container Registry (ACR) и Azure DevOps Pipelines делает это полностью автоматизированным процессом.
Централизованная конфигурация — использование AppConfig submodule позволяет нам поддерживать единую конфигурационную базу для всех сервисов, при этом обеспечивая гибкость на уровне отдельных репозиториев.
Что ещё нравится в werf:
Content-based tagging — образы тегируются по content hash, что исключает проблемы с «грязными» тегами и обеспечивает точную идентификацию образов. Это критично для отслеживания, какая версия кода реально развёрнута в production.
Автоматическая генерация образов — через Go-шаблоны генерируются все необходимые образы. Так разработчикам не нужно писать и поддерживать Dockerfile'ы — всё автоматизировано.
Stapel builder — multi-stage builds с агрессивным кешированием значительно ускоряют сборки. Это экономит огромное количество времени на CI, особенно когда мы собираем множество сервисов параллельно.
Единый инструмент — build, deploy, cleanup в одной утилите без зоопарка скриптов. Не нужно поддерживать отдельные скрипты для сборки, деплоя и очистки — всё работает из коробки.
Прозрачность — понятные логи. Когда что-то идёт не так, легко понять, на каком этапе и почему.
Активная поддержка — быстрые реакции команды в чатах, учёт пожеланий пользователей. Это важно, когда работаешь с инструментом в production на таком масштабе.
Спасибо команде разработки за супербыстрые реакции и помощь в чатах поддержки! Отдельное спасибо за то, что слышите пользователей и учитываете наши пожелания.
Пожелание на будущее: хотелось бы видеть более гибкие возможности отслеживания состояния ресурсов через аннотации — это упростило бы интеграцию с мониторингом и кастомными контроллерами.
Илья Дяковецкий, технический директор в «Иксора»
Мы в компании «Иксора» используем werf более трёх лет, и для нас его ценность заключается не столько в самой утилите, сколько в инженерной идеологии команды «Фланта», которая за ней стоит. Werf стал логичным продолжением и популяризацией фундаментальных принципов работы с Kubernetes: декларативности, конвергентности, идемпотентности, детерминированности и других процессов деплоя.
Благодаря этому подходу CI/CD перестаёт быть набором хрупких скриптов и превращается в воспроизводимую, предсказуемую систему, понятную как инженерам, так и бизнесу. В нашей практике werf позволил унифицировать процессы деплоя, значительно снизить операционную сложность и высвободить время DevOps-специалистов для более ценных задач.
Хочется поблагодарить команду «Фланта» за последовательное продвижение правильных инженерных идей в Kubernetes-сообществе и пожелать проекту дальнейшего развития, роста сообщества и сохранения этого фокуса на качестве, прозрачности и инженерной культуре.
Максим Базуев, мобильный разработчик
Я использовал werf, когда выкатывал свои проекты. Почему выбрал именно его? Потому что он легко интегрируется, быстро настраивается и сразу работает так, как мне нужно. Для меня это сразу несколько инструментов в одном.
Он собирает образы, деплоит их и показывает, что происходит с подами — запустились ли они или возникла ошибка: с секретами, с чем-то ещё. В этом плане он мне очень нравится — состояние видно прямо в реальном времени. С Helm’ом же запустил — и всё: непонятно, работает оно или нет.
Марк Барзали, Software Engineer
Пользуюсь werf примерно с 2022 года. Решение использовать именно его пришло из-за all-in-one-подхода: минимальная настройка CI, отличная система кеширования и работы с тегами. Больше всего в werf нравятся поддержка GitOps-подхода и декларативность конфигурации — это идеально закрывает мои задачи по деплою.
Алексей Махонин, DevOps
Утилитой пользуюсь для своих личных проектов, а также там, где есть возможность её применения на работе. После выхода второй версии — просто огонь, полный контроль и понимание, что происходит при деплое (спасибо
werf plan). Плюс server-side apply решает большое количество проблем, связанных с ручными изменениями в кластере и three-way merge.
Вместо заключения
От всей души благодарим всех, кто был с нами эти 10 лет: пользователей, контрибьюторов, коллег из сообщества и наших клиентов. Без ваших вопросов, баг-репортов, пул-реквестов, кейсов, отзывов и просто веры в проект werf не стал бы тем, чем он есть сегодня. Спасибо, что выбираете нас — и продолжайте двигаться вперёд вместе с нами!
Если вы ещё не с нами, то вступайте в сообщество werf в Telegram:
Также свои предложения и вопросы можете приносить в GitHub и Slack проекта. А в блоге можно почитать все публикации про werf.
