WEBVTT 00:00.210 --> 00:02.610 Hello and welcome to this lecture. In this lecture 00:02.610 --> 00:04.950 we look at networking in Docker. 00:05.040 --> 00:10.530 We will start with a basic networking options in Docker and then try and related to the concepts around 00:10.620 --> 00:11.910 networking name spaces. 00:11.970 --> 00:17.230 Let’s start with a single Docker Host. A server with Docker installed on it. 00:17.340 --> 00:23.240 It has an ethernet interface at eth0 that connects to the local network with the IP address 192.168.1.10. 00:23.280 --> 00:25.380 It has an ethernet interface at eth0 that connects to the local network with the IP address 192.168.1.10. 00:25.380 --> 00:29.700 When you run a container you have different networking options to choose from. 00:29.700 --> 00:32.970 First, let’s see the none network. With the None network, 00:33.000 --> 00:36.350 the docker container is not attached to any network. 00:36.390 --> 00:42.420 The container cannot reach the outside world and no one from the outside world can reach the container. 00:42.420 --> 00:48.360 If you run multiple containers they are all created without being part of any network and cannot talk 00:48.360 --> 00:51.270 to each other or to the outside world. 00:51.270 --> 00:54.330 Next is the Host network. With the host network, 00:54.330 --> 00:57.030 the container is attached to the host’s network. 00:57.030 --> 01:00.840 There is no network isolation between the host and the container. 01:00.870 --> 01:06.600 If you deploy a web application listening on port 80 in the container then the web application is available 01:06.630 --> 01:11.310 on port 80 on the host without having to do any additional port mapping. 01:11.310 --> 01:17.550 If you try to run another instance of the same container that listens on the same port it won't work 01:17.640 --> 01:23.460 as they share hosts networking and two processes cannot listen on the same port at the same time. 01:24.750 --> 01:30.930 The third networking option is the bridge. In this case, an internal private network is created which 01:30.930 --> 01:37.230 the docker host and containers attach to. The network has an address 172.17.0.0 01:37.230 --> 01:43.170 by default and each device connecting to this network get their own internal private network address 01:43.260 --> 01:44.880 on this network. 01:44.880 --> 01:51.660 This is the network that we are most interested in. So we will take a deeper look at how exactly docker 01:51.660 --> 01:55.000 creates and manages this network. 01:55.140 --> 02:01.590 When Docker is installed on the host it creates an internal private network called bridge by default. 02:01.590 --> 02:03.740 You can see this when you run the docker network 02:03.750 --> 02:09.960 ls command. Now, docker calls the network by the name “bridge”. But on the host the network is created 02:10.320 --> 02:12.480 by the name docker 0. 02:12.480 --> 02:18.630 You can see this in the output of the ip link command. Docker internally uses a technique similar to 02:18.630 --> 02:22.550 what we saw in the video on namespaces by running the IP link 02:22.600 --> 02:28.500 add command with the type set to bridge. So remember, the name bridge in the docket network ls output 02:28.500 --> 02:31.440 refers to the name docker 0 on the host. 02:31.500 --> 02:32.780 They are one and the same thing. 02:32.790 --> 02:37.100 Also note that the interface or network is currently down. 02:37.110 --> 02:43.070 Now, remember we said that the bridge network is like an interface to the host, but a switch to the 02:43.070 --> 02:45.590 namespaces or containers within the host. 02:45.660 --> 02:52.470 So the interface docker0 on the host is assigned an IP 172.17.0.1. 02:52.470 --> 02:56.270 You can see this in the output of the ip addr command. 02:56.610 --> 03:02.850 Whenever a container is created Docker creates a network namespace for it just like how we created 03:02.940 --> 03:03.340 network 03:03.360 --> 03:10.230 namespaces in the previous video. Run the ip netns command to list the namespace. 03:10.230 --> 03:16.080 Note that there is a minor hack to be done to get the ip netns command to list the namespaces 03:16.080 --> 03:17.660 created by Docker. 03:17.730 --> 03:21.710 Checkout the resources section of this lecture for information on that. 03:22.010 --> 03:26.160 The namespace has the name starting b3165. 03:26.160 --> 03:31.740 You can see the namespace associated with each container in the output of the docker inspect comment. 03:32.010 --> 03:37.920 So how does docker attach the container or its network namespace to the bridge network? For the remainder 03:37.920 --> 03:38.810 of this lecture. 03:38.840 --> 03:44.060 container and network namespace mean the same thing. When I say container 03:44.100 --> 03:47.880 I'm referring to the network namespace created by Docker for that container. 03:48.480 --> 03:53.010 So how does docker attach the container to the bridge? As we did before 03:53.010 --> 03:58.350 it creates a cable, a VIRTUAL cable, with two interfaces on each end. 03:58.980 --> 04:01.570 Let's find out what Docker has created here. 04:01.620 --> 04:07.170 If you run the ip link command on the docker host you see one end of the interface which is attached to 04:07.170 --> 04:08.880 the local bridge Docker zero. 04:09.510 --> 04:15.450 If you run the same command again this time with the –n option with the namespace, then it lists 04:15.480 --> 04:19.630 the other end of the interface within the container namespace. 04:19.680 --> 04:23.180 The interface also gets an IP assigned within the network. 04:23.280 --> 04:29.430 You can view this by running the ip addr command but within the container's namespace. The container 04:29.460 --> 04:33.210 gets assigned 172.17.0.3. 04:33.240 --> 04:38.470 You can also view this by attaching to the container and looking at the IP address assigned to it that 04:38.480 --> 04:38.730 way. 04:39.750 --> 04:45.990 The same procedure is followed every time a new container is created. Docker creates a namespace. Creates 04:45.990 --> 04:52.230 a pair of interfaces. Attaches one end to the container and another end to the present. The interface 04:52.230 --> 04:54.710 pairs can be identified using their numbers. 04:54.870 --> 04:58.810 Odd and even former pair 9 and 10 are one pair. 04:58.810 --> 05:02.910 7 and 8 are another and 11 and 12 are one pair. 05:02.910 --> 05:07.970 The containers are all part of the network now they can all communicate with each other. 05:08.130 --> 05:14.900 Let us look at port mapping now. The container we created is nginx, so it’s a web application serving 05:14.910 --> 05:21.080 web page on port 80. Since our container is within a private network inside the host. 05:21.330 --> 05:26.280 Only other containers in the same network or the host itself can access this Web page. 05:26.640 --> 05:32.550 If you tried to access the web page using curl with the IP of the container from within Docker host 05:32.640 --> 05:36.290 on port 80 you will see the web page. 05:36.300 --> 05:42.210 If you try to do the same thing outside the host, you cannot view the web page. To allow external users 05:42.210 --> 05:45.630 to access the applications hosted on containers. 05:45.630 --> 05:50.860 Docker provides a port publishing or port mapping option. When you run containers 05:50.940 --> 05:57.310 Tell Docker to map port 8080 on the Docker host to port 80 on the container. 05:57.390 --> 06:03.720 With that done, you could access the web application using the IP of the docker host and port 8080. 06:04.110 --> 06:10.380 Any traffic to port 8080 on the docker host will be forwarded to port 80 on the container. 06:10.390 --> 06:17.430 Now all of your external users and other applications or service can use this Url to access the application 06:17.460 --> 06:19.160 deployed on the host. 06:19.320 --> 06:21.060 But how does docker do that? 06:21.120 --> 06:24.730 How does it forward traffic from one port to another? 06:24.880 --> 06:25.740 What would you do? 06:26.430 --> 06:29.520 Let's forget about Docker and everything else for a second. 06:29.520 --> 06:36.000 The requirement is to forward traffic coming in on one port to another port on the server. 06:36.060 --> 06:39.260 We talked about it in one of our prerequisite lectures. 06:39.270 --> 06:46.050 We create a NAT rule for that. Using iptables we create an entry into the NAT table, to append a rule 06:46.080 --> 06:54.240 to the PREROUTING chain to change the destination port from 8080 to 80. Docker does it the same way. Docker 06:54.300 --> 07:01.630 adds the rule to the docker chain and sets destination to include the containers IP as well you can 07:01.630 --> 07:06.020 see the rule docker creates when you list the rules in iptables. 07:07.520 --> 07:10.040 Well that's it for this lecture in the next lecture. 07:10.040 --> 07:15.200 We will talk about CNI and what container networking interface is.