DEV Community: Megha Sharma

How Docker Compose works

Megha Sharma — Tue, 27 Jan 2026 10:00:04 +0000

Docker Compose relies on a YAML configuration file, usually named compose.yaml.

The compose.yaml file follows the rules provided by the Compose Specification in how to define multi-container applications.

👉 Compose Specification:

The Compose Specification is the latest and recommended version of the Compose file format. It helps you define a Compose file which is used to configure your Docker application’s services, networks, volumes, and more.

Legacy versions 2.x and 3.x of the Compose file format were merged into the Compose Specification. It is implemented in versions 1.27.0 and above (also known as Compose V2) of the Docker Compose CLI.

👉 The Compose file

The default path for a Compose file is compose.yaml (preferred) or compose.yml that is placed in the working directory. Compose also supports docker-compose.yaml and docker-compose.yml for backwards compatibility of earlier versions. If both files exist, Compose prefers the canonical compose.yaml.

Multiple Compose files can be merged together to define the application model. The combination of YAML files is implemented by appending or overriding YAML elements based on the Compose file order you set. Simple attributes and maps get overridden by the highest order Compose file, lists get merged by appending. Relative paths are resolved based on the first Compose file’s parent folder, whenever complimentary files being merged are hosted in other folders. As some Compose file elements can both be expressed as single strings or complex objects, merges apply to the expanded form.

If you want to reuse other Compose files, or factor out parts of your application model into separate Compose files, you can also use include. This is useful if your Compose application is dependent on another application which is managed by a different team, or needs to be shared with others.

Example:
Consider an application split into a frontend web application and a backend service.

The frontend is configured at runtime with an HTTP configuration file managed by infrastructure, providing an external domain name, and an HTTPS server certificate injected by the platform’s secured secret store.

And The backend stores data in a persistent volume.

Both services communicate with each other on an isolated back-tier network, while the frontend is also connected to a front-tier network and exposes port 443 for external usage.

The example application is composed of the following parts:

2 services, backed by Docker images: webapp and database
1 secret (HTTPS certificate), injected into the frontend
1 configuration (HTTP), injected into the frontend
1 persistent volume, attached to the backend
2 networks

services:
  frontend:
    image: example/webapp
    ports:
      - "443:8043"
    networks:
      - front-tier
      - back-tier
    configs:
      - httpd-config
    secrets:
      - server-certificate

  backend:
    image: example/database
    volumes:
      - db-data:/etc/data
    networks:
      - back-tier

volumes:
  db-data:
    driver: flocker
    driver_opts:
      size: "10GiB"

configs:
  httpd-config:
    external: true

secrets:
  server-certificate:
    external: true

networks:
  # The presence of these objects is sufficient to define them
  front-tier: {}
  back-tier: {}

let’s break down each part of the Docker Compose file you provided step by step:

👉 Services Section:

frontend: This section defines a service named frontend. It uses the Docker image example/webapp to create containers. The service exposes port 443 of the container to port 8043 on the host machine. This means that incoming traffic on port 8043 of the host will be directed to port 443 inside the container running the frontend service.

ports: Maps the host machine's port 8043 to the container's port 443.
networks: Connects the frontend service to two Docker networks: front-tier and back-tier. This allows the frontend service to communicate with other services connected to these networks.
configs: Associates the frontend service with an external configuration named httpd-config. This configuration likely contains settings for an HTTP server like Apache.
secrets: Links the frontend service with an external secret named server-certificate. This secret probably contains SSL certificates or other sensitive information needed by the web server.

backend: This section defines a service named backend that uses the Docker image example/database to create containers. The backend service is simpler compared to frontend.

volumes: Mounts a Docker volume named db-data to the container's /etc/data directory. This volume is used to persist data for the database service.
networks: Connects the backend service to the back-tier Docker network. This network likely facilitates communication between backend services.

👉 Volumes Section:

db-data: Defines a Docker volume named db-data using the Flocker driver. The volume's driver options specify a size of 10GiB. This volume is used by the backend service to store data persistently.

👉 Configs Section:

httpd-config: Specifies an external configuration named httpd-config. This configuration is likely used by the frontend service, possibly containing settings for an Apache HTTP server.

👉 Secrets Section:

server-certificate: Specifies an external secret named server-certificate. This secret is used by the frontend service, possibly containing SSL certificates or other sensitive information required by the web server.

👉 Networks Section:

front-tier and back-tier: Defines two Docker networks named front-tier and back-tier. Although the definition in the file is empty, referencing these networks within services automatically creates and connects containers to them. These networks enable communication between services and provide isolation and segmentation within the Docker environment.

This Docker Compose file sets up a frontend web application (frontend service) with a specific image, ports, networks, configurations, and secrets. It also includes a backend database (backend service) with its own image, volume, and network configurations. The file ensures that the necessary volumes, configurations, secrets, and networks are available for the services to function properly within the Docker environment.

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: Installing Docker Compose
Medium Profile: Meghasharmaa

Installing Docker Compose

Megha Sharma — Wed, 21 Jan 2026 09:51:40 +0000

Here are three common scenarios for installing Docker Compose:

Scenario one: Install Docker Desktop

The easiest and recommended way to get Docker Compose is to install Docker Desktop. Docker Desktop includes Docker Compose along with Docker Engine and Docker CLI which are Compose prerequisites.

Docker Desktop is available on:

Linux
Mac
Windows

If you have already installed Docker Desktop, you can check which version of Compose you have by selecting About Docker Desktop from the Docker menu.

Scenario two: Install the Compose plugin

If you already have Docker Engine and Docker CLI installed, you can install the Compose plugin from the command line, by either:

Using Docker’s repository
Downloading and installing manually

Scenario three: Install the Compose standalone

You can install the Compose standalone on Linux or on Windows Server.

👉 Install the Docker Compose plugin:

To install the Compose plugin on Linux, you can either:

Set up Docker’s repository on your Linux system.
Install Compose manually.

👉 Install using the repository:

Set up the repository. Find distro-specific instructions in:
Ubuntu | CentOS | Debian | Raspberry Pi OS | Fedora | RHEL | SLES.
Update the package index, and install the latest version of Docker Compose:
For Ubuntu and Debian, run:

$ sudo apt-get update
$ sudo apt-get install docker-compose-plugin

For RPM-based distros, run:

$ sudo yum update
$ sudo yum install docker-compose-plugin

Verify that Docker Compose is installed correctly by checking the version.

$ docker compose version

Expected output:

Docker Compose version vN.N.N

Where vN.N.N is placeholder text standing in for the latest version.

👉 Install the plugin manually:

To download and install the Compose CLI plugin, run:

$ DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker}
$ mkdir -p $DOCKER_CONFIG/cli-plugins
$ curl -SL https://github.com/docker/compose/releases/download/v2.26.1/docker-compose-linux-x86_64 -o $DOCKER_CONFIG/cli-plugins/docker-compose

This command downloads the latest release of Docker Compose (from the Compose releases repository) and installs Compose for the active user under $HOME directory.

To install:

Docker Compose for all users on your system, replace ~/.docker/cli-plugins with /usr/local/lib/docker/cli-plugins.
A different version of Compose, substitute v2.26.1 with the version of Compose you want to use.
For a different architecture, substitute x86_64 with the architecture you want.

Apply executable permissions to the binary:

$ chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose

or, if you chose to install Compose for all users:

$ sudo chmod +x /usr/local/lib/docker/cli-plugins/docker-compose

Test the installation.

$ docker compose version


Docker Compose version v2.26.1

👉 Install Compose standalone

On Linux:

To download and install Compose standalone, run:

$ curl -SL https://github.com/docker/compose/releases/download/v2.26.1/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose

Apply executable permissions to the standalone binary in the target path for the installation.

Test and execute compose commands using docker-compose.

On Windows Server:

Follow these instructions if you are running the Docker daemon and client directly on Microsoft Windows Server and want to install Docker Compose.

GitHub now requires TLS1.2. In PowerShell, run the following:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12Run PowerShell as an administrator. When asked if you want to allow this app to make changes to your device, select Yes in order to proceed with the installation.

Run the following command to download the latest release of Compose (v2.26.1):

 Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/v2.26.1/docker-compose-windows-x86_64.exe" -Destination $Env:ProgramFiles\Docker\docker-compose.exe

Test the installation.

docker-compose.exe version


Docker Compose version v2.26.1

👉 Uninstall Docker Compose

Uninstalling Docker Compose depends on the method you have used to install Docker Compose.

Uninstalling the Docker Compose CLI plugin:

