Прозрачный прокси HaProxy для AWS S3 Статический сайт Страница

Question

Я использую haproxy для балансировки кластера серверов. Я пытаюсь добавить страницу обслуживания в конфигурацию haproxy. Я считаю, что могу это сделать, указав объявление сервера в бэкэнд с модификатором «backup». У меня есть вопрос: как я могу использовать страницу обслуживания, размещенную удаленно на вебе AWS S3 (статический веб-сайт), без фактического перенаправления пользователя на эту страницу (то есть определение «перенаправление» haproxy-сервера).

Если у меня есть серверы: a, b, c. Все серверы идут вниз для обслуживания, тогда я хочу, чтобы все запросы были разрешены с помощью определения сервера d (который помечен как «резервная копия») на статический адрес на S3. Обратите внимание, что я не хочу, чтобы пути переносились и оценивались на s3, он всегда должен отображать статическую страницу обслуживания.

Answer 1

Это определенно возможно.

Сначала объявите резервный сервер, который будет использоваться, только если серверы, не поддерживающие резервное копирование.

server s3-fallback example.com.s3-website-us-east-1.amazonaws.com:80 backup 

следующие элементы конфигурации используются для изменения запроса или ответа только если мы используем альтернативный путь. Мы используем два теста в следующих примерах:

# { nbsrv le 1 } -- if the number of servers in this backend is <= 1 
# (and) 
# { srv_is_up(s3-fallback) } -- if the server named "s3-fallback" is up; "server name" is the arbitrary name we gave the server in the config file 
# (which would mean it's the "1" server that is up for this backend) 

Итак, теперь, когда мы имеем backup фоновым, нам нужно несколько других директив.

Заставить путь к / независимо от пути запроса.

http-request set-path/if { nbsrv le 1 } { srv_is_up(s3-fallback) } 

Если вы используете по существу пустое ведро с документом об ошибке, то это на самом деле не нужен, так как любой запрос путь будет генерировать ту же ошибку.

Далее, нам нужно установить заголовок Host: в исходящем запросе, чтобы он соответствовал имени ведра. Это не технически необходимо, если ведро названо так же, как и заголовок Host:, который уже присутствует в запросе, который мы получили от браузера, но, вероятно, все же хорошая идея. Если имя ведра отличается, оно должно быть здесь.

http-request set-header host example.com if { nbsrv le 1 } { srv_is_up(s3-fallback) } 

Если имя ведра не является допустимым DNS-именем, то здесь вы должны включить конечную точку всего веб-сайта. Для ведра под названием «Пример» -

http-request set-header host example.s3-website-us-east-1.amazonaws.com if { nbsrv le 1 } { srv_is_up(s3-fallback) } 

Если ваши клиенты отправлять вам свои куки, нет необходимости передавать их на S3. Если клиентами являются HTTPS, а соединение S3 - HTTP, вы определенно можете их удалить.

http-request del-header cookie if { nbsrv le 1 } { srv_is_up(s3-fallback) } 

Теперь обработка ответа ...

Вы, вероятно, не хотите браузеров кэшировать ответы от этого альтернативного фонового.

http-response set-header cache-control no-cache if { nbsrv le 1 } { srv_is_up(s3-fallback) } 

Вы также, вероятно, не хотят, чтобы вернуться «200 OK» для этих ответов, так как технически, вы показываете страницу ошибки, и вы не хотите, чтобы поисковые системы, чтобы индексировать этот материал. Здесь я выбрал «503 Service Unavailable», но любой действительный код ответа будет работать ... например, 500 или 502.

http-response set-status 503 if { nbsrv le 1 } { srv_is_up(s3-fallback) } 

И там у Вас есть это - с помощью S3 сайта Ковш конечной точки в качестве резервного бэкэндом, не ведет себя не по-другому, чем любой другой серверной. Нет перенаправления браузера.

Вы также можете настроить запрос на S3 для использования HTTPS, но поскольку вы просто загружаете статический контент, это кажется ненужным. Если браузер подключается к прокси-серверу с помощью HTTPS, этот раздел соединения будет по-прежнему безопасным, хотя вам нужно очистить что-либо чувствительное от запроса браузера, поскольку оно будет перенаправлено на S3 незашифрованным (см. Выше «cookie») ,

Данное решение протестировано на HAProxy 1.6.4.

---

Обратите внимание, что по умолчанию поиск DNS для S3 конечной точки будет сделан только тогда, когда HAProxy перезапуска. Если этот IP-адрес изменится, HAProxy не увидит изменения без дополнительной настройки - это выходит за рамки этого вопроса, но см. В руководстве по конфигурации the resolvers section.

---

Я использую S3 в качестве фонового сервера за HAProxy в нескольких различных системах, и я считаю, что это будет отличным решением для целого ряда различных вопросов.

Однако существует более простой способ создать страницу пользовательских ошибок, которая будет использоваться, когда все внутренние компоненты опущены, если это то, что вы хотите.

errorfile 503 /etc/haproxy/errors/503.http 

Эта директива обычно находится в глобальной конфигурации, но это также справедливо в бекенде - так это сырье файл будет автоматически возвращен прокси-сервером для любого запроса, который пытается использовать этот бэкэнд, если все серверов в этом back-end нездоровы.

Файл является сырым ответом HTTP. Он по существу просто выписан клиенту, поскольку он существует на диске, с нулевой обработкой, поэтому вам нужно включить нужные заголовки ответов, включая Connection: close. Каждая строка заголовков и строка после заголовков должны заканчиваться \r\n, чтобы быть действительным ответом HTTP. Вы также можете просто скопировать один из других и изменить его по мере необходимости.

Эти файлы ограничены размером буфера ответа, который я считаю является tune.bufsize, который по умолчанию 16384 байт ... так что это очень хорошо для небольших файлов.

HTTP/1.0 503 Service Unavailable\r\n 
Cache-Control: no-cache\r\n 
Connection: close\r\n 
Content-Type: text/plain\r\n 
\r\n 
This site is offline. 

---

Наконец, следует отметить, что, несмотря на то, что вы желающей «прозрачно прокси запрос,» Я не думаю, что фраза «прозрачный прокси» правильный один за то, что «попробуйте сделать это, потому что« прозрачный прокси »подразумевает, что либо клиент, либо сервер или оба будут видеть IP-адреса друг друга в соединении и полагают, что они обмениваются напрямую, без промежуточного прокси-сервера, из-за некоторой skullduggery, сделанной прокси и/или сетевой инфраструктуры, чтобы скрыть существование прокси в пути. Это не то, что вы ищете.