¿Encontraste ip en virtualbox o en el host?

Creo que el docker0 estaba en la máquina virtual virtualbox.

Estoy hablando de Docker para Mac que está en beta y no funciona a través de una máquina virtual.

También estoy enfrentando exactamente el mismo problema. Se encontró la dirección IP del host en la máquina acoplable usando el siguiente comando. Suponiendo que 0.0.0.0 represente al host, corríjame si me equivoco aquí.
netstat -nr | grep '^ 0.0.0.0' | awk '{imprimir $ 2}'
172.17.0.1

pero cuando hago rizo en esta ip con un puerto donde estoy ejecutando un servidor web, da conexión rechazada.
rizo 172.17.0.1:9000
curl: (7) No se pudo conectar al puerto 172.17.0.1 9000: Conexión rechazada

No estoy seguro de cómo obtener la solución adecuada. Esto parece estar dando problemas, ya que es necesario conectarse al servicio que se ejecutará en la máquina host.
También encontré una manera de arreglar la dirección IP de la máquina host configurándola en DOCKER_OPTS.
DOCKER_OPTS = "- H tcp: //0.0.0.0 : 5000 -H unix: ///var/run/docker.sock --bip = 172.17.42.1 / 16"

pero ¿dónde en mac puedo poner estas opciones? en ubuntu se puede colocar en / etc / default / docker.

Proporcione instrucciones si esto se puede solucionar en mac.

ping @justincormack tal vez tenga algunas sugerencias aquí.

@MiteshSharma exactamente, esa es una de las primeras cosas que probé también y con exactamente los mismos problemas

@NinoFloris Parece que ambos estamos exactamente en el mismo lugar. En mi caso, estoy ejecutando mysql en mi máquina host.
Hola chicos,
Actualice si alguien puede hacer esto.

Usé esto
https://docs.docker.com/engine/installation/mac/

no estoy seguro si tu beta es especial

@HackToday eso es diferente, esa es la instalación de Mac basada en VirtualBox; Docker para Mac está en beta.docker.com

Gracias @thaJeztah ¿ Algún enlace de documento bueno posible para la arquitectura Mac Docker relacionada o algo más detalles? Parece interesante

@HackToday https://blog.docker.com/2016/03/docker-for-mac-windows-beta/ da un poco más, y hay documentación, pero creo que es solo si estás en la versión beta; https://beta.docker.com/docs/. Si te registras en la beta, entonces dame un "ping"; Puedo intentar colocarte en la lista de prioridades como colaborador: sonríe:

oh @thaJeztah Gracias, pensé que era gratis trabajar y probar. No necesita ningún especial para contribuir. Leeré ese blog primero para entenderlo antes de intentarlo. 😺

@HackToday es completamente gratis, solo para no abrumar al equipo, se decidió lanzarlo como una versión beta "privada" primero, porque "muchos usuarios '===" muchas preguntas de soporte ": sonrisa:

Hola, sí, actualmente no hay una forma de enrutar desde la Mac al puente docker0 . Es posible que podamos agregar esto más adelante, pero generalmente le recomendamos que se conecte desde un contenedor o exponiendo puertos. Esto es lo mismo que con las redes de superposición de Docker también en Linux, a las que no puede conectarse desde el host.

Bueno, no es realmente satisfactorio, ya que las Mac no suelen ser servidores de producción, sino
dev máquinas.

En mis máquinas de producción no me importa el problema de no poder
conectarse al host.

Pero en una máquina de desarrollo que se conecta a servicios en el mismo host desde dentro de un
contenedor es exactamente el escenario donde se desea esta funcionalidad el
más.

También necesito esta interfaz docker0 para usarla en un entorno mixto "docker + en el host (desde IDE) en ejecución".

La mejor solución actual es conectarse a sus contenedores desde otro contenedor. En la actualidad, no hay forma de que podamos proporcionar enrutamiento a estos contenedores debido a problemas con OSX que Apple aún no ha resuelto. estamos realizando un seguimiento de este requisito, pero no podemos hacer nada al respecto en este momento.

¿Es correcto el comentario anterior?

Descubrí que, desde dentro de los contenedores docker-for-mac-beta, el host de la ventana acoplable se podía encontrar y conectar en la dirección 172.17.0.1 habitual (asumiendo que el servicio está vinculado a 0.0.0.0 ).

@igrayson Esto se debe a que los contenedores están en la VM con el demonio de la ventana acoplable y ciertamente pueden acceder a él.
El problema es el enrutamiento de OSX a la red de VM.

El problema es el enrutamiento de OSX a la red de VM.

Ese no es mi entendimiento del problema de OP:

Me gustaría poder conectarme a mi redis local y otros servicios sin tener que dockerizar estos ...

Estoy ejecutando docker-for-mac-beta y no tengo problemas para conectarme a redis y otros servicios locales, que se ejecutan en OSX, al hacer que escuchen en 0.0.0.0 y que mis aplicaciones acopladas se conecten a 172.17.0.1 .

Visión general

Tengo el mismo problema. Usando la versión de Docker 1.11.1-beta14 (build: 8670) 984649fbd63d53a62b34f08b59694d4d569b74d5 . Mi pinata doctor dice que todo está bien.

No puedo rizar un servicio que se ejecuta en el host, por ejemplo, una aplicación ExpressJS que escucha en el puerto 3001 , desde el interior del contenedor:

root<strong i="11">@e19fc8e02595</strong>:/# curl localhost:3001
curl: (7) Failed to connect to localhost port 3001: Connection refused

root<strong i="12">@e19fc8e02595</strong>:/# curl 0.0.0.0:3001
curl: (7) Failed to connect to 0.0.0.0 port 3001: Connection refused

root<strong i="13">@e19fc8e02595</strong>:/# curl 172.25.8.25:3001
{"status":200} 
root<strong i="14">@e19fc8e02595</strong>:/#

_Nota: 172.25.8.25 es mi IP WiFi._

Piñata

$pinata list
These are advanced configuration settings to customize Docker.app on MacOSX.
You can set them via pinata set <key> <value> <options>.

🐳  hostname = docker
   Hostname of the virtual machine endpoint, where container ports will be
   exposed if using nat networking. Access it via 'docker.local'.

🐳  hypervisor = native (memory=4, ncpu=6)
   The Docker.app includes embedded hypervisors that run the virtual machines
   that power the containers. This setting allows you to control which the
   default one used for Linux is.

 ▸  native: a version of the xhyve hypervisor that uses the MacOSX
              Hypervisor.framework to run container VMs. Parameters:
              memory (VM memory in gigabytes), ncpu (vCPUs)


🐳  network = hostnet (docker-ipv4=192.168.65.2, host-ipv4=192.168.65.1)
   Controls how local containers can access the external network via the
   MacOS X host. This includes outbound traffic as well as publishing ports
   for external access to the local containers.

 ▸ hostnet: a mode that helps if you are using a VPN that restricts
              connectivity. Activating this mode will proxy container network
              packets via the Docker.app process as host socket traffic.
              Parameters: docker-ipv4 (docker node), host-ipv4 (host node)
 ▸     nat: a mode that uses the MacOS X vmnet.framework to route container
              traffic to the host network via a NAT.

🐳  filesystem = osxfs
   Controls the mode by which files from the MacOS X host and the container
   filesystem are shared with each other.

 ▸   osxfs: a FUSE-based filesystem that bidirectionally forwards OSX
              filesystem events into the container.


🐳  native/port-forwarding = true
   Expose container ports on the Mac, rather than the VM

 ▸    true: Container ports will be exposed on the Mac
 ▸   false: Container ports will be exposed on the VM

