В любом проекте возникает необходимость ограничения доступа к определенным частям приложения. Веб‑сервер Angie предоставляет разнообразные возможности решения этой задачи с помощью стандартных (встроенных) и сторонних модулей, которые мы будем разбирать в этой статье.

Ранее мы рассматривали различные варианты балансировки нагрузки (HTTP, L4) с помощью Angie. Однако мы обходили стороной вопрос отказоустойчивости. Балансировщик становится единой точкой отказа для системы, и эту проблему необходимо решать. Одним из решений является использование протокола VRRP для организации отказоустойчивого кластера — его мы и разберём в этой статье.

Контроль основных метрик веб‑сервера или балансировщика — основа надежной работы системы. Ранее мы разбирали работу с мониторингом через API и Angie Console Light, но это не единственный вариант, доступный в Angie. Использование встроенного экспортера Prometheus и визуализация через Grafana дают принципиально другие возможности. Итак, в этой статье мы запустим полноценную систему мониторинга Angie.

Современная инфраструктура приложений динамична и требует гибкости от конфигурации ключевых элементов. В этой статье мы разберём все варианты реализации динамических групп серверов (upstream) в Angie. С помощью этих методов вы сможете изменять состав и статус серверов без вмешательства в конфигурацию Angie. 

Один из самых простых способов ускорить работу сайтов и снизить нагрузку на инфраструктуру — корректно использовать клиентское кэширование. Механизм одновременно и простой, и сложный. В этой статье посмотрим, как можно управлять клиентским кэшированием в веб‑сервере Angie.

Возможности Angie в качестве веб‑сервера и обратного прокси довольно известны. Но кроме работы на уровне L7 (HTTP), мы можем применять его на L4 (TCP и UDP) в качестве балансировщика и прокси‑сервера. Именно об этой функциональности мы и поговорим в сегодняшней статье.

Не секрет, что штатные возможности мониторинга Nginx довольно скромны. Решалась эта задача различными способами: либо парсингом логов, либо сторонними модулями. При создании Angie эту проблему решили радикально и сразу несколькими способами. Начнём с исторического модуля stub_status.

Балансировка нагрузки в веб‑сервисах решает сразу две задачи: масштабирование и отказоустойчивость. В этой статье поговорим о возможностях балансировки нагрузки для HTTP(S) протокола в Angie.

Теоретическая основа, описание алгоритмов уже описана разработчиком Angie, поэтому рекомендую обращаться к статьям с обзором балансировки и алгоритмам балансировки в Angie. Здесь же разберём практическую сторону настройки балансировки.

Исторически роль обратного прокси (reverse proxy) можно назвать первоначальным предназначением для Nginx, а значит и для Angie. В этой статье разберёмся, почему он обратный, какие тонкости настройки проксирования нужно учитывать при настройке.

Сегодня использование HTTPS стало практически обязательным для большинства веб‑приложений. Angie позволяет эффективно обрабатывать HTTPS‑трафик, обеспечивая при этом высокий уровень безопасности. В новых протоколах HTTP/2 и HTTP/3 использование защищённого соединения обязательно. Однако, как обычно, есть много деталей в конфигурации, которые мы последовательно разберём в этой статье.

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

Сжатие текстовых ресурсов — это базовая мера оптимизации скорости загрузки веб‑приложений. Действительно, текста в вебе много: HTML, CSS, JS, JSON, SVG и не только. Казалось бы, тема простая: включили gzip, добавили типы контента для сжатия и всё готово. Однако, как всегда самое интересное в деталях. Разберёмся во всём подробно.

Angie предоставляет широкие возможности по перенаправлению запросов, которые востребованы в большинстве веб‑приложений. В этой статье мы разберём все основные методы перенаправлений: от простых до сложных. Начнём с общего принципа обработки директив в модуле rewrite.

В этой статье погрузимся в основы конфигурации веб‑сервера Angie — директиву location. Она используется во всех конфигурациях при работе с HTTP‑модулем и отвечает за разделение настроек обработки запросов по URL. В том числе, с помощью location происходит разделение запросов на статические и динамические. Начнём с последнего: разберёмся, что такое динамические и статические запросы.

Итак, вы решили использовать Angie как замену Nginx. С чего начать процесс? Какие аспекты нужно учитывать при переходе? Разберёмся со всем по порядку.

Напомню, что Angie является форком Nginx. Это значительно упрощает процесс переезда с Nginx на Angie, так как Angie поддерживает все возможности и директивы конфигурации, что и Nginx. Обратный переход с Angie на Nginx может быть уже не таким простым, если мы начинаем использовать уникальные возможности Angie (например, возможности проксирования или балансировки).

Начнём с подготовки системы к миграции.

В этой статье разберём базовые действия для установки веб‑сервера Angie в различные дистрибутивы Linux в виде пакетов или docker‑контейнеров.

Для установки Nginx не требуется подробной инструкции по установке, потому что пакеты как правило включены в состав дистрибутива. Установка обычно будет заключаться в выполнении одной из команд:

Это первая из статей, посвященных веб-серверу Angie. Мысль создать цикл статей возникла в процессе разработки курса по администрированию Nginx и Angie. Приходилось сталкиваться с темами, которые довольно слабо описаны в открытых источниках, либо не описаны вообще. В планах описать типичные области его использования с реальными примерами доступным языком. Так как большинство решений и конфигов будет совместимо с Nginx, надеюсь цикл будет полезен сообществу.