1 00:00:00,000 --> 00:00:05,042 >> [MUSIC PLAYING] 2 00:00:05,042 --> 00:00:06,000 DAVID MALAN: All right. 3 00:00:06,000 --> 00:00:07,630 Thank you so much for coming. 4 00:00:07,630 --> 00:00:11,850 This is CS50 seminar on Docker, a technology that we ourselves and CS50 5 00:00:11,850 --> 00:00:13,392 have started using for some time now. 6 00:00:13,392 --> 00:00:15,766 So my name is David Malan, I teach Harvard's Introduction 7 00:00:15,766 --> 00:00:16,671 to Computer Science. 8 00:00:16,671 --> 00:00:18,670 For quite some years, we've been giving students 9 00:00:18,670 --> 00:00:20,435 downloadable client-side virtual machines 10 00:00:20,435 --> 00:00:22,134 on which they do their problems sets. 11 00:00:22,134 --> 00:00:24,300 That we have now transitioned to a Cloud environment 12 00:00:24,300 --> 00:00:27,396 that actually uses this technology called Docker, such that all the CS50 13 00:00:27,396 --> 00:00:29,270 students now have their own Docker containers 14 00:00:29,270 --> 00:00:31,180 that you'll soon hear all about. 15 00:00:31,180 --> 00:00:33,740 >> Moreover, on CS50's server side cluster, for many years 16 00:00:33,740 --> 00:00:35,290 we were using Amazon's Cloud server. 17 00:00:35,290 --> 00:00:37,164 We were running individual virtual machines. 18 00:00:37,164 --> 00:00:40,330 That too, we've begun to transition to these things called Docker containers 19 00:00:40,330 --> 00:00:43,762 so that all of our applications are now perfectly isolated from one another. 20 00:00:43,762 --> 00:00:46,720 So for that and more, allow me to introduce our friends, Nico and Mano, 21 00:00:46,720 --> 00:00:48,574 from Docker itself. 22 00:00:48,574 --> 00:00:49,740 NICOLA KABAR: Thanks, David. 23 00:00:49,740 --> 00:00:51,410 Hello, everyone. 24 00:00:51,410 --> 00:00:54,230 My name is Nico and this is Mano. 25 00:00:54,230 --> 00:00:58,260 We're from Docker. 26 00:00:58,260 --> 00:01:02,240 We're going to be talking about-- giving you guys an intro to Docker, 27 00:01:02,240 --> 00:01:08,100 and hopefully, towards the end of this talk you can realize 28 00:01:08,100 --> 00:01:12,890 how much you can use doctor to oxalate your application development 29 00:01:12,890 --> 00:01:14,200 and deployment. 30 00:01:14,200 --> 00:01:21,250 >> So, we're going to start off real quick with some background information. 31 00:01:21,250 --> 00:01:22,750 Describe what Docker is all about. 32 00:01:22,750 --> 00:01:25,490 How does it work? 33 00:01:25,490 --> 00:01:27,400 How is it architected? 34 00:01:27,400 --> 00:01:29,360 I'll be doing some demos. 35 00:01:29,360 --> 00:01:35,070 And Mano is going to be describing how can you use Docker 36 00:01:35,070 --> 00:01:37,720 and giving you specific steps how you can get started. 37 00:01:37,720 --> 00:01:41,490 >> I would appreciate if you guys can hold off for your questions towards the end. 38 00:01:41,490 --> 00:01:46,800 That way, I might be addressing those questions throughout the presentation. 39 00:01:46,800 --> 00:01:52,150 So we'll leave some time towards the end for questions. 40 00:01:52,150 --> 00:01:55,170 >> So just real quick, who has actually ever worked on Docker, 41 00:01:55,170 --> 00:01:56,850 like played with it? 42 00:01:56,850 --> 00:01:58,000 Awesome. 43 00:01:58,000 --> 00:01:58,520 Cool. 44 00:01:58,520 --> 00:01:59,817 Great. 45 00:01:59,817 --> 00:02:01,525 So, I'm going to start with some history. 46 00:02:01,525 --> 00:02:04,350 47 00:02:04,350 --> 00:02:09,820 So back in the '90s and early 2000s, basically 48 00:02:09,820 --> 00:02:16,940 as web developers, app developers, when they went to deploy an application 49 00:02:16,940 --> 00:02:19,350 it was tied to bare metal. 50 00:02:19,350 --> 00:02:20,860 It was one server. 51 00:02:20,860 --> 00:02:22,870 It was one application. 52 00:02:22,870 --> 00:02:25,260 >> Traditionally, an example would be like a LAMP stack, 53 00:02:25,260 --> 00:02:30,630 where you actually had to bring up the pool of resources. 54 00:02:30,630 --> 00:02:37,110 CPU, memory, disk, network, installing operating system on top of that. 55 00:02:37,110 --> 00:02:40,060 If you're serving something, if you're actually having web server, 56 00:02:40,060 --> 00:02:42,470 you need something like Apache to serve it. 57 00:02:42,470 --> 00:02:47,540 >> If your application needs database, backhand, 58 00:02:47,540 --> 00:02:50,840 you would install something like MySQL, and so on. 59 00:02:50,840 --> 00:02:55,910 And if you need the run time, PHPs and PHP Python work were there. 60 00:02:55,910 --> 00:02:59,480 And so we actually had to take those steps in order 61 00:02:59,480 --> 00:03:02,060 to get your application up and running. 62 00:03:02,060 --> 00:03:08,440 >> If you needed more compute power, you basically had to call your Ops guy 63 00:03:08,440 --> 00:03:16,260 or gal to go and rack up a new piece of hardware, connect it, 64 00:03:16,260 --> 00:03:19,850 and you have to repeat those processes again and again. 65 00:03:19,850 --> 00:03:23,680 So this process was relatively expensive. 66 00:03:23,680 --> 00:03:26,080 Was definitely very slow. 67 00:03:26,080 --> 00:03:27,550 >> It was inefficient. 68 00:03:27,550 --> 00:03:33,890 And in a lot of cases, your hardware was underutilized. 69 00:03:33,890 --> 00:03:38,830 So, in the late '90s and early 2000s, hardware virtualization came across. 70 00:03:38,830 --> 00:03:42,475 And as you can see here in the picture, basically what they did 71 00:03:42,475 --> 00:03:46,390 is abstracted the pool of free hardware resources 72 00:03:46,390 --> 00:03:49,680 and kind of served those to the upper layers, 73 00:03:49,680 --> 00:03:52,360 in this case, a guest operating system. 74 00:03:52,360 --> 00:03:54,940 >> And the whole idea of virtual machines came across 75 00:03:54,940 --> 00:03:59,110 and that truly helped Cloud computing as we know it today. 76 00:03:59,110 --> 00:04:02,730 So what that meant is you can run multiple VMs, which 77 00:04:02,730 --> 00:04:06,720 meant multiple stacks, multiple application on a same physical machine. 78 00:04:06,720 --> 00:04:10,570 79 00:04:10,570 --> 00:04:16,440 >> This definitely helped with the speed of application deployment. 80 00:04:16,440 --> 00:04:17,629 Definitely with expenses. 81 00:04:17,629 --> 00:04:22,810 You don't have to go and spend energy, time, and resources to rack 82 00:04:22,810 --> 00:04:26,210 more servers to get to more compute. 83 00:04:26,210 --> 00:04:30,950 And the speed of actually bringing those resources up is much faster. 84 00:04:30,950 --> 00:04:31,450 Great. 85 00:04:31,450 --> 00:04:34,320 >> So we solved world hunger, right? 86 00:04:34,320 --> 00:04:36,390 No, not really. 87 00:04:36,390 --> 00:04:42,410 So, virtualization as much as it's actually helped, address the problem, 88 00:04:42,410 --> 00:04:45,460 it actually introduced a lot of challenges. 89 00:04:45,460 --> 00:04:49,210 The hypervisor definitely introduced a lot of complexity, 90 00:04:49,210 --> 00:04:53,820 handling those underlying pool of resources. 91 00:04:53,820 --> 00:04:57,910 >> It's heavier in the sense that before you had a single operating system which 92 00:04:57,910 --> 00:05:01,830 is like three, four gigs on disk. 93 00:05:01,830 --> 00:05:04,230 Now, if you have 10 machines on a single hardware 94 00:05:04,230 --> 00:05:09,060 you have to multiply that by the number of machines. 95 00:05:09,060 --> 00:05:11,440 It's definitely more expensive in a sense you still 96 00:05:11,440 --> 00:05:14,430 have to get licensing for the virtualization technology 97 00:05:14,430 --> 00:05:18,210 if it's not open source. 98 00:05:18,210 --> 00:05:21,120 >> But, let's not take all the credit from virtualization. 99 00:05:21,120 --> 00:05:27,530 Because what happened is there's a lot of stacks and lots of software 100 00:05:27,530 --> 00:05:33,900 technologies that were enabled by how fast you were able to get 101 00:05:33,900 --> 00:05:38,040 to resources with the Cloud boom. 102 00:05:38,040 --> 00:05:46,675 >> So, today a single app or service can be using any of the following runtimes 103 00:05:46,675 --> 00:05:47,216 or databases. 104 00:05:47,216 --> 00:05:50,250 105 00:05:50,250 --> 00:05:56,070 PHP, Python, MySQL, Redis, whatnot. 106 00:05:56,070 --> 00:05:59,740 So there's a lot of complexity on this number of stacks to actually bring up 107 00:05:59,740 --> 00:06:02,210 a single service. 108 00:06:02,210 --> 00:06:07,300 And along with that, you had a lot of underlying resources or infrastructure 109 00:06:07,300 --> 00:06:15,210 types to test deploy and basically take to production those applications 110 00:06:15,210 --> 00:06:16,900 that you're developing. 111 00:06:16,900 --> 00:06:21,950 >> Especially as your teams have grown working on those apps, 112 00:06:21,950 --> 00:06:25,310 there's a lot of complexity and challenges 113 00:06:25,310 --> 00:06:31,660 that were brought to ensure that the cycle-- basically application 114 00:06:31,660 --> 00:06:34,040 development cycle, is actually successful. 115 00:06:34,040 --> 00:06:40,440 So, the fact that your application is working locally on your local VM 116 00:06:40,440 --> 00:06:47,480 does not guarantee that your colleague is going to expect the same results. 117 00:06:47,480 --> 00:06:51,330 >> And when the operations team is involved in taking what you have 118 00:06:51,330 --> 00:06:54,480 and deploying it in production scale, also there's no guarantee 119 00:06:54,480 --> 00:06:56,730 that that's actually going to happen. 120 00:06:56,730 --> 00:07:00,900 So this leaves us with a really big-- a lot of question marks, 121 00:07:00,900 --> 00:07:07,700 a lot of challenges actually faced similarly back in the days. 122 00:07:07,700 --> 00:07:12,280 And that reminded us of the shipping industry. 123 00:07:12,280 --> 00:07:14,280 >> So the shipping industry had a lot of goods, 124 00:07:14,280 --> 00:07:16,190 as you can see on the left hand side. 125 00:07:16,190 --> 00:07:19,840 And on the right hand side, there's a lot of, basically, 126 00:07:19,840 --> 00:07:22,160 ways to ship those goods. 127 00:07:22,160 --> 00:07:26,040 And what happens as a couple folks came together and said, 128 00:07:26,040 --> 00:07:29,600 we need to standardize how we actually ship those goods. 129 00:07:29,600 --> 00:07:33,280 And boom, you have the intermodal shipping container. 130 00:07:33,280 --> 00:07:38,970 >> So they agreed on the most common sizes for the container. 131 00:07:38,970 --> 00:07:40,160 How to handle them. 132 00:07:40,160 --> 00:07:44,560 What exact method you need to load them and unload them. 133 00:07:44,560 --> 00:07:49,590 And therefore, that truly helped the shipping industry. 134 00:07:49,590 --> 00:07:55,250 Now more than 90% focus transported globally are using those containers. 135 00:07:55,250 --> 00:08:01,010 And that definitely decreases the expenses as well as 136 00:08:01,010 --> 00:08:03,400 the damages due to shipping. 137 00:08:03,400 --> 00:08:09,660 >> So we take the same model and we apply the two app development software 138 00:08:09,660 --> 00:08:13,080 architecture, in the sense that containerization 139 00:08:13,080 --> 00:08:15,842 took the virtualization up one level. 140 00:08:15,842 --> 00:08:17,800 So instead of doing that at the hardware level, 141 00:08:17,800 --> 00:08:22,060 it became more of an operating system level virtualization. 142 00:08:22,060 --> 00:08:26,450 >> And we do that by providing each application in its own lightweight, 143 00:08:26,450 --> 00:08:31,180 isolated, runnable, and portable, most importantly, 144 00:08:31,180 --> 00:08:35,049 a way to actually package everything that it needs to run. 145 00:08:35,049 --> 00:08:36,100 Anywhere it can be run. 146 00:08:36,100 --> 00:08:42,039 So, regardless if you're running it on local dev environment, your production 147 00:08:42,039 --> 00:08:44,490 environment, your staging or testing. 148 00:08:44,490 --> 00:08:47,700 No matter what underlying infrastructure is there, 149 00:08:47,700 --> 00:08:51,410 you had a functional working app. 150 00:08:51,410 --> 00:08:54,100 151 00:08:54,100 --> 00:09:01,800 >> So that's exactly what basically containers do to this problem. 152 00:09:01,800 --> 00:09:04,070 They address it by packaging it in such way 153 00:09:04,070 --> 00:09:09,490 that it can guarantee that it's deployed successfully no matter where it lives. 154 00:09:09,490 --> 00:09:12,120 So if you're going like, Bob it's still OK. 155 00:09:12,120 --> 00:09:17,860 If you're confused with what I'm saying, I'm going to be elaborating on that. 156 00:09:17,860 --> 00:09:20,900 >> So how does Docker itself fit in this picture? 157 00:09:20,900 --> 00:09:26,335 So Docker is an open platform to easily, emphasize easily, 158 00:09:26,335 --> 00:09:30,500 to build ship, run, lightweight portable self 159 00:09:30,500 --> 00:09:33,440 sufficient app containers anywhere. 160 00:09:33,440 --> 00:09:37,660 So if you take something from this talk, please take the following. 161 00:09:37,660 --> 00:09:40,980 >> If you have your app running locally and you developed it 162 00:09:40,980 --> 00:09:45,930 in using the Docker platform, expect it to be successfully deployed. 163 00:09:45,930 --> 00:09:49,380 No matter what is the underlying infrastructure. 164 00:09:49,380 --> 00:09:53,830 So if you have a Docker container and it's working, then 165 00:09:53,830 --> 00:09:58,130 as long as there's a Docker engine on the other side-- 166 00:09:58,130 --> 00:10:02,190 if your operation infrastructure is using any Cloud, whether it 167 00:10:02,190 --> 00:10:06,680 is AWS, or Google's, or Microsoft, or any of the public Clouds, 168 00:10:06,680 --> 00:10:10,010 or your own Cloud, or your open stack Cloud, or your local environment. 169 00:10:10,010 --> 00:10:11,970 >> If you have an engine running, that means 170 00:10:11,970 --> 00:10:14,537 it's going to be successfully deployed there. 171 00:10:14,537 --> 00:10:16,620 It's going to be running exactly the same behavior 172 00:10:16,620 --> 00:10:21,480 as you architected it to be. 173 00:10:21,480 --> 00:10:26,080 So if we look at-- I'm going to go through what actually 174 00:10:26,080 --> 00:10:29,160 are in the main components of Docker. 175 00:10:29,160 --> 00:10:31,060 >> So Engine is at the core of Docker. 176 00:10:31,060 --> 00:10:32,770 It is the brain's. 177 00:10:32,770 --> 00:10:39,360 It orchestrates building, shipping, and deploying and managing 178 00:10:39,360 --> 00:10:41,570 the containers themselves. 179 00:10:41,570 --> 00:10:45,160 I'll dig into what Engine does in more details in a second. 180 00:10:45,160 --> 00:10:47,740 181 00:10:47,740 --> 00:10:51,720 Basically, because Doctor was built around the client server architectures, 182 00:10:51,720 --> 00:10:56,630 so in order to interact with the Engine you need some sort of a client. 183 00:10:56,630 --> 00:11:01,200 >> Images are the templates in which containers are built from. 184 00:11:01,200 --> 00:11:06,800 So images are basically just static files. 185 00:11:06,800 --> 00:11:08,740 Templates and containers is actually what's 186 00:11:08,740 --> 00:11:12,280 is running at runtime that is serving your application 187 00:11:12,280 --> 00:11:15,150 or doing something with the data. 188 00:11:15,150 --> 00:11:19,020 >> Registry is addressed as a problem of how you actually distribute images. 189 00:11:19,020 --> 00:11:23,230 So if you need to share an image that you worked on to your colleague 190 00:11:23,230 --> 00:11:27,220 or to the ops team, you use it using Registry. 191 00:11:27,220 --> 00:11:31,720 You can download an open source version of it that Docker worked on 192 00:11:31,720 --> 00:11:33,150 and open sourced. 193 00:11:33,150 --> 00:11:38,040 >> Or you can use Docker help, which is the Cloud version 194 00:11:38,040 --> 00:11:40,130 to push and pull images out there. 195 00:11:40,130 --> 00:11:41,160 That's a huge thing. 196 00:11:41,160 --> 00:11:44,520 Because there's a huge ecosystem around Docker and it's 197 00:11:44,520 --> 00:11:48,960 really heavily utilizing the hub. 198 00:11:48,960 --> 00:11:59,780 >> So to summarize here, this is how the minimalist Docker workflow client. 199 00:11:59,780 --> 00:12:04,040 You interact with the host, in this case it's the Docker daemons. 200 00:12:04,040 --> 00:12:06,490 It's the same thing as Engine. 201 00:12:06,490 --> 00:12:09,690 You do commands like Docker build, pull, run. 202 00:12:09,690 --> 00:12:14,280 And the Engine itself goes and does those things. 203 00:12:14,280 --> 00:12:18,010 >> So either it interacts with Registry to pull those images 204 00:12:18,010 --> 00:12:19,670 and the layers of the images. 205 00:12:19,670 --> 00:12:25,030 Whether if you want to deploy, run containers, kill them, throw them down, 206 00:12:25,030 --> 00:12:25,730 whatnot. 207 00:12:25,730 --> 00:12:32,190 So this summarizes the workflow of all of these components. 208 00:12:32,190 --> 00:12:34,710 >> So if you take every component by itself. 209 00:12:34,710 --> 00:12:37,690 So Engine, it's just a daemon. 210 00:12:37,690 --> 00:12:40,800 It'll kind of play it to support it on Linux because it does 211 00:12:40,800 --> 00:12:44,380 require certain Linux kernel features. 212 00:12:44,380 --> 00:12:48,820 But Windows is working on doing the same thing. 213 00:12:48,820 --> 00:12:53,720 It's supposed to be supported by Windows Server 2016. 214 00:12:53,720 --> 00:13:01,500 >> So, again, the responsibilities with the engine is to, or are to, build images. 215 00:13:01,500 --> 00:13:05,340 Pull images from the Docker Hub or your own Registry. 216 00:13:05,340 --> 00:13:07,840 If you're done with those images or you create a new images, 217 00:13:07,840 --> 00:13:14,770 you can push those back to registry to distribute them to other teams. 218 00:13:14,770 --> 00:13:18,300 >> And trying to contain it locally and manage the containers life cycle 219 00:13:18,300 --> 00:13:19,260 locally. 220 00:13:19,260 --> 00:13:22,010 It is built around HTTP REST API. 221 00:13:22,010 --> 00:13:24,480 So technically you can write your own client 222 00:13:24,480 --> 00:13:31,650 as long as it uses HTTP, which is a very standard mechanism to talk to Engine 223 00:13:31,650 --> 00:13:33,110 and a lot of other services. 224 00:13:33,110 --> 00:13:35,780 And you can see from here that regardless 225 00:13:35,780 --> 00:13:39,010 of what the infrastructure is, as long as you can-- all 226 00:13:39,010 --> 00:13:42,170 you need is an operating system, Linux specifically. 227 00:13:42,170 --> 00:13:45,460 >> And you can install Docker Engine on top of that and have it running 228 00:13:45,460 --> 00:13:48,970 and it orchestrates, basically, all these app one, two, 229 00:13:48,970 --> 00:13:51,530 and three are actual containers. 230 00:13:51,530 --> 00:13:53,990 So that's Engine. 231 00:13:53,990 --> 00:13:58,040 As I mentioned earlier because you need to interact with Engine, 232 00:13:58,040 --> 00:13:59,200 there's the client. 233 00:13:59,200 --> 00:14:03,180 >> But actually when you install Docker, it ships with it. 234 00:14:03,180 --> 00:14:06,110 So it gets installed, so it's a single binary. 235 00:14:06,110 --> 00:14:11,830 And you can do local calls to your Docker Engine. 236 00:14:11,830 --> 00:14:14,040 Or remote calls to remote Engines. 237 00:14:14,040 --> 00:14:16,600 238 00:14:16,600 --> 00:14:19,590 It does use HTTP, as I mentioned earlier. 239 00:14:19,590 --> 00:14:24,200 There's a GUI client called Kitematic from Docker. 240 00:14:24,200 --> 00:14:26,390 And there are definitely a lot of other folks 241 00:14:26,390 --> 00:14:29,740 who are building a lot of GUIs that basically implement 242 00:14:29,740 --> 00:14:32,980 some HTTP calls to talk to Engine. 243 00:14:32,980 --> 00:14:35,920 244 00:14:35,920 --> 00:14:39,280 >> Just some sample commands. 245 00:14:39,280 --> 00:14:44,620 If you do Docker version, it would show you the client version as well as 246 00:14:44,620 --> 00:14:47,030 the server version. 247 00:14:47,030 --> 00:14:49,500 If you do Docker info it will tell you all the information 248 00:14:49,500 --> 00:14:54,300 about how many containers are running or created, how many images you have, 249 00:14:54,300 --> 00:14:56,530 and so on and so on. 250 00:14:56,530 --> 00:15:01,850 >> Here I have, in the next to last box, I have Doctor run. 251 00:15:01,850 --> 00:15:04,970 So that's how I'm actually creating container. 252 00:15:04,970 --> 00:15:08,960 And I'm giving it to echo Hello World and sleep for a second and whatnot. 253 00:15:08,960 --> 00:15:12,830 And you can see the result. So it's ongoing. 254 00:15:12,830 --> 00:15:16,930 And similar to Linux ps, you can see all the processes and, in this case, 255 00:15:16,930 --> 00:15:18,540 all the running containers. 256 00:15:18,540 --> 00:15:23,430 This one's referring back to the container I just created. 257 00:15:23,430 --> 00:15:27,560 >> So, this is really important because, like, it can be a bit confusing. 258 00:15:27,560 --> 00:15:33,050 So images are the read-only collection of files, right? 259 00:15:33,050 --> 00:15:37,000 They are what our container is based on. 260 00:15:37,000 --> 00:15:40,340 But they're only read-only. 261 00:15:40,340 --> 00:15:44,330 So you start off with a base image. 262 00:15:44,330 --> 00:15:50,180 It tends to mimic OS-like, so Ubuntu, CentOS, whatnot base image. 263 00:15:50,180 --> 00:15:53,990 And then you start building on top of that, certain layers, that will make up 264 00:15:53,990 --> 00:16:00,010 your end image, the end result here. 265 00:16:00,010 --> 00:16:03,220 >> And each of those layers should have a parent image 266 00:16:03,220 --> 00:16:06,690 that it references when it actually wants to create. 267 00:16:06,690 --> 00:16:09,922 They are immutable, in the sense that because they're read-only, 268 00:16:09,922 --> 00:16:11,630 you cannot actually make changes to them. 269 00:16:11,630 --> 00:16:17,540 You can use them to create a container from an image, which 270 00:16:17,540 --> 00:16:23,530 will call all the subsequent required images underneath it. 271 00:16:23,530 --> 00:16:26,400 >> You can make changes to a different layer, 272 00:16:26,400 --> 00:16:28,810 it's a rewrite layer I'll talk about in a second. 273 00:16:28,810 --> 00:16:31,350 But each of those layers are never changed. 274 00:16:31,350 --> 00:16:34,300 275 00:16:34,300 --> 00:16:38,670 Basically images use something called Union File System, UFS. 276 00:16:38,670 --> 00:16:42,280 And there are different storage backends that utilize this technology. 277 00:16:42,280 --> 00:16:49,430 And what that means is that it brings together distinct file systems 278 00:16:49,430 --> 00:16:51,190 to make them look like one. 279 00:16:51,190 --> 00:16:54,460 >> So you can actually, from an application perspective, 280 00:16:54,460 --> 00:16:59,570 you have a top of a view that shows all the different file system needed 281 00:16:59,570 --> 00:17:01,120 for that application to run. 282 00:17:01,120 --> 00:17:04,400 But they're actually, on this, they're actually in separate places 283 00:17:04,400 --> 00:17:06,410 and being utilized by other containers as well. 284 00:17:06,410 --> 00:17:09,569 285 00:17:09,569 --> 00:17:14,410 >> So as you can see in here that if we start with daemon image 286 00:17:14,410 --> 00:17:18,619 as a base image, and then we go in and add [? emacs ?] 287 00:17:18,619 --> 00:17:20,720 and then that's another layer. 288 00:17:20,720 --> 00:17:21,916 And then add Apache. 289 00:17:21,916 --> 00:17:22,790 That's another layer. 290 00:17:22,790 --> 00:17:25,470 And then we spend the container from that. 291 00:17:25,470 --> 00:17:29,760 Each of those images, each of those layers, 292 00:17:29,760 --> 00:17:35,530 is distinct and can be reused by other containers. 293 00:17:35,530 --> 00:17:40,070 >> If you look at containers themselves, they're somehow like VM-like, 294 00:17:40,070 --> 00:17:41,930 but not treated the same time. 295 00:17:41,930 --> 00:17:49,180 So, they do not have, technically, the full operating system underneath them. 296 00:17:49,180 --> 00:17:52,630 They use the single kernel of the host operating system. 297 00:17:52,630 --> 00:17:54,440 And they build on top of that. 298 00:17:54,440 --> 00:17:56,250 They mimic in how they look. 299 00:17:56,250 --> 00:18:00,710 They mimic their root file system of the operating system. 300 00:18:00,710 --> 00:18:04,930 But they actually are not replicating. 301 00:18:04,930 --> 00:18:12,080 >> So, instead of having immutable layers, the last layer, which is the container 302 00:18:12,080 --> 00:18:14,690 itself, it's a read-write layer. 303 00:18:14,690 --> 00:18:17,350 That also runs the processes of your application. 304 00:18:17,350 --> 00:18:23,530 And it depends on the underlying layers. 305 00:18:23,530 --> 00:18:26,730 Every container is created from an image. 306 00:18:26,730 --> 00:18:32,450 And that image can be a single layer or multilayer image. 307 00:18:32,450 --> 00:18:37,200 >> And I want to note here that Docker heavily uses, 308 00:18:37,200 --> 00:18:40,370 or is based on Copy-On-Write mechanism. 309 00:18:40,370 --> 00:18:44,350 So that, actually, if you are not making changes to the container, 310 00:18:44,350 --> 00:18:45,930 it's not going to take extra space. 311 00:18:45,930 --> 00:18:49,600 So that's basically how you summarize a Copy-On-Write. 312 00:18:49,600 --> 00:18:53,820 It's going to definitely speed up the boot time for the container. 313 00:18:53,820 --> 00:18:56,300 Because if you're not making changes to the container, 314 00:18:56,300 --> 00:18:57,800 it's utilizing what's already there. 315 00:18:57,800 --> 00:19:01,130 316 00:19:01,130 --> 00:19:02,955 >> So, how it actually works. 317 00:19:02,955 --> 00:19:06,920 318 00:19:06,920 --> 00:19:14,240 Part of it's like, right now, it utilizes at least two key kernel 319 00:19:14,240 --> 00:19:14,820 features. 320 00:19:14,820 --> 00:19:17,660 And that is basically what created that level of isolation 321 00:19:17,660 --> 00:19:19,550 for the containers themselves. 322 00:19:19,550 --> 00:19:22,290 Those features are namespaces and cgroups. 323 00:19:22,290 --> 00:19:29,870 So namespaces are a way to create isolated resources, 324 00:19:29,870 --> 00:19:36,290 so that within the container itself, only you can see certain resources. 325 00:19:36,290 --> 00:19:40,030 Such as the networking interface or the certain users or whatnot. 326 00:19:40,030 --> 00:19:44,160 >> And those are only visible and only accessible within the container. 327 00:19:44,160 --> 00:19:48,290 Cgroup on the other side limits how you use those resources. 328 00:19:48,290 --> 00:19:50,950 CPU, memory, and disk. 329 00:19:50,950 --> 00:19:53,900 When you can go in, I mean those are actually 330 00:19:53,900 --> 00:19:57,410 features that were developed by-- they're part of the Linux kernel. 331 00:19:57,410 --> 00:20:01,800 So they were not reinvented by or recreated by Docker. 332 00:20:01,800 --> 00:20:03,770 Docker uses them. 333 00:20:03,770 --> 00:20:05,560 >> What Doctor really did here is actually it 334 00:20:05,560 --> 00:20:08,680 orchestrated creating namespaces for each container 335 00:20:08,680 --> 00:20:13,320 and creating the cgroups so that it's ridiculously easy to create containers 336 00:20:13,320 --> 00:20:14,870 using those features. 337 00:20:14,870 --> 00:20:22,910 Of course, as I described earlier, Union File Systems and Copy-On-Write truly 338 00:20:22,910 --> 00:20:26,810 help the speed and the disk utilization of containers. 339 00:20:26,810 --> 00:20:28,917 >> And once you get your hands around Docker, 340 00:20:28,917 --> 00:20:32,000 you're going to see how fast it is to actually spin up containers and tear 341 00:20:32,000 --> 00:20:32,500 them down. 342 00:20:32,500 --> 00:20:36,060 343 00:20:36,060 --> 00:20:40,230 So, if you might ask, how can you actually build images? 344 00:20:40,230 --> 00:20:45,940 We build images by a process of creating containers and making changes, altering 345 00:20:45,940 --> 00:20:50,220 them, and committing them into becoming an image. 346 00:20:50,220 --> 00:20:54,330 >> So it's a chicken and egg reference here, 347 00:20:54,330 --> 00:20:57,350 because all containers come from images and images come 348 00:20:57,350 --> 00:21:00,270 from committed containers, for the most part. 349 00:21:00,270 --> 00:21:03,830 There are three options to create images. 350 00:21:03,830 --> 00:21:06,580 I'm going to describe the first and last. 351 00:21:06,580 --> 00:21:10,060 You can either manually go and run the container 352 00:21:10,060 --> 00:21:14,280 and make those changes, like you would do on any VM 353 00:21:14,280 --> 00:21:17,060 or any operating system, such as installing new binaries, 354 00:21:17,060 --> 00:21:19,370 adding file systems, and whatnot. 355 00:21:19,370 --> 00:21:22,620 >> And then you exit, as you can see up there. 356 00:21:22,620 --> 00:21:24,330 I am exiting my container. 357 00:21:24,330 --> 00:21:26,050 And then I'm doing Docker commit. 358 00:21:26,050 --> 00:21:28,390 And I'm committing that. 359 00:21:28,390 --> 00:21:31,560 You can see that the number here is just a UUID, or the first 12 360 00:21:31,560 --> 00:21:32,810 bits of the UUID. 361 00:21:32,810 --> 00:21:34,320 Or bytes of the UUID. 362 00:21:34,320 --> 00:21:35,770 And then I'm calling it my image. 363 00:21:35,770 --> 00:21:39,510 So now Docker takes care of recording everything I did it 364 00:21:39,510 --> 00:21:42,830 and creating the new image based on that. 365 00:21:42,830 --> 00:21:47,080 366 00:21:47,080 --> 00:21:52,560 >> I'm not going to talk about tarball, but there's a way you can get a single, 367 00:21:52,560 --> 00:21:58,200 create a single, or make a single layer image using tarballs. 368 00:21:58,200 --> 00:22:02,650 What I'm going to talk about this and what's mostly used today, 369 00:22:02,650 --> 00:22:03,270 is Dockerfile. 370 00:22:03,270 --> 00:22:07,260 Which is technically the first step automated by Docker itself. 371 00:22:07,260 --> 00:22:11,920 So Dockerfiles are things that you're going to see in a lot of GitHub repos 372 00:22:11,920 --> 00:22:13,150 today. 373 00:22:13,150 --> 00:22:16,420 It's basically just a text file describing 374 00:22:16,420 --> 00:22:19,780 exactly how to build an image. 375 00:22:19,780 --> 00:22:25,540 >> And for every line, it actually creates the container, executes that line, 376 00:22:25,540 --> 00:22:30,480 commits that container into a new image, and you, basically, 377 00:22:30,480 --> 00:22:36,160 use it for all subsequent operations until you get to the last image. 378 00:22:36,160 --> 00:22:39,260 Which is basically the end goal here, the end. 379 00:22:39,260 --> 00:22:42,420 And after you exec-- after you write your Dockerfile, which 380 00:22:42,420 --> 00:22:46,750 is purely in text, you do a Docker build and the name of the image. 381 00:22:46,750 --> 00:22:50,000 >> And you point at that that is where the Dockerfile is at. 382 00:22:50,000 --> 00:22:56,570 And you can expect to see my image as an image that you have locally. 383 00:22:56,570 --> 00:22:59,100 So that's just a visual example of what goes on. 384 00:22:59,100 --> 00:23:00,820 You start with a base image. 385 00:23:00,820 --> 00:23:05,150 You run that into a container that doesn't alter the base image itself. 386 00:23:05,150 --> 00:23:08,310 But instead creates a rewrite layer on top of it 387 00:23:08,310 --> 00:23:10,340 where you make the changes, in which you commit 388 00:23:10,340 --> 00:23:15,050 and you repeat the process until you get to your final image. 389 00:23:15,050 --> 00:23:20,980 >> And by doing so, every other build process can use the same layers 390 00:23:20,980 --> 00:23:23,870 and the same-- basically Docker caches those layers. 391 00:23:23,870 --> 00:23:30,040 So that if I'm doing the same exact process, but instead of installing PHP, 392 00:23:30,040 --> 00:23:31,540 I'm installing Python. 393 00:23:31,540 --> 00:23:34,210 It's going to use Apache and Ubuntu. 394 00:23:34,210 --> 00:23:39,570 So that way you're utilizing your disk. 395 00:23:39,570 --> 00:23:42,330 It's utilizing the cache and available images there. 396 00:23:42,330 --> 00:23:45,320 397 00:23:45,320 --> 00:23:48,840 >> The final piece is Registry, which is how you distribute your images. 398 00:23:48,840 --> 00:23:52,710 And, as I mentioned earlier, there's a Cloud version of it, 399 00:23:52,710 --> 00:23:54,290 which is Docker Hub. 400 00:23:54,290 --> 00:23:57,550 You can go and explore a lot of, basically 401 00:23:57,550 --> 00:24:04,900 it's a public SAS product that you can still have private images, 402 00:24:04,900 --> 00:24:06,590 but there's a lot of public images. 403 00:24:06,590 --> 00:24:10,580 It's actually unlimited, you can push unlimited public images there. 404 00:24:10,580 --> 00:24:13,730 And this is how you can collaborate with your team. 405 00:24:13,730 --> 00:24:17,159 >> You can just point them at you repo and they can download it or your image 406 00:24:17,159 --> 00:24:18,200 and they can download it. 407 00:24:18,200 --> 00:24:21,140 408 00:24:21,140 --> 00:24:24,990 So enough with the talk. 409 00:24:24,990 --> 00:24:29,110 Who wants to see some demos real quick? 410 00:24:29,110 --> 00:24:31,330 All right. 411 00:24:31,330 --> 00:24:34,050 So here I have. 412 00:24:34,050 --> 00:24:37,480 Ca you guys see my screen? 413 00:24:37,480 --> 00:24:38,390 All right. 414 00:24:38,390 --> 00:24:45,810 >> So I have Docker running here, so I can check it's-- This is the version 415 00:24:45,810 --> 00:24:47,510 of Docker that's running. 416 00:24:47,510 --> 00:24:49,320 Can do Docker info. 417 00:24:49,320 --> 00:24:55,730 Check all the information about how many images they have, and so on and so on. 418 00:24:55,730 --> 00:24:58,890 Docker PS, there's nothing running. 419 00:24:58,890 --> 00:25:00,570 Concatenated those. 420 00:25:00,570 --> 00:25:06,370 >> So the first thing I want to do is show you how you can easily run a container. 421 00:25:06,370 --> 00:25:09,350 So the beauty about Doctor run, if it actually 422 00:25:09,350 --> 00:25:14,700 does not find an image locally, by default it talks to Doctor Hub 423 00:25:14,700 --> 00:25:17,240 and tries to find it there and downloads it for you. 424 00:25:17,240 --> 00:25:22,820 So it includes a Docker pull command, naturally. 425 00:25:22,820 --> 00:25:26,130 >> So if I do a Docker run, hello-world. 426 00:25:26,130 --> 00:25:28,890 427 00:25:28,890 --> 00:25:31,200 So, first it's going to try to locate it. 428 00:25:31,200 --> 00:25:36,140 Otherwise, as you can see here, it could not find it locally. 429 00:25:36,140 --> 00:25:41,830 Right now it just pulled two layers that made that image and I ran it. 430 00:25:41,830 --> 00:25:45,440 The hello-world is just basically outputs, what you have done. 431 00:25:45,440 --> 00:25:47,680 So this is the easiest, one the easiest examples. 432 00:25:47,680 --> 00:25:53,840 So actually I just ran and terminated the container real quick. 433 00:25:53,840 --> 00:25:59,500 >> If I want to run-- and by the way, if I want to time that, just so you know, 434 00:25:59,500 --> 00:26:03,572 this is how long it takes to actually spin up and contain it. 435 00:26:03,572 --> 00:26:05,030 We're measuring it in milliseconds. 436 00:26:05,030 --> 00:26:10,600 So you can see how much this can actually help you not only in testing, 437 00:26:10,600 --> 00:26:13,200 but also even deployment. 438 00:26:13,200 --> 00:26:17,221 So that's a quick note on that. 439 00:26:17,221 --> 00:26:18,970 The next thing I'm going to do is actually 440 00:26:18,970 --> 00:26:21,930 run an image I've already prepared. 441 00:26:21,930 --> 00:26:24,460 So docker run. 442 00:26:24,460 --> 00:26:27,240 -d is just a flag to tell it to run in the background. 443 00:26:27,240 --> 00:26:30,290 And -p assigns certain ports. 444 00:26:30,290 --> 00:26:32,670 Because by default, the containers are isolated, 445 00:26:32,670 --> 00:26:36,080 so you have to specify exactly how it can access them. 446 00:26:36,080 --> 00:26:41,150 And in this case, I'm telling Docker to map a random port on the host 447 00:26:41,150 --> 00:26:44,560 to a specified port within the container itself. 448 00:26:44,560 --> 00:26:47,130 449 00:26:47,130 --> 00:26:56,460 And that's basically where the image-- hopefully this is the right one. 450 00:26:56,460 --> 00:27:01,780 >> So it does parallel downloads each of those layers as you can see here. 451 00:27:01,780 --> 00:27:06,949 Those are of the layers making the end image that I built. 452 00:27:06,949 --> 00:27:08,115 It's going to take a second. 453 00:27:08,115 --> 00:27:11,290 454 00:27:11,290 --> 00:27:12,370 And voila. 455 00:27:12,370 --> 00:27:16,590 >> So now if I do a docker ps, I should see something that is running. 456 00:27:16,590 --> 00:27:22,250 I should see the ID, the image that this it was based off, 457 00:27:22,250 --> 00:27:23,880 and the command that was executed. 458 00:27:23,880 --> 00:27:28,720 And how to access it is basically you go to that port. 459 00:27:28,720 --> 00:27:33,240 So I'm going to go to-- this is I'm running it on AWS. 460 00:27:33,240 --> 00:27:37,150 I'm going to go to 32769. 461 00:27:37,150 --> 00:27:37,650 Oops. 462 00:27:37,650 --> 00:27:40,495 463 00:27:40,495 --> 00:27:41,120 And here we go. 464 00:27:41,120 --> 00:27:44,550 >> So this is actually just a web service that shows 465 00:27:44,550 --> 00:27:46,240 which container it's being served from. 466 00:27:46,240 --> 00:27:50,450 So you can see that it is from container a9f. 467 00:27:50,450 --> 00:27:52,850 And here this is the name of the container. 468 00:27:52,850 --> 00:27:56,550 So you guys can see how quickly it was to actually not only pull but also 469 00:27:56,550 --> 00:28:00,440 deploy this container. 470 00:28:00,440 --> 00:28:05,070 >> Now the next step is to look into Dockerfiles 471 00:28:05,070 --> 00:28:09,430 and how we can actually build new images. 472 00:28:09,430 --> 00:28:15,250 I'm just going to go get clone, a sample Dockerfile based on the earlier 473 00:28:15,250 --> 00:28:17,755 diagram, the one to Apache and PHP. 474 00:28:17,755 --> 00:28:26,740 475 00:28:26,740 --> 00:28:28,140 Hopefully I remember my repo. 476 00:28:28,140 --> 00:28:36,410 477 00:28:36,410 --> 00:28:38,750 >> So I have my repository right now. 478 00:28:38,750 --> 00:28:43,080 And you're going to see this a lot actually. 479 00:28:43,080 --> 00:28:45,110 I did not install tree. 480 00:28:45,110 --> 00:28:48,700 >> So basically you're going to see how your source code documentation around 481 00:28:48,700 --> 00:28:51,240 it, and then a Dockerfile on how to actually package it. 482 00:28:51,240 --> 00:28:57,970 So it's just a sample PHP that echoes hello CS50. 483 00:28:57,970 --> 00:29:01,550 >> So if I want to run it, I'll do docker build. 484 00:29:01,550 --> 00:29:03,370 I have to build it first. 485 00:29:03,370 --> 00:29:12,420 I'm going to name it demo_cs50. 486 00:29:12,420 --> 00:29:16,470 And you need a tag to it too. 487 00:29:16,470 --> 00:29:19,802 So let's call it v1 dot. 488 00:29:19,802 --> 00:29:21,760 So as I described earlier, what I'm doing today 489 00:29:21,760 --> 00:29:26,840 is I'm telling Docker to go use that-- actually, sorry, my bad. 490 00:29:26,840 --> 00:29:29,450 491 00:29:29,450 --> 00:29:32,500 We did not take a look at the Dockerfile itself. 492 00:29:32,500 --> 00:29:39,020 So the only things in here are index.php as well as the readme file 493 00:29:39,020 --> 00:29:39,810 and a Dockerfile. 494 00:29:39,810 --> 00:29:44,600 >> So if you take a look at the Dockerfile, so it's 495 00:29:44,600 --> 00:29:47,150 very similar to what I described earlier. 496 00:29:47,150 --> 00:29:51,220 It's just a bunch of steps that Docker executes 497 00:29:51,220 --> 00:29:56,330 by creating and tearing down containers and [? counting ?] them into an image. 498 00:29:56,330 --> 00:29:59,570 >> And basically you can see-- [INAUDIBLE] it here-- 499 00:29:59,570 --> 00:30:04,340 but this is from the local repo. 500 00:30:04,340 --> 00:30:06,410 It's going to go and grab index.php. 501 00:30:06,410 --> 00:30:10,970 So that's the only source code that are actually part of your application. 502 00:30:10,970 --> 00:30:16,800 All this are basically operating system plumbing, 503 00:30:16,800 --> 00:30:21,460 getting the right packages and Apache, and PHP, and whatnot. 504 00:30:21,460 --> 00:30:26,950 But this is actually taking index.php and committing it into the container, 505 00:30:26,950 --> 00:30:28,210 into the image. 506 00:30:28,210 --> 00:30:33,120 >> So if you go ahead and run the command by doing the following, 507 00:30:33,120 --> 00:30:36,155 it's going-- actually, this might take a bit. 508 00:30:36,155 --> 00:30:40,870 509 00:30:40,870 --> 00:30:42,455 Hopefully it doesn't take too long. 510 00:30:42,455 --> 00:30:45,129 511 00:30:45,129 --> 00:30:46,170 So you can see the steps. 512 00:30:46,170 --> 00:30:49,320 And I encourage you to go back home today and try it. 513 00:30:49,320 --> 00:30:51,280 And Mano will describe how exactly you do that. 514 00:30:51,280 --> 00:30:57,810 But it's really great to see exactly what's happening behind the scenes. 515 00:30:57,810 --> 00:31:02,420 But it's ridiculously easy to build images and deploy them using Docker. 516 00:31:02,420 --> 00:31:12,170 517 00:31:12,170 --> 00:31:14,050 >> It's taking a bit longer than I expected. 518 00:31:14,050 --> 00:31:29,085 519 00:31:29,085 --> 00:31:32,690 >> Let's see what happens when you-- cool. 520 00:31:32,690 --> 00:31:36,260 So as you can see, each of those steps represent lines in the Dockerfile. 521 00:31:36,260 --> 00:31:42,570 And it shows here that it successfully built this image. 522 00:31:42,570 --> 00:31:46,480 >> So if I do docker images, I'm going to see all the images that I have locally. 523 00:31:46,480 --> 00:31:52,160 And one of them is called my username, and the name of the image, 524 00:31:52,160 --> 00:31:56,050 and the tag representing-- mainly it's a version tag. 525 00:31:56,050 --> 00:31:58,040 >> So now if I want to run it, I do docker run. 526 00:31:58,040 --> 00:32:06,040 527 00:32:06,040 --> 00:32:14,960 And I just want to do a -d -P. Do v1. 528 00:32:14,960 --> 00:32:18,500 So I can see now that I have two containers running, the one that I just 529 00:32:18,500 --> 00:32:21,230 created and the hello Docker one that I got last. 530 00:32:21,230 --> 00:32:24,320 >> And you can see here that it assigned it a different port. 531 00:32:24,320 --> 00:32:30,710 So if I go to the same IP but assign it a different port-- hopefully I did not. 532 00:32:30,710 --> 00:32:33,060 So now this is application that I just deployed. 533 00:32:33,060 --> 00:32:35,980 534 00:32:35,980 --> 00:32:43,900 >> If I want to make changes, I can quickly edit the source code 535 00:32:43,900 --> 00:32:49,050 and do the following. 536 00:32:49,050 --> 00:32:55,170 Let's do hello Harvard. 537 00:32:55,170 --> 00:32:57,989 So now what's going to happen is that I'm 538 00:32:57,989 --> 00:32:59,905 going to tag it with a different version-- oh, 539 00:32:59,905 --> 00:33:03,080 not this guy-- tag it with a different version. 540 00:33:03,080 --> 00:33:05,735 And you're going to see-- do you guys expect 541 00:33:05,735 --> 00:33:11,020 it to take the same amount of time to build it a second time or not? 542 00:33:11,020 --> 00:33:14,470 All right, and anyone knows why? 543 00:33:14,470 --> 00:33:15,020 Speak up. 544 00:33:15,020 --> 00:33:16,350 >> AUDIENCE: [INAUDIBLE] 545 00:33:16,350 --> 00:33:19,830 >> NICOLA KABAR: It's basically we only change one of the later steps. 546 00:33:19,830 --> 00:33:23,110 And therefore it's going to use the cache and use each of those layers. 547 00:33:23,110 --> 00:33:27,080 And that's truly some of the killer features of Docker 548 00:33:27,080 --> 00:33:32,930 is how it actually utilizes and reuses taking over 549 00:33:32,930 --> 00:33:36,950 your disk for the same exact pieces of information. 550 00:33:36,950 --> 00:33:40,700 >> So if we do the same thing, it took just a couple seconds. 551 00:33:40,700 --> 00:33:48,860 If we want to redeploy-- so now I should have three containers. 552 00:33:48,860 --> 00:33:56,160 But this one is being served on the-- seven one. 553 00:33:56,160 --> 00:33:58,860 So now it's the third container. 554 00:33:58,860 --> 00:34:02,580 Everyone understand what I just did here? 555 00:34:02,580 --> 00:34:06,320 >> So now if you want to share this container real quick with your friends, 556 00:34:06,320 --> 00:34:14,840 you can just do docker push the name of the container, hopefully. 557 00:34:14,840 --> 00:34:20,130 So now it's going to push it to-- I'm not signed in here. 558 00:34:20,130 --> 00:34:33,511 559 00:34:33,511 --> 00:34:34,219 Sorry about that. 560 00:34:34,219 --> 00:34:39,219 But I'm not going troubleshoot this now. 561 00:34:39,219 --> 00:34:42,780 But basically that one command is just going up push it. 562 00:34:42,780 --> 00:34:45,670 And you're going to be able to see it if you go to Docker Hub 563 00:34:45,670 --> 00:34:48,587 And you log in, you're going to be able to see it. 564 00:34:48,587 --> 00:34:50,420 And then you can just point whoever is going 565 00:34:50,420 --> 00:34:52,750 to use that image to go and pull it. 566 00:34:52,750 --> 00:34:55,460 And they can use it. 567 00:34:55,460 --> 00:34:57,760 >> With that, hopefully I kind of demonstrated 568 00:34:57,760 --> 00:35:01,230 how easy it is to work with Docker. 569 00:35:01,230 --> 00:35:06,610 And I'm just going to give it back to Mano. 570 00:35:06,610 --> 00:35:11,760 And he's going take it from here. 571 00:35:11,760 --> 00:35:13,990 >> MANO MARKS: All right thanks, thanks Nico. 572 00:35:13,990 --> 00:35:18,700 573 00:35:18,700 --> 00:35:20,614 So what? 574 00:35:20,614 --> 00:35:24,410 So one of the things I wanted to do is put together 575 00:35:24,410 --> 00:35:28,820 why this is an important-- why Docker and why 576 00:35:28,820 --> 00:35:33,000 containers are such an important new development, 577 00:35:33,000 --> 00:35:36,890 a new way of actually doing software. 578 00:35:36,890 --> 00:35:41,300 >> And before I do, I'm going to just introduce a few stats. 579 00:35:41,300 --> 00:35:42,790 I'm not going to read all of these. 580 00:35:42,790 --> 00:35:52,540 But this shows you a lot about how popular this is in the community. 581 00:35:52,540 --> 00:35:56,310 The core Docker technologies are open source. 582 00:35:56,310 --> 00:36:03,560 So that's Docker Engine, Compose, Swarm, a bunch of other stuff 583 00:36:03,560 --> 00:36:05,210 is all open source. 584 00:36:05,210 --> 00:36:10,590 And we have, what did I say, 1,300 contributors. 585 00:36:10,590 --> 00:36:15,630 You're seeing now, if you look at the number of job openings, the last time 586 00:36:15,630 --> 00:36:19,640 we looked, it was about 43,000 job openings specifically mentioning 587 00:36:19,640 --> 00:36:22,230 familiarity with Docker. 588 00:36:22,230 --> 00:36:26,450 Hundreds of millions of images have been downloaded from Docker Hub. 589 00:36:26,450 --> 00:36:31,870 And, well, much more large stats. 590 00:36:31,870 --> 00:36:34,770 >> For those who are curious, it was originally written in Python 591 00:36:34,770 --> 00:36:37,730 and then rewritten into Go. 592 00:36:37,730 --> 00:36:40,320 And it's only been open source-- it's only 593 00:36:40,320 --> 00:36:44,950 been released for about 2 and 1/2 years, which means that in 2 and 1/2 years, 594 00:36:44,950 --> 00:36:48,020 we've seen a tremendous amount of growth and importance 595 00:36:48,020 --> 00:36:50,190 of this in the community. 596 00:36:50,190 --> 00:36:52,400 And so I want to talk a little bit about why. 597 00:36:52,400 --> 00:36:54,940 598 00:36:54,940 --> 00:36:59,880 >> So just to reiterate some of Nico's key points, Docker is fast. 599 00:36:59,880 --> 00:37:00,630 It is portable. 600 00:37:00,630 --> 00:37:02,500 It is reproducible. 601 00:37:02,500 --> 00:37:06,130 And it sets up a standard environment. 602 00:37:06,130 --> 00:37:13,370 >> And what-- this is my crappy stamp out monoliths slide-- what 603 00:37:13,370 --> 00:37:17,990 it's helping people do, which a lot of the software industry 604 00:37:17,990 --> 00:37:21,400 started doing in the early 2000s, is moving 605 00:37:21,400 --> 00:37:24,200 from these monolithic single applications 606 00:37:24,200 --> 00:37:28,590 where every dependency had to be tested before the entire app had 607 00:37:28,590 --> 00:37:31,280 to be deployed, which could mean a website 608 00:37:31,280 --> 00:37:36,240 only got deployed once every three months, or more, 609 00:37:36,240 --> 00:37:42,650 to a much more service oriented architecture 610 00:37:42,650 --> 00:37:46,090 or componentized different type of application architecture. 611 00:37:46,090 --> 00:37:48,610 And so allowing these kind of architectures 612 00:37:48,610 --> 00:37:52,250 that take advantage of Docker to run in these three 613 00:37:52,250 --> 00:37:58,450 principal areas of development, which is development writing your actual code, 614 00:37:58,450 --> 00:38:00,140 testing your code, and deploying it. 615 00:38:00,140 --> 00:38:03,000 616 00:38:03,000 --> 00:38:05,420 >> So why is this important? 617 00:38:05,420 --> 00:38:09,920 If you're a-- let me give an example. 618 00:38:09,920 --> 00:38:13,600 If you are a website device developer, you're 619 00:38:13,600 --> 00:38:19,020 developing a website that's based on the database that David produced over here. 620 00:38:19,020 --> 00:38:20,490 Sorry David, I'm calling you out. 621 00:38:20,490 --> 00:38:22,984 622 00:38:22,984 --> 00:38:24,900 If you wanted to deploy the whole thing, you'd 623 00:38:24,900 --> 00:38:28,870 have to wait under a traditional monolithic software development 624 00:38:28,870 --> 00:38:32,710 environment, you'd have to wait until he was done with the database 625 00:38:32,710 --> 00:38:36,030 before you could actually make any changes to your website. 626 00:38:36,030 --> 00:38:40,900 You'd have to redeploy the entire application to do so. 627 00:38:40,900 --> 00:38:45,490 >> And what Docker helps you do is each person work on different components 628 00:38:45,490 --> 00:38:52,990 and update them as they go, just making sure that the interfaces stay the same. 629 00:38:52,990 --> 00:38:56,350 So what it has done is it's shifted people 630 00:38:56,350 --> 00:39:03,950 from doing these massive monolithic architected software that 631 00:39:03,950 --> 00:39:07,610 deployed every month to a continuous integration and continuous development 632 00:39:07,610 --> 00:39:08,490 environment. 633 00:39:08,490 --> 00:39:12,580 >> Now this isn't unique to Docker, but Docker makes it so much easier, 634 00:39:12,580 --> 00:39:16,620 which means you're basically constantly deploying. 635 00:39:16,620 --> 00:39:20,690 We talk to enterprises that are deploying public facing applications 636 00:39:20,690 --> 00:39:30,180 thousands of times a day because they see the value in just making 637 00:39:30,180 --> 00:39:33,740 small changes, and as long as it runs through the tests, 638 00:39:33,740 --> 00:39:35,900 letting it go out into production. 639 00:39:35,900 --> 00:39:41,890 Nico was always telling me earlier that in many environments, 640 00:39:41,890 --> 00:39:46,580 the standard life cycle of a container is measured in seconds, 641 00:39:46,580 --> 00:39:50,460 whereas a virtual machine might be measured in months. 642 00:39:50,460 --> 00:39:54,590 643 00:39:54,590 --> 00:39:58,690 >> I wanted to take a slight turn here because I'm 644 00:39:58,690 --> 00:40:00,170 at an educational institution. 645 00:40:00,170 --> 00:40:06,670 I wanted to give an example of how this works in an educational research 646 00:40:06,670 --> 00:40:07,670 situation. 647 00:40:07,670 --> 00:40:10,930 So there's an organization called bioboxes. 648 00:40:10,930 --> 00:40:15,450 Bioboxes does DNA analysis for researchers. 649 00:40:15,450 --> 00:40:22,029 >> Now what they found was that when a researcher-- and this is not 650 00:40:22,029 --> 00:40:24,070 the fault of any particular researcher-- but when 651 00:40:24,070 --> 00:40:31,240 a researcher deployed an algorithm to analyze, 652 00:40:31,240 --> 00:40:36,670 In a particular way, a DNA sample, they would write the software, 653 00:40:36,670 --> 00:40:39,980 publish that, maybe to GitHub or somewhere else, 654 00:40:39,980 --> 00:40:42,680 and then they were done. 655 00:40:42,680 --> 00:40:47,440 >> Well the problem was that it wasn't necessarily reproducible. 656 00:40:47,440 --> 00:40:51,610 Because in order to understand the software, 657 00:40:51,610 --> 00:40:54,830 they would be set up for the exact development environment 658 00:40:54,830 --> 00:41:00,460 that that researcher used, usually their laptop, or a server, or a data 659 00:41:00,460 --> 00:41:04,280 center that they were using. 660 00:41:04,280 --> 00:41:11,530 And consequently, it was very difficult to reproduce research results when 661 00:41:11,530 --> 00:41:16,910 analyzing DNA samples to look at things like incidence-- 662 00:41:16,910 --> 00:41:23,830 compare incidence of heart attacks based on certain genes being present, 663 00:41:23,830 --> 00:41:28,900 for instance, or cancer risk, or any of the other kinds of things. 664 00:41:28,900 --> 00:41:33,900 >> So what they did instead was they started creating containers. 665 00:41:33,900 --> 00:41:39,380 And you can go to bioboxes.org, it's a great organization. 666 00:41:39,380 --> 00:41:43,900 And what they do is they produce containers based on research. 667 00:41:43,900 --> 00:41:46,840 And then whenever somebody sends in their sample, they can run it. 668 00:41:46,840 --> 00:41:52,770 And it has all the environment needed to run that algorithm 669 00:41:52,770 --> 00:41:55,370 and produce the results. 670 00:41:55,370 --> 00:41:58,250 And they're finding that they're much more likely and much 671 00:41:58,250 --> 00:42:01,300 more quickly able to return results to people. 672 00:42:01,300 --> 00:42:06,860 >> And in fact, what people are doing are running their own analysis on DNA, 673 00:42:06,860 --> 00:42:11,220 sending that in to bioboxes, and then biobox just takes the data, 674 00:42:11,220 --> 00:42:15,350 runs it against the variety of different containers 675 00:42:15,350 --> 00:42:19,030 to see different results based on different research. 676 00:42:19,030 --> 00:42:21,860 So it's a very powerful way in which researchers 677 00:42:21,860 --> 00:42:28,070 can make a single instance that allows other people to try and reproduce 678 00:42:28,070 --> 00:42:28,650 the results. 679 00:42:28,650 --> 00:42:31,710 680 00:42:31,710 --> 00:42:34,360 >> So how do you get started? 681 00:42:34,360 --> 00:42:37,950 682 00:42:37,950 --> 00:42:39,800 We are well supported on Linux. 683 00:42:39,800 --> 00:42:43,070 So if you want to install anything on Linux, 684 00:42:43,070 --> 00:42:45,620 you use your standard package manager to install. 685 00:42:45,620 --> 00:42:47,600 If you're using a Debian, it's apt get. 686 00:42:47,600 --> 00:42:50,500 CentOS is yum. 687 00:42:50,500 --> 00:42:53,500 Fedora Red Hat is rpm-- I don't remember. 688 00:42:53,500 --> 00:42:56,070 Anyway, it's all there. 689 00:42:56,070 --> 00:42:59,610 We support a large variety of Linux distributions. 690 00:42:59,610 --> 00:43:01,150 You can check those out. 691 00:43:01,150 --> 00:43:06,370 >> We also have options so you could run on Mac or Windows. 692 00:43:06,370 --> 00:43:10,670 Now Nico mentioned earlier that it was only supported on Linux. 693 00:43:10,670 --> 00:43:18,180 That's true because it needs a Linux kernel. 694 00:43:18,180 --> 00:43:20,540 But, you can run in a virtual machine. 695 00:43:20,540 --> 00:43:25,290 And what the Docker Toolbox does, which you can download, 696 00:43:25,290 --> 00:43:27,610 it gives you that virtual machine. 697 00:43:27,610 --> 00:43:37,260 >> So just a quick 48 second, I think, download. 698 00:43:37,260 --> 00:43:40,670 You just search on Docker Toolbox, download it to the Mac, 699 00:43:40,670 --> 00:43:43,910 and this part is of course sped up because who 700 00:43:43,910 --> 00:43:47,620 wants to watch a download signal? 701 00:43:47,620 --> 00:43:54,190 Standard Mac installation, and then you're 702 00:43:54,190 --> 00:43:59,795 going to see Jerome put in his password. 703 00:43:59,795 --> 00:44:00,670 That's very exciting. 704 00:44:00,670 --> 00:44:03,510 705 00:44:03,510 --> 00:44:06,230 And then it installs a whole bunch of tools. 706 00:44:06,230 --> 00:44:10,010 And particularly it will install a command line. 707 00:44:10,010 --> 00:44:14,220 And then you could see Jerome testing his images. 708 00:44:14,220 --> 00:44:19,050 709 00:44:19,050 --> 00:44:22,640 >> And then based on this, you can see that YouTube 710 00:44:22,640 --> 00:44:27,420 thinks that Nico is interested in Star Wars, The Jimmy Kimmel show, 711 00:44:27,420 --> 00:44:29,020 and I think Ellen. 712 00:44:29,020 --> 00:44:34,130 I think that last one is a clip from an Ellen show. 713 00:44:34,130 --> 00:44:37,760 >> So Docker Toolbox though comes with more than just Docker Machine. 714 00:44:37,760 --> 00:44:39,840 So Docker Machine is the thing that helps 715 00:44:39,840 --> 00:44:43,710 you set up a virtual machine on your Windows 716 00:44:43,710 --> 00:44:52,080 or Mac-- your Windows box or your Mac box-- and helps you do provisioning, 717 00:44:52,080 --> 00:44:54,040 >> But it also comes with Swarm and Compose, 718 00:44:54,040 --> 00:45:00,840 which are designed to help you do large scale deployments of your application. 719 00:45:00,840 --> 00:45:04,000 So if you want to manage clusters of nodes, 720 00:45:04,000 --> 00:45:08,450 clusters of containers, Compose and Swarm are the way to go about that. 721 00:45:08,450 --> 00:45:11,430 >> And of course it comes with Docker Engine and Kitematic, 722 00:45:11,430 --> 00:45:13,250 which is this desktop GUI. 723 00:45:13,250 --> 00:45:17,060 I should also mention Docker Registry, which is not included in Toolbox, 724 00:45:17,060 --> 00:45:23,150 but it is a way for you to run your own registries of Docker Images like Docker 725 00:45:23,150 --> 00:45:28,970 Hub, but you can also just use Docker Hub as a way to do that. 726 00:45:28,970 --> 00:45:32,955 >> And, plot twist, you're seeing it running in a container. 727 00:45:32,955 --> 00:45:34,830 And that's how we're distributing our slides. 728 00:45:34,830 --> 00:45:38,610 This whole presentation is actually an HTML slide deck. 729 00:45:38,610 --> 00:45:43,170 And it is running in a container, which you can get by-- 730 00:45:43,170 --> 00:45:45,596 >> NICOLA KABAR: Yes, so it's running full time on my Max. 731 00:45:45,596 --> 00:45:47,540 And I'm presenting from it. 732 00:45:47,540 --> 00:45:50,910 And you just do Docker after you install your Toolbox. 733 00:45:50,910 --> 00:45:57,340 You can just do a docker run and get it, and use the slides. 734 00:45:57,340 --> 00:45:58,830 >> MANO MARKS: And that's it. 735 00:45:58,830 --> 00:46:02,160 So we thank you all for coming. 736 00:46:02,160 --> 00:46:03,990 And we're happy to answer questions. 737 00:46:03,990 --> 00:46:07,810 I should mention before anybody leaves there is T-shirts over there. 738 00:46:07,810 --> 00:46:10,940 Sorry anybody who is watching this on Livestream or video, 739 00:46:10,940 --> 00:46:12,820 but we have Docker T-shirts over there. 740 00:46:12,820 --> 00:46:16,250 And we know Docker students, and in my experience, 741 00:46:16,250 --> 00:46:18,940 professors too, like free clothing. 742 00:46:18,940 --> 00:46:22,490 >> So thank you all for coming out. 743 00:46:22,490 --> 00:46:27,050 And follow us on Twitter if you want, or don't. 744 00:46:27,050 --> 00:46:27,910 I don't care. 745 00:46:27,910 --> 00:46:29,430 Also follow Docker on Twitter. 746 00:46:29,430 --> 00:46:31,890 That's also interesting. 747 00:46:31,890 --> 00:46:32,990 And then that's it. 748 00:46:32,990 --> 00:46:33,490 Docker.com. 749 00:46:33,490 --> 00:46:35,410 Thank you. 750 00:46:35,410 --> 00:46:39,360 >> [APPLAUSE] 751 00:46:39,360 --> 00:46:41,625