1 00:00:00,940 --> 00:00:05,440 Now let's turn our attention to configuring container networking. 2 00:00:05,440 --> 00:00:08,010 Now I'm assuming you're coming out of the previous module 3 00:00:08,010 --> 00:00:10,750 in which we learned about virtual switches and how 4 00:00:10,750 --> 00:00:13,330 networking works in Microsoft Hyper‑V. 5 00:00:13,330 --> 00:00:13,620 Well, 6 00:00:13,620 --> 00:00:18,730 what we have with Docker is a completely separate networking ecosystem, so 7 00:00:18,730 --> 00:00:23,640 I'm going to constrain our discussion only to the overlay between Docker 8 00:00:23,640 --> 00:00:26,870 container networking and Hyper‑V networking. 9 00:00:26,870 --> 00:00:30,910 And I'm just going to call it as the slide says, Windows Container Networking. 10 00:00:30,910 --> 00:00:34,610 So we can see here that on the Windows Hyper‑V host, 11 00:00:34,610 --> 00:00:39,570 we've got VMs or Hyper‑V containers on one side, 12 00:00:39,570 --> 00:00:42,900 and then we have just standard process isolation 13 00:00:42,900 --> 00:00:45,120 Windows containers on the right side. 14 00:00:45,120 --> 00:00:48,820 But notice that both of those containers have a virtual network 15 00:00:48,820 --> 00:00:52,460 interface that interacts with the Hyper‑V virtual switch, 16 00:00:52,460 --> 00:00:56,460 and then, ultimately, especially if you're using the external switch type, 17 00:00:56,460 --> 00:01:00,120 the hardware network interface card on the Hyper‑V host. 18 00:01:00,120 --> 00:01:02,260 So the good news is for our AZ‑800, 19 00:01:02,260 --> 00:01:05,530 we don't have to get into the weeds with the complexities of 20 00:01:05,530 --> 00:01:07,850 Linux networking and Docker networking. 21 00:01:07,850 --> 00:01:09,340 We can look at it this way. 22 00:01:09,340 --> 00:01:16,230 The internal Hyper‑V vSwitch is directly mapped to the Docker NAT network mode, 23 00:01:16,230 --> 00:01:17,900 network address translation. 24 00:01:17,900 --> 00:01:19,660 The external vSwitch, 25 00:01:19,660 --> 00:01:23,390 which in my experience is by far the most popular type of switch 26 00:01:23,390 --> 00:01:27,450 because its surface is your Hyper‑V VMs to your network, 27 00:01:27,450 --> 00:01:31,230 this is mapped to the Docker transparent network mode. 28 00:01:31,230 --> 00:01:35,560 So just think of that in your mind, NAT mode to internal vSwitch, 29 00:01:35,560 --> 00:01:38,840 transparent mode to external vSwitch. 30 00:01:38,840 --> 00:01:41,940 Lastly, let's manage container instances. 31 00:01:41,940 --> 00:01:44,810 I'd mentioned that there's going to be, or likely to be, 32 00:01:44,810 --> 00:01:48,140 some Docker command line interface syntax on your exam, 33 00:01:48,140 --> 00:01:49,510 so don't be surprised. 34 00:01:49,510 --> 00:01:49,910 I mean, 35 00:01:49,910 --> 00:01:53,350 it is surprising in the sense that these certification exams 36 00:01:53,350 --> 00:01:55,480 are vendor specific and they're Microsoft, 37 00:01:55,480 --> 00:01:57,600 not Docker certifications. 38 00:01:57,600 --> 00:01:58,390 On the other hand, 39 00:01:58,390 --> 00:02:02,540 it should not be surprising that we'll see some Docker on our exams because 40 00:02:02,540 --> 00:02:05,920 Microsoft and Docker have formed such a deep relationship. 41 00:02:05,920 --> 00:02:10,420 So here I just have some sample Docker CLI code just to give you some feel. 42 00:02:10,420 --> 00:02:14,190 You've seen, we've come out of a demo, so this is basically just review. 43 00:02:14,190 --> 00:02:15,580 Let's go over it again. 44 00:02:15,580 --> 00:02:17,930 So to build an image from a Dockerfile, 45 00:02:17,930 --> 00:02:22,260 docker build, and then t is to tag the image with, 46 00:02:22,260 --> 00:02:25,310 normally you'll give the image a descriptive label, 47 00:02:25,310 --> 00:02:27,310 colon, and then a version number. 48 00:02:27,310 --> 00:02:32,570 We can do docker image ls to list images on our host. To delete an image, 49 00:02:32,570 --> 00:02:33,860 docker image rm. 50 00:02:33,860 --> 00:02:39,090 To run a Windows container image, this is really the exam alert for your exam, 51 00:02:39,090 --> 00:02:44,290 the fact that you can access those isolation modes when you start the container. 52 00:02:44,290 --> 00:02:46,020 So when you do docker run, 53 00:02:46,020 --> 00:02:51,420 you'll do isolation=hyperv if you want a Hyper‑V Windows Server container, 54 00:02:51,420 --> 00:02:55,710 isolation=process if you want to run the Windows Server container in a 55 00:02:55,710 --> 00:02:59,310 lower security or just a standard Docker container way. 56 00:02:59,310 --> 00:03:03,090 And just to review, docker run means to start the container. 57 00:03:03,090 --> 00:03:06,480 It means to bind to a terminal session, 58 00:03:06,480 --> 00:03:10,840 so instead of starting the container detached with ‑d, 59 00:03:10,840 --> 00:03:14,330 ‑it will put you at the command prompt into the container. 60 00:03:14,330 --> 00:03:17,240 And then lastly, after the image name and label, 61 00:03:17,240 --> 00:03:21,170 that's going to be your entry point if it's not already defined in the image. 62 00:03:21,170 --> 00:03:25,800 Here, these docker run commands will put you in a cmd​.exe session. 63 00:03:25,800 --> 00:03:28,800 To manage containers, docker container stop. 64 00:03:28,800 --> 00:03:31,040 There's a number of different ways to do that. 65 00:03:31,040 --> 00:03:35,140 So what I want you to see from the Docker CLI high‑level view is 66 00:03:35,140 --> 00:03:38,790 that Docker CLI behaves quite a bit like the Azure CLI where 67 00:03:38,790 --> 00:03:43,090 you've got the keyword, instead of az for Azure CLI it's Docker, 68 00:03:43,090 --> 00:03:46,880 then you've got your context, build, image, 69 00:03:46,880 --> 00:03:51,540 container, etc, and then you have your command and parameters. 70 00:03:51,540 --> 00:03:53,760 So it's a consistent syntax really. 71 00:03:53,760 --> 00:04:01,000 And I believe that the Azure CLI was definitely designed with the Docker CLI in mind.