Назад | Перейти на главную страницу

Обратный прокси-сервер Squid: режим обслуживания

В настоящее время я пытаюсь настроить обратный прокси-сервер squid (3.1) так, чтобы он всегда отображал статическую веб-страницу, когда единственный внутренний веб-сервер находится на обслуживании. В автоматическом переключении нет необходимости. Режим обслуживания активируется путем изменения конфигурации вручную.

Документация и вики по Squid не очень помогли в этом вопросе. Моя идея заключалась в том, чтобы блокировать каждый запрос и отображать статическую веб-страницу как deny_info с кодом состояния 200, например:

acl everyone src 0.0.0.0/0.0.0.0
## Testing with my client ip address:
# acl everyone src 10.123.0.40/32
http_access deny everyone
deny_info 200:/etc/squid/maintenance.html everyone

Я разместил этот фрагмент перед любой другой http_access Правило и попробовал эту конфигурацию, только заблокировав трафик моих собственных клиентов, но не было никакого эффекта, используя squid -k reconfigure. Это может сработать, когда я использую sudo service squid restart но я не хочу тестировать его прямо сейчас, потому что в то время многие пользователи используют эту службу, и перезапуск squid занимает около получаса (для каждого теста).

Мои вопросы:

  1. Подходит ли эта конфигурация для этой цели?
  2. Мне нужно использовать sudo service squid restart чтобы изменения вступили в силу или просто что-то не так?
  3. Есть ли лучшее решение для отображения статической страницы обслуживания?

Заранее спасибо.

  • squid 3.1.x похож на тысячу лет.
  • squid 3.x полностью утратил способность мягкая реконфигурация, поэтому для применения изменений конфигурации требуется перезапуск. Это означает, что вы потеряете свои клиентские подключения к сайту. Каждый раз это будет похоже на флеш-DoS.

В заключение: это делает squid непригодным для использования в качестве обратного прокси для веб-сайта в производственной среде. Рассмотрите возможность использования nginx.

Если, несмотря на эти предупреждения, вы по-прежнему планируете использовать кальмар, то вам следует написать перенаправитель который будет проверять, должна ли действовать ложная страница, чтобы нейтрализовать проблему перезапуска. Этот перенаправитель может быть написан на любом языке сценариев, который вы знаете: perl, python, ruby ​​или даже /bin/sh. Логика проста: перенаправитель проверит какой-то знак (например, флаг файла), если страница-ловушка должна отображаться, если нет - он просто передаст запрос бэкэнду. Он может даже проверить жизнеспособность таких бэкендов.

Но nginx имеет эту функциональность "из коробки".