Обратный прокси-сервер 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 занимает около полминуты (для каждого теста ).
Мои вопросы:
- Подходит ли эта конфигурация для этой цели?
- Нужно ли мне использовать
sudo service squid restart, чтобы изменения вступили в силу, или что-то просто не так? - Есть ли лучшее решение для отображения статической страницы обслуживания?
Спасибо заранее.
- squid 3.1.x похоже на тысячу лет.
- squid 3.x полностью потерял возможность мягкого перенастройки , поэтому для применения изменений конфигурации требуется перезапуск. Это означает, что вы потеряете свои клиентские подключения к сайту. Каждый раз это будет похоже на flash-DoS.
В заключение: это делает squid непригодным для использования в качестве обратного прокси для веб-сайта в производственной среде. Рассмотрите возможность использования nginx .
Если, несмотря на эти предупреждения, вы все еще планируете использовать squid, вам следует написать редиректор , который будет проверять, должна ли действовать ложная страница. , чтобы нейтрализовать проблему перезапуска. Этот редиректор может быть написан на любом языке сценариев, который вы знаете: perl, python, ruby или даже / bin / sh . Логика проста: перенаправитель проверит какой-то знак (например, флаг файла), если страница-ловушка должна отображаться, если нет - он просто передаст запрос бэкэнду. Он может даже проверить жизнеспособность таких механизмов.
Но nginx имеет эту функциональность "из коробки".