Getting Started with Amazon EC2 Container Service

Getting started with Amazon
EC2 Container Service
Abby Fuller, Sr Technical Evangelist, AWS
@abbyfuller

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Amazon EC2 Container Service
• Highly scaleable, high
performance container
management system.
• Eliminates the need to install,
operate and scale your own
container management system.

Amazon ECS
• ECS provides a managed platform for:
Cluster management Container orchestration Deep AWS integration

Amazon ECS
• No software to:
Deploy Manage Scale

Deep AWS integration
Autoscaling Load balancing IAM MonitoringNetworking Logging

How does ECS map to traditional
workloads?
Instances: standard EC2 boxes. Once registered to a
Cluster, your Tasks run here
Service: layer that manage and place your Tasks
Task: container wrapper and configuration around a
process running on the instance

How does ECS work?
Staging cluster Production cluster
Container instance Container instance
Container instance
Container instance Container instance
Container instance

A closer look
Load balancer (ALB, NLB, or ELB Classic)
routes traffic to the cluster instances
Cluster is made up of one or more EC2
instances
Each Container instance runs one or more
Services

A closer look
A Service controls things like the number of copies
of a Task you want running (Desired Count), and
registers your Service with a load balancer
A Task Definition controls things like container image,
environment variables, resource allocation, logger, and
other parameters

Building your cluster
Either navigate to the ECS service in your AWS console or:
$ aws ecs create-cluster --cluster-name ”your-cluster-name"
{
"cluster": {
"status": "ACTIVE",
"clusterName": ”websummit",
"registeredContainerInstancesCount": 0,
"pendingTasksCount": 0,
"runningTasksCount": 0,
"activeServicesCount": 0,
}
}

Task Definitions in ECS
After creating your Cluster, you need to create your first Task Definition. Task Definitions
control almost everything about your service, from the container image used, to your resource
allocation.
$ aws ecs register-task-definition [ --family <value>
[--task-role-arn <value>]
[--network-mode <value>]
--container-definitions <value>
[--volumes <value>]
[--placement-constraints <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]

Creating a task
• $ aws ecs register-task-definition --cli-input-json
file://pathwebsumit.json
• You can also use a JSON string:
• $ aws ecs register-task-definition --family websummit--container-
definitions
"[{"name":”websummit","image":”alpine","cpu":10,"command":[
"sleep","360"],"memory":10,"essential":true}]”
• This same call is used to register a different version of the task definition as well. For
example, websummit:5 à websummit:6

Use your task to create a service
• $ aws ecs create-service --service-name websummit --task-definition
websummit --desired-count 2
• You can add more parameters here, such as placement strategy. You can also register your
new service with an ELB/ALB.
Something to note: once a service is registered to a specific load balancer,
that value cannot be changed. This holds true for --family when you’re
registering tasks, as well.

Task Placement Policies
When you call create-service, you have the opportunity to set Task Placement constraints and
strategies:
$ aws ecs create-service
[--placement-constraints <value>]
[--placement-strategy <value>]
By default, the ECS scheduler will place tasks like this: first check for constraints like port,
memory, and CPU, then place tasks on the instances with the fewest number of running tasks,
balanced by Availability Zone. You have custom options, though.

Custom Task Placement Strategies
• If you’re so inclined, you can customize the strategy that ECS uses to place tasks:
Binpacking Spread Affinity Distinct instance

Custom Task Placement Constraints
Name Example
AMI ID attribute:ecs.ami-id == ami-eca289fb
Availability Zone
attribute:ecs.availability-zone == us-east-
1a
Instance Type attribute:ecs.instance-type == t2.small
Distinct Instances type=“distinctInstances”
Custom attribute:stack == prod

