Docker’s Virtual Network
Everything needed to understand docker networks, It’s simple but fascinating
Hello there, let's talk about docker, who is this docker, why so much name and fame? Have you ever seen a docker logo?
Docker was founded by a small company and later, they started a new company named docker, The docker logo: The whale carrying a stack of containers symbolizes the company’s four core values: expedition, automation, encapsulation, and simplification blah, blah.
Let's get into Docker. Docker is a toolkit, and it is not a virtual machine. Docker is a container-based service, where everything gets loaded onto a union of little layer-based images. An image is like a source, and we make containers out of images. So a running/compiled node JS application is a container, and guess what, we can make as many containers we want from a single docker image on a single docker machine.
Docker Container runs as a special system application/process that differs from virtual machines. It will have the same computation power as the host does. For example, we have a node JS application. The application requires lots of libraries, and there are even version-based syntax's, where certain code gets compiled only on a specific version of node/python.
So, the required node.js version, the libraries, and everything else that is required for our application to compile and run will be loaded onto an image. This image can be moved anywhere, regardless of the operating system you use. Do you want my application? If you install docker and download the image above, you will be able to run my app without having to worry about installing the required versions of node, libs, etc.
So, this should resolve dependency issues, syntax-based errors, and the core problem that Docker solves—compatibility issues between services and the host OS. Every time a service's version updates, you might need to recheck for compatibility issues with the underlying OS. That's not the case with Docker, so you can run two-node JS applications with two different node JS versions.
The command above will start an Nginx container in the background and the p flag will publish and open port 5555 on the host and redirects them to dockers port 80 for Nginx to reply, and yes dockers will maintain a separate virtual network differing from the host network. Let's interpret this, that is not how simple it may look, there is an underlying docker network that makes this process smooth and sexy!
Without Docker, installing Apache and MySQL on a public internet-facing server will open port 3306 and port 80 to the public, so that Apache and MySQL can interact with each other to provide an interactive website. Port 3306 will remain open to the public internet, and the interaction will not happen if you close it.
So, by default, containers will be created and assigned to a private default Docker network [docker0]. Let's say we created an apache and MySQL container in the Docker network. In that case, the apache will use port 80 on the host as well as in the docker0 network, and the host will listen for incoming connections on port 80 and redirect them to our Docker application running in our virtual Docker network.
Docker's virtual network resides on the 172.19.0.0 network, where Apache lies on 172.19.0.3 and SQL lies on 172.17.0.2. The host's IP address is 192.168.1.2. This makes it clear that they are on completely different networks, but the connection happens because of the NAT translation between the virtual network and the host network via my bridge, which acts as a gateway endpoint to the docker's network.
The 172.17.0.2 can talk with 172.17.0.3 and vice versa via the mybridge gateway, and the gateway will reside at 172.17.0.1[mybridge]. This 172.17.0.1 can talk with 192.168.1.2 to make a successful public-internet connection, so this basically restricts the communication to sustain within the docker's virtual network between the web and DB, to be more precise the communication between the DB and web will never leave the docker network, which makes it more secure than the public-facing server application model.
That's it? No, there is even more. You can create as many virtual networks as you want, like 172.18.0.0, 172.19.0.0, 172.20.0.0 networks. The basic reason for this is to create an isolated network for relatable containers. Let's say you have a web, DB, and elastic search containers, and the web and DB containers have to talk with each other, but there is no need for a connection between elastic search and the rest. So we will move the web and DB containers to a separate virtual network, isolating them from the rest of the containers.
For each separate virtual network, a separate my bridge will be created. If 172.18.0.2 wants to talk with 172.19.0.3, then it has to travel through the bridge at 172.18.0.1 and then reach the host at 192.168.1.2. Once again, it will go through the bridge at 172.19.0.1 before reaching 172.19.0.2.
Sumo :)