Георг Гаал "Краш-курс по fluxcd в реальной жизни"
Summary
TLDRДорогой аудиторией, сегодня Георгau de Vox инженер из компании Зодиак Маркерс поделился своим опытом внедрения подхода DevOps, в частности, с использованием инструментов от компании Flux. Рассмотрены предыстория и развитие автоматизации инфраструктуры, преимущества использования облачных технологий и Kubernetes. Основное внимание уделено деталям реализации детокса, автоматизации доставки приложений и управление конфигурациями с использованием Flux. Обсуждение включает в себя преимущества и возможности Flux, влияние на безопасность и производительность, а также рекомендации по миграции и оптимизации инфраструктуры.
Takeaways
- 😀 Георгей Вовк, инженер-девопс, поделился своим опытом внедрения подхода DevOps с использованием инструментов компании Luxide.
- 🔧 В прошлом настройка серверов вручную была не масштабируемой и дорогой, что не позволяло быстро внедрять изменения.
- 🌐 Появление инструментов для управления конфигурацией и технология облака способствовали унификации инфраструктуры и упрощению управления ресурсами.
- 📚 Введение подхода GitOps предполагает управление инфраструктурой через Git-репозиторий, что обеспечивает версионирование и откат к предыдущим версиям.
- 🛠️ Использование системы Flux для автоматической доставки приложений с использованием манифестов и helm-шаблонов.
- 🔄 Проблемы асинхронности в GitOps могут приводить к задержкам в применении конфигураций и возможным ошибкам.
- 👀 Важность мониторинга и тестирования изменений в управляющих репозиториях для предотвращения ошибок и быстрого выявления проблем.
- 🔒 Управление доступом на основе ролей для обеспечения безопасности и контроля над изменениями в инфраструктуре.
- 🔄 Гибкость GitOps подхода в реализации различных стратегий доставки, включая модульность и повторное использование компонентов.
- 🔄 Flux как инструмент поддержки GitOps подхода, обеспечивающий автоматизацию процесса доставки и упрощающий управление инфраструктурой.
- 🔗 Георгий Вовк выделил преимущества использования Flux, включая его профессионализм, поддержку сообщества и интеграцию с Microsoft Azure.
Q & A
Что такое подход 'детокс' (detox) и как он связан с инструментами Luxide?
-Подход 'детокс' - это методология управления инфраструктурой и конфигурациями, которая позволяет описывать целевую систему и автоматизировать процессы доставки. В контексте инструментов Luxide, это означает использование детекса для управления облачной инфраструктурой и серверами.
Какие проблемы с настройкой серверов возникали до появления инструментов для управления конфигурацией?
-До появления таких инструментов, настройка серверов вручную была не масштабируемой и не позволяла быстро внедрять изменения, так как всегда был риск ошибок, и невозможно было гарантировать возвращение к определенному состоянию сервера.
Как технологии облака влияли на развитие подхода детокс?
-Технологии облака предоставили инструменты для управления облачными ресурсами в различных облаках, что унифицировало описание инфраструктуры и позволило более эффективно управлять ресурсами, включая в себя автоматизацию и уменьшение человеческих ресурсов.
Что такое 'губернатор' и как он связан с детоксом?
-Губернатор - это инструмент, который используется для управления конфигурациями и автоматизации процессов доставки в рамках подхода детокс. Он позволяет описывать инфраструктуру и применять изменения через агентов.
Какие преимущества предлагает подход детокс для управления инфраструктурой?
-Детокс предоставляет возможность централизованного управления большим количеством серверов, использования подходов из разработки, включая тестирование и применение политик. Он также обеспечивает определенность контроля доступа и возможность отката к предыдущим состояниям.
Какие проблемы могут возникнуть при реализации подхода детокс?
-Одной из проблем может быть асинхронность в применении изменений, что может привести к задержкам в конфигурации. Также могут возникать проблемы с неправильным применением конфигураций или ошибками в манифестах.
Что такое 'флекс' (Flagger) и как он используется в контексте детокса?
-Флекс (Flagger) - это инструмент для автоматической доставки приложений и управления релизами в Kubernetes. Он используется в рамках детокса для управления процессом доставки и обновления приложений.
Какие возможности предлагает инструмент Флекс для управления приложениями?
-Флекс предлагает возможности для автоматического релиза, обновления приложений, управления агентами, настройки уведомлений о новых релизов и событиях в кластерах, а также поддержку различных способов упаковки приложений, таких как Helm и кастомные релизы.
Какова структура компонентов внутри Флекса?
-Флекс построен по микросервисной архитектуре и включает в себя три основных компонента: контроллер, оператор и применитель. Каждый из них выполняет специфические задачи, такие как получение данных, управление релизами и применение манифестов.
Какие сущности работает с контроллером в Флексе?
-Контроллер в Флексе работает с такими сущностями, как ресурсы, манифесты Губернатора и кастомные ресурсы. Они позволяют описывать конфигурацию, накладывать патчи и управлять процессом доставки.
Какие возможности предоставляет Флекс для работы с мультитантными кластерами?
-Флекс позволяет использовать иерархические структуры и разбивать компоненты по подкаталогам, что обеспечивает гибкое управление мультитантными кластерами. Он также поддерживает использование инструментов, таких как OPA или Kyverna, для дополнительной безопасности и контроля.
Outlines
😀 Введение в детокс и инфраструктуру Luxide
Георгей Я. Vox, инженер из России, делится своим опытом внедрения подхода детокс с инструментами Luxide. Он описывает историю развития от ручного настройки серверов к использованию облачных технологий и автоматизации инфраструктуры с Губернатором и детоксом, что позволяет управлять инфраструктурой через код и обеспечивает масштабируемость и удобство.
📚 Основы подхода детокс и его преимущества
Второй параграф посвящён основным понятиям детокса, его развитию и преимуществам. Георгий Я. Vox объясняет, что детокс - это систематический подход к развертыванию и обслуживанию инфраструктуры, позволяющая управлять изменениями и обеспечивать воспроизводимость конфигураций.
🛠️ Компоненты и архитектура флаг-сити
Третий параграф фокусируется на компонентах и архитектуре флаг-сити, одной из реализаций детокса. Рассматриваются три основных компонента: контроллер, оператор и кастомизатор, каждый из которых несет ответственность за определенную часть процесса управления инфраструктурой.
🔄 Автоматизация доставки приложений с флаг-сити
В четвёртом параграфе рассматривается процесс автоматизации доставки приложений с использованием флаг-сити. Обсуждается использование манифестов для описания состояния приложений и инфраструктуры, а также автоматическое обновление приложений с помощью хуков и триггеров.
🔧 Практическое применение флаг-сити в инфраструктурном управлении
Пятый параграф посвящён практическим шагам по внедрению флаг-сити в управление инфраструктурой. Рассказчик описывает процесс bootstrap'а, организацию репозиториев, использование кастомных объектов и разделение конфигураций для разных окружений.
🔄 Управление обновлениями и безопасности с флаг-сити
В шестом параграфе обсуждается управление обновлениями приложений и инфраструктуры с помощью флаг-сити. Рассматриваются методы обеспечения безопасности, включая тестирование изменений в изолированных средах и автоматическое применение патчей.
🤔 Вопросы и ответы о масштабировании и миграции с флаг-сити
Седьмой параграф включает в себя диалог о масштабировании флаг-сити на крупные кластеры и вопросы о миграции с предыдущих версий. Обсуждается управление большим количеством объектов и возможностей миграции с предыдущих конфигураций.
🌐 Многокластерное управление с флаг-сити
Восьмой параграф затрагивает возможность использования флаг-сити для управления несколькими кластерами. Обсуждается эффективность и оптимизация использования флаг-сити в многокластерных средах с высокими требованиями к производительности.
🏢 Применение флаг-сити в корпоративной среде
Девятый параграф заключает доклад, обсуждая применение флаг-сити в корпоративных средах и его способность к эффективному управлению инфраструктурой в больших компаниях с множеством команд и проектов.
Mindmap
Keywords
💡детокс
💡манифесты
💡гидропозиция
💡облачная инфраструктура
💡флекс
💡конфигурация
💡репозиторий
💡автоматизация
💡контроль версий
💡облачные сервисы
💡сетевая безопасность
Highlights
Внедрение подхода детокс для облачной инфраструктуры с использованием инструментов Luxide.
Георг де Вокс, инженер из России, обсуждает свои пять лет опыта работы в крупных компаниях.
Проблемы с ручной настройкой серверов и немасштабируемость старых подходов.
Введение инструментов управления конфигурацией для более эффективного управления большим количеством серверов.
Рост технологии облака и появление инструментов для управления ресурсами в различных облаках.
Введение концепции GitOps и его реализации в инфраструктурном управлении.
Описание детокса как развития инфраструктуры с использованием описаний целевых состояний и агентов.
Преимущества подхода детокс для тестирования и применения политик в разработке.
Управление большим количеством кластеров из одной точки и использование репозиториев для описания инфраструктуры.
Контроль доступа и история действий в рамках детокс-подхода для улучшенной прозрачности и обратной трассировки.
Проблемы асинхронности и необходимость тестирования и отслеживания изменений в детокс-подходе.
Флаг Сидит (Flux) как инструмент для реализации детокс подхода с поддержкой Kubernetes и облака.
Преимущества использования Флаг Сидит, включая его простоту, гибкость и широкую поддержку сообществом.
Функции Флаг Сидит для автоматического релиза и управления агентом с уведомлениями о новых версиях.
Микросервисная архитектура Флаг Сидит и его основные компоненты: Контролер, Оператор и Кастомайзер.
Использование Флаг Сидит для управления приложениями и инфраструктурными изменениями в различных средах.
Практическое применение детокс подхода и Флаг Сидит в крупном масштабе и на примере реальных проектов.
Возможности Флаг Сидит для работы с мультитантными кластерами и управлением большим количеством команд.
Ресурсы и сообщества Флаг Сидит для поддержки пользователей и обмена опытом.
Transcripts
Добрый день коллеги сегодня я хотел бы
поделиться своим позитивным опытом по
внедрению подхода детокс на примере
инструментов luxide Меня зовут георгау Я
de Vox инженер последние 5 работал в
крупных компаниях России например 7 x 5
Райффайзен На текущий момент времени
занимаюсь поддержкой облачным
инфраструктуры в компании зодиа маркерс
по совместительству различных Telegram
каналов войти направленности собственно
Давайте поговорим о предпосылках того
как мы подошли к Родине детокса
давным-давно мы занимались тем что
настраивались сервера вручную этот
подход был не масштабируемый он не
позволял нам носить нормальные изменения
Потому что
всегда был риск того что что-то пойдет
не так мы никогда не могли гарантировать
того что мы можем вернуться к
конкретному состоянию сервера
естественно это было очень дорого и не
позволяло масштабироваться поэтому
где-то примерно начале 2000 году
появились инструменты для управления
конфигурации
они позволили управлять большим парком
виртуальных машин или железных серверов
и при этом задействовать минимальное
количество человеческих ресурсов далее
произошел взлет технологии облака
появились другие инструменты такие как
фармейшен появился который позволяет
управлять облачным ресурсами в различных
облаках и таким образом унифицировать
описание нашей инфраструктуры Ну и в
конечном счете появился губернатос и
здесь Подходим к тому что нам каким-то
образом нужно иметь его настраивать
соответственно
появился такой подход как детокс это по
сути развитие инфраструктуры
у нас он реализуется тем что у нас
имеется некое описание
целевой системы которую мы хотим
применить инфраструктуру есть некий
Агент также
описание будет применять в данном случае
он будет устанавливаться пластырь при
этом так как мы управляем через
гидропозитурию э наших инфраструктуры то
мы можем применять все те самые подходы
которые мы используем разработки
получается тестирование можем применять
какие-то политики в общем этот подход
очень удобен на самом деле и позволяет
управлять большим количеством пасторов
из одной точки Ну или примерно
мы видим все текущее всё целевое
описание в одном дитрепозитории например
и понимаем что мы хотим это Мы также
дополнительно получаем определенности
контроля доступа на базе управления того
какие пользователи могут репозитории
ходить видеть какие там есть файлы
манифеста история действий плюс-минус
нам понятно что и когда было за
дополнено в классе мы всегда можем
откатиться на какой-то момент в истории
и получить состояние
в прошлый момент также если мы немножко
постараемся мы можем разбить ваше
описание на определенные модули на
какие-то компоненты и таким образом их
переиспользовать также мы получается
унифицируем процессы доставки нашего
приложения
Вот потому что детокс подход по большому
счету он и позволяет нам
определенную версию программного
обеспечения Какие проблемы этому у нас
возникают Дело в том что этот подход
реализуется через асинхронность Потому
что если мы закомитим какие-то новые
манифесты территории они применяются к
сожалению не сразу пойдет определенное
время будет некий конфигурации
появляется куча нового линга который
необходимо изучать действительно могут
возникать проблемы Что например один
работает не применяет конфигурацию или
мы закомитель кривые манифесты поэтому
нам нужно очень важно следить что мы
конкретно пометим управляющую
репозитории и тестировать
это не является глобальной проблемой
потому что все равно нужно открывать
мониторию и в целом
если немножко поработать с этим подходом
то становится понятно что он достаточно
удобно конкретно почитать про то как
именно формулируют описание detops и его
сущность его разработчики компания можно
посмотреть по ссылке и также смотреть
там же все его преимущества А дальше мы
посмотрим Собственно как будет выглядеть
процесс доставки сборки нашего положения
Вы готовы на данной диаграмме как раз
представлена путь от того как
разработчик закомить репозитории до его
развертывания вы целевом губернатор мы
видим то что на самом деле это подход
абсолютно не исключает себя
стадию сборки
Нам нужно будет ее
реализовывать или использовать текущего
подхода что у нас здесь меняется у нас
здесь появляется такая управляющий
репозитории которые мы складываем
гранаты с манифесты и флаг
студенток Оператор будет эти манифесты
применять и в случае изменения нашего
приложения да либо у нас будут меняться
манифесты либо можно настроить третье
образование об этом чуть позже расскажу
да и у нас будет происходить
автоматически такой новой версии это
Рабочая схема она реализована у меня уже
достаточно большом количестве она
доказала свою способность схема кстати
говоря взята у Майкрософт
чего бы я не хотел в данном докладе
освещать это конференцию между
различными инструментами потому что
подход стал действительно популярным и
уже появилось несколько конкурирующих
инструментов таких
реализуют аналогичную подходы но я думаю
что Каждый должен принимать свое
взвешенное решение о том как инструмент
ему подходит но по большому счету
принципе которые заложены сам подход они
везде одинаковые поэтому это остается
слушателя
логично для себя я выделил преимущества
Почему не лично нравится флаг Сити
во-первых Я его использую уже Достаточно
давно еще с первой версии ребята очень
много
переработали посмотрели что было не так
в первом в первой интерации и продукт
действительно стал удобным
разработчиками флаг Сиде является
компания вервокс ее профессионализм
профессионализм ее разработчиков
Абсолютно без проблем потому что они
разработали когда-то давно один из
известных
губернатоса под названием конечно
достаточно странно говорить 23 году но
Давно он был на вершине и был достаточно
без альтернативным также флаг сидит
принят вы проекте нцф он стал
участником То есть это доказывает зрелый
за ним стоит комьюнити и в случае
каких-то проблем вы не останетесь
Наедине с ними и сможет вам помочь также
я бы еще добавил бы что фла и теперь
используется как стандарт поставки
положения в области Microsoft esu тоже
доказывает то что решение зрелое и
соответственно Если Вы его знаете
ваша конкурентность
конкурентоспособность на рынке
повышается еще очень интересной новостью
было недавно то что отказываются от
встроенных агентов и тоже будет
предлагать флаг сидит как стандартное
средство доставки кода вы губернатор Об
этом можно посчитать по ссылочке
Ну а далее Давайте поговорим о том какие
возможности флаг доставляет как я уже
сказал его достаточно удобно
использовать для автоматического релиза
Потому что есть соответствующие
компонент отслеживает новые
чарты он флаг сумеет обратно
синхронизировать состояние кластеров это
возможность
частично реализовано но через неё как
раз и происходит процесс обновления
приложений
Также имеется очень удобная утилита
консольная для управления
этим приложением этим агентом я чуточку
попозже об этом расскажу можно
настраивать уведомления о появлении
новых релизов и событие кластеры у нас
появилась
положение мы можем легко получать
уведомление куда угодно удобно потому
что сразу видно что у нас происходит или
где у нас произошли какие-то проблемы
очень интересно то что Флакс на самом
деле нет накладывает каких-то особых
ограничений на то как Вы будете
использовать его основной функционал это
взять манифеста который лежат
определенных источников и применить их
на классов и поэтому в принципе если
немножко посидеть подумать Можно даже
собрать
У нас есть множество команд и они должны
друг другу мешать и разделить правами
доступа
можно сделать нормальную безопасность
флаг поддерживает различную способы
упаковки приложений среди них самыми
основными являются хельм частые и
кастомайцы здесь можно взять каталог
манифестами и его применить помощи
флакса если Нам требуются какие-то более
расширенные возможности по релиз
менеджмент Например наречные
можно взять дополнительный компонент от
тех же разработчиков ответ название у
него есть свой способ описания того как
должен происходить положение и он
нативно ложится на
этом сайте я решил показать как выглядит
консольные утилита для управления можно
увидеть то что при помощи можно делать
множество различных действий установка
агентам посмотреть что там у нас
происходит с налогами под капотом
произвести сравнение манифестов
примененных пластырей и репозиторий и
так далее тому подобное я найду на
каждодневной основе использую она очень
удобная оказалась вот Давайте теперь
поговорим собственно о том какие
компоненты есть внутри флакса Он
построен по микросервисной архитектуре и
в нем Имеется три основных компонента
первый компоненты контроля как следует
из названия Он занимается тем что
получает данные из различных источников
то есть из репозиториев чертов из
гиперпозитория где у нас могут лежать
манифесты вне зависимости от того что
это у нас
завайдер будет
дальше он эти сущности
делает доступными для остальных один из
контроля
контроля который собственно опять же из
названия очевидно занимается тем что
устанавливает обновляет удаляем релизы
и Кастома из контроля который название
достаточно интересное но по большому
счету Он занимается тем что просто
применяет манифесты из источника
Вот это основные наши компоненты
Давайте теперь поговорим о том какие у
нас есть сущности
контроля работает сущности под названием
по сути просто некий описание некоторых
каталога внутри
ресурсов также и манифест губернатоса
сдобренные файлом в этом случае у нас
появляются дополнительные возможности
связанные с тем что часть ямы можно
создавать
и это будет работать примерно так если
бы каталог применили через
один к одному счету разница особо нету а
также объект позволяет накладывать патчи
бесконечного манифеста таким образом
можно делать вариативность применения
наших манифестов создавать различные
окружения или параметризировать наше
положение это показано на скриншоте при
помощи параметров пост-бит
еще очень важный параметры он нам
говорит о чем что если Мы какие-то
манифесты удалим из
изначального репозитория флаг почистить
простые удалить те объекты которые стали
больше не нужны еще очень важной
полезной возможностью является опция
которая позволяет
объединять цепочки Когда применяется
один а потом последовательно 2 это может
быть очень важно если вы например хотите
доставлять компоненты ваших положение в
какой-то очередности и я сталкивался с
такой проблемой например да что если
И в чем смысл порядок применения
манифестов сам по себе неопределен если
вы захотите например применить какие-то
кастомные ресурсы а середины у вас пока
еще в пластыри нету то соответственно
применение манифестов не пройдет так как
решить эту проблему очевидное решение
разделить на несколько незрешено в одном
описать сердечки другом описать уже те
объекты которые все этим
соответствуют и тогда у нас все будет
порядке все будет
применяться вот есть еще очень такой
интересный момент связанный с Путаница
потому что как вы могли заметить у нас
флаксовский объект называется но у нас
же есть и файл кастомайзер который тоже
И это путает новичков здесь нужно быть
очень внимательно потому что хоть это и
специфированные объекты по сути яму файл
но они разные можно представить что
флаксов это на самом деле контейнер для
манифестов среди которых есть
просто будьте внимательны что есть
некоторые терминал логическая Путаница и
нужно понимать О чем конкретно будет
каждый конкретный момент времени говорим
соответственно Откуда мы можем
брать
манифесты для этих кастомизирующих
потому что мышцам указываем источник
Откуда мы хотим
источника может быть погиб репозиторий
который определяется как ссылкой по
протоколу SS
можно вообще любой брать можем указывать
на конкретный раньше
на какую-то конкретную так можно указать
реквизиты доступа к нему если он не
публичный все сделано для людей также
можно использовать такую Интересный
вариант хранения
манифеста как оси репозитории
это по сути обычный репозитории которые
могут храниться и прочее но мы можем
манифеста запаковать в отдельный так за
и положить таким образом
на самом деле система очень гибкая и она
не ограничена каким-то одним источником
соответственно третий вариант
Откуда мы можем брать наши манифеста это
фильм черты хейм черты у нас хранятся
очевидно в Кемере пользователей объект
Откуда эти черты брать и установка
самого релиза происходит
через отдельный объект под названием где
мы указываем
указываем имя черта можем указать
различным дополнительный параметры
умолчанию ставятся текущие интервалы
синхронизации То есть это через те
интервалы через которые у нас будет
попытка
пересинхронизации перед применения
можем указать версию как специфированное
значение в этом отношении у нас будет
постоянно одной версии и будет
требоваться ручное обновление на самом
деле рекомендую делать на продажу по
сторонам потому что у меня уже была
история когда я поставил версию
плавающую звездочку да то есть это будет
означать то что флаг
последнюю версию всегда стоят последнюю
версию и
был сбой и этот сбой был признан самими
разработчиками Но вот к сожалению
пришлось потратить отдельное время для
того чтобы понять в чем была его причина
если мы хотим
параметры черта переопределить флаг
предоставляет такую возможность У нас
есть ключевое слово описание релиза при
помощи которого мы можем передать
значение соответственно
если у нас есть какие-то дефолтные
значения черта который мне зашито
применяются если мы определили они
переопределяются также дополнительно
можно очень удобная возможность брать
значение из уже созданных в пластыре
секретов или мапов это бывает удобно
Если мы хотим
уменьшить количество хода или у нас там
есть какие-то секреты
внешних источников или подготавливается
и это позволяет делать достаточно
развесистые и гибкий конфигурации
что еще важно упомянуть то что фильм
релизы
могут
если у нас там есть какие-то долгие
операции нам соответственно нужно
выставить правильно тайм-аут Нам нужно
обязательно выставить Количество попыток
установки обновления чтобы это все
наехала и еще очень важный момент если
мы поменяем те объекты
управляются соответственно
флаг не знает ничего об этом и их
видоизменять не будет у нас изменения
произойдут только случае если вышла
новая версия hearcharte или Мы например
изменили изменили исходный в этом случае
ваша изменение перезагрузится это
отличие от объекта кастомизации все-таки
Существует
еще очень удобно использовать релизы в
случае если мы не можем менять
объекты получается
[музыка]
по сути
основная патчей
таким образом можно Дешево сердито
менять ведение фильмов я сильно Не
рекомендую этим увлекаться потому что
это достаточно нетривиально такая черная
магия Вот и становится тяжело читать что
у нас происходит
в общем три примера вот я здесь показал
того какие патчи мы можем накладывать
Соответственно что мы теперь научились
делать Мы научились писать кастомайзер
Мы научились ставить 7 релизы ими очень
удобно ставить системные компоненты
индексы
менеджер
мониторинг комиссию С обязательным но
возникает вопрос Что же нам делать все
таки с нашим положением потому что мы
можем написать
манифеста Да мы же хотим получить
обновление Здесь нам на помощь приходит
дополнительный компонент время под
названием он состоит из двух
микросервисов
в чем их задача имидж рефлектор
занимается тем что он смотрит в
определенный
репозитории докер Абазов
простите за такую терминологию надо быть
контейнер
и передает информацию о том какой у нас
образ появился Какой последний вы им еще
автоматически
контроля уже умеет брать манифест
репозитория и определенным образом Для
этого нам нужно подготовить ряд ресурсов
которые это автоматизация запускают Но
основной Смысл в том что нам нужно
проанатировать
те манифесты которых имеется переменная
имя образа вот такой вот фразы указать
его название тогда случится автомагия и
При появлении нового образа контейнера у
нас изменится новая версия честно скажу
разработчики от этой возможности всегда
просто в восторге потому что
выглядит как магия и мы получаем
последнюю версию положения вот опять же
как я уже сказал если нам необходимо
более сложные сценарии доставки да То
есть им еще автомашин открывает на самом
деле в первую очередь ролик
И если мы захотим какую-нибудь канарейку
или полноценный блюдо пойман очень
желательно попробовать компонент под
названием flager его особенность
заключается в том что он берет данные с
инвестконтроля или сервисной сетки с
мониторинга и управляет процессом или за
наших вложения
естественно
и поэтому он очень хорошо
а давайте дальше поговорим о том как бы
нам это все применить на практике
из чего начать Ну соответственно когда
мы хотим начать работу Мы естественно
берем пустой пластырем Флакс делаем так
называемые процедуру bootstrap при этом
у нас появляется три базовых манифеста
репозитории которая описывают саму флаг
под систему Он сам это вот требования
дальше мы что делаем мы логично начинаем
добавлять манифесты которые описывают
какие-то компоненты нашей системы
каких-то вложений и получается такая вот
я бы сказал
это все работает до того момента пока мы
добавляем сущности и проверяем что у нас
все хорошо работает но если мы попробуем
вот этот весь каталог применить единый
момент на какой-то пустой Пластов то
соответственно могут возникнуть проблемы
и поэтому вы в этот момент времени
задумываемся о том что как бы нам Но это
все упорядочить что нам с этим делать и
Флагман здесь помогают потому что мы
можем все компоненты разбить по
определенным подкаталогам описать это
отдельная Кастома из объекты То есть
например один сердечки отдельно уже
какие-то базовые компоненты структуры
Дальше
сами приложения которые этим всем
компонентам цепляются Их используют и в
таком случае у меня получается полностью
используемая конфигурация которую я могу
раскатывать как на различные
провода или просто взять новый класс
заполнить и получить за конечное время
свою способность положение
как это может выглядеть
что удобно не накладывает никаких
ограничений на то как мы хотим
упорядочивать нас вот этот управляющий
репозиторий это может быть как подход
один репозиторий на кластер или один
репозиторий на окружение или один
репозиторий на теннанта можем вообще все
инфраструктуру в одном репозитории
описывать просто разбив на подкаталоге
здесь все зависит от того какие у вас
есть входные требования Потому что если
вы например не дай Бог будете там
хранить какие-то секретные данные в
виде то или там во внутрь будет имидж
автомашин Да и вы будете из кластера
менять истории то логично наверное все
таки разнести
разные кластера на различные репозитории
Но с другой стороны
удобнее управлять когда все в одном
репетиторе лежит потому что в этом
случае можно использовать
каталоги с компонентами можно просто
переносить файлы из одного окружения в
другой здесь все зависит от того какой
вы хотите получить
также очень удобным инструментом
является очень долгое время считалось
нет панели она на самом деле есть Она
позволяет производить какие-то базовые
опции по администрированию то есть
делать со спенд на отдельные ресурсы
Когда у нас синхронизация выключается
например то нужно для каких-то ручных
изменений или аварийных работ видеть
полностью перечень всех ресурсов на
данном скриншоте видно просто у меня
часть ресурсов состояние Регги То есть
нормально применена часть из них выдала
ошибку То есть это может быть средством
какой-то первичной диагностики
первичного монитора Это не отменяет того
что есть очень хорошая интеграции
но инструмент удобный Я рекомендую его
тоже устанавливать и его смотреть также
Он позволяет удобно визуализировать
тебернета с объекты которые приносятся
конкретные ресурсами флага
релиз позволяет посмотреть зависимости
между объектами вот здесь на как раз на
диаграмме показано как я сделал
зависимость между различными
у меня в первую очередь
и потом уже вот эти вот конечные
которые можно назвать листовыми Я очень
рекомендую строить очень древовидную
структуру то есть наверное три уровня
иерархии это достаточно и больше не
стоит потому что вы будете путаться
время применения изменений будет
увеличиваться и будет не очень хорошо на
самом деле здесь стоит пользоваться
система вот для установки топ есть своя
утилита Я на скриншоте показал как можно
установить на самом деле она по большому
счету генерирует те же самые объекты
помощи которых она устанавливается
соответственно Давайте теперь поговорим
что мы сегодня узнаем мы узнали что есть
такой подход есть
факс Он позволяет
удобным способом описывать
конфигурацию губерната кластеров
тиражировать их и я думаю что инструмент
достаточно зрелый можно его
рекомендовать для применения вы
различных продакшн средах и частности в
средах разработки он реально экономит
время и позволяет более удобно
эффективно управлять
вот также я здесь решил поделиться
основными ресурсами которые имеются по
технологии по данному инструменту это
канал разработчиков где всегда можно
задать вопрос
им пользоваться там получить
консультации по каким-то багам респект
обязательно страница проекта там есть
проблема
не исключение но хорошо что ребята Их
быстро исправляют и Security тоже
выходит оперативно и хоть документация
на сайте и есть еще куча примеров
использования готовых которые можно
вытаскивать свои окружения и
адаптировать свои нужды
Вот на этом все я думаю что я готов
ответить на вопрос
Спасибо большое за доклад У меня вопрос
по мультитантами мастерам Какой у вас
опыт по масштабам Как это работает на
действительно больших кластерах сотни
команд условно
Я честно скажу что на сотни команд я не
проверял я проверял где-то примерно на
командах 10 здесь самый основной момент
заключается в том что флаг предоставляет
все необходимые примитивы для
организации такую схемы и выглядеть это
будет как некая иерархическая структура
нас будет
какие-то системные компоненты и при
помощи кастом из ресурсов мы можем
подключать
каждого из тэном По отдельности
предоставляя ему например отдельный
защита при этом будет обеспечиваться тем
что здесь нужно упомянуть что скорее
всего придется использовать
инструменты вроде Опа или киверна
которые позволят контролировать
параметры тех манифестов которые
доставляются или очень внимательно
смотреть на
ревью которые попадает эти репозитории
ребята пытаются сохранить если это все
сделать то это получается
достаточно безопасно и удобно
Я немножечко не про то я про то что
кажется что на сотнях объектов которые
контроллеры Flex смотрят Да это все
может распухнуть и контроллеры ну
проблемы нету то есть смотрите То есть
если вопрос в том сколько объектов флаг
сможет нормально переживать я бы сказал
где-то до тысяч
до 1000 точно дальше дальше надо
проводить нагрузочное тестирование
Понятно спасибо
Кучин Дмитрий Спасибо за доклад Вопрос
такой Yes правильно понимаю что при
изменении в гидрепозитории пройдет
каскадные изменения всех манифестов И
они автоматически будут диплоиться и
есть ли механизм
грубо говоря руками выкатить нужное
изменение Спасибо
две части Да действительно каскадные
изменения есть когда мы разбиваем нашу
инфраструктуру на вот эти вот
как там было на одном
случае когда мы изменяем сердечки
соответственно изменения
каскадно происходит во все остальные они
будут
Насчет второго что вы имеете в виду
Объясните пожалуйста
хочу грубо говоря у меня есть
я выкатываю
через Флакс хочу изменить версию
но при этом
хочу чтобы это изменилось не на всех
кластерах так как иерархическая история
А например на одном конкретном То есть
мне нужно будет в эту иерархию
подкидывать именно конкретную для этого
кластера изменений и таким образом
контролировать или все-таки есть
какие-то ручки через UI или еще
каким-либо образом
смотрите для того чтобы быть полностью в
рамках детокс подхода никаких ручных
изменений быть не может что то что вы
говорите Это вы хотите сделать
простомное конфигурации для каждого из
нас это можно достичь тем что мы когда
будем описывать
репозитории мы либо для каждого кластера
заведем например отдельный каталог либо
отдельные репозитории Они будут
ссылаться на общий репозитории там будут
каталоги с конкретными настройками для
каждого Вы можете определить версию
например Виктории метрикс
для каждого из косторов По отдельности
Это первый вариант второй вариант Вы
можете договориться внутри своей команды
что у вас будет условно говоря какой-то
большой конфигман который содержит
перечень версий компонентов И как я
показывал на слайде с вами Вы можете из
него вытаскивать
версию
поле значение ключа подставлять либо
он не накладывает никаких ограничений на
то как вы будете с ним работать здесь я
хотел бы подчеркнуть что он
предоставляет некий набор базовых
объектов Да как Вы будете использовать
это полностью
на вашей совести остается Как построить
Спасибо и наверное еще один вопрос Если
механизм получения дифа то есть опять же
если ты меняешь велью в каком-то
корневом чате хочется понять что
конкретно ты изменил если что-то
подобное
Ну во-первых есть субкомандова флаг сгиб
но здесь опять же в первую очередь Все
упирается в процесс Потому что если вы
захотите например управлять флаксом
только лишь Продакшен кластером вот у
вас есть один кластер и вы имплан
управляете вопрос Зачем так делать
потому что так удобно мы видим опять же
все конфигурацию в одном месте наличие
вот этого дополнительного инструмента не
создает но проблема возникают если мы
попробуем
это управляющего репетитория закормить
какие-то плохие манифест поэтому Что
нужно сделать перед тем как манифест
попадает управляющий территории мы
должны поверить идеально на каком-то
тестовом пластыре что у нас все хорошо
ничего не сломалось либо закрыться
проверками на уровне
pr-процесса что
манифест корректные и они ничего не
в первую очередь вопрос
Спасибо Добрый день спасибо спасибо
большое за доклад
подскажите пожалуйста вот допустим у
меня есть
репозиторий flags в нем достаточно
большая система и вот Раз уж мы сегодня
достаточно много времени уделили
безопасности Есть ли какой-то способ
перед установкой нового приложения перед
добавлением новых объектов о Flex
заранее их отрендерить отправить там на
анализ службу eBay или в Саске
Вот именно до применения
Ну смотрите как я уже сказал это вопрос
процесса Я лично рекомендую завести
тестовый пластырь на котором у вас все
изменения будут покатываться до того
момента как вы эти манифесты перенесете
в управляющую репозитории которые
отвечают за продакшн Пластов таким
образом
путем применения манифестов через фланц
на тестовый пластырь Вы можете получить
более-менее полную картину того что у
вас должно происходить и случае если
кластера очень большие
кластер на команду или кластер на 5 на
10 команд это подход зарекомендовал себя
и он абсолютно способный Вы можете более
того когда не только заниматься
проверками безопасности но еще и
какие-то смог проверки на само
предложение
Спасибо за доклад еще вопрос есть ли
утилиты для миграции с первого флакса на
второй
то есть репозитории для первого класса
все сильно поменялось хочется его
конвертировать в объекты
[музыка]
но смотрите есть мигрейшн гайд на сайте
flagsa самого Да они описывают Как
правильно произвести процесс миграции
готовых утилиту там из серии там взяли
барские там работали репозитории все
стало хорошо я не видел Вот и на самом
деле если есть возможность я скорее
сторонник того чтобы кластерам
относиться не как домашних животных А
как говорится скоту да то есть много
кластеров они нефемерные Да постоянно
создаются и случае если вы например
работаете в Облаке это никакой проблемы
нет представляет если конечно
пересоздать класс с нуля
подготовить все необходимые манифесты
запретить туда приложения радости
радостно дальше продолжать работать Я
понимаю ситуации бывают разные это не
всегда Возможно тогда остается
второй вопрос
насколько знаю во втором флагсе
выключили возможность
использовать плагины
как-то
обходили это
не было необходимость
Такой необходимости пока не было Но я
могу сказать то что сейчас
коллеги активно прорабатывают
возможность использования утилита Куле и
опять же есть пример использования в
интернете которые могут вот эту боль
отсутствие плагинов
немножко уменьшить
Спасибо Добрый день спасибо за
интересный доклад вопрос смотри
Судя по докладу я так фоном рассказывал
что есть какая-то мультитантная
структура Есть какой-то возможно
мультитрантный кластер нагруженный над
которым работает 11 здоровый флаг
который там кусочек командам
и
вот к предыдущему вопросу про количество
объектов которыми одновременно может
управлять Флакс при высоком объеме
мультитанатных команд на одном кубе и
высоком объеме компонентов насколько
оптимально флаг работает сервером не
придавливает ли он его Потому что если
смотреть на примерку верный там есть
интересные моменты где вместо того чтобы
делать Вот на объекты подписываться на
раз на секунд читайте переписывает
объекты чем задавливает на глухой сервер
если так такие проблемы со флаксом
смотрите я бы сказал бы так проблем не
выявлено но они очевидно могут
возникнуть на любом этапе Да вот по
разным причинам утки его написали версию
Всякое бывает жизни Да это программным
инженерия Все предусмотреть невозможно
но
что здесь можно сделать во-первых он
флаг достаточно написан нормально и я не
видел проблем связанных
в конце концов Если вы видите то что он
начинает создавать нагрузку нужно
конечно можно
но как бы таких дешевых кредитых решений
можно попросту уменьшить наоборот
увеличить интервал применение
сканирование объектов Таким образом у
вас улучшится количество запросов потому
что очевидно Вам наверное не нужно
выкатывать
контроллеры каждую минуту вам нормально
будет в час мониторятся Да сканируется
приехали какие-то изменения это уже на
самом деле большую проблем решает вот
если говорить о страх там не знаю на
5000 узлов Да у меня в практике такие
были не на 5 на 500 и
там тоже проблем с лаксом выявлено не
было явно и поэтому я бы сказал что
скорее проблем не должно быть но это все
нужно тестировать
Георг Спасибо у нас в онлайне вопрос Это
мы в аргустеди используем паттерн аппс
позволяет ли флаг сделать подобные
зависимости или что-то похожее
Ну принципе да Я показывал структуру
репозитория да то есть все у нас
начинается из чего у нас есть флаг
который сам себя контролирует сам себя
описывает
дальше соответственно мы добавляем этот
управляющий
ресурсы можем реализовать аналогичный
Без особых проблем
получает ливовидную структуру спасибо
спасибо и последний вопрос у нас в
онлайне но мне кажется на него ответил
это один управляющий Флакс для большого
количества кластеров это возможно
насколько насколько я знаю Недавно как
раз была статья про то как ребята взяли
Флакс 2 и как раз такой задачи чтобы
раньше разворачивали под кластер под
репозит под репозиторий каждая потом
развернули под кластеры типа сократили
40 процентов по Но это возможно Да Георг
именно в такой формулировке Наверное нет
Потому что флаг все-таки больше про
управление одним пластом
но у него есть возможности которые
позволяют например создавать
манифест
Я думаю
правление в конце концов можно
установить снаружи классно
и
я бы не стал поддерживать
Спасибо коллеги Спасибо всем за то что
послушали поддержим докладчика Георг
Спасибо
вам тоже большое спасибо за внимание
Weitere ähnliche Videos ansehen
2024 06 10 18 30 03
Как коробочные решения автоматизируют работу юристов за 2 недели
How to Run Google Ads for Amazon Products | External Traffic Masterclass for Amazon FBA
Новая нефть. Битва за будущее @posle_zavtra
ThinkRider X5-Neo Smart Cycle Trainer: Details // Ride Review
AMD's CEO Statement To CNBC Left The Whole World Speechless About Nvidia
5.0 / 5 (0 votes)