Балансировка нагрузки через веб-сокет через Apache и Haproxy с завершением SSL - PullRequest
0 голосов
/ 20 января 2020

Краткий обзор того, чего я пытаюсь достичь ... enter image description here

У меня 4 сервера приложений на 2 физических серверах, позвоните им:

app1 192.168.1.71 16001

app2 192.168.1.71 16002

app3 192.168.1.72 16003

app4 192.168.1.72 16004

И сервер Haproxy, вызов это:

192.168.1.36

Все веб-трафики c на 443 и 80 перенаправляются на сервер Apache со шлюза, а на сервере apache имеется много виртуальных хостов конфиги (которые все работают нормально). Единственный вопрос, о котором идет речь, - это перечисленный ниже, который перенаправляет на haproxy.

Сначала я попытался выполнить балансировку нагрузки исключительно с помощью Apache, но столкнулся с проблемами из-за разных номеров портов для каждого хоста.

Так что теперь я передаю прокси Apache в Haproxy для определенных URL, назовите его myapp.example.com, все HTTP-трафики c на apache перенаправляются на HTTPS, затем HTTPS-трафики c SSL завершается и отправляется на Haproxy IP, затем Haproxy предназначен для балансировки нагрузки соединений, а также в идеале для обновления веб-сокетов traffi c, однако я думаю, что у меня могут быть некоторые проблемы с конфигурацией, которые я надеюсь, что-то одно может помочь мне решить.

APACHE Конфиг

<VirtualHost *:80>
    ServerName myapp.example.com
    ServerAlias myapp.example.com
    Redirect / https://myapp.example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName myapp.example.com
    ServerAlias myapp.example.com

    SSLEngine On
    SSLProxyEngine On
    RewriteEngine On

    RewriteCond %{HTTP:UPGRADE} websocket [NC,OR]
    RewriteCond %{HTTP:CONNECTION} upgrade [NC]
    RewriteRule .* ws://192.168.1.36:80%{REQUEST_URL} [P,QSA,L]

    SSLProtocol +TLSv1.2
    SSLCertificateFile /etc/letsencrypt/live/myapp.example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/myapp.example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/myapp.example.com/chain.pem
    ProxyPreserveHost On
    ProxyRequests Off

    ProxyPass               /       http://192.168.1.36:80/ flushpackets=on
    ProxyPassReverse        /       http://192.168.1.36:80/

</VirtualHost>

ГАПРОКСИ Конфиг

global
    daemon
    maxconn 256
    user        haproxy
    group       haproxy
    chroot      /var/lib/haproxy

defaults
    mode http
    log global
    option dontlognull
    option httplog
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms
    option http-server-close
    option forwardfor
    option redispatch

frontend myapp.example.com
    bind *:80
    bind *:443
    #mode http
    stats enable
    stats uri /stats
    http-request add-header X-Forwarded-Proto https
    acl host_ws hdr_beg(Host) -i ws.
    use_backend myapp.example.com_servers_ws if host_ws

    acl hdr_connection_upgrade hdr(Connection) -i upgrade
    acl hdr_upgrade_websocket hdr(Upgrade) -i websocket
    use_backend myapp.example.com_servers_ws if hdr_connection_upgrade hdr_upgrade_websocket
    default_backend myapp.example.com_servers

backend myapp.example.com_servers
    mode http
    http-request add-header X-Forwarded-Proto https
    balance roundrobin
    cookie JSESSIONID prefix
    server app1 192.168.1.71:16001 check cookie app1
    server app2 192.168.1.71:16002 check cookie app2
    server app3 192.168.1.72:16003 check cookie app3
    server app4 192.168.1.72:16004 check cookie app4

backend myapp.example.com_servers_ws
    balance roundrobin
    cookie JSESSIONID prefix

    server app1 192.168.1.71:16001 check cookie app1
    server app2 192.168.1.71:16002 check cookie app2
    server app3 192.168.1.72:16003 check cookie app3
    server app4 192.168.1.72:16004 check cookie app4

Ошибки Это текущая ошибка, которую я получаю, у меня также был смешанный статус 504,400,200, когда я пробовал различные конфигурации. Видимо, я должен ожидать статус 101, если обновление прошло успешно? Но я никогда этого не вижу.

Любая помощь приветствуется

enter image description here

ОБНОВЛЕНИЯ 22/01/2020

Сейчас я передаю все траффики c с Apache на новый NGINX сервер, отображаются веб-сайты и заметки, однако я получаю ошибки смешанного содержимого. Хост - https://example.com, но затем сервер приложений выполняет HTTP-ответ, такой как http://example.com/getblah.

Я мог бы сделать это, используя F5 BigIP, например, ниже, как я могу повторить это в NGINX?

Возможное правило перезаписи для F5 BigIP (если у меня было такое, которого у меня нет)

when HTTP_RESPONSE {
    if { [HTTP::is_redirect] } {
    if { [string tolower [URI::host [HTTP::header Location]]] contains " 
        <example.com>" and [URI::protocol [HTTP::header Location]] equals "http"} {
                HTTP::header replace Location [string replace [HTTP::header Location] 0 3 https]
            }
        }
    }

Как мне переписать http-ответ сервера приложений на https, чтобы избежать ошибок смешанного содержимого?

NGINX Config

server {
    listen 80;
    server_name example.com;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header Connection "";
    location / {
            return 301 https://$server_name$request_uri;
            #proxy_pass https://$server_name$request_uri;
            #proxy_redirect $scheme://$host:$server_port $request_uri;
    }
}

server {
    access_log  /var/log/nginx/host.access.log  main;
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/cert.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_session_cache shared:SSL:1m;
    ssl_prefer_server_ciphers on;

    location / {
            proxy_pass http://snow;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Host $host:$server_port;
            proxy_set_header X-Forwarded-Proto $scheme;
    }
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

upstream snow {
    ip_hash;
    server 192.168.1.71:16001;
    server 192.168.1.71:16002;
    server 192.168.1.72:16003;
    server 192.168.1.72:16004;

}

...