приложения такой же вендорлок будет.
Тем, что вы развиваете комбайн в своем направлении, когда другие развивают каждый компонент вашего комбайна по отдельности и более управляемо
вы фактически сейчас описали любой проект)
Зеркалирование когда будет? Вы зачем решаете за других как ямлы писать в своих секретах? Деплой зачем из 1.2 выпилили?
Ок, werf = opinionated approach. Об этом явно заявляется. Это несёт свои плюсы и минусы. В этом смысле "вендорлока" больше, чем у Helm — тут соглашусь. Есть в комбайне явные ограничения в отличие от "собирать всё по кускам, каждый из которых можно покрутить в любую сторону". Но ровно в этом же и суть, и ценность конкретного продукта. И этого никто не скрывает ведь. Текущая ситуация с Helm, на мой вкус, не позволяет приводить его в качестве хорошего примера отсутствия вендорлока, потому что фактически из-за остановки его развития большое сообщество оказалось в такой ситуации. И ровно по этой причине команда werf активно работаем над Nelm. И делает его не только внутри комбайна werf, но ещё и отдельно, чтобы этим могли пользоваться и развивать другие люди из сообщества (которым не нужна werf).
Так вы же используете тот же хельм, вы смеетесь что ли?
Но не "как есть", а с дополнениями, которые в upstream не забирают. Потому что есть проблемы развития самого Helm и есть потребность в изменениях. Что тут смешного?
Это не совсем тот хельм что в классике, но то что ребята бывает катят в стейбл проблемы согласен, потому я сижу на роксолид
можно про деплой подробнее? в 1.2 есть два вида деплоя - werf converge и werf bundle apply. Вы про какой?
https://werf.io/documentation/v1.1/cli/main/deploy.html про этот
два "других" деплоя в 1.2 решают эту же задачу. Зачем этот старый механизм?
Есть билд, есть деплой. Это база, основа, фундамент. С чего этот механизм старый?
werf build - билд werf bundle publish - публикация образов в регистри werf bundle apply - деплой в чём проблема?
Таймаут где у бандлов?
хорошее замечание, согласен. Не вижу его в параметрах
werf deploy == werf converge В версии 1.2 переименовали, потому что новое название команды действительно отражает суть и подчёркивает, что скоуп шире, чем просто развёртывание — команда синхронизирует заявленное состояние в Git с container registry и Kubernetes.
а в bundle apply таймаута не может быть по другой природе деплоя?
Многие опции могут быть не выведены просто потому, что не доглядели и не было обратной связи запроса (таймаут как раз об этом). В чём проблема донести до проекта PR или хотя бы обратную связь?
Под капотом одна и та же механика, отличается только источник с чартом.
ишью с просьбой втащить в бандл апплай часть опций из конверж - будет норм?)
Будет прекрасно.
@antoha_za_sho, чего вам кроме таймаута не хватает в апплай? p.s. я ишью буду делать в любом случае, так что накидывайте идей - возможно я не всё вижу p.p.s. я нашёл только три (а фактически это два) ключа, которые есть в конверж и их нет в апплай: --atomic --auto-rollback --timeout все остальные отличия в ключах имеют отношение к процессу сброки и для апплай не имеют смысла имхо
@antoha_za_sho, @aigrychev https://github.com/werf/werf/issues/5968
https://github.com/werf/werf/pull/5975
Алексей, привет! решил потестить эту фичу, и опять) пара вопросов: 1) строка 37 на скрине, зачем опять экспортить только что вытянутый бандл? 2) строка 46 - это как? В строке 25 явно указано --skip-dependencies-repo-refresh=true
2. Опция означает не обновлять индекс репозиториев, но чарты всё равно надо выкачать, если они ещё не выкачаны
они выкачаны, в репе лежат. Chart.lock создан, предварительно (до коммита) в репе выполнялась werf helm dependency update
@ilya_lesikov, добрый день. Означает ли ваше молчание) - что вы берёте паузу для изучения почему чарты заново выгружаются даже присутствуя в репе?
По идее werf helm dependency update должен был скачать чарты в .helm/charts, но также скопировать их в ~/.werf, в наше хранилище чартов. После этого запуски werf converge должны были бы доставать чарты из ~/.werf
имхо вы ошибочно исходите из того что раннеры которые запускают процессы пайплайна - являются чем-то постоянным и могут иметь какие-то локальные хранилища всё может запускаться в подах, которые в свою очередь запускаются на спот-нодах. Т.е. всё что верф создаст локально и НЕ сохранит в регистри - пропадёт навсегда сразу после выполнения этапа
А почему, если они лежат в репе в логе from repo удаленные выкачиваются?
Такая реализация сейчас
Не понял, что значит реализация? Если сабчарт указан локальный, все равно скачивается что-то с битнами?
Только если он в архиве лежит, тогда да, скачивается единожды, в ~/.werf
нет конечно. Локальный сабчарты не выкачиваются, только те которые имеют ссылку на удаленную репу. Данное поведение Илья предполагаю считает неправильным, просто исторически сложилось, но не поправлено. Да и обычный хельм тоже правильно себя ведёт при helm upgrade/install, за сабчартами никуда не ходит если они уже загружены
Обсуждают сегодня