DOCKER - 14 Network Concepts
This section assumes you know how to start a container and that you have a basic grasp of TCP/IP — subnets, IP addresses, ports and firewalls. You don't need to be an expert, but the concepts will make the following lessons much smoother. The key flag to keep in mind is -p host:container on docker container run, which publishes a port of your machine onto the container. Docker follows a "batteries included but removable" philosophy: defaults work out of the box, yet almost every parameter can be customised.
How Docker networking is wired
When you start a container, you're really attaching it to a Docker network. By default that's the bridge network, routed through a NAT firewall that Docker sets up against your host's default interface so the container can reach the internet. Two containers that need to talk to each other on the same host should sit on the same Docker network — for example an Nginx and a PHP/Apache container in the same app — and they then don't need -p at all. Unrelated apps (say a Mongo + Node.js stack) can live on a separate network, isolated from the first one.
Many things are configurable: you can create several virtual networks (one per app, or split by security level), attach multiple virtual NICs to a single container, or even cut a container off from networking entirely. You can also bypass Docker's virtual networking with --net=host, at the cost of losing some isolation benefits. Later lessons will cover network drivers (overlay for multi-host, third-party plugins like Weave) and more advanced topics.
docker container run -p 80:80 --name webhost -d nginx— publish port 80docker container port webhost— list which ports are forwarded for a containerdocker container inspect --format '{{ .NetworkSettings.IPAddress }}' webhost— get the container's virtual IP
One last subtlety: the container does not share the host's IP. Inspecting the container reveals its own IP on Docker's virtual subnet (typically 172.x.x.x), separate from your physical network (often 192.168.x.x). For local development the defaults are usually enough, but everything is editable when production needs grow.