Comments 9
В планах у них есть добавление чего-то типа buildah для сборки, что позволит собирать без запущенного докер-демона, но пока нет.
Если интересно, как это настроить, могу сделать пост.
то начиная с Gitlab 12.10 есть возможность сборки образов с помощью kaniko в AWS Fargate
Gitlab не использую, но странно что это как-то ограниченно его версией. В Jenkins запускаю любой сборщик образов, без каких-либо проблем.
Если интересно, как это настроить, могу сделать пост
Думаю всем будет интересно почитать. Я для билдов AWS не использую, довольно дорого. Но нужной масштабируемости достигал связкой на hetzner cloud. k8s + cluster autosclaer + jenkins + kaniko. Правда kaniko багует частенько, да и хотелось использовать
werf deploy
, а не werf helm deploy-chart
, по этому пока от этой связки отказался.Да, сборщик werf требует доступа к локальному docker-server на хостах, где запускается.
https://habr.com/ru/company/flant/blog/504390/
Промахнулся.
Так-то оно так, но ни kaniko, ни buildah не умеют собирать по-настоящему распределённый кеш. Чтобы уже собранные слои были доступны во всех сборках.
В werf теперь возможно такое: werf собирает коммит номер 1 на одном билдере. Пользователь делает новый коммит в git, werf запускается на другом билдере, накладывает патч на уже существующий кеш из предыдущей сборки на другом раннере и публикует новый образ.
Это похоже на то, что предоставляет --cache-from
в docker builder, но быстрее и эффективнее и с поддержкой ansible и инкрементальных пересборок по истории git и т.д.
Интересно. Конечно. Пишите!!! Очень ждем
Да, сборщик werf требует доступа к локальному docker-server на хостах, где запускается.
Небольшое дополнение к статье. В werf сейчас реализован принципиально новый подход к сборке и публикации образов в docker registry, отличный от того, что используется при docker build:
- Werf делает push каждого собранного слоя (стадии) в registry сразу после успешной сборки, что позволяет сразу переиспользовать его в других процессах сборки на произвольных машинах. Это возможно благодаря новому алгоритму публикации и выборки стадий с оптимистичными блокировками.
- На момент публикации финального образа по определённому имени все необходимые слои, из которых состоит этот образ, уже есть в registry. Werf по факту делает push лишь для небольшого слоя с некоторой мета-информацией и ставит на этот слой тег. Таким образом этот push происходит моментально, т.к. registry переиспользует существующие слои.
К тому же werf по умолчанию предлагает content-based-тегирование, что позволяет ещё лучше переиспользовать уже существующие слои и избавится от лишних ребилдов и редеплоев приложения.
Организация распределенного CI/CD с помощью werf