☰

Как реагировать на проверку работоспособности http по определенному URL-адресу, перенаправляя остальной трафик?

tag-icon • tag-icon nginx configuration google-cloud-platform 301-redirect healthcheck
Как реагировать на проверку работоспособности http по определенному URL-адресу, перенаправляя остальной трафик?

Предыстория: Я пытаюсь настроить группу экземпляров в облачной платформе Google. Группа экземпляров состоит из нескольких экземпляров nginx, чья задача — просто перенаправлять входящий https-трафик на внешний сайт. Если входящий трафик — http, он будет преобразован в https.

Чтобы группа экземпляров работала, она должна ответить на запрос проверки работоспособности (по протоколу http или https) и вернуть 200.

У меня проблема в том, как определить такую ​​конфигурацию nginx.

Это мой первый отрезок. Он обрабатывает только перенаправление

    server {
        listen 80;
        listen 443 ssl;
        ssl on;
        ssl_certificate /etc/nginx/ssl/examples.pem;
        ssl_certificate_key /etc/nginx/ssl/examples.key;
        server_name incoming.examples.com;
        return 301 https://target.examples.com$request_uri;
    }

Я установил URL проверки работоспособности как '/_check' с протоколом http. Это моя первая попытка:

    server {
        listen 80;

        location /_check {
            return 200 'no content';
        }

        listen 443 ssl;
        ssl on;
        ssl_certificate /etc/nginx/ssl/examples.pem;
        ssl_certificate_key /etc/nginx/ssl/examples.key;
        server_name incoming.examples.com;
        return 301 https://target.examples.com$request_uri;
    }

Сервер nginx отвечает кодом 404.

Затем я попытался перейти location к другому serverопределению:

    server {
        location /_check {
            return 200 'no content';
        }
        listen 80;
    }

    server {
        listen 80;
        listen 443 ssl;
        ssl on;
        ssl_certificate /etc/nginx/ssl/examples.pem;
        ssl_certificate_key /etc/nginx/ssl/examples.key;
        server_name incoming.examples.com;
        return 301 https://target.examples.com$request_uri;
    }

У меня тот же результат. Вот что я вижу в журнале доступа.

130.211.3.85 - - [18/Jan/2017:08:41:25 +0000] "GET /_check HTTP/1.1" 404 168 "-" "GoogleHC/1.0"
130.211.3.81 - - [18/Jan/2017:08:41:29 +0000] "GET /_check HTTP/1.1" 404 168 "-" "GoogleHC/1.0"
130.211.1.249 - - [18/Jan/2017:08:41:30 +0000] "GET /_check HTTP/1.1" 404 168 "-" "GoogleHC/1.0"
130.211.3.85 - - [18/Jan/2017:08:41:30 +0000] "GET /_check HTTP/1.1" 404 168 "-" "GoogleHC/1.0"
130.211.3.81 - - [18/Jan/2017:08:41:34 +0000] "GET /_check HTTP/1.1" 404 168 "-" "GoogleHC/1.0"
130.211.1.249 - - [18/Jan/2017:08:41:35 +0000] "GET /_check HTTP/1.1" 404 168 "-" "GoogleHC/1.0"
130.211.3.85 - - [18/Jan/2017:08:41:35 +0000] "GET /_check HTTP/1.1" 404 168 "-" "GoogleHC/1.0"
130.211.3.81 - - [18/Jan/2017:08:41:39 +0000] "GET /_check HTTP/1.1" 404 168 "-" "GoogleHC/1.0"
130.211.1.249 - - [18/Jan/2017:08:41:40 +0000] "GET /_check HTTP/1.1" 404 168 "-" "GoogleHC/1.0

Если я вернусь к первой попытке и изменю проверку работоспособности https(как на следующем снимке экрана),

введите описание изображения здесь

Вместо этого я получаю 301. Мне кажется, что URL-адрес _checkпереопределяется правилом перенаправления.

Мой вопрос: как мне изменить nginx, чтобы он соответствовал требованиям?

решение1

Вы можете настроить проверку работоспособности на работу с любым определенным вами портом, как указано вдокументация. При создании проверки работоспособности можно использовать пользовательский интерфейс или командную строку:

$ gcloud compute health-checks create https NAME [--check-interval=CHECK_INTERVAL; default="5s"] [--healthy-threshold=HEALTHY_THRESHOLD; default=2] [--host=HOST] [--port=PORT; default=80]

На флаге PORT вы можете установить любой по вашему выбору. Затем вам придется настроить свое приложение, чтобы оно реагировало на него.

server {
        location /_check {
            return 200 'no content';
        }
        listen [PORT];

Это позволит избежать перенаправления запросов на проверку работоспособности вместе с остальным трафиком.

Связанный контент