Linux docker ip address

Docker Tip — How to use the host’s IP Address inside a Docker container on macOS, Windows, and Linux

Once in a while, you may need your Docker host’s IP address. For instance, you need to be able to connect to the host network from inside a Docker container to access your app or database running locally on the host. Debugging or reverse proxies running on your host are two additional example use-cases. I’ll show you how to easily make this work simultaneously for macOS, Windows, and Linux — because their docker networking settings differ.

Docker Networking on macOS and Windows vs. Linux

The host has a changing IP address (or none if you have no network access). From 18.03 onwards our recommendation is to connect to the special DNS name host.docker.internal , which resolves to the internal IP address used by the host. This is for development purpose and will not work in a production environment outside of Docker Desktop for Mac/Windows. The gateway is also reachable as gateway.docker.internal . Source: https://docs.docker.com/docker-for-mac/networking/#use-cases-and-workarounds
Source: https://docs.docker.com/docker-for-windows/networking/#use-cases-and-workarounds

On Docker for Linux, the IP address of the gateway between the Docker host and the bridge network is 172.17.0.1 if you are using default networking. Do you see the problem already? They are different, so you cannot simply run docker-compose up -d and all operating systems behave the same. But I got you covered, there’s an easy approach to make this work.

Setup docker-compose

I’ve seen some suggestions, like creating a Linux-specific config file docker-compose.override.yml (docs), but the solution a co-worker of mine came up with seems more elegant and less complex to me.

# docker-compose.yml version: '3.7' services: app: image: your-app:latest ports: - "8080:8080" environment: DB_UPSTREAM: http://$:3000 

So, what is happening here? The DB_UPSTREAM should point to the host’s IP and port 3000. $ is the critical piece here. This expression tells docker-compose to either us the environment variable DOCKER_GATEWAY_HOST or use the fallback host.docker.internal when resolving this value. On both macOS and Windows it works out of the box now without anything left to do. 🚀 If you are running this stack on Linux you need to have the DOCKER_GATEWAY_HOST environment variable set for the Docker gateway host. Simply put this line into your .bashrc ( .bash_profile or .zshrc ):

export DOCKER_GATEWAY_HOST=172.17.0.1 

Now you can start the stack from macOS, Windows, and Linux without further configuration or overwrites. If you stick to this pattern — as we do — this works for every project of your company. Great, isn’t it? I hope this saves you some time!

References

• compose-file#extra_hosts: an entry with the ip address and hostname is created in /etc/hosts inside containers at build-time.

Источник

Networking overview

Container networking refers to the ability for containers to connect to and communicate with each other, or to non-Docker workloads.

A container has no information about what kind of network it’s attached to, or whether their peers are also Docker workloads or not. A container only sees a network interface with an IP address, a gateway, a routing table, DNS services, and other networking details. That is, unless the container uses the none network driver.

This page describes networking from the point of view of the container, and the concepts around container networking. This page doesn’t describe OS-specific details about how Docker networks work. For information about how Docker manipulates iptables rules on Linux, see Packet filtering and firewalls.

Published ports

By default, when you create or run a container using docker create or docker run , the container doesn’t expose any of its ports to the outside world. Use the —publish or -p flag to make a port available to services outside of Docker. This creates a firewall rule in the host, mapping a container port to a port on the Docker host to the outside world. Here are some examples:

Flag value	Description
-p 8080:80	Map TCP port 80 in the container to port 8080 on the Docker host.
-p 192.168.1.100:8080:80	Map TCP port 80 in the container to port 8080 on the Docker host for connections to host IP 192.168.1.100 .
-p 8080:80/udp	Map UDP port 80 in the container to port 8080 on the Docker host.
-p 8080:80/tcp -p 8080:80/udp	Map TCP port 80 in the container to TCP port 8080 on the Docker host, and map UDP port 80 in the container to UDP port 8080 on the Docker host.

Important

Publishing container ports is insecure by default. Meaning, when you publish a container’s ports it becomes available not only to the Docker host, but to the outside world as well.

If you include the localhost IP address ( 127.0.0.1 ) with the publish flag, only the Docker host can access the published container port.

$ docker run -p 127.0.0.1:8080:80 nginx 

Warning

Hosts within the same L2 segment (for example, hosts connected to the same network switch) can reach ports published to localhost. For more information, see moby/moby#45610

If you want to make a container accessible to other containers, it isn’t necessary to publish the container’s ports. Inter-container communication is enabled by connecting the containers to the same network, usually a bridge network.

IP address and hostname

By default, the container gets an IP address for every Docker network it attaches to. A container receives an IP address out of the IP subnet of the network. The Docker daemon performs dynamic subnetting and IP address allocation for containers. Each network also has a default subnet mask and gateway.

When you connect an existing container to a different network using docker network connect , you can use the —ip or —ip6 flags on that command to specify the container’s IP address on the additional network.

When a container starts, it can only attach to a single network, using the —network flag. You can connect a running container to multiple networks using the docker network connect command. When you start a container using the —network flag, you can specify the IP address for the container on that network using the —ip or —ip6 flags.

In the same way, a container’s hostname defaults to be the container’s ID in Docker. You can override the hostname using —hostname . When connecting to an existing network using docker network connect , you can use the —alias flag to specify an additional network alias for the container on that network.

DNS services

By default, containers inherit the DNS settings of the host, as defined in the /etc/resolv.conf configuration file. Containers that attach to the default bridge network receive a copy of this file. Containers that attach to a custom network use Docker’s embedded DNS server. The embedded DNS server forwards external DNS lookups to the DNS servers configured on the host.

You can configure DNS resolution on a per-container basis, using flags for the docker run or docker create command used to start the container. The following table describes the available docker run flags related to DNS configuration.

Flag	Description
—dns	The IP address of a DNS server. To specify multiple DNS servers, use multiple —dns flags. If the container can’t reach any of the IP addresses you specify, it uses Google’s public DNS server at 8.8.8.8 . This allows containers to resolve internet domains.
—dns-search	A DNS search domain to search non-fully-qualified hostnames. To specify multiple DNS search prefixes, use multiple —dns-search flags.
—dns-opt	A key-value pair representing a DNS option and its value. See your operating system’s documentation for resolv.conf for valid options.
—hostname	The hostname a container uses for itself. Defaults to the container’s ID if not specified.

Nameservers with IPv6 addresses

If the /etc/resolv.conf file on the host system contains one or more nameserver entries with an IPv6 address, those nameserver entries get copied over to /etc/resolv.conf in containers that you run.

For containers using musl libc (in other words, Alpine Linux), this results in a race condition for hostname lookup. As a result, hostname resolution might sporadically fail if the external IPv6 DNS server wins the race condition against the embedded DNS server.

It’s rare that the external DNS server is faster than the embedded one. But things like garbage collection, or large numbers of concurrent DNS requests, can result in a roundtrip to the external server being faster than local resolution, on some occasions.

Custom hosts

Custom hosts, defined in /etc/hosts on the host machine, aren’t inherited by containers. To pass additional hosts into container, refer to add entries to container hosts file in the docker run reference documentation.

Proxy server

If your container needs to use a proxy server, see Use a proxy server.

Источник