Containerization in the Cloud

0:00Welcome back beautiful learners to another skill. Thus far we've talked about virtual machines as some of the real workhorses of cloud computing, but we've really just scratched the surface. There are many layers to this onion. And I'd like to consider the next layer down to be containers. Behind all those page you go services that dominate our IT landscape today, you can bet there's a container or 100 quietly chugging along doing our bidding. In this skill we're going to learn why this is and how they differ from virtual machines. We're also going to get some hands on with deploying containers on AWS.

0:36And because Google was one of the OGs in container adoption, we'll show some love to GCP as well. Perhaps most importantly, we'll finally be able to settle that critical benchmarking question about containers. Will it quake? Let's go.

0:00So when you think about containers, what comes to mind? Maybe it's these little food containers for your lunch, or maybe it's these shipping containers right here. They have a standardized size, and if you have the right equipment, you can pick it up off of a ship and put it on the back of a truck and then drive that truck to some delivery point, and then it gets emptied out, and then you can bring the container back and fill it up again and so forth and so on. Well, this was the inspiration for coming up with what we are going to talk about, about containers in the IT context, these shipping containers.

0:35So let's go back in history a little bit. Back in the day, we had our physical machines here. Of course, we still have physical machines, but we have the hardware, the operating system, and we would load software on top of the operating system. So over time, you'd get a bunch of stuff loaded up here in the operating system, in the application space, and then let's say it's time to upgrade to a different system. Maybe the system is out of warranty, it's getting old or something like that. Well, you're going to try to upgrade to a new system, and inevitably, there is going to be some little piece of software here from here that some reason doesn't make it over here.

1:14Now, I know it's shocking, but IT folks don't really like to document things. So if there was a problem over here, they'd solve the problem, and then we install the software over here, "Hey, there's something missing here, it's causing a problem," and that would cause this application maybe not to work. So this was a real pain, and it really is still a real pain when you're dealing with kind of upgrading physical hardware and moving all your stuff to a new system. Just imagine having to do this at scale, like with hundreds or even thousands of systems.

1:47This would really be a major headache. So along came virtual machines, we have the hardware, we have the operating system, and we have our hypervisor right here. Here are our nice little virtual machines. The problem is that this doesn't really solve that issue of all these different softwares kind of interacting together. Then if we wanted to maybe take this particular software out and pull it out into a separate virtual machine, well, we run the risk of the same thing. We're really not sure if we have all the stuff that we need here.

2:20So yes, we have portability. We can take this virtual machine to other locations, other physical locations, other cloud providers, but we still kind of have this nagging problem of, do we have all the ingredients if we want to move this to another virtual machine? And that's kind of the problem that containers were built to solve. So very similar to virtual machines, we have hardware, we have an operating system, and we have some container software here. And the container software is going to allow us to define little containers.

2:53They're kind of like little lightweight virtual machines. And the idea here is that each of these containers is specialized. It has just one purpose. Now, yes, you could create a container that's like this massive container and load all the software onto it, but that is really not what containers are designed to do. They're designed to be very atomic, kind of self-contained. So that I can take this little piece of software here, I can move it to another system or another cloud provider as long as they support this container software here, and it's going to run just fine.

3:25As a matter of fact, this is a very common way for developers whenever they're developing, they will create a container for their product or whatever they produced. And the old adage of, well, ran on my machine, that's kind of the excuse the developers always say, but by using containerization here, they can package all the needed requirements in this little package and then send that to some other developer or some other DevOps person or SysOps person, and they can put that in production, and they will know, they will know that if this container has been packaged properly, then it will run exactly like it did on the developer's machine.

4:08One of the most popular software, this container software here is something called Docker. And yeah, look at that. Their little logo has these little shipping containers, and it's kind of this happy little whale, looks like a shipping ship, I guess, and you may have heard of Docker. Well, if we say Docker containers, that's exactly what they're talking about here. They have used the Docker software to define a container, then you would build that container, and then you can upload that container into a registry, for example.

