Когда я писал статью про HAProxy, у меня возникла идея сравнить его с другим популярным proxy-сервером, например с Envoy. Но тогда мне показалось, что простое сравнение в виде таблицы или пары абзацев будет неинформативным — и я решил сделать полноценный разбор в отдельной статье. Если вам интересно — добро пожаловать! Здесь рассмотрены не все возможности каждого решения, но ключевые — те, которые действительно важны на практике.

Сегодня я разберу три популярных прокси, сравню их и расскажу: что, где и когда лучше применять. Под «популярными» я имею в виду те, с которыми работал сам и изучил их устройство «под капотом». Прокси существует гораздо больше, но о других говорить не буду — либо не копал глубоко, либо знаю слишком мало, чтобы включать их в разбор. Отдельно отмечу важность документации: если она запутана или неполна, приходится гадать, что и где настраивать, а это быстро отбивает желание работать с инструментом.

HAProxy 3.3, NGINX 1.29 и Envoy 1.35 — три open source-прокси с разной архитектурой и моделью управления. Enterprise-версии рассматривать не буду — капитализм делает свое дело: серьёзных отличий почти нет, а вот в OSS-вариантах есть что сравнить — в ряде моментов конкуренция пошла на пользу.

Привет, Habr. Сегодня снова поговорим о прокси — это, пожалуй, моя любимая тема, и я рад вернуться к ней. На этот раз речь пойдёт об универсальном солдате в мире балансировки — HAProxy. Этот инструмент уже много лет остаётся стандартом в высоконагруженных системах, но за последние релизы он стал ещё мощнее и гибче.

Напомню, HAProxy (High Availability Proxy) — это высокопроизводительный, отказоустойчивый прокси-сервер и балансировщик нагрузки, способный работать как с HTTP(S), так и с TCP-трафиком. Это делает его идеальным решением не только для веб-приложений, но и для баз данных, почтовых систем, брокеров сообщений и других сервисов.

В этой статье я разберу последнюю доступную версию — 3.2.3, расскажу о ключевых изменениях, особенностях конфигурации и поделюсь приёмами, которые помогают выжать из HAProxy максимум.

Итак, чем же хорош HAProxy как балансировщик и что интересного появилось в новых версиях?

Привет, Хабр. Продолжаем изучение Istio и сегодня рассмотрим некоторые интересные особенности, которые в дальнейшем могут облегчить сопровождение и развитие сервисной mesh-инфраструктуры в Kubernetes. С ростом распределённых систем и микросервисных архитектур в Kubernetes всё чаще встаёт вопрос о построении надёжной, масштабируемой и безопасной сетевой инфраструктуры. Когда одного кластера становится недостаточно, возникает потребность объединить несколько инсталляций в единую mesh-сеть. Здесь и появляется Istio, как кандидат на реализацию мультикластерной архитектуры.

Современные распределённые системы требуют надёжных, безопасных и масштабируемых способов управления сетевым взаимодействием между сервисами. Технологии Service Mesh, такие как Istio, предоставляют набор инструментов для решения этих задач. Недавно в экосистеме Istio появилась новая архитектура — Ambient Mesh, предлагающая альтернативный подход к реализации сетевых функций. В данной статье мы рассмотрим, чем отличаются классический Service Mesh и Ambient Mesh в контексте Istio, а также их преимущества и недостатки.

DevOps — это стремительно развивающаяся область, объединяющая разработчиков и специалистов по эксплуатации для автоматизации, ускорения и улучшения процессов доставки программного обеспечения. DevOps-инженеры играют ключевую роль в современном ИТ-ландшафте, помогая компаниям быстро адаптироваться к меняющимся условиям и требованиям рынка. Их задачи охватывают широкий спектр областей: автоматизация инфраструктуры, управление жизненным циклом приложений, настройка мониторинга и обеспечение надёжности систем.

Основная концепция DevOps заключается в устранении барьеров между командами разработки (Dev) и эксплуатации (Ops), что позволяет внедрять изменения быстрее и с меньшими рисками. Это достигается за счёт использования инструментов и подходов, таких как CI/CD (непрерывная интеграция и доставка), Infrastructure as Code (IaC, инфраструктура как код), контейнеризация и мониторинг. Однако DevOps — это не только технологии, но и культура взаимодействия, прозрачности и ответственности в командах.

Привет, Хабр! Давайте продолжим изучать возможности Envoy, но уже в контексте динамической конфигурации. В первой статье мы рассматривали настройку статической конфигурации, однако она имеет свои особенности. Статическая конфигурация подходит, когда ваши upstream (серверы, к которым Envoy отправляет запросы) редко изменяются. Envoy работает как прокси, и каждый запрос проходит через него. Чтобы правильно обработать запрос, Envoy должен иметь актуальную информацию о бэкенд-серверах, такую как их IP-адреса и порты. Когда информация о бэкенде меняется, необходимо обновить конфигурацию в статическом файле и перезапустить Envoy, что не всегда удобно.

Привет, Хабр, это моя первая статья. Меня зовут Константин, я системный инженер в компании ГНИВЦ. Здесь я хотел бы вам рассказать, что такое Envoy и как с его помощью можно упростить жизнь разработчикам и повысить надёжность взаимодействия микросервисов, минуя инфраструктуру для кого-то страшного и непонятного Kubernetes, а используя простой и старомодный Docker. Также эта статья поможет познакомиться с Envoy поближе и узнать, как он шагает в ногу с таким проектом как Istio.