Przekierowanie na serwis w klastrze

Cześć,

mam taką konfigurację dwóch serwisów - jeden fe na nginxie, drugi backend na .net core webapi:


Aplikacje działają poprawnie - jestem poprzez EXTERNAL-IP dobić się do aplikacji frontendowej.
Moje backendowe API działa na ścieżce /api/example-endpoint...
Potwierdziłem jego działanie logując się bashem do kontenera w podzie aplikacji frontendowej i wywołując curl http://webapi/api/weatherforecast

Problem w tym, że nie potrafię przekierować ruchu z adresu EXTERNAL_IP/api/... do aplikacji backendowej.

Próbowałem konfigurować nginxa na którym działa frontend jednak nic to nie dało...

Czy ktoś spotkał się z takim problemem w przeszłości?

w nginx zamiast proxy_pass http://webapi; musisz dać proxy_pass http://Backend;
A reszty nie czytałem, ale tu mi się błąd rzucił tylko.

faktycznie tak było oryginalnie w jakimś z przykładów i tej opcji inicjalnie próbowałem też (bez powodzenia), tutaj to webapi bezpośrednio wynika z moich prób..

Dodaj jeszcze przy tym server protokół czyli te server http://webapi; Jeśli nginx się wyświetla strona z zewnętrznego ip to powinno działać reszta.

Taka próba kończy się następującym logiem w podzie apki i failem jego wdrożenia:

nginx: [emerg] invalid host in upstream "http://webapi" in /etc/nginx/nginx.conf:65

W przykładzie z Internetu było bez http://

Może trzeba było sam port podać server webapi:80; sam nie pamiętam, ale port raczej wymagany bo nie ma defaultów chyba w nginx, a musi jakoś odróżnić pod jaki przekierować. Ja ostatnio stawiałem nginxa powinno przekierować bez problemu, tzn u mnie nie było.

Może mógłbym sprawdzić czy moja zmiana w konfigu nginxa w ogóle się aplikuje. Można jakoś przekierować z każdej ścieżki z EXTERNAL_IP do np google.com?
ps wdrażam na AKSie, jeśli to może mieć znaczenie.
Sam plik konfiga nadpisuję tak (mój plik posiada domyslną zawartość z oryginalnego configa + moje zmiany): COPY nginx.conf /etc/nginx/nginx.conf

w sumie skoro dostaję ten błąd przy dodaniu http:// to znaczy, że to się aplikuje w przypadku poprawnej konfiguracji. STATUS: http://EXTERNAL_IP/api/weatherforecast - 404

Patrzę w jakiś projekt co miałem na dysku i mam tak:

worker_processes 1;

events {
  worker_connections 1024;
}