To remove the Compose CLI plugin, run:
Ubuntu, Debian:

$ sudo apt-get remove docker-compose-plugin

RPM-based distros:

$ sudo yum remove docker-compose-plugin

Manually installed:

If you used curl to install Compose CLI plugin, to uninstall it, run:

$ rm $DOCKER_CONFIG/cli-plugins/docker-compose

Remove for all users:

Or, if you have installed Compose for all users, run:

$ rm /usr/local/lib/docker/cli-plugins/docker-compose

Inspect the location of the Compose CLI plugin:

To check where Compose is installed, use:

$ docker info --format '{{range .ClientInfo.Plugins}}{{if eq .Name "compose"}}{{.Path}}{{end}}{{end}}'

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: Docker Compose overview
Medium Profile: Meghasharmaa

Docker Compose overview

Megha Sharma — Sun, 11 Jan 2026 10:27:02 +0000

Docker Compose is a tool that simplifies the management of multi-container Docker applications. It allows you to define and run multi-container Docker applications using a single YAML file.

Docker Compose is a tool for defining and running multi-container applications. It is the key to unlocking a streamlined and efficient development and deployment experience.

Compose simplifies the control of your entire application stack, making it easy to manage services, networks, and volumes in a single, comprehensible YAML configuration file. Then, with a single command, you create and start all the services from your configuration file.

Compose works in all environments; production, staging, development, testing, as well as CI workflows. It also has commands for managing the whole lifecycle of your application:

Start, stop, and rebuild services
View the status of running services
Stream the log output of running services
Run a one-off command on a service

👉 Key benefits of Docker Compose

Using Docker Compose offers several benefits that streamline the development, deployment, and management of containerized applications:

Simplified control: Docker Compose allows you to define and manage multi-container applications in a single YAML file. This simplifies the complex task of orchestrating and coordinating various services, making it easier to manage and replicate your application environment.
Efficient collaboration: Docker Compose configuration files are easy to share, facilitating collaboration among developers, operations teams, and other stakeholders. This collaborative approach leads to smoother workflows, faster issue resolution, and increased overall efficiency.
Rapid application development: Compose caches the configuration used to create a container. When you restart a service that has not changed, Compose re-uses the existing containers. Re-using containers means that you can make changes to your environment very quickly.
Portability across environments: Compose supports variables in the Compose file. You can use these variables to customize your composition for different environments, or different users.
Extensive community and support: Docker Compose benefits from a vibrant and active community, which means abundant resources, tutorials, and support. This community-driven ecosystem contributes to the continuous improvement of Docker Compose and helps users troubleshoot issues effectively.
Security if internal container network: In Docker Compose, all containers specified in the compose file are connected to the same internal network, shielding them from unauthorized access. It not only enhances security but also streamlines network management for multi-container applications.
Host Isolation: Isolation is paramount in containerized environments, and Docker Compose provides a level of isolation by encapsulating each application component within its container. This prevents conflicts between dependencies and ensures that changes made to one component do not affect others. Docker Compose allows developers to define network and volume configurations, further enhancing isolation and security.

👉 Common use cases of Docker Compose

⚪ Development environments:

Docker Compose is extensively used for creating consistent and reproducible development environments. Developers define their application’s stack, including services like databases, web servers, caching systems, etc., in a Compose file. This allows team members to easily set up the development environment with a single command (docker-compose up) and ensures that everyone works in an environment that closely resembles production.

When you’re developing software, the ability to run an application in an isolated environment and interact with it is crucial. The Compose command line tool can be used to create the environment and interact with it.

The Compose file provides a way to document and configure all of the application’s service dependencies (databases, queues, caches, web service APIs, etc). Using the Compose command line tool you can create and start one or more containers for each dependency with a single command (docker compose up).

Together, these features provide a convenient way for you to get started on a project. Compose can reduce a multi-page “developer getting started guide” to a single machine-readable Compose file and a few commands.

⚪ Automated testing environments:

Compose is valuable for setting up isolated testing environments. Testers can use Docker Compose to deploy the application stack for integration testing, regression testing, or performance testing. By defining the entire environment in a Compose file, testing teams can ensure that tests are conducted in a consistent and controlled environment.

An important part of any Continuous Deployment or Continuous Integration process is the automated test suite. Automated end-to-end testing requires an environment in which to run tests. Compose provides a convenient way to create and destroy isolated testing environments for your test suite. By defining the full environment in a Compose file, you can create and destroy these environments in just a few commands:

$ docker compose up -d
$ ./run_tests
$ docker compose down

⚪ Local Development and Debugging:

Developers use Docker Compose for local development and debugging of multi-container applications. It allows them to run the application stack locally on their machines, making it easy to test changes, debug issues, and iterate rapidly. The containerized environment closely mirrors the production environment, reducing discrepancies between development and production environments.

⚪ Continuous Integration/Continuous Deployment (CI/CD):

Docker Compose is a key component of CI/CD pipelines for Dockerized applications. CI systems such as Jenkins, GitLab CI/CD, or GitHub Actions can use Compose to define and deploy application stacks for automated testing, building Docker images, running integration tests, and deploying to staging or production environments. This ensures consistency and reliability throughout the deployment pipeline.

⚪ Microservices Architecture:

In a microservices architecture, Docker Compose helps in orchestrating multiple microservices that work together to form a larger application. Each microservice can be defined as a separate container within the Compose file, allowing developers to manage the interactions and dependencies between services efficiently. Compose facilitates the development, testing, and deployment of microservices-based applications.

⚪ Demo and Training Environments:

Compose is useful for creating demo environments or training environments where users need to quickly deploy and interact with a pre-configured application stack. It simplifies the setup process and allows trainers or presenters to demonstrate the application’s functionality without worrying about complex setup procedures.

⚪ Prototyping and Proof of Concept (PoC):

Docker Compose is valuable for quickly prototyping and building proof of concepts for new projects or features. Developers can define a basic architecture using Compose, test different configurations, and iterate rapidly to validate ideas before investing significant resources in full-scale development.

⚪ Deployment for Small-scale Applications:

While Docker Compose is primarily designed for local development and testing, it can also be used for deploying small-scale applications in production environments, especially in scenarios where orchestration platforms like Docker Swarm or Kubernetes might be overkill. Compose allows for straightforward deployment and management of containerized applications on single-node hosts.

⚪ production Environments:

When you define your app with Compose in development, you can use this definition to run your application in different environments such as CI, staging, and production.

The easiest way to deploy an application is to run it on a single server, similar to how you would run your development environment. If you want to scale up your application, you can run Compose apps on a Swarm cluster.

👉History and development of Docker Compose

The image above shows that the currently supported version of the Docker Compose CLI is Compose V2 which is defined by the Compose Specification.

It also provides a quick snapshot of the differences in file formats, command-line syntax, and top-level elements. This is covered in more detail in the following sections.

⚪ Docker Compose CLI versioning:

Version one of the Docker Compose command-line binary was first released in 2014. It was written in Python, and is invoked with docker-compose. Typically, Compose V1 projects include a top-level version element in the compose.yml file, with values ranging from 2.0 to 3.8, which refer to the specific file formats.

Version two of the Docker Compose command-line binary was announced in 2020, is written in Go, and is invoked with docker compose. Compose V2 ignores the version top-level element in the compose.yml file.

⚪ Compose file format versioning:

The Docker Compose CLIs are defined by specific file formats.

Three major versions of the Compose file format for Compose V1 were released:

Compose file format 1 with Compose 1.0.0 in 2014
Compose file format 2.x with Compose 1.6.0 in 2016
Compose file format 3.x with Compose 1.10.0 in 2017

Compose file format 1 is substantially different to all the following formats as it lacks a top-level services key. Its usage is historical and files written in this format don't run with Compose V2.

Compose file format 2.x and 3.x are very similar to each other, but the latter introduced many new options targeted at Swarm deployments.

To address confusion around Compose CLI versioning, Compose file format versioning, and feature parity depending on whether Swarm mode was in use, file format 2.x and 3.x were merged into the Compose Specification.

Compose V2 uses the Compose Specification for project definition. Unlike the prior file formats, the Compose Specification is rolling and makes the version top-level element optional. Compose V2 also makes use of optional specifications - Deploy, Develop and Build.

To make migration easier, Compose V2 has backwards compatibility for certain elements that have been deprecated or changed between Compose file format 2.x/3.x and the Compose Specification.

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: Docker Network Commands
Medium Profile: Meghasharmaa

Docker Network Commands

Megha Sharma — Fri, 02 Jan 2026 12:08:49 +0000

