Deep dive - AWS Fargate

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Deep dive: AWS Fargate
Abby Fuller, Developer Relations, AWS
@abbyfuller

First things first: who here is new to containers?

A container is an atomic, self-contained package of software that includes
everything it needs to run (code, runtime, libraries, packages, etc.).
A popular, widely-used container platform is Docker. More on that here:
https://www.docker.com

Let’s talk container basics
Docker pull
Docker build
Docker run
Docker tag
Docker push

Why are containers so popular?
Portable
Lightweight
Standardized
Easy to deploy
Along with containers, comes the “monolith to microservices” story:
containers and microservices go hand in hand (more on that in a
second)

OK, so what are microservices?
”Service oriented architecture
composed of loosely coupled elements
that have bounded contexts.”
- Adrian Cockroft
(This is Adrian)

Why do microservices and containers go together?
• One job, one service  container
• Can deploy and scale containers independently
• This means that a high traffic service, like a messaging service,
might need to be scaled frequently, but a low traffic service, like
an internal dashboard, doesn’t need to be scaled at the same
time

Running one container is easy Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Running many containers is
hard…

Enter container orchestration tools

To avoid doing extra hard work that we don’t have to,
we use container orchestration tools

There are few options on AWS for container
orchestration

Today, we’re going to focus on Fargate.

No
infrastructure
Launch
quickly
Scale easily
Manage
everything at
container level
Resource
based pricing

“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”
P.S., the sandwich is
Fargate

Why Fargate?

Remember this?

Managing a production container infrastructure can be a lot
of work

Using ECS made it easier
Scheduling and Orchestration
Cluster Manager Placement Engine
Availability Zone #1 Availability Zone #2 Availability Zone #3

But it’s not totally hands off
ECS
AMI
Docker
agent
ECS
agent
ECSTaskECSTask
ECSTaskECSTask
EC2 Instance
ECS
AMI
Docker
agent
ECS
agent
EC2 Instance

Fargate lets you focus on your application

Let’s look at that in practice

So you want to run a managed container on AWS
1 Choose your orchestration tool
AMAZON CONTAINER SERVICES
2 Choose your launch type
ECS EKS
EC2 FARGATE EC2 FARGATE

Let’s go back to EC2 mode for a second

How do the pieces of ECS map back to traditional
workloads?
Instances: standard
EC2 boxes. Once
registered to a Cluster,
your Tasks run here
Services: layer that
manages and places
tasks
Tasks: container wrapper and
configuration around processes
running on the instance

So what am I responsible for in ECS?
Instance
s
Servi
ce
Tasks

So what am I responsible for in ECS pt 2 ?
• In EC2 mode, you’re responsible for configuring all three of those pieces:
instances, services, and tasks.
• Instances are configured through the ecs-optimized AMI (or your own AMI), and/or
you can configure with EC2 user-data
• Services and Tasks (and containers) are all configured through the ECS API, which
you can either access directly, or go through the CLI. Tasks are defined through
Task Definitions, and Containers are defined through Container Definitions.

How does compute work in ECS?
• Choose your own instance type, with any combination of resources
• Controlled through the Service ASG launch configuration, like with any other
EC2 cluster.
• Supports GPUs, spot instances, RIs, etc.

Running Fargate-mode containers on ECS

A lot of similarities with the basics of ECS
Same Task Definition schema Use ECS APIs to launch
Fargate Containers
Easy migration – Run
Fargate and EC2 launch
type tasks in the same
cluster
Share primitives like VPC,
CloudWatch, IAM with
ECS

So what am I responsible for in Fargate mode?
Instance
s
Servi
ce
Tasks

So what am I responsible for in Fargate mode pt 2?
• In EC2 mode, you’re responsible for configuring services and tasks
• Instances are not configured by you, you can ONLY configure at the container/task
level
• Services and Tasks (and containers) are all configured through the ECS API, which
you can either access directly, or go through the CLI. Tasks are defined through
Task Definitions, and Containers are defined through Container Definitions.

How does compute work in Fargate?
CPU Memory
256 (.25 vCPU) 512MB, 1GB, 2GB
512 (.5 vCPU) 1GB, 2GB, 3GB, 4GB
1024 (1 vCPU) 2GB, 3GB, 4GB, 5GB, 6GB, 7GB, 8GB
2048 (2 vCPU) Between 4GB and 16GB in 1GB increments
4096 (4 vCPU) Between 8GB and 30GB in 1GB increments

How do I know what to choose?
Depends on your workload.
Fargate: if you can configure with just 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)
EC2 mode: good if you need to customize!

•Change in networking mode: "networkMode": "awsvpc”
•Only specify container port, no host port:
•"portMappings":
[{"containerPort": ”8081"}]
•No links (only local loopback)
•No ELB Classic, only ALB or NLB. ALB needs to use target type IP, not
instance.
•Launch Type: Fargate
•Windows containers only on EC2, not Fargate

requiresCompatibilities
requiresCompatibilities parameter.
"requiresCompatibilities": ["FARGATE"]
You can have tasks that have multiple compatibilities:
"requiresCompatibilities": ["FARGATE”, “EC2”]

Let’s talk about networking (baby)

Local networking
On a single EC2 instance, two 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.

External networking
This covers communication with services that are 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)

Traditional Docker networking
Bridge: docker0. This is the default behavior. 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)

awsvpc (the slightly longer version)
With awsvpc, each task is allocated an ENI (Elastic Network Interface)
Containers launched as part of the same task can use the local loopback
interface
With the ENI allocation comes a private IP. Public IPs can also be allocated
(with Fargate).

Looking for more networking details?
https://aws.amazon.com/blogs/compute/task-networking-in-aws-fargate/
https://aws.amazon.com/blogs/compute/introducing-cloud-native-networking-for-
ecs-containers/

If you don’t know now you now (or FAQs)

Q: can I have both EC2 and Fargate tasks?
A: yes, you can run hybrid clusters, or switch back and forth. Tasks can be
compatible with both.
Q: how do I exec into a Fargate container?
Short A: you don’t
Longer A: if it were me, I’d stop the Fargate container and restart as type EC2
for debugging, then switch back over.

Q: why can’t I use my own VPC with the Fargate first run wizard?
A: The wizard is just for learning Fargate concepts and how it works. You
absolutely can (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.

I get by with a little help from my friends (CLIs)

CLIs (that I know about) for Fargate/ECS
aws-cli: the 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

Thanks!
@abbyfuller

Deep dive - AWS Fargate

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Deep dive - AWS Fargate

Similar a Deep dive - AWS Fargate (20)

Más de Amazon Web Services

Más de Amazon Web Services (20)

Deep dive - AWS Fargate