http {

  upstream backend {
    server webapi:80;
  }

  server {
    listen 80;
    server_name localhost;

    location / {
      proxy_pass http://backend;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
  }
}

I plik kopiuję do
Dockerfile

FROM nginx
COPY nginx.conf /etc/nginx

Po dodaniu :80 przy server webapi + dodaniu dwóch headerów który Ty masz dodane - wciąż http://EXTERNAL_IP/api/weatherforecast - 404

W takim razie to musi być problem wyżej gdzieś w kubernetesie jest źle bridge czy coś ustawione, a możesz jakiś hello world wyświetlić bez twojego backendu? A może sam backend ma jakiś błąd? staw jakiś prosty web serwer typu python -m http.server podstaw jako localhost w nginx. A konfig kubernetesa generowałeś z dockerafile? czy ręcznie?

Opierałem się częściowo na tym: https://learn.microsoft.com/en-us/dotnet/architecture/containerized-lifecycle/design-develop-containerized-apps/build-aspnet-core-applications-linux-containers-aks-kubernetes ale frontend u mnie stoi na nginxie, stąd potrzeba przekierowania w nginxie.
Nie wiem za bardzo jak sprawdzić i czym jest bridge (domyślnie w klastrze z AKSa mogło by być źle ustawione?)
Widziałem też przykład tego jak w location jest /api zamiast / (jak k8s rozumie że na EXTERNAL_IP/ ma serwować frontend a np EXTERNAL_IP/api backend?

Czy ktoś ma może jeszcze jakiś pomysł?
Zastanawiam się jak to docelowo powinno wyglądać by działało, tj,

chcę mieć możliwość routowania requestów dla EXTERNAL_IP/**api**/... do serwisu backendowego, a jakiekolwiek inne ścieżki powinny aplikować się do serwisu frontendowego np EXTERNAL_IP/sciezka_do_jakiegos_widoku.

Zastanawiam się jak mogło by to być osiągnięte konfiguracją nginxa, gdzie samo location / proxy_pass nie jest chyba w stanie obsłużyć takiego scenariusza jaki chcę zaimplementować. prawda?

Czekaj ty masz źle zrobione, chcesz mieć pod / frontend i pod /api backend? bo ja ci podałem, że api było pod / normalnie. To musisz dodać nowe

location / { }

i

location /api { }

ok, ale w aktualnej wersji w takim razie /api/weatherforecast powinno dzialac tak? i jednoczesnie samo / nie powinno poprawnie zwracać mi frontendu, jak w tej chwili skoro przekierowuje caly ruch / na backend?

@Autysta wracam z aktualizacją:
okazuje się, że powodem tego, że te proxy_pass nie działały było to, że jak napisałem mój nginx.config, którym nadpisuję oryginalny (tj. ten który jest defaultowo na serwerze po użyciu:

RUN apt-get install nginx -y
...
CMD ["nginx","-g","daemon off;"]

)
jest połączeniem zawartości oryginalnego + moja sekcja z location / i proxy_pass:
w wersji z obrazka location .. proxy_pass nie działa w ogóle, na EXTERNAL_IP/ mam aplikację frontendową która jest budowana Dockerfilem:
w momencie kiedy zakomentuję te dwie oznaczone linijki w nginx.config, wtedy przekierowywanie na backend zaczyna działać poprawnie, jednak
tracę funkcjonalność możliwości dostępu do aplikacji UI, która wcześniej (przed zakomentowaniem tych linijek) działała poprawnie.

Jak widać mam dwie konfiguracje w której w
1 działa tylko dostęp do frontendu
2 działa tylko dostęp do backend

Pytanie tylko jak połączyć te dwie funkcje, abym na adresie
EXTERNAL_IP/api/** przekierowywał requesty do backendu,
a wszelkich innych ścieżek do frontendu (czyli apka reactowa w tym przypadku z całym routingiem)

Już wszystko jasne, problemem był include sites-enabled, potrzebowałem mixa z jego zawartości + moich zmian w nginx.config w taki sposób by fe i be były dobrze przekierowywane.

Ogólnie tam źle po konfigurowałeś z tego ostatniego zdjęcia, jeśli frontend masz jak SPA, to możesz nginx możesz pod

worker_processes 1;               
                                  
events {                          
  worker_connections 1024;        
}                                 
                                  
http {                              
  server {
    listen 80;
  
    location /api/ {
      proxy_pass http://restapi:8080;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
  
    location / {
      root /usr/share/nginx/html;
      # index index.html index.htm index.php;
    }
  }
}

I teraz jak miałeś normalnie adres,
backend/api/weather
To external_ip/api/weather da ci tą pogodę z backendu.
Wszystko co będzie zaczynać się z external_ip/api to tam przekieruje.
A jak zrobisz external_ip/, to dostaniesz statyczny plik index.html, który jest w lokalizacji /usr/share/nginx/html;

Ewentualnie zamiast root i ścieżka do statycznych plików, możesz też dać takie same proxy jak przy backend, ale pod frontend, który to on będzie zajmował się static file serving.
Backend będzie działał tylko jeśli zaczyna się przy /api/ ścieżce

Kolejny problem to jak zbudujesz obrazy i potem wyedytujesz pliki to musisz od nowa zbudować, bo może ci poprzednio zbudowany użyć z repozytorium.

I jak korzystasz ze standardowej konfiguracji z nginx to ona ci może nadpisywać twoje ustawienia.
Więc musisz uwzględnić zawartość tych wszystkich innych plików co includujesz, po prostu możesz je otworzyć i zobaczyć jakie ustawienia są tam.

Sprawdzałem jeszcze raz sobie na nginx, z reactem i restapi w springu i adresy w springu miałem /api/costam /api/cosinnego, wszystko śmigało i pod / miałem statyczne pliki z reactem.

A ty tam na twoim obrazku źle ustawiłeś bo napisałeś location /some/path a to nie może być losowy, a taki sam początek jaki jest w backend, czyli powinno być location /api