Ruch między kontenerami na odpowiednim porcie

0

Mam utworzony poniższy plik yml:

version: "3"
services:
  backend:
    tty: true
    build:
      context: .
    #dockerfile: ./Dockerfile
    image: rejestr_wylegow:1.0
    container_name: rejestrwylegowapi
    working_dir: /Backend
    command: dotnet "WebAPI.dll"
    ports:
     - "5000:80"
    networks:
      - siec

  webapp:
    tty: true
    build:
     context: .
    image:  rejestr_wylegow:1.0
    environment:
      - LANG=en_DK.UTF-8
      - LC_TIME=en_DK.UTF-8
    container_name: rejestrwylegowapp
    working_dir: /Fronted
    command: dotnet "Rejestr Wylegow NET.dll"
    ports:
     - "5001:80"
    networks:
      - siec

networks:
  siec:

Problem polega na tym że pomimo wystawienia backendu na porcie 5000 to i tak komunikacja pomiędzy frontendem a backandem działa tylko na porcie 80

0

Pokaż docker file.

0
S4t napisał(a):

Pokaż docker file.


FROM asp_net_core:6.0
WORKDIR /Fronted
COPY /Fronted/ ./
WORKDIR /Backend
COPY /Backend/ ./

3
virusek391 napisał(a):

...

Problem polega na tym że pomimo wystawienia backendu na porcie 5000 to i tak komunikacja pomiędzy frontendem a backandem działa tylko na porcie 80

Problem chyba polega na opisaniu co chcesz osiągnąć.

Zgodnie z konfiguracją wklejoną:

  • podnosisz 2 kontenery: rejestrwylegowapp + rejestrwylegowapi
  • tworzysz bridge (domyślny driver dla konfiguracji networks)
  • porty z kontenerów mapujesz na porty hosta:
    a) backend -> host:5000
    b) webapp -> host:5001

Ruch, który przyjdzie do hosta na port 5001 zostanie przekierowany do kontenera w którym działa webapp i zostanie przekierowany na port 80 w ramach kontenera webapp (i w ramach bridgea)

I teraz tak, pisząc, że "komunikacja pomiędzy frontendem a backandem działa tylko na porcie 80", masz na myśli, że frontend strzela (po utworzonym bridge) na port 80 backendu?

Jeśli tak, to ta konfiguracja musi być gdzieś zaszyta na frontendzie i backendze. Nie znam się na .NET, ale google mówi, że dla klienta (frontendu) w .NET tworzysz HttpClienta, któremu wskazujesz URLa na który ma się łączyć. Dla sewera również wskazujsz (tu google mówi, że w .NET jest jakiś Kestrel, którego konfigurację możesz zmieniać przez appsettings.json albo bezpośrednio w kodzie).

Zakładając, że konfigurację klienta i serwera masz w jakichś plikach appsettings.json, to można by użyć dockerowego volumenu, tak by nadpisać takie pliki w ramach kontenera.

image: rejestr_wylegow:1.0
 volumes:
      - ./sciezka/na/hoscie/gdzie/masz/custom/appsettings.json:/sciezka/w/konenerze/gdzie/sa/domyslne/appsettings.json
2

Przy tej konfiguracji twoje WebApi powinno nasłuchiwać na porcie 80 (jeżeli niczego nie skonfigurujesz dodatkowo to domyślny template .net webapi będzie nasłuchiwał właśnie na porcie 80 w release mode), a front powinien uderzać do backendu przez http://localhost:5000/

5000 to port hosta, 80 to port wewnątrz kontenera.

0

@Inclouds: Ok, dzięki :)

@yarel: Ok, dzięki :)

0
yarel napisał(a):
virusek391 napisał(a):

...

Problem polega na tym że pomimo wystawienia backendu na porcie 5000 to i tak komunikacja pomiędzy frontendem a backandem działa tylko na porcie 80

Problem chyba polega na opisaniu co chcesz osiągnąć.

Zgodnie z konfiguracją wklejoną:

  • podnosisz 2 kontenery: rejestrwylegowapp + rejestrwylegowapi
  • tworzysz bridge (domyślny driver dla konfiguracji networks)
  • porty z kontenerów mapujesz na porty hosta:
    a) backend -> host:5000
    b) webapp -> host:5001

Ruch, który przyjdzie do hosta na port 5001 zostanie przekierowany do kontenera w którym działa webapp i zostanie przekierowany na port 80 w ramach kontenera webapp (i w ramach bridgea)

I teraz tak, pisząc, że "komunikacja pomiędzy frontendem a backandem działa tylko na porcie 80", masz na myśli, że frontend strzela (po utworzonym bridge) na port 80 backendu?

Jeśli tak, to ta konfiguracja musi być gdzieś zaszyta na frontendzie i backendze. Nie znam się na .NET, ale google mówi, że dla klienta (frontendu) w .NET tworzysz HttpClienta, któremu wskazujesz URLa na który ma się łączyć. Dla sewera również wskazujsz (tu google mówi, że w .NET jest jakiś Kestrel, którego konfigurację możesz zmieniać przez appsettings.json albo bezpośrednio w kodzie).

Zakładając, że konfigurację klienta i serwera masz w jakichś plikach appsettings.json, to można by użyć dockerowego volumenu, tak by nadpisać takie pliki w ramach kontenera.

image: rejestr_wylegow:1.0
 volumes:
      - ./sciezka/na/hoscie/gdzie/masz/custom/appsettings.json:/sciezka/w/konenerze/gdzie/sa/domyslne/appsettings.json

OK dzięki. Moim błędem było to że chciałem ustawić własny port do komunikacji pomiędzy kontenerami, ale to już mi ładnie wyjaśniłeś że tak to nie działa :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1