Вопрос или проблема
Я хотел бы начать с нуля с некоторой инфраструктурой, которая доступна в интернете, и ищу рекомендации по тому, какое решение для обратного прокси было бы самым простым и разумным. Я знаю о CDN, таких как Cloudflare и Bunny, которые могли бы помочь в этом, но A; я не думаю, что нам нужен их масштаб, и B; я не хочу их стоимости, когда у меня уже есть серверы в ко-ло. У меня есть начальный опыт работы с Nginx, Traefik и Cloudflare. Я слышал о многих других решениях для этого и хочу знать, на чем мне следует сосредоточить свои усилия.
Текущая ситуация;
- Пользователи обращаются прямо к внешнему IP этих систем
- ~100 внутренних веб-страниц в ко-ло
- ~100 внутренних веб-страниц, разбросанных по нескольким штатам США
- Серверы, по сути, все одинаковые — веб-серверы Tomcat / копии корпоративного приложения с несколькими исключениями
- Два домена
- Каждый сервер использует свой собственный SSL-сертификат, wildcard; меня беспокоит переход интернета на сертификаты длительностью ~45 дней в ближайшие годы.
- DNS — это запись “А”, уникальные записи для каждого сервера, каждый сервер имеет свой собственный IPv4
- Совершенно не используют IPv6
Цели для готового решения
- Географическое ограничение источника; только США, с обновлениями по мере покупки и продажи IP пространства (maxmind?)
- Автоматизация SSL-сертификатов
- Изменения в картировании ресурсов или правилах, или обновления приложения требуют минимального времени простоя. У нас нет SLA, системный сбой на несколько минут в не пиковое время будет допустим
- Консолидация в единый новый домен. DNS будет wildcard и в основном будет указывать все на прокси.
- Для пользователей, использующих старый домен; отображать сообщение “Перенаправление на новый URL, пожалуйста, обновите закладку” и затем перенаправлять их на новый URL для этого конкретного сервера.
- Мониторинг в реальном времени, что используется и сколько и т. д., подходит просто в виде таблицы текста
- Некоторый вид долгоживущего внутреннего доверенного SSL-сертификата между прокси и внутренними ресурсами
Расширенные цели
- Резервирование прокси; внутренние ресурсы не могут балансировать нагрузку, но сам прокси может иметь некоторую форму резервирования
- Исторический мониторинг с историей на месяц-два, с диаграммами и графиками
- Основные функции WAF, что-то вроде OWASP mod security, SQL-инъекции, блокировка по угрозе, снижение ботов и т. д.
- Блокировка на основе репутации IP с автоматическими обновлениями
- Блокировка плохих ботов с автоматическими обновлениями
- Доступность IPv6, завершение на прокси, IPv4 к внутренним ресурсам.
Ответ или решение
Прежде всего, давайте разберемся с вашими требованиями и предложим решения, которые помогут вам достичь целей по обновлению вашего интернет-инфраструктуры. Учитывая вашу текущую ситуацию и задачи, есть несколько альтернатив для реализации обратного прокси, среди которых Nginx и Traefik выглядят наиболее подходящими.
1. Анализ текущей ситуации
Вы имеете следующие особенности:
- ~100 серверов приложений на Tomcat, с одинаковой конфигурацией.
- SSL-сертификаты на каждом сервере, которые вызывают беспокойство из-за предстоящих изменений в длительности их действия.
- Отсутствие ГРС (Глобальной Распределенной Системы) для управления адресами IP и DNS-записи типа "A".
- Интерес к автоматизации и мониторингу.
2. Назначение целей
Ваши цели можно разделить на основные и дополнительные:
- Составление линейки бесперебойной работы сервиса.
- Динамическая работа с SSL-сертификатами.
- Географическая сегрегация трафика.
- Обновление доменов и системы мониторинга.
3. Выбор решений
Nginx
Преимущества:
- Широкая поддержка функциональности обратного прокси.
- Настройка автоматического обновления SSL-сертификатов с помощью Let’s Encrypt (при помощи плагина Certbot).
- Простота конфигурации для урегулирования маршрутизации, перенаправления и ограничения доступа по IP.
- Поддержка CDN и можно добавить дополнительные плагины для защиты (например, модуль WAF).
Недостатки:
- Интерфейс настройки может быть менее интуитивным для новичков, чем у некоторых других решений.
Traefik
Преимущества:
- Автоматическое обнаружение сервисов и динамическая настройка маршрутизации.
- Простой в использовании интерфейс и возможность конфигурировать через Docker или Kubernetes, что может быть полезным в будущем.
- Встроенная поддержка Let’s Encrypt для автоматизации SSL-сертификатов.
- Гибкие возможности работы с API, что может помочь в создании расширений функционала.
Недостатки:
- В некоторых случаях может быть менее производительным, чем Nginx, если ваш трафик станет очень высоким.
4. Рекомендации
Учитывая ваши круглосуточные цели и начальный опыт, рекомендую остановиться на Traefik. Он предоставляет отличный баланс между простотой и мощностью, что идеально подходит для вашего уровня сложности и потребностей. С помощью интеграции с Let’s Encrypt вы можете автоматически управлять SSL-сертификатами, а использование встроенного механизма маршрутизации поможет легко адаптироваться к изменениям и требованиям.
5. Реализация и мониторинг
Реализация
- Установите и настройте Traefik на вашем сервере.
- Этот прокси будет работать как промежуточное соединение и обеспечит настройку маршрутизации вашей инфраструктуры.
- Настройте автоматизацию SSL, используя Let’s Encrypt, чтобы избежать беспокойства о коротких сроках действия сертификатов.
Мониторинг
- Внедрите простую систему мониторинга трафика, например, Grafana в комбинации с Prometheus, чтобы отслеживать нагрузки на сервера и тревожные события.
- Исследуйте варианты базовых WAF-функций, возможно потребуется добавить дополнительные модули.
Заключение
Выбор подходящего решения заведомо должен отражать характер вашего предприятия и специфику архитектуры. Traefik предлагает многофункциональный подход с низкой стоимостью и гибкость для выполнения ваших требований. Надеюсь, что этот анализ поможет вам сделать осознанный выбор и успешно перезапустить вашу инфраструктуру.