🐳  daemon = run 'pinata get daemon' or 'pinata set daemon [@file|-]>
   JSON configuration of the local Docker daemon. Configure any custom
   options you need as documented in:
   https://docs.docker.com/engine/reference/commandline/daemon/. Set it
   directly, or a <strong i="20">@file</strong> or - for stdin.

Posibles duplicados, referencias, ayuda, etc.

• https://github.com/docker/docker/issues/23388
• https://forums.docker.com/t/beta-9-and-localhost-connection-via-net-host/10471
• https://forums.docker.com/t/docker-for-mac-beta-9-and-daemon-options/10449/9
• http://stackoverflow.com/questions/24319662/from-inside-of-a-docker-container-how-do-i-connect-to-the-localhost-of-the-mach
• http://stackoverflow.com/questions/29598504/how-to-connect-to-service-in-the-host-machine-from-inside-a-docker-container
• http://blog.michaelhamrah.com/2014/06/accessing-the-docker-host-server-within-a-container/

Tuve problemas similares y encontré 172. * ips no me dejaba conectarme a una instancia local de mysql enlazada a 0.0.0.0.

Podría conectarme a él con cualquier dirección IP enrutable desde mi máquina host. ifconfig y busca uno de los tuyos.

Ahora, ¿cómo consigo esto dinámicamente en el contenedor?

Tener el mismo problema que @Kazanz (mysql ejecutándose localmente / sin contener) al intentar 172.17.0.1. ¿Así que supongo que probaré Docker Toolbox? Sería útil si se documentara esta restricción. No pude encontrar nada al respecto hasta que me topé con este problema.

Ping @londoncalling ^^

¿Alguna noticia sobre este? porque en Ubuntu (host) la aplicación dentro del contenedor que escucha en 0.0.0.0 puede ser contactada por el host usando IP 172.17.*.*. . Así que no es necesario exponer el puerto cuando se ejecuta el contenedor.

En Docker para Mac Beta, no puedo hacer eso porque no hay docker0. Espero que se arregle en la versión final :)

@thaJeztah @astasoft Lo investigaré hoy, gracias @

Tengo entendido que su problema es acceder a los servicios que se ejecutan en su Mac desde un contenedor.
Si ese es el caso, puede hacerlo utilizando la dirección IP expuesta por la interfaz en0.
ifconfig en0 | grep "inet" | cortar -d "" -f2

Por ejemplo, si tengo un servidor web ejecutándose en mi Mac en el puerto 80:
docker run -it tutum / curl curl ifconfig en0 | grep "inet " | cut -d " " -f2

¡Funciona!

Puede configurar esa ip en una variable de entorno y pasarla a su contenedor, como hago para el servidor X11 en https://github.com/chanezon/docker-tips/blob/master/x11/README.md

@chanezon Pude hacer que esto funcionara, pero parece menos que ideal, ya que esta IP cambia a menudo dependiendo de la red a la que esté conectado. Esperaba establecer una IP más o menos estática que representara mi puente acoplable local.

@londoncalling Gracias,

@chanezon No, mi caso está accediendo al servicio del Host al contenedor. Hay un caso en el que quiero ejecutar el servidor web en mi host en el puerto 80 y el mismo puerto en mi contenedor. Si expongo el puerto 80 del contenedor al host, no podré ejecutar el servidor web en mi máquina host. Este tipo de configuración es importante para mi desarrollo.

Mi solución alternativa actual es volver a Docker Toolbox para Mac y realizar el reenvío de puertos en la instancia de Boot2Docker en Virtualbox.

sudo iptables -t nat -A PREROUTING -d 192.168.99.100/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.0.2:80

Luego puedo llamar al servicio en el contenedor usando boot2docker IP 192.168.99.100:80.

curl -i http://192.168.99.100

Así que tengo el siguiente problema que podría estar relacionado con esto.
Por el simple hecho de ser claro, estoy ejecutando Docker Beta for Mac 1.12.0-beta21 (build: 10868) .

Básicamente, no puedo conectarme desde el host al contenedor usando la dirección IP 172.17.0.2 , porque no hay una interfaz docker0 con la dirección 172.17.0.1 asignada.

El contenedor es una imagen de ubuntu y aquí está la información relevante de la red

root<strong i="12">@app</strong>:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:02
          inet addr:172.17.0.2  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:acff:fe11:2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:524 errors:0 dropped:0 overruns:0 frame:0
          TX packets:370 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:217502 (217.5 KB)  TX bytes:40451 (40.4 KB)

root<strong i="13">@app</strong>:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.17.0.1      0.0.0.0         UG    0      0        0 eth0
172.17.0.0      *               255.255.0.0     U     0      0        0 eth0

El host es un MacbookPro y, como puede ver en el siguiente fragmento, no tiene docker0 (o cualquier interfaz para este asunto) con una dirección IP 172.17.0.1 , que se asigna en el contenedor como la salida.

robert<strong i="19">@localhost</strong> $ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=3<RXCSUM,TXCSUM>
    inet6 ::1 prefixlen 128
    inet 127.0.0.1 netmask 0xff000000
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
    nd6 options=1<PERFORMNUD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
    ether f4:5c:89:c9:be:0d
    nd6 options=1<PERFORMNUD>
    media: autoselect (<unknown type>)
    status: inactive
en1: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
    options=60<TSO4,TSO6>
    ether 6a:00:02:06:b7:f0
    media: autoselect <full-duplex>
    status: inactive
en2: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
    options=60<TSO4,TSO6>
    ether 6a:00:02:06:b7:f1
    media: autoselect <full-duplex>
    status: inactive
p2p0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2304
    ether 06:5c:89:c9:be:0d
    media: autoselect
    status: inactive
awdl0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> mtu 1484
    ether 0e:f1:f1:4d:46:88
    nd6 options=1<PERFORMNUD>
    media: autoselect
    status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=63<RXCSUM,TXCSUM,TSO4,TSO6>
    ether f6:5c:89:9c:e6:00
    Configuration:
        id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
        maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
        root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
        ipfilter disabled flags 0x2
    member: en1 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 5 priority 0 path cost 0
    member: en2 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 6 priority 0 path cost 0
    nd6 options=1<PERFORMNUD>
    media: <unknown type>
    status: inactive
en4: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
    ether 39:c9:87:45:22:ee
    inet6 fe80::3ac9:86ff:fe40:22de%en4 prefixlen 64 scopeid 0x9
    inet 192.168.1.123 netmask 0xffffff00 broadcast 192.168.1.255
    nd6 options=1<PERFORMNUD>
    media: autoselect (1000baseT <full-duplex,flow-control>)
    status: active

Algunos colegas hacen que esto funcione correctamente en los hosts de Ubuntus, por lo que supongo que es un problema de Mac o un entorno local.
¿Alguna idea?

@robertoestivill no está seguro sobre el caso de uso exacto, pero si ese contenedor publicó un puerto, puede acceder a él a través de localhost:port

@nikdavis, si desea una IP estable, puede agregar una IP (cualquiera a la que nunca enrutará) a la interfaz de bucle invertido lo0 de la Mac y usarla.

Hola, en mi humilde opinión, esta es una gran diferencia para Docker en Linux. Existe mucha documentación que simplemente no se aplica. Tampoco tengo el conocimiento suficiente de la red para saber cómo adjuntar otra ip a lo0 y luego qué. Sería realmente útil si hubiera una descripción de las soluciones alternativas (que no involucren a boot2docker) para este problema y mencionarlo en los documentos.

@justincormack @chanezon ¿podemos trabajar juntos en esto para obtener buenos documentos sobre este problema?

@ pourquoi42
Puede agregar otra IP a la interfaz lo0 de la siguiente manera:
CONTAINER_IP = $ (docker inspect --format '{{.NetworkSettings.IPAddress}}' nombre-contenedor)
ifconfig lo0 alias $ CONTAINER_IP

