Amazon AWS DevOps Engineer Professional – Configuration Management and Infrastructure Part 10
So, for the first lecture, just a quick overview of Docker. Now, if you know Docker, you can skip this. And if you don’t know Docker, I would tell you that it is a huge topic. I’ll try to make this very simple for you. You’re not going to be a Docker expert at the end of this lecture, but you will know how Docker works and what it is about, which is all that is needed for the AWS Certified Developer Exam. So what is Docker? Well, Docker is a software development platform that is basically used to deploy apps. It’s also revolutionary. Why? because we package apps in something called a container. So you may have heard of the term “docker container.”
And these containers are very special because they can be run on any OS. As a result, Linux, Mac, and Windows all operate in the same manner. And because they run the exact same way, it allows you to do a lot of things. It allows you to run any application on any machine. There won’t be any compatibility issues; their behavior will be predictable; there will be no surprises. You need to do less work. And then, when you want to maintain your software and deploy it, it is easier because it is standardized.
So it works with any language, any system, and any technology. That may seem like something a bit miraculous and stuff, but it’s really, really smart technology, and there’s a lot of complicated engineering behind how it works. However, for end users, we primarily consider: “How do I create a Docker container from my app?” And then, you know, it will be able to run anywhere, which I think is really, really awesome.
So, some magic here, but we’ll get into the details to see how it works. So what does that mean? That means that if we have an operating system, for example, an EC2 instance running Linux, we’ll be able to deploy a Docker container on it. For example, this one runs Java, but maybe we’ll be able to run another Docker container on it. Maybe this one is Nodes. And maybe we can even run a SQL database in my SQL database. All of these containers can communicate with one another via a wireless network. So maybe our Java application can rely on our MySQL container. But the really cool thing here is that even though they run on the same machine, they don’t interact with each other unless we tell them to, and they don’t impact each other.
So if one application is going crazy, the other ones won’t be impacted. And on top of it, because they run on the same server, you can scale them. So we can definitely have more Java containers. So maybe when we need to scale, we’ll have another Java container from Docker, and there’ll be another Docker container again on Java. So after three times the same container, maybe when we need to scale down, it’ll go away, and then you’ll go back again. And then maybe we also need to scale our Node JS application. So this is what Docker is in JS. Basically, it doesn’t matter if it’s a Java node or MySQL. The idea is that from the server’s perspective, what it does is just run and remove Docker containers. So now these Docker images are stored where they are. So basically, when you create a Docker image, this is what’s going to be run on a machine. So Docker images will be stored in Docker repositories. And so there are two very famous repositories. There’s a Docker hub at this address. And we can basically find images from various technologies or operating systems in there. So we can find an Ubuntu MySQL node. JS is Java.
I mean, you can find anything. And then there are some private Docker repositories. So this is where you would store your personal images. and one of these is Amazon ECR. ECR stands for “elastic container registry.” And for the exam, you should be familiar with ECR. So if we do a quick tour on the DockerHub, for example, if we look for MySQL, we can find that there are a lot of MySQL images. We can run the MySQL server edition. Mariodb I mean, we can find pretty much anything. We can type Ubuntu and we’ll find one; we can type NodeJS and we’ll find something; we can type Java. I mean, have fun typing anything in there.
You will find Docker images for pretty much anything, including Amazon stuff. So if we type “DynamoDB,” I’m pretty sure there is a DynamoDB image. Here we go. We can download a DynamoDB image and have DynamoDB running on our local computer. So overall, Docker Hub has a lot of images, and all of these are public. We can download these images. So this is what I want to show you. So one question you may be asking yourself is, “Okay, what’s the difference between Ducker and a virtual machine?” Because they kind of do the same thing, right? So yes, Ducker is sort of a virtualization technology, but not exactly, and I won’t get into the details of that statement, but basically, with Ducker, all the resources are virtualized. So the RAM CPU network is shared with the host. That means you can run many, many containers on one server—maybe hundreds of them.
Okay, if you have a big machine. So, for example, in the VM case, there is a distinction. We have the infrastructure, so that’s your actual hardware. Then we have the host OS, and then we have something called the hypervisor. And so this is basically how Easy Two is built. There’s a big, giant server in Amazon’s virtual Amazon Data Center. And they have a host OS, and they run the hypervisor on it. And then, when you request an EC2 instance, you basically get your guest OS and an app you can run on it.
And then if someone else requests EC2, there’s another guest OS, for example, another Linux version, Amazon Linux, and then there’s an app running on it, and likewise for a third guest OS. Right? Because there is a hypervisor, these guest OS are very well logically separated. They can’t interact with each other; there’s strong security. I mean, it’s crazy. But as you can see, there are a lot of stacks. And then, if on these guest OSes we wanted to run more VMs, we’d have to run another hypervisor and run more VMs, so it can stack up very quickly. So what’s the difference with Docker? Well, for Docker, you have your infrastructure, the host OS, and maybe your EC2 instance, and there’s no hypervisor.
There’s something called a Docker daemon, which you have to install. However, once a Docker daemon is installed, you can simply run containers, containers for whatever technology you want, a second container, a third container. And because it’s so lightweight and because it’s so well made, you can run a lot of containers—a lot more containers than VMs—on your machines and your host OS. So that’s a short, high-level overview of why Docker is a bit more lean than hypervisors. They all have their advantages and disadvantages, but I just wanted to illustrate the differences at a high level. Now, how do we get started with Docker?
We have to do a little bit of Docker in this section, so we can download Docker at this URL. So let’s go check it out. So to instal Docker, very simply, you go to the website, you scroll down, and for me, there is a Docker for developers, and you can say Docker for Mac, Docker for Windows. So you choose whichever version you need. And also for Docker for Linux instructions, you can just Google it; it will basically instal something, and then you’ll be ready for this lab. I won’t show you how it works. It’s very simple.
You press the Next, Next, Next, Next buttons. But you need to instal Docker if you want to go ahead with a hands-on in this section at some points. And then once we have Docker installed, what we can do is create something called a Docker file. And it’s just going to describe how to build a Docker image. It’s actually really simple. We’ll have a look at one; you don’t need to know how to write them, don’t worry. For this section, we’ll build them, and from building them, we’ll have ducker images. And then when we run these Docker images, that will make Docker containers.
And so these Docker images that we have, we also need to store them somewhere so we can push them. And where can we push them? where we can push them to DockerHub, the website I showed you before. So this is if you want to make your images public. And also, you can push them to Amazon ECR if you want to keep your images private. And so once they’re stored, Once they’re pushed, guess what? We can also pull them.
So if we wanted to use an image from Docker Hub or Amazon ECR, we would pull it, and then we’d have a Docker image, and then we could run that Docker image as a container. So if you understand Bill, push, pull, and run. We’re basically all set with all the little terms you need to know for this section. Now, Docker containers also need to be managed so we can run them. But it’s really good if there’s an infrastructure to manage them. And so it’s a container management platform. And there are three choices for this.
On the AWS cloud, there is ECS, which is Amazon’s own platform. That’s what we’re going to learn in this section. There is Fargate, and it’s also Amazon’s own platform, but this time it’s serverless. We’ll see the difference in practice. And then there’s EKS, which is out of scope for this section because it’s not in the exam yet. and it’s basically Amazon’s managed Kubernetes platform. And Kubernetes is a very popular container management system. It’s open source, and it’s sort of becoming the standard right now. But ECS and Fargate are still very good. Okay, so that’s it for the introduction to Docker. I hope that gives you a better idea of what Docker is. I know it’s still very confusing because we haven’t used it, but don’t worry, it’s coming in this section. I hope you liked it, and I will see you in the next lecture. Bye.
Okay, so now let’s get started with ECS. We’re going to talk about ECS clusters. So, what exactly are ECS clusters? They are logical groupsings of EC2 instances on which we will run services and tasks. But right now, just see them as a grouping of two easy instances. So the two EC2 instances we’re going to launch will run something called the ECS agents, and the ECS agent is just a Docker container. The ECS agents will then register our EC2 instance with the ECS cluster, and that’s basically how it works. The EC has two instances, though they’re a little bit special.
They don’t run the plain Amazon Linux 2 AMI. They run the special ECS AMI. and I’ll show you this in a second. So we have our EC2 instance running an ECS Docker agent, which will register our instance into the ECS cluster. Very simple. Let’s go hands-on. First things first, let’s type ECS within the Find Services window, and we are taken straight into ECS.
So there is a little bit of a video you should watch if you want to know how ECS works. But don’t worry, we’re going to get started together. So if you click on “Get Started,” which you shouldn’t do, then it says to start with ECS using Fargate. Now, Fargate is going to come at the end of this section. Right now we’re not going to do Fargate because it’s a little bit too recent. The exam just asks a minor question about Fargate. So, for the time being, we will scroll down and cancel this. We’re not going to go and click on “Get Started.” So, actually, if you click on clusters on the left hand side, you get a Create Cluster and Get Started option. So now we’ll go ahead and click on Create Cluster. So as you can see, there’s a cluster of templates. The networking only powered by AWS Far gates is the one they read for us to use. Again, they’re trying to push us to use Fargate. Fargate is really awesome.
But for now, we’re not going to use Fargate. Just at the end of this section, we’re going to go on to EC, to Linux Plus Networking, so that we can start with the ECS the good old way, as we’ve been doing it for the past two or three years. So basically, in this template, we’re going to create a cluster and optionally a VPC subnets, but we won’t do that.
Then there’s an auto-scaling group with Linux. MI expertise. So let’s click on “next step.” And now we’re going to type a cluster name. So I’ll name it Cluster Demo. We could just finish it and create an empty cluster. But we want to create a cluster that’s going to become easier with two instances to go a little bit faster. So the provisioning model is on-demand instances. So we’re going to create an ASG, and we’ll have on-demand instances. But if you wanted to save costs in your huge workload, you could use spot instances. So we click on “on demand,” and for the instant type, I will scroll all the way down and use a T-2 micro because there will be enough and that will be within the free tier. Now the number of instances that we want is going to be one.
We’ll just start with one instance. Maybe we’ll scale later. But one is fine right now. And the EC-2 AMI.ID is actually the ECS AMI. So this ID, as you can see right here, is Amazon ECS Optimized. So it comes pre-installed with Docker, which saves us some time and effort in the setup process. So we’ll use this. Amazon ECS-optimised AMI IDs Storage would leave it at 22 GB and then create a key pair. You should just create one or use one that you already have.
I’m going to use my AWS course key pair. Excellent. Now for networking, we’re not going to create a VPC. We’re just going to reuse the VPC we already have. So I’m going to use my default VPC. 172, 310, 00:16, and we’re ready. Now, for subnets, we can select the subnets that we want. So I’m going to choose three subnets because I want my ASG to be available in three subnets. So here we go. I’ve selected my three security groups here. We’re just going to create a new security group, and for now, what I will allow is just any IP on port 22, just so I can SSH. We’ll see how things work later on, and we’ll modify the security group. Obviously, for the container instance’s IAM role, it basically needs to be provisioned. An IAM role such as the EC2 instance can register with ECS.
So we’ll create a new role, and this will create something called the ECS instance role that comes with its own policy. Okay, tags. We don’t need to add them, and then we need to click on Creates. So this is going to provision the cluster. So what I will do is wait for everything to happen, and I will get back to you. The cluster has now launched. So I’m going to click on the view cluster to see what’s happening. So as we can see, there’s one register container instance available. And if I click on ECS instances on this third tab, you will see one container instance available. Now if you’re just getting started and go a little bit too quickly, maybe this won’t appear here. You need to wait two or three minutes, and then your ECS instance will appear here. So a lot of things happened, but if we go back to our clusters, just to take a step back, we’ve created a cluster demo, and it has one container instance, and within it we’re going to be able to run containers. Okay, so services, this is empty because we haven’t run any service task empty as well. We haven’t run any tasks. ECS instances are what’s important.
And then there are metric schedule task tags as well. We’re not going to look at it. They’re going to be empty. So this ECS instance that was created is linked to an EC2 instance. It’s in Azeus one B, and as you can see, the agent is linked to it. So that means that the ECS agent is working on this machine, and currently it’s running zero tasks. So let’s look at something. The agent version is 1.25.1, which indicates the Amazon ECS agent version, and the docker version is 18.6.1 CE, which indicates the docker version. Okay. Now there is this CPU available—124, 1024, and 985 of available memory. So this represents the number of vCPUs you have on your machine. On my T, I have one vCPU and two micro. For each vCPU, I’m going to have 1024 CPUs available. It’s just an abstract measure of it because we’re going to share that CPU resource between different containers. And for memory’s sake, it’s the same thing. I have one gig of RAM. A little bit of that RAM is already used by my agent. So I have 985 megabytes of RAM available to run containers on my machine.
Okay, so that’s for the cluster. Now let’s have a look at what happened on the EC-2 side, because I think it’s really important to understand how this machine came to be. So we’re going to the EC console, and in the bottom left, I’m going to scroll all the way down and click on auto-scaling groups. So when we created our ECS cluster, it came with an auto-scaling group. And this auto-scaling group is basically what has created our instance that has been in service. So if we click on that instance ID, we’re taken straight to the instance we’re going to use. Okay, so let’s have a look at the ASG first. The ASG is multi-AZ because we configured it so it has one of these area capacities. The Min is 0 and the Max is 1. So this is about it for now. And then it has created an instance that is healthy. And basically, if you want to scale the number of instances in our ECS cluster, we could just edit this and add more capacity to it. Okay, let’s go to the launch configuration now.
So this was another launch configuration created by ECS for us, and it is a bit special. So there is an amiid, which is the ECS amiid. The instance profile is the ECS instance role. So that was created for us by ECS as well, which has the correct IAM permissions. The key name is “course.” That’s from my SSH. And the user data is doing a little bit of everything. It’s echoing the ECS cluster equalscluster demo into this file. So basically, what that means is that our ECSconfig file right here etc ECS’s config file contains the variable ECS cluster equals cluster demo, and this is how, when our instance starts, it knows to register with the cluster named cluster demo. When we started, if you wanted to have multiple clusters, you would just change that a little bit right here. Okay, now monitoring is set to “block device,” “one volume,” and so on, so everything looks great. So now let’s have a look at the EC2 instance itself. So it is running; it’s a T-2 micro, and as you can see, there is a security group that was created for us. So if we click on that security group, we can look at the inbound roles, and currently we allow port 22 from anywhere, so it will allow us to SSH into that instance, and then if we look at the IAM role, if we click here, it’s an ECS instance role.
So I clicked on it, and I just want to see what the policy is. And the policy is Amazon EC2 Container Service for EC2 Roles, which is a managed policy. And basically, you can look at it. But it contains a lot of “allow” statements, basically to create an instance and register our instance with the container, et cetera, et cetera. So this is enough to get started and basically make sure that our EC2 instance has enough permissions to function. Okay, lastly, maybe we want to just SSH into our instance, so let’s do that. We’re going to go back to our instances. So auto-scaling group instances Here it is; I’m going to click on it, and I just want SSH onto it to show you what’s happening. So here is the public IP; I enter my SSH command, press Enter, and I’m in my machine. Okay, so as we can see, this is an Amazon ECS-optimised Linux. So this is ECS, and the first file I want you to look at is this etc. ECS config file. The important thing to remember here is that the ECS cluster is equal to cluster demo, and this is how our instance knows to register to the cluster name clusterdemo. So how does it register? Docker does it, and the Docker agent does it.
So for this, let’s type Docker PS, which means Docker processes, and we can see that one container is running; it’s running the image Amazon Amazon ECSagent, which comes straight from Docker Hub, by the way, and it’s running the command agent. It’s been up for eight minutes, and that agent is what is registering. Looking at this file right here, that’s what’s registering our instance into the ECS service. Lastly, you can do something really cool, but it’s not needed just to show you cool command Docker logs, and then we can just copy and paste this container ID, press Enter, and it will show us exactly the logs of the ECS agent of what happened. So we can see it started, we can look at the version, and then it tells you everything that happened. It’s also worth noting that it says “registering instance with ECS remaining memory 985,” followed by “registering container instance successfully with cluster.” So very good. That’s all we need to know here. But overall, it’s quite helpful to just have a look at how the EC2 instance works, and we’ll be starting to launch some containers on that instance. So keep that SSH session open. Okay? I will see you at the next lecture.
Okay, so next we are going to look at ECS task definitions. So what is a task definition? Well, it’s basically a definition. It’s metadata. Okay. And it’s in JSON form. So it’s a JSON document, and it will tell ECS how to run a Docker container. So it won’t run it, but it will tell you how to. And it’s a definition in JSON form. Okay, so what is included in a task definition? Well, there’s some crucial information in it, such as the image name, the port binding for the container, and the host. I’ll show you what it means in a second. the memory and CPU that are required, the environment variables, networking information, and so on. There’s a lot of information you can include in there.
So let’s have a look at our EC2 instance. Right now, it’s running the ECS agent. So I’m just putting it there for information. And we’re going to run a Httpd. It’s an Apache server in a Docker container, and we’ll pull that from Docker Hub. And so the important thing is that Docker images are created such that inside the container, the port number represents the Apache server. However, on our host, we’ll map it to a host port of at, which is just an arbitrary number. Okay, so basically, why do we do this? Well, when some traffic comes from the internet into our EC2 instance on port 80, then automatically Docker is really smart and we’ll map that port 80 to port 80 within our Apache container and be directly talking to Apache. Okay, enough theory. Let’s go to practice. Okay, so let’s go back to ECS. And in ECS, we have a cluster. In one instance, we’re going to create a task definition. So on the left hand side, I’m going to click on “task definition” and “create a new task definition.” And here we go again. We ask whether or not we want Fargate or Easy Two. We’ll use EC 2 for now; Fargate will come a little bit later. Okay, next step: the task designation name. I’ll call it my http, okay? And this is just whatever you want it to be; compatibility is EC 2.
This is because we chose EC 2 so that we could be Fargate as well. And the task role is an optional IAM role that tasks can use. So it’s really important that the task that we assign have an IAM role, and that’s a question they will ask you at the exam. If a task cannot do anything, it cannot pull an image from the ECR, talk to spray, or whatever. If a container can’t do this well, it’s because it’s missing a task role. so we could assign a role. There are none right now because we need to create a task role and don’t have one. But just so you know, the option is here and it’s really important. Network mode, choose default, leave it as default, and this will basically be Bridge on Linux and not on Windows. So leave it as a default. This is how you get better compatibility. The task execution role is basically a task role that is created to allow ECS to basically create that task. So we’ll just leave this as is; it’s just information, and here we get to choose the task memory and CPU. So, if you remember when we went into ECS, let’s quickly go back into ECS and look at our ECS instance in a cluster demo.
The T2 microprocessor in this EC2 instance has 1024 CPUs and 985 MB of available memory. So, when we get to the bottom, we’ll save some of that memory. So maybe we want to reserve 300 megabytes of memory for CPU 250. And this is arbitrary; don’t worry about how we choose it right now. It’s just for the sake of the example. The exam will not ask you about it. So just trust me on this, okay? Okay, so this is how much memory and RAM will be assigned to our task. Then we’re going to add a container definition. So I’ll click on “add container,” and this is the container we want to run. So it’s going to be HTTP. And now we have to choose the image. So let’s go to Docker Hub one more time, because we’re going to pull this from Docker Hub for now. And I’ll just type httpd. As we can see, this is the Apache HTTP server project, and this is the image we’re going to use. So there are a bunch of tags and a Docker file we can use. But the idea is that the name is HTTPD, and if we look at tags, we’re going to use a tag such as 2.4 right here. This is a good tag to keep things stable. So let’s go back to ECS, and we’re going to say image is HTTP.
The tag goes after the two columns, and we’re saying 2.4 now, this is enough. And basically, Docker knows that whenever you specify an image like this, the image name and the tag indicate that it comes directly from the Docker Hub. Okay, we’re not going to take this line and then the memory; we’re going to add a hard limit. So we’ll choose 300. We’ll do the exact same thing, and we could add a soft limit if we wanted to, but I won’t need it. Okay, now port mapping is really important. If you recall, this is where we map the port of the container to the port of the host using a diagram. So on the host, we said port 80.80; that’s where the traffic is going to go through. And for the container itself, well, if we look at the Docker Hub, what does it say in the description? If we scroll down, basically, you’ll see that here. Port 80 is what’s being exposed within the container. So basically, we’re going to map port 80 to port 80 within the container. So let’s do this. Right now, we’re going to go back to ECS and the container portal.
Choose port 80. Okay, if you’re a bit lost, don’t worry; just keep on going. Now, for advanced container configuration, we won’t do anything. And we will not do anything to help the environment. We don’t need all these things and network settings. There’s a really advanced tool, but all that you can see here is that there are a lot of options in here to basically configure your test definition the way you want. Okay, click on Add, and here we go. We have HTTPD running from this image, which has 300 RAM. And we didn’t even need to specify the CPU units in this. Okay, this is enough. Now we could basically add volumes if we wanted to map some EBS volumes. But for now, we’re not going to do this. And we’re good. Now we click on Create, and our first task definition has been created. As we can see, it’s called my HTTPD, and the tag is 1. So it’s the first version of this task definition. If we scroll down, we get basically a UI of everything that happened. And if we go to JSON, we get the JSON form of this task definition. So the important thing to note here is that in port mapping, we map the host port of HTTP to the container port of AT, and then the memory is 300. That sort of thing in the image is HTTP/2, 4 Okay, that’s enough. So we have created a task definition, but now we’re going to need to run this task definition. and I will do this in the next lecture.
Popular posts
Recent Posts