4:42So this container here is kind of like an image. It has a lot in common with an image when we were talking about virtual machines, but it is much more lightweight, and we'll see how much more lightweight later in this skill. So here's the cool thing about containers. We have all these little independent software bits here that are working properly on our local network, our local data center, and we can very easily move those to the cloud if we wanted to.

5:15And yes, we can do the same with virtual machines, but let's say a virtual machine, maybe it averages five gigabytes in size or something like that. Well, what we can do by being able to scale back on what we need inside this container, maybe this container is only like a couple megabytes or something like that. Well, we can upload that to the cloud much more regularly and much faster than if we're trying to upload a full virtual machine. So containers are really easy to be able to deploy in these cloud providers.

5:46And all the major cloud providers support Docker for sure. And in fact, they'll support any container that adheres to something called the OCI standard or the OCI compliance. That is not Oracle Cloud infrastructure. That is open container initiative. And if the container applies or is compliant to that standard and Docker will create containers that are compliant with that, then we can very easily move this into one of these cloud providers.

6:19Or we can also host this on-prem in our own data center and kind of move them back and forth as needed. Now, if we just have all these containers just lying around on somebody's hard drive somewhere, that's not very good at all. No, we have something called a registry. So there are public registries of containers. And you can also create a private registry for within your organization where you can store all these containers in that registry. And most of these registries have version control.

6:50So let's say you have a version one of this and a version seven of that and so forth and so on. And you can upload that to the registry. And then you can pull that container from that registry. It's very similar to GitHub if you've ever used that where you can pull a certain version. If you want a back version of this for one reason or another. Or if you want the latest version, you can just say, "Hey, give me the latest version of that container." And it is going to download that from that registry. Now, in and among this discussion about containers, there have been all sorts of other tools and processes and services that have cropped up.

7:28One of the most popular is something called Kubernetes. And that came from these folks right here at Google. They open sourced Kubernetes. And really Kubernetes is designed to manage containers at a huge scale. So most of the organizations that are deploying containers that have more than 100 or so or 50 or so or whatever, they're going to be using something like Kubernetes because it offers a bunch of tools to help manage the instances that are running these containers and manage fault tolerance and workload distribution and all sorts of stuff like that.

8:04So of course, if you're like me, when you first heard Kubernetes, you're asking yourself, "What the heck is a Kubernetes?" Well, it's a Greek word that means a captain or a pilot. And sometimes it's shortened to K8s. And the reason for that is that there's a K and there's one, two, three, four, five, six, seven, eight letters and I guess this S doesn't really count. But Kubernetes is sometimes shortened to K8s. Why? Why do they call it K8s?

8:35I don't know. We computer nerds are kind of a strange bunch. But anyway, that is how we got here with containers.

0:00All right, one of the things you may be asking yourself, is it sure it does sound like containers or a lot like virtual machines? Well, yes, they are a lot like virtual machines. They are virtual entities that host software and both of these kind of do that same thing. But really virtual machines are supposed to be totally self-contained. And that just means that we can take that particular virtual machine, we can load it on some other virtual machine software and then start it up and it's gonna boot up as if it's a full computer.

0:30Containers on the other hand are mostly self-contained. They do rely on the container software to do some magic and abstract things away. But here's the trade-off here. Virtual machines are less portable, usually because they're larger and they require relatively specialized hardware. And yes, if you create a virtual machine using VMware, you can run it using VMware someplace else, but it's a bit of a hassle to run a VMware machine and then have it load up into VirtualBox, for example.

1:03Yes, it can be done, absolutely. But sometimes you may have to go through some sort of conversion process. So virtual machines are less portable. And that's also due to the fact that they're usually larger than containers because they contain everything that they need, everything in the operating system. Containers on the other hand contain just really the only stuff that they're gonna need to do whatever job it is they're supposed to be doing. And that makes them more portable. Virtual machines have a full OS, full operating system.

