Mam dwa osobne docker-compose.ymlpliki w dwóch różnych folderach:

• ~/front/docker-compose.yml
• ~/api/docker-compose.yml

Jak mogę się upewnić, że kontener w frontmoże wysyłać żądania do kontenera w api?

Wiem, że tę --default-gatewayopcję można ustawić za pomocą docker rundla pojedynczego kontenera, dzięki czemu można przypisać określony adres IP do tego kontenera, ale wydaje się, że ta opcja nie jest dostępna podczas korzystania docker-compose.

Obecnie kończę docker inspect my_api_container_idi patrzę na bramę w danych wyjściowych. Działa, ale problem polega na tym, że to IP jest losowo przypisywane, więc nie mogę na nim polegać.

Inną formą tego pytania może być zatem:

• Czy mogę przypisać stały adres IP do konkretnego kontenera przy użyciu funkcji dokowania-tworzenia?

Ale w końcu to, na czym mi zależy:

• W jaki sposób dwa różne projekty dokowania mogą się ze sobą komunikować?

Musisz tylko upewnić się, że kontenery, z którymi chcesz rozmawiać, znajdują się w tej samej sieci. Sieci są pierwszorzędną konstrukcją dokującą i nie są specyficzne do tworzenia.

# front/docker-compose.yml
version: '2'
services:
  front:
    ...
    networks:
      - some-net
networks:
  some-net:
    driver: bridge

...

# api/docker-compose.yml
version: '2'
services:
  api:
    ...
    networks:
      - front_some-net
networks:
  front_some-net:
    external: true

Uwaga: sieć Twoja aplikacja jest nadać nazwę opartą na „Nazwa projektu”, która oparta jest na nazwie katalogu Zamieszkuje w tym przypadku prefiks front_został dodany

Następnie mogą rozmawiać ze sobą przy użyciu nazwy usługi. Od frontmożna zrobić ping apii vice versa.

Tylko małe przyzwolenie na świetną odpowiedź @ johnharris85, kiedy uruchamiasz plik komponowania dokera, defaulttworzona jest sieć „ ”, dzięki czemu możesz po prostu dodać go do innego pliku tworzenia jako sieć zewnętrzna:

# front/docker-compose.yml 
version: '2' 
  services:   
    front_service:
    ...

...

# api/docker-compose.yml
version: '2'
services:
  api_service:
    ...
    networks:
      - front_default
networks:
  front_default:
    external: true

Dla mnie to podejście było bardziej odpowiednie, ponieważ nie posiadałem pierwszego pliku skomponowanego w oknie dokowanym i chciałem się z nim komunikować.

AKTUALIZACJA: Od momentu skomponowania pliku w wersji 3.5:

To teraz działa:

version: "3.5"
services:
  proxy:
    image: hello-world
    ports:
      - "80:80"
    networks:
      - proxynet

networks:
  proxynet:
    name: custom_network

docker-compose up -ddołączy do sieci o nazwie „custom_network”. Jeśli nie istnieje, zostanie utworzony!

root@ubuntu-s-1vcpu-1gb-tor1-01:~# docker-compose up -d
Creating network "custom_network" with the default driver
Creating root_proxy_1 ... done

Teraz możesz to zrobić:

version: "2"
services:
  web:
    image: hello-world
    networks:
      - my-proxy-net
networks:
  my-proxy-net:
    external:
      name: custom_network

Spowoduje to utworzenie kontenera, który będzie w sieci zewnętrznej.

Nie mogę znaleźć żadnego odniesienia w dokumentacji, ale działa!

Wszystkie kontenery z apimogą dołączyć do front domyślnej sieci z następującą konfiguracją:

# api/docker-compose.yml

...

networks:
  default:
    external:
      name: front_default

Zobacz przewodnik tworzenia dokerów: za pomocą istniejącej sieci (patrz na dole)

Informacje z poprzednich postów są poprawne, ale nie zawierają szczegółowych informacji na temat łączenia kontenerów, które powinny być połączone jako „external_links”.

Mam nadzieję, że ten przykład wyjaśni ci:

• Załóżmy, że masz app1 / docker-compose.yml z dwiema usługami (svc11 i svc12) oraz app2 / docker-compose.yml z dwoma dodatkowymi usługami (svc21 i svc22) i załóżmy, że musisz połączyć się w sposób krzyżowy:

• svc11 musi połączyć się z kontenerem svc22

• svc21 musi połączyć się z kontenerem svc11.

