Комментарии 19
Но что делать, если сборочным инструкциям требуются все файлы, а пересборка должна выполняться при изменении конкретных?
В случае с Dockerfile решить такую задачу невозможно. Приходится выполнять сборочные инструкции при любых изменениях.
Точно точно невозможно?
А слои и наследование образов в докере придумали для дяди Васи?
P. S. И сравнивать в стиле "наша рыба шевелит хвостом (читает собственный формат Stapel), а ваш мальчик (Docker) этого не умеет" - вообще моветон.
В этой части статьи рассматриваются особенности работы с исходными файлами в Dockerfile и Stapel, особенности кеширования и слоёв. В случае с Dockerfile добавление файлов происходит на определённом шаге сборки, а в случае со Stapel оно плавающее.
В Dockerfile можно выполнить команду при любом изменении файлов:
COPY . .
RUN commandВ Dockerfile можно выполнить команду при изменении определённого файла/среза файлов:
COPY trigger_file .
RUN command
COPY . .Но в Dockerfile нельзя выполнить команду со всем исходным кодом при изменении определённого файла/среза файлов. Нет возможности реализовать некий триггер и не выполнять времязатратную команду при других изменениях.
Причём здесь docker multi-stage и как он поможет решить данный кейс — мне не понятно.
Хоть инструмент ваша команда и написала интересный, респект, похоже есть интересные фишки, но многое в статье сомнительно и похоже на маркетинг. Некоторые утверждения ложные и желаемое выдаётся за действительное. Докер умеет много что из того, что в статье преподносится, как невозможное. Возможно из коробки с werf это проще, но говорить, что невозможно не нужно.
Отдельно замечу, что эдакий мультикомбайн напоминает монолит, от которых мы все как раз пытаемся уйти к микросервисам. Да, иногда бывает удобно в образ поставить несколько утилит для сборки/деплоя и т.п. А тут прямо и helm и docker и ещё что-то... Не уверен, что это работает и главное будет в будущем работать лучше, чем вышеупомянутое, ведь там его поддерживает гораздо большее коммьюнити.
Удачи!
werf — это действительно эдакий мультикомбайн, решение для доставки приложения в Kubernetes, которое отвечает за весь жизненный цикл приложения и его артефактов (ближайший аналог от Google — skaffold).
Не уверен, что это работает и главное будет в будущем работать лучше, чем вышеупомянутое, ведь там его поддерживает гораздо большее коммьюнити
Функционал выстраивается поверх кода из upstream, а также мы делаем свой вклад в развитие используемых проектов, участвуем в обсуждении проблем и непосредственно в разработке.
Что касается поддержки, то мы имеем более 2000 внутренних инсталяций werf, которые работают на различных каналах стабильности, и получаем оперативную обратную связь.
Некоторые утверждения ложные и желаемое выдаётся за действительное. Докер умеет много что из того, что в статье преподносится, как невозможное
А есть какие-то конкретные замечания, спорные моменты?
Функционал выстраивается поверх кода из upstream, а также мы делаем свой вклад в развитие используемых проектов, участвуем в обсуждении проблем и непосредственно в разработке
Супер, надеюсь так и будет продолжаться, тем более, что звёзд на Github у вас уже очень даже прилично.
А есть какие-то конкретные замечания, спорные моменты?
Есть. Замечание по подаче информации в статье в формате: «в docker этого нет, а в werf есть».
Например, пользователю не нужно думать о тегировании образа и о том, что хранится в container registry
«Пользователю», т.е., условно, «разработчику», может быть и не нужно, но ci/cd пайплайны обычно выстраивают релиз инженеры или DevOps'ы/SRE и им нужно и думать и понимать что, куда и как выкатывается. Делается это тегами или вашим изобретением в виде… имён контейнеров, т.е. более вручную или более автоматизированно это в контексте моего комментария уже вторичный момент, т.к. в werf вы судя по тому, что я прочёл в статье, вы идёте по пути условного Apple или Gitlab и решаете за пользователя в каком виде ему что лучше иметь на выходе.
Как следствие, в werf нет понятий tag и push — эти процедуры встроены в werf build
Понятия то может и нет, но если вы просто объединили эти процессы под капотом, то это не значит, что это не происходит, т.е. у вас, вместо `docker build -t example. && docker push example` происходит условный `werf build example`
werf экономит время на сборку, собирая только те образы, или слои образа, которые требуются для текущего коммита и которых еще нет в container registry. Вдобавок, экономится место, поскольку нет необходимости повторно сохранять образ в реестре.
Multistage builds не все могут освоить, там много фишек и вы наверное по сути реализовали многое из этого под капотом werf, но это не значит, что этих механизмов не существует в обычном docker, как мне кажется подаётся в статье. Думаю при грамотной настройке multistage build docker скорость сборки не будет отличаться от werf.
Также во всех широко распространённых docker registry, например Gitlab, есть механизм использования слоёв из других контейнеров, который задействуются при сохранении/push новых образов именно с описанными вами целями. Пример:
$ docker push $CI_REGISTRY_IMAGE/example
The push refers to repository [registry.gitlab.com/example]
4804b936f9fb: Preparing
4e680695ab1f: Preparing
f05ab25ed134: Preparing
f65353d0c4cd: Preparing
fafbb6872cae: Preparing
56456681cc56: Preparing
5c92c7ad7044: Preparing
777b2c648970: Preparing
5c92c7ad7044: Waiting
777b2c648970: Waiting
56456681cc56: Waiting
4e680695ab1f: Layer already exists
f65353d0c4cd: Layer already exists
fafbb6872cae: Layer already exists
f05ab25ed134: Layer already exists
777b2c648970: Layer already exists
5c92c7ad7044: Layer already exists
56456681cc56: Layer already exists
4804b936f9fb: Pushed
1.8.3-alpine: digest: sha256:07d028c89da81f460e0442f5f50275a878765aef43df0bb71dc0840d31f1c9bf size: 1987
Cleaning up file based variables
00:01
Job succeededЕщё раз повторюсь: существует множество best practices для различного рода кэширования, которые многие не используют ввиду неопытности и werf похоже заполняет этот пробел в знаниях новичков просто задействуя эти механизмы и реализуя их как бы за них. Но как мне кажется в статье информация подаётся в таком виде, что этих механизмов нет вообще или они сильно уступают werf. Это конечно же не так. В добавок по вашему собственному утверждению
Функционал выстраивается поверх кода из upstreamи схема с использованием docker daemon тоже про это.
Например, пользователю не нужно думать о тегировании образа и о том, что хранится в container registry
При использовании werf выкатывание приложения в Kubernetes, а точнее синхронизация состояния с конфигурацией в Git, — это первичная задача, ради которой выстраиваются CI/CD пайплайны и используются подобные решения. Все сопутствующие артефакты вторичны и werf берёт на себя ответственность за них и не даёт пользователю стрелять себе в ногу.
Как следствие, в werf нет понятий tag и push — эти процедуры встроены в werf build
Понятия то может и нет, но если вы просто объединили эти процессы под капотом
Статья является сравнением двух инструментов. В docker пользователь может вручную выполнить тегирование и публикацию. В werf такой возможности нет — пользователь решает конкретную задачу без промежуточных состояний и работы с артефактами:
werf build— собрать образ соответствующий текущему коммиту;werf run— запустить контейнер для текущего коммита;werf converge— синхронизировать состояние в Kubernetes с текущим коммитом.
werf экономит время на сборку, собирая только те образы, или слои образа, которые требуются для текущего коммита и которых еще нет в container registry. Вдобавок, экономится место, поскольку нет необходимости повторно сохранять образ в реестре.
- много фишек и вы наверное по сути реализовали многое из этого под капотом werf;
Мы не разрабатываем ради разработки — наши решения выстраиваются поверх существующих (кстати, docker multi-stage в виде артефактов в Stapel-сборщике появился до Docker).
- это не значит, что этих механизмов не существует в обычном docker;
- при грамотной настройке multistage build docker скорость сборки не будет отличаться от werf;
- множество best practices для различного рода кэширования;
- этих механизмов нет вообще или они сильно уступают werf.
Как уже было сказано раннее мы не изобретаем велосипед по новой, а добавляем уровни абстракции поверх. В werf водится новая сущность — стадия, которая позволяет делать больше, чем Docker может со слоями.
Вы мне про Фому, а я вам про Ерёму :)
Я вам конкретно говорю, что в статье сформулировано так, что docker что-то не умеет, а werf умеет. Это не так.
Про то что вы реализуете уровни абстракции поверх всего этого и в итоге связывая всё этого воедино экономите для всех время, деньги и принуждать их к использованию best practices кэширования это понятно.
позволяет делать больше, чем Docker может со слоями
Опять же: сомнительно по вышеописанным мной причинам, но, надеюсь, что ошибаюсь и обязательно проверю на практике :)
Docker много чего не умеет из того, что умеет werf. Не в силу того, что werf лучше, а просто потому что эти инструменты о разном. Docker — это фундаментальное решение, которое выполняет конкретные задачи по управлению образами и контейнерами на хосте (в большинстве своём низкоуровневые операции). werf, в свою очередь, про жизненный цикл приложения в Kubernetes, который обеспечивается слаженной работой множества компонентов.
Надеюсь у вас будет время попробовать werf и дать обратную связь в наших telegram-каналах и на GitHub.
Не могу сказать что там супер сложного в multistage, который могут освоить не только лишь все, но опишу свой опыт работы с докером, который побуждает к поиску альтернатив для билда образов:
Имеем Laravel приложение, которое живёт в 3х образах, которые билдятся из одного репозитория. Для билда используем buildkit, т.к. можно для каждого dockerfile задать соответствующий dockerignore и кеш выгружать вместе с образом.
Проблема следующая: для работы php используется расширение, которое билдятся в районе 15 минут локально и ещё дольше в контексте CI/CD, для билда которого ещё надо поставить зависимости через apt-get.
Что ж, идём на сайт докера, и выясняем, что для RUN'ов кеш считается не по файлам, которые содержит слой, а по самой инструкции. А значит если dockerfile не меняли в бранче то --cache-from master должен всегда кешировать первые слои, в которых содержатся инструкции вида RUN apt-get update && apt-get install... На практике, --cache-from работает 50/50. Когда работает, а когда нет, что может критично сказаться на времени пайплайна. Почему и по какой причине так происходит я устал разбираться. Если и есть способ решения этой проблемы силами Docker + buildkit, то я его не нашел и если есть инструмент, который избавит меня от таких вот загадок, на которые ответ кроется глубоко в недрах source кода, то лучше его использовать.
Не могу сказать что там супер сложного в multistage
На практике, --cache-from работает 50/50. Когда работает, а когда нет, что может критично сказаться на времени пайплайна. Почему и по какой причине так происходит я устал разбираться
У всего есть причины. Не разобрались и werf решил вашу проблему за вас, супер! Ни коим образом не говорю, что нужно всё билдить только докером или вместо apt только из исходников :) Лишь указываю на некорректность формулирования в статье некоторых моментов, которые звучат как "это невозможно с докер и возможно с werf". Это не так, как и, я уверен, в вашем случае.
Докер умеет много что из того, что в статье преподносится, как невозможное. Возможно из коробки с werf это проще, но говорить, что невозможно не нужно.
Давайте по пунктам? Тогда обсуждение будет предметным, а не эмоциональным ;-)
В контексте маркетинга и ложных утверждений предлагаю также посмотреть на само явление werf немного в другом срезе:
Создание подобного продукта — огромные инвестиции. Если на рынке уже есть всё готовое для тех же задач, зачем нам ввязываться в такую сложную и многолетнюю разработку? Да ещё и делать это в рамках Open Source-проекта, инвестиции в который больше…
Это сравнение, в том числе, призвано показать, зачем мы вообще делали werf. Фокус вовсе не на том, как плох Docker (он в определённых смыслах хорош, и об этом в статье явно написано). Фокус на том, чего нам не хватило в нем (и других существующих инструментах), чтобы эффективно и качественно решать задачи для себя/клиентов. Причем не хватило настолько сильно, что обойтись некими workaround'ами (да хоть патчами в соответствующие проекты) не удалось, а пришлось что-то большое своё (и потом это поддерживать). Мы объясняем, почему мы сделали werf и к реализации каких фич в утилите это привело. Чтобы другие пользователи, которые столкнулись с похожими проблемами, возможно, увидели в werf решение своей боли.
Как компания, мы с самого начала про и за Open Source. И делаем проект соответствующим образом, и на маркетинг здесь вовсе не про какую-то коммерческую разработку. (К слову, пример интересного побочного эффекта: в рамках werf зародился проект поменьше — kubedog, — который используют совсем для других целей в других компаниях.) У нас нет цели убивать какие-то Open Source-проекты — есть более глобальная цель приносить профессиональному сообществу удобство. И здесь мы в деталях объясняем, что это за «удобство», к которому сами пришли.
Отдельно замечу, что эдакий мультикомбайн напоминает монолит, от которых мы все как раз пытаемся уйти к микросервисам. Да, иногда бывает удобно в образ поставить несколько утилит для сборки/деплоя и т.п. А тут прямо и helm и docker и ещё что-то... Не уверен, что это работает и главное будет в будущем работать лучше, чем вышеупомянутое, ведь там его поддерживает гораздо большее коммьюнити.
Про Open Source и сообщество уже написано. Сравнение с монолитом — интересное… Хотя и не совсем точное, примем его за возможное. Тогда мысль следующая: у микросервисов есть ряд серьёзных проблем, о которых вам, наверное, тоже известно. (Об этом сто раз писали на хабре. Был у нас и доклад.)
Так вот использование маленьких утилит — с тем, чтобы у каждой было свое одно дело, — иногда действительно может быть оптимальным. Однако, по нашему опыту, со временем это удобство сопряжено с рядом проблем (как их между собой интегрировать, как потом в этой схеме что-то менять и в целом поддерживать). Поэтому основная идея werf являться таким «клеем», объединяющим стандарты индустрии (Git, Docker, Helm и прочее). werf интегрирует эти стандартные инструменты и расширяет их возможности для конечного удобства пользователей.
«Не уверен, что это работает» — совсем странное заявление на фоне того, что у утилиты (помимо множества инсталляций, что мы поддерживаем сами; см. соседний комментарий) давно сформировалось сообщество пользователей. Заходите в @werf_ru, если просто словам веры нет.
Давайте по пунктам? Тогда обсуждение будет предметным, а не эмоциональным ;-)
А где вы увидели эмоции с моей стороны? :)
Создание подобного продукта — огромные инвестиции. Если на рынке уже есть всё готовое для тех же задач, зачем нам ввязываться в такую сложную и многолетнюю разработку? Да ещё и делать это в рамках Open Source-проекта, инвестиции в который больше
Навскидку (и это всё положительные и правильные шаги):
1) процесс работы над собственным opensource проектом внутри компании реализует некий team building. Уверен, что ребята работают над ним не только в рабочее время, как и все, кто участвует в opensource.
2) лишнее подтверждение для клиентов, которым это решение внедряется в состоятельности и крутости компании.
3) вы регулярно реализуете некие решения у клиентов и решили написать собственный продукт, который бы реализовывал хотя бы часть best practices по части multi stage docker builds и т.п. чтобы каждый ваш инженер не реализовывал это на свой вкус и это было бы стандартизированно + в целом это экономия времени для компании, а значит денег.
…
Про маркетинг я упомянул в контексте того, что в статье всё же некоторые вещи про docker описываются как невозможные и возможные только с werf, тогда как это не так.
Тогда мысль следующая: у микросервисов есть ряд серьёзных проблем, о которых вам, наверное, тоже известно.
И это не отменяет плюсов в их использовании, как вам прекрасно известно.
Так вот использование маленьких утилит — с тем, чтобы у каждой было свое одно дело, — иногда действительно может быть оптимальным. Однако, по нашему опыту, со временем это удобство сопряжено с рядом проблем (как их между собой интегрировать, как потом в этой схеме что-то менять и в целом поддерживать).
Использовать точно такой же подход, как к микросервисам, конечно. Другое дело, что каждый инженер может начать лепить что-то своё и не то что описать интерфейсы взаимодействия между тегированием и пушем образов достаточно сложно, это не сложно, а сложно проконтроллировать фактическую реализацию. werf я так понимаю решает часть этой проблемы, т.к. забирает конвенцию по именованию и по использованию кэширования под капот. Но это опять же не значит, что всего этого нет для отдельных утилит, как мне кажется подаётся в статье. Поэтому с вашим утверждением
werf интегрирует эти стандартные инструменты и расширяет их возможности для конечного удобства пользователей
не соглашусь по части «расширяет их возможности». В статье не увидел ничего, что нельзя было бы реализовать не с помощью werf.
В целом для меня это похоже на сравнение Jenkins и Gitlab: в Gitlab многое сделано за вас и склеено, но это не значит, что это нельзя реализовать в Jenkins :)
Но это всё слова основанные на статье. Планирую обязательно пощупать werf, выглядит достаточно интересно и возможно напишу неафилированную статью.
Про маркетинг я упомянул в контексте того, что в статье всё же некоторые вещи про docker описываются как невозможные и возможные только с werf, тогда как это не так.
Возможно, весь корень разногласий в том, что «невозможно встроенными командами Docker» (то есть легко и «из коробки») != «невозможно в принципе с использованием Docker»? :-) Задача статьи была в сравнении конкретной утилиту с другой конкретной утилитой (как мы уже делали с Helm). Сделано это было не с абстрактной целью, а по конкретной причине, описанной выше: показать, к чему именно и почему мы пришли в реализации в werf (когда сами начинали с обычного Docker). (А другая причина — объяснить новичкам место werf в CI/CD и показать её особенности в сравнении с базовыми возможностями Docker.)
Не было задачи сказать, что что-то вообще можно только с werf. Ведь werf, повторюсь, про «клей», которым сразу можно пользоваться. Если смотреть на глобальную картину всех доступных инструментов и подходов, то это, конечно, всего лишь один из путей. Задачи комплексного сравнения всех возможных путей не было. Она тоже интересная, конечно, но слишком масштабная (и быстро устареет).
Планирую обязательно пощупать werf, выглядит достаточно интересно и возможно напишу неафилированную статью.
Было бы очень круто! В любом случае — уже сейчас спасибо за обратную связь!
Никаких вопросов к «задаче» статьи, но в ходе сранения формулируется посыл о невозможности реализации чего либо «встроенными» командами Docker и возможности реализации этого с помощью werf. У докера все команды «встроенные», werf использует api docker daemon, является клеем и т.д., поэтому уверен, что при детальном разборе любой ситуации окажется, что это реализуемо/возможно и с помощью «встроенных» команд Docker, определённой правильной для конкретной ситуации последовательности в реализации multi stage build'ов и т.д., просто для этого нужно явно знать как это настраивать и потратить на это, возможго немало, дополнительного времени, а werf это делает из коробки и за вас.
Но "реализуемо за дополнительное время" != "нереализуемо".
Да ещё и делать это в рамках Open Source-проекта, инвестиции в который больше
Не совсем. На долгой дистанции open source может обойтись дешевле проприетарного решения. Выкатывание проекта уровня enterprise в открытый доступ - это возможность привлечь "инвестиции" в виде труда сотрудников других компаний. Чем популярнее продукт, тем больше в него вкладываются другие.
сорри, промахнулся тредом
В целом, инструмент выглядит интересным, но плавно перейти на него от `docker build` не выйдет - придется полностью перестраивать текущие процессы (и, в некотором роде, мышление). Получается этакая вещь в себе и это отпугивает.
Еще один вопрос - как с этим будут работать локально тестировщики\разработчики. У многих до сих пор есть проблемы с освоением "классического" докера, а здесь еще и content-based тэгирование, и дополнительный файл werf.yaml.
И да, ждем возможность сборки без докер-демона (может быть тогда и больше пунктов для перехода наберется)
werf vs Docker. Чем лучше собирать образы