Docker’s Virtual Network

Docker’s Virtual Network

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.

Enough of the intro!, let us 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

Pulls the image from docker hub

Docker Container runs as a special system application/process differing virtual machines, Which 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

No alt text provided for this image

So, the required node JS version, the libraries, whatnot everything that is required for our application to compile and run will be loaded onto an image, and this image can be moved anywhere regardless of any operating system you use, do you want my application? Install docker, download the image, and let the container run from the image above, and you will be having my app, within seconds, with no hassle of downloading the required versions of node, libs, etc.

No alt text provided for this image

So this initially solves, dependency issues, syntax-based errors [python2 and python3], and the core problem docker solves the compatibility issues of services/applications with the host OS, every time version of any service updates, you might need to recheck incompatibilities with the underlying OS, that's not the case with docker, so like you can run 2 node JS applications with 2 different node JS versions

No alt text provided for this image

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!

In general speaking, without docker, installing apache and MySQL on a public internet faced server, will open port 3306 and port 80 to the public so that apache and MySQL can interact with each other to provide us an interactive website so that apache can store/retrieve information from SQL, but port 3306 will remain open to the public internet, the interaction will not happen if you close any of them

So, By default, containers will be created and assigned to a private default docker network [docker0], let's say we created an apache[web] container and MySQL[db] container in the docker network, so the apache will port 80 on the host as well as in the docker, and the host will listen for incoming connection on port 80 and redirect them to our docker application running in our virtual docker network

docker container run -p 8000:5000 web

Making this more clear the docker0 network will reside on the 172.19.0.0 network where apache lies on 172.19.0.3 and SQL lies on 172.17.0.2 and the host OS is having an IP address 192.168.1.2, so this makes us clear that they are on completely different networks, but the connection happens because of the NAT translation between the docker virtual network and the host network via my bridge which acts 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] and 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 you want like 172.18.0.0, 172.19.0.0, 172.20.0.0 networks, so 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 and 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 from the rest of the containers

Elastic container wants to talk with web/DB network

For every separate virtual network, there will be a separate my bridge created, so if 172.18.0.2 wants to talk with 172.19.0.3 then it has to travel through the bridge[172.18.0.1] and then has to reach the host at 192.168.1.2 and then again it will go through bridge [172.19.0.1], and now it can reach 172.19.0.2

Thanks!

Sumo :)

要查看或添加评论,请登录

社区洞察

其他会员也浏览了