rights reserved. 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
rights reserved. 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)
rights reserved. OK, so what are microservices? ”Service oriented architecture composed of loosely coupled elements that have bounded contexts.” - Adrian Cockroft (This is Adrian)
rights reserved. 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
rights reserved. 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…
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” P.S., the sandwich is Fargate
rights reserved. 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…
rights reserved. Using ECS made it easier Scheduling and Orchestration Cluster Manager Placement Engine Availability Zone #1 Availability Zone #2 Availability Zone #3
rights reserved. But it’s not totally hands off ECS AMI Docker agent ECS agent ECSTask ECSTask ECSTask ECSTask EC2 Instance ECS AMI Docker agent ECS agent EC2 Instance
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” P.S., the sandwich is Fargate
rights reserved. 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
rights reserved. 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
rights reserved. 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.
rights reserved. 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.
rights reserved. 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
rights reserved. 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.
rights reserved. 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 50-ish combos, y’all
rights reserved. 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!
rights reserved. •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
rights reserved. requiresCompatibilities requiresCompatibilities parameter. "requiresCompatibilities": ["FARGATE"] You can have tasks that have multiple compatibilities: "requiresCompatibilities": ["FARGATE”, “EC2”]
rights reserved. 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.
rights reserved. 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)
rights reserved. 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)
rights reserved. 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).
rights reserved. 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/
rights reserved. 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.
rights reserved. 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.
rights reserved. 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
abbyfuller
jnunemaker
akosma
michielstock
trishagee
dougneiner
mza
rkendrick25
davidcarrasco
stephenakadiri
lara
csswizardry
rkaga