Konfiguracja powinna wyglądać następująco:

to jest app1 / docker-compose.yml:

version: '2'
services:
    svc11:
        container_name: container11
        [..]
        networks:
            - default # this network
            - app2_default # external network
        external_links:
            - container22:container22
        [..]
    svc12:
       container_name: container12
       [..]

networks:
    default: # this network (app1)
        driver: bridge
    app2_default: # external network (app2)
        external: true

to jest app2 / docker-compose.yml:

version: '2'
services:
    svc21:
        container_name: container21
        [..]
        networks:
            - default # this network (app2)
            - app1_default # external network (app1)
        external_links:
            - container11:container11
        [..]
    svc22:
       container_name: container22
       [..]

networks:
    default: # this network (app2)
        driver: bridge
    app1_default: # external network (app1)
        external: true

Od wersji Compose 1.18 (specyfikacja 3.5) możesz po prostu zastąpić domyślną sieć, używając własnej niestandardowej nazwy dla wszystkich potrzebnych plików Compose YAML. Jest to tak proste, jak dodanie do nich następujących elementów:

networks:
  default:
    name: my-app

Powyżej zakłada się, że versionustawiłeś 3.5(lub wyżej, jeśli nie będą one zastępować w 4+).

Inne odpowiedzi wskazują na to samo; to jest uproszczone podsumowanie.

Chciałbym upewnić się, że wszystkie kontenery są docker-composepodłączone do tej samej sieci, tworząc je razem w tym samym czasie, używając:

docker compose --file ~/front/docker-compose.yml --file ~/api/docker-compose.yml up -d

AKTUALIZACJA: Od momentu skomponowania pliku w wersji 3.5:

Natknąłem się na podobny problem i rozwiązałem go, dodając niewielką zmianę w jednym z moich projektów docker-compose.yml.

Na przykład mamy dwa API scoringi ner. ScoringInterfejs API musi wysłać do nerinterfejsu API żądanie przetworzenia żądania wejściowego. Aby to zrobić, oboje powinni dzielić tę samą sieć.

Uwaga: każdy kontener ma własną sieć, która jest automatycznie tworzona w momencie uruchomienia aplikacji w oknie dokowanym. Na przykład zostanie utworzona sieć ner api jak ner_defaulti sieć oceniająca api zostanie nazwana jako scoring default. To rozwiązanie będzie działać dla wersji: „3”.

Jak w powyższym scenariuszu mój punktacyjny interfejs API chce komunikować się z interfejsem Ner API, więc dodam następujące wiersze. Co oznacza, że ​​ilekroć tworzę kontener dla interfejsu API, to automatycznie dodaje się do sieci scoring_default.

networks:
  default:
      external:
        name: scoring_default

ner / docker-compose.yml

version: '3'
services:
  ner:
    build: .
    ...

networks:
  default:
      external:
        name: scoring_default

scoreing / docker-compose.yml

version: '3'
services:
  api:
    build: .
    ...

Widzimy to, jak powyższe kontenery są teraz częścią tej samej sieci nazywanej scoring_defaultza pomocą polecenia:

doker sprawdza punktację domyślną

