1 00:00:00,000 --> 00:00:01,050 In this lesson, 2 00:00:01,050 --> 00:00:03,960 we're going to dive into the concepts of containerization, 3 00:00:03,960 --> 00:00:06,060 its benefits, its use cases, 4 00:00:06,060 --> 00:00:08,490 and how you can perform basic container operations 5 00:00:08,490 --> 00:00:10,050 inside of Linux. 6 00:00:10,050 --> 00:00:11,790 Now, the newest type of virtualization 7 00:00:11,790 --> 00:00:13,860 that's becoming popular in our networks today 8 00:00:13,860 --> 00:00:16,230 is known as container-based virtualization, 9 00:00:16,230 --> 00:00:18,780 also referred to as containerization. 10 00:00:18,780 --> 00:00:20,400 Now, this is a type of virtualization 11 00:00:20,400 --> 00:00:22,380 that is much more focused on servers 12 00:00:22,380 --> 00:00:24,510 than on end user workstations. 13 00:00:24,510 --> 00:00:26,280 With this type of virtualization, 14 00:00:26,280 --> 00:00:27,690 the operating system kernel 15 00:00:27,690 --> 00:00:30,330 is going to be shared across multiple virtual machines, 16 00:00:30,330 --> 00:00:33,450 but the user space for each of those virtual machines 17 00:00:33,450 --> 00:00:35,640 is uniquely created and managed. 18 00:00:35,640 --> 00:00:38,520 Containerization is really a type of virtualization 19 00:00:38,520 --> 00:00:40,650 that's applied by the host operating system 20 00:00:40,650 --> 00:00:42,840 to provision an isolated execution environment 21 00:00:42,840 --> 00:00:44,559 for a given application. 22 00:00:44,559 --> 00:00:47,130 Containerization is considered fairly secure 23 00:00:47,130 --> 00:00:49,020 because it enforces resource separation 24 00:00:49,020 --> 00:00:51,060 at the operating system level. 25 00:00:51,060 --> 00:00:54,210 Now, containerization is commonly used with Linux servers, 26 00:00:54,210 --> 00:00:55,320 and some common examples 27 00:00:55,320 --> 00:00:57,450 of container-based virtualization software 28 00:00:57,450 --> 00:01:00,150 includes things like Kubernetes, Docker, 29 00:01:00,150 --> 00:01:03,570 Parallels Virtuozzo, and the OpenVZ project. 30 00:01:03,570 --> 00:01:06,570 So what does containerization really look like? 31 00:01:06,570 --> 00:01:08,250 Well, you have a piece of hardware, 32 00:01:08,250 --> 00:01:09,930 and then on top of that hardware 33 00:01:09,930 --> 00:01:12,150 you have some host operating system. 34 00:01:12,150 --> 00:01:14,310 And usually this is going to be Linux. 35 00:01:14,310 --> 00:01:16,290 Then you have a container manager, 36 00:01:16,290 --> 00:01:19,740 something like Kubernetes or Docker or something like that. 37 00:01:19,740 --> 00:01:21,480 This container manager is going to be used 38 00:01:21,480 --> 00:01:22,770 to create different containers 39 00:01:22,770 --> 00:01:25,140 that have different applications within them. 40 00:01:25,140 --> 00:01:27,900 In this case, let's say I have three containers. 41 00:01:27,900 --> 00:01:29,130 I have the first environment, 42 00:01:29,130 --> 00:01:31,590 which is based on the kernel of the host OS. 43 00:01:31,590 --> 00:01:34,170 In this example, a Linux system is being used, 44 00:01:34,170 --> 00:01:37,170 and so you can see container one is running Linux 45 00:01:37,170 --> 00:01:38,430 and it has some applications 46 00:01:38,430 --> 00:01:40,050 that can be run inside of there. 47 00:01:40,050 --> 00:01:42,870 Now, in container two, we're going to do the same thing. 48 00:01:42,870 --> 00:01:45,780 And then in container three, we're going to do the same thing. 49 00:01:45,780 --> 00:01:47,340 Now, all three of these containers 50 00:01:47,340 --> 00:01:49,710 are sharing the same host operating system, 51 00:01:49,710 --> 00:01:50,970 in this case Linux, 52 00:01:50,970 --> 00:01:53,280 and so this takes a lot less resources 53 00:01:53,280 --> 00:01:56,370 than doing pure virtualization using virtual machines. 54 00:01:56,370 --> 00:01:59,340 If we instead wanted to use individual virtual machines, 55 00:01:59,340 --> 00:02:00,900 each one would need its own copy 56 00:02:00,900 --> 00:02:02,460 of the Linux operating system, 57 00:02:02,460 --> 00:02:04,290 and this could add eight to 10 gigabytes 58 00:02:04,290 --> 00:02:06,270 for each and every container. 59 00:02:06,270 --> 00:02:08,880 But with containers, we don't have to do that 60 00:02:08,880 --> 00:02:11,340 because we can all share the same operating system, 61 00:02:11,340 --> 00:02:13,800 and therefore it takes a lot less storage space 62 00:02:13,800 --> 00:02:15,510 and a lot less processing power, 63 00:02:15,510 --> 00:02:17,670 and it's much more resource efficient. 64 00:02:17,670 --> 00:02:18,763 This is really the real benefit 65 00:02:18,763 --> 00:02:20,760 of using something like a container 66 00:02:20,760 --> 00:02:22,860 from an operational perspective. 67 00:02:22,860 --> 00:02:25,710 Now, because these containers are logically isolated, 68 00:02:25,710 --> 00:02:28,170 they can't actually interface with each other. 69 00:02:28,170 --> 00:02:29,580 If we want these two containers 70 00:02:29,580 --> 00:02:31,050 to be able to talk to each other, 71 00:02:31,050 --> 00:02:33,750 I have to actually connect them through a virtual network, 72 00:02:33,750 --> 00:02:36,150 and I do that by using the right routing and switching 73 00:02:36,150 --> 00:02:37,710 to allow them to talk. 74 00:02:37,710 --> 00:02:38,820 By default though, 75 00:02:38,820 --> 00:02:40,620 they have no way of talking to each other, 76 00:02:40,620 --> 00:02:43,470 and this is another great thing from a security standpoint 77 00:02:43,470 --> 00:02:45,930 because they are being fully isolated. 78 00:02:45,930 --> 00:02:47,490 Now, here's a big warning for you 79 00:02:47,490 --> 00:02:49,290 when you're dealing with containers. 80 00:02:49,290 --> 00:02:50,550 If the attacker compromises 81 00:02:50,550 --> 00:02:52,920 the host operating system underneath, 82 00:02:52,920 --> 00:02:56,070 for example that Linux operating system I'm using here, 83 00:02:56,070 --> 00:02:57,480 guess what happens? 84 00:02:57,480 --> 00:03:00,150 This attacker now has access to all of the containers 85 00:03:00,150 --> 00:03:01,500 and all of their data 86 00:03:01,500 --> 00:03:03,150 because that one operating system 87 00:03:03,150 --> 00:03:05,190 is being used by all of the containers 88 00:03:05,190 --> 00:03:07,680 that I'm hosting on this physical machine. 89 00:03:07,680 --> 00:03:09,390 This is one of the biggest vulnerabilities 90 00:03:09,390 --> 00:03:11,070 when you use containers. 91 00:03:11,070 --> 00:03:12,360 I can have a container system 92 00:03:12,360 --> 00:03:14,700 that's running 50 different servers right now, 93 00:03:14,700 --> 00:03:16,560 and because I'm running all these different servers 94 00:03:16,560 --> 00:03:18,390 and services using containerization, 95 00:03:18,390 --> 00:03:21,060 they're all hosted on the same physical server. 96 00:03:21,060 --> 00:03:23,700 Now, if somebody gets into that one physical Linux server 97 00:03:23,700 --> 00:03:24,840 that's underneath them 98 00:03:24,840 --> 00:03:26,550 that's hosting all of these containers, 99 00:03:26,550 --> 00:03:28,260 they now have access to all 50 100 00:03:28,260 --> 00:03:30,570 of those hosted services and applications 101 00:03:30,570 --> 00:03:32,220 as well as their data. 102 00:03:32,220 --> 00:03:34,740 So now that we understand the basics of containers, 103 00:03:34,740 --> 00:03:37,710 let's dive a little bit into Kubernetes for a moment. 104 00:03:37,710 --> 00:03:39,660 Kubernetes is an open source system 105 00:03:39,660 --> 00:03:42,210 for automated deployment, scaling, and management 106 00:03:42,210 --> 00:03:44,460 of containerized applications. 107 00:03:44,460 --> 00:03:46,500 Kubernetes is going to be used to group containers 108 00:03:46,500 --> 00:03:47,850 that make up applications 109 00:03:47,850 --> 00:03:50,550 into logical units for production use. 110 00:03:50,550 --> 00:03:52,080 When you deploy Kubernetes, 111 00:03:52,080 --> 00:03:53,730 you're going to gain access to a cluster 112 00:03:53,730 --> 00:03:57,420 that contains a set of worker machines which we call nodes. 113 00:03:57,420 --> 00:03:59,190 These nodes or worker machines 114 00:03:59,190 --> 00:04:00,420 are the objects that are running 115 00:04:00,420 --> 00:04:02,520 the containerized applications. 116 00:04:02,520 --> 00:04:03,960 Now, inside of these nodes, 117 00:04:03,960 --> 00:04:06,210 we host something known as a pod. 118 00:04:06,210 --> 00:04:08,460 A pod is the name used by Kubernetes 119 00:04:08,460 --> 00:04:09,870 for one or more containers 120 00:04:09,870 --> 00:04:12,660 that have shared storage and network resources. 121 00:04:12,660 --> 00:04:14,070 A pod is really the smallest 122 00:04:14,070 --> 00:04:16,709 deployable unit of computing power that you can create 123 00:04:16,709 --> 00:04:18,690 and manage within Kubernetes. 124 00:04:18,690 --> 00:04:21,149 Multiple pods can also be combined into a node 125 00:04:21,149 --> 00:04:23,250 for use in Kubernetes too. 126 00:04:23,250 --> 00:04:24,630 Now, in addition to pods, 127 00:04:24,630 --> 00:04:26,400 there's also these specialized containers 128 00:04:26,400 --> 00:04:27,960 known as sidecars. 129 00:04:27,960 --> 00:04:30,990 Now, a sidecar container is designed to run alongside 130 00:04:30,990 --> 00:04:33,000 a main container or pod. 131 00:04:33,000 --> 00:04:35,670 These two containers are designed to share resources, 132 00:04:35,670 --> 00:04:38,100 like a pod storage or network interfaces, 133 00:04:38,100 --> 00:04:40,740 as well as allowing a sidecar and a main container 134 00:04:40,740 --> 00:04:42,540 to both share a storage volume 135 00:04:42,540 --> 00:04:43,710 so that data can be accessed 136 00:04:43,710 --> 00:04:46,860 by both the main and sidecar containers. 137 00:04:46,860 --> 00:04:48,840 The real benefit of using a sidecar 138 00:04:48,840 --> 00:04:50,250 is that you can enhance and extend 139 00:04:50,250 --> 00:04:52,200 the functionalities of the main container 140 00:04:52,200 --> 00:04:54,990 without having to modify its original code base. 141 00:04:54,990 --> 00:04:56,910 Additionally, the sidecar can also use 142 00:04:56,910 --> 00:04:58,230 a different programming language 143 00:04:58,230 --> 00:05:00,450 than the main container does if you need to. 144 00:05:00,450 --> 00:05:02,880 And this makes it even more extendable and useful 145 00:05:02,880 --> 00:05:05,970 when you're developing and deploying microservices. 146 00:05:05,970 --> 00:05:08,400 Now, in addition to regular sidecar containers, 147 00:05:08,400 --> 00:05:10,620 there's also a specialized type of sidecar 148 00:05:10,620 --> 00:05:12,810 known as an Ambassador container. 149 00:05:12,810 --> 00:05:14,160 Now, an Ambassador container 150 00:05:14,160 --> 00:05:16,290 is a special type of sidecar container 151 00:05:16,290 --> 00:05:17,730 that's going to simplify the process 152 00:05:17,730 --> 00:05:21,750 of accessing data and services outside of a given pod. 153 00:05:21,750 --> 00:05:24,600 The Ambassador container is also used to hide the complexity 154 00:05:24,600 --> 00:05:27,090 involved in accessing external services 155 00:05:27,090 --> 00:05:29,010 by providing you with a uniform interface 156 00:05:29,010 --> 00:05:30,900 to access those services. 157 00:05:30,900 --> 00:05:32,430 For example, let's pretend 158 00:05:32,430 --> 00:05:34,470 that I have a main container application 159 00:05:34,470 --> 00:05:36,300 that's being used to host my website, 160 00:05:36,300 --> 00:05:38,880 and this website is going to be used to sell exam vouchers 161 00:05:38,880 --> 00:05:40,800 for the CompTIA exams. 162 00:05:40,800 --> 00:05:42,270 Now, in addition to providing 163 00:05:42,270 --> 00:05:44,160 inventory management and assignment, 164 00:05:44,160 --> 00:05:46,320 when somebody buys one of those exam vouchers, 165 00:05:46,320 --> 00:05:47,430 we also need to access 166 00:05:47,430 --> 00:05:49,710 our credit card processor's remote service 167 00:05:49,710 --> 00:05:52,230 to get paid for selling that exam voucher. 168 00:05:52,230 --> 00:05:54,750 We could do this by using an Ambassador container 169 00:05:54,750 --> 00:05:57,390 as a proxy between our main application container 170 00:05:57,390 --> 00:05:59,790 that runs our exam voucher store and inventory 171 00:05:59,790 --> 00:06:02,520 and the remote services of our credit card company 172 00:06:02,520 --> 00:06:04,110 that's going to be used to process the sale 173 00:06:04,110 --> 00:06:05,760 and verify that your credit card 174 00:06:05,760 --> 00:06:08,790 has sufficient funds available to make this purchase. 175 00:06:08,790 --> 00:06:10,320 Another area you need to think about 176 00:06:10,320 --> 00:06:12,480 when it comes to containers is storage, 177 00:06:12,480 --> 00:06:14,700 because often we're going to use containerization 178 00:06:14,700 --> 00:06:15,870 with cloud services 179 00:06:15,870 --> 00:06:18,060 to rapidly scale upwards or downwards 180 00:06:18,060 --> 00:06:20,160 based on the demands of our users. 181 00:06:20,160 --> 00:06:23,370 For example, at my company we use containers a lot 182 00:06:23,370 --> 00:06:24,660 to host our websites, 183 00:06:24,660 --> 00:06:26,430 and as the user demand increases, 184 00:06:26,430 --> 00:06:28,590 we can spin up new containers automatically 185 00:06:28,590 --> 00:06:30,270 and add them to our load balancer 186 00:06:30,270 --> 00:06:32,340 to handle those additional requests. 187 00:06:32,340 --> 00:06:33,180 The challenge, though, 188 00:06:33,180 --> 00:06:35,310 is that all the data that we need to store 189 00:06:35,310 --> 00:06:37,020 has to be set up in a separate area 190 00:06:37,020 --> 00:06:38,490 outside of the containers 191 00:06:38,490 --> 00:06:41,610 because these containers will spin up and later be destroyed 192 00:06:41,610 --> 00:06:43,470 along with all the data they have. 193 00:06:43,470 --> 00:06:44,820 And this is because containers 194 00:06:44,820 --> 00:06:47,220 are designed to be non-persistent by default, 195 00:06:47,220 --> 00:06:48,870 and they're responsive to our user demand 196 00:06:48,870 --> 00:06:50,160 of going up and down 197 00:06:50,160 --> 00:06:52,980 and destroying that data when we close them out. 198 00:06:52,980 --> 00:06:54,360 Now, to solve this issue, 199 00:06:54,360 --> 00:06:57,000 we also need to create a persistent storage volume 200 00:06:57,000 --> 00:06:58,980 that these containers can then use. 201 00:06:58,980 --> 00:07:01,620 To do this, you're going to create a PersistentVolume 202 00:07:01,620 --> 00:07:03,900 that exists on your physical storage device, 203 00:07:03,900 --> 00:07:06,780 and then you're going to create a PersistentVolumeClaim 204 00:07:06,780 --> 00:07:08,040 that'll automatically be bound 205 00:07:08,040 --> 00:07:10,260 to that suitable PersistentVolume. 206 00:07:10,260 --> 00:07:12,090 Now, whenever you create a pod, 207 00:07:12,090 --> 00:07:14,790 you can configure it to use the PersistentVolumeClaim 208 00:07:14,790 --> 00:07:16,410 and access this persistent storage 209 00:07:16,410 --> 00:07:18,870 for any data that needs to be read or written 210 00:07:18,870 --> 00:07:20,940 to a more permanent storage media area 211 00:07:20,940 --> 00:07:23,070 outside of a given container. 212 00:07:23,070 --> 00:07:24,840 Now, when you start using containers, 213 00:07:24,840 --> 00:07:27,240 you'll often find yourself becoming a bit overwhelmed 214 00:07:27,240 --> 00:07:29,040 with all the different options that exist 215 00:07:29,040 --> 00:07:31,650 between things like Docker and Kubernetes. 216 00:07:31,650 --> 00:07:34,230 These tools actually work together really well, 217 00:07:34,230 --> 00:07:36,630 even though some people think they're competitors. 218 00:07:36,630 --> 00:07:38,910 For example, using Docker Compose, 219 00:07:38,910 --> 00:07:41,040 you can build a single configuration file 220 00:07:41,040 --> 00:07:43,770 to orchestrate multi-container applications. 221 00:07:43,770 --> 00:07:45,630 Let's say you have a new web application 222 00:07:45,630 --> 00:07:46,463 that's going to be split 223 00:07:46,463 --> 00:07:48,450 between your front end and your back end. 224 00:07:48,450 --> 00:07:51,360 The front end is going to be written in React JavaScript 225 00:07:51,360 --> 00:07:54,630 and the back end is going to be written with Node JavaScript. 226 00:07:54,630 --> 00:07:56,490 Now, this could be built in Docker Compose 227 00:07:56,490 --> 00:07:59,280 as a single node but with multiple containers, 228 00:07:59,280 --> 00:08:01,410 one for the front end and one for the back end. 229 00:08:01,410 --> 00:08:03,270 And maybe you might have a third container 230 00:08:03,270 --> 00:08:05,100 for a database as well. 231 00:08:05,100 --> 00:08:07,920 Now, this could all be converted into Kubernetes as well 232 00:08:07,920 --> 00:08:10,020 if you wanted to use the Kompose tool, 233 00:08:10,020 --> 00:08:12,420 and you do this by entering kompose convert, 234 00:08:12,420 --> 00:08:15,870 and that will create a Kubernetes manifest in YAML format 235 00:08:15,870 --> 00:08:18,930 that's ready to be deployed into your Kubernetes kernel. 236 00:08:18,930 --> 00:08:20,490 Now, why would you want to do this 237 00:08:20,490 --> 00:08:23,280 instead of just using Kubernetes in the first place? 238 00:08:23,280 --> 00:08:26,340 Well, Docker Compose is a lot easier to work with 239 00:08:26,340 --> 00:08:28,410 and it's much more convenient than Kubernetes 240 00:08:28,410 --> 00:08:29,580 when you want to get an application 241 00:08:29,580 --> 00:08:32,669 up and running very quickly during your local development. 242 00:08:32,669 --> 00:08:35,280 So you can do all the necessary configuration 243 00:08:35,280 --> 00:08:37,380 for running a multi-container application 244 00:08:37,380 --> 00:08:40,260 within a single file using Docker Compose. 245 00:08:40,260 --> 00:08:43,080 And then you can convert it using Kompose 246 00:08:43,080 --> 00:08:46,680 to the relevant Kubernetes manifest file inside YAML format 247 00:08:46,680 --> 00:08:49,260 for large scale production deployments. 248 00:08:49,260 --> 00:08:52,260 Another thing we need to talk about is container registries. 249 00:08:52,260 --> 00:08:54,840 Now, a container registry is a place to store, 250 00:08:54,840 --> 00:08:57,510 manage, and secure your container images. 251 00:08:57,510 --> 00:08:58,860 From within the registry, 252 00:08:58,860 --> 00:09:01,650 you can conduct vulnerability analysis of your containers 253 00:09:01,650 --> 00:09:03,750 and implement fine grain access controls 254 00:09:03,750 --> 00:09:05,250 to those containers. 255 00:09:05,250 --> 00:09:06,720 Container registries are set up 256 00:09:06,720 --> 00:09:08,220 to work with Docker containers, 257 00:09:08,220 --> 00:09:10,830 and these registries can be linked from within Kubernetes 258 00:09:10,830 --> 00:09:13,200 to allow you to pull an image from the registry 259 00:09:13,200 --> 00:09:14,130 and launch the container 260 00:09:14,130 --> 00:09:16,710 using automations and orchestrations. 261 00:09:16,710 --> 00:09:18,690 Finally, we need to cover the concepts 262 00:09:18,690 --> 00:09:21,300 of a service mesh within Kubernetes. 263 00:09:21,300 --> 00:09:22,980 Now, a Kubernetes service mesh 264 00:09:22,980 --> 00:09:25,770 is a tool that inserts security, observability, 265 00:09:25,770 --> 00:09:28,410 and reliability features to your applications 266 00:09:28,410 --> 00:09:31,950 at the platform layer instead of at the application layer. 267 00:09:31,950 --> 00:09:33,630 Now, a service mesh is going to be used 268 00:09:33,630 --> 00:09:35,040 to manage the network traffic 269 00:09:35,040 --> 00:09:37,740 between different services, containers, and pods, 270 00:09:37,740 --> 00:09:40,800 which is critical when you're building microservices. 271 00:09:40,800 --> 00:09:43,170 Generally, the service mesh is going to be implemented 272 00:09:43,170 --> 00:09:44,760 as a set of network proxies 273 00:09:44,760 --> 00:09:46,890 that are deployed alongside a sidecar, 274 00:09:46,890 --> 00:09:49,020 and they can make use of the Ambassador containers 275 00:09:49,020 --> 00:09:50,430 that I mentioned earlier. 276 00:09:50,430 --> 00:09:51,540 This service mesh layer 277 00:09:51,540 --> 00:09:53,940 sits on top of a Kubernetes infrastructure 278 00:09:53,940 --> 00:09:56,580 to provide interservice communication over the network 279 00:09:56,580 --> 00:09:58,830 in a reliable and safe manner. 280 00:09:58,830 --> 00:10:00,450 This service mesh is going to consist 281 00:10:00,450 --> 00:10:02,520 of a data plane and a control plane. 282 00:10:02,520 --> 00:10:04,380 And if you think back to your Network+ studies 283 00:10:04,380 --> 00:10:06,180 where you learned about overlay networks, 284 00:10:06,180 --> 00:10:08,550 that's exactly what we're referring to here. 285 00:10:08,550 --> 00:10:10,140 These overlay networks can be used 286 00:10:10,140 --> 00:10:12,210 to bridge physical or logical networks, 287 00:10:12,210 --> 00:10:14,580 conduct network address translation or NAT, 288 00:10:14,580 --> 00:10:16,320 and connect the host and the containers 289 00:10:16,320 --> 00:10:18,270 to other data sources or services 290 00:10:18,270 --> 00:10:20,460 outside of the network or across the internet, 291 00:10:20,460 --> 00:10:22,060 depending on your configuration.