1:35So they're larger usually. And containers typically only have the parts and pieces of an operating system that they need because they rely on the container software to do other stuff that normally would be encased in a virtual machine. Virtual machines require more hardware because they have all these things, all this OS and kind of virtualizing the hardware. They require more horsepower to run. And containers are lightweight and they're relatively nimble and they would just require less resources.

2:10Now finally, this is kind of the most important distinction here is that if you remember back when we were talking about our scaling conversation, if you're dealing with legacy applications that kind of needed to scale vertically rather than they didn't have the ability to scale horizontally, vertical machines are more attuned or they're more equipped to deal with legacy applications. And if you think about it, it makes sense because if you have this legacy application that is used to running on a physical system, a full operating system with all the underlying hardware, then that legacy system is gonna wanna run on a virtual machine or you could get it to run on a virtual machine.

2:52In contrast, containers, kind of think of those as kind of like bits and pieces of various stuff, you're not going to get the full complement of a full virtual machine using a container. So virtual machines are typically used more for legacy purposes, legacy application purposes, whereas containers are typically used for more cloud native applications. And these are applications that are probably gonna be able to scale horizontally. And let's say we have this little container and we can spin up maybe a dozen containers and that would be the horizontal scaling aspect of it there.

3:28Whereas maybe your legacy app just doesn't handle that. It doesn't know how to deal with multiple systems. It only knows, hey, I need a more memory or a bigger CPU. So those are the main differences between VMs and containers.

0:00Alright, let's play around with some containers. So I have just created just a standard old EC2 instance out here using Ubuntu Linux. Now in the past, we've been working primarily with Amazon Linux. And if you remember, Linux is kind of the lingua franca of the cloud. So I would really highly encourage you to learn at least some Linux. And there are many different variants of Linux. Ubuntu is one type. Amazon Linux is another type. There's Red Hat. There's Sent. There's Debian.

0:30There's all sorts of other variants. Generally speaking, they all work the same way. They have little different subtle differences between them and they're used for different purposes. So I am just going to log into the system. We're going to log in the same way we have with the other systems. I'm going to connect there. And you can see there's a little bit different information when we log in here than when we logged into Amazon Linux. They had that bird looking thing there. So this gives us some statistics here about the machine we're logging into.

1:03Let me make this a little bit larger. What I've already done here is I've already updated and upgraded the system. And let me just do that again just to show you and I'll explain what these commands do. Because whenever I can show you some Linux, I think that's going to be a good thing because Linux skills go hand in hand with cloud skills. So what this is is pseudo. That's the little command that allows us to perform administrative tasks in most Linux's.

1:37When we were dealing with Amazon Linux, we used a command called YUM. That was the package manager for Amazon Linux. That's because it was based on a red hat, RPM style distribution. So you don't really have to know that. The two big flavors we're talking about here is did it come off the red hat tree or did it come off the Debian tree and Ubuntu came off the Debian tree. And so it uses apt apt to do its software package management.

2:08So apt update and this little dash Y is just going to go ahead and say yes. Because if I didn't include that there, it would prompt me to have to enter yes . Do I want to continue? So this little ampersand here says do this command and then after that do this command. So this command right here looks similar, but this one says update. This one says upgrade. So this is going to update the software library such that it matches the repository out there on the public internet and then upgrade is going to upgrade any packages that may need to be upgraded or patched.

2:44So there it's going to install. Let's see. It doesn't look like there's anything that we need to install. There are some extra packages out here and just because I like to clean things up, I'm going to get rid of those extra packages. pseudo apt auto remove. Yep, get rid of all those things. I think I know why they got installed because I was trying something else out on the same box, but we don't need them for our purposes. So next we are ready to install Podman. What's that Podman? Well, Podman is a container software much like Docker.

3:18And yes, I said the Docker is one of the most popular container softwares out there. It is, but Podman is an alternative and it creates OCI compliant containers just the same as Docker does. And we can use Podman to run Docker containers and Docker to run Podman containers. So Podman is just another software. It's often pre installed and like sent OS, I think it may be red hat, but let's go ahead and install it here. So pseudo apt install Podman and it's going to want to install some other dependencies here.

3:52I'm going to click yes and there it goes. All right. So it is installed. I'm going to issue a clear command that's going to clear my screen here and move my cursor back up to the top. Just like every beginner learning programming or something like that, it is customary for us to do a hello world type project, whereas the mission is to print out hello world. If we're working on learning a programming language or something like that. So we are going to do the same. So here we go.

4:22Podman run. Quay.io Podman hello. So what does this command say? So Podman is the command that we're going to be issuing. That's our container software. Run says, Hey, run this thing. And this right here, Quay.io is the repository. That's where this image, this container image lives. So we're saying go out to this address, go to the subdirectory and download this image right here.

4:55There's an image called hello. Now as soon as I hit enter, it's going to be very quick to download that because this is a very tiny image, but then it's going to give us some nice little, I don't know what these are moles or something. Hello, Podman world and it gives us some URLs and stuff like that down here. So that's really all that particular container does. It just is hello world. But hey, congratulations, you just ran your first container. Okay. So let's go do something a little bit more substantial. So now let's install engine X.

5:27That is a well known web server in the past. We've been installing Apache, which is fine. Engine X tends to be more performant, more designed for commercial performance use. And so we're going to be installing that container. So to do that, we need to do pseudo podcast podcast, Podman, not Podmon, Podman . So why are we saying pseudo? Because if you noticed when we did the hello world, we didn't have to do pseudo there.

5:57Well, the reason we're having to kind of switch over into administrator access is because this particular image and the container interacts with our network. It touches parts of the system that are outside its tiny little container environment. So we're going to map parts of this container to this virtual machine such that we can accept web requests inbound. Okay. So let's take a look at this full command here.

6:27Podman run dash D. That's going to say detach. If we didn't have this in here, it would keep running and we would see the logs of the engine X process. And that could be kind of cool, but we don't really need to do that. So I'm just going to issue a D detach. So it's going to kind of spin it off in the background. Here's a name. Here's where it's mapping the ports. So it's saying, Hey, on the host port, I want 80 to map to my container port 80 . And here is the repository.

6:58Here's the registry. And here is the image that it's going to pull down. Now, when I hit enter here, it's going to take a little bit longer than that other little hello world thing because it's going to download its parts and pieces. Okay. So there it was pretty quick though, but you can see it is downloading some parts and pieces required for that particular container. It was definitely more than that hello world, but really it wasn't that much at all. So it gives us this big old long number here. This is the container ID.

7:29And because I said dash D here, it just kind of dropped us back off at the command parameter here, command line interface here. And so how do we know if it's running? Well, we'll do a pseudo Podman PS. That's going to give us the processes that are running. And so there it is. Here's its name. You can see it's kind of a truncated version of this up here. Here's the image. Here's the command. This is the command that was inside the image that when the container software said, Hey, it's time for you to run.

8:00What do you want to do? Hey, run this command here. And that just starts up the engine X web server. It was created 28 seconds ago. And here are ports that are mapping in our container from the container to the outer VM. And it's going to accept traffic from anywhere. So let's give it a shot. Let's run curl local host. And there we go. So this is our web page that's being served up by our engine X container. All right, let's say we want to stop that container.

8:33Pseudo Podman stop. And then we have to give it part of this little name here. We can usually just get by with giving it the first three here, B88. So if go down here, B88. And then it will have stopped that and we'll check here. And you can see there are no more containers running. Let's take a look at the image of that particular container. So I can use that command Podman images. And this is the image that was downloaded from that repository here.

9:04And it was created five weeks ago or less updated five weeks ago. This is the latest version of that. And look at the size, 197 megabytes. That's really nothing. Now compare that to our virtual machine here. If I do df dash h. So this root volume that we're using here, it's bigger than this. I think it's eight gig altogether, but it's kind of partitioned in different things here. But if we were to install our web browser or if we are into install our web server on here, then this would go up slightly.

