[ CoyoteKG @ 28.09.2018. 12:34 ] @
Da li postoji nešto slično kao što AWS ima "Application Load Balancer".

Naime, razvijamo neki sajt u .NET (hostovan na IIS). Trenutni sajt je PHP (hostovan na LAMP).
Razvijen je komplet frontend koji koristi MySQL bazu trenutnog live PHP servera.
Zbog kompleksnosti Admin panela za partnere sajta, ne možemo stići da ga uradimo odmah, a klijent želi odmah live sa .NET verzijom frontenda koja je kompletno završena.

Neko rešenje nam je da .NET počne da koristi trenutni aktivni live domain, a PHP sajt da prebacimo na neki subodomain.

Ali sad vidim da ovaj AWS servis pruža da na nivou samog urla Load Balancer forwarduje saobraćaj na server koji treba.

Što bi bilo super jer

sav saobraćaj www.nekidomen.com/* da usmerava na IIS server, a www.nekidomen.com/admin/* da ide na LAMP.
Na taj način ne bismo morali da menjamo domain php sajta, koji komplikuje sa još nekim drugim stvarima koje n'umem da namestim.

Nisam nameštao još ni na AWS da vidim kako bi to izgledalo, ali po dokumentaciji deluje da je moguće i lako. Još bi bilo bolje, da na Hetzneru uzmem neki server za par eura, koji će da radi load balancing :)
[ djoka_l @ 28.09.2018. 12:39 ] @
http://nginx.org/en/docs/http/load_balancing.html
[ CoyoteKG @ 28.09.2018. 12:53 ] @
Čitao sam ranije, ali nisam video da može na nivou URL-a da prosleđuje zahtev na određeni server.
Ali pročitaću ponovo :)
[ djoka_l @ 28.09.2018. 13:29 ] @
Tebi, u stvari, nije potreban load balancing, nego reverse proxy
https://docs.nginx.com/nginx/a...uide/web-server/reverse-proxy/

Code:

server {
   listen 80;

   location /admin {
      proxy_pass <lokacija admin sajta>;
   }

   location / {
     proxy_pass <lokacija ostatka sajta>;
   }
}


Konfiguracioni fajl sam izvukao iz malog mozga, ne mora da znači da je ispravan, ali to je, otprilike, princip.
[ Burgos @ 28.09.2018. 13:30 ] @
Mislim da i haproxy ima podršku za to:

https://cbonte.github.io/hapro...nfiguration.html#4-use_backend
https://cbonte.github.io/hapro.../configuration.html#7.3.6-path

https://stackoverflow.com/a/20640578

Edit: mislim da je djoka_l u pravu :-)
[ nkrgovic @ 28.09.2018. 13:37 ] @
NginX je za to majka, HA Proxy moze isto. Koji od ta dva, zavisi od use case-a. Obicno, ako imas NginX za php, onda imas NginX i tu, da ti stack bude uniforman, a ako ti samo treba proxy HA Proxy je nesto bolji, posebno dok ne treba da skalira na vise procesora.

HA Proxy je ziva zgoda kad nemas samo HTTP/HTTPS, jer on moze i cist TCP da hendluje, dok je NginX dosta specific. S'druge strane NginX moze i npr. da uglavi ModSecurity i napredno kesiranje i svasta nesto HTTP related.... :)
[ djoka_l @ 28.09.2018. 13:44 ] @
Pre, otprilike, 2-3 godine, dok sam se time više bavio svi su se slagali da je vreme hardverskih reverse proxy gotovo. Koristi se samo nginx ili HA proxy.

Pa još kad u to uglaviš load balancing, dodaš da statičke fajlove vraća sam nginx umesto da to radi Apache ili IIS, web aplikacija poleti.
Ja sam najčešće koristio nginx da imam 3-4 verzije istog sajta, pa onda radim redirekcije /test1 , /test2 ... pa kad mi testiranje prođe, samo promenim nginx config fajl da root pokazuje na test lokaciju koja postaje produkcija, jedan kill -HUP na nginnx i u "letu" promeniš šta ti korisnici vide.
[ CoyoteKG @ 28.09.2018. 13:53 ] @
nije mi pao na pamet nginx reverse proxy :).
Koristio sam ga samo ispred apache za staticke fajlove.

hvala
[ nkrgovic @ 28.09.2018. 17:02 ] @
Citat:
djoka_l:
Pre, otprilike, 2-3 godine, dok sam se time više bavio svi su se slagali da je vreme hardverskih reverse proxy gotovo. Koristi se samo nginx ili HA proxy.

Pa još kad u to uglaviš load balancing, dodaš da statičke fajlove vraća sam nginx umesto da to radi Apache ili IIS, web aplikacija poleti.
Ja sam najčešće koristio nginx da imam 3-4 verzije istog sajta, pa onda radim redirekcije /test1 , /test2 ... pa kad mi testiranje prođe, samo promenim nginx config fajl da root pokazuje na test lokaciju koja postaje produkcija, jedan kill -HUP na nginnx i u "letu" promeniš šta ti korisnici vide.

nginx -s reload , mnogo je kulturnije nego kill -HUP .

A da je vreme hadvera gotovo.... zavisi za koga. Again, za neke velike firme, tipa banke, kojima treba PCI compliant WAF i slicno, vreme je jos uvek tu. Pri tom F5 je jako fina sprava, ima finu integraciju, podrsku za OpenStack i Kubernetes orkestraciju, sjajan firewall, svasta.... :) JAKO je skupa, ali da imam budzet u projektu i te kako bi voleo da je vidim. :D
[ CoyoteKG @ 28.09.2018. 21:21 ] @
Dakle ovo sto je djoka_l napisao.

delovalo bi da je ovako dovoljno.

S obzirom da su mi serveri kod dva razlicita provajdera, ostaje ili da ih povezem VPNom ili da koristim njihove public ip, s tim što bih limitirao portove da na njih može da se pristupi samo sa te jedne adrese LBa
SSL treba da mi bude stavljen pretpostavljam samo tamo gde su mi sajtovi?

Code:
server {
    listen 443 default_server;

    root /usr/share/nginx/html;
    index index.html index.htm;

    server_name www.nekidomain.com;

    location / {
       proxy_set_header X-Real-IP  $remote_addr;
       proxy_set_header X-Forwarded-For $remote_addr;
       proxy_set_header Host $host;
       proxy_pass https://jednapublicip;
       }

    location /admin/ {
       proxy_set_header X-Real-IP  $remote_addr;
       proxy_set_header X-Forwarded-For $remote_addr;
       proxy_set_header Host $host;
       proxy_pass https://drugapublicip;
    }
}
[ nkrgovic @ 28.09.2018. 22:17 ] @
"SSL" (Deprecated odavno, TLS zapravo, ili https kako hoces) obavezno na load balanceru. Ako ti treba https na https mozes to da stavis u backend, pa da onda stavis i https u backend deo - to ti ovde fali. Ovako nesto:
Code:

server {
    listen 443 default_server;

    root /usr/share/nginx/html;
    index index.html index.htm;

    server_name www.nekidomain.com;

    ssl_certificate /etc/some/path/fullchain.pem; 
    ssl_certificate_key /etc/some/path/privkey.pem;
    ssl_dhparam /etc/some/path/ssl-dhparams.pem;

    ssl_protocols        TLSv1.1 TLSv1.2;
    ssl_ciphers           HIGH:!aNULL:!MD5;

    upstream prvi {
        server a.b.c.d:443 max_fails=3 fail_timeout=30s;
    }

    upstream drugi {
        server e.f.g.h:443 max_fails=3 fail_timeout=30s;
    }

    location / {
       proxy_set_header X-Real-IP  $remote_addr;
       proxy_set_header X-Forwarded-For $remote_addr;
       proxy_set_header Host $host;
       proxy_pass https://prvi;
       }

    location /admin/ {
       proxy_set_header X-Real-IP  $remote_addr;
       proxy_set_header X-Forwarded-For $remote_addr;
       proxy_set_header Host $host;
       proxy_pass https://drugi;
    }
}