Puncte:0

{âstatusâ:400,âmessageâ:âBad requestâ} atunci când accesați un microserviciu folosind Nginx API Gateway

drapel us

Bună, încerc să consum o API folosind Nginx API Gateway: am această adresă URL: example.com/api/nodeapp. În configurația mea, am un controler Ingress care este expus extern la .com și care acceptă cererea de autentificare și redirecționare către podul intern nginx (expus ca serviciu IP Cluster în cluster privat) acest pod intern nginx va redirecționa către podul microserviciu țintă ( expus și ca serviciu IP Cluster în același cluster privat). Scop: răsfoiesc URL-ul ca example.com/api/nodeapp ---> Ingress va face o cerere de auth și redirecționează către Nginx (ceea ce se întâmplă bine), Nginx ia cererea mea și mă redirecționează către microserviciu nodeapp țintă (care nu reușește la Eroare 400) Fragmentele mele de cod:

Intrare.yaml

specificație:
  reguli:
    - gazdă: example.com
      http:
        trasee:
          - calea: /api/nodeapp
            backend:
              serviceName: nginx-internal-service
              servicePort: 80
          - calea: /api/tea
            backend:
              serviceName: nginx-internal-service
              servicePort: 80

Nginx.conf

utilizator nginx;
worker_proceses auto;

error_log /var/log/nginx/error.log depanare;
pid /var/run/nginx.pid;


evenimente {
    conexiuni_muncitor 1024;
}


http {
    includ /etc/nginx/mime.types;
    aplicație de tip_default/octet-stream;

    log_format principal „$remote_addr - $remote_user [$time_local] „$request” '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log principal;

    sendfile activat;
    #tcp_nopush on;

    keepalive_timeout 65;

    #gzip activat;
    includ /etc/nginx/api_gateway.conf;
    includ /etc/nginx/conf.d/*.conf;
}

api_gateway.conf

include api_backends.conf;
#include api_keys.conf;

Server {
    access_log /var/log/nginx/api_access.log principal; # Fiecare API se poate conecta și la un fișier separat

    asculta 80; # Configurația TLS merge aici (pentru utilizare în producție)
    nume_server example.com;

    # Configurare TLS
    #ssl_certificate /etc/ssl/certs/api.example.com.crt;
    #ssl_certificate_key /etc/ssl/private/api.example.com.key;
    #ssl_session_cache shared:SSL:10m;
    #ssl_session_timeout 5m;
    #ssl_ciphers HIGH:!aNULL:!MD5;
    #ssl_protocols TLSv1.2 TLSv1.3;
   # Resursa nevalidă
    Locație / {
        rescrie ^ https://$host$request_uri permanent;
    }
    # Definiții API, una per fișier
    include api_conf.d/*.conf;

    # Răspunsuri de eroare
    error_page 404 = @400; # Căile nevalide sunt tratate ca solicitări incorecte
    locație @400 {
        returnează 400 '{"status":400,"message":"Solicitare greșită"}\n';
    }
    proxy_intercept_errors activat; # Nu trimiteți erori de backend către client
    include errors_json.conf; # Răspunsuri de eroare JSON prietenoase cu clienții API
    tip_implicit aplicație/json; # Dacă nu există tip de conținut, presupuneți JSON
}

nodeapi_simple.conf

# Node API
#
locație /api/ {
    # Configurarea politicii aici (autentificare, limitare a ratei, înregistrare în jurnal, mai multe...)
    #
    access_log /var/log/nginx/nodeapp_api.log principal;

    # URI rutare
    #
    locație /api/ceai {
        proxy_pass http://tea;
    }

    locație /api/nodeapp {
        proxy_pass http://nodeapp;
    }

    întoarce 404; # Prindele pe toate
}

# vim: syntax=nginx

api_backend.conf

nodeapp în amonte {
    zona nodeapp 64k;
    server nodeapp IP: 8000;
    
    
}


ceai din amonte {
    zona ceai 64k;
    server aplicație ceai IP:80;
    
    
}



# vim: syntax=nginx

Principalul meu obiectiv aici este să rulez example.com/api/nodeapp pentru a rula, care nu funcționează, deși am testat deja nodeapp pe localhost, care funcționează bine.De asemenea, un lucru ciudat este că această aplicație de ceai este doar un exemplu de aplicație bazată pe text, care funcționează așa cum am accesat în browser URL-ul example.com/api/tea funcționează a[[1]: https://i.stack.imgur .com/3fP3k.png][1]s pe imaginea de mai jos:

Aici sunt jurnalele mele [1]: https://i.stack.imgur.com/jssnb.png][1] Am rămas blocat cu această eroare de 3 zile, prin urmare, am cerut tuturor să mă ajute în privința asta cât mai curând posibil

Michael Hampton avatar
drapel cz
Ai scris această configurație nginx sau ai copiat-o de undeva? Arată clar că „400” pe care l-ați primit a fost de fapt un 404 de la serverul API pe care configurația dvs. îl rescrie într-un 400 cu acel corp de răspuns specific. Ar trebui să vă uitați mai departe la serverul API.
yash avatar
drapel us
Folosesc configurația nginx de pe blogul nginx „Deploying NGINX as an API Gateway, Part 1” și am testat serverul node api cu intrarea externă a nginx în sine, a fost bine (200) ca ori de câte ori am lovit example.com/node (fără utilizare de nginx intern) primesc pagina cu succes, dar când lovesc example.com/api/nodeapp (prin intrare și pod intern nginx) primesc această eroare 400
yash avatar
drapel us
Am adăugat și jurnalele, deși nu sunt multe detalii, dar asta este ceea ce primesc
yash avatar
drapel us
ai dreptate, am comentat linia „pagina de eroare 404 = @400” și acum primesc eroarea 404, dar nu sunt sigur ce să fac în continuare
Michael Hampton avatar
drapel cz
Vă verificați din nou cererea.
yash avatar
drapel us
Mi-am verificat din nou aplicația în interiorul serverului că funcționează, de fapt, există o captură aici, este ceva în neregulă cu "proxy pass http://nodeip:nodeport" Ce am făcut este că am comentat această linie în blocul locație /api/nodeapp {) și in schimb ca am pus return 200; și apoi mi-am testat aplicația, aceasta atinge 200, ceea ce înseamnă că există ceva neplăcut cu trecerea proxy care nu poate atinge aplicația mea nod
yash avatar
drapel us
Funcționează, cred că acum trebuie doar să adaug / la sfârșitul proxy pass proxy pass nodeip:nodeport astfel --> proxy pass nodeip:nodeport/
yash avatar
drapel us
Singura problemă pe care a avut-o cum, dacă aplicația mea este configurată în așa fel încât solicitarea mea ar putea fi ca /api/nodeapp/something, atunci cum să redirecționez această adresă URL către pagina vizată?

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.