instruction: Explain Docker containerization and best practices
output: Back
  Ask AI
  Start typing to search or try
  Contact support
  Manuals
  Get started
  Guides
  Networking overview
  Page options
  Copy page as Markdown for LLMs
  View page as plain text
  Ask questions with Docs AI
  Claude
  Open in Claude
  Container networking refers to the ability for containers to connect to and
  communicate with each other, or to non-Docker workloads.
  Containers have networking enabled by default, and they can make outgoing
  connections. 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,
  Packet filtering and firewalls
  User-defined networks
  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 and
  running a container in the created network:
  docker network create -d bridge my-net
  docker run --network
  my-net -itd --name
  container3 busybox
  Drivers
  The following network drivers are available by default, and provide core
  networking functionality:
  Driver
  Description
  bridge
  The default network driver.
  host
  Remove network isolation between the container and the Docker host.
  none
  Completely isolate a container from the host and other containers.
  overlay
  Overlay networks connect multiple Docker daemons together.
  ipvlan
  IPvlan networks provide full control over both IPv4 and IPv6 addressing.
  macvlan
  Assign a MAC address to a container.
  For more information about the different drivers, see
  Network drivers
  overview
  Connecting to multiple networks
  A container can be connected to multiple networks.
  For example, a frontend container may be connected to a bridge network
  with external access, and a
  --internal
  network
  to communicate with containers running backend services that do not need
  external network access.
  A container may also be connected to different types of network. For example,
  ipvlan
  network to provide internet access, and a
  bridge
  network for
  access to local services.
  When sending packets, if the destination is an address in a directly connected
  network, packets are sent to that network. Otherwise, packets are sent to
  a default gateway for routing to their destination. In the example above,
  ipvlan
  network's gateway must be the default gateway.
  The default gateway is selected by Docker, and may change whenever a
  container's network connections change.
  To make Docker choose a specific default gateway when creating the container
  or connecting a new network, set a gateway priority. See option
  gw-priority
  for the
  docker run
  docker network connect
  commands.
  The default
  gw-priority
  and the gateway in the network with the
  highest priority is the default gateway. So, when a network should always
  be the default gateway, it is enough to set its
  gw-priority
  docker run --network
  name
  gwnet,gw-priority
  --network anet1 --name myctr myimage
  docker network connect anet2 myctr
  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
  The following example runs a Redis container, with Redis binding to
  localhost
  , then running the
  redis-cli
  command and connecting to the Redis
  server over the
  localhost
  interface.
  docker run -d --name redis example/redis --bind 127.0.0.1
  docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1
  Published ports
  By default, when you create or run a container using
  docker create
  docker run
  containers on bridge networks don't expose any ports to the outside world.
  Use the
  --publish
  flag to make a port available to services
  outside the bridge network.
  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 port
  on the Docker host to TCP port
  in the container.
  -p 192.168.1.100:8080:80
  Map port
  on the Docker host IP
  to TCP port
  in the container.
  -p 8080:80/udp
  Map port
  on the Docker host to UDP port
  in the container.
  -p 8080:80/tcp -p 8080:80/udp
  Map TCP port
  on the Docker host to TCP port
  in the container, and map UDP port
  on the Docker host to UDP port
  in the container.
  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 (
  , or
  ) with the
  publish flag, only the Docker host and its containers can access the
  published container port.
  docker run -p 127.0.0.1:8080:80 -p
  '[::1]:8080:80'
  nginx
  Warning
  In releases older than 28.0.0, 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.
  You can enable inter-container communication by connecting the containers to the
  same network, usually a
  bridge network
  Ports on the host's IPv6 addresses will map to the container's IPv4 address
  if no host IP is given in a port mapping, the bridge network is IPv4-only,
  --userland-proxy=true
  (default).
  For more information about port mapping, including how to disable it and use
  direct routing to containers, see
  packet filtering and firewalls
  IP address and hostname
  When creating a network, IPv4 address allocation is enabled by default, it
  can be disabled using
  --ipv4=false
  . IPv6 address allocation can be enabled
  using
  --ipv6
  docker network create --ipv6 --ipv4
  false
  v6net
  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
  --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
  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. DNS requests will be forwarded from the container's network namespace so, for example,
  --dns=127.0.0.1
  refers to the container's own loopback address.
  --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. To pass additional hosts into a 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