{
    "Name": "scoring_default",
        ....
    "Containers": {
    "14a6...28bf": {
        "Name": "ner_api",
        "EndpointID": "83b7...d6291",
        "MacAddress": "0....",
        "IPv4Address": "0.0....",
        "IPv6Address": ""
    },
    "7b32...90d1": {
        "Name": "scoring_api",
        "EndpointID": "311...280d",
        "MacAddress": "0.....3",
        "IPv4Address": "1...0",
        "IPv6Address": ""
    },
    ...
}

Możesz dodać .envplik do wszystkich swoich projektów zawierających COMPOSE_PROJECT_NAME=somename.

COMPOSE_PROJECT_NAME przesłania prefiks używany do nazywania zasobów, ponieważ wszystkie twoje projekty będą używać somename_defaultich sieci, dzięki czemu usługi mogą komunikować się ze sobą, tak jak były w tym samym projekcie.

Uwaga: Otrzymasz ostrzeżenia dla „osieroconych” kontenerów utworzonych z innych projektów.

version: '2'
services:
  bot:
    build: .
    volumes:
      - '.:/home/node'
      - /home/node/node_modules
    networks:
      - my-rede
    mem_limit: 100m
    memswap_limit: 100m
    cpu_quota: 25000
    container_name: 236948199393329152_585042339404185600_bot
    command: node index.js
    environment:
      NODE_ENV: production
networks:
  my-rede:
    external:
      name: name_rede_externa

Aby użyć innej sieci składającej się z dokerów, wystarczy wykonać następujące czynności (aby udostępnić sieci między kompozycjami dokerów):

1. Uruchom pierwszy projekt skomponowania dokera przez up -d
2. Znajdź nazwę sieci pierwszego skomponowanego okna dokowanego przez: docker network ls(Zawiera nazwę projektu katalogu głównego)
3. Następnie użyj tej nazwy według tej struktury poniżej w drugim pliku tworzenia dokerów.

drugi docker-compose.yml

version: '3'
services:
  service-on-second-compose:  # Define any names that you want.
    .
    .
    .
    networks:
      - <put it here(the network name that comes from "docker network ls")>

networks:
  - <put it here(the network name that comes from "docker network ls")>:
    external: true

Inną opcją jest po prostu uruchomienie pierwszego modułu za pomocą funkcji „docker-compose”, sprawdzenie adresu IP powiązanego z modułem i połączenie drugiego modułu z poprzednią siecią, jak zewnętrzny, i skierowanie wewnętrznego adresu IP

przykład app1 - nowa sieć utworzona w liniach serwisowych, oznacz jako zewnętrzny: prawda na dole app2 - wskaż „nową sieć” utworzoną przez app1, gdy idzie w górę, zaznacz jako zewnętrzny: prawda na dole i ustaw w konfiguracji do połączenia, ip, które aplikacja1 ma w tej sieci.

Dzięki temu powinieneś być w stanie ze sobą rozmawiać

* ten sposób służy wyłącznie do testowania lokalnego, aby nie robić zbyt skomplikowanej konfiguracji ** Wiem, że jest to bardzo łatwa metoda, ale działa dla mnie i myślę, że jest tak prosta, że ​​inni mogą z tego skorzystać

Jeśli jesteś

• próbuje komunikować się między dwoma kontenerami z różnych projektów tworzących dokery i nie chce korzystać z tej samej sieci (ponieważ powiedzmy, że miałyby kontener PostgreSQL lub Redis na tym samym porcie i wolisz nie zmieniać tych portów i nie używać ich w tej samej sieci)
• rozwijają się lokalnie i chcą naśladować komunikację między dwoma projektami komponowania dokerów
• uruchamianie dwóch projektów tworzenia dokerów na localhost
• tworzenie aplikacji Django lub API Django Rest Framework (drf) i uruchamianie aplikacji w kontenerze na niektórych odsłoniętych portach
• uzyskiwanie Connection refusedpodczas próby komunikacji między dwoma kontenerami

A ty chcesz

• kontener api_akomunikuje się z api_b(lub odwrotnie) bez tej samej „sieci dokerów”

(przykład poniżej)

możesz użyć „hosta” drugiego kontenera jako adresu IP komputera i portu odwzorowanego z wnętrza kontenera Docker. Możesz uzyskać adres IP swojego komputera za pomocą tego skryptu (z: Znajdowanie lokalnych adresów IP za pomocą stdlib Pythona ):

import socket
def get_ip():
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    try:
        # doesn't even have to be reachable
        s.connect(('10.255.255.255', 1))
        IP = s.getsockname()[0]
    except:
        IP = '127.0.0.1'
    finally:
        s.close()
    return IP

Przykład:

project_api_a/docker-compose.yml:

networks:
  app-tier:
    driver: bridge

services:
  api:
    container_name: api_a
    image: api_a:latest
    depends_on:
      - postgresql
    networks:
      - app-tier

wewnątrz api_akontenera uruchomiona jest aplikacja Django: manage.py runserver 0.0.0.0:8000

i drugi docker-compose.yml z innego projektu:

project_api_b/docker-compose-yml :

networks:
  app-tier:
    driver: bridge

services:
  api:
    container_name: api_b
    image: api_b:latest
    depends_on:
      - postgresql
    networks:
      - app-tier

wewnątrz api_bkontenera uruchomiona jest aplikacja Django: manage.py runserver 0.0.0.0:8001

I próba połączenia z kontenera api_ado api_badresu URL api_bkontenera będzie: http://<get_ip_from_script_above>:8001/

Może być szczególnie cenny, jeśli używasz nawet więcej niż dwóch (trzech lub więcej) projektów dokowania i trudno jest zapewnić wspólną sieć dla wszystkich - jest to dobre obejście i rozwiązanie