No hay ruta al host dentro del contenedor acoplable


8

Estoy ejecutando un contenedor de Docker de Debian en una máquina con Windows 10 que necesita acceder a una URL particular en el puerto 9000 ( 164.16.240.30:9000)

La máquina host puede acceder bien a través del navegador, sin embargo, cuando inicio sesión en el terminal y ejecuto wget 172.17.240.30:9000, obtengo failed: No route to host.

En un intento de resolver esto, agregué:

ports:
  - 9000:9000

al archivo docker-compose.yml, sin embargo, eso no parece haber hecho ninguna diferencia.

En caso de que no puedas adivinar que soy nuevo en esto, ¿qué probarías después?

Todo el archivo docker-compose.yml:

version: '3.4'

services:
  tokengeneratorapi:
    network_mode: host
    image: ${DOCKER_REGISTRY}tokengeneratorapi
    build:
      context: .
      dockerfile: TokenGeneratorApi/Dockerfile
    ports:
      - 5000:80
      - 9000
    environment:
      ASPNETCORE_ENVIRONMENT: local
      SSM_PATH: /ic/env1/tokengeneratorapi/
      AWS_ACCESS_KEY_ID: 
      AWS_SECRET_ACCESS_KEY: 

Comando que estoy ejecutando:

docker-compose build --build-arg BRANCH=featuretest --build-arg CHANGE_ID=99 --build-arg CHANGE_TARGET=develop --build-arg SONAR_SERVER=164.16.240.30

Intente simular el navegador a través de wget, como stackoverflow.com/questions/43182879/using-wget-to-fake-browser Puede ser un firewall que corta la conexión. Intente también deshabilitar ufw ( wiki.debian.org/Uncomplicated%20Firewall%20%28ufw%29 ): "sudo service ufw stop" si está instalado y habilitado.
Jannes Botis

1
Su contenedor necesita acceso 164.16.240.30:9000, que no se está ejecutando en su máquina. Su navegador tiene acceso a este 164.16.240.30:9000recurso, pero el contenedor no. Estoy en lo cierto? ¿Por qué estás intentando obtener recursos diferentes 172.17.240.30:9000del terminal y no 164.16.240.30:9000?
Jan Garaj

Verifique que no tenga entradas proxy en su archivo ~ / .wgetrc.
Gautam

Por lo que yo entiendo, tokengeneratorapi envía solicitudes a algún servidor sonar. Es esto correcto ? ¿Estamos seguros de que tokengeneratorapi reenvía correctamente al puerto 9000? El siguiente paso puede ser iniciar sesión en su contenedor y apuntar con get o curl the sonar server: 9000. Y si está bien, apunte a su "aplicación" tokengeneratorapi como 127.0.0.1:9000 y asegúrese de que se envíe correctamente (todavía dentro del contenedor)
grodzi

Todavía no está claro sobre su problema, ¿está diciendo que 'desde el contenedor no puede acceder a 164.16.240.30:9000? Cuando dices I log in to the terminal and run¿estás dentro del contenedor? y por qué está usando una IP diferente 172.17.240.30 vs 164.16.240.30
Vikrant Pawar

Respuestas:


1

Parece que el contenedor tiene problemas de conectividad, por lo que es probable que la solución propuesta no funcione, ya que eso solo asigna un puerto de host a un puerto de contenedor (teniendo en cuenta que su URL de destino no es el host real).

Consulte https://docs.docker.com/compose/compose-file/#network_mode e intente configurarlo como host.


Intenté esto en vano, por favor vea la pregunta actualizada
m.edmondson

Para agregar a esto, parece que 'host' no funciona en un host que no sea de Linux docs.docker.com/network/network-tutorial-host
m.edmondson

Buena captura, mis disculpas por eso! ¿Podría verificar que no es un problema de firewall? El firewall debe permitir conexiones desde los contenedores acoplables a través del host.
agermain

No estoy seguro de cómo haría eso, ya que el host es Windows 10. Además, las conexiones a Internet funcionan, por ejemplo, wget www.google.co.ukdevuelve 200. Tal vez esto sea una cosa de Linux, ¿iptables quizás?
m.edmondson

¿Estás detrás de un proxy de la empresa? Tratar docker network prune. Además, ¿en qué se basa la imagen?
agermain

1

Su navegador tiene acceso 164.16.240.30:9000, ya que está pasando por un proxy (entorno empresarial típico), por lo que también the proxytiene conectividad de red 164.16.240.30. No significa que también su host tenga la misma conectividad de red. En realidad, parece que tu host no tiene ese. Esa es la razón por la cual wget directo desde el contenedor o desde la terminal tiene un error No route to host.

Todo debe pasar por el proxy. Intente configurar el proxy correctamente: las aplicaciones de Linux usan variables de entorno http_proxy,https_proxygeneralmente, pero las aplicaciones pueden tener su propia opción para configurar el proxy, eventualmente puede configurarlo en el nivel del código fuente. Depende de la aplicación / código utilizado.


1

Creo que el problema es que utiliza el modo host en su archivo de configuración de composición de Docker y ¿tiene permitido el firewall IPTABLES para los puertos en la máquina Debian? ¿Qué hay de las ventanas?

network_mode: host 

que en realidad pasa por alto el puente acoplable por completo, por lo que no se aplica la sección de puertos que especifique. Todos los puertos se abrirán en el sistema host. Puedes consultar con

nestat -tunlp | grep 5000

Y verá que el puerto 5000 no está abierto y asignado a los 80 del acoplador como era de esperar. Sin embargo, los puertos 80 y 9000 deberían estar abiertos en la red de Debian pero no estar unidos a ningún puente acoplable solo a la IP de Debian.

Desde aquí: https://docs.docker.com/network/host/

ADVERTENCIA: los puertos publicados se descartan cuando se utiliza el modo de red host

Como solución podría ser eliminar la línea network_mode y funcionará como se esperaba.


0

Su código no permite el acceso a su contenedor 164.16.240.30:9000. Debería wget 164.16.240.30:9000desde la terminal en lugar de 172.17.240.30:9000.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.