Angie: российский форк nginx, за полтора года занявший своё место в проде

Когда в 2022 году ключевые разработчики nginx покинули F5, чтобы создать Web Server LLC в Москве, признаюсь честно, я, Евгений Семёнов, директор ITFresh, был настроен скептически. Знаете, форки, как правило, долго не живут, чаще всего «умирают» буквально за полгода. Но вот наступила весна 2024-го, и картинка изменилась драматически. Angie не просто так попал в Реестр отечественного ПО. Он уже прошёл через множество серьёзных обновлений и отлично показал себя у трёх наших клиентов, которые перешли с оригинального nginx. А сегодня? Мы активно внедрили Angie на своих площадках: у нас целых 12 продакшн-сайтов работают на этом решении. Хотите узнать, какой опыт мы получили, что это даёт на практике и где ждать сюрпризов?

Кто и зачем сделал Angie

Форк основан в 2022 году командой, которая 15 лет вела оригинальный nginx. Старший разработчик Валентин Бартенев, Руслан Ермилов, автор nginx.com — все ушли из F5 и собрали в Москве компанию Web Server. Цель — продолжать развитие веб-сервера с упором на корпоративные требования и независимость от санкционных рисков. Код лицензирован BSD 2-Clause, открыт в GitLab (github.com/webserver-llc/angie), разработка идёт на русском и английском.

Что улучшили относительно nginx

• Динамический балансировщик — upstream можно менять без reload через API, в Community-версии есть API readonly, в Pro — writable.
• Prometheus-метрики из коробки — директива prometheus_exporter, не надо ставить sidecar.
• Расширенный ACME-клиент — Let's Encrypt интегрирован в Pro-версию на уровне ядра, автоматическое обновление сертификатов.
• Улучшенный HTTP/3 — QUIC собран стабильнее, меньше падений под нагрузкой.
• Модули HAproxy PROXY v2 — для прозрачной передачи реальных IP за L4-балансировщиками.
• Поддержка MQTT — балансировка IoT-трафика нативно.
• NTLM passthrough в stream — корпоративные сценарии с ADFS работают без костылей.

Community vs Pro — что выбрать

Для рядового коммерческого сайта Community-версия Angie не окажется избыточной, поверьте. А вот Pro-версию мы используем уже для более серьёзных проектов: например, для госконтрактов или очень крупных интернет-магазинов. Там критично важна быстрая ротация upstream и наличие WAF.

Установка на Debian 12 и AlmaLinux 9

# Debian / Ubuntu
curl -o /etc/apt/keyrings/angie-signing.gpg \
  https://angie.software/keys/angie-signing.gpg

echo "deb [signed-by=/etc/apt/keyrings/angie-signing.gpg] \
  https://download.angie.software/angie/debian/ bookworm main" \
  > /etc/apt/sources.list.d/angie.list

apt update
apt install -y angie
systemctl enable --now angie

# AlmaLinux / Rocky 9
cat > /etc/yum.repos.d/angie.repo << 'EOF'
[angie]
name=Angie repository
baseurl=https://download.angie.software/angie/almalinux/9/$basearch/
gpgcheck=1
gpgkey=https://angie.software/keys/angie-signing.gpg
enabled=1
EOF

dnf install -y angie
systemctl enable --now angie

Миграция конфигов с nginx

С этим никаких проблем: Angie полностью совместим с nginx на уровне конфигураций. Мы за всё время не сталкивались ни с одним случаем, чтобы конфиг от nginx не запустился на Angie. Сама миграция — дело быстрое: стандартная процедура занимает всего 20-30 минут на один сервер.

# 1) Бэкап конфига действующего nginx
nginx -T > /root/nginx-current.conf
tar czf /root/nginx-config-$(date +%F).tgz /etc/nginx /var/log/nginx

# 2) Остановка nginx
systemctl stop nginx
systemctl disable nginx

# 3) Установка Angie
apt install -y angie

