Amazon AWS DevOps Engineer Professional – Configuration Management and Infrastructure Part 11

58. ECS Service

All right, so now we’re going to run our task, and for this, we’re going to define an ECS service that will basically define how many tasks should run and how they should be run, and the ECS service will ensure that the number of desired tasks is always running consistently across our fleet of EC. There are two instances that will also help us when we do updates to our task. So, because ECS services can be linked to an ELB, LB, and ALB, load balancers are essentially required if needed, as we will see in practice. So let’s have our first service. Okay, so in our case, we’re going to go back to our cluster and we’re going to click on Cluster demo, and in there, we’re going to create a service. So a service gets created at the level of a cluster. So we’ll create a service, and the launch type is going to be “easy,” the task definition is going to be “Httpd,” which comes from the task definition we just created, and the revision is one that is the latest. The cluster we assign this to is Cluster Demo, and their service name is HTTPD. I’ll just call it Httpd service.

Now the type of service we’re going to run is replica, and replica means that we’re going to run as many tasks as possible. So if I say five, it’s going to try to run five tasks, but if I run Demon, it’s different. The number of tasks is automatic, and it is going to try to run one task on each ECS instance. Simple to run in our ECS cluster. So a daemon is used when you want to run monitoring across all of your instances and gather metrics, but in our case, we’ll just run Replica because we only want to run our application. The number of tasks I will choose for now is one.

Now, for the minimum healthy person, I’ll just set this as zero. You don’t need to understand why—just set it to zero. This will essentially allow us to do rolling restarts, with a maximum of 200 people. Now for deployments, we define how our service is deployed, and so the deployment type is going to be a rolling update. That’s basically what comes with ECS, but now there’s a new rolling deployment called Bluegreen deployment that is powered by code deployment. This is out of scope for now, but just know that code deploy can be used to deploy to ECS as well. We’ll keep this as rolling update task placement and simply leave it as default, which is essentially defining a strategy for how to place tasks on different ECS instances so you can choose whatever you want. For now, we’ll just choose the AZ Balance spread.

Okay, click on the next step, and we scroll back up. Now we configure the network, so basically we can choose a load balancer type, and for now I’ll choose none, as this is intended, but we’ll add a load balancer later on. But we could choose application network or classic load balancer, which will disable service discovery integration because this is out of scope and a little bit too complicated. So click on next, and we won’t set up ODO scaling, but it is possible to set up ODO scaling for your ECS service as well. Next step. Okay, everything looks good. This task description is being carried out. This is the name of our service. We’re going to run one task. It’s a replica type, and the minimum healthy and maximum healthy zero 200 networks, as well as Otisal, are not configured. That makes the service really simple. Let’s create the service. The service was created; we can view the service, and as we can see now very quickly, a task is in a pending state. So our service is going to start a task to basically launch our HTTPD task. Okay, let’s go back to the cluster demo. And in there, we can see that we have our service name, httpd, that’s running. The desired number of tasks is one, and the number of running tasks is one as well. So our task is running. If we go to Tasks now, we can see in this tab that indeed our task is running this task definition, and it’s running on this container instance right here. So what I could do is click on this container instance and get some information about the public IP and stuff. However, we know it’s the instance we just made. So as we can see, this instance had 124 CPUs, but now that we’re using a little bit of it, it has less CPUs available, and the memory has decreased as well because we’ve reserved some stuff. Okay, so this is good. Let’s go back to our cluster demo.

Everything looks good; the task has been created. So how about we check out our service? So for this, if we go to the public IP of our instance, let’s click on our instance. Here is the public IP, and we go to portat; if you’re attentive, this should work, but it doesn’t. Why? because it’s a security group issue, obviously. So we click on the security group and go to inbound editing. We’re going to add a rule and a custom TCP. I’ll say that port 80 from anywhere will just allow HTTPD, click on save, and now we have added that role. So if I go back, yes, now it says it works. So our first Docker container is running our EC2 instance, and it’s mapped to port 80, and it works. Saying HTTPD works is just what it does. It just says it works. Now, let’s return to our instance and, once you’ve seen what’s going on, we’ll do Docker PS. And now we can see that, on top of the Amazon ECS agent, there is HTTPD 2.4 that is running in the foreground and has started. So we could curl this container from our local host and do local host 80 80 and get an answer back.

