# Docker Networking

***

[1](https://www.youtube.com/watch?v=fBRgw5dyBd4), [2](https://www.youtube.com/watch?v=bKFMS5C4CG0)

***

Docker networking is what allows your containers to talk to each other, the host machine, and the outside world. By default, Docker provides an isolated environment for each container, but you can use different network drivers to control how that isolation is broken.

***

#### The Core Network Drivers

Docker uses drivers to handle networking. Choosing the right one depends on your use case:

| **Driver**       | **Best Use Case**                 | **Key Characteristic**                                                   |
| ---------------- | --------------------------------- | ------------------------------------------------------------------------ |
| Bridge (Default) | Standard standalone containers.   | Creates a private internal network on the host.                          |
| Host             | Performance-critical apps.        | Removes isolation; container uses host's IP directly.                    |
| Overlay          | Multi-host / Docker Swarm.        | Connects multiple Docker daemons together.                               |
| Macvlan          | Legacy apps / Network monitoring. | Assigns a MAC address, making the container look like a physical device. |
| None             | Highly secure/Isolated tasks.     | Disables all networking for the container.                               |

***

#### Working with the Bridge Network

The Bridge network is what you will use 90% of the time.

**Default vs. User-Defined Bridges**

* Default Bridge: When you run a container without specifying a network, it joins the default `bridge`. However, containers on the default bridge can only talk to each other via IP addresses, which change often.
* User-Defined Bridge: Recommended for production. These provide Automatic DNS Resolution, meaning containers can talk to each other using their container names as hostnames.

**Hands-on Example:**

```bash
# 1. Create a custom network
docker network create my-app-net

# 2. Run a database container on that network
docker run -d --name db-container --network my-app-net mariadb

# 3. Run a web app on the same network
# It can now reach the DB using the hostname "db-container"
docker run -d --name web-app --network my-app-net my-web-img
```

***

#### Essential Docker Network Commands

Use these commands to manage and troubleshoot your connections:

* `docker network ls`: Lists all networks on your engine.
* `docker network inspect [name]`: See the subnet, gateway, and which containers are connected (with their IPs).
* `docker network connect [net] [container]`: Add a running container to a network on the fly.
* `docker network disconnect [net] [container]`: Remove a container from a network.
* `docker network prune`: Clean up all unused networks.

***

#### **Advanced: Overlay and Macvlan**

**Overlay (Multi-host)**

If you are running a cluster of servers (Docker Swarm), the Overlay driver creates a distributed network. Traffic is encrypted by default, and containers on Host A can ping containers on Host B as if they were on the same local switch.

**Macvlan (Direct Physical Access)**

If you have an application that *must* have its own identity on your physical network (e.g., it needs its own IP from your router's DHCP), Macvlan is the answer. It bypasses the Docker bridge entirely.

***

#### Pro-Tips for 2026

* Use Docker Compose: Don't manually create networks. Define them in your `docker-compose.yml`. Compose automatically creates a shared bridge network for all services in the file.
* Don't expose all ports: Use the `-p` flag only for services that need to be accessed from *outside* the host. For internal communication (like Web to DB), they will talk over the internal bridge without needing exposed ports.
* Security: If a container doesn't need internet access, use the `--internal` flag when creating the network to block all external traffic.

***