Comments 28
Не удается получить доступ к сайту
Превышено время ожидания ответа от сайта www.envoyproxy.io.
Одно из главных достоинств NGINX же это быстрая отдача статического контента… Переходить рановато явно.
Текущий план решить эту проблему с Envoy — кеширование + проксирование в S3 (или любой другой object storage). Оно проще:
- с точки зрения поддержки. Не нужно поддерживать stateful сервис: серверов раздающих статику обычно несколько так что нужно мониторить что файлы на всех серверах есть и хеши совпадают.
- с точки зрения разработки. У программистов появляется API для работы со статикой (S3 API или подобный), вместо сложной интеграции с системой деплоя для пуша новой версии статики по всем серверам.
У программистов появляется API для работы со статикой (S3 API или подобный), вместо сложной интеграции с системой деплоя для пуша новой версии статики по всем серверам.
И программистам теперь надо разрабатывать сложные системы деплоя новой версии статики на S3 или подобные, причём всё равно нужен механизм инвалидации кэша, только теперь распределённого.
Тут невзирая на средний перевод, неплохо раскрыт вопрос "как?"
Но, я вообще не понимаю пока "зачем?"
Стало интересно, что же за "наблюдаемость на уровне проводов" такая. Полез в оригинал — а там этого и нет совсем...
Ну и fastcgi у envoy даже не пахнет. Кто-то использует nginx как чистый прокси?
Проблема ведь не в fastcgi как таковом. Кстати, nikolau
Банально — есть запрос на высокопроизводительный http сервер, который будет обеспечивать склейку всех наших сервисов. По определенным причинам nginx уже не отвечает этой задаче — в нем большинство модулей с нормальной балансировкой только в Nginx Plus, а не все готовы собирать свой пакет из открытых модулей. Могу сослаться на чудесный доклад Романа Сивко — https://habr.com/ru/company/oleg-bunin/blog/423085/
Плюс в traefik/envoy мы автоматически получаем возможность отгружать все запросы в структурированном виде во внешнюю систему типа jaeger для обеспечения мониторинга, прозрачности взаимодействия (микро)сервисов и пр. nginx тоже это все может, но сколько его пилить для этого придется?
Рассматривайте envoy именно как ядро для высокопроизводительной service mesh и все встает на свои места.
Одно из главных достоинств NGINX же это быстрая отдача статического контента… Переходить рановато явно.
Варианты — делайте свой (микро)сервис со статикой, пускай и на nginx, либо (лучше) — отгружайте статику в нечто типа s3 (а в любой большой инфре подобное хранилище будет) и радуйтесь жизни...
Кто-то использует nginx как чистый прокси?
а почему нет? и как чистый прокси тоже использую
Конфигурация в таком формате совершенно нечитаемая. Или мне одному так кажется?
Эм. Это дело привычки. Конфигурация nginx тоже весьма своеобразная. Просто мы с ней живёт уже десяток лет и… Привыкли.
Хотя если подумать — она ничуть не лучше.
Есть ли место для envoy в кластере k8s, где с одной стороны стоит ingress nginx, разрулиаающий HTTP трафик по подам, где либо чистый nginx со статикой, либо как гейт к fastcgi/wsgi контейнерам в том же поле сдругой?
Envoy претендует на то, чтобы nginx оттуда выкинуть. Вообще. И оставить разве что для каких-то конкретных задач (вроде fastcgi), но есть хорошая степень вероятности, что этот ваш fastcgi в куб вообще тащить не надо — легаси, однако, которое так написано, что работать нормально не будет. И проще будет его переписать на python/golang/java в виде cloud native приложения.
То есть претендент на роль ingres и раздачу статики?
Переписал недавно один сервис с PHP на Golang. Каких-то особых преимуществ не заметил ни в плане взаимодействия со средой, ни в плане лёгкости написания и поддержки кода (тут у меня скорее негативное впечатление). На высоких нагрузках наверняка что-то вылезет, но с нашими ну вообще никакой разницы кроме синтаксической, кроме того, что запрос и ответ представлены явно в net/http, а не суперглобально. Но это и в PHP давно нормальная практика напрямую с суперглобалами не работать.
Ingres == Istio Gateway, ога
раздачу статики?
Еще раз — статику лучше вообще вынести. Чего ей в кластере делать-то? Ну, ок — поднимите С3, сделайте поды с nginx со статикой и скейлите их… Но попахивает...
Каких-то особых преимуществ не заметил ни в плане взаимодействия со средой, ни в плане лёгкости написания и поддержки кода (тут у меня скорее негативное впечатление)
А как насчет стоимости поддержки в будущем? Всяких дополнительных фишек (типа трейсингов и пр.)? И вообще количества прогеров под конкретный язык?
С3 нам не подходит, и вообще "всё своё ношу с собой" — всё в кластере. Может спорное решение, но не без плюсов.
А как насчет стоимости поддержки в будущем? Всяких дополнительных фишек (типа трейсингов и пр.)? И вообще количества прогеров под конкретный язык?
В Go есть трейсинги? А я вот ручками делал, вычитывал из запроса, заносил в контекст и пробрасывал везде. Ну и PHP дешевле Go однозначно. Даже если считать по моим человеко-часам :)
То есть претендент на роль ingres и раздачу статики?
На роль ингресс контроллера, да. Но не на раздачу статики.
Он не ориентирован на раздачу контента, только проксирование.
Если это ответ на статью… то он слабый. Но спасибо за уточнение )
«А как же статика?», «а куда прикрутить fast-cgi» и т.п
У Envoy есть свои фишки, такие как динамическое обновление конфигов, переподключения, Circuit Breaking и пр.
более подробно — www.envoyproxy.io/learn
на envoy надо обратить внимание, когда нужен «более умный» прокси, чем из коробки nginx. Со стакой и пр. web он не работает
Миграция с Nginx на Envoy Proxy