So, very cool, right? We have one easy-to-instance running innercluster, and it’s running a task of HTTPD. very, very awesome. So now you may ask me, “Can we scale our service?” Can we run two tasks? So let’s click on the service, update it, and then say number of tasks two, click on Next Step, Next Step, Next Step, and Next Step and update the service. So now we’re saying to our service, “I want to have two tasks running.” But the problem is that, as we can see, nothing will happen. So nothing happens. There’s just one task happening; no other task is pending. And it says, “Okay, it was unable to place a task because no container instance met its requirements.” The container is already taking up the space needed for your task. So if you remember from our task definition right here, when we defined our task, we said, “Hey, by the way, I want you to map the container port to the host port.” So we can only have one task per ECS instance, because if I try to launch a second task, it will try to use that port 80 again, but it’s already in use by our instance, so this will not work.

So this is a bit of a problem, but for now, let’s do something pretty cool. Instead of launching two tasks on the same EC2 instance, what we can do is scale our cluster so we can go to ECS instances. I’ll click on scale ECS instances, and I’ll have two instances. This will basically create another T, two micros that will come up, hopefully join the cluster, and then run our task. So let’s wait a little bit. Okay, so if I refresh this now, I see two instances, and what happened is that our autoscaling group was updated to have the desired count of two. So it has created two easy instances in total. Now, if we go back to ECS, we see that the instance got registered automatically, and all of a sudden, magically, a second task is running. So now we have two tasks, HTTPD and HTTP, running on two different container instances. So let’s take a quick look at this one’s IP address. So I think it was this instance that just got launched. We’ll have a look at the IP. So here is the public IP on the right, and I’ll go to port 80, and yes, that works too. So now we have two instances running our HTTPD image, and it works. So that’s it for this beginning, but we’ll see how to launch this with a little load balancer and see how we can make this more fun. So I’ll see you in the next class.

59. ECS Service with Load Balancers

Okay, so now the idea is that we’d like to run our HTTPD service, but many times on many different easy-to-create instances. So this is our instance, and what we’re going to do is that we’re going to change the task definition, but this time we’re not going to include any host ports. What will happen is that we just specify a container port, and the host port becomes random. So here’s a random number: 32657. And we’ll do it again and again. So every time we launch an HTTPD task, it will have a new random port number. And so, as you can see, it’s really, really hard because it’s random to direct traffic to these port numbers. But thankfully there is an application load balancer, which will receive our traffic from the internet. And it has a feature called “dynamic port forwarding,” which basically routes the traffic to the random port. It knows how to pick up these random ports; it will route this traffic to the random ports and basically spread our load on our different containers. So this dynamic port forwarding is how you run multiples of the same task on the same EC2 instance.

And we’re going to get a demo of this right now. And this is a very common exam question, so let’s get started. As I previously stated, if we return to the service and update it, and then say, okay, we’d like to have four tasks now on our ECS cluster, this will not work because we still have a fixed host port. We will never get four tasks; each task will only get two, and the two remaining tasks will never be launched. So let’s go back to our task definition, this one, and we’re going to create a new revision. So we select that task definition, and we’re going to update it and create a new revision. Now the task definition name is my HTTPD. Same thing. The role we still want to sign in your role is that we’ll use the same network mode, the same EC2-compatible mode, the same memory, and the same CPU, but I’m going to change the container definition here. So I’ll just leave it empty this time. The only thing I specify is the container port, and this will mean that the host port will be random when the containers are launched. Click on “update.” And now we’re good. Now we’ll click on Create, and here we go. Now we have the task definition, my HTTPD 2. And if we look at the JSON now, basically the host port is zero, zero.

That means undefined; that means random. Okay? So now we have to update our service to use this new task definition. So I clicked on the service, and now I clicked on Updates. And here is the task definition. I will not choose revision one. I will choose revision two, which is the new latest. Okay, we could basically use this to force the deployment of the service, but we don’t need it right now. We’ll just do this and say, “Okay, zero means you can take down all the current tasks and 200 means you can create all the new tasks as well.” Okay, next step, next step, next step, and update the service view service. And here we go. So now we have two deployments. We have the old deployment that’s active, and then we have the primary deployment, which is the one we want to have. And here we want to run the same container four times. So ECS will do its thing, and you can look at the events to see what’s happening. But basically, ECS will do its thing and start running more containers.

