Name: Mini talk - Allow Containers to Communicate through Docker Networks
Uploaded: 2021-01-06T14:24:59-06:00
Description: Docker containers that are running on your local machine can't communicate with each other. In this mini talk, the instructor explains why and shows a demonstration of Docker networks.

Course Intro: Containerize Full-Stack JavaScript Applications with Docker

Configure and Run a Node.js API Powered by a Vue Application

Running Your First Container

Use Environment Variables for Docker Containers

Run MySQL in Docker Container

Integrate a MySQL Docker Container Into an Application

Create a Custom Image with a Dockerfile running Node.js

Mini talk - Allow Containers to Communicate through Docker Networks

Allow Containers to Communicate through Docker Networks

Mini talk - Containerize the Front End of an Application with a Multi-Step Docker Build

Containerize the Front End of an Application with a Multi-Step Docker Build

Mini talk - Access Environment Variables in a Dockerfile to Build a Front-End Container

Access Environment Variables in a Dockerfile to Build a Front-End Container

Modify a JSON Configuration File with jq

Create a Node.js Non-root Image

Run an Nginx Image as Non-Root Within a Multi-Step Docker Build Process

Push a Docker Container Image to Docker Hub

Use Docker Compose To Share An Entire Application

Containerize Full-Stack JavaScript Applications with Docker

Docker containers that are running on your local machine can't communicate with each other. In this mini talk, the instructor explains why and shows a demonstration of Docker networks.

https://app.egghead.io/api/v1/lessons/docker-mini-talk-allow-containers-to-communicate-through-docker-networks/subtitles

Instructor: [0:01] In the last lesson, our backend stopped working again because it couldn't find a database. That might seem odd, especially since we fixed a similar issue in a previous lesson. It makes a lot of sense when you think about it.

[0:16] One of the advantages of running containers is that they run in isolation. As far as the container is concerned, nothing exists outside of it. It behaves as if it was its own operating system. This is why the backend can't find a database on localhost. The two containers are running in the same host, but as far as the backend is concerned, there is no database.

[0:40] The same goes for the database. It can't see anything outside of what is running inside its own container. Therefore, it can't see the backend application running. This is great for many reasons. First of all, it prevents your containers to access the host operating system. If something happens inside the container and crashes it, you can simply restart it. Nothing can happen to the host machine.

[1:05] It also helps to prevent unwanted communication between various containers that might be running on your host. You might have multiple databases running, but you won't want all of your applications to have access to all those databases. Containers will prevent this.

[1:21] Yet, sometimes you want your containers to be able to speak to each other. This is where container networks can help you. To demonstrate this, you can start by running two Alpine containers. Use the -it flag to run it in interactive mode and the -d flag to run it in the background. Make sure to add the --rm flag to clean it up afterwards.

[1:45] Give it a name. You can use One. The base image you will use is Alpine. We will ask Alpine to execute /bin/sh once it starts. Because the container is running in interactive and detached mode, this will open up a session in the container, and it will prevent it to close until we use a docker stop command. You can also start an identical container called Two.

[2:11] Now that you have those two containers, you can use a docker exec command to log into the first one. You will use the -it flag to run this command in interactive mode. Specify the container on which to execute the command. This will be container one. Specify the command to be executed. We execute /bin/sh to open up a shell session inside the container.

[2:33] You are now inside the container. From here, if you try to do things like ls, you will see the content of the file system of this particular container. If you try various commands that would normally work on your laptop, they most likely won't work. For example, you can try to run docker ps to see what are the containers, and you will get an error message saying that Docker is not found.

[2:56] Once again, this is because your container is entirely isolated. As far as this container is concerned, Docker was never installed. The Alpine image comes with a very limited set of tools and is ideal for lightweight images. It comes pre-packaged with ping, which is the only one you will need for now.

[3:15] Docker took care of networking your container to the outside world using your network interface. This is why you can ping various services from inside the container. If you want to reach the redhat.com website, you should see the response time where you're using ping. You can use Ctrl+C to stop the ping command.

[3:34] If that works, you should be able to ping the other container, right? That would make sense. Try pinging the other container called Two. You will get an error message. Once again, as far as this container is concerned, the container named Two does not exist. You can exit the shell session with the exit command, and you can stop those two containers from running now.

[3:56] Now, we need a way for those two containers to be able to talk to each other. Docker has a tool called Networks to help you with this. The first thing you'll want to do is to create a network. A network will create a group of containers that can talk to each other.

[4:13] To create this network, you use the docker network command. Use Create to create a new network, and give it the name Alpine Network. Now, every container that we add to this network will be able to see each other. You can add a container to this network by using the --network parameter in the docker run command.

[4:32] Do this for the two Alpine containers that you had running earlier. Your two containers are now running and are part of the same network. You can see the network configuration with the docker network inspect command. From here, you can see the containers that are a part of this network, along with their internal IP addresses.

[4:54] Now, let's log back into the container called One. From here, you can try to do a ping to the container called Two again. You should see that the container is successfully pinged.

[5:06] Docker added the name of the containers to the internal host list, so you don't even have to learn the IP addresses of the containers. You can reach them by their own name, which makes it a lot easier to be able to get all of your microservices to speak to each other. You're now ready to apply those same principles to your application.

Mini talk - Allow Containers to Communicate through Docker Networks

Share this video with your friends

Course

Containerize Full-Stack JavaScript Applications with Docker