Używanie sieci hosta i dodatkowych sieci w oknie dokowanym do komponowania

Question

Próbuję skonfigurować środowisko dev dla mojego projektu.

Mam kontener (ms1), który powinien być umieszczony w jego własnej sieci ("usługi" w moim przypadku), oraz kontener (apigateway), który powinien uzyskać dostęp do tej sieci podczas wystawiania portu http do sieci hosta.

Idealnie komponuje doker mój plik będzie wyglądać następująco:

version: '2' 
services: 
    ms1: 
     expose: 
      - "13010" 
     networks: 
      services: 
       aliases: 
        - ms1 
    apigateway: 
     networks: 
      services: 
       aliases: 
        - api 
     network_mode: "host" 
networks: 
    services: 

doker-komponować nie pozwala używać network_mode i sieci jednocześnie.

Czy mam inne możliwości?

Obecnie używam to:

apigateway: 
     networks: 
      services: 
       aliases: 
        - api 
     ports: 
      - "127.0.0.1:10000:13010" 

a następnie apigateway pojemnik nasłuchuje na 0.0.0.0:13010. Działa, ale działa wolno i zawiesza się, jeśli połączenie z Internetem hosta zostanie przerwane.

Ponadto, zamierzam użyć vagrant w przyszłości na docker, czy pozwala to rozwiązać w czysty sposób?

Answer 1

chciałbym spróbować to:

1/Znajdź sieć hosta docker network ls

2/do tego pliku dockercompose

 services: 
      ms1: 
       ports: 
        - "13010" 
       networks: 
        - service 
      apigateway: 
       networks: 
        - front 
        - service 

     networks: 
      front: 
      service: 
       external: 
        name: "<ID of the network>" 

Answer 2

W dokowanym 1.13 powinieneś być w stanie stworzyć usługę most między dwiema sieciami. Używam coś podobnego naprawić another problem i myślę, że może to również pomóc tutaj:

docker service create \ 
--name proxy \ 
--network proxy \ 
--publish mode=host,target=80,published=80 \ 
--publish mode=host,target=443,published=443 \ 
--constraint 'node.hostname == myproxynode' \ 
--replicas 1 \ 
letsnginx 

Answer 3

expose w dokowanym-komponować does not publish the port on the host. Ponieważ prawdopodobnie nie potrzebujesz już połączenia z usługami (zamiast tego powinieneś polegać na sieciach Docker, tak jak to już robisz), opcja ma ogólnie ograniczoną wartość i wydaje się, że nie dostarcza ona żadnej wartości w twoim scenariuszu.

I podejrzany Trafiłeś używając go przez pomyłkę, a po sobie sprawę, że nie wydaje się mieć żadnego wpływu przez siebie, natknęliśmy się na tym, że za pomocą sterownika sieciowego gospodarz „sprawiają, że działa”. To nie miało nic wspólnego z własnością expose, pamiętajcie. Chodzi o to, że sterownik sieciowej hosta pozwala zawartym procesom powiązać się bezpośrednio z interfejsem sieciowym hosta. Dzięki temu możesz dotrzeć do procesu bramy API z zewnątrz. Możesz usunąć właściwość expose i nadal będzie działać.

Jeśli jest to jedyny powód, dla którego wybraliśmy sterownika sieciowego hosta, a następnie upadłeś ofiarą X-Y problem:

(tl; dr) Nigdy nie ma potrzeby korzystania ze sterownika sieciowego hosta w normalnych sytuacjach domyślny sterownik sieci mostkowej działa dobrze. To, czego szukasz, to własność ports, a nie expose. To ustawia odpowiednie przekazywanie portów za kulisami.