[Системное администрирование, IT-инфраструктура, DevOps] Что вам нужно знать, если вы поменяете nginx на envoy: впечатления спустя два года
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Мы используем envoy как front edge proxy, который перенаправляет входящий трафик в несколько кластеров kubernetes (для новых сервисов) и в бэкенды legacy-архитектуры исторического наследия. Т.е. там сочетаются функции как обычного балансировщика и ssl termination point, так и api gateway.
До envoy у нас там был nginx, как и у многих. Классный софт, мне нравится. Вся история с envoy началась в тот момент, когда начались микросервисы в большом количестве и даже шаблоны ansible не спасали от увеличивающегося времени на управление nginx-конфигом. Долго выкатывалось, плюс админы приунывали от однообразных заявок вида «заведите мне домен для нового сервиса». Явно была нужна более лучшая™ автоматизация. В идеале, чтобы тот, кому нужно что-то завести, мог сам это сделать и желательно в том же месте, где настраивал прочие параметры своего сервиса. Вдобавок хотелось побольше прозрачности в том, что происходит внутри front proxy и на отрезке между ним и апстримами, и больше нативных возможностей для балансировки (переповторы запросов разных типов, исключение нездоровых хостов по определённым условиям, хелсчеки). И привлекла edge-технология, конечно же.
Long story short, вот перевод статьи о переходе Dropbox на envoy, там много деталей про его сравнение с nginx. Я же расскажу больше про личные впечатления от результатов перехода.
Самый главный и очевидный факт для любого, кто сталкивался с использованием масштабируемого ПО: будьте готовы за него заплатить. Повышенной сложностью сетапа (data plane + control plane), а если есть апстримы не только в kubernetes, то, возможно, даже написанием своего control plane. Также в случае конкретно с envoy — за относительную молодость софта и отсюда — отсутствием некоторых, обычных для nginx, фич + повышенной частотой обновлений, если эти фичи в них добавляются. Например, может оказаться, что в штатных опциях нет какого-нибудь умолчального для nginx объединения слешей в :path, отбрасывания порта из заголовка Host или, прости господи, rewrite по регекспу. На сегодня всё из этого списка уже добавили, но наверняка найдёте что-то ещё.
Положительные вещи
Ужасная документация! А положительное здесь то, что команда envoy в конце прошлого года наконец-то наняла технического писателя и всё стало значительно дружелюбнее. По крайней мере, больше не нужно изучать путь обработки запроса по исходникам и находить описание работы некоторых опций исключительно в ответах в твоём issue. А для нахождения самих опций — быть мастером гугления 80-го уровня. Теперь многое из этого в прошлом, хотя авторы всё ещё не утруждают себя отметкой, в какой версии envoy появилась та или иная опция, или ссылками на issue в release notes, но хотя бы начали выделять список ломающих изменений в релизах в выделенную секцию, видно, что есть прогресс.
Расширенная телеметрия
Здесь все надежды оправдались, теперь наш grafana-дашборд по envoy убивает браузеры всех неподготовленных количеством графиков. А если серьёзно, то теперь можно удобно следить за тем, что происходит с трафиком на всех этапах его прохождения, особенно хорошо это помогает в увлекательных детективных историях — расследованиях после происшествий. И, конечно же, определение аномалий.
Аномалия: «Привет». Фрагмент из того самого envoy grafana-дашборда.
Про control plane
Ну и самое главное, ради чего всё затевалось, — решили задачу автоматического управления роутами. Два слова про подход, если кто не в теме: control plane работает контроллером данных, управляет их хранением и создаёт конфиг, который потом отдаёт в envoy (stateless data plane).
Если в качестве бэкенда у вас только один kubernetes, то можно брать готовый control plane типа ambassador. Но нам нужно было управлять и старой инфрой тоже, плюс кластеров было несколько. Так что пришлось взять одну из предлагаемых проектом envoy реализаций data plane api и навернуть все нужные нам особенности, связав эту часть инфраструктуры с автоматикой в kubernetes, но это уже тема отдельной интересной истории.
Впечатления от процесса перехода на envoy — «почему-то не было особых проблем, очень подозрительно».
Вкратце, с чего начать и к чему быть сразу готовым. После медитации над документацией envoy и принятием тщетности сущего берём два виртуальных хоста со старого front proxy (самый простой и типичный, и самый развесистый), заводим их в envoy, разбираясь в опциях по ходу дела.
Здесь главное иметь в виду, что подходы к написанию конфигов между nginx и envoy очень различаются, т.е. надо быть готовым к крутым поворотам вида: вместо двух простых записей allow/deny пишем 26 строчек дерева RBAC-правил. В общем, принять, что немного взрывающаяся голова здесь — это нормально, так как конфиг envoy сделан c приоритетом на удобство автоматизации, а не на human readability.
Возможно, придётся составить шпаргалку маппинга опций и убедиться, что они действительно делают то, что вы думаете. Так мы однажды наступили на то, что механизм объединения слешей в URL (даже тогда, когда он уже был добавлен в envoy) работает по-разному: в nginx он не изменял :path, который отправлялся в upstream, а в envoy происходила полноценная перезапись, и всё бы ничего, но при этой перезаписи вылезал баг, который менял :path совсем на дичь, ну в общем, после нашего issue это тоже починили, но будьте осторожны.
Кстати, об issues — не могу не сказать про ещё одно положительное впечатление.
Доброжелательное сообщество и разработчики
Так как envoy — CNCF-hosted open source, то можно традиционно просто прийти в GitHub проекта и предложить своё улучшение или задать вопрос. Issues дикое количество, рук у разработчиков явно не хватает, но при этом самое плохое, что может случиться с вашим вопросом, — его проигнорируют. Хотя чаще всего хоть что-то, но отвечают, даже если это что-то краткое в духе «извини, это делать не планируем». Никакой токсичности, даже если вопросы от новичков, очень доброжелательная атмосфера.
Атмосферные топики, особенно corgis. Скрин публичного репозитория envoy на github.com
Ну и как обычно — pull requests are welcome. В них помогают даже тем, кто не особо шарит в C++. Также есть ряд issues, помеченных тегом beginner, на случай, если кто-то хочет внести свой вклад и не знает, с чего начать.
Кроме GitHub есть ещё email-рассылки и slack, но в последнем чаще каша. :)
Из мероприятий проводят EnvoyCon, который сейчас, правда, онлайн, но всё равно рекомендую.
Итог
В общем, вам не нужен envoy только потому, что он модный-молодёжный, «все переходят» и у фаундера забавная причёска. Оставайтесь на чём были, пока не прижмёт. Если у вас стартап или просто маленький проект — однозначно лучше оставить nginx, потому что он простой и милый. Там главное запустить.
Если много сервисов, много разработчиков, есть kubernetes и не смущают все трейдоффы по статье выше — можно задуматься и попробовать.
Удачи и, может быть, до встречи на EnvoyCon!
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование, MySQL, PostgreSQL, Администрирование баз данных] Углубленный мониторинг баз данных с помощью DBmarlin – вебинар
- [Информационная безопасность, Системное администрирование, Программирование, API] Подтверждение номеров телефона без SMS
- [Системное администрирование, Виртуализация, Восстановление данных, Резервное копирование] Обзор Veeam Backup & Replication v11
- [Тестирование IT-систем, Системное администрирование, DevOps] Хаос на практике: зачем ломать production?
- [Системное администрирование, IT-инфраструктура, Карьера в IT-индустрии, DevOps] Свидетели DevOps: мифы и байки про девопсов и тех, кто их нанимает
- [IT-инфраструктура, Исследования и прогнозы в IT, Карьера в IT-индустрии, AR и VR] Кому давно пора обучиться IT: пять сфер, где не хватает специалистов
- [IT-инфраструктура, Amazon Web Services, Учебный процесс в IT, Облачные сервисы] Авторизованные курсы AWS: за или против
- [Высокая производительность, IT-инфраструктура, Сетевые технологии, Сетевое оборудование] В МТИ соединили чипы с помощью кабеля толщиной в человеческий волос
- [Информационная безопасность, Системное администрирование, Сетевые технологии, Сетевое оборудование] Fortinet Single Sign-On. Описание технологии
- [Виртуализация, DevOps, Облачные сервисы, Kubernetes] Вебинар «Ошибки PRO-уровня при внедрении Kubernetes»
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_itinfrastruktura (IT-инфраструктура), #_devops, #_envoy, #_nginx, #_masshtabiruemost (масштабируемость), #_avtomatizatsija (автоматизация), #_blog_kompanii_tutu.ru (
Блог компании Туту.ру
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_itinfrastruktura (
IT-инфраструктура
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:17
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Мы используем envoy как front edge proxy, который перенаправляет входящий трафик в несколько кластеров kubernetes (для новых сервисов) и в бэкенды legacy-архитектуры исторического наследия. Т.е. там сочетаются функции как обычного балансировщика и ssl termination point, так и api gateway. До envoy у нас там был nginx, как и у многих. Классный софт, мне нравится. Вся история с envoy началась в тот момент, когда начались микросервисы в большом количестве и даже шаблоны ansible не спасали от увеличивающегося времени на управление nginx-конфигом. Долго выкатывалось, плюс админы приунывали от однообразных заявок вида «заведите мне домен для нового сервиса». Явно была нужна более лучшая™ автоматизация. В идеале, чтобы тот, кому нужно что-то завести, мог сам это сделать и желательно в том же месте, где настраивал прочие параметры своего сервиса. Вдобавок хотелось побольше прозрачности в том, что происходит внутри front proxy и на отрезке между ним и апстримами, и больше нативных возможностей для балансировки (переповторы запросов разных типов, исключение нездоровых хостов по определённым условиям, хелсчеки). И привлекла edge-технология, конечно же. Long story short, вот перевод статьи о переходе Dropbox на envoy, там много деталей про его сравнение с nginx. Я же расскажу больше про личные впечатления от результатов перехода. Самый главный и очевидный факт для любого, кто сталкивался с использованием масштабируемого ПО: будьте готовы за него заплатить. Повышенной сложностью сетапа (data plane + control plane), а если есть апстримы не только в kubernetes, то, возможно, даже написанием своего control plane. Также в случае конкретно с envoy — за относительную молодость софта и отсюда — отсутствием некоторых, обычных для nginx, фич + повышенной частотой обновлений, если эти фичи в них добавляются. Например, может оказаться, что в штатных опциях нет какого-нибудь умолчального для nginx объединения слешей в :path, отбрасывания порта из заголовка Host или, прости господи, rewrite по регекспу. На сегодня всё из этого списка уже добавили, но наверняка найдёте что-то ещё. Положительные вещи Ужасная документация! А положительное здесь то, что команда envoy в конце прошлого года наконец-то наняла технического писателя и всё стало значительно дружелюбнее. По крайней мере, больше не нужно изучать путь обработки запроса по исходникам и находить описание работы некоторых опций исключительно в ответах в твоём issue. А для нахождения самих опций — быть мастером гугления 80-го уровня. Теперь многое из этого в прошлом, хотя авторы всё ещё не утруждают себя отметкой, в какой версии envoy появилась та или иная опция, или ссылками на issue в release notes, но хотя бы начали выделять список ломающих изменений в релизах в выделенную секцию, видно, что есть прогресс. Расширенная телеметрия Здесь все надежды оправдались, теперь наш grafana-дашборд по envoy убивает браузеры всех неподготовленных количеством графиков. А если серьёзно, то теперь можно удобно следить за тем, что происходит с трафиком на всех этапах его прохождения, особенно хорошо это помогает в увлекательных детективных историях — расследованиях после происшествий. И, конечно же, определение аномалий.  Аномалия: «Привет». Фрагмент из того самого envoy grafana-дашборда. Про control plane Ну и самое главное, ради чего всё затевалось, — решили задачу автоматического управления роутами. Два слова про подход, если кто не в теме: control plane работает контроллером данных, управляет их хранением и создаёт конфиг, который потом отдаёт в envoy (stateless data plane). Если в качестве бэкенда у вас только один kubernetes, то можно брать готовый control plane типа ambassador. Но нам нужно было управлять и старой инфрой тоже, плюс кластеров было несколько. Так что пришлось взять одну из предлагаемых проектом envoy реализаций data plane api и навернуть все нужные нам особенности, связав эту часть инфраструктуры с автоматикой в kubernetes, но это уже тема отдельной интересной истории. Впечатления от процесса перехода на envoy — «почему-то не было особых проблем, очень подозрительно». Вкратце, с чего начать и к чему быть сразу готовым. После медитации над документацией envoy и принятием тщетности сущего берём два виртуальных хоста со старого front proxy (самый простой и типичный, и самый развесистый), заводим их в envoy, разбираясь в опциях по ходу дела. Здесь главное иметь в виду, что подходы к написанию конфигов между nginx и envoy очень различаются, т.е. надо быть готовым к крутым поворотам вида: вместо двух простых записей allow/deny пишем 26 строчек дерева RBAC-правил. В общем, принять, что немного взрывающаяся голова здесь — это нормально, так как конфиг envoy сделан c приоритетом на удобство автоматизации, а не на human readability. Возможно, придётся составить шпаргалку маппинга опций и убедиться, что они действительно делают то, что вы думаете. Так мы однажды наступили на то, что механизм объединения слешей в URL (даже тогда, когда он уже был добавлен в envoy) работает по-разному: в nginx он не изменял :path, который отправлялся в upstream, а в envoy происходила полноценная перезапись, и всё бы ничего, но при этой перезаписи вылезал баг, который менял :path совсем на дичь, ну в общем, после нашего issue это тоже починили, но будьте осторожны. Кстати, об issues — не могу не сказать про ещё одно положительное впечатление. Доброжелательное сообщество и разработчики Так как envoy — CNCF-hosted open source, то можно традиционно просто прийти в GitHub проекта и предложить своё улучшение или задать вопрос. Issues дикое количество, рук у разработчиков явно не хватает, но при этом самое плохое, что может случиться с вашим вопросом, — его проигнорируют. Хотя чаще всего хоть что-то, но отвечают, даже если это что-то краткое в духе «извини, это делать не планируем». Никакой токсичности, даже если вопросы от новичков, очень доброжелательная атмосфера.  Атмосферные топики, особенно corgis. Скрин публичного репозитория envoy на github.com Ну и как обычно — pull requests are welcome. В них помогают даже тем, кто не особо шарит в C++. Также есть ряд issues, помеченных тегом beginner, на случай, если кто-то хочет внести свой вклад и не знает, с чего начать. Кроме GitHub есть ещё email-рассылки и slack, но в последнем чаще каша. :) Из мероприятий проводят EnvoyCon, который сейчас, правда, онлайн, но всё равно рекомендую. Итог В общем, вам не нужен envoy только потому, что он модный-молодёжный, «все переходят» и у фаундера забавная причёска. Оставайтесь на чём были, пока не прижмёт. Если у вас стартап или просто маленький проект — однозначно лучше оставить nginx, потому что он простой и милый. Там главное запустить. Если много сервисов, много разработчиков, есть kubernetes и не смущают все трейдоффы по статье выше — можно задуматься и попробовать. Удачи и, может быть, до встречи на EnvoyCon! =========== Источник: habr.com =========== Похожие новости:
Блог компании Туту.ру ), #_sistemnoe_administrirovanie ( Системное администрирование ), #_itinfrastruktura ( IT-инфраструктура ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:17
Часовой пояс: UTC + 5