9:38But you can see it's still 2.6 gig. So if we trim this system down, this virtual machine down to bare minimum, it would probably be about three gig as compared to doing the same task as if we were to load in Genex or Apache on this virtual machine, we can do that same task in a size of 197 meg abytes. So that is one of the benefits of containers and we can shuffle them around much, much easier than we can virtual machines.

10:09So that is some pretty low level work using Podman in this case. Let's go explore some of the cloud services that the cloud providers provide to us to run these containers.

0:00All right, let me take a few minutes to explain what project we are going to build here. So if you recall in our last project, we created some instances here, some EC2 instances, and we put them behind a load balancer, and we put them in a target group, we even did this through an auto scaling group as well. And we could very easily do the same exact thing. We could create containers that have web servers, and we could deploy them in our target group. And yes, there's auto scaling with those as well.

0:30We would be using a service called Elastic Container Service that would prevent us from having to go and issue all those Docker commands or those Podman commands that we issued. It's just going to manage things for us. And yes, we can absolutely do this. But that's kind of boring. What we want to do is we want to see if it will quake. Yes, that quake. So what I'm going to do is be deploying a container with an image that is supposedly a version of quake that we can play via our browser.

1:01So we're going to find out if containers can quake, we're going to do it on AWS . And then we're going to do the same thing on GCP, because as I mentioned, Google was one of the OGs. When it comes to containers, they contributed a lot of open source to the effort. Kubernetes was one of their projects. So I wanted to show GCP, some love plus it's good to go into another cloud provider and basically see how that cloud provider is similar and is different to some of the other cloud providers that we've already explored.

1:33Now before we get into ECS, I wanted to kind of draw some similarities between these two here. We have EC two and ECS when we were dealing with EC two, we had AMIs that was an image. Well, for ECS, they call it an image. So same, same there. Then we have the AMI catalog that was that catalog that we can choose from, either our own images or images that other people had created. Same thing is called a registry and ECS or that's kind of container speak for this type of similar AMI catalog here.

2:08Then we had the launch template that kind of defined, okay, when it was time to launch a new instance, here's kind of the pre populated information that I want you to use. So I don't have to enter that all the time. Well, we have a task definition over here on ECS that is kind of equivalent to this right here. And then we have the instance that was our EC two instance and ECS calls that a service. So we will be defining a task definition and we will say, hey, for this service , use that task definition, pull the image from the registry.

2:44And that's kind of the similar thing that we did over here. but it's just slightly different terminology. So let's go.

0:00All right, here we are back out at the AWS console. We want to go into Elastic Cloud Service, so ECS. Click on that right there. And there we go. So we're just gonna click on getting started and that's gonna drop us off onto this little page right here. So let's create a cluster. Well, a cluster is what's going to actually run our containers. So let's go ahead and click on Create Cluster, Frequent Zebra. I could not have come up with a more creative name, I think.

0:30So I'm just gonna leave that there. We're gonna call this cluster Frequent Zebra. And we are going to use AWS Fargate. It says serverless, but it's not really serverless. There's servers behind it. The difference here is that if we had EC2 instances that we wanted to manage ourselves, then we can deploy this cluster onto those EC2 instances. But if we didn't want to have to fuss with EC2 instances, then we can just use Fargate and AWS is gonna handle everything for us behind the scenes.

1:00And that is all right by me. So I'm gonna leave that there. Gonna keep scrolling down here. There's nothing here I need to change. So I'm gonna click on Create. And hopefully this is going to properly create. Just a word of caution here. About 50% of the time when I've gone into other accounts and tried for the first time to create an elastic container service cluster, I've gotten a big old fat red error message up here. And I believe the reason for that is because whenever we try to create something in AWS, things kind of spider out and create in parallel.

1:34And I think some things get finished faster than others. And sometimes some dependencies are left undone because they're not really synced up as to how they get created. So it gives me a big error there. All I do is go in and create another cluster. And then after that one error is done, then I seem to be able to create them pretty easily. As a matter of fact, on this account here, I'd come in here earlier today and created a cluster. And I got that same red error message. So we're just gonna keep on rolling here.

