‫Now let's talk about
‫Amazon ECS Task Definitions, but in depth.
‫So you define them in JSON form
‫but through the console
‫there is a UI to help you create the JSON,
‫and the task definition tells the ECS service,
‫how to run a or multiple Docker containers on ECS.
‫And there is crucial information
‫within your task definition, such as the Image Name,
‫the Port Binding for the Container
‫and the Host, if you're on EC2.
‫The memory and the CPU required for your container.
‫The environment variables, the networking information,
‫the IAM role attached to the task definition,
‫and the login configuration
‫such as, for example, CloudWatch.
‫So there's more information as well
‫but these are the most important
‫and the exam will test you on a few of these.
‫So, I will do a deep dive on some of that in this lecture.
‫So let's take an example.
‫We have an EC2 instance,
‫and because it is registered with an ECS cluster,
‫it has to be running the ECS agent.
‫Next, we're going to run a Docker container
‫through ECS test definition,
‫for example, an Apache HTP server.
‫And we have to expose that server to the internet.
‫Therefore, we are going to define a container port
‫on 80, meaning that on the container ,
‫the port 80 is the one that is exposing the HTP server.
‫But then we have also the host port
‫because we are on EC2.
‫If we were on Fargate, that would not be relevant,
‫but we are on EC2.
‫And therefore we need to map this container port
‫to a host port, which is for example,
‫could be 80 but it could be also at 8080.
‫So they don't have to be the same.
‫And then thanks to the host port, then the internet
‫or an external network communication
‫is able to access the EC2 instance,
‫on port 8080, the host port,
‫which is going to be directed to the container port 80,
‫and then will get access to the HTP server.
‫Okay.
‫And you should know that you can define
‫more than one container per task definition.
‫You can define up to 10 containers per task definition.
‫So let's do a deep dive onto first the container port.
‫So if you have load balancing
‫and you're using the EC2 launch type,
‫then you're going to get
‫what's called a Dynamic Host Port Mapping.
‫If you define only the container port
‫and the task definition.
‫Let me explain.
‫So we are running for example, an ECS task,
‫and all of them have the container port
‫set to 80 but the host port set to zero,
‫meaning not set.
‫What's going to happen is that the host port only
‫is represented in this diagram,
‫but the host port is going to be random,
‫is going to be dynamic.
‫And so, each ECS task
‫from within the EC2 instance,
‫is going to be accessible from a different port on the host,
‫the EC2 instance.
‫And therefore, if you define an application of that answer
‫then you may say, well,
‫it is difficult for the ALB to connect
‫to the ECS test because the port is changing.
‫But the ALB when linked to an ECS service
‫knows how to find the right port,
‫thanks to the Dynamic Host Port Mapping feature.
‫And so, the ALB,
‫automatically thanks to the ECS service,
‫knows to connect to different ports
‫onto different instances automatically.
‫And so this setup works,
‫but it does not work with a classic load balancer
‫because it is older generation.
‫So this logic only happens with the ALB.
‫And so therefore from a security perspective,
‫well the EC2 instance security group, must allow any port,
‫from the ALB security group,
‫because we don't know in advance
‫what is going to be the host port mapping.
‫So that was for the EC2 launch type.
‫But now what happens when we have the Fargate launch type?
‫Well, each ECS task is going to get
‫a unique private IP this time.
‫And so, because this is Fargate,
‫there is no host,
‫and therefore we only have to define the container ports.
‫And so if you look at your ECS cluster,
‫then for example, with four tasks
‫each task is going to get its own private IP
‫through an Elastic Network Interface or ENI.
‫And then each ENI is going to get
‫the same container ports.
‫And so this is a setup you're going to get with Fargate.
‫And therefore, when you have an ALB,
‫then to connect to the Fargate task,
‫it's just going to connect to all all of them
‫on the same port on port 80.
‫So there is the ECS ENI Security Group
‫that needs to allow port 80, from the ALB security group.
‫And then the ALB security group
‫needs to allow just to port 80 or 443,
‫if you have SSL enabled, from the web.
‫Next, the exam will ask you about IAM roles within ECS.
‫And you should know that IAM roles are assigned
‫per task definition.
‫So you have a task definition
‫and then you assign an ECS task role.
‫And this will allow you, for example,
‫for your ECS tasks out of your task definition,
‫to access the Amazon S3 service.
‫And therefore when you create an ECS service
‫from this task definition
‫then each ECS task automatically
‫is going to assume and inherit this ECS task role.
‫But you should know that the role is defined
‫at the task definition level, not at this service level.
‫And so, therefore all the tasks
‫within your service, are going to get access to Amazon S3.
‫And if you define another task definition,
‫you can add another role on it.
‫And this role, for example, can access DynamoDB.
‫And if you were to create another service,
‫then that service would assume this other role
‫and you would be good to go.
‫So the exam will ask you,
‫where do you define an IAM role for ECS task?
‫And the answer is, on your task definition.
‫Next, you have environment variables.
‫So, your task definition, can have environment variables
‫and they can come from multiple places.
‫You can hard code them.
‫For example, you set them directly
‫from within the test definition.
‫And for example,
‫this is when you will have a fixed non-secret URL.
‫But then if you have sensitive variables,
‫such API keys or shared configs,
‫or for example, database passwords,
‫then you can use either the SSM Parameter Store,
‫or Secrets manager, to store these values.
‫And you reference them from within the ECS task definition
‫and upon launching an ECS task
‫then these values are going to be fetched
‫and resolved at run time
‫and injected as environment variables, within your ECS task.
‫Finally, there is a last option
‫where you load your ECS environment variables
‫directly from an Amazon S3 bucket.
‫And this is called a bulk environment
‫variables loading through a file.
‫Next we have, how do we share data between ECS tasks?
‫So, as I said, an ECS task can contain one container
‫but also you can define multiple containers
‫in the same task definition.
‫And you would do that because sometimes,
‫your side containers also called side cars
‫can help you with lugging, with tracing and so on.
‫And so, it's a common pattern.
‫But sometimes, well for example, for lugging
‫and for metrics and so on,
‫these containers need to share some files together.
‫And therefore, we must mount a data volume
‫onto both containers,
‫and then they will be able to share data.
‫And so, this data volume, bind them out,
‫works for both EC2 and Fargate tasks.
‫So let's imagine we have an ECS task
‫and we have the application containers.
‫It could be one, it could be many.
‫And then some side car containers,
‫for example the metrics and logs container.
‫You're going to create a bind mount,
‫and it's going to create a shared storage
‫that you have to define between your task.
‫And you say, for example, it is /var/logs
‫and so therefore your application containers
‫are going to be able to write
‫to this shared storage,
‫and your metrics and log container
‫can read from these shared storage.
‫And this is the whole idea behind the bind mount.
‫So if you use EC2 tasks
‫then the bind Mount itself is the EC2 instant storage.
‫And therefore the data of that mount is tied
‫to lifecycle of the EC2 instance.
‫Or, for Fargate task, then you use ephemeral storage,
‫and the data is tied to the container,
‫a lifecycle using them.
‫And so whenever your Fargate task disappears,
‫then your storage disappears as well.
‫Now, on Fargate you get from 20 gigabytes to 200 gigabytes
‫of shared storage,
‫so it gives you lot of space for different use cases.
‫So between them.
‫So the basic use case,
‫especially from the exam perspective
‫is to share data between multiple containers
‫or when you have a side car container
‫where the side car is used to, for example
‫send metrics or logs to other destinations.
‫And it needs to read from a shared storage.
‫Okay.
‫So that's it for the Amazon ECS task definition, deep dive.
‫I hope you liked it.
‫And I will see you in the next lecture.