So that was really, really quick, but here we go. On our containers, we have four HTTP/2 servers running. So if we go back to our cluster, go to tasks. Now, as we can see, we have four containers running, and they’re running on our easy instances. So now our simple instances have two running tasks each, and the CPU and memory available have been reduced. But this is awesome. This was really, really quick. So see how quick it is to deploy an application. Okay? So now let’s have a look at the port. So if I come in and docker PS. As you can see here, http is running twice, and now the port it’s assigned to is 32769. So that’s really complicated; that’s random. And this one is 32768. This will work if I simply curl localhost 32769. It says it works, and if I curl six and eight, it will say it works as well. So these two applications are running in parallel, but from a user perspective, it’s really hard for me to know how to get to that port.

And I have to open security groups; I have to open a wide range of ports. It’s really insecure, right? So we wanted a load balancer to basically load balance these four HTTP containers, two on this instance and two on the other instance. So for this, we can go to the service. And if you try to edit the service, and this has been the case for many, many years, you basically cannot add a load balancer as you go along. So it can only be set during service creation. So what we have to do is basically create a new service, and this one will have a load balancer. So let’s go ahead and create it. We’ll click “create,” and this is a simple type that uses my HTTP/2 cluster, cluster demo. For load balancing, the service name is http://ALB; it is a replica. I want four tasks, and I will just say zero and 200. So here we go. Zero. I can’t even type zero. The deployment type is rolling update, and the deployment spread type is AZ balance spread. Click on “next.” And here we’re able to basically set a load balancer. So we’re going to choose an application load balancer, and as you can see, this one has dynamic host port mapping. So this is the feature I’m talking about. It basically allows multiple tasks per container instance and will dynamically route based on the port. So it’s really, really smart. This is not something you get with a classic load balancer.

The classical balancer requires static host port mapping. So an application load balancer is what we want. We can basically create a new role for this. So I’ll click “Create new role,” and it will say “No load balancer found.” So we have to actually create a load balancer in EC 2. So let’s go do this right now. We’re going to go and create an application load balancer. I’ll call it my ECS cluster ALB. It’s Internet-facing; it’s IPV4, and it’s going to listen on port 80 for HTTP. It’ll be connected to the three you have, and then I’ll configure the security settings. Security groups. I’m going to create a new group, and I’ll call it ECSAlbsg, and it’s going to listen on port 80 from anywhere. Excellent routing. So I will just not need to specify any target groups. So I’ll just basically have to do this, but I don’t have to. So I’ll just say “dummy target group,” and it could be either an instance IP or limit function. But right now I’ll just leave this as is, click Next, and then I’ll click on Review because I don’t need a target group, and I’ll click on Create.

Okay, so now the load balancer was successfully created, and I just have to wait a few minutes until it is provisioned. In the meantime, we have to do one last thing because our load balancer is going to talk directly to our EC2 instances. We need to allow the load balancer to talk to our instances on any port, and it has to be done through security groups. So let’s go back to our security groups. This one will be filtered for ECS, and so this is the service and group that we have for our EC two instances and an inbound. I’m going to edit it. I can remove this port 80, and I’m going to say okay, you can have all traffic, all of it. As a result, all ports must come from a security group. This is the ECS security group. So it says, “Okay, the ECS ALB SG.” So the security group that belongs to the ALB is allowed to talk to my two EC2 instances on allports, and this is basically how the dynamic will work. So I’ll say okay, allow ALB to communicate with any ports on EC. There are two instances of the dynamic port feature on ECS. Great. This is a great description. Click on “Save.” And now we have allowed all protocols and all ranges to come from our load balancer, Excellence. So let’s go back to our load balancer and see if it’s ready. So it’s still provisioning, but we can try ECS refresh again and see if we still have it. So we found it.

So, for the service for which I am responsible, we will simply select the ECS service role that was previously created, and the container to load balance will simply add this one to the load balancer. Now follow me. This is a bit complicated, but for the production listener port, I’ll just select the ad Http. The target group name will just be a new one.And then the path pattern we’re just going to say is to accept all traffic, and the evaluation order is going to be one. Okay, Excellence. The health check path is also going to be just a slash. Okay, Excellence. We’re going to disable service discovery. Click on “next step.” Select “otos” scaling. Click on “next step.” And let’s just review everything. So we’re going to launch this task definition for replicas. It’s going to be configured as a load balancer. This is the load balancer name. This is the target group, the health check pass, the listener port, the health check pattern, and the service role. Very important. We use the ECS service role that was created before. Click on “Create Service,” and, hopefully, everything will go well. So let’s have a look. The target group has been created, and the rule has been created.