2:04If you do get that error message, just say, okay, and then create a cluster, then just do the exact same thing again, and it should work. So frequent zebra, this is our cluster. Now we have to define a task definition. So let's go over here. This is kind of analogous to the launch template. So I'm gonna click on create new task definition. Let's get rid of that right there. And we are gonna call this quake. And launch type is fargate, yep. That architecture is fine. These defaults are fine. Keep on scrolling down.

2:35Now we get to the container. It's asking us for the details of our container. So I'm gonna call this quake. And the URL that I'm going to be using or the location of the repository is this right here. It's Trey Yoder/QuakeJS colon latest. And I'll include this in the paragraph below this video if you wanna just copy and paste it. And this is not a private registry. This is a public registry. And we're asked for some port mappings.

3:07These are the mappings from the container or from the kind of outside the host into the container. Now we want port 80 because that's how we're going to visit this site. But we also wanna add another port. And that port is 27960. Now this is very specific to this container. I believe that that port is the port that multiplayer is communicating with behind the scenes when we're dealing with quake on port 80 here. So in my experience, you can't really start the game unless you have also exposed this port as well, which we will do.

3:44Scrolling down, I'm gonna keep all this stuff there. So keep all this stuff there, keep all the logs, keep on scrolling, keep on scrolling. All this stuff looks good I'm going to create. So I am creating our task definition and it appears to me that it created properly. All right. So now we can go back over here to namespace, oops not namespace clusters. Now we'll go into clusters. And here's our cluster. Now we have services and tasks.

4:15Whenever we create a service, there probably gonna be a task out here to actually build that container and deploy it. The difference here is tasks are kind of those things that if you want a container to come up, do some sort of activity and then go away, then that's a task. If you want a service, that's gonna come up and stay up until you intentionally shut it down. So you can have containers, do either one of these and containers are really useful in doing tasks because maybe have something relatively complex and you need to do a lot of processing.

4:49You can have that container spin up, do that thing and then go away. So let's go over to here to services and we are going to create a service. So I'm gonna choose Quake and it's gonna identify the fact that, hey we have a task definition revision. Well, it says two, that's fine. I think it's because I had created a task by that name earlier today, but I deleted it. So I'm just gonna keep on scrolling down here. Capacity provider strategy, that's fine. All this stuff is fine.

5:19We're gonna leave that alone. And we're gonna go to networking. Now this is kind of important because we want to be able to reach our instance. And if we don't have the right security group and the right subnet set up, then that's going to be very difficult. So I'm gonna choose our good old VPC, cloud plus VPC, has the two subnets. I don't really care which subnet receives this container. And as far as security groups, I am going to choose, yeah, I'll create a new security group. We'll just keep this separate here.

5:50So we're gonna create a new security group. I'm gonna give this my SG Quake. That'll just save me from navigating over to the VPC to create a new one. And we're gonna do HTTP port 80. The source is anywhere. And we're gonna add a rule HTTP. We're gonna do custom. And the port is 27960 from anywhere. And public IP, yes, we want a public IP.

6:21So I think that looks good. Yep, okay, gonna keep on going down here. There's load balancing. If we wanted to, we could spin up a load balancer and stuff these containers into that load balancer instead of our instances. Gonna hit create here. Now, what it's going to do is it's gonna start the deployment process for that service. So if I scroll down here and hit refresh, eventually our service is gonna show up. There it is. So the service has showed up, but if we go over here to tasks, generally speaking, whenever you launch a service, there's going to be a task to actually build the container.

7:01So eventually we're going to get a task show up there. There we go. And it says provisioning. So it's running. It's a desired status is running. It's provisioning right now. So this is building that container and deploying that container onto our Fargate resources. So this is probably gonna take maybe a minute or two. What we're looking for here is the last status is gonna be ready or running. That's what we wanna see. And I'm just gonna pause the video until that happens. No sooner that I paused the video did it turn into a running status.

