underlying infrastructure, cluster resources, capacity, setup. Just give it a task definition or pod (in 2018), set some resource limits, and away you go.
rights reserved. Scheduling and Orchestration Cluster Manager Placement Engine Using ECS made it easier Availability Zone #1 Availability Zone #2 Availability Zone #3
rights reserved. “When someone asks you for a sandwich, they aren’t asking you to put them in charge of a global sandwich logistic chain. They just want a sandwich”
rights reserved. Running Fargate containers in ECS Use ECS APIs to launch Fargate Containers Easy migration – Run Fargate and EC2 launch type tasks in the same cluster Same Task Definition schema
rights reserved. OK, so what’s a Task Definition? { "family": “scorekeep", "containerDefinitions": [ { "name":“scorekeep-frontend", "image":"xxx.dkr.ecr.us-east- 1.amazonaws.com/fe" }, { "name":“scorekeep-api", "image":"xxx.dkr.ecr.us-east- 1.amazonaws.com/api" } ] } • Immutable, versioned document • Identified by family:version • Contains a list of up to 10 container definitions • All containers are co-located on the same host • Each container definition has: • A name • Image URL (ECR or Public Images) • And more…stay tuned! Task Definition Snippet
mode? • Depends on your workload. • For Fargate: if you have a Task Definition, and you’re ok with awsvpc networking mode, try Fargate. Some caveats: can’t exec into the container, or access the underlying host (this is also a good thing) • For EC2 mode: good if you need to customize!
rights reserved. Container CPU sharing • Task CPU is a hard upper bound • Container CPU is optional. By default all containers get an equal share of task CPU time • Specify container CPU to control relative sharing among containers • In our example: task cpu = 1024; scorekeep-frontend = 256; scorekeep-api = 768; scorekeep-api container scorekeep-frontend container Container 1 Container 2
rights reserved. Container memory sharing • Task memory is a hard upper bound across all containers • Container level memory settings are optional. By default all task memory is available to all containers • • Two settings to control sharing at the container level: memory reservation & memory • Memory reservation is a soft lower bound. Can kick in when task memory is under contention • In our example: task memory = 2 gb; scorekeep-frontend = 512 mb; scorekeep-api = 512 mb; • Memory is a hard upper bound. Container will not be allowed to grow beyond this value Task Memory scorekeep-api container scorekeep-frontend container Available for all Container 1 Container 2 Available for all Task Memory non-critical container critical container Task Memory Memory Reservation Memory Reservation Memory Reservation Hard Memory Limit
rights reserved. Platform version • What is it? • It refers to a specific runtime environment around your task • Version available today: 1.0.0 • New versions will be released as the runtime environment evolves: Kernel/OS updates, new features, bug fixes, and security updates • Why should I care? • It gives you explicit control over • Migration to new platform versions • Rollback to previous platform versions • Leave it blank and we will automatically place your tasks on the latest version • How do I use it? • $ aws ecs run-task ... --platform-version 1.0.0 • $ aws ecs run-task ... --platform-version LATEST #or just leave it blank
Containers on the same network can communicate via IP address. No automatic service discovery. Connect containers with ---link None: no network interface, only local loopback (which I’ll explain shortly) Host: connect to host network (container maps to host)
• For multi-host native networking, you can use overlay networks (like Consul, or Swarm). I’m not covering this today, but if you’re interested, you can start here: https://www.consul.io/docs/guides/consul- containers.html • For more info on container communication, start with the Docker documentation: https://docs.docker.com/engine/userguide/networking/default_network/ container-communication/
components could communicate via the local, loopback interface: more commonly known as `localhost` or 127.0.0.1 • This bypasses networking interface and lets processes communicate directly Got it? Good.
not part of the same task, or to external services. This means traffic is (most likely) routed through the internet through your VPC. • Tasks are launched into subnets, which define traffic rules through routing tables. • Two types of subnets: • Public: associated internet gateway • Private: no direct internet gateway, traffic is routed through NAT (Network Address Translation)
(Elastic Network Interface) • Containers launched as part of the same task can use the local loopback interface (remember that one?), since containers part of the same task share an ENI • With the ENI allocation comes a private IP. Public IPs can also be allocated. • ENIs are at the task level, though, so how to containers that are part of different tasks communicate?
rights reserved. VPC integration Launch your Fargate Tasks into subnets Beneath the hood : • We create an Elastic Network Interface (ENI) • The ENI is allocated a private IP from your subnet • The ENI is attached to your task • Your task now has a private IP from your subnet! You can also assign public IPs to your tasks Configure security groups to control inbound & outbound traffic 172.31.0.0/16 Subnet 172.31.1.0/24 Internet Other Entities in VPC EC2 LB DB etc. Private IP 172.31.1.164 us-east-1a us-east-1b us-east-1c ENI Fargate Task Public / 208.57.73.13 /
rights reserved. Internet access The Task ENI is used for: • All network traffic to and from your task • Image Pull (from ECR or a public repository) • Log Pushing to CloudWatch (if configured) Outbound Internet Access is required for Image Pull & Log Pushing (even if the application itself doesn’t require it) There are two ways to set this up: • Private task with outbound internet access. Does not allow inbound internet traffic. • Public task with both inbound and outbound internet access
rights reserved. A bigger picture: Fargate networking Internet Gateway 172.31.0.0/16 Subnet 3 Fargate Task Public IP 54.191.135.69 172.31.3.0/24 ENI Subnet 1 Fargate Task Public IP 54.191.135.66 172.31.1.0/24 ENI Subnet 2 Fargate Task 172.31.2.0/24 ENI
rights reserved. Looking for more networking details? https://aws.amazon.com/blogs/comp ute/task-networking-in-aws-fargate/ https://aws.amazon.com/blogs/comput e/introducing-cloud-native-networking- for-ecs-containers/
rights reserved. Types of permissions Cluster level permissions: • Control who can launch/describe tasks in your cluster Application level permissions: • Allows your application containers to access AWS resources securely Housekeeping permissions: • Allows us to perform housekeeping activities around your task: • ECR Image Pull • CloudWatch logs pushing • ENI creation • Register/Deregister targets into ELB Cluster Permissions Application Permissions Task Housekeeping Permissions Cluster Fargate Task
rights reserved. Cluster level permissions { "Effect": "Allow", "Action": [ "ecs:RunTask" ], "Condition": { "ArnEquals": {"ecs:cluster":"<cluster-arn>"} }, "Resource": [ “<task_def_family>:*" ] } You can tailor IAM policies for fine grained access control to your clusters Attach these policies to IAM Users and/or Roles as necessary Some example policies: Example 1: Allow RunTask in a specific cluster with a specific task definition only { "Effect": "Allow", "Action": [ "ecs:ListTasks“, “ecs:DescribeTasks” ], "Condition": { "ArnEquals": {"ecs:cluster":"<cluster-arn>"} }, "Resource": “*” } Example 2: Read-only access to tasks in a specific cluster and many more!
rights reserved. Application level permissions Do your application containers access other AWS resources? Need to get credentials down to the task? Create an IAM Role with the requisite permissions that your application needs. In our Scorekeep example, DDB & SNS permissions. Establish a trust relationship with ecs-tasks.amazonaws.com on that role. This lets us assume the role and wire the credentials down to your task. Add the ARN to your task definition and you’re done! AWS CLI/SDK calls from within your application will automatically use the Task Role credentials Credentials are rotated in a timely manner { "family": "scorekeep", "cpu": "1 vCpu", "memory": "2 gb", "networkMode": “awsvpc“, “taskRoleArn": “arn:aws...role/scorekeepRole“, "containerDefinitions": [ { "name":“scorekeep-frontend", "image":"xxx.dkr.ecr.us-east-1.amazonaws.com/fe", "cpu": 256, "memoryReservation": 512, "portMappings": [ { "containerPort": 8080 } ] }, { "name":“scorekeep-api", "image":"xxx.dkr.ecr.us-east-1.amazonaws.com/api", "cpu": 768, "memoryReservation": 512, "portMappings": [ { "containerPort": 5000 } ] } ] } Task Definition
rights reserved. Housekeeping permissions • Fargate needs certain permissions in your account to bootstrap your task and keep it running. • Execution Role gives permissions for: • ECR Image Pull • Pushing Cloudwatch logs • ECS Service Linked Role gives permissions for: • ENI Management • ELB Target Registration/Deregistration
rights reserved. Execution role Using an ECR Image or Cloudwatch Logs? • Create an IAM Role and add Read Permissions to ECR • ecr:GetAuthorizationToken & ecr:BatchGetImage • Or use AmazonEC2ContainerRegistryReadOnly managed policy • Add Write Permissions to CloudWatchLogs • logs:CreateLogStream & logs:PutLogEvents • Or use CloudWatchLogsFullAccess managed policy • Establish trust relationship with ecs-tasks.amazonaws.com. This lets us assume the role • Add the execution ARN into your task definition Give Fargate permissions via an Execution Role { "family": "scorekeep", "cpu": "1 vCpu", "memory": "2 gb", "networkMode": “awsvpc“, “taskRoleArn": “arn:aws...role/scorekeepRole“, “executionRoleArn": “arn:aws...role/scorekeepExecutionRole“, "containerDefinitions": [ { "name":“scorekeep-frontend", "image":"xxx.dkr.ecr.us-east-1.amazonaws.com/fe", "cpu": 256, "memoryReservation": 512, "portMappings": [ { "containerPort": 8080 } ] }, { "name":“scorekeep-api", "image":"xxx.dkr.ecr.us-east-1.amazonaws.com/api", "cpu": 768, "memoryReservation": 512, "portMappings": [ { "containerPort": 5000 } ] } ] } Task Definition
rights reserved. Permissions summary Cluster Permissions Control who can launch/describe tasks in your cluster. via IAM Policies Application Permissions Allows your application containers to access AWS resources securely. via Task Role Housekeeping Permissions Allows us to perform housekeeping activities around your task. via Task Execution Role and Service Linked Role Cluster Permissions Application Permissions Task Housekeeping Permissions Cluster Fargate Task via IAM Policies via Task Execution Role & Service Linked Role via Task Role
of type Fargate, and of type EC2 FAQ: how do I exec into a Fargate container? Short Answer: you don’t Longer answer: if it were me, I’d stop the Fargate container and restart as type EC2 for debugging, then switch back over. Long term, something we’re looking at building.
The wizard is just for learning Fargate concepts and how it works. You can absolutely use (and should use) your own VPC. Wait what? The wizard/getting started flow in Fargate will create a VPC and subnets for you. You can both a) edit the resources created through the wizard, or launch Fargate tasks into a previously created VPC through the regular console flow/the CLI.
rights reserved. Isolation is at the Cluster level PROD Cluster Infrastructure DEV Cluster Infrastructure BETA Cluster Infrastructure QA Cluster Infrastructure Web Web Shopping Cart Shopping Cart Notifications Notifications Web Shopping Cart Notifications Web Shopping Cart Shopping Cart Notifications Notifications Web Web PROD CLUSTER BETA CLUSTER DEV CLUSTER QA CLUSTER
rights reserved. Load Balancer setup • ELB integration supported on services • ALB & NLB supported. Classic ELB not supported • Some details on ALB: • ALB requires that you pick at least two subnets in two different Azs • Ensure that the ALB subnet AZs are a superset of your task subnet Azs • Select ALB Target type: IP (not Instance)
official OG. Open source, includes most AWS services. • More info here: https://aws.amazon.com/cli/ • Github here: https://github.com/aws/aws-cli • ecs-cli: also official, but just for ECS. Supports docker compose files. • More info here: https://github.com/aws/amazon-ecs-cli Some good unofficial options: • Fargate cli: https://github.com/jpignata/fargate • Coldbrew cli: https://github.com/coldbrewcloud/coldbrew-cli
abbyfuller
vanstee
tamaranovitovic
tammyeverts
konakalab
jonrohan
schlessera
jct
inesmontani
ryanjones
smashingmag
aki_iinuma
