# Demonstration: Reaching a Container By Name, Not IP

## OBSERVE

```
$ docker network create demo-net
$ docker run -d --name api-server --network demo-net nginx:alpine
```

## HYPOTHESIS

Predict: can another container on `demo-net` reach `api-server` using its NAME as a hostname,
without knowing its IP?

## INSPECT

```
$ docker run --rm --network demo-net alpine:3.19 sh -c "wget -qO- http://api-server:80/ | head -1"
<!DOCTYPE html>
```

Yes — Docker's built-in DNS resolved `api-server` (a container NAME) directly, no IP address
needed anywhere in that command.

## CHANGE

Now try reaching it from a container that is NOT on the same network:

```
$ docker run --rm alpine:3.19 sh -c "wget -qO- http://api-server:80/ 2>&1 | head -1"
wget: bad address 'api-server'
```

Name resolution fails entirely — the container isn't even on the same Docker network, so there's
no DNS entry for it there.

## VERIFY

Container-to-container name resolution is scoped to a SPECIFIC Docker network, not global —
exactly like ROOT 02's subnet concept: reachability depends on which network you're actually on.

## Instructor Notes

**Demo goal:** Show container-name DNS resolution as a real, working feature — and show it
explicitly FAILING when containers aren't on the same network, reinforcing that this isn't
magic, it's scoped.

**Approximate timing:** 8 minutes live.

**Common mistake to watch for:** assuming any two containers can always reach each other by name
regardless of network — reinforce the "same network required" rule explicitly.