Компания «Флант» (flant.ru) - специалисты по Kubernetes и DevOps. На рынке - с 2008 года. Сопровождаем production (и связанные окружения) любых масштабов в режиме 24×7 и под ключ, с помощью постоянной команды квалифицированных инженеров.
Внедряем отточенные многолетней практикой DevOps-процессы, помогаем разработчикам правильно и эффективно использовать контейнеры, K8s и другие технологии для реализации CI/CD и связанных задач, бизнесу - достигать своих целей. Обслуживаем 1000+ приложений в production. Ориентируемся на долгосрочное сотрудничество.
Первый в России сертифицированный поставщик услуг по Kubernetes (статус KCSP в CNCF). В штате - десятки инженеров, сертифицированных как Certified Kubernetes Administrators.
Авторы werf (werf.io), shell-operator и других Open Source-проектов для cloud native-экосистемы. Регулярно выступаем на конференциях.
чет вы переусложнили всё, целая команда работает над key value хранилищем ахахахахах мы храним секреты в коде проекта в гите и докер образах, удобно и ничего лишнего - минимализм и простота
В видео-докладе не было полностью раскрыто про слои docker-образа, которые пушатся в registry как отдельные docker-образы (для werf). С кэшированием слоев в рамках docker-а показали, а с werf-ом - нет. Так что происходит в werf, если изменяется какой-то слой docker-образа? Он только измененный слой запушит в registry? 11:30
ААААА! 64гига... Как мртг, катси, нагиос и (о боже) опен-вьюв 20 лет назад мониторили?.. "Дайте мне больше денег (т.е. памяти, цпу и айопсов)" (с) любой продавант ЗЫ: спикеру Вове (как сам представился) респект. Всё очень доступно и интересно ) ЗЫЫ: TSDB придумывали-придумывали-придумывали. "а давайте ноусиквел новую поверх тсдб придумаем" )
Я не к тому, что увеличилось количество метрик. Я к тому, что нафига оно увеличилось? Т.е. просто снизилось требование к анализаторам (человекам)? Отучились анализировать?
@@VasiliyVolkov Действительно, сейчас количество метрик кратно увеличилось, и зачастую меня это тоже шокирует. Но я попробую побыть адвокатом текущих систем мониторинга. Если вернуться на 20-25 лет назад, то системы были достаточно простыми: монолитное приложение, запущенное на физическом сервере, и рядом ещё база данных, на соседнем сервере. Всё, что нам нужно было знать, укладывалось в пару сотен метрик. Сейчас же ситуация совсем другая: монолит превратился в десятки, а то и сотни микросервисов, а инфраструктура обросла дополнительными слоями: виртуализация, контейнеризация, оркестрация. Всё это приводит к кратному росту количества метрик. С другой стороны, есть некая путаница в терминах. С точки зрения Prometheus, да и любой современной системы мониторинга на базе TSDB, значение имеют временные ряды. Например, http_request_total{instance="1.1.1.1", method="GET"} и http_request_total{instance="2.2.2.2", method="GET"} - это два временных ряда, но метрика-то одна, а не две! На мой взгляд, это важно понимать. В докладе как раз идёт речь о количестве временных рядов, а не метрик. Однако сейчас у нас есть полноценный язык запросов (например, PromQL), который позволяет работать не напрямую с временными рядами, а строить агрегаты на их основе. Тем не менее, часто возникает ситуация, когда в лейблы пытаются добавить слишком много ненужной информации, что тоже ведёт к росту количества временных рядов. В итоге, 64 ГБ оперативки для мониторинга кажется слишком много, но проблема заключается не в увеличении количества метрик как таковых, а в недостаточном понимании инструментов и неправильной работе с ними.
Дима, что случилось? ну ладно имя сменил или фамилию, но все вместе? ну это так шутки, спасибо что работаешь на Русско-говорящую публику, и продолжаешь делать опенсорс
Вы делаете хорошее решение, но не нравится цена, а в community нет графического интерфейса а значит и смысла. Не совершайте ошибок прошлых хороших проектов, технически превосходящих конкурентов, но дорогих и из-за этого погибших.
@@михаилказанцев-п4щ "цена равна квартире в нашем регионе" <- вот что за манера вокруг да около? говори регион, стоимость квартиры. а так - вообще ничего не понятно.
Материал подается хорошо, для введения в тему - самое то. Только докладчик слишком много жестикулирует, ОЧЕНЬ отвлекает от просмотра картинки. Если не получается контролировать руки, то можно просто "обрезать" человека по плечи или вообще убрать из кадра бОльшую часть времени.
После прослушивания этого доклада я ощутил смесь разочарования и потенциала. Начиная с презентации, я надеялся увидеть четкие, практические подходы к управлению проектами, но вместо этого мне пришлось столкнуться с бесконечным потоком слайдов и хаосом в организации материала. Особенно это касается момента, когда обсуждалась "проблема часа инженера". Введение концепции 'слотов времени' и универсальных единиц измерения работы инженера кажется непродуктивным. Это упрощает понимание человеческого таланта и креативности до простых цифр, что, на мой взгляд, не отражает истинную ценность инженерной работы. Докладчик казался потерянным в собственных объяснениях, что подрывает доверие к представляемым методам. Как можно ожидать, что кто-то захочет применять эти методы, когда даже спикер кажется неуверенным в их пользе? Ещё один критический момент - это непрекращающееся переключение слайдов. Это отвлекает и делает следование за ходом доклада утомительным. Каждый раз, когда докладчик пытался объяснить свои методы, это звучало скорее как отчаянная попытка звучать убедительно, нежели как демонстрация эффективного решения. Если бы Стив Джобс находился в зале, я уверен, он бы поставил под вопрос столь сложный подход к измерению работы инженеров, упускающий из виду важность инноваций и креативности. Он всегда подчеркивал, что величайшая ценность заключается не в количестве потраченных часов, а в качестве и влиянии созданного продукта. Нужно сосредоточиться на том, как эти методы могут реально улучшить работу команды. Этот доклад был упущенной возможностью демонстрации эффективной интеграции скрама и канбана в рабочем процессе. Надеюсь, что в следующий раз мы увидим от Фланта более вдохновляющий и понятный доклад.
Иван, привет! Рад видеть, что бывшие коллеги-ПМы интересуются моим докладом, правда очень странно видеть отзыв на доклад о фреймворке, написанный таким образом, как будто ты не знаешь, как это работает в жизни и требуешь практических подходов, по которым работал сам. За критику по количеству слайдов спасибо! Учту в будущем. А сейчас, так как ты смотрел этот доклад в видео-версии, предлагаю лайфхак: можно нажать паузу и внимательно рассмотреть слайд, я старался сделать так, чтобы информация на нем иллюстрировала слова, которые я говорю и делала их наглядными. К сожалению, тема доклада довольно узкая, а времени на ее раскрытие не так много, чтобы в доклад уложить еще и методы развития и проявления творческих способностей инженеров команды. Да и тебе ли не знать, что во Фланте существуют для этого иные механизмы, например performance review, с описанием которого можно ознакомиться в этом докладе ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-japvfswnwtg.html Ну и наконец, если бы Стив Джобс был на моем докладе, я был бы счастлив, что такого масштаба человек пришел, чтобы послушать меня и задает вопросы по существу. Удачи, Иван!
Рассказал про проблемы, а что это такое и как его использовать и кейсы, чёт ничего не рассказал. Зачем вообще мне этот вектор нужен? От того, что он "классный", чёт как то попробовать не захотелось)
Настроил vector года 2 назад. Логи контейнеров в elasticsearch, логи nginx отдельно в clickhouse, до сих пор работает стабильно. Правда в clickhouse по факту через http вставляет, тот самый json insert.
смешно 😄 1. что мешает держать тестовый и прод в разных кластерах или в разных неймспейсах. 2. так же допустим для теста в gitops репе можно создать тестовую и продовую папку для манифестов. 3. еще ни разу не было проблем с деплоем. 4. выпрямите руки и делайте правильное тегирование и проблем не будет. уже как неделю юзаю flux и проблем не знаю
ну, это каждому на свой вкус и цвет. лично мы используем популярные фреймворки и очень довольны. конечно, каждый их под себя адаптирует, но если управлять этим с коучем или аспро.agile, например, то адаптация проходит проще
"это каждому на свой вкус и цвет" - вот тут согласен на все 146%, если в вашем конкретном производственном процессе подходит готовое, то изобретать велосипед ни к чему
"Голый докер в 2024 вряд ли будет использоваться". Пишу из 2024. Ну более-менее докер уже начинает нами использоваться и кажется многие его уже не боятся :) Хотя некоторым бы стоило уже начать делать свои поделки в докере, мне все же удобнее было бы разворачивать, но они еще не умеют.
Все это очень круто, но кто готов интегрироваться во флан продукты вместо того что-бы юзать ванильные решения, вопрос. Фор фан - гуд, для прода нот реди ет.
werf опенсорсный, свободный и в CNCF (как и Helm), никаких других продуктов Фланта для работы не требует. Активных за последний месяц проектов (обычно один проект - один репозиторий), использующих werf, больше 10 тысяч. Конечно, не Helm, но всё же. Скоро ещё выделим эту новую подсистему развертывания в отдельный продукт (Nelm), он не будет затрагивать сборку и ряд других вещей, которыми werf занимается. Nelm будет прямой альтернативой Helm.
Хотя, справедливости ради, в этот раз мне самому не понравилось, как выступил. Когда пытался пересмотреть, хватило меня на пару минут. Мало времени выделил на подготовку, в итоге подтупливал и какое-то все такое вышло. Но если есть конкретные пожелания, я бы послушал
Вопрос, на который мы отвечали письменно в чате встречи: Вопрос: будет ли в werf поддержка Timoni + CUE? Ответ: У нас как раз появился новый движок деплоя, который пришел на замену helm и совместим с helm. Давать несколько альтернативных вариантов для деплоя - немного не наш путь, такой подход больше практикуется например в skaffold, который поддерживает множество бекендов, в том виде как они есть. У werf другой подход, мы стараемся предлагать один вариант и сильно дорабатываем его так, чтобы он соответствовал некоторым базовым требованиям.
а gitlab autodevops это gitops или это gitops+ciops? там есть обратная связь, измены регистри там не имеет значения ) я удалил все образы и даже подменял существующий gitlab agent'у на это вообще плевать :) ну и там два способа либо pull либо push deployment. тоесть pull когда хранишь манифесты в репо и агент пулит в кластер изминения, а push когда совственно ci/cd пушит изминения но там есть обратная связь в deploy пайплайне и там собирается хелм сам по шаблонам что удобно при множестве микросервисов, мне вообще писать скрипты не надо все шаблонно :) правда вот со стэйджом я пока не разобрался но наверно у них есть решение и для стэджа с полным окружением под ревью и для миграций тоже.
GitLab Auto DevOps - это «сахар», который в простых сценариях позволяет не думать о части конфигурации доставки приложения и настройки различного рода интеграций (в том числе с Flux, который реализует устоявшееся понимание GitOps). Но по большому счету, то, что дает GitLab AutoDevOps, можно самостоятельно построить на базе того же GitLab CI/CD или любой другой CI-системы.
