Deploying individual containers is not difficult. However, when you need to coordinate many container deployments, a container management tool like ECS can greatly simplify the task (no pun intended).
ECS refers to a JSON formatted template called a Task Definition that describes one or more containers making up your application or service. The task definition is the recipe that ECS uses to run your containers as a task on your EC2 instances or AWS Fargate.
INFO: What is a task?
A task is a running set of containers on a single host. You may hear or see 'task' and 'container' used interchangeably. Often, we refer to tasks instead of containers because a task is the unit of work that ECS launches and manages on your cluster. A task can be a single container, or multiple containers that run together.Fun fact: a task is very similar to a Kubernetes 'pod'.
Most task definition parameters map to options and arguments passed to the docker run command which means you can describe configurations like which container image(s) you want to use, host:container port mappings, cpu and memory allocations, logging, and more.
In this lab, you will create a task definition to serve as a foundation for deploying the containerized adoption platform stored in ECR with ECS. You will be using the Fargate launch type, which let's you run containers without having to manage servers or other infrastructure. Fargate containers launch with a networking mode called awsvpc, which gives ECS tasks the same networking properties of EC2 instances. Tasks will essentially receive their own elastic network interface. This offers benefits like task-specific security groups. Let's get started!
Note: You will use the AWS Management Console for this lab, but remember that you can programmatically accomplish the same thing using the AWS CLI, SDKs, or CloudFormation.
-
Create an ECS task definition that describes what is needed to run the monolith.
The CloudFormation template you ran at the beginning of the workshop created some placeholder ECS resources running a simple "Hello World" NGINX container. (You can see this running now at the public endpoint for the ALB also created by CloudFormation available in
cfn-output.json.) We'll begin to adapt this placeholder infrastructure to run the monolith by creating a new "Task Definition" referencing the container built in the previous lab.In the AWS Management Console, navigate to Task Definitions in the ECS dashboard. Find the Task Definition named
Monolith-Definition-STACK_NAME, select it, and click "Create new revision". Select the "monolith-service" container under "Container Definitions", and update "Image" to point to the Image URI of the monolith container that you just pushed to ECR (something like018782361163.dkr.ecr.us-east-1.amazonaws.com/mysfit-mono-oa55rnsdnaud:latest).
-
Check the CloudWatch logging settings in the container definition.
In the previous lab, you attached to the running container to get stdout, but no one should be doing that in production and it's good operational practice to implement a centralized logging solution. ECS offers integration with CloudWatch logs through an awslogs driver that can be enabled in the container definition.
Verify that under "Storage and Logging", the "log driver" is set to "awslogs".
The Log configuration should look something like this:
Click "Update" to save the container settings and then "Create" to create the Task Definition revision.
-
Run the task definition using the Run Task method.
You should be at the task definition view where you can do things like create a new revision or invoke certain actions. In the Actions dropdown, select Run Task to launch your container.
Configure the following fields:
- Launch Type - select Fargate
- Cluster - select your workshop cluster from the dropdown menu
- Task Definition - select the task definition you created from the dropdown menu
In the "VPC and security groups" section, enter the following:
- Cluster VPC - Your workshop VPC, named like
Mysfits-VPC-STACK_NAME - Subnets - Select a public subnet, such as
Mysfits-PublicOne-STACK_NAME - Security goups - The default is fine, but you can confirm that it allows inbound traffic on port 80
- Auto-assign public IP - "ENABLED"
Leave all remaining fields as their defaults and click Run Task.
You'll see the task start in the PENDING state (the placeholder NGINX task is still running as well).
In a few seconds, click on the refresh button until the task changes to a RUNNING state.
-
Test the running task by using cURL from your Cloud9 environment to send a simple GET request.
First we need to determine the IP of your task. When using the "Fargate" launch type, each task gets its own ENI and Public/Private IP address. Click on the ID of the task you just launched to go to the detail page for the task. Note down the Public IP address to use with your curl command.
Run the same curl command as before (or view the endpoint in your browser) and ensure that you get a list of Mysfits in the response.
HINT: curl refresher
$ curl http://TASK_PUBLIC_IP_ADDRESS/mysfits
Navigate to the CloudWatch Logs dashboard, and click on the monolith log group (e.g.:
mysfits-MythicalMonolithLogGroup-LVZJ0H2I2N4). Logging statements are written to log streams within the log group. Click on the most recent log stream to view the logs. The output should look very familiar from your testing in Lab 1.
If the curl command was successful, stop the task by going to your cluster, select the Tasks tab, select the running monolith task, and click Stop.
Nice work! You've created a task definition and are able to deploy the monolith container using ECS. You've also enabled logging to CloudWatch Logs, so you can verify your container works as expected.