Moby: Não há docker0 no docker para mac?

Criado em 16 mai. 2016  ·  115Comentários  ·  Fonte: moby/moby

Resultado de docker version :

Client:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Wed Apr 27 00:34:20 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   8b63c77
 Built:        Tue May 10 10:39:20 2016
 OS/Arch:      linux/amd64

Resultado de docker info :

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 21
Server Version: 1.11.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 25
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: null host bridge
Kernel Version: 4.4.9-moby
Operating System: Alpine Linux v3.3
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.954 GiB
Name: moby
ID: DFWG:ZZBI:QGZP:CAFF:PZVX:WLED:3XNK:J2LK:UV3V:X2JR:VCGJ:QFBK
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): true
 File Descriptors: 17
 Goroutines: 38
 System Time: 2016-05-15T23:53:58.530098977Z
 EventsListeners: 1
Registry: https://index.docker.io/v1/

Detalhes adicionais do ambiente (AWS, VirtualBox, físico, etc.):

Etapas para reproduzir o problema:
1
2
3 -

Descreva os resultados que você recebeu:
Sem docker0 e absolutamente nenhuma maneira de se conectar a serviços em execução no host docker via gateway de ponte.
Eu tentei de tudo e pensei que estava ficando louco, então tentei exatamente as mesmas coisas no meu host ubuntu sem problemas

Descreva os resultados que você esperava:
Eu gostaria de poder me conectar ao meu redis local e a outros serviços sem precisar encaixá-los no dock ...

kinquestion platfordesktop versio1.11

Comentários muito úteis

Bem, não é realmente satisfatório, pois os macs geralmente não são servidores de produção, mas
máquinas de desenvolvimento.

Em minhas máquinas de produção, não me importo com o problema de não ser capaz de
conectar-se ao host.

Mas em uma máquina de desenvolvimento conectando-se a serviços no mesmo host de dentro de um
container é exatamente o cenário onde esta funcionalidade é desejada a
a maioria.

Todos 115 comentários

você achou ip no virtualbox ou no host?

Acho que o docker0 estava na VM virtualbox.

Estou falando sobre o docker para mac que está em beta e não funciona por meio de uma vm

Eu também estou enfrentando exatamente o mesmo problema. Endereço IP do host encontrado na máquina docker usando o comando abaixo. Assumindo que 0.0.0.0 representa o host, corrija-me se eu estiver errado aqui.
netstat -nr | grep '^ 0.0.0.0' | awk '{print $ 2}'
172.17.0.1

mas quando faço curl neste ip com uma porta onde estou rodando um servidor web ele dá conexão recusada.
curl 172.17.0.1:9000
curl: (7) Falha ao conectar à porta 9000 172.17.0.1: Conexão recusada

Não tenho certeza de como obter a correção adequada. Isso parece estar causando problemas, pois é necessário conectar-se ao serviço que será executado na máquina host.
Também encontrei uma maneira de corrigir o endereço IP da máquina host, configurando-o em DOCKER_OPTS.
DOCKER_OPTS = "- H tcp: //0.0.0.0 : 5000 -H unix: ///var/run/docker.sock --bip = 172.17.42.1 / 16"

mas onde no mac posso colocar essas opções? no ubuntu, ele pode ser colocado em / etc / default / docker.

Forneça instruções se isso pode ser corrigido no mac.

ping @justincormack talvez você tenha algumas dicas aqui.

@MiteshSharma exatamente, foi uma das primeiras coisas que tentei também e exatamente com os mesmos problemas

@NinoFloris Parece que nós dois estamos exatamente no mesmo lugar. No meu caso, estou executando o mysql na minha máquina host.
Ei pessoal,
Atualize se alguém for capaz de fazer isso.

Eu usei isso
https://docs.docker.com/engine/installation/mac/

não tenho certeza se o seu beta é especial

@HackToday é diferente, é a instalação do Mac baseada no VirtualBox; Docker para Mac está em beta.docker.com

Obrigado @thaJeztah Qualquer possível link de documento bom para a arquitetura do Mac Docker relacionada ou outros detalhes? Parece interessante

@HackToday https://blog.docker.com/2016/03/docker-for-mac-windows-beta/ dá um pouco mais, e há documentação, mas acho que é só se você estiver em beta; https://beta.docker.com/docs/. Se você se inscrever para o beta, me dê um "ping"; Posso tentar colocar você na lista de prioridades como contribuidor: sorria:

oh @thaJeztah Obrigado, pensei que era grátis para trabalhar e experimentar. Não precisa de nenhum especial para contribuir. Vou ler esse blog primeiro para entender antes de tentar. 😺

@HackToday é totalmente gratuito, apenas para não sobrecarregar a equipe, foi decidido lançá-lo como um beta "privado" primeiro, porque "muitos usuários '===" muitas perguntas de suporte ": smile:

Olá, sim, no momento não há uma maneira de rotear do Mac para a ponte docker0 . Podemos adicionar isso mais tarde, mas geralmente recomendamos que você se conecte de um contêiner ou expondo as portas. Isso é igual a redes de sobreposição de docker e também no Linux, às quais você não pode se conectar a partir do host.

Bem, não é realmente satisfatório, pois os macs geralmente não são servidores de produção, mas
máquinas de desenvolvimento.

Em minhas máquinas de produção, não me importo com o problema de não ser capaz de
conectar-se ao host.

Mas em uma máquina de desenvolvimento conectando-se a serviços no mesmo host de dentro de um
container é exatamente o cenário onde esta funcionalidade é desejada a
a maioria.

Eu preciso dessa interface docker0 também para usar no ambiente misto "docker + no host (do IDE) em execução de aplicativos".

A melhor solução atual é conectar-se aos seus contêineres de outro contêiner. No momento, não há como fornecer roteamento a esses contêineres devido a problemas com OSX que a Apple ainda não resolveu. estamos monitorando esse requisito, mas não podemos fazer nada a respeito no momento.

O comentário acima está correto?

Descobri que, de dentro dos contêineres docker-for-mac-beta, o host docker pode ser encontrado e conectado no endereço 172.17.0.1 usual (assumindo que o serviço está vinculado a 0.0.0.0 ).

@igrayson Isso ocorre porque os contêineres estão na VM com o daemon docker e certamente podem acessá-lo.
O problema é o roteamento do OSX para a rede VM.

O problema é o roteamento do OSX para a rede VM.

Esse não é o meu entendimento sobre a questão do OP:

Eu gostaria de poder me conectar ao meu redis local e a outros serviços sem precisar encaixá-los no dock ...