# 4) Копируем конфиги
cp -a /etc/nginx/* /etc/angie/
chown -R angie:angie /etc/angie

# 5) Правим пути в конфиге, если есть nginx-specific
sed -i 's|/var/log/nginx|/var/log/angie|g' /etc/angie/nginx.conf
sed -i 's|/var/run/nginx.pid|/var/run/angie.pid|g' /etc/angie/nginx.conf

# 6) Проверка
angie -t
systemctl start angie
systemctl status angie

Prometheus-метрики

Что для меня стало одним из самых весомых аргументов в пользу Angie? Безусловно, это встроенный экспортёр Prometheus. Помните, как с nginx нужно было возиться? Ставить отдельный контейнер nginx-prometheus-exporter, потом ещё вытягивать данные через stub_status... А теперь? В Angie это вопрос буквально двух строчек в конфиге.

http {
    status_zone main;

    server {
        listen 127.0.0.1:9090;
        location /p8s {
            prometheus all;
            access_log off;
        }
    }

    server {
        listen 443 ssl http2;
        server_name example.ru;
        status_zone example.ru;

        location /app {
            status_zone app_backend;
            proxy_pass http://app_upstream;
        }
    }
}

На 127.0.0.1:9090/p8s появляется полный набор метрик: запросы на зоне, upstream latency, 2xx/4xx/5xx, соединения, SSL handshakes. Цепляем Prometheus, строим Grafana-дашборд за 15 минут.

Live-конфигурация upstream

Имейте в виду: в Community-версии статус upstream вы можете только читать. Изменять его не получится.

curl http://127.0.0.1:9090/status/upstreams/app_upstream

Зато в Pro-версии всё намного гибче: серверы можно добавлять или удалять вообще без всяких reload'ов.

curl -X POST http://127.0.0.1:9090/status/upstreams/app_upstream/servers \
  -d '{"server":"10.0.0.5:8080","weight":2,"backup":false}'

curl -X DELETE http://127.0.0.1:9090/status/upstreams/app_upstream/servers/1

Для систем CI/CD это просто находка! Представьте: ваш деплой-скрипт спокойно выводит старый upstream из ротации, потом обновляет приложение, а затем возвращает его обратно. И всё это без единого service reload, без какого-либо обрыва keep-alive соединений. Никакого простоя!

Реальный кейс: перевод 12 сайтов клиента

Как сейчас помню, был октябрь 2024 года. К нам обратился клиент – крупный издательский дом, расположенный, между прочим, прямо в центре Москвы. У них функционировали 12 разнообразных сайтов: и новостные порталы, и интернет-магазин, и личные кабинеты. Все эти ресурсы работали на оригинальном nginx версии 1.22 под Debian 11, да ещё и за балансировщиком HAProxy. Задача, которую они перед нами поставили, была чёткой и недвусмысленной: необходимо перейти на российское ПО из Реестра. Почему? Всё просто: на горизонте уже виднелся серьёзный тендер по 223-ФЗ. А самое важное для нас, да и для клиента, конечно, было одно — миграция должна пройти без малейшего даунтайма. Это было нашим ключевым, просто незыблемым условием.

Провели одно утро в субботу. Схема:

1. Переход мы выполняли последовательно: обрабатывали серверы по очереди, выводя каждый из-под HAProxy перед началом работ.
2. На каждом сервере выполняли такой порядок действий: сначала делали бэкап текущего конфига, затем устанавливали Angie, после чего копировали старый конфиг, обязательно проверяли его командой `angie -t` на корректность и только потом запускали новый сервер.
3. Обязательный смоук-тест проводили по пяти ключевым URL: это главная страница, поиск, личный кабинет, API и, конечно, проверка статики. Важно было убедиться, что всё работает.
4. Возврат в HAproxy-ротацию.

Один сервер выпал: в конфиге было nginx в директиве server_tokens nginx; — не влияет на работу, но мы заметили и почистили. За 3.5 часа перевели все 6 фронтовых нод. Даунтайма не было, нагрузка на CPU стала ниже на 4-6% благодаря улучшенному HPACK-декодеру HTTP/2. Стоимость работ — 38 000 руб., тендер заказчик выиграл.

Где Angie ведёт себя не так, как nginx

• Путь конфига по умолчанию — /etc/angie/, пользователь — angie. Скрипты мониторинга, которые лезли за /etc/nginx/, придётся поправить.
• Команда называется angie, но symlink /usr/sbin/nginx остался — для обратной совместимости.
• Да, статусная страница `stub_status` по-прежнему функционирует, и, конечно, вы можете ею пользоваться. Но давайте будем честными: если говорить о современном мониторинге, то самый правильный путь сегодня — это всё же через встроенный Prometheus-экспортёр.
• Есть один нюанс: некоторые сторонние модули, если они были скомпилированы под конкретную версию nginx, придётся пересобрать уже под Angie. Но не пугайтесь: это почти всегда делается без необходимости править исходный код.
• Важный момент: пакеты Angie обновляются из собственного репозитория. Поэтому, чтобы избежать конфликтов и не допустить восстановления старого nginx при системном `dist-upgrade`, обязательно заблокируйте его из стандартного репозитория. Для Debian/Ubuntu это делается командой `apt-mark hold nginx`.

Мониторинг и логи

# Лог-файлы по умолчанию
tail -F /var/log/angie/access.log /var/log/angie/error.log

# Основные метрики Prometheus
curl -s 127.0.0.1:9090/p8s | grep -E 'angie_http_(request|response|upstream)'

# Проверка конфига
angie -t
angie -V  # версия и флаги сборки

FAQ — частые вопросы о Angie

Angie полностью совместим с nginx?

Да, конфигурации nginx работают в Angie без изменений. Форк делала команда основных разработчиков nginx, совместимость на уровне синтаксиса полная.

Что даёт Angie Pro по сравнению с Community?

Pro добавляет live-конфигурацию upstream без reload, расширенный Prometheus-экспортёр, OIDC, WAF-модуль, mTLS между узлами, русскоязычную enterprise-поддержку. Community достаточно для большинства веб-проектов.

Как мигрировать с nginx на Angie?

Простейший путь: остановить nginx, удалить пакет, установить angie, указать тот же путь к конфигам. Перед остановкой сохраните бэкап через nginx -T.

Есть ли проблемы с сертификацией ФСТЭК?

Angie включён в Реестр российского ПО Минцифры с 2022 года, что закрывает 223-ФЗ и 44-ФЗ. Сертификат ФСТЭК готовит Pro-редакция. Для коммерческих организаций без госсертификатов достаточно Community.

Производительность отличается от nginx?

На одинаковой нагрузке — в пределах 1-3% расхождения. Angie добавил несколько оптимизаций, но разница на обычных веб-нагрузках не ощущается.