Now we’re just waiting for the IAM policy and the service. So the IAM policy has been attached to our role, and the HTTP ALB service has been created as well. Okay, now let’s go back to the service and see how things work. So make your way to the Cluster Demo. And as we can see now, we have two services running. So the one we have from before and the one from the ALB are actually starting to run some tasks. So we can delete the HTTPD service. Now we’ll update it, and we’ll just say I want zero tasks. This is how you delete it for the first time. So you’re saying I want no tasks. And then you say, “Okay, this is from my old service.” And then, when you’re finished, so when it has a zero number of tasks, you can delete them by clicking here. And it will basically say “delete me.” And this is how you delete a service. Okay, so now this will basically allow our HTTP ALB service to go from two tasks to four tasks because we deleted the old ones. So let’s just refresh.

As we can see, two tasks are running, but the desired number is four. So let’s click on the service itself to see what’s happening. We have four tasks running now running.It was really, really quick, actually, to launch, and now we have four tasks running, which is pretty awesome. So how do we see if it’s working? How do we see that everything’s working? So if we click on the task, we can see that the container itself is mapped, for example, to port 32771. And this is a random port, right? And so if everything is done, then the ALB should redirect to it automatically. So for this, how do we test it? Well, we’re just going to go to our load balancer and get the URL of this load balancer. The DNS name is right here. I’ll copy it and open it in a new tab, and it works. So now we have our ALB redirecting to our four containers, running on two instances with dynamic host routing and port routing, which is really, really cool. And this is an exam question, but I wanted to show you how it works because I think it’s really cool to see it set up in real life, and I think it’s quite a complicated setup as well. But here we go. We run four tasks of HTTPD on two easy instances linked to an ALB. Congratulations. Let’s keep on moving with this tutorial.

60. ECR – Part I

Okay, so just a quick introduction to ECR. So far, we’ve been using Docker images from the DockerHub, which are public, but this time we’re going to use ECR, which is a private Docker image repository. So we’ll be able to push our own images, and we’ll build our own images in this lecture. So access to ECR is really good because it’s controlled through IAM. So if you get any permission errors, that means there is a problem with the IAM policy. and that’s a very common exam question.

As a result, you must understand how to run, push, and pull commands against a Docker repository in ECR. And the trick is to use this first command called AWS Event Logging, which we’ll see in the hands-on as well. And then finally, you do a Docker push with the full ECR URL and a Docker pull with the full ECR URL. So don’t be concerned; we’ll see it in action right now. Okay, so now we want to play with ECR, and for this we have to create our own Docker image and push it to ECR. So let’s do something fun. First, we go to Docker Comget, and then we scroll down to find Docker for Mac and Docker for Windows. So instal the version you need. Then, to ensure that Docker is installed, go to the Docker minus minus version, which displays the Docker versions from 180 to 180. Here’s the build number.

So once everything is installed, you know you’re ready. So far, so good! Now we’re going to basically build our own Docker image. So you don’t need to be a Docker expert; don’t worry. But this is just what’s called a Docker file, which explains how to build a Docker image through layers. And so here we’re saying, “Okay, we’re going to use our HTTPD image from Docker Hub, and we’re going to instal a few things on it.” Then we’re going to add some HTML to it, add a script, and then launch that script. So this is very simply what a Docker file does. And so, okay, we’re going to add an index of HTML. As you can see, this index of HTML file right here says “Hello World” from a custom Docker image. This image is running on ECS. Here’s some information about this task, okay? And then the bootstrap grip is what’s going to run; it’s going to pick up some metadata information around ECS and display it to us, and you’ll see what it looks like in a few minutes. So that’s the idea. You don’t need to be a pro Docker, but we are going to see how to basically build that image, tag it, and so on. So from this screen, open a terminal in the directory.

