Preparing for the EC2 Container Service (ECS)

Introduction

The most exciting announcement at AWS Reinvent 2014 for me was that of the EC2 Container Service (ECS), which is not yet available, but there is a "Deep Dive" webinar for this Wednesday which I shall be probably be blogging about.

The container service revolves around managing groups of Docker containers that work together and may wish to be deployed across various nodes. Containerizing applications has been very easy, but managing/deploying groups of containers has always been difficult, which is where this service comes in. Below is one of the talks from re:Invent which goes into more detail about the service which I shall be referencing throughout this post. One can click the times to go to that part of the video.

Why Use Containers (2:17)

• Containers allow you to run the exact same environment easily from your laptop to your production server (Environment fidelity). This resolves one of the issues I hear a lot. "But it works on my machine".
• Easier/automated deployments. Just pull the container and execute it.
• More efficient resource utilization since containers can "share" resources, whereas virtual machines have dedicated resources allocated to them which results in a lot of waste.
• More suitable for distributed applications and microservices architecture rather than running monolithic applications.

Why Do I need AWS For This (4:30)?

As mentioned previously, managing multiple containers across multiple hosts is hard, if not impossible. I've seen lots of services that try to manage docker containers, such as shipyard, but they usually work well on a single node, and not across multiple nodes, or the project is not "finished" and ready for production.

The AWS Container Service will also be able take advantage of AWS systems for automatic network management.

What about Docker Swarm/Compose

Docker Swarm and Docker Compose were announced recently, but these projects are not yet "finished". Also, I'm not sure that they will have the useful CPU shares system that AWS has which will be mentioned later. However when they are "finalized", I will be evaluating them to see how easy it is to switch and are unlikely to have any kind of scaling management that ECS is likely to have (bringing up more docker hosts and adding IPs).

Scheduler (09:17)

The service will have a "scheduler" for matching containers to the EC2 instances in a cluster. In this regard, it could be referred to an "allocator" or "packer" rather than a "scheduler" since there is nothing related to timings or specific ordering. One will be able to create custom schedulers if desired.

Tasks (11:56)

A task is a grouping of related containers that perform a job. For example, your website may need a proxy service, some web frontends, and a MySQL database. A task is defined by a config file like below:

{
    "family" : "my-website",
    "version" : "1.0",
    "containers" : [
        <container definitions>
    ]
}

• family - a name for the entire group of containers.
• version - a version that can be used for rolling back if desired. One doesn't have to use sequential versioning. For example, it could be a git hash.

Container Definition (14:24)

Each container in the task will need a definition which specifies: * the name for the container * default runtime attributes * the image to be running * environment variables * port mappings * container entry point and commands * resource constraints

{
    "name": "webServer",
    "image": "nginx:latest",
    "cpu": 512,
    "memory": 128,
    "portMappings" : [ 
        {
            "containerPort" : 9443,
            "hostPort" : 443
        }
    ],
    "links" : ["rails"],
    "essential" : true
}

• name - the name for the container
• image - the reference to the docker container image. E.g from the public repo which uses your username, or a private repository that needs an address.
• cpu
  • unit is in cpuShares
  • ec2 uses 1024 cpu shares per core. (The speaker may mean per vCPU rather than per core.)
• memory
  • Always in MB
• essential
  • Specifies whether the entire task should be brought down if the container goes down.

Clusters (18:32)

Clusters (sometimes referred to as "ships") are groupings of EC2 instances that provide a "pool" of resources for your "tasks" (groups of containers). A cluster can consiste of just a single EC2 instance and scale up/down as need be.

• Demo (20:57)

Pricing

You only pay for the EC2 instances you use (including IOPS/bandwidth etc), nothing in addition for the service itself.

Unanswered Questions

• Will the provisioning service automatically allocate multiple IPs to a single node so that two containers that require the same port can run on the same host.
  • Larger nodes in AWS already support multiple IPs per node, up to a limit.
  • Most of my personal containers are REST API's that require ports 80 and 443.
  • Running one container per node would be almost pointless.
  • The speaker specifically mentioned this (6:44) when getting feedback from customers.
• Will it be able to deploy docker nodes for scaling, not simply deploy containers against a fixed size cluster.
• Will I be able to ensure that my cluster is made up of different physical nodes, without having to use different zones?
  • Speaker stopped just short of saying this at 8:34.
• What support is there going to be for data persistence? The talk specifically mentions a MySQL container. Would that container use an EBS volume and the scheduler be intelligent enough to automatically attach that EBS to whichever node the container is re-deployed upon in future? My experience with AWS tells me that their solution will probably be to use the RDS rather than a MySQL container, and use S3 for everything else.
• Can a "task" only run on a single EC2 instance in the cluster? (e.g. can't split the task's containers across multiple nodes).

Conclusion

ECS could be a tool for greatly increasing the cost efficiency and scalability of our infrastructure in future whilst also providing failover management for increased robustness. There are a lot of questions that need answering, but hopefully these will be covered by the webinar on Wednesday the 14th of January. If there is anything important that you think I have left out, please mention it in the comments below.