Estou executando o docker-for-mac-beta e não tenho problemas para me conectar ao redis e outros serviços locais - executando no OSX - fazendo-os ouvir em 0.0.0.0 e fazendo com que meus aplicativos dockerizados se conectem a 172.17.0.1 .

Visão geral

Eu tenho o mesmo problema. Usando Docker versão 1.11.1-beta14 (build: 8670) 984649fbd63d53a62b34f08b59694d4d569b74d5 . Meu pinata doctor diz que está tudo bem.

Não consigo curl um serviço em execução no host, por exemplo, um aplicativo ExpressJS ouvindo na porta 3001 , de dentro do contêiner:

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 é o meu IP WiFi._

Pinata

$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.

Possíveis duplicatas, referências, ajuda e etc.

Tive problemas semelhantes e encontrei 172. * ips não me permitiu conectar a uma instância local do mysql ligada a 0.0.0.0.

Eu poderia me conectar a ele com qualquer endereço IP roteável de minha máquina host. ifconfig e encontre um dos seus.

Agora, como faço para colocar isso dinamicamente no contêiner?

Tendo o mesmo problema que @Kazanz (mysql rodando localmente / não contido) tentando 172.17.0.1. Então, acho que vou tentar o Docker Toolbox? Seria útil se essa restrição fosse documentada. Não consegui encontrar nada sobre isso até que me deparei com esse problema.

Ping @londoncalling ^^

Alguma notícia sobre este? porque no Ubuntu (host), o aplicativo dentro do contêiner que escuta em 0.0.0.0 pode ser contatado pelo host usando IP 172.17.*.*. . Portanto, não há necessidade de expor a porta ao executar o contêiner.

No Docker para Mac Beta não posso fazer isso porque a ausência do docker0. Espero que seja corrigido na versão final :)

@thaJeztah @astasoft Vou dar uma olhada nisso hoje, obrigado @

Meu entendimento é que seu problema é acessar serviços executados em seu Mac a partir de um contêiner.
Se for esse o caso, você pode fazer isso usando o endereço IP exposto pela interface en0.
ifconfig en0 | grep "inet" | cut -d "" -f2

Por exemplo, se eu tiver um servidor da web em execução no meu Mac na porta 80:
docker run -it tutum / curl curl ifconfig en0 | grep "inet " | cut -d " " -f2

Funciona!

Você pode definir esse ip em uma variável de ambiente e passá-lo para o seu contêiner, como eu faço para o servidor X11 em https://github.com/chanezon/docker-tips/blob/master/x11/README.md

@chanezon Consegui fazer funcionar, mas não parece o ideal, já que esse IP muda frequentemente dependendo da rede à qual você está conectado. Eu esperava definir um IP mais ou menos estático representando minha ponte docker local.

@londoncalling Obrigado,

@chanezon Não, meu caso é acessar o serviço do Host para o container. Há um caso em que desejo executar o servidor web no meu host na porta 80 e na mesma porta do meu contêiner. Se eu expor a porta 80 do contêiner para o host, não poderei executar o servidor da web em minha máquina host. Este tipo de configuração é importante para o meu desenvolvimento.

Minha solução alternativa atual é voltar ao Docker Toolbox para Mac e encaminhar a porta na instância do Boot2Docker no 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

Então, posso chamar o serviço no contêiner usando boot2docker IP 192.168.99.100:80.

curl -i http://192.168.99.100

Estou tendo o seguinte problema que pode estar relacionado a isso.
Apenas para deixar claro, estou executando Docker Beta for Mac 1.12.0-beta21 (build: 10868) .

Basicamente, não consigo me conectar do host ao contêiner usando o endereço IP 172.17.0.2 , porque não há interface docker0 com o endereço 172.17.0.1 atribuído.

O contêiner é uma imagem do ubuntu e aqui está a informação relevante de rede

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

O host é um MacbookPro e como você pode ver no próximo snippet que ele não tem docker0 (ou qualquer interface para este assunto) com um endereço IP 172.17.0.1 , que é atribuído no contêiner como o portão.

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

Alguns colegas têm feito isso funcionando corretamente em hosts Ubuntus, então estou supondo que seja um problema do Mac ou ambiente local.
Qualquer ideia?

@robertoestivill não tem certeza sobre o caso de uso exato, mas se esse contêiner publicou uma porta, você pode acessá-la através de localhost:port

@nikdavis se quiser um IP estável, você pode adicionar um IP (qualquer um para o qual você nunca irá rotear) à interface de loopback lo0 do Mac e usá-lo.

Oi, imho, esta é uma grande diferença para docker no Linux. Há muita documentação por aí que simplesmente não se aplica. Também não tenho conhecimento de rede o suficiente para saber como conectar outro ip a lo0 e depois o quê. Seria muito útil se houvesse uma descrição das soluções alternativas (que não envolvem boot2docker) para esse problema e mencionasse isso nos documentos.

@justincormack @chanezon podemos trabalhar juntos nisso para obter alguns bons documentos sobre este problema?

@ pourquoi42
Você pode adicionar outro IP à interface lo0 da seguinte maneira:
CONTAINER_IP = $ (docker inspect --format '{{.NetworkSettings.IPAddress}}' nome do contêiner)
ifconfig lo0 alias $ CONTAINER_IP

Para removê-lo:
ifconfig lo0 -alias $ CONTAINER_IP

@itilk Não parece funcionar em MacOs. Tentei com names e 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>:~ $

Eu tinha o Docker 1.12.0 (build 10871) em execução no Darwin,
1) Todo o contêiner docker funciona bem;
2) O contêiner pode se comunicar com o host ;
3) A comunicação entre os contêineres funciona bem;

Onde está a interface virtual docker0 ? OU há alguma maneira de permitir que o host se conecte aos contêineres?

triste ler isto: Limitações conhecidas no 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.

Por enquanto, temos apenas uma maneira de conectar o host ao contêiner : Mapeamento de porta

Version 1.12.0-beta21 (build: 11019)
1) Todo o contêiner docker funciona bem.
2) O contêiner não pode se comunicar com o host.
3) A comunicação entre os contêineres funciona bem.
4) docker0 não disponível.

Ad.2)

Estou tendo uma instância de hugo que se liga a 0.0.0.0 na porta 1313 . curl de dentro do contêiner em execução retorna: curl: (7) Failed to connect to 172.19.0.1 port 1313: Connection refused .
Usar o endereço IP retornado por ifconfig en0 | grep "inet " | cut -d " " -f2 também não funciona:
curl: (7) Failed to connect to 172.19.27.228 port 1313: No route to host .

Olá a todos,

Eu encontrei um artigo de outro produto de contêiner ( não docker ): https://www.flockport.com/using-flockbox-with-xhyve/ , e também nem testei se realmente funciona.

