remove - Mi contenedor docker no tiene internet
docker tag example (13)
Lo hice funcionar bien, pero ahora se detuvo. Intenté los siguientes comandos sin ningún resultado:
docker run -dns 8.8.8.8 base ping google.com
docker run base ping google.com
sysctl -w net.ipv4.ip_forward=1
- tanto en el host como en el contenedor
Todo lo que obtengo es unknown host google.com
. Docker versión 0.7.0
¿Algunas ideas?
PS ufw
deshabilitado
Actualizando esta pregunta con una respuesta para OSX (usando Docker Machine)
Si está ejecutando Docker en OSX utilizando Docker Machine, entonces lo siguiente funcionó para mí:
docker-machine restart
<...wait for it to restart, which takes up to a minute...>
docker-machine env
eval $(docker-machine env)
Entonces (al menos en mi experiencia), si haces ping a google.com desde un contenedor, todo estará bien.
El acceso a Internet no puede ser causado por la falta de configuración de proxy . En ese caso, el --network host
puede no funcionar tampoco. El proxy se puede configurar estableciendo las variables de entorno http_proxy
y https_proxy
:
docker run -e "http_proxy=YOUR-PROXY" /
-e "https_proxy=YOUR-PROXY"/
-e "no_proxy=localhost,127.0.0.1" ...
No se olvide de establecer no_proxy también, o todas las solicitudes (incluidas las de localhost) pasarán por el proxy.
Más información: Configuración de Proxy en Archlinux Wiki.
En Windows (8.1) eliminé la interfaz de la caja virtual (a través de taskmgr) y resolvió el problema.
Es posible que haya comenzado su docker con opciones de dns --dns 172.xxx
Tuve el mismo error y eliminé las opciones de /etc/default/docker
Las líneas:
# Use DOCKER_OPTS to modify the daemon startup options.
DOCKER_OPTS="--dns 172.x.x.x"
Estaba usando DOCKER_OPTS="--dns 8.8.8.8"
y luego descubrí que mi contenedor no tenía acceso directo a internet pero podía acceder a mi intranet corporativa. Cambié DOCKER_OPTS
a lo siguiente:
DOCKER_OPTS="--dns <internal_corporate_dns_address"
reemplazando internal_corporate_dns_address
con la dirección IP o FQDN de nuestro DNS y reiniciando el docker usando
sudo service docker restart
y luego generé mi contenedor y verifiqué que tenía acceso a internet.
La forma prevista de reiniciar el acoplador no es hacerlo manualmente, sino usar el service
o el comando init:
service docker restart
Lo primero que debe comprobar es ejecutar cat /etc/resolv.conf
en el contenedor acoplable . Si tiene un servidor DNS no válido, como nameserver 127.0.xx
, entonces el contenedor no podrá resolver los nombres de dominio en direcciones IP, por lo que ping google.com
fallará.
Lo segundo que debe comprobar es ejecutar cat /etc/resolv.conf
en el equipo host . Docker básicamente copia el /etc/resolv.conf
del /etc/resolv.conf
al contenedor cada vez que se inicia un contenedor. Entonces, si el /etc/resolv.conf
del /etc/resolv.conf
es incorrecto, entonces también lo hará el contenedor del /etc/resolv.conf
.
Si ha encontrado que el /etc/resolv.conf
del /etc/resolv.conf
es incorrecto, entonces tiene 2 opciones:
Hardcode el servidor DNS en daemon.json. Esto es fácil, pero no ideal si espera que el servidor DNS cambie.
/etc/resolv.conf
el/etc/resolv.conf
los/etc/resolv.conf
. Esto es un poco más complicado, pero se genera dinámicamente y no está codificando el servidor DNS.
1. Servidor DNS Hardcode en docker daemon.json
Editar
/etc/docker/daemon.json
{ "dns": ["10.1.2.3", "8.8.8.8"] }
Reinicie el daemon del acoplador para que los cambios surtan efecto:
sudo systemctl restart docker
Ahora cuando ejecuta / inicia un contenedor, la
/etc/resolv.conf
acoplable completará/etc/resolv.conf
con los valores dedaemon.json
.
2. /etc/resolv.conf
el /etc/resolv.conf
los /etc/resolv.conf
A. Ubuntu 16.04 y anterior
Para Ubuntu 16.04 y
/etc/resolv.conf
anteriores,/etc/resolv.conf
fue generado dinámicamente por NetworkManager.Comente la línea
dns=dnsmasq
(con un#
) en/etc/NetworkManager/NetworkManager.conf
Reinicie NetworkManager para regenerar
/etc/resolv.conf
:
sudo systemctl restart network-manager
Verificar en el host:
cat /etc/resolv.conf
B. Ubuntu 18.04 y posterior
Ubuntu 18.04 cambió para usar
systemd-resolved
para generar/etc/resolv.conf
. Ahora, de manera predeterminada, utiliza un caché DNS local 127.0.0.53. Eso no funcionará dentro de un contenedor, por lo que Docker utilizará de manera predeterminada el servidor DNS 8.8.8.8 de Google, lo que puede afectar a las personas que se encuentran detrás de un firewall./etc/resolv.conf
es en realidad un enlace simbólico (ls -l /etc/resolv.conf
) que apunta a/run/systemd/resolve/stub-resolv.conf
(127.0.0.53) de forma predeterminada en Ubuntu 18.04.Simplemente cambie el enlace simbólico para que apunte a
/run/systemd/resolve/resolv.conf
, que enumera los servidores DNS reales:
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Verificar en el host:
cat /etc/resolv.conf
Ahora debe tener un /etc/resolv.conf
válido en el host para que Docker copie en los contenedores.
Originalmente, mi contenedor Docker pudo llegar a Internet externo (este es un servicio / contenedor acoplable que se ejecuta en Amazon EC2).
Como mi aplicación es una API, seguí la creación de mi contenedor (logró extraer todos los paquetes que necesitaba) con la actualización de mis Tablas IP para enrutar todo el tráfico desde el puerto 80 al puerto donde mi API (que se ejecutaba en la ventana acoplable) era escuchando
Luego, más tarde, cuando intenté reconstruir el contenedor, falló. Después de mucha lucha, descubrí que mi paso anterior (establecer la regla de reenvío de puertos IPTable) estropeó la capacidad de conexión de red externa de la ventana acoplable.
Solución: detenga su servicio IPTable:
sudo service iptables stop
Reinicie The Docker Daemon:
sudo service docker restart
Luego, intenta reconstruir tu contenedor. Espero que esto ayude.
Seguir
Pasé por alto por completo que no tenía que meterme con las Tablas IP para reenviar el tráfico entrante a 80 al puerto en el que se estaba ejecutando la API que se ejecutaba en la ventana acoplable. En cambio, simplemente alias el puerto 80 al puerto en el que se ejecutaba la API en la ventana acoplable:
docker run -d -p 80:<api_port> <image>:<tag> <command to start api>
Para mí fue el firewall del host. Tuve que permitir DNS en el firewall del host. Y también tuvo que reiniciar Docker luego de cambiar la configuración del firewall del host.
Para mí fue una regla de reenvío de iptables. Por alguna razón, la siguiente regla, junto con las reglas de iptables de Docker, hizo que todo el tráfico saliente de los contenedores golpeara localhost:8080
:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080
Si está en OSX, es posible que deba reiniciar su máquina después de instalar Docker. Esto ha sido un problema a veces.
Solucionado siguiendo este consejo:
[...] ¿puedes intentar restablecer todo?
pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
docker -d
Obligará a Docker a recrear el puente y reiniciar todas las reglas de la red
https://github.com/dotcloud/docker/issues/866#issuecomment-19218300
Parece que la interfaz fue ''colgada'' de alguna manera.
Tuve el problema en Ubuntu 18.04. Sin embargo, el problema fue con el DNS. Estaba en una red corporativa que tiene su propio servidor DNS y bloquea otros servidores DNS. Esto es para bloquear algunos sitios web (pornografía, torrents, etc.)
Para resolver su problema
- encuentra tu DNS en la máquina host
use --dns your_dns como lo sugiere @jobin
docker run --dns your_dns -it --name cowsay --hostname cowsay debian bash