Checkpoint Lab — Container Networking Foundations: Bridge, Host, None, User-Defined Networks, Endpoints, and Namespaces

1. Setup and assumptions

Create a local evidence directory and record versions first. The mandatory path works on Docker Engine/Linux and Docker Desktop with ordinary bridge networking. Host networking, cloud registries, external DNS, and paid capabilities are not required.

mkdir -p da-network17-checkpoint/evidence
cd da-network17-checkpoint

docker version > evidence/docker-version.txt
docker info > evidence/docker-info.txt
docker context show > evidence/docker-context.txt
docker compose version > evidence/compose-version.txt 2>&1 || true
docker buildx version > evidence/buildx-version.txt 2>&1 || true

docker network ls > evidence/networks.before.txt

docker pull busybox:1.36.1
docker image inspect busybox:1.36.1   --format 'id={{.Id}} repodigests={{json .RepoDigests}}'   > evidence/busybox.identity.txt

Assumptions to write down: Engine/Desktop version, OS/context, bridge driver availability, no production containers using the checkpoint names, and no need to alter daemon/firewall configuration.

2. Create two isolated network objects

The networks are “isolated” from each other by separate user-defined bridge membership. We intentionally let Docker choose non-overlapping subnets so the lab does not collide with an unknown host VPN/LAN.

docker network create   --driver bridge   --label devops-academy.lab=network17-checkpoint   da-net17-left

docker network create   --driver bridge   --label devops-academy.lab=network17-checkpoint   da-net17-right

docker network inspect da-net17-left > evidence/left.empty.json
docker network inspect da-net17-right > evidence/right.empty.json

3. Predict state changes before containers exist

1. Prediction A: left-service will have one endpoint only on da-net17-left; right-service will have one endpoint only on da-net17-right.
2. Prediction B: dual-test will have two endpoints, one address/gateway context per network, while keeping a single container ID/PID 1.
3. Prediction C: dual-test can reach each service by its network-scoped name because it is a member of both networks.
4. Prediction D: left-service cannot directly resolve/reach right-service, because they share no network and we do not enable routing through dual-test.
5. Prediction E: no host port is published and no daemon/firewall setting changes.

4. Create one service per network plus a dual-homed tester

docker run -d \
  --name da-net17-left-service \
  --network da-net17-left \
  --label devops-academy.lab=network17-checkpoint   busybox:1.36.1   sh -c 'mkdir -p /www; echo left > /www/index.html; exec httpd -f -p 8080 -h /www'

docker run -d \
  --name da-net17-right-service \
  --network da-net17-right \
  --label devops-academy.lab=network17-checkpoint   busybox:1.36.1   sh -c 'mkdir -p /www; echo right > /www/index.html; exec httpd -f -p 8080 -h /www'

docker run -d   --name da-net17-dual-test   --network da-net17-left   --label devops-academy.lab=network17-checkpoint   busybox:1.36.1 sleep 3600

docker network connect da-net17-right da-net17-dual-test

5. Capture endpoint, route, DNS, and identity evidence

docker inspect da-net17-left-service --format '{{json .NetworkSettings.Networks}}'   > evidence/left-service.networks.json
docker inspect da-net17-right-service --format '{{json .NetworkSettings.Networks}}'   > evidence/right-service.networks.json
docker inspect da-net17-dual-test --format '{{json .NetworkSettings.Networks}}'   > evidence/dual-test.networks.json

docker inspect da-net17-dual-test --format   'id={{.Id}} image={{.Image}} pid={{.State.Pid}} status={{.State.Status}}'   > evidence/dual-test.identity.txt

docker exec da-net17-dual-test ip addr > evidence/dual-test.ip.txt
docker exec da-net17-dual-test ip route > evidence/dual-test.routes.txt
docker exec da-net17-dual-test cat /etc/resolv.conf > evidence/dual-test.resolver.txt

docker network inspect da-net17-left > evidence/left.with-endpoints.json
docker network inspect da-net17-right > evidence/right.with-endpoints.json

Review the evidence before testing connectivity. Confirm the dual-homed container has two network entries and two address contexts. This proves membership; it does not prove forwarding between the networks.

6. Verify the predicted communication matrix

