Это хороший вопрос! К сожалению, у нас сейчас нет детального сравнения, но это в ближайших планах. Кстати, если кому-то вдруг интересно поучаствовать в его создании — пишите мне в личку.
Сколько человек опросили? Каков размер, профиль (а в идеале - "культура") их компаний? Без такой базовой информации приведенные в тексте цифры мало что показывают.
Про маркетинг я упомянул в контексте того, что в статье всё же некоторые вещи про docker описываются как невозможные и возможные только с werf, тогда как это не так.
Возможно, весь корень разногласий в том, что «невозможно встроенными командами Docker» (то есть легко и «из коробки») != «невозможно в принципе с использованием Docker»? :-) Задача статьи была в сравнении конкретной утилиту с другой конкретной утилитой (как мы уже делали с Helm). Сделано это было не с абстрактной целью, а по конкретной причине, описанной выше: показать, к чему именно и почему мы пришли в реализации в werf (когда сами начинали с обычного Docker). (А другая причина — объяснить новичкам место werf в CI/CD и показать её особенности в сравнении с базовыми возможностями Docker.)
Не было задачи сказать, что что-то вообще можно только с werf. Ведь werf, повторюсь, про «клей», которым сразу можно пользоваться. Если смотреть на глобальную картину всех доступных инструментов и подходов, то это, конечно, всего лишь один из путей. Задачи комплексного сравнения всех возможных путей не было. Она тоже интересная, конечно, но слишком масштабная (и быстро устареет).
Планирую обязательно пощупать 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, если просто словам веры нет.
И без этих слов, уже имеющих устоявшийся (однозначный, понятный…) перевод, в таких статьях всё равно будет достаточно терминологии. Красота в разумном балансе.
Не автор этого перевода, но написал много текстов по теме… И nodes, и namespaces — устоявшиеся в ИТ термины, получившие широкое распространение (и перевод) задолго до Kubernetes. Поэтому сравнение со «стручками» не очень корректно, а их русскоязычная версия, на мой вкус, предпочтительнее (иначе утонем в англицизмах).
Не совсем понял как было обновление в облачных средах. Ведь там все делается через интерфейс управления облаком — конечно я понимаю, что это просто вызов команд для обновления kubernetes, но ведь у разных поставщиков услуг могут быть немного разные вызова и особенности.
У нас своя разработка (Deckhouse), у которой одна из главных идей — это поддержка одним и тем же дистрибутивом разных провайдеров, что позволяет разворачивать одинаковые кластеры в разных облаках (и даже мигрировать при такой необходимости). В облаках мы используем не managed-решения провайдеров (AKS, GKE…), а их вычислительные мощности, куда ставим свой Kubernetes (грубо говоря, мы раскатываем там свой managed K8s). И поэтому обновление происходит у разных провайдеров аналогично, оно никак не зависит от специфики того или иного облачного managed-решения.
Про железные не сказали как обновили, kubespray playbook переписывали или просто бинари подменили?
Соответственно, bare metal — это просто еще один вид инфраструктуры, которую поддерживает Deckhouse помимо разных облачных провайдеров. Kubespray мы не используем. А про подмену бинарников лучше расскажет автор :-)
Имена обычно не переводят, а используют для них транскрипцию или транслитерацию. Конкретно у Тома известно и имя на русском (его книги переводили на русский), и легко читается имя в оригинале — не понимаю, в чем проблема :-) Мне кажется предпочтительным оставлять оригинальные написания (за редкими исключениями).
Это хороший вопрос! К сожалению, у нас сейчас нет детального сравнения, но это в ближайших планах. Кстати, если кому-то вдруг интересно поучаствовать в его создании — пишите мне в личку.
Сколько человек опросили? Каков размер, профиль (а в идеале - "культура") их компаний? Без такой базовой информации приведенные в тексте цифры мало что показывают.
Спасибо за пожелание! Issue в GitHub (и растущее число upvote'ов в нем ;-)) подойдет.
Возможно, весь корень разногласий в том, что «невозможно встроенными командами Docker» (то есть легко и «из коробки») != «невозможно в принципе с использованием Docker»? :-) Задача статьи была в сравнении конкретной утилиту с другой конкретной утилитой (как мы уже делали с Helm). Сделано это было не с абстрактной целью, а по конкретной причине, описанной выше: показать, к чему именно и почему мы пришли в реализации в werf (когда сами начинали с обычного Docker). (А другая причина — объяснить новичкам место werf в CI/CD и показать её особенности в сравнении с базовыми возможностями Docker.)
Не было задачи сказать, что что-то вообще можно только с werf. Ведь werf, повторюсь, про «клей», которым сразу можно пользоваться. Если смотреть на глобальную картину всех доступных инструментов и подходов, то это, конечно, всего лишь один из путей. Задачи комплексного сравнения всех возможных путей не было. Она тоже интересная, конечно, но слишком масштабная (и быстро устареет).
Было бы очень круто! В любом случае — уже сейчас спасибо за обратную связь!
сорри, промахнулся тредом
Давайте по пунктам? Тогда обсуждение будет предметным, а не эмоциональным ;-)
В контексте маркетинга и ложных утверждений предлагаю также посмотреть на само явление werf немного в другом срезе:
Создание подобного продукта — огромные инвестиции. Если на рынке уже есть всё готовое для тех же задач, зачем нам ввязываться в такую сложную и многолетнюю разработку? Да ещё и делать это в рамках Open Source-проекта, инвестиции в который больше…
Это сравнение, в том числе, призвано показать, зачем мы вообще делали werf. Фокус вовсе не на том, как плох Docker (он в определённых смыслах хорош, и об этом в статье явно написано). Фокус на том, чего нам не хватило в нем (и других существующих инструментах), чтобы эффективно и качественно решать задачи для себя/клиентов. Причем не хватило настолько сильно, что обойтись некими workaround'ами (да хоть патчами в соответствующие проекты) не удалось, а пришлось что-то большое своё (и потом это поддерживать). Мы объясняем, почему мы сделали werf и к реализации каких фич в утилите это привело. Чтобы другие пользователи, которые столкнулись с похожими проблемами, возможно, увидели в werf решение своей боли.
Как компания, мы с самого начала про и за Open Source. И делаем проект соответствующим образом, и на маркетинг здесь вовсе не про какую-то коммерческую разработку. (К слову, пример интересного побочного эффекта: в рамках werf зародился проект поменьше — kubedog, — который используют совсем для других целей в других компаниях.) У нас нет цели убивать какие-то Open Source-проекты — есть более глобальная цель приносить профессиональному сообществу удобство. И здесь мы в деталях объясняем, что это за «удобство», к которому сами пришли.
Про Open Source и сообщество уже написано. Сравнение с монолитом — интересное… Хотя и не совсем точное, примем его за возможное. Тогда мысль следующая: у микросервисов есть ряд серьёзных проблем, о которых вам, наверное, тоже известно. (Об этом сто раз писали на хабре. Был у нас и доклад.)
Так вот использование маленьких утилит — с тем, чтобы у каждой было свое одно дело, — иногда действительно может быть оптимальным. Однако, по нашему опыту, со временем это удобство сопряжено с рядом проблем (как их между собой интегрировать, как потом в этой схеме что-то менять и в целом поддерживать). Поэтому основная идея werf являться таким «клеем», объединяющим стандарты индустрии (Git, Docker, Helm и прочее). werf интегрирует эти стандартные инструменты и расширяет их возможности для конечного удобства пользователей.
«Не уверен, что это работает» — совсем странное заявление на фоне того, что у утилиты (помимо множества инсталляций, что мы поддерживаем сами; см. соседний комментарий) давно сформировалось сообщество пользователей. Заходите в @werf_ru, если просто словам веры нет.
Кстати, для взаимодействия с Kubernetes в этом проекте его авторы (из Confluent) использовали наш shell-operator:
Перевод очень похожей статьи мы публиковали аж 4 года назад.
Такие сравнения тоже есть в планах.
Сделать оператор как одну из опций (в дополнение к текущей, но не вместо ее) стоит в планах проекта: https://github.com/werf/werf/issues/2612
По терминологии — понятие GitOps нам тоже не очень (но его более-менее "знают"), поэтому придумали Giterminism.
Из инструментов — чат по werf довольно активен и вырос уже до 600+ участников: https://t.me/werf_ru
Ещё не увидел канал https://t.me/devopslibrary
А раз есть про K8s от MCS, то можно было бы и Флант добавить ;-) https://t.me/flant_ru (есть и чат).
У нас своя разработка (Deckhouse), у которой одна из главных идей — это поддержка одним и тем же дистрибутивом разных провайдеров, что позволяет разворачивать одинаковые кластеры в разных облаках (и даже мигрировать при такой необходимости). В облаках мы используем не managed-решения провайдеров (AKS, GKE…), а их вычислительные мощности, куда ставим свой Kubernetes (грубо говоря, мы раскатываем там свой managed K8s). И поэтому обновление происходит у разных провайдеров аналогично, оно никак не зависит от специфики того или иного облачного managed-решения.
Соответственно, bare metal — это просто еще один вид инфраструктуры, которую поддерживает Deckhouse помимо разных облачных провайдеров. Kubespray мы не используем. А про подмену бинарников лучше расскажет автор :-)