We also know that at container runtime, in order to actually attach to the exposed port created during the build process, we must pass in command line arguments like so:
docker run -d -p 80:80 apachephp
How to network 2 containers
Many times you will have multiple containers that you need to link together. Remember we want to make sure each container is doing separate tasks. I.e. you may have one container running apache and php, another container running mysql.
How to get them to talk to one another?
Docker Networking
This page has a lot of information about networking with docker.
Docker Networking commands
docker network ls
Shows the networks that are available to our containers. By default the bridge network is what containers are attached to. You can read about the other two.
Docker Networking Types
User-defined Bridge Networks: are best when you need multiple containers to communicate on the same Docker host.
Host Networks: are best when the network stack should not be isolated from the Docker host, but you want other aspects of the container to be isolated.
Overlay Networks: are best when you need containers running on different Docker hosts to communicate, or when multiple applications work together using swarm services(Not going to discuss)
Macvlan Networks: are best when you are migrating from a VM setup or need your containers to look like physical hosts on your network, each with a unique MAC address. (Can put containers on different vlans than your host machine)(Not going to discuss)
Docker Networking
This command will show us information about the bridge network. And the containers attached to it.
docker network inspect bridge
Docker Bridge Network
Containers connected to the default bridge network can communicate with each other by IP address. Docker does not support automatic service discovery on the default bridge network. If you want containers to be able to resolve IP addresses by container name, you should use user-defined networks instead.
User defined bridge vs default bridge
User-defined bridges provide automatic DNS resolution between containers.
Imagine an application with a web front-end and a database back-end. If you call your containers web and db, the web container can connect to the db container at db, no matter which Docker host the application stack is running on.
User-defined bridges provide better isolation.
You want to restrict what other containers might have access to others
Containers can be attached and detached from user-defined networks on the fly but in the default bridge, you would have to stop & recreate it with other network options.
Each user-defined network creates a configurable bridge, you can customize this network and rules a lot easier than the default, and make them more specific to the containers that you are running.
User defined bridge vs default bridge
Containers connected to the same user-defined bridge network effectively expose all ports to each other. For a port to be accessible to containers or non-Docker hosts on different networks, that port must be published using the -p or --publish flag.
docker network connect isolated_nw mysqltest
#create 2 instances of the following container for example on next page
docker container run -d --net mybridgenet --net-alias search elasticsearch:2
docker container run -d --net mybridgenet --net-alias search elasticsearch:2
Docker bridge example
docker container run --rm --net mybridgenet alpine nslookup search.mybridgenet
Do this command multiple times and you should be able to bounce back and forth from the previous 2 containers
docker container run --rm --net mybridgenet centos curl -s search:9200
Take aways
Don't use the default docker bridge network for production