Para eliminarlo:
ifconfig lo0 -alias $ CONTAINER_IP

@itilk No parece funcionar en MacOs. Probé con names y container id .

robert<strong i="9">@work</strong>:~ $ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
d047790e196a        group/name              "/bin/bash"         About a minute ago   Up About a minute                       jovial_goodall

robert<strong i="10">@work</strong>:~ $ docker inspect --format '{{ .NetworkSettings.IPAddress }}' jovial_goodall

robert<strong i="11">@work</strong>:~ $ docker inspect --format '{{ .NetworkSettings.IPAddress }}' d047790e196a

robert<strong i="12">@work</strong>:~ $

Tenía Docker 1.12.0 (compilación 10871) ejecutándose en Darwin,
1) Todo el contenedor de la ventana acoplable funciona bien;
2) El contenedor puede comunicarse con el anfitrión ;
3) La comunicación entre contenedores funciona bien;

¿Dónde está la interfaz virtual de docker0 ? ¿O hay alguna forma de permitir que el host se conecte a los contenedores?

Es triste leer esto: Limitaciones conocidas en OSX

Known Limitations
There is no docker0 bridge on OSX
Because of the way networking is implemented in Docker for Mac, you cannot see a docker0 interface in OSX. This interface is actually within HyperKit.

I can’t ping my containers
Unfortunately, due to limtations in OSX, we’re unable to route traffic to containers, and from containers back to the host.

Entonces, por ahora, solo tenemos una forma de conectar el host al contenedor : Mapeo de puertos

Version 1.12.0-beta21 (build: 11019)
1) Todo el contenedor Docker funciona bien.
2) El contenedor no puede comunicarse con el anfitrión.
3) La comunicación entre contenedores funciona bien.
4) docker0 no disponible.

Ad.2)

Tengo una instancia de hugo que se une a 0.0.0.0 en el puerto 1313 . curl dentro del contenedor en ejecución devuelve: curl: (7) Failed to connect to 172.19.0.1 port 1313: Connection refused .
El uso de la dirección IP devuelta por ifconfig en0 | grep "inet " | cut -d " " -f2 tampoco funciona:
curl: (7) Failed to connect to 172.19.27.228 port 1313: No route to host .

Hola a todos,

Encontré un artículo de otro producto contenedor ( no docker ): https://www.flockport.com/using-flockbox-with-xhyve/ , y ni siquiera lo he probado si realmente funciona.

al final, menciona:

También puede utilizar el enrutamiento en lugar del reenvío de puertos descrito anteriormente para acceder a aplicaciones en contenedores. El enrutamiento hará que toda la subred del contenedor dentro de la VM esté disponible en el host.

Si prefiere utilizar el enrutamiento en lugar del reenvío de puertos, así es como funciona. Los comandos de enrutamiento deben ejecutarse en el host.

Si la IP de su VM es 192.168.64.3 y la subred del contenedor es 10.0.3.0/24, puede crear una ruta con un comando como el siguiente

sudo route -n add 10.0.3.0/24 192.168.64.3

Xyhve crea una interfaz bridge100 automáticamente para redes de VM. Ejecute un ifconfig rápido para comprobar que la interfaz bridge100 está activada, por ejemplo en4, y luego ejecute el siguiente comando.

sudo ifconfig bridge100 -hostfilter en4

Ahora debería poder hacer ping a cualquier contenedor dentro de la VM directamente desde el host

ping 10.0.3.175

Para acceder a la aplicación en el navegador de su Hosts, edite el archivo / etc / hosts en el host como se describe arriba con el reenvío de puertos, pero esta vez asocie la IP del contenedor con la URL de la aplicación.

Lo siento, tengo el conocimiento básico de las redes de Linux, pero ¿es una solución?

No sé cómo hacer que la dirección IP de la máquina virtual (alpine with docker) se ejecute dentro de xhyve, ¿alguna idea?

Hola @Kaijun , no había instalado Docker Machine, ¿y de dónde viene tu bridge100?

@junjiemars no, el artículo que

Pensé si podíamos inspirarnos con este artículo o este producto y aplicar la misma solución para la ventana acoplable.

@Kaijun , sé que puede haber una forma de piratear xhyve para hacer las cosas. Si lo hiciste, comparte tu piratería.

@nikdavis, si desea una IP estable, puede agregar una IP (cualquiera a la que nunca enrutará) a la interfaz de bucle invertido lo0 de la Mac y usarla.

@justincormack ¿Le importaría ser más preciso sobre cómo lograr esto? :)
Probé lo que publicó

En términos generales: ¿Existe una ETA para reintroducir la red docker0 en docker para mac beta?

Gracias

@georgehrke puedes hacer sudo ifconfig lo0 alias 10.200.10.1/24 ; obviamente, elige una dirección que no vas a encontrar localmente. Luego, puede usar esa dirección para hablar con el anfitrión independientemente de si tiene una conexión de red.

Perdón por no expresar mi problema con mayor precisión

No estoy tratando de conectarme desde un contenedor al host, sino al revés.
No puedo conectarme desde mi host a un contenedor directamente.

Estaba usando docker inspect container_name para obtener la IP.
Pero no puedo ni hacer ping ni abrirlo en un navegador a pesar de que el Dockerfile tiene un servidor web y EXPOSE 80 en él

Sí, hay dos problemas separados, que están algo relacionados.

1. Quiero conectarme desde un contenedor a un servicio en el host. La Mac tiene una dirección IP modificada o ninguna si no tiene acceso a la red.

La recomendación actual es adjuntar una IP no utilizada a la interfaz lo0 en la Mac, por ejemplo, sudo ifconfig lo0 alias 10.200.10.1/24 , asegúrese de que su servicio esté escuchando en esta dirección o 0.0.0.0 (es decir, no 127.0.0.1 ). Entonces los contenedores pueden conectarse a esta dirección.

1. Quiero conectarme a un contenedor desde Mac.

La recomendación actual es publicar un puerto o conectarse desde otro contenedor. Tenga en cuenta que esto es lo que debe hacer incluso en Linux si el contenedor está en una red superpuesta, no en una red puente, ya que estos no están enrutados.

Entendemos que estos no son ideales, pero hay varios problemas, en particular un error en OSX que solo se corrigió en 10.12 y que no se está retroportando hasta donde podemos decir, lo que significa que no podríamos admitir esto en todos los OSX compatibles. Versiones Además, esta configuración de red requeriría acceso de root que estamos tratando de evitar por completo en Docker para Mac (actualmente tenemos un asistente de root muy pequeño que estamos tratando de eliminar).

( @londoncalling ¿desea agregar este resumen a los documentos?)

@justincormack, ¿quiere decir que todo --net=host en macOS Docker es inútil?

@ m1ome no es completamente inútil: puede conectarse a los servicios que ejecuta allí desde otros contenedores a medida que los puertos se abren en la máquina virtual, pero la gente espera que los servicios estén disponibles en Mac como puertos publicados, que no tenemos. todavía funciona, ya que esto es bastante complejo (no obtenemos un feed de eventos para los puertos que abre así, a diferencia de los puertos publicados donde usamos eventos de docker).

@justincormack ¿ hay aquí alguna solución para este problema al menos por ahora? Si Docker lo tiene, creo que será bastante útil escribirlo en la documentación.

@justincormack Puedo agregar su escrito a los documentos, pero creo que deberíamos incluir algunos ejemplos específicos. Lo probaré yo mismo, pero probablemente necesitaré la ayuda de usted o de otra persona. Me pondré en contacto con usted mientras lo soluciono.

@londoncalling seguro que te enviará algunos.

El 30 de agosto de 2016 a las 6:28 pm, "Victoria" [email protected] escribió:

@justincormack https://github.com/justincormack Puedo agregar tu escrito
a los documentos, pero creo que deberíamos incluir algunos ejemplos específicos. Lo intentaré
yo mismo, pero probablemente necesite la ayuda de usted o de otra persona. Enfermo
me pondré en contacto contigo mientras lo trabajo.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/22753#issuecomment -243515932,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAdcPPgFU3H6TZCLcI0yUvbPn4tPwZj7ks5qlGhUgaJpZM4Ie9PB
.

@justincormack gracias: dado este hilo, creo que necesitamos al menos dos ejemplos, y quizás incluso tres, como se muestra a continuación. ¿Qué piensas?

1. Un ejemplo de cómo acceder a un servicio en el host de Mac desde un contenedor (por ejemplo, ¿funcionaría que la aplicación fuera un servidor web como nginx conectándose a una base de datos de redis en el host?)
2. Un ejemplo de conexión a un contenedor desde Mac. ¿Nuestro ejemplo actual run ? es decir, docker run -d -p 80:80 --name webserver nginx ? @justincormack, pero deberíamos mostrar esto con y sin mapeo de puertos según el comentario de @weaver a continuación, entonces, ¿probablemente dos casos de uso diferentes aquí?
3. Un ejemplo de cómo ejecutar una aplicación en un contenedor que usa un servicio en otro (por ejemplo, repita el ejemplo nginx más redis pero esta vez ¿ejecutar redis en un contenedor?

An example of connecting to a container from the Mac. Does our current nginx example cover the second case, since we expose a port in the run command; i.e., docker run -d -p 80:80 --name webserver nginx?

Realmente agradecería un ejemplo de conexión de Mac a un contenedor que no implique el mapeo de puertos. Mi caso de uso es ejecutar un clúster mesos para el desarrollo local. Si el mapeo de puertos es la única forma de lograr la comunicación directa desde la Mac a un contenedor (esclavo), se requiere trabajo adicional para asegurarse de que cada proceso esclavo de mesos se ejecute en un puerto único para que cualquier acceso desde la Mac (ver registros para depuración, para ejemplo) es consistente con los puertos que usa mesos internamente (de lo contrario, los marcos de mesos representan las URL en paneles con números de puerto internos que no funcionan desde el host).

En este momento, utilizo docker-machine con una ruta desde la Mac a la red virtual para que todas las direcciones IP y números de puerto que usa el clúster mesos "simplemente funcionen" desde la Mac. Esta es una solución muy sencilla.

@weaver como se indicó, no existe una forma actual de conectarse a un contenedor directamente desde el host si no tiene un puerto publicado. Sin embargo, puede conectarse desde otro contenedor.

@justincormack Leí todo el hilo tratando de averiguar cómo conectarme desde mi mac al contenedor, tal como lo hago en Linux: container-ip: 8080 por ejemplo. Por lo que entiendo, esto debería ser posible en MacOS (10.12), ¿verdad?

@matiasserrano puede hacer esto con portmapping en, por ejemplo, docker run -p 8080:8080

@ m1ome sí, lo sé. Pero no es escalable para mí. Soy desarrollador y normalmente ejecuto varios contenedores con apache / Nginx, por lo que 80 siempre está en uso. Si hago lo que propones, primero necesito deshabilitar apache en mi mac, segundo necesito ejecutar un contenedor a la vez porque comparten el mismo puerto. Usar diferentes puertos no es una opción.
Por otro lado, les damos contenedores a los desarrolladores para que comiencen a trabajar, y nuevamente podrían estar trabajando en más de un proyecto al mismo tiempo.
Por eso la posibilidad de conectarnos desde la Mac a los contenedores utilizando su IP es imprescindible para nosotros.

@matiasserrano ¿ -P para reenviar los puertos expuestos a un puerto alto arbitrario automáticamente? Si está buscando la IP del contenedor a través de algo como docker inspect también es posible hacer una operación muy similar para el puerto expuesto.

@nathanleclaire El problema no es conocer el puerto o la IP del contenedor, es básicamente la misma solución que en el post anterior. Otra solución es crear una máquina virtual vagabunda para cada proyecto y ejecutar docker dentro o usar docker-machine, que es básicamente lo mismo. Ambas soluciones no son aceptables para nosotros. Preferimos usar Vagrant en su lugar.

Por lo que vale, tengo un caso de uso similar al de @weaver (es decir, acceder directamente a la red de contenedores desde el host). Ejecuto un clúster Spark a través de Docker, en su propia red. Utilizo docker-machine y agrego una ruta estática sobre la interfaz docker0 para la subred que usa el clúster.

La interfaz de usuario de Spark está disponible en el nodo principal e incluye enlaces HTML a todos los demás nodos del clúster (a través de su dirección IP). Al agregar la ruta estática, puedo acceder a la interfaz de usuario de Spark en el maestro directamente desde mi máquina de desarrollo, y los enlaces que genera a través de otros nodos en el clúster simplemente funcionan. Estos enlaces también significan que no es solo un caso de reenvío del puerto 7080 para que el maestro opere sin docker0 ; necesito poder llegar a toda la red de alguna manera.

Supongo que una solución alternativa por ahora sería hacer un enrutamiento inteligente a través de nginx u otro proxy web en un contenedor adicional, aunque no tengo un ejemplo de que funcione en este momento.

@nathanleclaire El problema no es conocer el puerto o la IP del contenedor, es básicamente la misma solución que en el post anterior.

No entiendo.

Tu dices:

Por eso la posibilidad de conectarnos desde la Mac a los contenedores utilizando su IP es imprescindible para nosotros.

¿Por qué diferentes direcciones IP específicamente? Aquí está describiendo los conflictos de puertos como el problema:

Soy desarrollador y normalmente ejecuto varios contenedores con apache / Nginx, por lo que 80 siempre está en uso. Si hago lo que propones, primero necesito deshabilitar apache en mi mac, segundo necesito ejecutar un contenedor a la vez porque comparten el mismo puerto.

Con -P no hay dos contenedores que expongan el mismo puerto, incluso si todos están escuchando en 80 internamente. Entonces, ¿por qué necesitaría deshabilitar Apache, etc.?

Otra solución es crear una máquina virtual vagabunda para cada proyecto y ejecutar docker dentro o usar docker-machine, que es básicamente lo mismo. Ambas soluciones no son aceptables para nosotros. Preferimos usar Vagrant en su lugar.

Si insiste en usar Vagrant y no usará Docker Machine o Docker para Mac, ¿por qué presentar / discutir aquí?

@nathanleclaire En Linux, usando los contenedores que creé, si quiero puedo ejecutar 4 contenedores al mismo tiempo, por ejemplo, que exponen el puerto 80. IE: Uno para Magento, uno para Drupal, uno para Larabel y otro con un clean apache.

Cada contenedor tendrá una IP, por ejemplo, 192.100.200.1, 192.100.200.2, 192.100.200.3 y 192.100.200.4.

Con esas IP, agrego un host a mi archivo / etc / hosts, con un alias para cada uno, ejemplo:

192.100.200.1 magento.local
192.100.200.2 drupal.local
192.100.200.3 larabel.local
192.100.200.4 apache.local

y luego ingrese a los servidores directamente desde el navegador.

En Mac, no puedo hacer eso, porque no puedo obtener una IP para cada contenedor. Usar -P no es una opción, porque en lugar de tener un alias para cada contenedor, necesitaré usar algo como localhost: 8012 , para Magento, localhost: 9823 para drupal y así sucesivamente.

Otra solución es usar vagrant con una máquina virtual Linux para cada contenedor que ejecuta el contenedor dentro y usa el mapeo de puertos 80:80. Con esta solución, docker no tiene sentido, porque si creo una máquina Vagrant, con las mismas cosas que tiene el contenedor docker, es lo mismo. (Conozco las diferencias entre Docker y Vagrant, y prefiero Docker en lugar de Vagrant 100 veces ...)

Espero que este caso de uso le ayude a comprender por qué es tan importante para nosotros obtener la IP del contenedor.

El ejemplo es con el puerto 80 pero es aplicable a cualquier puerto que desee.

@matiasserrano OK, sospeché que podría estar relacionado con el deseo de mapeo de DNS / nombre de host, gracias.

Tenía el mismo problema (conectarse al host desde el contenedor). Usar 192.168.65.1 funcionó para mí. No estoy del todo seguro de qué es esto, pero creo que aparece brevemente en el registro de piñata de @thalesfsp :

🐳  network = hostnet (docker-ipv4=192.168.65.2, host-ipv4=192.168.65.1)
   Controls how local containers can access the external network via the
   MacOS X host. This includes outbound traffic as well as publishing ports
   for external access to the local containers.

(¡Gracias @feedthefire por mostrarme esto!)

Si insiste en usar Vagrant y no usará Docker Machine o Docker para Mac, ¿por qué presentar / discutir aquí?

@nathanleclaire Esa es una respuesta bastante inútil, tal vez incluso insinuando que la gente no debería quejarse si no está de acuerdo. Es este tipo de actitud la que le dará a Docker una mala reputación cuando se trata de discusiones en la comunidad.

Gracias @cpoonolly , tu respuesta es muy útil, pero creo que tu solución funciona en la dirección opuesta: el contenedor intenta conectarse a Mac Host. Lo que necesito es todo lo contrario: Mac Host tratando de conectarse a los contenedores usando su IP.

Hey gente. Este problema se ha extendido en una variedad de direcciones y sugeriría a los mantenedores de la ventana acoplable / ventana acoplable que lo cierren y lo dividan en varios problemas secundarios. por ejemplo, uno para acceder a la IP de la Mac desde el interior de la máquina virtual D4M y otro para la direccionabilidad IP por contenedor (aunque yo diría que esto podría ser mejor simplemente admitiendo la asignación de nombres de host / DNS de contenedor de forma nativa en D4M). Lo más probable es que esté en el repositorio de Docker para Mac, ya que este es el repositorio del "Motor", e idealmente debería tener tickets sobre las preocupaciones del motor en Linux / Windows en el rastreador.

Por lo que vale, hay _definitivamente_ un puente docker0 en Docker para Mac VM. Puede verlo usted mismo si ejecuta un contenedor con --net host y ejecuta ifconfig . Sin embargo, los diversos problemas aquí no tienen que ver con lo que sugiere el título original: están relacionados con la visibilidad y la red de contenedores y VM.

@icecrime @justincormack ¿Qué piensas? Gracias a todos.

@nathanleclaire Esa es una respuesta mucho mejor, gracias, y estoy completamente de acuerdo en que dividir en varios temas secundarios sería una buena manera de avanzar aquí.

¡¡¡¡Estoy de acuerdo!!!! no hay problema si haces eso!

@nathanleclaire @justincormack , mientras tanto, los documentos Beta 25 (que se publicarán hoy, un poco por detrás de los lanzamientos de la aplicación) proporcionarán las sugerencias de Justin y Nathan para soluciones en los temas de redes y preguntas frecuentes. Aunque sé que no resuelve los problemas de todos, será un comienzo para proporcionar algunas soluciones en los documentos y reconocer los problemas.

@matiasserrano en la próxima versión beta, prevista para el martes, podrá publicar puertos en diferentes direcciones IP en el host. Entonces, si agrega varias direcciones a la interfaz de loopback, como mencioné anteriormente, luego agregue estas en su archivo de hosts, podrá publicar diferentes contenedores en el puerto 80 en cada una de estas direcciones y usar los nombres de host.

así que si agregas

192.100.200.1 magento.local
192.100.200.2 drupal.local
192.100.200.3 larabel.local
192.100.200.4 apache.local

a /etc/hosts entonces puedes hacer:

sudo ifconfig lo0 alias 192.100.200.1/24
sudo ifconfig lo0 alias 192.100.200.2/24
sudo ifconfig lo0 alias 192.100.200.3/24
sudo ifconfig lo0 alias 192.100.200.4/24

luego

docker run -p 192.100.200.1:80:80 magento
docker run -p 192.100.200.2:80:80 drupal
...

entonces debería poder conectarse directamente a drupal.local etc.

@londoncalling deberíamos documentar esto para los próximos documentos beta.

@justincormack nitpick: ¿es correcto este bloque?

$ ifconfig lo0 alias 192.100.200.1/24
$ ifconfig lo0 alias 192.100.200.2/24
$ ifconfig lo0 alias 192.100.200.2/24
$ ifconfig lo0 alias 192.100.200.2/24

¿Deberían los dos últimos ser 192.100.200.3 y 192.100.200.4 ? ¿Y por qué alias todo el cidr ( 192.100.200.1/24 es el rango completo de 192.100.200.0 a 192.100.200.255 verdad?)? ¿Debería ser solo la única IP?

Disculpa error. Sí, /32 está bien.

@justincormack ¿

Además, ¿por qué Docker establece 10 ip [192.168.65.1 a 10] en /etc/resolv.conf?
PD: no use 192.100.xx ya que es un rango público. Utilice 192.168.xx

Estamos tratando de evitar agregar DNS a la interfaz, pero solo lea el
configuración de la Mac. Leemos el archivo de hosts pero leemos todos los
configuración pronto.

Las direcciones de archivos de hosts se asignan a los resolutores de archivos de hosts, pero
alrededor, para que la conmutación por error funcione correctamente.

El 11 de septiembre de 2016 a las 7:09 pm, "Jijo Varghese" [email protected] escribió:

@justincormack https://github.com/justincormack ¿Estará el DNS en la interfaz gráfica de usuario?
interfaz pronto? Dado que beta25 todavía no puede resolver los nombres de DNS
a través de vpn de túnel dividido esperaba ejecutar dnsmasq en mi host mac. Todos los demás
los puertos en mi mac son accesibles a través de 192.168.65.1 desde contenedores internos pero
no dns.

Además, ¿por qué Docker establece 10 ip [192.168.65.1 a 10] en /etc/resolv.conf?
PD: no use 192.100.xx ya que es un rango público. Utilice 192.168.xx

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/22753#issuecomment -246194539,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAdcPEQcEyn3w7BPJCeaz5mlbgJx5etTks5qpEPUgaJpZM4Ie9PB
.

Solo quiero agradecer a @justincormack por esto:

Sí, hay dos problemas separados, que están algo relacionados.

1. Quiero conectarme desde un contenedor a un servicio en el host. La Mac tiene una dirección IP modificada o ninguna si no tiene acceso a la red.
   La recomendación actual es adjuntar una IP no utilizada a la interfaz lo0 en Mac, por ejemplo, sudo ifconfig lo0 alias 10.200.10.1/24 , asegúrese de que su servicio esté escuchando en esta dirección o 0.0.0.0 (es decir, no 127.0.0.1). Entonces los contenedores pueden conectarse a esta dirección.

Si bien no es lo ideal, esto debería funcionar para nosotros por ahora. (probado y funcionando)

@justincormack

Estamos tratando de evitar agregar DNS a la interfaz, pero simplemente lea la configuración de Mac.
Las combinaciones de VPN son variadas y complejas, por lo que sería miope asumir que siempre puede leer la configuración correcta. https://github.com/docker/for-mac/issues/19 (cerrado) todavía está roto para nosotros en vpn de túnel dividido. Probablemente no sea un problema de la ventana acoplable, sino cómo nuestro servidor vpn divide los dns.

En otro ejemplo, en mi lugar anterior, le diríamos a la gente de QA y Dev que apunten a diferentes servidores de nombres según el env que quisieran acceder. Si ese tipo de prueba solo se necesitaba dentro de Docker, ese es otro caso de uso a considerar. Gracias.

Estamos trabajando en la compatibilidad del servidor de nombres divididos para VPN.

El 13 de septiembre de 2016 a las 6:48 pm, "Jijo Varghese" [email protected] escribió:

@justincormack https://github.com/justincormack

Estamos tratando de evitar agregar DNS a la interfaz, pero solo lea el
configuración de la Mac.
Las combinaciones de VPN son variadas y complejas, por lo que sería miope si
suponga que siempre puede leer la configuración correcta. docker / para mac # 19
https://github.com/docker/for-mac/issues/19 (cerrado) todavía está roto
para nosotros en vpn de túnel dividido. Probablemente no sea un problema de Docker, sino cómo
nuestro servidor vpn hace split-dns.

Otro ejemplo, en mi lugar anterior, le diríamos a la gente de QA y Dev que apunten
a diferentes servidores de nombres dependiendo de qué env querían golpear. Si eso
El tipo de prueba solo se necesitaba dentro de Docker, entonces ese es otro uso
caso a considerar. Gracias.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/22753#issuecomment -246764433,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAdcPDXx3ziQv81fPBXpQHvU7_j9YWKQks5qpuHdgaJpZM4Ie9PB
.

Muchas gracias @justincormack , puedo usar su solución alternativa para acceder a todos mis contenedores directamente mediante el alias en lo0 , lo que me pone en funcionamiento con Docker para Mac: +1:

Estoy usando docker-compose para ejecutar mis contenedores, por lo que la última arruga es la necesidad de configurar el reenvío de puertos para vincularse a la dirección IP correcta en el host, por contenedor. (La vinculación a 0.0.0.0 me dará conflictos de puerto cuando tenga más de un contenedor).

No estoy seguro de si alguien ha encontrado una forma de evitar esto. - De hecho, necesito interpolar en la configuración de docker-compose, ya que la dirección IP no se conoce hasta que se inicia el contenedor.

(Aprecie que nos estamos desviando del número original aquí).

@NoOrdInaryGuy esto debería funcionar en las últimas versiones (tanto estables como beta); puede especificar una IP específica que esté en la Mac para enlazarse, por ejemplo, una dirección en lo0 .

@justincormack Sí, puedo confirmar que funciona correctamente. El único problema es cuando se usa docker-compose (particularmente con el escalado, o supongo que podría configurar direcciones estáticas). No es posible agregar reenvíos de puerto después de que se inicia un contenedor, y no conozco una forma de hacer referencia a la dirección IP real del contenedor al archivo de composición / Dockerfile en "tiempo de ejecución", que creo que necesitaría en orden para configurar el reenvío de puertos para escuchar en la IP correcta.

Estoy resolviendo esto en este momento al no usar docker-compose en este escenario y tener un script bash personalizado para invocar docker, pero me preguntaba si alguien más había pensado en una mejor solución.

Esto parece prometedor.

Mi caso de uso es similar a lo que otros han dicho. Creamos contenedores con servicios Java en ejecución e intentamos probar esos servicios desde el sistema host. Ejecutamos las pruebas en una canalización jenkins, por lo que la publicación de puertos en el sistema host es problemática, porque el sistema host podría estar ejecutando varios contenedores, todos intentando vincular los mismos puertos.

Por lo general, solo "exponemos" los puertos y luego usamos 'docker inspect' para descubrir la IP del contenedor y conectarnos a los puertos de servicio en esa IP. Cuando los desarrolladores quieren probar las pruebas en Mac, hemos estado usando un truco boot2docker para agregar una ruta estática a los contenedores a través de VirtualBox VM.

He estado viendo Mac Beta con la esperanza de poder acceder a los puertos expuestos usando un método similar, y este truco de alias lo0 parece el boleto.

Probablemente este no sea el lugar para una solicitud de función, pero me preguntaba si sería posible agregar una IP como entrada a la opción docker run publish-all. Se vería algo como esto yo:

sudo ifconfig lo0 alias 10.200.10.1/32
docker run --publish-all 10.200.10.1 -d --name webserver my_test_image

Luego, si hubiera varios puertos EXPUESTOS en my_test_image, podría acceder a ellos a través del alias de IP.

Puedo confirmar el docker0 que falta en el último docker-mac

MacBook $ docker version
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.7.1
 Git commit:   6f9534c
 Built:        Thu Sep  8 10:31:18 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 17:52:38 2016
 OS/Arch:      linux/amd64
MacBook$ docker info
Containers: 7
 Running: 0
 Paused: 0
 Stopped: 7
Images: 107
Server Version: 1.12.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 133
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.20-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.953 GiB
Name: moby
ID: W53J:DFZB:4SCO:CS34:6CRF:FCDR:74RZ:TBJC:WZ35:QUVW:NZQU:7ANZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 17
 Goroutines: 29
 System Time: 2016-09-26T00:20:31.292958501Z
 EventsListeners: 1
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

Mi necesidad es inversa a la publicación original. Me gustaría acceder a una dirección de containter fija como 172.17.0.3 del anfitrión. Por ejemplo, tendré una aplicación web ejecutándose y quiero acceder a ella desde el host; Prefiero no hacer un reenvío de puertos desagradable que es necesario sin docker0 como interfaz en el host. VirtualBox tiene redes de solo host y puedo hablar con esta red de solo host desde el host.

docker0 se ve si mi host es linux; solo falta con docker-mac. Tampoco quiero usar virtualbox para ejecutar Docker en Mac.

Como se describe en el documento: se corrigieron algunos tipos de errores en 10.12

Entendemos que estas soluciones alternativas no son ideales, pero existen varios problemas. En particular, _ hay un error en OSX que solo se corrigió en 10.12 _ y, por lo que sabemos, no se está modificando, lo que significa que no podríamos admitirlo en todas las versiones compatibles de OSX.

Entonces, preguntaría, ¿Docker ya soluciona este problema en 10.12? o aún no lo ha hecho, por la compatibilidad de todas las versiones.

@Kaijun no, necesitamos admitir varias versiones de OSX, y la forma en que lo estábamos haciendo antes tiene otros problemas, por lo que es poco probable que volvamos a eso.

Hola, realmente aprecio toda la discusión en este hilo. Me pregunto: ¿alguien podría resumir (o señalarme) ese problema real con OS X que nos impide poder establecer una ruta directamente a los contenedores?

He visto comentarios sobre cómo hay algún problema con OS X (aquí y en otros hilos). Parece que no puedo encontrar una descripción sólida de cuál es realmente el problema, por qué 10.12 está arreglado, etc.

(1) ¿Por qué funciona esto para algo como virtualbox / docker-machine pero no para xhyve?

(2a) Incluso si la ventana acoplable no puede admitir esta función solo para 10.12, ¿hay algo que pueda hacer si ejecuto 10.12 para piratearlo y hacerlo funcionar?

(2b) ¿Cuáles son los "otros problemas" con la "forma en que lo hacíamos antes"?

Lo siento mucho si estas son preguntas tontas (o si la respuesta ya está en este hilo y me la perdí).

Gracias.

@weaver anteriormente estábamos usando la opción vmnet en https://github.com/docker/hyperkit que crea un puente para la máquina virtual, lo que permite el enrutamiento desde contenedores al host en una IP en el puente. Sin embargo, no permite el enrutamiento a los contenedores. Hubo un CVE relacionado con esto que exponía un servidor DNS abierto cuando estaba habilitado, que se corrigió en Sierra.

Hay muchas otras desventajas del modo vmnet: no es compatible con IPv6, tiene poco control, tenemos que ejecutar como root, no funciona con muchas configuraciones de VPN y más. Comenzamos a usar el "modo VPN" como una opción, que se convirtió en el valor predeterminado actual, y luego se eliminó la otra opción después del problema de seguridad.

La opción de que el puente docker0 parecería estar mágicamente en Mac y no en la máquina virtual Linux nunca se ha implementado y no es realmente posible, de la misma manera que no está disponible si usa un host remoto. . Sin embargo, la gente ha llegado a depender de varias formas en las que pueden usar varias configuraciones de enrutamiento, y nos gustaría intentar adaptar algunos de estos casos de uso, pero no es muy fácil de hacer. Virtualbox instala módulos del kernel en Mac para hacer esto, lo cual no vamos a hacer.

Hola,

En primer lugar, deje que cualquiera deje de responder con respuestas sobre el reenvío de puertos. Lo sabemos y no queremos eso, porque como muchos han publicado ahora, queremos un puerto simple en el acceso IP.
¿Podemos intentar mantener este hilo sobre soluciones para eso?
Me sorprendió mucho que esto no fuera posible. No veo por qué necesitamos un puente en la mac per se, siempre que la red sea enrutable.

Entonces, para todos los que quieran eso: elimine Docker para Mac, instale Docker Toolbox y ejecute algo como:
sudo route -n agregar 172.17.0.0/24 192.168.99.100
donde 172.xxx es la red acoplable configurada en el host de VirtualBox y 192.xxx es la IP real de ese host que se puede enrutar en el mac (a través de la interfaz de red de VirtualBox).
Simplemente enruta el tráfico correctamente.

¿Se puede agregar a la documentación de la ventana acoplable?

Dado que lo anterior me dio lo que quiero, no busqué más en xhyve.
¿No sería la solución ingresar un comando similar al anterior, que funciona con la configuración de red a partir de eso? No pude hacer ping a la dirección 192.168.65.x, por lo que agregar una ruta no funcionaría. Si alguien publica el comando para habilitarlo, el comando de ruta también debería funcionar.

¿Problema resuelto? Sería genial si estos se documentaran donde describe la limitación de mac.
gracias

@justincormack @ dmp42 @jeanlaurent, ¿puedes echar un vistazo al comentario de @VGerris directamente arriba y decirme cómo / dónde te gustaría que se documentara esto: Toolbox y d4mac?

¿Es posible que esto pueda solucionarse para 10.12 y arrojar un error / advertencia si la corrección de 10.12 requerida no está presente en el sistema? A continuación, puede documentar la solución alternativa de / etc / host o toolbox para las personas que ejecutan 10.11.

En mi opinión, poder acceder a la red de contenedores desde el host sin reenvío de puertos o configuración de red manual es una característica fundamental de Docker. El hecho de que esto no funcione como se esperaba es realmente un problema importante.

@justincormack : todavía no funciona para nuestra configuración de dns dividida después de la versión beta de hoy.

repitiendo desde arriba.

Estamos tratando de evitar agregar DNS a la interfaz, pero solo lea el
configuración de la Mac.

Las combinaciones de VPN son variadas y complejas, por lo que sería miope asumir que siempre puede leer la configuración correcta.

@justincormack no ha proporcionado ninguna solución a los usuarios de Docker para mac, el acceso ip es muy demandado, porque desarrollar con docker necesita acceso directo al servicio de contenedor desde docker-container y desde host, el reenvío de puertos no funciona para esta situación (el El servicio tendrá una dirección diferente desde un lugar diferente).

también el libvmnet no es tan bueno, pero es una solución, sudo es aceptable que nada !!!

la solución del dispositivo tap necesita permiso no-sudo. al menos, Docker para Mac debería proporcionar alguna forma de pirateo para permitir que los desarrolladores se abran paso. por ejemplo, los usuarios pueden personalizar el argumento del comando de inicio del hiperkit.

En este momento, la ventana acoplable para mac es casi inútil para las personas.

mierda!

¿Hay alguna vista sobre si esto se solucionará o cuándo?

@justincormack : Además, esta configuración de red requeriría acceso de root que estamos tratando de evitar por completo en Docker para Mac (actualmente tenemos un asistente de root muy pequeño que estamos tratando de eliminar).

¿Por qué? En linux no es posible ejecutar Docker sin privilegios de root y todo está bien, en OSX quieres evitar eso. ¿Cuál es la razón detrás de eso? Entonces, a partir de ahora, la ventana acoplable para OSX debería ser como la aplicación de Facebook, no importa que la función principal no funcione, pero no requiere privilegios de root.

En mi opinión, si el privilegio de root ayuda a resolver ese problema, arréglelo y, mientras tanto, intente lograrlo sin root. Actualmente no tenemos la función principal, que solíamos hacer, que planificamos todo el flujo en función de esa función, y ahora tenemos que resolver muchos problemas.

Sería un compromiso aceptable considerar esto como una característica avanzada. ¿Y cuando las funciones avanzadas están habilitadas, requieren privilegios adicionales?

La razón por la que quiero que se devuelva esta función es para mantener las cosas en los puertos estándar. Tenemos una convención de nomenclatura estándar para todos nuestros servicios. Tengo registros DNS creados incluso para desarrolladores que podrían apuntar a una IP estática en su Mac. Cada contenedor tiene su propia IP, por lo que siempre es el puerto 3306 sin importar en qué proyecto esté trabajando. Cada proyecto está realmente separado al igual que en qa hasta prd.

Ahora, cuando un desarrollador quiere conectarse a MySQL en su máquina local, tiene que mirar un gráfico para ver qué puerto único tiene el proyecto. El Proyecto A es 3307, el Proyecto B es 3308 ¿Qué fue el Proyecto Q nuevamente? La aleatorización del puerto también es descuidada porque no le permite guardar la configuración de conexión y demás. Aún necesitas buscarlo todo el tiempo.

Si bien esto puede parecer un problema menor. Cambiar entre proyectos con mucha frecuencia es molesto, con esta estandarización elimina muchos pasos adicionales. ¿Quieres trabajar en un proyecto diferente? Git clone y ejecute make. TODO se configura a partir de ahí. Múltiples contenedores, credenciales, configuraciones, etc. Configuración de desarrollo de un solo comando.

+1, desesperadamente necesario: - /

Acabo de ponerme al día con la documentación en https://docs.docker.com/docker-for-mac/networking/, así que entiendo los desafíos involucrados.

Desafortunadamente, este es un impedimento severo para usar Docker Native en nuestro entorno de desarrollo local. Tenía la esperanza de migrar lejos de Virtualbox / Vagrant.

Nuestro problema es que utilizamos Consul para el descubrimiento de servicios. Para el desarrollo local, queremos ejecutar una combinación de servicios desde docker-compose y directamente desde los IDE del desarrollador en Mac. Dado que los servicios que se ejecutan en contenedores se registran con consul usando su docker ip: port, los servicios que se ejecutan fuera de Docker no se pueden integrar.

Por supuesto, esto también es un problema en un clúster de múltiples hosts, pero eso se resuelve mediante la superposición de redes (o en nuestro caso, un script de punto de entrada de introspección desagradablemente hack que averigua la ip del host: asignaciones de puertos).

Parece que finalmente se está trabajando en una API de introspección para ayudar a resolver este tipo de problema (https://github.com/docker/docker/issues/7472). Con suerte, la API de introspección también funcionará con Docker para mac / windows).

Hola chicos, creo que hay algo que vale la pena compartir relacionado con este hilo, podemos hablar con la máquina host desde dentro de los contenedores usando el default IP creado por Docker for Mac/Windows .

La IP es 192.168.65.1

Puede probarlo siguiendo los pasos a continuación:

rogaha@MacBook-Pro:~/development/rogaha$ docker run --name docker-nginx -p 80:80 -d nginx                                
4bc4818c49cffd7b4186294c71e6d4608c0482fd74521b3e9d03a14d499b3e6b
rogaha@MacBook-Pro:~/development/rogaha$

rogaha@MacBook-Pro:~/development/rogaha$ docker run -it --rm tutum/curl curl 192.168.65.1                                                                                   5:52:22
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
rogaha@MacBook-Pro:~/development/rogaha$

¡Espero que ayude!

@rogaha Esa es información interesante. ¿Está eso documentado en alguna parte? ¿Cómo te enteraste?

He confirmado localmente en mi Mac que de hecho llega hasta el host (no solo otro contenedor Docker) a través de 192.168.65.1 .

No estoy seguro. @thaJeztah @justincormack, ¿sabes por casualidad?

Sí, esa ruta se agregó para ayudar a contactar al anfitrión.

Hasta que no exista un nombre estándar, generalmente no recomendamos usar
ya que obviamente no funcionará en producción, pero está bien pasar como un
parámetro.

El 27 de febrero de 2017 a las 08:49, "Roberto Gandolfo Hashioka" [email protected]
escribió:

No estoy seguro. @thaJeztah https://github.com/thaJeztah @justincormack
https://github.com/justincormack ¿lo sabes?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/22753#issuecomment-282777837 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAdcPJ3h5OrhxpgWao8by-qu-UmsuWIOks5rgv62gaJpZM4Ie9PB
.

@rogaha 192.168.65.1 no funciona en mi extremo. ¿Cómo se enteró de esa propiedad intelectual?

Solo quería agregar un + 1 / suscribirse junto con todos los demás en este hilo, y agregar otra voz a la solicitud de función de poder acceder fácilmente a los contenedores de la ventana acoplable a través de la interfaz del puente en direcciones IP únicas / personalizadas.

Estuve golpeando mi cabeza contra la pared durante al menos 4 horas tratando de averiguar por qué no podía hacer funcionar ningún ejemplo documentado, hasta que de alguna manera encontré este problema, describiendo el problema perfectamente.

Por ahora, la solución mencionada por @justincormack (https://github.com/moby/moby/issues/22753#issuecomment-246054946) parece funcionar de manera aceptable. Estoy agregando soporte experimental de Docker a Drupal VM usando las instrucciones:

1. Agregue un host a /etc/hosts con sudo /etc/hosts (por ejemplo, 192.168.1.100 mysite.dev )
2. Cree un alias en la interfaz de loopback: sudo sudo ifconfig lo0 alias 192.168.1.100/24

3. Trae un contenedor con el siguiente pseudocomposición:

     version: "3"
   
     services:
       app:
         image: image-name
         ports:
           - 192.168.1.100:80:80
           - 192.168.1.100:443:443
         [...]
   

Esto parece funcionar perfectamente para mí, y aunque actualmente requiere un par de pasos manuales (que se evitan si se usan otras herramientas además de Docker ... algo que no quiero obligar a mis usuarios a hacer), me permite casi alcanza el nirvana de Docker en Mac.

Así que gracias por la solución, y espero que pueda encontrar una manera de hacer que la red puente funcione pronto (o simplemente abandonar macOS <10.12 😏)

@rogaha muchas gracias, 192.168.65.1 ha resuelto mi problema. Espero que esto no cambie en el futuro, a menos que encuentren una solución más limpia. A partir de Docker para Mac 17.0.3.1, esto ha permitido que mi contenedor se comunique con el servidor MySQL que se ejecuta en el host local de mi máquina.

@TheAntonioReyes Me alegro de que te haya funcionado. ¡Gracias por la respuesta!

Hola,

Estoy leyendo los documentos aquí: https://docs.docker.com/docker-for-mac/networking/#use -cases-and-workarounds, y estoy tratando de usar el _el nombre de DNS especial solo para Mac_ mencionado allí : docker.for.mac.localhost .

Si hago un ping en una terminal dentro del contenedor de la ventana acoplable, se resuelve en 192.168.65.1, y al hacer un curl en una aplicación que se ejecuta en mi mac, se recupera el resultado esperado.

Estoy usando esta imagen: https://github.com/elgalu/docker-selenium , y puedo abrir un navegador Chrome allí. Así que quería ir a http: //docker.for.mac.localhost : 80 y la conexión fue rechazada. Sin embargo, hacer http://192.168.65.1 : 80 funciona.

¿Me estoy perdiendo de algo? Quería comenzar a usar docker.for.mac.localhost .

Estoy usando esto: Versión 17.06.0-ce-mac18 (18433)

EDITAR : Parece que esto solo sucede en Chrome y este problema lo explica. https://github.com/docker/for-mac/issues/1837

Creo que usar docker.for.mac.localhost fue una mala decisión. El objetivo de los contenedores es que son portátiles y _deben_ no depender del tipo de host en el que residan. Si mi equipo está formado por la mitad de usuarios de Windows y la mitad de Mac, entonces el código dentro de nuestros contenedores deberá configurarse de manera diferente.

Me alegro de que haya un enfoque de nombre de host, solo creo que la reunión en la que se decidió este enfoque debería haber durado 5 minutos más.

docker.for.mac.localhost funcionó. Divertidísimo. https://docs.docker.com/docker-for-mac/networking/#use -cases-and-workarounds

Resolví este problema volviendo a docker-machine para Mac. La máquina VM docker es una distribución de Linux, lo que significa que crea una interfaz docker0 que tiene acceso al rango de red privada de los contenedores docker. Luego, en mi máquina host mac, creé una ruta para el rango de direcciones 172.18.xx de los contenedores que apunta a la dirección IP de la instancia de la máquina acoplable (192.168.99.100 en mi caso).

Esto permite que los paquetes destinados a la red de contenedores privados sean reenviados por mi sistema operativo mac a la dirección IP de la máquina virtual linux de la máquina docker, que sabe cómo llegar a los contenedores privados y les reenvía los paquetes directamente.

Creación de la ruta a la máquina acoplable vm para la red de contenedores privados

sudo route -n add -net 172.18.0.0/16 192.168.99.100

Puede obtener la dirección de la red de contenedores usando docker network inspect o docker inspect <container_name> .

Puede encontrar la ip del host en la ventana acoplable para mac ejecutando este comando:

docker run busybox ping -c 1 docker.for.mac.localhost | awk 'FNR==2 {print $4}' | sed s'/.$//'

Ejecute este comando

docker run -i -d --expose=80 <container_name> bash

Luego obtenga la dirección IP de

docker ps

si dice 0.0.0.0, funcionará bien una vez que el puerto esté expuesto o cualquier otra dirección IP escrita allí.

La solución es relativamente sencilla; IDK por qué Docker no lo soluciona.

Consulte https://github.com/AlmirKadric-Published/docker-tuntap-osx para obtener una solución alternativa que calce el binario del hiperkit.

Duplicado parcial de # 155 (y # 171, # 515, # 3484).

Estoy cerrando. Esto es por diseño y de todos modos no está relacionado con este repositorio.

Lo siguiente funciona maravillosamente para mí. Sin contenedores intermedios, sin solución de DNS.

De https://github.com/AlmirKadric-Published/docker-tuntap-osx#how -it-works:

Una vez hecho esto, la dirección IP 10.0.75.2 se puede utilizar como una puerta de enlace de enrutamiento de red para llegar a cualquier contenedor dentro de la máquina virtual host:
route add -net <IP RANGE> -netmask <IP MASK> 10.0.75.2

Gracias @pauldraper (!).

@pauldraper comentó el 14 de julio de 2019

La solución es relativamente sencilla; IDK por qué Docker no lo soluciona.

Consulte https://github.com/AlmirKadric-Published/docker-tuntap-osx para obtener una solución alternativa que calce el binario del hiperkit.

Mi versión de macOS:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.6
BuildVersion:   18G3020
$