So I’m in my Dockerfile directory, and I’m going to run a function line of code called “Docker build minus” my HTTP image and then dot. So docker build -t my HTTPD image, and this will go ahead and basically run all the things you need to do. So six steps was really something Quick had already done for me, but you can do it. It will take you maybe a little bit more time to do this, but this will run commands, instal a bunch of stuff, and get your image ready when it’s done. It’s going to say, “Successfully built blah blah and successfully tagged my HTTPD image.” So when you have this, we have built our first Docker image, and we’re going to run it in ECS. So before running it in ECS, we have to push it to ECR. Next, we’re going to Amazon ECR, click on Repositories, and we’re going to create our own first repository.

So I’ll click on Create Repository, and I’m in this one demo. just very simple. Click on Create Repository, and here we go. Our first repository has been created. Here we have the Uri of this repository. Okay, let’s click on “Demo.” And currently there are zero images in our demo repository, so we’re going to start adding images to this repository. Very well. We’re going to click on “View push commands,” and this is the list of push commands for the demo. Now you have to remember these commands when you go into the exam. So have a look, especially at the macOS and Linux ones. But if you’re on Windows, you obviously need to run the Windows command, obviously.So what we have to do is run this command. Email and region are not required for AWS eCrget login. So you need to have your AWS CLI already set up, and we need to have the right ECR IAM permissions; otherwise, this will not work. So let’s run this command and see what it does. So I’m going to go here and then run this command on my screen. As you can see, it provides me with a massive Docker login minus U, minus B, and this entire thing right here. And then at the end, the URL of our Ducker repository.

So basically, this AWS Ecrget login command generates a temporary ducker login that we can use to login our ducker against the ECR repository and start pushing and pulling images from it. As a result, until you surround this Aries ECR get login with dollar parenthesis, it does nothing. If you’re using a Mac or Linux, simply follow the instructions on the websites. But by surrounding it in these little dollar parenthesis, we’re basically running this command. So we’re going to run this whole command right away with one little shortcut. So I press Enter, and here we go. Login succeeded. And so what this does is that it runs this entire command right here. So now I’m logged in with an ECR, and that’s the first step. Okay? Remember, if you’re on Windows, the command you had to run was invoke the expression command and run this entire thing. Okay, so the second command is to build our Docker image. So we already ran this, but let’s run it again because now the name is “Demo” instead of my HTTP image. It really doesn’t matter, but let’s just run it the way the push command tells us to do it. So, demo docker build minus T. And this should be very, very quick. So now we have successfully tagged the latest demo.

Okay, excellent. And then, after the build completes, we tag our images so we can push the image to the repository. So docker tag is saying, “Okay, this demolished image, you’re going to rename it, retag it,” and that’s the docker repository URL. That’s the namespace; that’s the imagename; and that’s the tag latest. So we have to run this entire command right here. And this will differ because this is my AWS account. And so this will be changing for you. But we run the third command to tag the image and rename it to this entire name. So let’s go back, and we’re going to run this command. So here we go. Now it’s tagged, and there is no output for this command. And then finally, to push it, we do Docker push and then the entire image name we’ve just created. And this should push the image into ECR. This will require a small amount of Internet from your end. So here we go. The image is being pushed from your computer, and since you have fast Internet, it should be fairly quick. But as you can see, there are about 100 megabytes of things to upload. So I’ll just wait until this is completed. Okay, so my entire image has been pushed. And so if we go back to ECR, I’m going to close this and refresh my images.

Here we go. Our first image is here, and the image tag is latest. We have the image Uri, and we see when it was pushed. So, this is really awesome, right? We’ve just pushed our first image into a repository, this one. And this is very exciting. This is the first step. But now, what if you wanted to get that image onto our computer? So, let’s say you download it. Well, first, very simply. So we’re going to use the exact same ECS login details. So we’re going to run AWS EC2 login, and this will lug us into Docker. So we don’t have to do it twice, but I’m still doing it twice to show you. Then we’ll do Docker pull, pass in the entire imagename right here, Docker pull, and press Enter. It also says pulling from Demo. And then obviously the image is up-to-date because this is the one that I’ve just pushed. But the idea is that the exam will ask, “How do we pull an image from ECR?” The reason the answer is “get login,” ECR, “get login,” And then Docker pulls with the right image name and the right tags. Okay? So we’re going to use that image in the next lecture on ECS. I hope you’re excited, and I will see you in the next lecture.