ao final, menciona:

Você também pode usar o roteamento em vez do encaminhamento de porta descrito acima para acessar aplicativos em contêineres. O roteamento tornará a sub-rede inteira do contêiner dentro da VM disponível no host.

Se você preferir usar o roteamento em vez do encaminhamento de porta, é assim que funciona. Os comandos de roteamento precisam ser executados no host.

Se o IP da sua VM for 192.168.64.3 e a sub-rede do contêiner for 10.0.3.0/24, você pode criar uma rota com um comando como abaixo

sudo route -n add 10.0.3.0/24 192.168.64.3

O Xyhve cria uma interface bridge100 automaticamente para rede VM. Execute um ifconfig rápido para verificar se a interface bridge100 está ligada, por exemplo en4, e execute o comando abaixo.

sudo ifconfig bridge100 -hostfilter en4

Agora você deve ser capaz de executar ping em qualquer contêiner dentro da VM diretamente do host

ping 10.0.3.175

Para acessar o aplicativo em seu navegador Hosts, edite o arquivo / etc / hosts no host conforme descrito acima com encaminhamento de porta, mas desta vez associe o IP do contêiner à URL do aplicativo.

Desculpe, eu tenho conhecimento básico dos recursos de rede do Linux, mas é uma solução alternativa?

Não sei como obter o endereço IP do vm (alpine com docker) rodando dentro do xhyve, alguma ideia?

Olá @Kaijun , Não

@junjiemars não, o artigo que postei não é relacionado ao docker, é apenas outro produto de contêiner que funciona basicamente da mesma forma com o docker. (Host -> VM (xhyve) -> Containers)

Pensei se podemos nos inspirar neste artigo ou produto e aplicar a mesma solução alternativa para o próprio docker.

@Kaijun , eu sei que pode haver uma maneira de hackear xhyve para fazer as coisas. Se você fez isso, por favor, compartilhe seu hack.

@nikdavis se quiser um IP estável, você pode adicionar um IP (qualquer um para o qual você nunca irá rotear) à interface de loopback lo0 do Mac e usá-lo.

@justincormack Você se importaria de ser mais preciso como fazer isso? :)
Eu tentei o que @itilk postou, mas não funcionou para mim.

De um modo geral: existe um ETA para reintroduzir a rede docker0 no docker para mac beta?

THX

@georgehrke você pode fazer sudo ifconfig lo0 alias 10.200.10.1/24 - obviamente, escolha um endereço que você não encontrará localmente. Em seguida, você pode usar esse endereço para falar com o host, independentemente de ter uma conexão de rede.

Desculpe por não declarar meu problema com mais precisão.

Não estou tentando me conectar de um contêiner ao host, mas ao contrário.
Não consigo me conectar diretamente do meu host a um contêiner.

Eu estava usando docker inspect container_name para obter o IP.
Mas não consigo fazer ping ou abri-lo em um navegador, embora o Dockerfile tenha um servidor da web e EXPOSE 80 nele

Sim, existem dois problemas separados, que estão um tanto relacionados.

  1. Quero me conectar de um contêiner a um serviço no host. O Mac tem um endereço IP alterado ou nenhum se você não tiver acesso à rede.

A recomendação atual é anexar um IP não utilizado à interface lo0 no Mac, por exemplo, sudo ifconfig lo0 alias 10.200.10.1/24 , certifique-se de que seu serviço esteja escutando neste endereço ou 0.0.0.0 (ou seja, não 127.0.0.1 ). Então, os contêineres podem se conectar a este endereço.

  1. Quero me conectar a um contêiner do Mac.

A recomendação atual é publicar uma porta ou conectar-se a partir de outro contêiner. Observe que isso é o que você deve fazer até mesmo no Linux se o contêiner estiver em uma rede overlay, não em uma rede de ponte, já que elas não são roteadas.

Entendemos que não são ideais, mas existem vários problemas, em particular um bug no OSX que só foi corrigido no 10.12 e que não está sendo retransportado até onde podemos dizer, o que significa que não poderíamos suportar isso em todos os OSX suportados versões. Além disso, essa configuração de rede exigiria acesso root que estamos tentando evitar totalmente no Docker para Mac (atualmente temos um auxiliar de root muito pequeno que estamos tentando remover).

( @londoncalling , você deseja adicionar este resumo aos documentos?)

@justincormack, você quer dizer que todos os --net=host no MacOS Docker são inúteis?

@ m1ome não é completamente inútil - você pode se conectar a serviços que executa lá a partir de outros contêineres à medida que as portas são abertas na VM, mas as pessoas esperam que os serviços lá estejam disponíveis no Mac como portas publicadas, que não precisamos funciona ainda, pois isso é bastante complexo (não recebemos um feed de evento para portas que você abre assim, ao contrário de portas publicadas onde usamos eventos docker).

@justincormack há alguma solução alternativa para esse problema, pelo menos por enquanto? Se o Docker o tiver, acho que será muito útil escrevê-lo na documentação.

@justincormack posso adicionar sua escrita à documentação, mas acho que devemos incluir alguns exemplos específicos. Vou tentar sozinho, mas provavelmente precisarei da ajuda sua ou de outra pessoa. Entrarei em contato com você à medida que trabalhar nisso.

@londoncalling com certeza enviará alguns.

Em 30 de agosto de 2016, 18:28, "Victoria" [email protected] escreveu:

@justincormack https://github.com/justincormack posso adicionar o seu artigo
para os documentos, mas acho que devemos incluir alguns exemplos específicos. Vou tentar
eu mesmo, mas provavelmente precisarei da ajuda sua ou de outra pessoa. eu vou
retorno para você enquanto eu trabalho com isso

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/22753#issuecomment -243515932,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAdcPPgFU3H6TZCLcI0yUvbPn4tPwZj7ks5qlGhUgaJpZM4Ie9PB
.