Let’s take a second to talk about Load
Balancers
• Three different kinds: Application Load Balancer, Network Load Balancer, ELB Classic:
• ELB Classic: the original. Distributes traffic between instances.
• Application Load Balancer: path based routing. Great for microservices. Functions at
Application Layer (7)
• Network Load Balancer: extremely high performance/low latency. Also good for
unusual/spiky traffic patterns. Functions at Connection Layer (4)
• Strongly recommend Application Load Balancer (ALB) for microservices and ECS. Why? Path-
based routing lets you route traffic to multiple services (/web, /messages, /api) with a single
ALB. It also supports dynamic port allocation. This is magical.

Editing a service can deploy or scale
• $ aws ecs update-service --service reinvent --desired-count 4 --task-definition
reinvent:6
• This update-service call serves many functions:
• Changing the --desired-count will scale the service up or down.
• Changing the --task-definition will change the revision. This is effectively a deploy.
•

Scaling up and down
• This is possible in the console and the CLI:
• $ aws ecs update-service --service reinvent --
desired-count 2
• However, in a production environment, this is something we
probably want to handle with autoscaling.

Query cluster state
• $ aws ecs describe-services --service reinvent
• This returns A TON of information about our service: most importantly, it shows us our
current deployment, and what events are happening in our cluster:
• "events": [
• {
• "message": "(service reinvent) has reached a steady state.”
• Cluster events can also be streamed to CloudWatch.

Amazon ECS Event Stream for
CloudWatch Logs
• Receive near real-time updates about both the current state of both the container instances
within the ECS Cluster, and the current state of all tasks running on those container
instances.
• Can be used to build custom schedulers, or to monitor cluster state and handle those state
changes by consuming events with other AWS services, such as Lambda.

You’ve set up your cluster: now what?

Monitoring with CloudWatch Metrics
• Get Task, Service, and Cluster level metrics via CloudWatch:

Monitoring with CloudWatch Metrics

Centralized logging with CloudWatch
Logs
{
"image": ”nginx:latest",
...
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": ”nginx",
"awslogs-region": "us-east-1"
}
}
{
• Defined within the task definition
• Available log drivers
• awslogs
• fluentd
• gelf
• journald
• json-file
• splunk
• Syslog
• Open a PR on ecs-agent GitHub repo if you want
to add others.

Centralized logging with CloudWatch
Logs

Use metric filters with CloudWatch Logs
• Helps reduce noise, and makes for faster debugging!

Service Discovery with ALB
• There are lots of ways to do this. One way is with your load balancer. This is particularly
straightforward with an ALB, since we can route to content based on path (like /web vs
/messaging).
• This might look something like:
• https://<load-balancer-name>/ à goes to main website service
• https://<load-balancer-name>/signin à goes to login service
• https://<load-balancer-name>/api à goes to backend API service
• As new tasks are added to the service, they can be ’discovered’ through the ALB, since the
ALB handles routing requests to all available services.

Service Discovery with DNS
• As new tasks stop and start, CloudWatch events trigger a Lambda handler, which adds or
removes a DNS record in Route53.

What about secrets?
• Couple of different ways. You can pass environments variables as part of the Task Definition:
• "environment" : [ { "name" : "string", "value" : "string" }, { "name" :
"string", "value" : "string" } ]
• This maps to:
• --env
• In Docker run. While this is OK for non sensitive variables, it’s not great for sensitive secrets,
since the value can be seen in the Task Definition.

EC2 Systems Manager Parameter Store
• Sensitive variables can be stored with EC2 Systems Manager Parameter Store, and ecnrypted
via KMS.
• This allows Tasks only to access the parameters that they have permission to access. Since
IAM Roles can be set at the Task level, this allows for granular control over which resources
and variables each Service can access.
prod.app1.db-pass
general.license-code
prod.app2.user-name
Service A
Service B
IAM Role
IAM Role
EC2 Systems Manager Parameter Store

Performance monitoring with X-Ray

Getting Started with Amazon EC2 Container Service

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Getting Started with Amazon EC2 Container Service

Ähnlich wie Getting Started with Amazon EC2 Container Service (20)

Mehr von Amazon Web Services

Mehr von Amazon Web Services (20)

Getting Started with Amazon EC2 Container Service