- PVSM.RU - https://www.pvsm.ru -
Werf [1] — это GitOps CLI-утилита с открытым кодом [2] для сборки и доставки приложений в Kubernetes. Werf поддерживает сборку образов приложения с помощью Dockerfile или собственного встроенного сборщика (на основе синтаксиса YAML, с поддержкой Ansible и инкрементальной пересборки на базе Git). Для доставки приложения используется формат конфигурации, совместимый с Helm. Код приложения, конфигурация собираемых образов и конфигурация выката приложения хранятся в одном Git-репозитории.
Долгожданный стабильный релиз 1.0 [3] — это законченная по функциям базовая версия утилиты (точный номер версии первого стабильного релиза — это 1.0.6). В базовой версии werf поддерживает полный цикл доставки приложения и его сопровождения. Это включает в себя сборку образов приложения, деплой в Kubernetes, очистку неиспользуемых образов.
Важно, что в версии 1.0 все операции по одному проекту (build
, deploy
, cleanup
) должны выполняться с одного хоста. Это означает, что в CI-системе должен использоваться фиксированный worker. При этом нет никаких ограничений по параллельности заданий: werf этот вопрос полностью разруливает. Также можно распределить разные проекты по разным worker’ам.
В этой приуроченной к релизу статье мы подробнее рассмотрим, что предоставляет и не предоставляет данная версия, а также наши планы на будущие версии. Но начнём мы с того, что разберёмся в понимании термина «GitOps» и роли werf в процессах непрерывной интеграции и доставки приложений (CI/CD).
Итак, что мы подразумеваем под GitOps и какие области закрывает werf?
Термин «GitOps» придумали в компании Weaveworks около 2,5 лет назад, а статью от его авторов, раскрывающую суть этого нового явления, мы не так давно переводили [4] для блога. В нашем понимании, основная идея и основной смысл GitOps заключается в том, что Git является «единым источником истины» (single source of truth). В Git хранится:
А вот далее есть «нечто», которое делает так, чтобы реальность изменилась в соответствии с изменениями Git. Этот подход может быть реализован не только установкой некоторого оператора в Kubernetes, который следит за Git, но и с помощью консольной утилиты, которую можно вызывать из любой CI-системы. Более того, с нашей точки зрения, подход с CLI-утилитой не накладывает лишних ограничений: мы можем делать CI любым инструментом и с любым количеством нюансов, вызывая CLI-утилиту, которая синхронизирует «реальность» (т.е. Kubernetes) с состоянием Git.
Werf предоставляет высокоуровневый CLI-интерфейс с основными командами для сборки и публикации образов, доставки приложения и очистки образов: werf build-and-publish
, werf deploy
, werf dismiss
, werf cleanup
. Предполагается, что именно эти основные команды встраиваются в ту или иную CI-систему и обеспечивают необходимую синхронизацию с реальностью. Помимо этого, werf предоставляет и низкоуровневый CLI-интерфейс для управления разными подсистемами — см. low level management commands [5] в документации.
Не имеет значения, по push- или по pull-модели (подробнее о них читайте здесь [6]) будет работать весь выстроенный CI/CD, потому что werf можно встроить в любую модель. При этом werf закрывает такие проблемы, как работа с отдельными низкоуровневыми утилитами вроде git
, docker
и kubernetes api-server, являясь «недостающей частью» для конфигурирования унифицированного CI/CD приложений.
Если ваше приложение требует сборки Docker-образов, то с помощью werf 1.0 можно:
werf.yaml
;
Werf поддерживает два способа описания сборки: подключение в werf.yaml
существующих Dockerfile'ов и инструкции для сборщика Stapel. Сборка с помощью Stapel имеет свои преимущества: ускорение инкрементальной пересборки при изменении кода приложения в Git, использование синтаксиса Ansible для сборки и другие. Подробнее об этом сборщике и синтаксисе можно узнать в документации [7], а пример его использования представлен в руководстве [8].
Доступны разные схемы тегирования/версионирования собираемых образов с привязкой к Git-коммитам, веткам и тегам.
Сборка образов — это опциональный этап развёртывания приложения и может быть пропущен в случае отсутствия собственных собираемых образов.
Werf вводит такое понятие, как хранилище стадий (stages storage). Основные команды werf используют хранилище стадий следующим образом:
При развёртывании одного приложения должно быть использовано единое хранилище стадий для всех команд (сборка, публикация, очистка образов, развёртывание приложения).
В версии 1.0 в качестве хранилища стадий может выступать только локальное хранилище хоста (соответствующий параметр у команд: --stages-storage=:local
). При использовании :local
стадии хранятся на диске. Следствие из этого: werf 1.0 может быть использован только на одном хосте для организации развёртывания одного приложения. Этот хост должен сохранять данные между запусками команд для корректной работы werf.
В версии 1.0 отсутствует поддержка хранения стадий во внешнем хранилище, с помощью которого можно было бы организовать распределённую сборку. Однако такая функция появится в следующих версиях werf (подробнее об этом см. ниже).
Для выката приложения пользователь описывает чарт в формате, совместимом с Helm: набор манифестов Kubernetes и параметры шаблонизации.
Werf запускает приложение в Kubernetes и обеспечивает гарантию, что оно запустилось и функционирует, прежде чем завершить процесс выката приложения. Это включает в себя вывод логов компонентов и мгновенное реагирование на ошибки выката, когда что-то пошло не так — команда выката упадёт с ненулевым кодом. Таким образом, при использовании выката werf в CI/CD мы получаем адекватную обратную связь от софта: выкачено приложение или нет — и достаточно информации для отладки и исправления проблем (без необходимости запуска других утилит для поиска проблем вроде kubectl
).
Werf полностью совместим с уже существующими инсталляциями Helm 2, однако werf имеет ряд преимуществ перед ним. Например, в качестве механизма обновления ресурсов в Kubernetes используются патчи 3-way-merge [9], а также есть возможность получения обратной связи при доставке приложения в кластер. Полный список отличий описан на этой странице [10].
Werf интегрирует в единую систему собираемые образы, процесс их тегирования и версионирования с процессом доставки приложения в Kubernetes. Образы, которые собирает werf, можно использовать в шаблонах описания Kubernetes-ресурсов.
Именно за счёт этих функций можно говорить, что werf предоставляет более высокоуровневый интерфейс, чем Helm, Docker и другие сборщики и утилиты для деплоя в отдельности. Этот интерфейс позволяет просто интегрировать werf в любую существующую CI/CD-систему и не решать проблемы объединения всех используемых компонентов — эту задачу он берёт на себя.
В версии 1.0 доступна автоматическая интеграция только с системой GitLab CI [11]. Для этого предусмотрена команда werf ci-env
. Она получает необходимую информацию от CI/CD-системы и автоматически настраивает werf для корректной работы в CI-окружении.
Подробнее о том, как работает интеграция с любой CI/CD-системой, можно прочитать в мануалах (обзор [12], специфика GitLab CI [11], интеграция с другими системами [13]).
Werf 1.0 представляет собой статически слинкованный бинарный файл, который самостоятельно работает и с Docker, и с Helm-релизами. Внешние зависимости на хост-системе:
Werf может работать на любой из операционных систем и окружений GNU/Linux, Windows или macOS. Более того, результат сборки будет одинаков вне зависимости от используемой системы: одинаковые сигнатуры стадий кэша, одинаковое наполнение стадий вне зависимости от системы, где эту стадию собрали. Изменения в конфиге для работы в разных системах также не требуются.
Таким образом, werf 1.0 предоставляет средства кроссплатформенной сборки и доставки приложений в Kubernetes.
Здесь следует также отметить, что werf собирает стандартные Docker-образы для работы в Linux-окружении, но Windows-контейнеры [14] в версии 1.0 не поддерживаются.
На данный момент 60% кода werf покрыто интеграционными e2e-тестами и unit-тестами.
Werf тестируется на всех поддерживаемых ОС (Linux, Windows и macOS) с использованием GitHub Actions для организации их запуска. Все результаты тестирования доступны для просмотра на этой странице [15].
На данный момент, к выходу версии 1.0, в проекте было всего сделано около 700 релизов [16].
Werf использует продвинутую систему релизов с разбиением по каналам стабильности: alpha, beta, rc, ea (early access) и stable. Данный пост как раз приурочен к выходу первой версии 1.0 в канале stable. Нестабильные изменения в версию сначала проходят через цепочку каналов и в итоге оказываются в stable. Релизы делаются часто (порой по несколько за день) и изменения доставляются непрерывно «маленькими порциями».
Каналы стабильности и много частых релизов позволяют получить непрерывную обратную связь по новым изменениям, возможность быстро их откатить и в целом обеспечить высокую стабильность софта и при этом приемлемую скорость его развития.
Важный момент, что при переходе между версиями 1.0->1.1, 1.1->1.2 возможны такие изменения в werf, которые потребуют ручного вмешательства со стороны пользователя (это может быть скрипт миграции или просто инструкции для ручного выполнения, описанные в релизе). Обновление же версий внутри 1.0 (1.0.1, 1.0.2,… 1.0.6-alpha.1, 1.0.6-rc.2 и т.п.) гарантирует, что таких ручных изменений не потребуется.
Подробнее о backward compatibility promise можно прочитать здесь [17].
Вот как выглядят основные крупные направления работ для дальнейших версий и примерные сроки их реализации:
Главная цель — добится единого унифицированного конфига для развёртывания приложений как локально, так и в production, без сложных действий, «из коробки».
От werf также требуется такой режим работы, в котором будет удобно редактировать код приложения и мгновенно получать обратную связь от работающего приложения для дебага.
Версия 1.1, январь-февраль 2020 г.
Тегирование образов при их публикации, основанное исключительно на содержимом этого образа. В отличие от режимов с привязкой к Git-коммитам, данный режим позволит полностью избавится от лишних пересборок. Git-commit-id не является универсальным идентификатором содержимого worktree (хотя и зависит от него).
В случае, когда код приложения не менялся, но был сделан новый коммит, текущий режим тегирования по Git-коммитам создаст образ с новым именем при его публикации. Это повлечет за собой также перевыкат ресурсов, использующих этот образ в Kubernetes. При этом содержимое самого образа не менялось.
Чтобы решить эти проблемы, werf введёт новый тип тегирования, основанный на расчётах контрольных сумм содержимого приложения, — content-based tagging.
Версия 1.1, февраль-март 2020 г.
Включает в себя переход на новую кодовую базу Helm 3 [18] и проверенный, удобный способ миграции существующих установок.
Версия 1.1, февраль-март 2020 г.
На данный момент werf 1.0 собирает все стадии образов и артефактов, объявленных в werf.yaml
, последовательно. Требуется возможность распараллелить процесс сборки стадий.
Версия: 1.1, январь-февраль 2020 г.
На данный момент werf 1.0 возможно использовать лишь на одном выделенном хосте (см. пункт выше про хранилище стадий только на одном хосте).
Чтобы открыть возможности распределенной сборки, когда сборка запускается на нескольких хостах и эти хосты не сохраняют свое состояние между сборками (временные runner’ы), от werf требуется реализация возможности использования Docker Registry в качестве хранилища стадий.
Ранее, когда проект werf еще назывался dapp, в нем была такая возможность. Однако мы столкнулись с рядом проблем, которые необходимо учесть при реализации этой функции в werf.
Версия 1.2: март-апрель 2020 г.
Werf будет поддерживать описание конфигурации для Kubernetes в формате Jsonnet [19]. При этом werf останется совместимым с Helm и будет возможность выбора формата описания.
Причиной служит тот факт, что шаблоны языка Go, по оценке множества людей, имеют большой порог вхождения, и понятность кода этих шаблонов также страдает.
Также рассматривается возможность внедрения и других систем описания конфигурации Kubernetes (например, Kustomize).
Версия 1.1: январь-февраль 2020 г.
Цель: обеспечить сборку образов и доставку приложения с использованием runner’ов в Kubernetes. Т.е. сборка новых образов, их публикация, очистка и деплой может происходить прямо из pod’ов Kubernetes.
Чтобы реализовать эту возможность, сначала требуется возможность распределенной сборки образов (см. пункт выше).
Также требуется поддержка режима работы сборщика без Docker-демона (т.е. Kaniko-подобная сборка или сборка в userspace).
Werf будет поддерживать сборку в Kubernetes не только с помощью Dockerfile, но и с помощью своего сборщика Stapel с инкрементальными пересборками.
Версия 1.2: апрель-май 2020 г.
Также планируется:
beforeInstall
, install
, beforeSetup
, setup
);werf.yaml
, переход на configVersion: 2
(связано, в том числе, с двумя предыдущими пунктами), поддержка спецификации OpenAPI;werf.yaml
в главной master-ветке, — эти образы будут удаляться периодической очисткой);Буду краток в подведении итогов. Мы:
Выход версии 1.0 знаменует начало нового этапа разработки werf, в рамках которого будут добавлены принципиально новые возможности. Следите за новостями! А также присоединяйтесь к tg-каналу werf_ru [20], в жизни которого участвуют как непосредственные разработчики werf, так и наши инженеры, и пользователи утилиты вне компании «Флант».
Читайте также в нашем блоге:
Автор: tkir
Источник [27]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/open-source/343117
Ссылки в тексте:
[1] Werf: https://werf.io/
[2] открытым кодом: https://github.com/flant/werf
[3] стабильный релиз 1.0: https://github.com/flant/werf/releases/tag/v1.0.6
[4] переводили: https://habr.com/ru/company/flant/blog/458878/
[5] low level management commands: https://werf.io/documentation/cli/management/stages/build.html
[6] здесь: https://habr.com/ru/company/flant/blog/456754/
[7] узнать в документации: https://werf.io/documentation/reference/build_process.html#stapel-image-and-artifact
[8] руководстве: https://werf.io/documentation/guides/advanced_build/first_application.html
[9] патчи 3-way-merge: https://werf.io/documentation/reference/deploy_process/resources_update_methods_and_adoption.html
[10] этой странице: https://werf.io/documentation/reference/deploy_process/differences_with_helm.html
[11] системой GitLab CI: https://werf.io/documentation/reference/plugging_into_cicd/gitlab_ci.html
[12] обзор: https://werf.io/documentation/reference/plugging_into_cicd/overview.html
[13] интеграция с другими системами: https://werf.io/documentation/guides/unsupported_ci_cd_integration.html
[14] Windows-контейнеры: https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/
[15] этой странице: https://github.com/flant/werf/actions
[16] около 700 релизов: https://github.com/flant/werf/releases
[17] здесь: https://github.com/flant/werf#backward-compatibility-promise
[18] Helm 3: https://habr.com/ru/company/flant/news/t/475722/
[19] Jsonnet: https://jsonnet.org/
[20] tg-каналу werf_ru: https://t.me/werf_ru
[21] У werf появилась документация на русском языке: https://habr.com/ru/company/flant/news/t/478716/
[22] 3-way merge в werf: деплой в Kubernetes с Helm „на стероидах“: https://habr.com/ru/company/flant/blog/476646/
[23] Использование werf для выката комплексных Helm-чартов: https://habr.com/ru/company/flant/blog/468049/
[24] Поддержка monorepo и multirepo в werf и при чём здесь Docker Registry: https://habr.com/ru/company/flant/blog/465131/
[25] Собирать Docker-образы в werf теперь можно и по обычному Dockerfile: https://habr.com/ru/company/flant/blog/463613/
[26] werf — наш инструмент для CI/CD в Kubernetes (обзор и видео доклада): https://habr.com/ru/company/flant/blog/460351/
[27] Источник: https://habr.com/ru/post/481306/?utm_campaign=481306&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.