7:35Go back over here to our service. There's our service there. So now our container should be available for us. I think it's available. Let's drill into the task here. And we are gonna go to network bindings. So if we look down here, we have our network bindings here and we have our external link. So there's our two ports right there. I'm gonna copy that one right there. Go up here to open a new tab, paste. See what we get. Ha ha.

8:06All right. So some license agreement here. I agree and it's loading. Loading. Oh, look at that. I don't know if you can hear the audio here. Nope, that's not me. That's the game. Yeah. Yeah. Woo hoo. All right. Well, I will say it is kind of boring because there's nobody else here. So, but we can say that containers on ECS will quake.

8:40All right. Enough of this. Let's shut this down. I'll show you how to kind of disassemble this and get out of here. Close that down. Let's go over here to task definitions. We're gonna click on that. Click on that. D register. There we go. Then we're gonna go up here to the cluster.

9:10Click on that. Delete cluster. We have to confirm it here. And in a little bit, it's going to shut our cluster down. All right. Clues. And there was an error deploying it. Yeah, because we shut it down before it got deployed. So we have no clusters right there and task definitions. This is gonna go away. There we go. Okay. So we're back to normal on ECS. Now let's try to do the same thing over on GCP.

0:00Alright, so here we are in GCP. You can see it kind of looks similar to the other cloud providers. And there's this little hamburger over here that you can click on. Now if you want to create a GCP account and play around, I highly recommend that. The more clouds that you can kind of sample, the better you're going to have an idea about how just general cloud stuff works. But they have this little hamburger over here. I'm going to scroll down here and I'm going to go to Kubernetes Engine and click on that. And we're going to go out to Overview.

0:31So this is going to give us an overview of anything we have set up. But we don't have anything set up. I'm going to go to Clusters. Very similar terminology here. Create a cluster. And we'll just call this Quake. That's all we're going to be running on here. And Standard tier is fine. Click on Create. Alright, so it's going to take a little bit of time. Actually, I think it's already set up. It is being created. Okay. So we need to give it a little bit of time until it's finished setting up.

1:04And then we can start working on our workload. So I'm going to just pause the video until that happens. Alright, at long last, our cluster is up and running. That took probably all of 10 minutes to do. So we have a little green check there. Next, we're going to go over to Workloads. And this is where we can define our service or what was the equivalent of the service in AWS. And we're going to call this deployment Quake. And scroll down here. We want to put it on the Quake cluster, container details. And it's asking us for what is the existing container image or maybe a new image.

1:38So let me grab that, paste this in here. There we go. And keep going down here. Next we want to go to Expose. Do we want to expose this as a new service? Yes, we do. Report map 80, target port 80. TCP, we're going to add a port mapping there. Port is 27, 960. Target is 27, 960. There we go. And we have our option of what we want to put in front of this.

2:09We're just going to use a load balancer because, yeah, why not deploy. And it's in the process of deploying our workload. So now all we have to do is wait until this deployed deploys. And if we did everything right, we'll find a public IP address and we should be able to get our Quake on. I'm going to pause it for the moment and then resume whenever it looks like it 's up and running. All right, as soon as it was done deploying, it brought me to this screen right here, which is kind of like an overview for this service.

2:41If I scroll all the way down here, so let me tell you what these things are, managed pods. Kind of like the resources that are used to run this container. I'm going to come down here. There's our Quake service. There's our little endpoint IP address there. I'm going to click on that. There, I got my little agreement. Click on agree. And if we did everything right, we should be quaking in no time at all. All right, there we go.

3:11Yeah. Oh, yeah. Get some, get some. All right. Enough of that. This is not really fun just wandering around an empty dungeon. But anyway, we have proven the point. This does Quake. Our containers do Quake. So let's back out of this. All right. So here we are. It gives us some CPU's memory, some disk, but let's tear it back down.

