Skip to main content
Docker Basics Tutorial
CHAPTER 07 Beginner

Docker Networking Basics

Updated: May 15, 2026
20 min read

# CHAPTER 7

Docker Networking Basics

1. Introduction

A production application rarely consists of a single container. You typically have a Frontend (React), a Backend API (PHP/Node.js), and a Database (MySQL). For these isolated containers to function as a cohesive application, they must be able to communicate securely over a network. In this chapter, we will master Docker Networking, learning how to create custom virtual networks to allow containers to discover and talk to each other while remaining hidden from the outside world.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Understand the default bridge network.
  • Explain the concept of Port Mapping (Publishing).
  • Create a custom Docker network.
  • Understand automatic DNS resolution between containers.
  • Connect multiple containers securely without exposing internal ports.

3. Beginner-Friendly Explanation

Imagine an office building with a highly secure internal telephone system.
  • No Network: Bob and Alice sit in separate soundproof rooms. They cannot speak to each other.
  • The Default Network: Bob and Alice are given phones, but they only know each other's IP addresses (e.g., 172.17.0.2). Because IP addresses change every day, they constantly call the wrong number.
  • A Custom Docker Network: Bob and Alice are placed in the same custom "Department" network. Docker acts as the receptionist. Bob simply picks up the phone and dials the name "Alice." Docker automatically looks up Alice's current IP address and connects the call.

4. The 3 Default Network Drivers

When you install Docker, it automatically creates 3 types of networks:
  1. 1. Bridge (The Default): A private internal network created on your host machine. If you don't specify a network, containers are attached here.
  1. 2. Host: The container removes network isolation entirely and shares the exact IP address and ports of your laptop/server. (Extremely fast, but dangerous for security).
  1. 3. None: Disables all networking. The container is completely isolated from the world.

5. Port Mapping (-p) vs. Exposing

This is a critical distinction that confuses many beginners:
  • Expose (Internal): A container saying "I am listening on Port 3306." If a Database and a Web Server are on the same Docker Network, the Web Server can freely talk to the Database on Port 3306. The outside world *cannot*.
  • Port Mapping/Publishing (-p): This punches a hole through your laptop's firewall. docker run -p 8080:80 takes traffic from your laptop's physical Port 8080 and funnels it into the container's Port 80. You ONLY map ports that the public internet (or your browser) needs to access.

*Golden Rule:* Never use -p 3306:3306 for a production database unless you explicitly want hackers on the internet to attempt to log in!

6. Automatic DNS Resolution

If you place two containers on the Default Bridge network, they must communicate using IP addresses (which change every time a container restarts). This is useless for production. However, if you create a Custom User-Defined Network, Docker activates its internal DNS server. Containers can suddenly communicate using their *Container Names*!

7. Mini Project: Connect a Web App to a Database

Let's build a secure, 2-tier architecture.

Step-by-Step Tutorial:

  1. 1. Open your terminal. Create a custom network:

bash
1 
docker network create my-app-net
  1. 2. Launch a MySQL Database container, attach it to our network, and do NOT use -p (Keep it secure!):
bash
12345 
docker run -d \
  --name my-db \
  --network my-app-net \
  -e MYSQL_ROOT_PASSWORD=secret \
  mysql:8.0
  1. 3. Now, let's launch a temporary Linux container attached to the *same* network to test the connection:
bash
1 
docker run -it --network my-app-net alpine sh
  1. 4. You are now inside the Alpine container. It does not have the mysql tool installed, but we can test the network using ping. Type:
bash
1 
ping my-db
  1. 5. *The Magic:* You will see successful ping replies! Notice that the Alpine container automatically translated the name "my-db" into a private IP address (e.g., 172.18.0.2). You did not have to configure any DNS or memorize IPs!
  1. 6. Type exit to leave the Alpine container. Clean up the database:
bash
12 
docker stop my-db
docker rm my-db

8. Real-World Scenarios

A company has a React Frontend, a Node.js Backend API, and a MongoDB Database. The architect creates a network called ecommerce-net. The React container is launched with -p 80:80 (so customers can see the website). The Node container and Mongo container are launched with NO -p flag. The React app talks to Node via http://node-api:3000, and Node talks to Mongo via mongodb://mongo-db:27017. The database and API are 100% invisible to the outside internet, rendering them highly secure from external attacks.

9. Best Practices

  • Network Segmentation: Do not put all your company's containers onto one massive custom network. Create separate networks. Place the Frontend and Backend on frontend-net. Place the Backend and Database on backend-net. This ensures the Frontend container physically cannot route traffic to the Database container, enforcing a strict defense-in-depth architecture.

10. Common Mistakes

  • Relying on Default Bridge: Developers often launch multiple containers and wonder why their web server throws a "Database Host Not Found" error when trying to connect via container name. If you do not explicitly create a network with docker network create, Docker puts them on the default bridge, which does *not* support automatic DNS name resolution!

11. Exercises

  1. 1. Explain the architectural difference between Exposing a port internally and Publishing (-p) a port to the host machine.
  1. 2. Why is relying on Container IP addresses for communication considered an anti-pattern in Docker?

12. FAQs

Q: Can containers on different networks talk to each other? A: By default, no. Docker sets up strict firewall rules isolating custom networks. If Container A is on Network1 and Container B is on Network2, they cannot ping each other. A container must be explicitly connected to both networks to act as a bridge.

13. Interview Questions

  • Q: Describe Docker's internal DNS resolution. What specific network configuration is required for two containers to resolve each other's hostnames automatically?
  • Q: A security audit requires that a MySQL container be entirely inaccessible from the host machine's physical network, yet fully accessible to a PHP web container. Detail the Docker networking commands and flags required to architect this.

14. Summary

In Chapter 7, we eliminated the isolation of single containers and built cohesive network architectures. We distinguished between opening internal ports for container-to-container traffic and punching holes through the host firewall via Port Publishing (-p). Crucially, we discovered the power of Custom User-Defined Networks, unlocking Docker's internal DNS server to allow our web servers to seamlessly communicate with databases using human-readable container names instead of fragile, fluctuating IP addresses.

15. Next Chapter Recommendation

Typing docker run, docker network create, and docker volume create manually in the terminal is exhausting when you have a 5-container application. We need a way to automate this. Proceed to Chapter 8: Docker Compose Fundamentals.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Docker Volumes and Persistent Storage
Next Chapter Docker Compose Fundamentals

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 5

❓ Related Quizzes 6

🎥 Related Videos 1