The docker network command is used to manage Docker networks. It allows you to create, inspect, list, connect, disconnect, and remove Docker networks. Below are some common subcommands and examples of using the docker network command:

👉List Docker Networks:

This command provides a list of all networks created on your Docker host. Here’s how you can use it:

docker network ls

When you run this command, Docker will output a table with information about each network, including its ID, name, driver, and scope (local or global). The output will look something like this:

NETWORK ID     NAME            DRIVER    SCOPE
abcdef123456   bridge          bridge    local
ghijkl789012   host            host      local
mnopqr345678   my-network      bridge    local
stuvwx901234   my-overlay-net  overlay   swarm

In this example output:

NETWORK ID: Unique identifier for each network.
NAME: Name of the network.
DRIVER: The type of driver used for the network (e.g., bridge, overlay, host).
SCOPE: Specifies whether the network is local (only accessible on the current host) or global (accessible across multiple hosts in a swarm).

The docker network ls command is useful for quickly checking the existing Docker networks on your system and their basic properties.

👉 Inspect a Docker Network:

To inspect a Docker network and view detailed information about it, you can use the docker network inspectcommand followed by the network's name or ID.

docker network inspect NETWORK_NAME_OR_ID

Replace NETWORK_NAME_OR_ID with the actual name or ID of the Docker network you want to inspect. For example, if you want to inspect a network named my-network, you would use:

docker network inspect my-network

The output of the docker network inspect command provides comprehensive details about the specified network, including its configuration, containers connected to it, IP address ranges, and more. The information is presented in JSON format.

Example of the output:

[
    {
        "Name": "my-network",
        "Id": "abcdef1234567890",
        "Created": "2022-01-01T12:00:00Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Containers": {
            "container1": {
                "Name": "container1",
                "EndpointID": "xyz123456789",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            },
            "container2": {
                "Name": "container2",
                "EndpointID": "abc987654321",
                "MacAddress": "02:42:ac:11:00:03",
                "IPv4Address": "172.18.0.3/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]

The output contains information such as the network’s name, ID, creation time, driver, IP address management (IPAM) configuration, connected containers, and additional options. This information can be useful for troubleshooting, managing network configurations, or understanding network settings in Docker.

👉Create a Docker Network:

To create a Docker network, you can use the docker network create command followed by the desired options and the name you want to give to the network.

docker network create my-network

This command creates a Docker network named my-network using the default bridge driver and default options. If you want to specify additional options, such as the network driver, subnet, gateway, or other configurations, you can include those options in the command.

Here’s an example of creating a Docker network with custom options:

docker network create \
  --driver bridge \
  --subnet 172.18.0.0/16 \
  --gateway 172.18.0.1 \
  --ip-range 172.18.0.0/24 \
  my-custom-network

In this example:

--driver bridge: Specifies the network driver as bridge. You can use
other drivers like overlay, macvlan, etc., based on your requirements.
--subnet 172.18.0.0/16: Defines the subnet for the network.
--gateway 172.18.0.1: Specifies the gateway IP address for the network.
--ip-range 172.18.0.0/24: Defines the range of IP addresses that can be assigned to containers on this network.
my-custom-network: The name given to the network.

After running the docker network create command, Docker will create the specified network with the provided configurations. You can verify the network's creation by using the docker network ls command to list all networks on your Docker host.

👉 Connect a Container to a Network:

To connect a Docker container to a network, you can use the docker network connect command followed by the network name and the container name or ID.

docker network connect my-network my-container

In this example:

my-network is the name of the network to which you want to connect the container.
my-container is the name or ID of the container you want to connect to the network.

After running this command, the specified container (my-container) will be connected to the my-network network. This allows the container to communicate with other containers on the same network using their container names or IP addresses within the network.

👉 Disconnect a Container from a Network:

To disconnect a Docker container from a network, you can use the docker network disconnect command followed by the network name and the container name or ID.

docker network disconnect my-network my-container

In this example:

my-network is the name of the network from which you want to disconnect the container.
my-container is the name or ID of the container you want to disconnect from the network.

After running this command, the specified container (my-container) will be disconnected from the my-network network. This means that the container will no longer be able to communicate with other containers on that network, although it may still be connected to other networks or have its own network namespace.

👉Remove a Docker Network:

To remove a Docker network, you can use the docker network rm command followed by the name or ID of the network you want to remove.

docker network rm my-network

my-network is the name of the Docker network you want to remove.

After running this command, Docker will delete the specified network (my-network). Any containers connected exclusively to this network will be disconnected from it. However, if a container is connected to multiple networks and one of them is removed, the container remains connected to the other networks.

👉 docker network prune:

The docker network prune command is used to remove all unused Docker networks from your system. Unused networks are those that are not connected to any containers. This command helps clean up your Docker environment by removing networks that are no longer in use.

docker network prune

When you run docker network prune without any options, Docker will prompt you to confirm whether you want to remove all unused networks. You can type y and press Enter to proceed with the removal.

If you want to skip the confirmation prompt, you can use the -f or --force option:

docker network prune -f

This command will immediately remove all unused networks without asking for confirmation.

Note - It’s important to note that the docker network prune command only removes unused networks. Networks that are still in use by one or more containers will not be removed.

👉docker network create-ipam:

The docker network create-ipam command is used to create a new IP address management (IPAM) configuration for a Docker network. IPAM allows you to define custom IP address ranges, subnets, gateways, and other network configurations.

docker network create-ipam --subnet=192.168.1.0/24 my-custom-network

In this example:

--subnet=192.168.1.0/24 specifies the subnet for the new IPAM configuration. You can adjust the subnet to match your network requirements.
my-custom-network is the name given to the Docker network for which you are creating the custom IPAM configuration.

After running the docker network create-ipam command, Docker will create a new IPAM configuration with the specified subnet for the my-custom-network Docker network. This allows you to define specific IP address ranges and network settings for containers connected to this network.

It’s worth noting that custom IPAM configurations are optional, and Docker provides default IPAM settings for networks created without specifying custom configurations. Custom IPAM configurations are useful for advanced networking scenarios where you need precise control over IP address allocation and network parameters.

👉docker network connect-ipam:

The docker network connect-ipam command is used to connect a container to a Docker network with a custom IP address management (IPAM) configuration. IPAM allows you to define specific IP address ranges, subnets, gateways, and other network settings.

docker network connect-ipam --ip=192.168.1.10 my-custom-network my-container

In this example:

--ip=192.168.1.10 specifies the IP address that you want to assign to the container on the connected network. You can adjust the IP address as needed.
my-custom-network is the name of the Docker network with a custom IPAM configuration to which you want to connect the container.
my-container is the name or ID of the container you want to connect to the network.

After running the docker network connect-ipamcommand, Docker will connect the specified container (my-container) to the my-custom-network Docker network with the custom IPAM configuration. The container will be assigned the specified IP address (192.168.1.10) on the network.

Using the docker network connect-ipam command with custom IPAM configurations allows you to have more control over IP address assignment and network parameters for containers connected to your Docker networks.

👉docker network disconnect-ipam:

The docker network disconnect-ipam command is used to disconnect a container from a Docker network that has a custom IP address management (IPAM) configuration. This command is specifically designed for networks with custom IPAM settings.

docker network disconnect-ipam my-custom-network my-container

In this example:

my-custom-network is the name of the Docker network with a custom IPAM configuration from which you want to disconnect the container.
my-container is the name or ID of the container you want to disconnect from the network.

After running the docker network disconnect-ipam command, Docker will disconnect the specified container (my-container) from the my-custom-network Docker network with the custom IPAM configuration.

It’s important to note that the docker network disconnect-ipam command is specifically used for networks with custom IPAM configurations. For networks with default IPAM settings, you would use the regular docker network disconnect command without the -ipam suffix.

👉 Example:

By default when the bridge network is created, the DNS is not enabled. But if we create our custom bridge network DNS is enabled by default.

loclhost:~$ docker container ls
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

localhost:~$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
6c51373f78ad   bridge    bridge    local
3a33f83c3664   host      host      local
e4ebd601732e   none      null      local

localhost:~$ docker container run -itd ubuntu:14.04 bash
7b1af2ee48e43f8018c4324bbcb9f52a27f741bd7a0437ddd0f6766bd7ca6b10

localhost:~$ docker container run -itd ubuntu:14.04 bash
c3ce5dbe5d859705f139e811bc11367d02bf0969492e9d515a3cc6cc636ddfbb

localhost:~$ docker container ls
CONTAINER ID   IMAGE          COMMAND   CREATED          STATUS         PORTS     NAMES
c3ce5dbe5d85   ubuntu:14.04   "bash"    8 seconds ago    Up 7 seconds             unruffled_sinoussi
7b1af2ee48e4   ubuntu:14.04   "bash"    10 seconds ago   Up 9 seconds             trusting_joliot

localhost:~$ docker container exec -it 7b bash
root@7b1af2ee48e4:/# ping c3ce5dbe5d85

ping: unknown host c3ce5dbe5d85
root@7b1af2ee48e4:/#

To achieve the above use case, let’s create a network test first:

localhost:~$ docker network create test
b1e05c1afdb2f901e81a66a52d64a9dcdca9c5cab98433cdaed2faa83c5b3e6b

localhost:~$ docker container ls
CONTAINER ID   IMAGE     COMMAND   CREATED              STATUS              PORTS     NAMES

localhost:~$

Now, create a container with ubuntu image with network as test :

localhost:~$ docker container run -itd --network=test ubuntu:14.04 bash
c7b07b61bb20cdbb6e1b54a165aed0f8907d95d563fdd7a60940d004694c4557

List the containers:

localhost:~$ docker container ls
CONTAINER ID   IMAGE     COMMAND   CREATED              STATUS              PORTS     NAMES
c7b07b61bb20   ubuntu    "bash"    About a minute ago   Up About a minute

Inspect the container using inspect command:

"Networks": {
                "host": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "b1e05c1afdb2f901e81a66a52d64a9dcdca9c5cab98433cdaed2faa83c5b3e6b",
                    "EndpointID": "b860ca4fdda3e0732367949cb94fd2eded08a4f2e46715a6c125b1bf336c102f",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "",
                    "DriverOpts": null
                }
            }

Delete a Network:

localhost:~$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
6c51373f78ac   bridge    bridge    local
3a33f83c3663   host      host      local
e4ebd601732c   none      null      local
348f7295d3ca   test      bridge    local

localhost:~$ docker network rm test
test

localhost:~$

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: What is None network driver
Medium Profile: Meghasharmaa

What is None network driver

Megha Sharma — Thu, 25 Dec 2025 11:49:32 +0000

The nonenetwork driver in Docker is a special type of network that provides complete isolation for a container from any external network. When you attach a container to the none network, it means the container has no network connectivity whatsoever. This can be useful in certain scenarios where you want to prevent a container from communicating with other containers or external networks.

If you want to completely isolate the networking stack of a container, you can use the --network none flag when starting the container. Within the container, only the loopback device is created.

👉 Possible Use Cases:

The none network driver in Docker provides complete network isolation for containers, making it suitable for specific use cases where network connectivity is not required or should be restricted. Here are some possible scenarios where you might consider using the “none” network driver:

Highly Sensitive Applications: For applications handling highly sensitive data or running critical processes, isolating them from any network connectivity using the “none” network driver adds an extra layer of security.
Isolation from Malware or Attacks: In environments where there’s a higher risk of network-based attacks or malware, running containers on the none network can reduce the attack surface.
Network Debugging: When debugging networking issues within a container or testing network-related functionalities, isolating the container using the none network driver helps eliminate external network interference.
Simulating Network Outages: For testing how applications behave during network outages or when connectivity is lost, using the none network driver allows you to simulate these scenarios effectively.
Stand-Alone Containers: Containers that do not require any external dependencies or network services can be run on the none network to ensure they operate independently.
Resource Isolation: Isolating containers with resource-intensive tasks or specific workloads from the network can prevent network-related performance impacts.
Transient Containers: Containers that are spun up temporarily for specific tasks or short-lived processes can be attached to the none network to minimize exposure and clean up automatically after use (--rm flag).

👉 Example:

Here’s an example of running the ip link show command inside an Alpine container that is attached to the none network driver:

First, start an Alpine container named app1 with the none network driver:

docker run -it --name app1 --network=none alpine sh

Inside the container’s shell (sh), run the ip link show command to display network interfaces:

ip link show

The output of ip link show in an Alpine container attached to the "none" network driver will typically look like this:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Explanation of the output:

lo: Loopback interface, which is always present.
eth0@if2: Virtual Ethernet interface (eth0) with MAC address 02:42:ac:11:00:02 and link-netnsid 0. This is typically assigned by Docker when using the none network driver.

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: What is Macvlan network driver?
Medium Profile: Meghasharmaa

What is Macvlan network driver?

Megha Sharma — Wed, 17 Dec 2025 09:30:43 +0000

Macvlan network is used to connect applications directly to the physical network. By using the macvlan network driver to assign a MAC address to each container, also allow having full TCP/Ip stack. Then, the Docker daemon routes traffic to containers by their MAC addresses. You can isolate your macvlan networks using different physical network interfaces. This is used in legacy applications which require MAC address.

Macvlan networking in Docker is a mode that gives each container its own MAC address, making them appear as separate physical devices on the network. This enables containers to directly communicate with external networks without going through the Docker host’s network stack. Macvlan networking is beneficial for scenarios where containers require direct access to the underlying network infrastructure, such as when running network-intensive applications or services that need to expose specific ports. It provides improved network performance, isolation, and flexibility compared to bridge networking, making it suitable for applications needing container-to-network communication without network address translation (NAT) overhead.

For example some applications, especially legacy applications or applications which monitor network traffic, expect to be directly connected to the physical network. In this type of situation, you can use the macvlan network driver to assign a MAC address to each container's virtual network interface, making it appear to be a physical network interface directly connected to the physical network. In this case, you need to designate a physical interface on your Docker host to use for the Macvlan, as well as the subnet and gateway of the network. You can even isolate your Macvlan networks using different physical network interfaces.

Keep the following things in mind:

You may unintentionally degrade your network due to IP address exhaustion or to VLAN spread, a situation that occurs when you have an inappropriately large number of unique MAC addresses in your network.
Your networking equipment needs to be able to handle promiscuous mode, where one physical interface can be assigned multiple MAC addresses.
If your application can work using a bridge (on a single Docker host) or overlay (to communicate across multiple Docker hosts), these solutions may be better in the long term.

👉 Use case of Macvlan network:

Network Appliances: Macvlan is commonly used when running network appliances or virtual network devices within containers. For example, you might have a containerized firewall, load balancer, or VPN server that needs to interact with the external network as if it were a physical appliance.
Virtual Routers: In networking setups where virtual routers are utilized for routing traffic between different networks or VLANs, Macvlan can be used to create containers that act as virtual routers. These containers can have their own MAC and IP addresses and route traffic between various network segments.
Containerized Servers: For applications that require direct access to network hardware or external resources, Macvlan can provide containers with dedicated MAC addresses and IP addresses on the same subnet as the host or on a separate subnet. This allows the containers to communicate directly with external servers, devices, or services without network address translation (NAT) overhead.
Multi-Tenant Environments: In multi-tenant environments where different users or applications require separate network identities and isolation, Macvlan can be used to create individual networks for each tenant. This ensures that containers belonging to different tenants operate as independent entities on the network.
Testing and Development: Macvlan networks are also useful for testing and development environments where you want containers to behave as if they were physical machines on the network. This can be beneficial for simulating real-world network configurations and scenarios.
Media Streaming and Broadcasting: Applications that involve media streaming, broadcasting, or multicast communication can benefit from Macvlan networks to ensure efficient and direct communication with network hardware and services.

The following table describes the driver-specific options that you can pass to --option when creating a network using the macvlan driver.

macvlan_mode: Sets the Macvlan mode. Can be one of: bridge, vepa, passthru, private.

parent: Specifies the parent interface to use.

👉 Prerequisites

Most cloud providers block macvlan networking. You may need physical access to your networking equipment.
The macvlan networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.
You need at least version 3.9 of the Linux kernel, and version 4.0 or higher is recommended.
The examples assume your ethernet interface is eth0. If your device has a different name, use that instead.
The macvlan driver is not supported in rootless mode.

👉 Create a Macvlan network

When you create a Macvlan network, it can either be in bridge mode or 802.1Q trunk bridge mode.

In bridge mode, Macvlan traffic goes through a physical device on the host.
In 802.1Q trunk bridge mode, traffic goes through an 802.1Q sub-interface which Docker creates on the fly. This allows you to control routing and filtering at a more granular level.

Bridge mode example:

In our example, we have a physical network interface eth0 on the 172.16.86.0/24 network and the default gateway of 172.16.86.1 The default gateway is the IP address of the router.

Now, we will create a macvlan network called my-macvlan-net with the following configuration.

To create a macvlan network which bridges with a given physical network interface, use --driver macvlan with the docker network create command. You also need to specify the parent, which is the interface the traffic will physically go through on the Docker host.

$ docker network create -d macvlan \
  --subnet=172.16.86.0/24 \
  --gateway=172.16.86.1 \
  -o parent=eth0 \
  my-macvlan-net

Let’s break down the components of this command:

docker network create: This part of the command instructs Docker to create a new network.
-d macvlan: Specifies that the network driver to be used is Macvlan.
--subnet=172.168.86.0/24: Defines the subnet range for the Macvlan network. You can adjust this subnet range as needed for your network configuration.
--gateway=172.16.86.1: Specifies the gateway IP address for the Macvlan network. Replace 172.16.86.1 with your desired gateway IP.
-o parent=eth0: Indicates the parent interface (physical interface) to which the Macvlan network will be attached. Replace eth0 with the appropriate interface name on your host machine.
my-macvlan-net: Assigns the name my-macvlan-net to the Macvlan network. You can choose a different name if desired.

If you need to exclude IP addresses from being used in the macvlan network, such as when a given IP address is already in use, use --aux-addresses:

$ docker network create -d macvlan \
  --subnet=192.168.32.0/24 \
  --ip-range=192.168.32.128/25 \
  --gateway=192.168.32.254 \
  --aux-address="my-router=192.168.32.129" \
  -o parent=eth0 macnet32

To confirm that the newly added macvlan network is present, run the command:

$ docker network ls

When you run this command, Docker will display a list of networks along with their IDs, names, driver types, and other details. Look for your Macvlan network in the list to confirm its presence.

$ NETWORK ID     NAME               DRIVER    SCOPE
abcdef123456   bridge             bridge    local
ghijkl789012   host               host      local
mnopqr345678   none               null      local
xyz123456789   my-macvlan-net     macvlan   local

In this example output:NETWORK ID: Unique identifier for the network.

NAME: Name of the network (my-macvlan-net in this case).
DRIVER: Network driver used for the network (Macvlan in this case).
SCOPE: Indicates the scope of the network (local means it's local to the Docker host).

Start an container and attach it to the my-macvlan-net network. The -dit flags start the container in the background but allow you to attach to it. The --rm flag means the container is removed when it is stopped.

$ docker run --rm -dit \
  --network my-macvlan-net \
  --name my_container \
  alpine:latest \
  ash

Let’s break down this command:

docker run: This command is used to create and start a new container.
-d: Runs the container in detached mode (background).
--network= my-macvlan-net: Specifies that the container should be attached to the my-macvlan-net Macvlan network that you created earlier.
--name my_container: Assigns the name my_container to the Docker container. You can replace my_container with your desired container name.
nginx: Specifies the Docker image to use for the container. In this example, we're using the Nginx image. Replace nginx with the image name you want to use.

The container will run in the background, and you can verify its status using docker ps.

$ docker ps

When you run docker ps, Docker will display a list of all running containers along with their container IDs, names, statuses, ports, and other information. Look for your container in the list to ensure it's running and verify its network configuration.

CONTAINER ID       IMAGE       COMMAND            CREATED         STATUS       PORTS      NAMES
5e3ec79625d388       nginx      "/bin/bash"       1 minute ago     Up 1 minute             my_container

Inspect the my_container container and notice the MacAddress key within the Networks key:

$ docker container inspect my_container

...truncated...
"Networks": {
  "my-macvlan-net": {
      "IPAMConfig": null,
      "Links": null,
      "Aliases": [
          "bec64291cd4c"
      ],
      "NetworkID": "5e3ec79625d388dbcc03dcf4a6dc4548644eb99d58864cf8eee2252dcfc0cc9f",
      "EndpointID": "8caf93c862b22f379b60515975acf96f7b54b7cf0ba0fb4a33cf18ae9e5c1d89",
      "Gateway": "172.16.86.1",
      "IPAddress": "172.16.86.2",
      "IPPrefixLen": 24,
      "IPv6Gateway": "",
      "GlobalIPv6Address": "",
      "GlobalIPv6PrefixLen": 0,
      "MacAddress": "02:42:ac:10:56:02",
      "DriverOpts": null
  }
}
...truncated

Check out how the container sees its own network interfaces by running a couple of docker exec commands.

$ docker exec my_container ip addr show eth0

9: eth0@tunl0: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:10:56:02 brd ff:ff:ff:ff:ff:ff
inet 172.16.86.2/24 brd 172.16.86.255 scope global eth0
   valid_lft forever preferred_lft forever

$ docker exec my_container ip route

default via 172.16.86.1 dev eth0
172.16.86.0/24 dev eth0 scope link  src 172.16.86.2

Stop the container (Docker removes it because of the --rm flag), and remove the network.

$ docker container stop my_container

$ docker network rm my-macvlan-net

802.1Q trunked bridge example:

In the 802.1Q trunked bridge example, your traffic flows through a sub-interface of eth0 (called eth0.10) and Docker routes traffic to your container using its MAC address. To network devices on your network, your container appears to be physically attached to the network.

Create a macvlan network called my-8021q-macvlan-net. Modify the subnet, gateway, and parent values to values that make sense in your environment.

$ docker network create -d macvlan \
  --subnet=172.16.86.0/24 \
  --gateway=172.16.86.1 \
  -o parent=eth0.10 \
  my-8021q-macvlan-net

You can use docker network ls and docker network inspect my-8021q-macvlan-net commands to verify that the network exists, is a macvlan network, and has parent eth0.10. You can use ip addr show on the Docker host to verify that the interface eth0.10 exists and has a separate IP address.

Start an alpine container and attach it to the my-8021q-macvlan-net network. The -dit flags start the container in the background but allow you to attach to it. The --rm flag means the container is removed when it is stopped.

$ docker run --rm -itd \
  --network my-8021q-macvlan-net \
  --name my-second-macvlan-alpine \
  alpine:latest \
  ash

Inspect the my-second-macvlan-alpine container and notice the Mac Address key within the Networks key:

$ docker container inspect my-second-macvlan-alpine

...truncated...
"Networks": {
  "my-8021q-macvlan-net": {
      "IPAMConfig": null,
      "Links": null,
      "Aliases": [
          "12f5c3c9ba5c"
      ],
      "NetworkID": "c6203997842e654dd5086abb1133b7e6df627784fec063afcbee5893b2bb64db",
      "EndpointID": "aa08d9aa2353c68e8d2ae0bf0e11ed426ea31ed0dd71c868d22ed0dcf9fc8ae6",
      "Gateway": "172.16.86.1",
      "IPAddress": "172.16.86.2",
      "IPPrefixLen": 24,
      "IPv6Gateway": "",
      "GlobalIPv6Address": "",
      "GlobalIPv6PrefixLen": 0,
      "MacAddress": "02:42:ac:10:56:02",
      "DriverOpts": null
  }
}
...truncated

Check out how the container sees its own network interfaces by running a couple of docker exec commands.

$ docker exec my-second-macvlan-alpine ip addr show eth0

11: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:10:56:02 brd ff:ff:ff:ff:ff:ff
inet 172.16.86.2/24 brd 172.16.86.255 scope global eth0
   valid_lft forever preferred_lft forever

$ docker exec my-second-macvlan-alpine ip route

default via 172.16.86.1 dev eth0
172.16.86.0/24 dev eth0 scope link  src 172.16.86.2

Stop the container (Docker removes it because of the --rm flag), and remove the network.

$ docker container stop my-second-macvlan-alpine

$ docker network rm my-8021q-macvlan-net

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: What is IPvlan network driver?
Medium Profile: Meghasharmaa

What is IPvlan network driver?

Megha Sharma — Sun, 14 Dec 2025 12:19:29 +0000

The IPvlan network driver in Docker is a type of network driver that provides network isolation and allows containers to have their own MAC and IP addresses on a network. It operates at Layer 2 of the OSI model and enables containers to communicate directly with the physical network, bypassing the host’s networking stack.

The IPvlan network driver in Docker provides users with extensive control over IPv4 and IPv6 addressing within containers. It allows for the creation of isolated network segments with their own MAC and IP addresses, enhancing network security and segmentation capabilities.

The IPvlan driver gives users total control over both IPv4 and IPv6 addressing. The VLAN driver builds on top of that in giving operators complete control of layer 2 VLAN tagging and even IPvlan L3 routing for users interested in underlay network integration.

IPvlan is a new twist on the tried and true network virtualization technique. The Linux implementations are extremely lightweight because rather than using the traditional Linux bridge for isolation, they are associated to a Linux Ethernet interface or sub-interface to enforce separation between networks and connectivity to the physical network.

IPvlan offers a number of unique features and plenty of room for further innovations with the various modes. Two high level advantages of these approaches are, the positive performance implications of bypassing the Linux bridge and the simplicity of having fewer moving parts. Removing the bridge that traditionally resides in between the Docker host NIC and container interface leaves a simple setup consisting of container interfaces, attached directly to the Docker host interface. This result is easy to access for external facing services as there is no need for port mappings in these scenarios.

The following table describes the driver-specific options that you can pass to --option when creating a network using the ipvlan driver.

ipvlan_mode: Sets the IPvlan operating mode. Can be one of: l2, l3, l3s

ipvlan_flag: Sets the IPvlan mode flag. Can be one of: bridge, private, vepa

parent: Specifies the parent interface to use.

👉Kernel requirements:

IPvlan Linux kernel v4.2+ (support for earlier kernels exists but is buggy). To check your current kernel version, use uname -r

👉 Example:

The driver is specified with -d driver_name option. In this case -d ipvlan.

The parent interface in the next example -o parent=eth0 is configured as follows:

ip addr show eth0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.1.250/24 brd 192.168.1.255 scope global eth0

Use the network from the host's interface as the --subnet in the docker network create. The container will be attached to the same network as the host interface as set via the -o parent= option.

Create the IPvlan network and run a container attaching to it:

# IPvlan  (-o ipvlan_mode= Defaults to L2 mode if not specified)
docker network create -d ipvlan \
    --subnet=192.168.1.0/24 \
    --gateway=192.168.1.1 \
    -o ipvlan_mode=l2 \
    -o parent=eth0 db_net

# Start a container on the db_net network
docker run --net=db_net -it --rm alpine /bin/sh

# NOTE: the containers can NOT ping the underlying host interfaces as
# they are intentionally filtered by Linux for additional isolation.

The default mode for IPvlan is l2. If -o ipvlan_mode= is left unspecified, the default mode will be used. Similarly, if the --gateway is left empty, the first usable address on the network will be set as the gateway. For example, if the subnet provided in the network create is --subnet=192.168.1.0/24 then the gateway the container receives is 192.168.1.1.

The following will create the exact same network as the network db_net created earlier, with the driver defaults for --gateway=192.168.1.1 and -o ipvlan_mode=l2.

# IPvlan  (-o ipvlan_mode= Defaults to L2 mode if not specified)
docker network create -d ipvlan \
    --subnet=192.168.1.0/24 \
    -o parent=eth0 db_net_ipv

# Start a container with an explicit name in daemon mode
docker run --net=db_net_ipv --name=ipv1 -itd alpine /bin/sh

# Start a second container and ping using the container name
# to see the docker included name resolution functionality
docker run --net=db_net_ipv --name=ipv2 -it --rm alpine /bin/sh
ping -c 4 ipv1

# NOTE: the containers can NOT ping the underlying host interfaces as
# they are intentionally filtered by Linux for additional isolation.

The drivers also support the --internal flag that will completely isolate containers on a network from any communications external to that network. Since network isolation is tightly coupled to the network's parent interface the result of leaving the -o parent= option off of a docker network create is the exact same as the --internal option. If the parent interface is not specified or the --internal flag is used, a netlink type dummy parent interface is created for the user and used as the parent interface effectively isolating the network completely.

👉 In Other Example:

To create an IPvlan network in Docker, you can use the docker network create command with the -d ipvlan option. Below is an example command to create an IPvlan network:

docker network create -d ipvlan --subnet=192.168.1.0/24 --gateway=192.168.1.1 -o parent=eth0 my_ipvlan_network

Let’s break down the components of this command:

docker network create: This part of the command instructs Docker to create a new network.

-d ipvlan: Specifies that the network driver to be used is IPvlan.
--subnet=192.168.1.0/24: Defines the subnet range for the IPvlan network. You can adjust this subnet range as needed for your network configuration.
--gateway=192.168.1.1: Specifies the gateway IP address for the IPvlan network. Replace 192.168.1.1 with your desired gateway IP.
-o parent=eth0: Indicates the parent interface (physical interface) to which the IPvlan network will be attached. Replace eth0with the appropriate interface name on your host machine.
my_ipvlan_network: Assigns the name my_ipvlan_network to the IPvlan network. You can choose a different name if desired.

After running the above command, Docker will create an IPvlan network named my_ipvlan_network with the specified subnet, gateway, and parent interface.

If you want to run a container and attach it to the IPvlan network you created (my_ipvlan_network), you can use the docker run command with the --network=my_ipvlan_network option:

docker run -d --network=my_ipvlan_network --name my_container nginx

Let’s break down the components of this command:

docker run: This part of the command instructs Docker to run a new container.
-d: Runs the container in detached mode (background).
--network=my_ipvlan_network: Specifies that the container should be attached to the my_ipvlan_network IPvlan network that you created.
--name my_container: Assigns the name my_container to the Docker container. You can replace my_container with your desired container name.
nginx: Specifies the Docker image to use for the container, in this case

After running the above command, Docker will create a new container named my_container and attach it to the my_ipvlan_network IPvlan network.

To verify that the container is running and attached to the IPvlan network, you can use the docker ps command to check the container's status and the network it's connected to.

docker ps

you should see it listed in the output of docker ps:

CONTAINER ID   IMAGE    COMMAND                  CREATED          STATUS         PORTS     NAMES
123456789abc   nginx    "nginx -g 'daemon of…"   1 minute ago    Up 1 minute             my_container

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: What is Host network driver?
Medium Profile: Meghasharmaa

What is Host network driver?

Megha Sharma — Wed, 10 Dec 2025 11:54:36 +0000

The Host network driver in Docker is a networking mode that allows containers to directly use the networking stack of the Docker host machine. When a container is run with the Host network driver, it bypasses Docker’s network abstraction layer and gains direct access to the host’s network interfaces, routing table, and ports. This means that the container shares the same network namespace as the host, using the host’s IP address and network configuration.

If you use the host network mode for a container, that container's network stack isn't isolated from the Docker host (the container shares the host's networking namespace), and the container doesn't get its own IP-address allocated. For instance, if you run a container which binds to port 80 and you use host networking, the container's application is available on port 80 on the host's IP address.

Use cases:

Host mode networking in Docker can be beneficial for several use cases where direct access to the host’s networking stack is required. Here are some scenarios where host mode networking can be useful:

High-Performance Applications: Host mode networking is ideal for applications that demand maximum network performance and low latency. By bypassing Docker’s networking abstraction layer, containers can achieve better throughput and reduced overhead, making it suitable for high-performance workloads such as databases or real-time streaming services.
Networking Tools and Utilities: Networking tools or utilities that require direct access to network interfaces or network configuration on the host machine can benefit from host mode networking. This includes tools like network monitoring agents, packet sniffers, or VPN clients that need full access to the host’s network stack.
Legacy Applications: Legacy applications that are designed to run directly on the host and expect to bind to specific host ports can be containerized using host mode networking. This allows the containerized application to behave similarly to how it would run natively on the host without network address translation (NAT) or port mapping.
Single-Container Deployment: In cases where a single container needs to expose multiple services on different ports without conflicts, host mode networking can simplify the configuration. Each service within the container can bind directly to the corresponding port on the host, avoiding port collision issues.
Network Troubleshooting and Debugging: During network troubleshooting or debugging tasks, using host mode networking can provide a clear view of network traffic and behavior by directly accessing host interfaces and routing tables. This can be useful for diagnosing network-related issues within containers.
Containerized Network Services: Certain network services or daemons running inside containers may require access to low-level network functionalities that are only available in the host’s networking stack. Host mode networking allows these services to operate with full network capabilities.
Integration with Host Services: Applications that need seamless integration with host services or rely on specific network configurations present on the host machine can benefit from host mode networking. This ensures compatibility and consistent behavior between containerized services and host-level networking setups.

Limitations of the `host` driver

Lack of Network Isolation: Containers using the Host network driver share the same networking namespace as the host machine, leading to reduced network isolation. This means that processes running inside the container have full access to the host’s network interfaces, potentially increasing security risks if not properly configured.
Port Binding Conflicts: Since containers using the Host network driver share the same network stack as the host, conflicts can occur if multiple containers attempt to bind to the same ports on the host. This can lead to port binding errors and service disruption.
Security Concerns: Host mode networking reduces network isolation between containers and the host, which can pose security risks, especially in multi-tenant environments. Containers running in Host mode have direct access to host network interfaces and services, potentially exposing sensitive information or resources.
Limited Scalability: Host mode networking may not scale well in environments with a large number of containers or distributed systems. It may not be suitable for complex networking architectures or deployments requiring advanced network routing and segmentation.
Only works on Linux machines: The Host network driver in Docker only works on Linux machines. This limitation arises due to the way the Host networking mode is implemented and how it leverages the underlying networking capabilities of the Linux kernel.

Example using `host` driver:

To use the Host network driver in Docker, you can specify the --network=host option when running a container. This option tells Docker to use the host's networking stack directly for the container, allowing the container to share the same network namespace as the host machine. Here's how you can use the Host network driver:

For example, To run an Nginx container named app2 using the Host network driver in Docker:

docker run -d --network=host --name app2 nginx

Let’s break down the command:

docker run: This is the command to run a new Docker container.
-d: This flag runs the container in detached mode, meaning it runs in the background.
--network=host: This option specifies that the container should use the host's networking stack directly, using the Host network driver.
--name app2: This option gives the container the name "app2" so that you can refer to it easily.
nginx: This is the name of the Docker image to use for the container. In this case, we're using the Nginx official image.

After running this command, Docker will start a new Nginx container named “app2” using the Host network driver.

Use the docker inspect command to view detailed information about the container, including its network settings:

docker inspect app2

Here’s an example of what the output might look like for a container named app2 running with the Host network driver:

[
    {
        "Id": "container_id",
        "Created": "2024-03-25T12:34:56.000Z",
        "State": {
            ...
        },
        "NetworkSettings": {
            "Networks": {
                "host": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "",
                    "EndpointID": "",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "",
                    "DriverOpts": null
                }
            },
            ...
        },
        ...
    }
]

To check the logs of the app2 container, you would use:

docker logs app2

To clean up and remove the Docker containers that were created during the hands-on lab, you can use the docker rm command.

docker rm -f app2

This command removes the containers named app2. The -f flag is used to force the removal of the containers even if they are currently running.

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: What is Overlay network driver?
Medium Profile: Meghasharmaa

What is Overlay network driver?

Megha Sharma — Fri, 05 Dec 2025 11:48:22 +0000

The overlay network driver creates a distributed network among multiple Docker daemon hosts. This network sits on top of (overlays) the host-specific networks, allowing containers connected to it to communicate securely when encryption is enabled. Docker transparently handles routing of each packet to and from the correct Docker daemon host and the correct destination container.

You can create user-defined overlay networks using docker network create, in the same way that you can create user-defined bridge networks. Services or containers can be connected to more than one network at a time. Services or containers can only communicate across networks they're each connected to.

Overlay networks are often used to create a connection between Swarm services, but you can also use it to connect standalone containers running on different hosts. When using standalone containers, it’s still required that you use Swarm mode to establish a connection between the hosts.

Create an overlay network

Before you start, you must ensure that participating nodes can communicate over the network. The following lists ports that need to be open to each host participating in an overlay network:

Ports:

2377/tcp: The default Swarm control plane port, is configurable with docker swarm join --listen-addr

4789/udp: The default overlay traffic port, configurable with docker swarm init --data-path-addr

7946/tcp, 7946/udp: Used for communication among nodes, not configurable

Here are the steps to create an overlay network in Docker Swarm:

👉 Initialize Docker Swarm :

docker swarm init

This command initializes Docker Swarm on the host and creates a Swarm manager node.

👉 Create an Overlay Network:

Once Docker Swarm is initialized, you can create an overlay network using the docker network create command with the --driver option set to overlay. Optionally, you can specify additional parameters such as subnet, gateway, and network name.

docker network create --driver overlay my-overlay-network

You can also specify subnet and gateway parameters while creating the overlay network:

docker network create --driver overlay --subnet=10.0.1.0/24 --gateway=10.0.1.1 my-overlay-network

You Can also use — attachable Command

To create an overlay network that containers on other Docker hosts can connect to, run the following command:

docker network create --driver overlay --attachable my-overlay-network

The --attachable option enables both standalone containers and Swarm services to connect to the overlay network. Without --attachable, only Swarm services can connect to the network.

👉 Verify the Overlay Network:

After creating the overlay network, you can use the docker network ls command to list all networks and verify that your overlay network has been created:

docker network ls

Encrypt traffic on an overlay network

Use the --opt encrypted flag to encrypt the application data transmitted over the overlay network:

docker network create \
  --opt encrypted \
  --driver overlay \
  --attachable \
  my-attachable-multi-host-network

This enables IPsec encryption at the level of the Virtual Extensible LAN (VXLAN). This encryption imposes a non-negligible performance penalty, so you should test this option before using it in production.

Attach a container to an overlay network

Adding containers to an overlay network gives them the ability to communicate with other containers without having to set up routing on the individual Docker daemon hosts. A prerequisite for doing this is that the hosts have joined the same Swarm.

To join an overlay network named multi-host-network with a busybox container:

$ docker run --network multi-host-network busybox sh

Note: Due to limitations set by the Linux kernel, overlay networks become unstable and inter-container communications may break when 1000 containers are co-located on the same host.

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: What is Bridge network driver?
Medium Profile: Meghasharmaa
Hashnode: Megha Sharma's Blog

What is Bridge network driver?

Megha Sharma — Mon, 01 Dec 2025 09:36:52 +0000

Bridge network is a default network created automatically when you deploy a container. Bridge network uses a software bridge that allows containers connected to the same bridge network to communicate. Bridge networks used on containers that are running on the same Docker daemon host. The bridge network creates a private internal isolated network to the host so containers on this network can communicate.

In terms of networking, a bridge network is a Link Layer device which forwards traffic between network segments. A bridge can be a hardware device or a software device running within a host machine’s kernel.

In terms of Docker, a bridge network uses a software bridge which lets containers connected to the same bridge network communicate, while providing isolation from containers that aren’t connected to that bridge network. The Docker bridge driver automatically installs rules in the host machine so that containers on different bridge networks can’t communicate directly with each other.

When you start Docker, a default bridge network (also called bridge) is created automatically, and newly-started containers connect to it unless otherwise specified. You can also create user-defined custom bridge networks. User-defined bridge networks are superior to the default bridge network.

👉 Differences between user-defined bridges and the default bridge

User-defined bridges provide automatic DNS resolution between containers:

Containers on the default bridge network can only access each other by IP addresses, unless you use the --link option, which is considered legacy. On a user-defined bridge network, containers can resolve each other by name or alias. Imagine an application with a web front-end and a database back-end. If you call your containers web and db, the web container can connect to the db container at db, no matter which Docker host the application stack is running on.
If you run the same application stack on the default bridge network, you need to manually create links between the containers (using the legacy --link flag). These links need to be created in both directions, so you can see this gets complex with more than two containers which need to communicate. Alternatively, you can manipulate the /etc/hosts files within the containers, but this creates problems that are difficult to debug.

User-defined bridges provide better isolation:

All containers without a --network specified, are attached to the default bridge network. This can be a risk, as unrelated stacks/services/containers are then able to communicate.
Using a user-defined network provides a scoped network in which only containers attached to that network are able to communicate.

Containers can be attached and detached from user-defined networks on the fly:

During a container’s lifetime, you can connect or disconnect it from user-defined networks on the fly. To remove a container from the default bridge network, you need to stop the container and recreate it with different network options.

Each user-defined network creates a configurable bridge:

If your containers use the default bridge network, you can configure it, but all the containers use the same settings, such as MTU and iptables rules. In addition, configuring the default bridge network happens outside of Docker itself, and requires a restart of Docker.
User-defined bridge networks are created and configured using docker network create. If different groups of applications have different network requirements, you can configure each user-defined bridge separately, as you create it.

Linked containers on the default bridge network share environment variables:

Originally, the only way to share environment variables between two containers was to link them using the --link flag. This type of variable sharing isn't possible with user-defined networks. However, there are superior ways to share environment variables.

Multiple containers can mount a file or directory containing the shared information, using a Docker volume.
Multiple containers can be started together using docker-compose and the compose file can define the shared variables.
You can use swarm services instead of standalone containers, and take advantage of shared secrets and configs.

👉 Manage a user-defined bridge

Use the docker network create command to create a user-defined bridge network.

$ docker network create my-net

👉 Connect a container to a user-defined bridge

When you create a new container, you can specify one or more --network flags. This example connects an Nginx container to the my-net network. It also publishes port 80 in the container to port 8080 on the Docker host, so external clients can access that port. Any other container connected to the my-net network has access to all ports on the my-nginx container, and vice versa.

$ docker create --name my-nginx \
  --network my-net \
  --publish 8080:80 \
  nginx:latest

To connect a running container to an existing user-defined bridge, use the docker network connect command. The following command connects an already-running my-nginx container to an already-existing my-net network:

$ docker network connect my-net my-nginx

👉 Disconnect a container from a user-defined bridge

To disconnect a running container from a user-defined bridge, use the docker network disconnect command. The following command disconnects the my-nginx container from the my-net network.

$ docker network disconnect my-net my-nginx

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: User-defined networks
Medium Profile: Meghasharmaa
Hashnode: Megha Sharma's Blog

User-defined networks

Megha Sharma — Fri, 28 Nov 2025 16:56:15 +0000

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.

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev
🔗 Explore More Docker Tutorials
Next Blog: Docker Networking Overview
Medium Profile: Meghasharmaa
Hashnode: Megha Sharma's Blog

Docker Networking Overview

Megha Sharma — Fri, 21 Nov 2025 11:37:25 +0000

Docker networking refers to the set of technologies and functionalities within Docker that enable communication between containers, between containers and the host machine, and between containers and external networks. It allows containers to interact with each other and with external systems securely and efficiently.

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.

👉 Here are the key points to understand about Docker networking:

Container Communication: Docker networking enables containers running on the same host to communicate with each other using IP addresses or DNS names. This communication can be established within a single Docker host or across multiple Docker hosts in a cluster.
Network Isolation: Docker networking provides network isolation between containers, ensuring that each container has its own network stack and IP address.
Default Bridge Network: When you install Docker, it automatically creates a default bridge network called bridge. Containers connected to this network can communicate with each other using container names as DNS names. The default bridge network is suitable for most development and testing scenarios.
Custom Networks: Docker allows users to create custom networks using the docker network create command. This feature enables better control over networking configurations such as IP address ranges, subnets, and DNS settings.
Networking Drivers: Docker supports different networking drivers such as bridge, host, overlay, macvlan, and none. Each driver has specific use cases and functionalities, providing flexibility in how containers interact with networks.
Container-to-Container Communication: Containers within the same network can communicate with each other using their container names as hostnames. Docker’s built-in DNS server resolves container names to their respective IP addresses within the network.
Container-to-External Network Communication: Docker containers can communicate with external networks and services through port mappings or by connecting containers to external networks using custom bridge networks or host networking mode.
Service Discovery and Load Balancing: Docker networking integrates with service discovery and load balancing mechanisms, such as Docker Swarm’s built-in DNS-based service discovery and load balancing features. This allows containers to discover and communicate with services running on different containers or nodes in a cluster.
Network Security: Docker networking provides security features such as network segmentation, firewall rules, and network policies to control inbound and outbound traffic, ensuring secure communication between containers and networks.
Scalability and Orchestration: Docker networking is scalable and integrates seamlessly with container orchestration platforms like Docker Swarm and Kubernetes, allowing for dynamic network configurations and efficient management of containerized applications.

👉 Types of networking in Docker

Bridge Network:
Bridge network is a default network created automatically when you deploy a container. Bridge network uses a software bridge that allows containers connected to the same bridge network to communicate. Bridge networks used on containers that are running on the same Docker daemon host. The bridge network creates a private internal isolated network to the host so containers on this network can communicate.

The Bridge Network in Docker is a default networking mode that enables communication between containers on the same Docker host. It provides network isolation, giving each container its own IP address and DNS configuration. Containers connected to the bridge network can communicate using their IP addresses or container names, facilitated by Docker’s built-in DNS server. Additionally, bridge networking allows containers to access the internet through NAT rules. It’s commonly used in development and testing environments for local container communication. However, for more complex networking needs or distributed systems across multiple hosts, other Docker networking modes may be preferred.

Host Network:
The Host Network mode in Docker allows containers to share the host’s networking stack directly, bypassing Docker’s network isolation. In this mode, containers use the host’s IP address, network interfaces, and routing table, resulting in improved networking performance. Containers on the host network can access external networks and services without the overhead of network address translation (NAT) or port mapping. However, this mode lacks network isolation between containers and may not be suitable for scenarios requiring strict network segmentation. Host networking is commonly used for applications requiring maximum network performance or direct access to host networking interfaces, such as network-intensive services or legacy applications.

Overlay Network:
Overlay networking is used if container on node A wants to talk to node B then to make communication between them we use Overlay networking. Overlay networking uses VXLAN to create an Overlay network. This has the advantage of providing maximum portability across various cloud and on-premises networks. By default, the Overlay network is encrypted with the AES algorithm.

Overlay networking in Docker, especially in Docker Swarm, is used to facilitate communication between containers across different Docker hosts or nodes within a Swarm cluster. When a container on one node (let’s say node A) needs to communicate with a container on another node (node B), overlay networking comes into play.

Overlay networking leverages technologies like VXLAN (Virtual Extensible LAN) to create a virtual network overlay that spans all nodes in the Swarm cluster. This overlay network enables seamless communication between containers regardless of their physical host, providing a unified network environment for distributed applications.

One of the key advantages of overlay networking is its portability across various cloud environments and on-premises networks. Containers can communicate across different infrastructure setups without needing to worry about underlying network configurations, thanks to the abstraction provided by overlay networking.

Macvlan Network:
Macvlan network is used to connect applications directly to the physical network. By using the macvlan network driver to assign a MAC address to each container, also allow having full TCP/Ip stack. Then, the Docker daemon routes traffic to containers by their MAC addresses. You can isolate your macvlan networks using different physical network interfaces. This is used in legacy applications which require MAC address.

Macvlan networking in Docker is a mode that gives each container its own MAC address, making them appear as separate physical devices on the network. This enables containers to directly communicate with external networks without going through the Docker host’s network stack. Macvlan networking is beneficial for scenarios where containers require direct access to the underlying network infrastructure, such as when running network-intensive applications or services that need to expose specific ports. It provides improved network performance, isolation, and flexibility compared to bridge networking, making it suitable for applications needing container-to-network communication without network address translation (NAT) overhead.

ipvlan:
IPvlan networks give users total control over both IPv4 and IPv6 addressing. The VLAN driver builds on top of that in giving operators complete control of layer 2 VLAN tagging and even IPvlan L3 routing for users interested in underlay network integration.

📝 Liked this blog?
If you found this helpful, Buy me a coffee ☕
💬 Have questions or thoughts on Docker? Leave a comment below!
👉 Want more Docker content? Follow me on Dev

🔗 Explore More Docker Tutorials
Next Blog: Docker storage drivers
Medium Profile: Meghasharmaa
Hashnode: Megha Sharma's Blog

DEV Community: Megha Sharma

How Docker Compose works

👉 Compose Specification:

👉 The Compose file

👉 Services Section:

👉 Volumes Section:

👉 Configs Section:

👉 Secrets Section:

👉 Networks Section:

Installing Docker Compose

Scenario one: Install Docker Desktop

Scenario two: Install the Compose plugin

Scenario three: Install the Compose standalone

👉 Install the Docker Compose plugin:

👉 Install using the repository:

👉 Install the plugin manually:

👉 Install Compose standalone

👉 Uninstall Docker Compose

Docker Compose overview

👉 Key benefits of Docker Compose

👉 Common use cases of Docker Compose

👉History and development of Docker Compose

Docker Network Commands

👉List Docker Networks:

👉 Inspect a Docker Network:

👉Create a Docker Network:

👉 Connect a Container to a Network:

👉 Disconnect a Container from a Network:

👉Remove a Docker Network:

👉 docker network prune:

👉docker network create-ipam:

👉docker network connect-ipam:

👉docker network disconnect-ipam:

👉 Example:

What is None network driver

👉 Possible Use Cases:

What is Macvlan network driver?

Keep the following things in mind:

👉 Use case of Macvlan network:

👉 Prerequisites

👉 Create a Macvlan network

Bridge mode example:

802.1Q trunked bridge example:

What is IPvlan network driver?

👉Kernel requirements:

👉 Example:

👉 In Other Example:

What is Host network driver?

Use cases:

Limitations of the host driver

Example using host driver:

What is Overlay network driver?

Create an overlay network

Here are the steps to create an overlay network in Docker Swarm:

Encrypt traffic on an overlay network

Attach a container to an overlay network

What is Bridge network driver?

👉 Differences between user-defined bridges and the default bridge

👉 Manage a user-defined bridge

👉 Connect a container to a user-defined bridge

👉 Disconnect a container from a user-defined bridge

User-defined networks

Docker Networking Overview

Limitations of the `host` driver

Example using `host` driver: