The last component that I want to show you is called the task definition. If you ever used Docker compose before, this is going to look very familiar. It's essentially a file, in this case a JSON formatted file that you can use to define pretty much everything; parameters, volumes, number of containers, memory, CPU, everything that you need to take full advantage of your entire Fargate cluster.

Before we go there, I want to show you that the Amazon ECR is here. This is where you're going to have your container images. So, this goes beyond the scope of this course that the creation of your own images. That's going to require CICD, DevOps, and all kinds of things to create your own container images.

However, if you want to test if you've been following along and I have my own test information here and it shows a container, in this case, nginx:latest, let me show you here, this one actually going to open this. You see here nginx:latest essentially a web server, very popular. So, what if you wanted to do your own testing? Well, first of all, you can use this same image name that I'm using here. So, the question is, where does it come from? There are several possibilities. I'm going to show you one right here. You have the ECR public repository, which I'm going to show you right now. If I go to gallery.ecr.aws, for example, let's say I type nginx right here, you see we have a version. I'm going to click on this, shows you how to use it. You can do it directly from the command line, docker run, and use this URL for example.

So, my point is you don't need to have your own ECR repository. You can just use Amazon Public ECR repository. For example, I'm going to try WordPress which is a very popular image and it's also available here in the public repository. So, with these images, you can create a task definition. Amazon will go here at your request and pull this image and set it up for you. Of course, each one of these images is going to have its own set of requirements. So, that's why you have this usage tab here, which you can probably find information that is specific to this. It may require certain environment variables, a certain amount of CPU, a certain amount of memory, all those things. Take a look at this for example, how to use this image.

And there are several values here that you need to consider. For example, MySQL information and all that stuff. So, let's go back to where we started. All those values that are required need to be defined in a task definition. So, in this case I'll click on JSON and as I mentioned, this file is formatted just like this in a JSON format. The reason being is that even though you can define a task definition right here in the console, it's just so cumbersome. You want this file to be a part of your repository. So, you really don't want to be editing any of this directly in the console. It's so much better to have it as part of your configuration, as part of your repository, in general as part of your CICD process.

So, let's go over the attributes here. So, when you start a task definition, the first thing you need to define is of course going to be containers. And I say containers plural. As you can see on line three, there's an opening left bracket here at the end, meaning that in a single task definition, you can include several containers. In this case we just have one, in this case, line six, nginx:latest. And then beyond that, we're defining how much CPU. In this case, you see 256 here. I believe the definition of one virtual CPU would be a 1,024 and this scale meaning that 256 is a tiny fraction, let's say 25% of a CPU. Memory, I believe that's expressed in megabytes. So, 512 is going to be 0.5 gigabytes of RAM.

If you were doing a real-life deployment, you would have let's say a Spring Framework or some other Java-based environment. Then you'll have a really large number here, say they're going to be 4096 for four gigs of of RAM or 8,192 for eight gigs. Whatever is necessary for your application to run smoothly. Beyond that, we have Port mappings. In this case, we're just using Port 80 and this is going to be very specific to your application. So, whatever you're running, it's probably going to be a different Port than than Port 80. So, you need to be aware, you need to be in touch with your developers and hey, which port is the application using. And that's very critical information because you need that information to define proper security groups and allow networking to to happen smoothly.

You don't want to have a port that's being blocked or a health check that is failing to report values because you don't even know what the port is exactly. What else? Environment, we talked about this already. This is where you define your SSM parameters or your secret manager parameters. Or you're probably going to need a few ones that can be hard-coded as long as they're not sensitive pieces of information. Mount Points and volumes. This is also very important. We just saw the WordPress image and that probably is going to require a volume mounted.

Usually, an EFS volume where you would have images and videos and anything that you need to display in a WordPress block, those need to be stored in a mounted volume so that when the container dies or is recycled by an auto-scaling group for example, you would have the opportunity to preserve those files and be able to reuse them over and over when the containers reloads, perhaps in a different availability zone or some other auto-scaling event scenario. The next one is also very important. This is the log configuration because this is what's going to help you monitor and troubleshoot your containers.

Something very important here. You see that we're accessing a specific AWS log group as well as the region where it is located, and this is all cloud watch stuff. What's very important here is that this container has permission to write to these locks because otherwise, you're going to get a failure saying, hey I can't write to Cloud Watch for this reason or that reason. This is a job for the ECS Task Execution role, what you see here on line 31. So, this role needs to have permission to access Cloud Watch, in particular to this log group define on line 23 so that we can see what's going on with the container. If it's running fine, you probably never need to look in there, but still very useful so that you can define alarms. Like, hey, what is this word error showing up and the locks, what do we do?

You can set up alarms and all kinds of monitoring, but you need those permissions defined in the ECS task execution. The rest of the information is pretty much standard task definition stuff. The last interesting pieces of information are going to be the Fargate definitions here. So, this is not a normal ECS cluster, a traditional ECS cluster. This is Fargate, meaning that is managed by AWS and not by you. And the last two values you see here, CPU and memory, they match exactly these two values that we have here on line seven and eight. The reason being is that we only have one container defined in this task definition, so we get to use a total available for this task definition.

So, if we had more than one container defined up here, the total cannot exceed the values that you see down here. Just something to keep in mind, and that's all really that there is to know about Task definition. As I mentioned, as a best practice to edit this document in JSON format and not in the nicely formatted view that you get here in the console because you're going to be making a ton of changes to this document and it's a lot easier to do it with your favorite text editor or just in general not doing it in the AWS console. And that's all there is to know about Task definition to run your containers.