Почему "совершенно лишний"? :) У нас это стандартный стек, тоже работает с любой CI-системой. Вы используете для этого что-то другое - это вполне ок и не становится от этого "лишним", а выполняет свою функцию. Удобство - вопрос субъективный, есть много факторов и поэтому есть много решений.
А вот и официальный анонс завезли. В частности, обновление etcd до 3.5.0 там отдельно отмечается:
Kubernetes' default backend storage, etcd, has a new release: 3.5.0. The new release comes with improvements to the security, performance, monitoring, and developer experience. There are numerous bug fixes and some critical new features like the migration to structured logging and built-in log rotation. The release comes with a detailed future roadmap to implement a solution to traffic overload. You can read a full and detailed list of changes in the 3.5.0 release announcement.
И дали такой логотип релизу, позиционируя его как «напоминание не останавливаться в достижении новых высот и установлении новых рекордов» (53 улучшения — это максимум для релизов K8s):
Продукт чисто по общему впечатлению выглядит интересно, мы за ним поглядываем некоторое время, но вот знаешь ли его пользователей в России? Мы не слышали о таких...
P.S. Кстати, они в своем инсталляторе используют shell-operator.
Это хороший вопрос! К сожалению, у нас сейчас нет детального сравнения, но это в ближайших планах. Кстати, если кому-то вдруг интересно поучаствовать в его создании — пишите мне в личку.
Сколько человек опросили? Каков размер, профиль (а в идеале - "культура") их компаний? Без такой базовой информации приведенные в тексте цифры мало что показывают.
Про маркетинг я упомянул в контексте того, что в статье всё же некоторые вещи про 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. Поэтому сравнение со «стручками» не очень корректно, а их русскоязычная версия, на мой вкус, предпочтительнее (иначе утонем в англицизмах).
О, про крайности и модули у нас как раз недавно был другой перевод.
Почему "совершенно лишний"? :) У нас это стандартный стек, тоже работает с любой CI-системой. Вы используете для этого что-то другое - это вполне ок и не становится от этого "лишним", а выполняет свою функцию. Удобство - вопрос субъективный, есть много факторов и поэтому есть много решений.
Если вы про таблицу, то успели исправить до этого комментария, спасибо! :-)
А вот и официальный анонс завезли. В частности, обновление etcd до 3.5.0 там отдельно отмечается:
И дали такой логотип релизу, позиционируя его как «напоминание не останавливаться в достижении новых высот и установлении новых рекордов» (53 улучшения — это максимум для релизов K8s):
Продукт чисто по общему впечатлению выглядит интересно, мы за ним поглядываем некоторое время, но вот знаешь ли его пользователей в России? Мы не слышали о таких...
P.S. Кстати, они в своем инсталляторе используют shell-operator.
Это хороший вопрос! К сожалению, у нас сейчас нет детального сравнения, но это в ближайших планах. Кстати, если кому-то вдруг интересно поучаствовать в его создании — пишите мне в личку.
Сколько человек опросили? Каков размер, профиль (а в идеале - "культура") их компаний? Без такой базовой информации приведенные в тексте цифры мало что показывают.
Спасибо за пожелание! 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.