3:42All right. So Quake delete. Get rid of that. All right. So that's going to terminate all the resources involved there. And I believe I can go back over here. Once that's done deleting enough, click on that and click on delete as well. Quake. So you can see there's a lot of similarities between the platforms, at least with regard to these particular services. If you want to go out to Azure and try it out there as well. Yeah. I welcome that.

4:12I don't really see a need to do that a third time on that platform as well. But I did want to give GCP some love because after AWS, GCP was my second cloud certification. So I really like GCP and it has a lot of cool things that it can do a little bit better than some of the other cloud providers. So that is, will it Quake on AWS? The answer is yes. Will it Quake on GCP? The answer is yes.

0:00Alright, let's take a look at these questions. First question, a cloud administrator needs to deploy a web application that requires specific libraries and not included in the host OS. Why would a container be an effective solution for this deployment? Alright, let's start up here. Containers require the libraries to be installed on the host OS system. Well, no, that's not correct at all. Containers are their own container. They contain all the stuff. So they don't require anything to be installed on the host OS other than the container software itself. Next option for us containers can modify the host OS to include the required libraries. Well, no, because this would really be a security issue if this was allowed to happen.

0:48Containers cannot just modify the host OS to install new software. We're not going to allow that and we wouldn't want our containers to do that either. So I can definitely eliminate that one. Next option containers automatically upgrade the host OS to support the libraries. Well, again, this is kind of the same thing as that. So we can get rid of that one there. And we're going to get rid of that one by process of elimination. This is probably it. But let's just make sure containers isolate the application and its libraries from the host OS. Well, yes, that is exactly kind of the business case for why containers are useful is because they package everything they need in a nice neat little portable container that we can send to multiple places pretty easily. So that is my final answer. I'm sticking to it. All right, next question, why might a legacy application struggle to run in a containerized environment compared to a virtual machine?

1:46Let's start at the top here. Containers lack support for network connectivity. No, that is not correct at all. We can draw a line through that because that is not true. Containers cannot isolate applications from the host. Well, no, containers can isolate applications from the host. So that is not a factual statement unto itself. So we know that cannot be a reason why a legacy application might struggle to run in a containerized environment. Containers require more hardware resources than virtual machines. Well, no, that is not true. Actually, containers are more lightweight, and they would require less resources compared to the same application loaded on a virtual machine.

2:29So we can even eliminate that one. Look at us, we only have one left. Cont ainers rely on the host OS limiting OS customization. Well, yes, that is true about containers. And that is one of the reasons why legacy applications may really struggle to run in a containerized environment, because sometimes those legacy applications need to modify and do things to the underlying OS. So that is a good reason why a legacy application might struggle in a containerized environment. So that's my final answer. Last question, a company is migrating a multi tier application to a containerized environment in the cloud, which of the following is not recommended to ensure successful deployment and operation across multiple cloud providers.

3:21So this is the key here, because if you kind of skimmed over this, and you didn't pay attention to this not here, then you may be going through here saying, Hey, some of these are valid answers . Multiple of these are valid answers. Why am I supposed to pick just one? Well, no, we're being asked, which is not? Let's start up top here, use a standardized container format to ensure portability. Yes, that is a best practice. That's something that I would recommend people to do is to use a standardized container format. You certainly don't want to try to invent your own container format or use a proprietary one. Next option store container images in a registry with version control. Yes, that is something that is beneficial as well, especially when we have multiple versions of the same container, we want to be sure that we're using the latest and greatest or whatever version we need. Implement a container orchestration tool to manage load balancing and fail over.

4:20Well, yes, yes, if we have a bunch of containers, we certainly don't want to be going out there and using the command line interface to issue Docker commands or podman commands, we would want some sort of infrastructure, some sort of tool to help us manage those. And we call that 90 orchestration. So yes, that is something I definitely want. Last option here, install a full operating system in each container for compatibility. No, we would not want to do that because that kind of defeats the purpose of having a lightweight container. So of all these options here, this is the one that sounds most bananas. And I'm going to pick that one because that was would be something I would not recommend somebody do. And that is my final answer. I hope this has been formed before you and I'd like to thank you for viewing.