You can create custom, user-defined networks, and connect multiple containers to the same network. Once connected to a user-defined network, containers can communicate with each other using container IP addresses or container names.
The following example creates a network using the bridge network driver:
$ docker network create -d bridge my-net
Running a container in the created network:
$ docker run --network=my-net -itd --name=container3 busybox
👉 Container networks
In addition to user-defined networks, you can attach a container to another container’s networking stack directly, using the --network container:<name|id> flag format.
The following flags aren’t supported for containers using the container: networking mode:
--add-host--hostname--dns--dns-search--dns-option--mac-address--publish--publish-all--expose
👉 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:
-p 8080:80: Map port 8080 on the Docker host to TCP port 80 in the container.
-p 192.168.1.100:8080:80: Map port 8080 on the Docker host IP 192.168.1.100 to TCP port 80 in the container.
-p 8080:80/udp: Map port 8080 on the Docker host to UDP port 80 in the container.
-p 8080:80/tcp -p 8080:80/udp: Map TCP port 8080 on the Docker host to TCP port 80 in the container, and map UDP port 8080 on the Docker host to UDP port 80 in the container.
👉 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.
You can connect a running container to multiple networks, either by passing the --network flag multiple times when creating the container, or using the docker network connect command for already running containers. In both cases, you can use the --ip or --ip6 flags to specify the container's IP address on that particular network.
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
Containers use the same DNS servers as the host by default, but you can override this with --dns.
By default, containers inherit the DNS settings 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:
--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.
👉Custom hosts
Your container will have lines in /etc/hosts which define the hostname of the container itself, as well as localhost and a few other common things. Custom hosts, defined in /etc/hosts on the host machine, aren't inherited by containers.