Puncte:0

Proxy invers Nginx pentru două aplicații web

drapel in

Am două aplicații.

  • Aplicația Laravel - Fiind doar un site web dinamic. Nu are date-cunoaștere. Toate datele sunt preluate din a doua aplicație folosind cereri AJAX. Merge mai departe 127.0.0.1:8000.
  • Aplicarea ruginii - O aplicație web care conține toată afacerea logica si accesul la date. Merge mai departe 127.0.0.1:8080.

Ambele aplicații trebuie să fie accesibile de la adresa URL exemplu.com. Pentru aceasta vreau să folosesc Nginx Reverse Proxy. Pot deja să redirecționez toate solicitările către aplicația mea Laravel.

evenimente {}
http {
    Server {
        asculta 80;

        # Site-ul web
        Locație / {
            proxy_pass http://127.0.0.1:8000;
        }
        
    }
}

În timp ce aplicația Laravel funcționează, am nevoie de următoarea configurație Nginx:

  • Pagini specifice cum ar fi /știri, /, /despre,/a lua legatura,... ar trebui redirecționat către 127.0.0.1:8000.
  • Notă: Paginile de mai sus pot conține parametri GET, cum ar fi de ex /news?article=abc.
  • TOATE celelalte solicitări trebuie redirecționate către 127.0.0.1:8080.
  • Notă: 127.0.0.1:8080 poate conține adesea un subdomeniu. Dar acest subdomeniu trebuie să acționeze ca un wildcard și este necunoscut în momentul configurării. Exemplu: bussiness1.example.com, bussiness2.example.com, businnesX.example.com,...

Subdomeniul returnează o pagină personalizată pentru care un număr nelimitat de companii o pot solicita pe example.com.

Cum as realiza aceasta configuratie? Ma gandeam la asa ceva?

#PSEUDO
evenimente {}
http {
    Server {
        asculta 80;

        # Site-ul web
        Locație / {
            proxy_pass http://127.0.0.1:8000;
        }
        locație /știri {
            proxy_pass http://127.0.0.1:8000;
        }
        locație /aproximativ {
            proxy_pass http://127.0.0.1:8000;
        }

        # Aplicație
        Locație * {
            proxy_pass http://127.0.0.1:8080;
        }

    }
}

Editați cu privire la răspunsul lui Tero: Am nevoie de un fel de wildcard pentru subdomenii.

 # Aplicație captivantă
    Locație / {
        proxy_pass http://$subdomain.$application;
    }

abc.example.com trebuie să acceseze abc.127.0.0.1:8080 def.example.com trebuie să acceseze def.127.0.0.1:8080 ...

Știu că un IP nu poate avea un subdomeniu, dar nu vă faceți griji pentru asta. Am rezolvat asta cu gazde virtuale.

Editare 2 - Treceți subdomeniul solicitării către proxy_pass:

Server {
        asculta 80;
        nume_server *.website.com;
        nume_server ~^(?<subdomeniu>.+)\.website\.com$;

        Locație / {
            proxy_pass http://$subdomain.vhost.local:8080;
        }
    }

Este acesta modul corect de a redirecționa dynamicxxx.website.com către dynamicxxx.vhost.local:8080?

djdomi avatar
drapel za
Cred că trebuie să înlocuiți steaua cu tilde
Puncte:2
drapel us

Designul tău este puțin complex și, prin urmare, fragil. Cu toate acestea, puteți încerca următoarele. Am adăugat în amonte blocuri astfel încât diferitele proxy_pass destinațiile sunt mai ușor de citit.

site web din amonte {
    server 127.0.0.1:8000;
}

aplicație în amonte {
    server 127.0.0.1:8080;
}

Server {
    nume_server example.com *.example.com;

    asculta 80;

    # Aplicație captivantă
    Locație / {
        proxy_pass http://aplicație;
    }

    # Site-ul web
    locație = / {
        proxy_pass http://site-ul web;
    }

    locație /știri {
        proxy_pass http://site-ul web;
    }

    locație /aproximativ {
        proxy_pass http://site-ul web;
    }
}

The = caracterul înseamnă o potrivire exactă pe URI și este prima prioritate în procesul de căutare nginx, așa cum este descris în documentația nginx

O abordare alternativă este utilizarea expresiei regulate:

Server {
    nume_server example.com *.example.com;

    asculta 80;

    Locație / {
        proxy_pass http://aplicație;
    }

    locație ~ ^(?:/|/știri|/despre) {
        proxy_pass http://site-ul web;
    }
}

The nume_server example.com *.example.com îi spune nginx să proceseze toate cererile către domeniul principal și orice subdomeniu cu aceste reguli.

Dacă regulile de solicitare a site-ului web trebuie să se aplice numai pentru exemplu.com, atunci trebuie să definiți altul Server bloc cu nume_server *.example.com și numai reguli de aplicare.

Editați | ×

Da, subdomeniul poate fi capturat într-o variabilă ca aceasta și utilizat în proxy_pass destinaţie.Trebuie să aveți toate domeniile într-un singur numele serverului linia:

nume_server example.com ~^(?<subdomeniu>[^.]+)\.example\.com;
O'Niel avatar
drapel in
Multumesc mult pentru raspuns! Asta se apropie. Cu toate acestea, Catch-all pentru aplicație trebuie să se ocupe și de subdomenii. Este posibil un fel de wildcard? Vezi editarea postării.
drapel us
Apoi trebuie să faceți un al doilea bloc `server` pentru subdomeniile cu `server_name *.example.com`.
O'Niel avatar
drapel in
Mulțumesc pentru tot ajutorul! A explicat mult. Dacă ai putea să te uiți din nou la a doua mea editare? În ceea ce privește wildcardul subdomeniului.
O'Niel avatar
drapel in
Sunt foarte apropiat. Rămâne doar wildcardul subdomeniului.
drapel us
Am adăugat un exemplu `server_name`.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.