@justincormack obrigado - dado este tópico, acho que precisamos de pelo menos dois exemplos, e talvez até três, como mostrado abaixo. O que você acha?

  1. Um exemplo de como acessar um serviço no host Mac a partir de um contêiner (por exemplo, funcionaria se o aplicativo fosse um servidor da web como nginx conectando-se a um banco de dados redis no host?)
  2. Um exemplo de conexão a um contêiner do Mac. Nosso exemplo atual de nginx cobre o segundo caso, já que expomos uma porta no comando run ; ou seja, docker run -d -p 80:80 --name webserver nginx ? @justincormack, mas devemos mostrar isso com e sem mapeamento de porta de acordo com o comentário de
  3. Um exemplo de como executar um aplicativo em um contêiner que usa um serviço em outro (por exemplo, repetir o exemplo nginx mais redis mas desta vez rodar redis em um contêiner?

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?

Eu realmente apreciaria um exemplo de conexão do Mac ao contêiner que não envolva mapeamento de porta. Meu usecase está executando um cluster mesos para desenvolvimento local. Se o portmapping for a única maneira de realizar a comunicação direta do Mac com um contêiner (escravo), é necessário trabalho extra para garantir que cada processo escravo mesos seja executado em uma porta exclusiva para que qualquer acesso do Mac (visualização dos logs para depuração, para exemplo) é consistente com as portas que o mesos usa internamente (caso contrário, os frameworks mesos renderizam URLs em painéis com números de porta internos que não funcionam no host).

No momento, eu uso docker-machine com uma rota do Mac para a rede virtual para que todos os endereços IP e números de porta que o cluster mesos usa "simplesmente funcionem" no Mac. Esta é uma solução muito simples.

@weaver conforme declarado, não há uma maneira atual de se conectar a um contêiner diretamente do host se ele não tiver uma porta publicada. Você pode se conectar de outro contêiner.

@justincormack Li todo o tópico tentando descobrir como conectar do meu mac ao container, assim como faço no Linux: container-ip: 8080 por exemplo. Pelo que entendi, isso deveria ser possível no MacOS (10.12), certo?

@matiasserrano você pode fazer isso com portmapping em, por exemplo, docker run -p 8080:8080

@ m1ome sim, eu sei disso. Mas não é escalável para mim. Sou um desenvolvedor e normalmente executo vários contêineres com apache / Nginx, então 80 está sempre em uso. Se eu fizer o que você propõe, primeiro preciso desabilitar o apache no meu mac, segundo preciso executar um contêiner por vez porque eles compartilham a mesma porta. Usar portas diferentes não é uma opção.
Por outro lado, damos containers para que os desenvolvedores comecem a trabalhar e, novamente, eles podem estar trabalhando em mais de um projeto ao mesmo tempo.
Portanto, a possibilidade de conectar do Mac aos containers usando seu IP é imprescindível para nós.

@matiasserrano Por que não usar -P para encaminhar as portas expostas para uma porta alta arbitrária automaticamente? Se você estiver procurando o IP do contêiner por meio de algo como docker inspect também é possível fazer uma operação muito semelhante para a porta exposta.

@nathanleclaire O problema não é saber a porta ou o IP do container, é basicamente a mesma solução do post anterior. Outra solução é criar uma VM vagrant para cada projeto e executar docker dentro ou usar docker-machine, que é basicamente o mesmo. Ambas as soluções não são aceitáveis ​​para nós. Preferimos usar o Vagrant.

Pelo que vale a pena, eu tenho um caso de uso semelhante ao @weaver (ou seja, acessando diretamente a rede do contêiner do host). Eu executo um cluster Spark via Docker, em sua própria rede. Eu uso docker-machine e adiciono uma rota estática docker0 interface

O Spark UI está disponível no nó mestre e inclui links HTML para todos os outros nós do cluster (por meio de seu endereço IP). Ao adicionar a rota estática, posso acessar a UI do Spark no mestre diretamente da minha máquina de desenvolvimento, e os links que ela gera para outros nós no cluster funcionam. Esses links também significam que não é apenas um caso de encaminhar a porta 7080 para o mestre operar sem docker0 - eu preciso ser capaz de alcançar toda a rede de alguma forma.

Acho que uma solução alternativa por agora seria fazer algum roteamento inteligente via nginx ou outro proxy da web em um contêiner adicional, embora eu não tenha um exemplo disso funcionando no momento.

@nathanleclaire O problema não é saber a porta ou o IP do container, é basicamente a mesma solução do post anterior.

Eu não entendo.

Você diz:

Portanto, a possibilidade de conectar do Mac aos containers usando seu IP é imprescindível para nós.

Por que endereços IP diferentes especificamente? Você está descrevendo os conflitos de porta como o problema aqui:

Sou um desenvolvedor e normalmente executo vários contêineres com apache / Nginx, então 80 está sempre em uso. Se eu fizer o que você propõe, primeiro preciso desabilitar o apache no meu mac, segundo preciso executar um contêiner por vez porque eles compartilham a mesma porta.

Com -P nenhum contêiner exporia a mesma porta, mesmo se todos estivessem escutando 80 internamente. Então, por que você ainda precisa desabilitar o Apache, etc.?

Outra solução é criar uma VM vagrant para cada projeto e executar docker dentro ou usar docker-machine, que é basicamente o mesmo. Ambas as soluções não são aceitáveis ​​para nós. Preferimos usar o Vagrant.

Se você está determinado a usar o Vagrant e não usará o Docker Machine ou o Docker para Mac, por que registrar / discutir aqui?

@nathanleclaire No Linux, usando os containers que criei, se eu quiser posso rodar 4 containers ao mesmo tempo, por exemplo, que expõe a porta 80. IE: Um para Magento, um para Drupal, um para Larabel e outro com um clean apache.

Cada container terá um IP, por exemplo, 192.100.200.1, 192.100.200.2, 192.100.200.3 e 192.100.200.4.

Com esses IPs, adiciono um host ao meu arquivo / etc / hosts, com um alias para cada um, por exemplo:

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

e, em seguida, entre nos servidores diretamente do navegador.

No Mac, não posso fazer isso, porque não consigo obter um IP para cada contêiner. Usar -P não é uma opção, porque em vez de ter um alias para cada contêiner, vou precisar usar algo como localhost: 8012 , para Magento, localhost: 9823 para drupal e assim por diante.

Outra solução alternativa é usar o vagrant com uma VM Linux para cada contêiner executando o contêiner interno e usando o mapeamento de porta 80:80. Com esta solução, docker não tem sentido, pois se eu criar uma máquina Vagrant, com as mesmas coisas que o container docker possui, é o mesmo. (Eu sei as diferenças entre Docker e Vagrant, e eu prefiro Docker em vez de Vagrant 100 vezes ...)

Espero que este caso de uso ajude você a entender por que é tão importante para nós obter o IP do contêiner.

O exemplo é com a porta 80, mas é aplicável a qualquer porta que você desejar.

@matiasserrano OK, suspeitei que pode estar relacionado ao desejo de mapeamento de DNS / nome de host, obrigado.

Estava tendo o mesmo problema (conectar ao host do contêiner). Usar 192.168.65.1 funcionou para mim. Não tenho certeza do que é isso, mas acho que aparece brevemente no log de pinata 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.

(Obrigado @feedthefire por me mostrar isso!)

Se você está determinado a usar o Vagrant e não usará o Docker Machine ou o Docker para Mac, por que registrar / discutir aqui?

@nathanleclaire Essa é uma resposta bastante inútil, talvez até insinuando que as pessoas não deveriam reclamar se discordarem. É esse tipo de atitude que dará ao Docker uma má fama quando se trata de uma discussão da comunidade.

Obrigado @cpoonolly , sua resposta é muito útil, mas acho que sua solução funciona na direção oposta: Container tentando se conectar ao Mac Host. O que eu preciso é exatamente o oposto: um host Mac tentando se conectar aos contêineres usando seu IP.

Ei pessoal. Esse problema se espalhou em uma variedade de direções e eu sugiro aos mantenedores do docker / docker fechá-lo e dividi-lo em vários sub-problemas. por exemplo, um para alcançar o IP do Mac de dentro da VM D4M e um para endereçabilidade de IP por contêiner (embora eu argumente que isso pode ser melhor simplesmente suportando o mapeamento DNS do contêiner / nome do host nativamente no D4M). Provavelmente no repositório Docker para Mac, pois este é o repositório para o "Motor" e, idealmente, deve haver tíquetes sobre questões de motor no Linux / Windows no rastreador.

Pelo que vale a pena, há _definidamente_ uma ponte docker0 no Docker para Mac VM. Você pode ver por si mesmo se executar um contêiner com --net host e executar ifconfig . Os vários problemas aqui não são sobre o que o título original sugere, no entanto: eles estão em torno de contêiner e rede de VM e visibilidade.

@icecrime @justincormack O que você acha. Obrigado a todos.

@nathanleclaire Essa é uma resposta muito melhor, obrigado, e eu concordo plenamente que dividir em várias questões secundárias seria uma boa maneira de avançar aqui

Concordo!!!! não há problema se você fizer isso!

@nathanleclaire @justincormack , enquanto isso os documentos do Beta 25 (a serem publicados hoje, um pouco atrasados ​​em relação aos lançamentos do aplicativo) fornecerão sugestões de Justin e Nathan para soluções alternativas nos tópicos Networking e FAQ. Embora eu saiba que isso não resolve os problemas de todos, será um começo fornecendo algumas soluções nos documentos e reconhecendo os problemas.

@matiasserrano no próximo beta, que

então se você adicionar

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

para /etc/hosts então você pode fazer:

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

então

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

então você deve ser capaz de se conectar diretamente a drupal.local etc.

@londoncalling devemos documentar isso para os próximos documentos beta.

@justincormack nitpick: este bloco está correto?

$ 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

os dois últimos devem ser 192.100.200.3 e 192.100.200.4 ? E por que o alias do cidr inteiro ( 192.100.200.1/24 é a faixa completa de 192.100.200.0 até 192.100.200.255 certo?)? Deve ser apenas um IP?

Desculpe, erro de digitação. Sim, /32 está bom.

@justincormack O DNS estará na interface gui em breve? Uma vez que o beta25 ainda não consegue resolver os nomes de dns através da VPN de túnel dividido, eu esperava executar o dnsmasq no meu host mac. Todas as outras portas do meu mac podem ser acessadas via 192.168.65.1 em contêineres internos, mas não por DNS.

Além disso, por que docker define 10 ip's [192.168.65.1 a 10] em /etc/resolv.conf?
PS: não use 192.100.xx, pois é um intervalo público. Use 192.168.xx

Estamos tentando evitar adicionar DNS à interface, mas apenas leia o
configurações do Mac. Lemos o arquivo hosts, mas leremos todos os
configurações em breve.

Os endereços do arquivo hosts mapeiam para os resolvedores de arquivo hosts, mas envolvendo
ao redor, para que o failover funcione corretamente.

Em 11 de setembro de 2016, 19h09, "Jijo Varghese" [email protected] escreveu:

@justincormack https://github.com/justincormack O DNS estará no gui
interface em breve? Já que o beta25 ainda não consegue resolver nomes de DNS
sobre a VPN de túnel dividido, eu esperava executar o dnsmasq no meu host mac. Todos os outros
portas no meu mac são acessíveis via 192.168.65.1 de dentro de contêineres, mas
não dns.

Além disso, por que docker define 10 ip's [192.168.65.1 a 10] em /etc/resolv.conf?
PS: não use 192.100.xx, pois é um intervalo público. Use 192.168.xx

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/22753#issuecomment -246194539,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAdcPEQcEyn3w7BPJCeaz5mlbgJx5etTks5qpEPUgaJpZM4Ie9PB
.

Só quero agradecer a @justincormack por isso:

Sim, existem dois problemas separados, que estão um tanto relacionados.

  1. Quero me conectar de um contêiner a um serviço no host. O Mac tem um endereço IP alterado ou nenhum se você não tiver acesso à rede.
    A recomendação atual é anexar um IP não utilizado à interface lo0 no Mac, por exemplo, sudo ifconfig lo0 alias 10.200.10.1/24 , certifique-se de que seu serviço esteja escutando neste endereço ou 0.0.0.0 (ou seja, não 127.0.0.1). Então, os contêineres podem se conectar a este endereço.

Embora não seja o ideal, isso deve funcionar para nós por enquanto. (testado e funcionando)

@justincormack

Estamos tentando evitar adicionar DNS à interface, mas apenas leia as configurações do Mac.
As combinações de VPNs são variadas e complexas, portanto, seria imprevisível supor que você sempre pode ler as configurações certas. https://github.com/docker/for-mac/issues/19 (fechado) ainda está quebrado para nós na VPN de túnel dividido. Provavelmente não é um problema do docker, mas apenas como nosso servidor vpn faz split-dns.

Outro, por exemplo, em meu local anterior, diríamos ao pessoal de QA e Dev para apontar para servidores de nomes diferentes dependendo de qual env eles queriam atingir. Se esse tipo de teste foi necessário apenas dentro do Docker, então esse é outro caso de uso a ser considerado. Obrigado.

Estamos trabalhando no suporte ao servidor de nomes divididos para VPN.

Em 13 de setembro de 2016, 18:48, "Jijo Varghese" [email protected] escreveu:

@justincormack https://github.com/justincormack

Estamos tentando evitar adicionar DNS à interface, mas apenas leia o
configurações do Mac.
As combinações de VPN são variadas e complexas, por isso seria míope
suponha que você sempre pode ler as configurações corretas. docker / para mac # 19
https://github.com/docker/for-mac/issues/19 (fechado) ainda está quebrado
para nós na VPN de túnel dividido. Provavelmente não é um problema do docker, mas apenas como
nosso servidor vpn faz split-dns.

Outra, por exemplo, no meu local anterior, diríamos ao pessoal de QA e Dev para apontar
para servidores de nomes diferentes, dependendo de qual env eles queriam atingir. Se isso
tipo de teste era necessário apenas dentro do Docker, então isso é mais um uso
caso a considerar. Obrigado.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/22753#issuecomment -246764433,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAdcPDXx3ziQv81fPBXpQHvU7_j9YWKQks5qpuHdgaJpZM4Ie9PB
.

Muito obrigado @justincormack , posso usar sua solução alternativa para acessar todos os meus contêineres diretamente, lo0 , o que me deixa pronto e funcionando com o Docker para Mac: +1:

Estou usando docker-compose para executar meus contêineres, então o último problema é a necessidade de configurar o encaminhamento de porta para vincular ao endereço IP correto no host, por contêiner. (Vincular a 0.0.0.0 me dará conflitos de porta quando eu tiver mais de um contêiner).

Não tenho certeza se alguém encontrou uma maneira de contornar isso? - Eu preciso efetivamente interpolar na configuração docker-compose, já que o endereço IP não é conhecido até que o contêiner seja inicializado.

(Agradeço que estamos nos desviando do problema original aqui).

@NoOrdInaryGuy deve funcionar nas versões mais recentes (estável e beta) - você pode especificar um IP específico que está no Mac para vincular, por exemplo, um endereço em lo0 .

@justincormack Sim, posso confirmar que funciona com sucesso. O único problema é ao usar docker-compose (particularmente com escalonamento, ou acho que você poderia apenas configurar endereços estáticos). Não é possível adicionar encaminhamentos de porta depois que um contêiner é iniciado, e não conheço uma maneira de fazer referência ao endereço IP real do contêiner para o arquivo de composição / Dockerfile em "tempo de execução", que acho que precisaria para para configurar o encaminhamento de porta para escutar no IP correto.

Estou resolvendo isso no momento, não usando docker-compose neste cenário e tendo um script bash personalizado para invocar docker, mas me pergunto se alguém mais pensou em uma solução melhor.

Isso parece promissor.

Meu caso de uso é semelhante ao que outros declararam. Criamos contêineres com serviços java em execução e tentamos testar esses serviços no sistema host. Executamos os testes em um pipeline jenkins, portanto, publicar portas no sistema host é problemático, porque o sistema host pode estar executando vários contêineres, todos tentando vincular as mesmas portas.

Normalmente, nós apenas "expomos" as portas e, em seguida, usamos 'docker inspect' para descobrir o IP do contêiner e nos conectar às portas de serviço nesse IP. Quando os desenvolvedores querem fazer os testes no Mac, usamos um truque do boot2docker para adicionar uma rota estática aos contêineres por meio do VirtualBox VM.

Estive observando o Mac Beta esperando que pudéssemos acessar as portas expostas usando um método semelhante, e esse truque do alias lo0 se parece com o tíquete.

Este provavelmente não é o lugar para uma solicitação de recurso, mas eu queria saber se seria possível adicionar um IP como entrada para a opção publicar tudo do docker run. Seria mais ou menos assim:

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

Então, se houvesse várias portas EXPOSED em my_test_image, eu poderia acessá-las através do alias IP.

Posso confirmar o docker0 ausente no ú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

Minha necessidade é o oposto da postagem original. Eu gostaria de acessar um endereço de contêiner fixo como 172.17.0.3 do host. Por exemplo, terei um aplicativo da web em execução e desejo acessá-lo do host; Eu prefiro não fazer o encaminhamento de porta nojento, que é necessário sem docker0 como uma interface no host. O VirtualBox tem rede somente de host e posso falar com esta rede somente de host a partir do host.

docker0 é visto se meu host for linux; só falta no docker-mac. Eu também não quero usar o virtualbox para executar o docker no mac.

Conforme descrito no documento: alguns tipos de bugs foram corrigidos no 10.12

Entendemos que essas soluções alternativas não são ideais, mas existem vários problemas. Em particular, _ há um bug no OSX que só foi corrigido em 10.12 _ e não está sendo feito backport até onde podemos dizer, o que significa que não poderíamos suportar isso em todas as versões OSX suportadas.

Então, eu perguntaria: o Docker já corrigiu esse problema no 10.12? ou ainda não, para compatibilidade de todas as versões.

@Kaijun não, precisamos oferecer suporte a várias versões do OSX, e a maneira como fazíamos antes tem outros prolems, então é improvável que voltemos a ele.

Olá, eu realmente aprecio toda a discussão neste tópico. Estou me perguntando: alguém poderia resumir (ou apontar) aquele problema real com o OS X que nos impede de estabelecer uma rota diretamente para os contêineres?

Eu vi comentários sobre como é algum problema com o OS X (aqui e em outros tópicos). Não consigo encontrar uma descrição sólida do que é realmente o problema, por que 10.12 foi meio que corrigido, etc.

(1) Por que isso funciona para algo como virtualbox / docker-machine, mas não para xhyve?

(2a) Mesmo que o docker não ofereça suporte a esse recurso apenas para 10.12, há algo que eu posso fazer se executar o 10.12 para hackear e fazê-lo funcionar?

(2b) Quais são os "outros problemas" com a "maneira como fazíamos antes"?

Eu realmente sinto muito se essas perguntas são idiotas (ou se a resposta já está neste tópico e eu a perdi).

Obrigado.

@weaver , estávamos usando anteriormente a opção vmnet em https://github.com/docker/hyperkit que cria uma ponte para a VM, que permite o roteamento de contêineres para o host em um IP na ponte. Porém, não permite o roteamento de maneira útil para os contêineres. Houve um CVE relacionado a isso expondo um servidor DNS aberto quando ativado, que foi corrigido no Sierra.

Existem muitas outras desvantagens no modo VMnet: sem suporte IPv6, pouco controle, temos que executar como root, não funciona com muitas configurações de VPN e muito mais. Começamos a usar o "modo VPN" como uma opção, que se tornou o padrão atual, e a outra opção foi removida após o problema de segurança.

A opção de que a ponte docker0 pareceria estar magicamente no Mac e não no Linux VM nunca foi implementada e como realmente não é possível, da mesma forma que não está disponível se você usar um host remoto . No entanto, as pessoas passaram a confiar em várias maneiras pelas quais podem usar várias configurações de roteamento e gostaríamos de tentar acomodar alguns desses casos de uso, mas não é muito fácil de fazer. O Virtualbox instala módulos do kernel no Mac para fazer isso, o que não vamos fazer.

Oi,

Em primeiro lugar, permita que todos parem de responder com respostas sobre redirecionamento de portas. Nós sabemos disso e não queremos isso, porque como muitos postaram agora, queremos uma porta simples no acesso IP.
Podemos tentar manter este tópico sobre soluções para isso?
Fiquei muito surpreso que isso não fosse possível. Não vejo porque precisamos de uma bridge no mac em si, desde que a rede seja roteável?

Então, para todos que desejam exatamente isso: remova o docker para mac, instale o docker toolbox e execute algo como:
rota sudo -n add 172.17.0.0/24 192.168.99.100
onde 172.xxx é a rede docker configurada no host do VirtualBox e o 192.xxx é o IP real desse host que pode ser roteado no mac (por meio da interface de rede do VirtualBox).
Ele simplesmente direciona o tráfego corretamente.

Isso pode ser adicionado à documentação do docker?

Uma vez que o exposto acima me deu o que eu quero, não procurei mais no xhyve.
A solução não seria inserir um comando semelhante ao anterior, que funcione com a configuração da rede a partir daí? Não consegui executar ping no endereço 192.168.65.x, portanto, adicionar uma rota não funcionaria. Se alguém postar o comando para habilitá-lo, o comando de rota deve funcionar também.

Problema resolvido? Seria ótimo se eles fossem documentados onde descrevessem a limitação do mac.
obrigado

@justincormack @ dmp42 @jeanlaurent você pode dar uma olhada no comentário @VGerris diretamente acima e me dizer como / onde você gostaria que este re: Toolbox e d4mac documentado?

É possível que isso possa ser corrigido para 10.12 e gerar um erro / aviso se a correção necessária de 10.12 não estiver presente no sistema? Você pode então documentar o / etc / host ou a solução alternativa da caixa de ferramentas para pessoas que executam o 10.11.

Imho ser capaz de acessar a rede de contêiner do host sem encaminhamento de porta ou configuração manual de rede é um recurso fundamental do docker. O fato de não funcionar como esperado é realmente um grande problema.

@justincormack - ainda não funciona para nossa configuração de DNS dividido após o lançamento beta de hoje.

repetindo de cima.

Estamos tentando evitar adicionar DNS à interface, mas apenas leia o
configurações do Mac.

As combinações de VPNs são variadas e complexas, portanto, seria imprevisível supor que você sempre pode ler as configurações certas.

@justincormack você não forneceu nenhuma solução para usuários do Docker para mac, o acesso ip é muito exigido, pois desenvolver com docker precisa de acesso direto ao serviço de container do docker-container e do host, o port forwarding não funciona para esta situação (o serviço terá endereço diferente de local diferente).

tambem o libvmnet nao ta tao bom, mas e uma solucao, sudo e aceitavel que nada !!!

a solução do dispositivo tap não precisa da permissão do sudo. pelo menos, o docker para mac deve fornecer alguma forma de hack para permitir que o desenvolvedor faça o seu caminho. por exemplo, o argumento do comando hyperkit start pode ser customizado pelos usuários.

No momento, o docker para mac é quase inútil para as pessoas.

merda !

Há alguma visão de se ou quando isso será consertado?

@justincormack : Além disso, esta configuração de rede exigiria acesso root, que estamos tentando evitar totalmente no Docker para Mac (atualmente temos um auxiliar de root muito pequeno que estamos tentando remover).

Por quê? No linux não é possível rodar o docker sem privilégios de root e está tudo bem, no OSX você quer evitar isso. Qual é a razão por trás disso? Portanto, de agora em diante o docker para OSX deve ser como o aplicativo do Facebook, não importa se o recurso principal não está funcionando, mas não requer privilégios de root?

IMO se o privilégio de root ajudar a resolver esse problema, corrija-o e, enquanto isso, tente obtê-lo sem root. No momento, estamos sem o recurso principal, que tínhamos antes, que planejamos todo o fluxo com base nesse recurso, e agora precisamos resolver muitos problemas.

Um meio-termo aceitável seria considerar este um recurso avançado. E quando os recursos avançados estão ativados, eles exigem privilégios adicionais?

O motivo pelo qual quero que esse recurso seja devolvido é para manter as coisas nas portas padrão. Temos uma convenção de nomenclatura padrão para todos os nossos serviços. Eu tenho registros DNS criados para mesmo dev que podem apontar para um IP estático em seu Mac. Cada contêiner recebe seu próprio IP, então é sempre a porta 3306, não importa em qual projeto você está trabalhando. Cada projeto é verdadeiramente separado, exatamente como no qa até o prd.

Agora, quando um desenvolvedor deseja se conectar ao MySQL em sua máquina local, ele deve olhar um gráfico para ver qual porta exclusiva o projeto possui. Projeto A é 3307, Projeto B é 3308, o que era o Projeto Q novamente? A randomização da porta também é desleixada porque não permite que você salve as configurações de conexão e tal. Você ainda precisa pesquisar o tempo todo.

Embora isso possa parecer um problema menor. Alternar entre projetos com muita frequência é chato, com essa padronização, ela remove uma série de etapas extras. Você quer trabalhar em um projeto diferente? Faça clone e execute make. TUDO é configurado a partir daí. Vários contêineres, credenciais, configurações, etc. Configuração de desenvolvimento de comando único.

+1, desesperadamente necessário: - /

Acabei de ler a documentação em https://docs.docker.com/docker-for-mac/networking/, então entendo os desafios envolvidos.

Infelizmente, este é um grande impedimento para o uso de docker nativo em nosso ambiente de desenvolvimento local. Eu esperava migrar do Virtualbox / Vagrant.

Nosso problema é que usamos o Consul para descoberta de serviços. Para o desenvolvimento local, queremos executar uma combinação de serviços do docker-compose e diretamente dos IDEs do desenvolvedor no Mac. Como os serviços executados em contêineres se registram no consul usando seu docker ip: port, os serviços executados fora do docker não podem ser integrados.

É claro que isso também é um problema em um cluster de vários hosts, mas isso é resolvido por sobreposição de rede (ou, em nosso caso, um script de ponto de entrada de introspecção ofensivamente hackeado que descobre o ip do host: mapeamentos de porta).

Parece que uma API de introspecção está finalmente sendo trabalhada para ajudar a resolver esse tipo de problema (https://github.com/docker/docker/issues/7472). Esperançosamente, a API de introspecção funcionará com docker para mac / windows também).

Ei pessoal, acho que há algo que vale a pena compartilhar relacionado a este tópico, podemos conversar com a máquina host de dentro dos contêineres usando o default IP criado por Docker for Mac/Windows .

O IP é 192.168.65.1

Você pode testá-lo seguindo as etapas abaixo:

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 ajude!

@rogaha Essa é uma informação interessante. Isso está documentado em algum lugar? Como você ficou sabendo disso?

Eu confirmei localmente no meu Mac que ele realmente alcança todo o caminho até o host (não apenas outro contêiner Docker) por meio de 192.168.65.1 .

Não tenho certeza. @thaJeztah @justincormack por acaso você sabe?

Sim, essa rota foi adicionada para dar suporte ao contato com o host.

Até que haja alguma nomenclatura padrão, geralmente não recomendamos o uso
isso, como obviamente não vai funcionar na produção, mas está tudo bem para passar como um
parâmetro.

Em 27 de fevereiro de 2017 08:49, "Roberto Gandolfo Hashioka" [email protected]
escrevi:

Não tenho certeza. @thaJeztah https://github.com/thaJeztah @justincormack
https://github.com/justincormack por acaso você conhece?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/22753#issuecomment-282777837 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAdcPJ3h5OrhxpgWao8by-qu-UmsuWIOks5rgv62gaJpZM4Ie9PB
.

@rogaha 192.168.65.1 não está funcionando para mim. Como você ficou sabendo desse IP?

Eu só queria adicionar um + 1 / subscribe junto com todos os outros neste tópico e adicionar outra voz à solicitação de recurso de ser capaz de acessar facilmente os contêineres do docker através da interface de ponte em endereços IP exclusivos / personalizados.

Eu estava batendo minha cabeça na parede por pelo menos 4 horas tentando descobrir por que eu não conseguia fazer nenhum exemplo documentado funcionar, até que de alguma forma encontrei este problema, descrevendo o problema perfeitamente.

Por enquanto, a solução alternativa mencionada por @justincormack (https://github.com/moby/moby/issues/22753#issuecomment-246054946) parece funcionar razoavelmente bem. Estou adicionando suporte Docker experimental ao Drupal VM usando as instruções:

  1. Adicione um host a /etc/hosts com sudo /etc/hosts (por exemplo, 192.168.1.100 mysite.dev )
  2. Crie um alias na interface de loopback: sudo sudo ifconfig lo0 alias 192.168.1.100/24
  3. Abra um contêiner com o seguinte pseudo-propósito:

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

Isso parece funcionar perfeitamente para mim e, embora atualmente exija algumas etapas manuais (que são evitadas se usar outras ferramentas no Docker ... algo que não quero forçar meus usuários a fazer), permite-me quase alcance o nirvana do Docker no Mac.

Obrigado pela solução alternativa e espero que você encontre uma maneira de fazer a rede de ponte funcionar em breve (ou simplesmente abandonar o macOS <10.12 😏)

@rogaha muito obrigado, 192.168.65.1 resolveu meu problema. Espero que isso não seja alterado no futuro, a menos que eles encontrem uma solução mais limpa. A partir do Docker para Mac 17.0.3.1, isso permitiu que meu contêiner se comunicasse com o servidor MySQL em execução no host local da minha máquina.

@TheAntonioReyes Fico feliz que funcionou para você. Obrigado pelo feedback!

Oi,

Estou lendo os documentos aqui: https://docs.docker.com/docker-for-mac/networking/#use -cases-and-workarounds e estou tentando usar o _o nome DNS especial somente para Mac_ mencionado lá : docker.for.mac.localhost .

Se eu fizer um ping em um terminal dentro do contêiner do docker, ele será resolvido para 192.168.65.1 e fazer um curl para um aplicativo em execução no meu mac recupera o resultado esperado.

Estou usando esta imagem: https://github.com/elgalu/docker-selenium , e posso abrir um navegador Chrome lá. Então, eu queria ir para http: //docker.for.mac.localhost : 80 e a conexão foi recusada. No entanto, fazer http://192.168.65.1 : 80 funciona.

Estou esquecendo de algo? Eu queria começar a usar docker.for.mac.localhost .

Estou usando este: Versão 17.06.0-ce-mac18 (18433)

EDIT : Parece que isso só acontece no Chrome e esse problema explica isso. https://github.com/docker/for-mac/issues/1837

Acho que usar docker.for.mac.localhost foi uma má decisão. O ponto principal dos contêineres é que eles são portáteis e _devem_ não depender do tipo de host em que residem. Se minha equipe for metade usuários do Windows e metade do Mac, então o código dentro de nossos contêineres terá que ser configurado de forma diferente.

Estou feliz que haja uma abordagem de hostname, só acho que a reunião onde essa abordagem foi decidida deveria ter durado mais 5 minutos.

docker.for.mac.localhost funcionou. Hilário. https://docs.docker.com/docker-for-mac/networking/#use -cases-and-workarounds

Eu contornei esse problema revertendo para docker-machine para Mac. A máquina VM docker é uma distro Linux, o que significa que ela cria uma interface docker0 que tem acesso ao intervalo de rede privada dos contêineres docker. Em seguida, em minha máquina host mac, criei uma rota para o intervalo de endereços 172.18.xx dos contêineres que aponta para o endereço IP da instância da máquina docker (192.168.99.100 no meu caso).

Isso permite que os pacotes destinados à rede privada de contêineres sejam encaminhados pelo meu mac OS para o endereço IP da VM linux da máquina docker, que sabe como chegar aos contêineres privados e encaminha os pacotes diretamente para eles.

Criando a rota para a máquina docker vm para a rede de contêiner privada

sudo route -n add -net 172.18.0.0/16 192.168.99.100

Você pode obter o endereço da rede de contêineres usando docker network inspect ou docker inspect <container_name> .

Você pode encontrar o ip do host no docker para mac executando este comando:

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

Execute este comando

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

Em seguida, pegue o endereço IP de

docker ps

se indicar 0.0.0.0, funcionará bem assim que a porta for exposta ou qualquer outro endereço IP escrito nela.

A solução é relativamente simples; IDK por que o Docker não corrige isso.

Consulte https://github.com/AlmirKadric-Published/docker-tuntap-osx para obter uma solução alternativa que corrige o binário do hyperkit.

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

Estou fechando Isso ocorre por design e, de qualquer forma, não está relacionado a este repo.

O que segue funciona maravilhosamente bem para mim. Sem contêineres intermediários, sem solução alternativa de DNS.

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

Uma vez feito isso, o endereço IP 10.0.75.2 pode ser usado como um gateway de roteamento de rede para alcançar qualquer contêiner dentro da Máquina Virtual Host:
route add -net <IP RANGE> -netmask <IP MASK> 10.0.75.2

Obrigado @pauldraper (!).

@pauldraper comentou em 14 de julho de 2019

A solução é relativamente simples; IDK por que o Docker não corrige isso.

Consulte https://github.com/AlmirKadric-Published/docker-tuntap-osx para obter uma solução alternativa que corrige o binário do hyperkit.

Minha versão do macOS:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.6
BuildVersion:   18G3020
$
Esta página foi útil?
1 / 5 - 1 avaliações