Организация распределенного CI/CD с помощью werf

[identw]

Наверное стоит упомянуть, что werf'у, по прежнему нужен демон докера для сборки, и поды внутри которых запускается сборка образа должны быть запущены с демоном докера, то есть по сути нужен DIND контейнер, и его нужно запускать со специальными привилегиями. Или я неправильно всё понял?

[GamePad64]

В планах у них есть добавление чего-то типа buildah для сборки, что позволит собирать без запущенного докер-демона, но пока нет.

[VitalySh]

Если не хочется использовать DIND, то начиная с Gitlab 12.10 есть возможность сборки образов с помощью kaniko в AWS Fargate. Возможность недокументированная, есть куча особенностей, но стоит это раз в почти в 10 раз дешевле, чем AWS CodeBuild, если Fargate запускать на спотовых мощностях. И при этом масштабируется практически неограниченно.
Если интересно, как это настроить, могу сделать пост.

[identw]

Про kaniko, buildkit, buildah, makisu я знаю. Меня интересует сборка именно в werf. Просто в статье это не совсем очевидно, мне кажется об этом нужно было упомянуть.

то начиная с Gitlab 12.10 есть возможность сборки образов с помощью kaniko в AWS Fargate

Gitlab не использую, но странно что это как-то ограниченно его версией. В Jenkins запускаю любой сборщик образов, без каких-либо проблем.

Если интересно, как это настроить, могу сделать пост

Думаю всем будет интересно почитать. Я для билдов AWS не использую, довольно дорого. Но нужной масштабируемости достигал связкой на hetzner cloud. k8s + cluster autosclaer + jenkins + kaniko. Правда kaniko багует частенько, да и хотелось использовать werf deploy, а не werf helm deploy-chart, по этому пока от этой связки отказался.

[tkir]

Да, сборщик werf требует доступа к локальному docker-server на хостах, где запускается.

https://habr.com/ru/company/flant/blog/504390/
Промахнулся.

[tkir]

Так-то оно так, но ни kaniko, ни buildah не умеют собирать по-настоящему распределённый кеш. Чтобы уже собранные слои были доступны во всех сборках.

В werf теперь возможно такое: werf собирает коммит номер 1 на одном билдере. Пользователь делает новый коммит в git, werf запускается на другом билдере, накладывает патч на уже существующий кеш из предыдущей сборки на другом раннере и публикует новый образ.

Это похоже на то, что предоставляет --cache-from в docker builder, но быстрее и эффективнее и с поддержкой ansible и инкрементальных пересборок по истории git и т.д.

[gecube]

Интересно. Конечно. Пишите!!! Очень ждем

[tkir]

Да, сборщик werf требует доступа к локальному docker-server на хостах, где запускается.

[tkir]

Небольшое дополнение к статье. В werf сейчас реализован принципиально новый подход к сборке и публикации образов в docker registry, отличный от того, что используется при docker build:

• Werf делает push каждого собранного слоя (стадии) в registry сразу после успешной сборки, что позволяет сразу переиспользовать его в других процессах сборки на произвольных машинах. Это возможно благодаря новому алгоритму публикации и выборки стадий с оптимистичными блокировками.
• На момент публикации финального образа по определённому имени все необходимые слои, из которых состоит этот образ, уже есть в registry. Werf по факту делает push лишь для небольшого слоя с некоторой мета-информацией и ставит на этот слой тег. Таким образом этот push происходит моментально, т.к. registry переиспользует существующие слои.

К тому же werf по умолчанию предлагает content-based-тегирование, что позволяет ещё лучше переиспользовать уже существующие слои и избавится от лишних ребилдов и редеплоев приложения.