# These two should succeed:
docker exec da-net17-dual-test wget -qO- http://da-net17-left-service:8080/   | tee evidence/dual-to-left.txt
docker exec da-net17-dual-test wget -qO- http://da-net17-right-service:8080/   | tee evidence/dual-to-right.txt

# Left service should not resolve/reach right service directly:
docker exec da-net17-left-service sh -c   'wget -qO- -T 2 http://da-net17-right-service:8080/ || true'   > evidence/left-to-right.expected-failure.txt 2>&1

# Right service should not resolve/reach left service directly:
docker exec da-net17-right-service sh -c   'wget -qO- -T 2 http://da-net17-left-service:8080/ || true'   > evidence/right-to-left.expected-failure.txt 2>&1

# No host publication should exist:
docker port da-net17-left-service > evidence/left.published-ports.txt
docker port da-net17-right-service > evidence/right.published-ports.txt

The success/failure pattern is the core checkpoint result. The dual-homed test container can initiate connections to both networks because it owns endpoints on both. The two single-homed services remain isolated from each other because there is no shared network and we did not configure dual-test as a forwarding router.

7. Evidence packet checklist

Create the limitations note:

cat > evidence/ASSUMPTIONS.txt <<'EOF'
Lab: Docker Chapter 17 checkpoint
Baseline checked: 2026-09-21
Mandatory network mode: user-defined bridge only
No host port publication, daemon mutation, firewall edit, privileged mode, or IP forwarding enabled
Dual-homed container is a test endpoint, not a router
Docker Desktop may implement host/bridge internals behind a managed VM; Engine API/container evidence is authoritative for this lab
Engine 29 nftables backend is experimental; this lab does not change firewall backend
EOF

8. Verification checklist

• Two labeled bridge network objects exist with distinct IDs/IPAM ranges.
• Left and right services each have exactly one intended endpoint.
• Dual-test has endpoints on both networks and remains one container/process object.
• Dual-test reaches both service names over their respective networks.
• Left and right services cannot directly reach each other by name.
• No published host ports exist.
• No firewall, daemon, routing-forwarding, or privilege setting was changed.
• All image/network/container IDs and timestamps are retained before cleanup.

9. Cleanup and rollback

docker rm -f   da-net17-left-service   da-net17-right-service   da-net17-dual-test 2>/dev/null || true

docker network rm   da-net17-left   da-net17-right 2>/dev/null || true

# Verify checkpoint ownership is gone:
docker ps -a --filter label=devops-academy.lab=network17-checkpoint
docker network ls --filter label=devops-academy.lab=network17-checkpoint

# Keep evidence/ for review.

No broad prune is needed. The image can remain cached because it may be shared by other labs; delete it only after separately proving no dependent container requires it.

10. What Chapter 17 adds to the production operating model

You can now represent connectivity as evidence: exact Docker network object, endpoint membership, container-visible addresses/routes/DNS, host/platform assumptions, and application-level proof. That makes network intent reviewable and prevents “fixes” that flatten trust boundaries or expose ports unnecessarily.

11. Bridge to Chapter 18

Chapter 17 treated basic network membership and namespace/endpoint mechanics. Chapter 18 builds on that foundation with Docker DNS, service discovery aliases, IPv4/IPv6, custom subnets, and multi-network application identity. Keep one rule: network membership creates the scope in which names, aliases, and addresses have meaning.

Knowledge check

Official references and version notes

• Docker Docs — Networking overview: container-visible interfaces, routes, gateways, DNS, and built-in drivers.
• Docker Docs — Bridge network driver: default versus user-defined bridges, DNS, isolation, masquerading, and dynamic connect/disconnect.
• Docker Docs — Host network driver: shared host networking, ignored port publishing, Linux support, and Docker Desktop limitations.
• Docker Docs — None network driver: isolated network stack with loopback only.
• Docker CLI — docker network create: bridge creation, --internal, IPAM, labels, and network scope.
• Docker Docs — Packet filtering and firewalls: firewall rules for bridge networks and backend selection.
• Docker Docs — Docker with iptables: current iptables rule ownership and DOCKER-USER behavior.
• Docker Docs — Docker with nftables: Engine 29 experimental nftables backend and migration caveats.
• Docker Desktop networking how-tos: VM-boundary networking and host.docker.internal.
• Docker Engine 29 release notes: current Engine 29 networking changes and compatibility notes.