This morning, I watched AWS’ webinar presenting their container service. Here are some quick notes, for those of you who are as curious as I was about it!
This is not meant to be an intro to Docker. This is not meant to be an intro to EC2 or to AWS. This is for people who are already familiar with AWS, specifically with EC2, and who are already familiar with Docker, and wonder what’s behind the ECS (EC2 Container Service) announcements made at AWS re:invent last November.
AWS has made the video available if you want to watch the webinar yourself.
- it’s supposed to be a set of building blocks, usable “as-is” or as part of something more complex
- your containers will run on your EC2 instances (a bit like for Elastic Beanstalk, if you’re familiar with that)
- there is no additional cost: you pay only for the EC2 resources
- it only works on VPC
- the service is currently in preview (behind a sign-up wall) in us-east-1; general availability will come in the next few months
- there is no console dashboard yet; you have to use the CLI or API
- for now, you can only start containers from public images hosted on the Docker Hub, but that’s expected to change when the service goes out of preview
Glossary of terms
Here is some vocabulary to help you to mash through the ECS docs.
A “container instance” can be any EC2 instance, running any distro (Amazon Linux, Ubuntu, CoreOS…)
It just needs two extra software components:
- the Docker daemon,
- the AWS ECS agent.
The ECS agent is open source (Apache license). You can check the ECS agent repo on github.
That’s a pool of resources (i.e. of container instances).
A cluster starts being empty, and you can dynamically scale it up and down by adding and removing instances.
You can have mixed types of instances in here.
It’s a regional object, that can span multiple AZs.
It’s an app definition in JSON. The format is conceptually similar to Fig, but not exactly quite like it.
I don’t know why they didn’t pick something more like Fig, or more like the Docker Compose project. It might be because almost everything else on AWS is in JSON, and they wanted to stick to that.
Note: Micah Hausler wrote container-transform, a tool to convert Fig/Compose YAML files to the ECS task format:
@jpetazzo @docker I wrote a little fig.yml <==> ecs-task.json converter. https://t.co/brcOtFvLAk— Micah Hausler (@micahhausler) January 15, 2015
A task is an instanciation of a task definition. In other words, that will be a group of related, running containers.
So, how does one use that? The workflow looks like this:
- Build image using whatever you want.
- Push image to registry.
- Create JSON file describing your task definition.
- Register this task definition with ECS.
- Make sure that your cluster has enough resources.
- Start a new task from the task definition.
Now, diving into the details; there are 3 ways to start a task:
- Use the CLI command
start-task. You must then specify the cluster to use, the task definition, and the exact container instance on which to start it. It’s a bit like doing manual scheduling.
- Use the CLI command
run-task. You must then specify the cluster, task definition, and an instance count. It will run ECS default resource scheduler (which is a random scheduler).
- Bring your own scheduler!
The webinar had a demo involving Mesos; they started container from Marathon, from Chronos, and using the CLI as well, and the containers were visible everywhere. That looked cool. Initially, I didn’t understand how it worked; but the people who built it were kind enough to chime in and explain:
@jpetazzo the Mesos integration is via a Mesos scheduler driver— Deepak Singh (@mndoci) January 15, 2015
@mndoci @jpetazzo the scheduler drive speaks to AWS ECS only, there are no Mesos masters or slaves involved. Just ECS + Marathon/Chronos— William Thurston (@williamthurston) January 15, 2015
Not much on that side.
Containers can be linked (the task definition allows to name containers, and then to indicate that a container is linked to another one) but I don’t know how that works.
My personal take
My understanding is, that ECS as it is today is a technological preview.
There are a some items that are still to be clarified, like the use of private registries (but on that front, Docker Hub Enterprise might eventually come on AWS; and it will likely integrate nicely with ECS).
Docker-centric point of view
I would love if:
- container instances and clusters could be managed with Docker Machine
- task definitions and tasks could be managed with Docker Compose as the frontend
- Docker Swarm could be used as a custom scheduler
Those interoperability points would let anyone move their container workloads seamlessly form/to ECS. More importantly, they will let anyone use the elasticity and scale of EC2, without having to learn APIs and concepts specific to ECS.
AWS-centric point of view
I would love if:
- ECS could integrate with Cloud Formation (that’s plannned)
- I could also build images (that’s pretty trivial with an ad-hoc instance)…
- … and push them on a S3-backed registry that would be neatly integrated with ECS (notably for security credentials)
Full disclaimer: I haven’t tested ECS yet (and unfortunately, I don’t know if I’ll be able to). So if you have any feedback or useful tip that would be useful for others, don’t hesitate to let me know!