Пікірлер
@Moveah
@Moveah 5 күн бұрын
После прослушивания этого доклада я ощутил смесь разочарования и потенциала. Начиная с презентации, я надеялся увидеть четкие, практические подходы к управлению проектами, но вместо этого мне пришлось столкнуться с бесконечным потоком слайдов и хаосом в организации материала. Особенно это касается момента, когда обсуждалась "проблема часа инженера". Введение концепции 'слотов времени' и универсальных единиц измерения работы инженера кажется непродуктивным. Это упрощает понимание человеческого таланта и креативности до простых цифр, что, на мой взгляд, не отражает истинную ценность инженерной работы. Докладчик казался потерянным в собственных объяснениях, что подрывает доверие к представляемым методам. Как можно ожидать, что кто-то захочет применять эти методы, когда даже спикер кажется неуверенным в их пользе? Ещё один критический момент - это непрекращающееся переключение слайдов. Это отвлекает и делает следование за ходом доклада утомительным. Каждый раз, когда докладчик пытался объяснить свои методы, это звучало скорее как отчаянная попытка звучать убедительно, нежели как демонстрация эффективного решения. Если бы Стив Джобс находился в зале, я уверен, он бы поставил под вопрос столь сложный подход к измерению работы инженеров, упускающий из виду важность инноваций и креативности. Он всегда подчеркивал, что величайшая ценность заключается не в количестве потраченных часов, а в качестве и влиянии созданного продукта. Нужно сосредоточиться на том, как эти методы могут реально улучшить работу команды. Этот доклад был упущенной возможностью демонстрации эффективной интеграции скрама и канбана в рабочем процессе. Надеюсь, что в следующий раз мы увидим от Фланта более вдохновляющий и понятный доклад.
@sergeygoncharuk6258
@sergeygoncharuk6258 5 күн бұрын
Иван, привет! Рад видеть, что бывшие коллеги-ПМы интересуются моим докладом, правда очень странно видеть отзыв на доклад о фреймворке, написанный таким образом, как будто ты не знаешь, как это работает в жизни и требуешь практических подходов, по которым работал сам. За критику по количеству слайдов спасибо! Учту в будущем. А сейчас, так как ты смотрел этот доклад в видео-версии, предлагаю лайфхак: можно нажать паузу и внимательно рассмотреть слайд, я старался сделать так, чтобы информация на нем иллюстрировала слова, которые я говорю и делала их наглядными. К сожалению, тема доклада довольно узкая, а времени на ее раскрытие не так много, чтобы в доклад уложить еще и методы развития и проявления творческих способностей инженеров команды. Да и тебе ли не знать, что во Фланте существуют для этого иные механизмы, например performance review, с описанием которого можно ознакомиться в этом докладе kzbin.info/www/bejne/oJLTp5mprNOqqsk Ну и наконец, если бы Стив Джобс был на моем докладе, я был бы счастлив, что такого масштаба человек пришел, чтобы послушать меня и задает вопросы по существу. Удачи, Иван!
@maks-xn6rg
@maks-xn6rg 11 күн бұрын
Чет водичка какая-то)) старый доклад актуальнее
@user-if1iw8dg5q
@user-if1iw8dg5q 12 күн бұрын
26.21 "если у Вас в одном кластере живет и дев и прод ...." - Чегооо? Отвага и безумие + экономия. Не делайте так(
@PahaUsd
@PahaUsd 12 күн бұрын
было интересно
@junegton
@junegton 2 ай бұрын
после фразы "куб не предназначен для одновременной работы с несколькими командами" - можно расходиться, у вас руки не из того места растут
@jidckii
@jidckii 2 ай бұрын
Рассказал про проблемы, а что это такое и как его использовать и кейсы, чёт ничего не рассказал. Зачем вообще мне этот вектор нужен? От того, что он "классный", чёт как то попробовать не захотелось)
@user-ec8lg6jt2n
@user-ec8lg6jt2n 2 ай бұрын
Настроил vector года 2 назад. Логи контейнеров в elasticsearch, логи nginx отдельно в clickhouse, до сих пор работает стабильно. Правда в clickhouse по факту через http вставляет, тот самый json insert.
@spiritcxz
@spiritcxz 2 ай бұрын
смешно 😄 1. что мешает держать тестовый и прод в разных кластерах или в разных неймспейсах. 2. так же допустим для теста в gitops репе можно создать тестовую и продовую папку для манифестов. 3. еще ни разу не было проблем с деплоем. 4. выпрямите руки и делайте правильное тегирование и проблем не будет. уже как неделю юзаю flux и проблем не знаю
@SlavaVy0
@SlavaVy0 2 ай бұрын
Классный доклад, архитектору бы немного подтянуть речь, чтобы голос был совсем дикторским, было бы прям совсем огонь!
@ivanbrykalov9955
@ivanbrykalov9955 2 ай бұрын
Спасибо, было весьма интересно. Уже используем декхаус, подумаем ещё над Лантри)
@batazor
@batazor 3 ай бұрын
werf в эпоху flux/argocd не очень понятен для меня а вот Nelm наверно будет интересно посмотреть
@andrew2066
@andrew2066 3 ай бұрын
Эх, я думал что в ролике будет идти речь чем заменить K8s (nomad, serverless etc) а тут просто о надстройке над ним для энтерпрайза.
@cucumbaislife
@cucumbaislife 3 ай бұрын
спасибо за подробный доклад. Именно такие вещи и двигают opensource. Желаю werf стабильного развития!
@semremal
@semremal 3 ай бұрын
Спасибо за демонстрации разницы между нормальными управленцами и теми, кто считает, что скрама (или альтернативы) достаточно
@user-gw6df6ns7e
@user-gw6df6ns7e 4 ай бұрын
Не всегда можно назад состояние откатить. Например прошла миграция в базу и убрали поля из таблицы. В модели они при откате появятся 😢.
@Lev637
@Lev637 4 ай бұрын
ну, это каждому на свой вкус и цвет. лично мы используем популярные фреймворки и очень довольны. конечно, каждый их под себя адаптирует, но если управлять этим с коучем или аспро.agile, например, то адаптация проходит проще
@sergeygoncharuk6258
@sergeygoncharuk6258 4 ай бұрын
"это каждому на свой вкус и цвет" - вот тут согласен на все 146%, если в вашем конкретном производственном процессе подходит готовое, то изобретать велосипед ни к чему
@smaileee
@smaileee 4 ай бұрын
вообще-то это была створка двери, а не крышка рояля...
@andrey.nekrasov
@andrey.nekrasov 4 ай бұрын
"Голый докер в 2024 вряд ли будет использоваться". Пишу из 2024. Ну более-менее докер уже начинает нами использоваться и кажется многие его уже не боятся :) Хотя некоторым бы стоило уже начать делать свои поделки в докере, мне все же удобнее было бы разворачивать, но они еще не умеют.
@berg4mut
@berg4mut 4 ай бұрын
Все это очень круто, но кто готов интегрироваться во флан продукты вместо того что-бы юзать ванильные решения, вопрос. Фор фан - гуд, для прода нот реди ет.
@ilyalesikov3868
@ilyalesikov3868 4 ай бұрын
werf опенсорсный, свободный и в CNCF (как и Helm), никаких других продуктов Фланта для работы не требует. Активных за последний месяц проектов (обычно один проект - один репозиторий), использующих werf, больше 10 тысяч. Конечно, не Helm, но всё же. Скоро ещё выделим эту новую подсистему развертывания в отдельный продукт (Nelm), он не будет затрагивать сборку и ряд других вещей, которыми werf занимается. Nelm будет прямой альтернативой Helm.
@VilikSpb
@VilikSpb 4 ай бұрын
Спасибо, очень интересно. Запишите по возможности подобное видео по trdl.
@DimosMos
@DimosMos 4 ай бұрын
Должен ли DevOps знать все детали разработки? Может, каждый должен заниматься своим делом? ✌️😉
@youmeek
@youmeek 4 ай бұрын
Спасибо. Отличный доклад!
@nobody_nowhere_
@nobody_nowhere_ 5 ай бұрын
очень не хватает еще vs helmfile вышло бы поинтереснее..
@Flant
@Flant 5 ай бұрын
на 52:12 как раз об этом:)
@romann1295
@romann1295 5 ай бұрын
Спасибо большое, было интересно. Пока только хельм юзаем, стоит рассмотреть и другие подходы
@evseevav
@evseevav 5 ай бұрын
Как можно так скучно рассказывать про такую интересную вещь?
@jidckii
@jidckii 5 ай бұрын
Потому, что они разработчики, а не рассказчики
@evseevav
@evseevav 5 ай бұрын
@@jidckii нельзя было найти разработчика-рассказчика? Ну или изложение более интересное сделать.
@ilyalesikov3868
@ilyalesikov3868 4 ай бұрын
@@evseevav Посоветуйте, что не так, постараюсь получше в следующий раз
@ilyalesikov3868
@ilyalesikov3868 4 ай бұрын
Хотя, справедливости ради, в этот раз мне самому не понравилось, как выступил. Когда пытался пересмотреть, хватило меня на пару минут. Мало времени выделил на подготовку, в итоге подтупливал и какое-то все такое вышло. Но если есть конкретные пожелания, я бы послушал
@alexanderr2688
@alexanderr2688 2 ай бұрын
@@ilyalesikov3868 а мне наоборот понравилось, всё по делу. Отдельно хочется отметить хорошее разрешение камеры, освещение и звук
@Flant
@Flant 5 ай бұрын
Вопрос, на который мы отвечали письменно в чате встречи: Вопрос: будет ли в werf поддержка Timoni + CUE? Ответ: У нас как раз появился новый движок деплоя, который пришел на замену helm и совместим с helm. Давать несколько альтернативных вариантов для деплоя - немного не наш путь, такой подход больше практикуется например в skaffold, который поддерживает множество бекендов, в том виде как они есть. У werf другой подход, мы стараемся предлагать один вариант и сильно дорабатываем его так, чтобы он соответствовал некоторым базовым требованиям.
@werf8888
@werf8888 5 ай бұрын
верф это мое имя
@aleks_strong
@aleks_strong 6 ай бұрын
спасибо, сжато и чётко)
@kl45gp
@kl45gp 7 ай бұрын
сволочи такую лекцию прервали!
@Holms
@Holms 7 ай бұрын
а gitlab autodevops это gitops или это gitops+ciops? там есть обратная связь, измены регистри там не имеет значения ) я удалил все образы и даже подменял существующий gitlab agent'у на это вообще плевать :) ну и там два способа либо pull либо push deployment. тоесть pull когда хранишь манифесты в репо и агент пулит в кластер изминения, а push когда совственно ci/cd пушит изминения но там есть обратная связь в deploy пайплайне и там собирается хелм сам по шаблонам что удобно при множестве микросервисов, мне вообще писать скрипты не надо все шаблонно :) правда вот со стэйджом я пока не разобрался но наверно у них есть решение и для стэджа с полным окружением под ревью и для миграций тоже.
@Flant
@Flant 5 ай бұрын
GitLab Auto DevOps - это «сахар», который в простых сценариях позволяет не думать о части конфигурации доставки приложения и настройки различного рода интеграций (в том числе с Flux, который реализует устоявшееся понимание GitOps). Но по большому счету, то, что дает GitLab AutoDevOps, можно самостоятельно построить на базе того же GitLab CI/CD или любой другой CI-системы.
@eletenkov
@eletenkov 7 ай бұрын
Слишком много воды.
@JohnSmith-ok1vi
@JohnSmith-ok1vi 7 ай бұрын
Иначе бы Дима не заработал 30 лямов за 22 год😁
@panchwall_devops
@panchwall_devops 7 ай бұрын
доходчиво как и всегда. спасибо
@alexandrkulakov7884
@alexandrkulakov7884 8 ай бұрын
Этот спич весьма занятен) Благодарствую)
@a1dwow
@a1dwow 8 ай бұрын
какое ПО вы используете для создания таких красивых презентаций ?
@andreypolovov5240
@andreypolovov5240 8 ай бұрын
Google slides, который не очень подходит для таких объёмов + дизайнеры с чувством прекрасного :)
@mixalic
@mixalic 8 ай бұрын
Чет грустно стало, на хрен я это посмотрел(
@mixalic
@mixalic 8 ай бұрын
Интересно на самом деле, спасибо за лекцию
@8462bb1
@8462bb1 9 ай бұрын
Наконец Привет
@Setapus
@Setapus 9 ай бұрын
вода.
@xxxxPomaHxxxx
@xxxxPomaHxxxx 9 ай бұрын
Сделали бы, для поиграться, в докере эту штуку, как с ранчером одна команда и готово `docker run --net host --privileged rancher/rancher`
@user-em3nt3kr2z
@user-em3nt3kr2z 9 ай бұрын
да все круто,ждем новую встречу!)
@user-di3nd4dk7d
@user-di3nd4dk7d 9 ай бұрын
Максим все круто но лучше пару таблеток валерьяны выпить иначе слушать сложно и больно
@russiantime778
@russiantime778 10 ай бұрын
Очень интересно, спасибо. От себя добавлю что каждый, условный критикал алерт должен автоматически порождать тикет в service desk. То есть должна быть интеграция системы мониторинга и SD. Тогда и ложных срабатываний меньше, потому как более ответственный подход будет к настройке триггеров. В своё время, лет 10 назад, Zabbix с OTRS пытался подружить).
@zuzexsupportonline
@zuzexsupportonline 10 ай бұрын
Спасибо ребята! Вы спасли столько часов в моей жизни!! Очень круто что вы разработали верфь!
@Petyaumniy
@Petyaumniy 10 ай бұрын
werf run максимально странное решение для тестирования. И вот почему. Я как разработчик уже имею полностью описаное развертывание своего приложения в helm chart. А это значит минимальными манипуляциями с имеющимся чартом (оборачиванием всех ресурсов в условные их отключатели) я могу поднимать необходимое количество уже настроеных на взаимодействие ресурсов для конкретного теста. В дефолтном хелм есть стандартный тестовый хук и аннотации для автоматического удаления созданых ресурсов после завершения теста. Раньше (год назад) я мог в верфе используя стандартный уже имеющийся чарт поднять необходимую тестовую инфраструктуру и тригернуть хук теста созданый на основе имеющегося бекенда со всеми енвами, секретами, инит/и_не_инит контейнерами, лимитами и т.д. Сейчас так могу только в хелме. В верфе сейчас мне предлагается первую часть (инфраструктуру теста) деплоить по старому чартом, а потом для чего-то взять и повторить вторую часть (сам тест) - всю тут работу, которая уже была выполнена в имеющейся конфигурации хелм чарта, которая всех устраивает, которая максимально близка к проду, взять и перенести её в werf run и потом сопровождать это одно и тоже в 2 местах!!! sic! У меня как пользователя возникает вопрос: а для чего собственно этот werf run нужен? - Если предполагается каноническое "само в себе" unit тестирование или linter - я предпочту уменьшить уровень абстракций. Не запускать gitlab-ci image:werf:stable, который потом сходит через werf в какой-то еще k8s кластер по api и запустит там тест. А запустить сразу image: repo:image-commit_hash и 1 тестовую команду в нем. Такой запуск гораздо понятнее для меня как для разработчика не желающего погружаться в devops тулзы и вообще их видеть. Вопросы тагирования? Ну дак они все так же автоматически решаются для меня выше с имутабельностью, скоростью, маштабированием и всеми плюшками. - Если это kind of e2e тестирования - я лучше добавляю помимо отключения ненужных сервисов в своем хелм чарте переопределение entrypoint/args уровня sleep infinity и лайвнес пробы в том контейнере в котором собираюсь запускать тесты, задеплою тестовое окружение и выполню тест через kubectl. Для меня как для разработчика главное чтобы мне не приходилось делать 2 раза одну и ту же работу в которой я могу ошибиться. Все эти возможности: что оно что-то там предварительно соберет - это ничто по сравнению с делать неинтересную работу 2 раза (от такого подхода самого по себе уже подгорает). И к тому же даже если оно и может что-то собирать, кто же ему позволит? Я не готов на стади выполнения тестов (= реквесты/лимиты контейнера пулящего строки с куба) резервировать ресурсы еще и под сборку. "Разделяйте стадии сборки и исполнения" 12 factors app (c). Из моего опыта (выше) он не нужен ни для чего. Очень печально (для меня :() что у разработчиков другое мнение и другие юз кейсы.
@ilyalesikov3868
@ilyalesikov3868 9 ай бұрын
Для запуска тестов, требующих инфру, предлагается: 1. По умолчанию: "werf converge --set infra.enabled=true" + "werf converge --set tests.enabled=true". По сути это то же, что и "helm install" + "helm test". 2. Другой вариант: "werf converge --set infra.enabled=true" + "werf kube-run". Этот вариант для того, чтобы по-простому выгрузить артефакты из теста (kube-run --copy-to/--copy-from), либо если лень делать отдельный чарт для тестов. Выгрузку артефактов добавим в будущем и в werf converge. Для запуска тестов без инфры: 1. `werf kube-run myimage -- mycommand`. Погружаться тут ни во что не нужно, это просто запуск команды в контейнере в кубе вместо локальной машины (хотя учиться работать с кубами разрабам придется в любом случае). Для тестирования/разработки у вас ведь всё-равно кубы есть? Вот их и используйте. Пока есть вариант ещё с `werf run`, оно работает в Docker'е локально, может и оставим его. kube-run добавляли из расчета, что и разработка и тестирование будут в кубах, и мы сможем полностью отвязаться от Docker'а (что было бы полезно в процессе миграции на Buildah). Основное предназначение kube-run - интерактивный запуск контейнеров при локальной разработке на той же платформе, на которой крутится прод (Kubernetes), а также запуск простых задач в CI (с точки зрения эксплуатации это не сильно отличается от "docker run", кроме того, что вычисления переносятся в кубы и их проще масштабировать). kube-run - это гибрид `docker run` и `kubectl run`.
@ilyalesikov3868
@ilyalesikov3868 9 ай бұрын
Большинство команд, отличных от `werf build`, действительно (по умолчанию) делает сборку. Хотя если образы уже были собраны, то оно, грубо говоря, просто скачает конечный образ, если он ещё не скачан. Большинство команд должны иметь флаг `--skip-build`, чтобы вместо пересборки просто упасть, если собранный образ не был найден в репозитории. Сейчас заметил, что в kube-run флага нет, и это мы что-то упустили, надо добавить. А вообще я с вами согласен в том, что мне тоже не нравится попытка собрать образы практически перед каждой командой. Мне `--skip-build` по умолчанию для CI было бы удобнее, но тут надо с коллегами обсуждать.
@ilyalesikov3868
@ilyalesikov3868 9 ай бұрын
И ещё по поводу этого: "В верфе сейчас мне предлагается первую часть (инфраструктуру теста) деплоить по старому чартом, а потом для чего-то взять и повторить вторую часть (сам тест) - всю тут работу, которая уже была выполнена в имеющейся конфигурации хелм чарта, которая всех устраивает, которая максимально близка к проду, взять и перенести её в werf run и потом сопровождать это одно и тоже в 2 местах!!! sic!" Такого не предлагаю, здесь лучше оставить всё как есть, разве что аналога `helm test` у нас сейчас нет, поэтому вторую часть (тест) надо как-то через `--set` включать/выключать вместо использования test-хука. Есть ещё более простой вариант, если инфра поднимается быстро: сделать тест post-install/update-хуком, и катить и инфру и тесты одним релизом с `werf converge`. И по поводу "потом сопровождать это одно и тоже в 2 местах": в этом, конечно, смысла никакого нет. Либо держите джобу с тестом в чартах, либо используйте `kube-run` для этого теста, но только что-то одно, оба сразу смысла нет.
@Rundik
@Rundik 10 ай бұрын
"он премайс"
@Rundik
@Rundik 10 ай бұрын
ДатаВолум
@sergeydev8273
@sergeydev8273 10 ай бұрын
Флант конечно лютые!) Качество материала и подачи просто пушка!
@evgeniipetrenko2019
@evgeniipetrenko2019 10 ай бұрын
А хранилище используется на Linstor DRBD?
@Flant
@Flant 10 ай бұрын
Да, LINSTOR. Вот тут подробнее можно почитать, что под капотом системы виртуализации: habr.com/ru/companies/flant/articles/715426/
@evgeniipetrenko2019
@evgeniipetrenko2019 10 ай бұрын
@@Flant интересно ваше мнение о Harvester hci
@kvapskvaps
@kvapskvaps 10 ай бұрын
@evgeniipereverzev2070 Harvester неплохой, на данный момент он выглядит наиболее завершённым проектом использующим KubeVirt. Однако хранилище longhorn не самое быстрое, и есть некоторые вопросы к отказоустойчивости. Сеть реализуется в класическом режиме бриджами, когда кубовая сеть подов используется только как дополнительная management network
@simplewhite9472
@simplewhite9472 10 ай бұрын
А еще интересно то, что при внедрении istio вы теояете Qos guarantee, из-за невозможности переопредения реквестов/лимитов у istio-init. То есть все ваши поды теперь будут burstable
@TheBasfeo
@TheBasfeo 10 ай бұрын
Один лучших докладчиков, которого интересно слушать. Что по линстору, что по небуле.
@musicthreads
@musicthreads 10 ай бұрын
Чесанул от призыва?
@vandud
@vandud 10 ай бұрын
мне кажется он слишком стар для этого
@musicthreads
@musicthreads 10 ай бұрын
@@vandud А мне кажется, что он слишком умён для этого
@agronaut2991
@agronaut2991 10 ай бұрын
это пять