Containers get their own network namespace, so a server listening inside the container is not automatically reachable from your laptop. Publishing a port maps host traffic into the container.
Volumes attach persistent storage to a container path. They are useful for databases and development workflows, but they also explain why deleting and recreating a container may not reset the data you see.
Ports
Publishing a port maps host traffic to a container port. The application inside the container still needs to listen on an address reachable from that container namespace, usually 0.0.0.0 for web servers.
docker run --rm -p 8080:80 nginx:alpine
docker port <container>
docker logs <container>Networks
Containers on the same user-defined Docker network can reach each other by container or service name. This is the pattern Docker Compose uses for multi-service apps.
Use network names instead of hard-coded container IPs. Container IPs are implementation details and can change.
Volumes
A named volume is managed by Docker and survives container removal. A bind mount points at a specific path on the host and is common during development.
If data keeps coming back after recreating a container, inspect the mounts and volumes before blaming the image.
docker volume ls
docker inspect <container>
docker volume rm <name>what to remember
- Expose only the ports you need, and check whether the app listens on 0.0.0.0 or localhost.
- Use named volumes for persistent app data and bind mounts for local development files.
- When debugging stale state, inspect both the container and the volume behind it.