AWS Using ECS-Optimized AMI with Docker Containers in ECS

Question

I have used an extensive amount of time building the kind of deployment setup I'm going to describe next. I've gone through most of the documentation on ECS and documented an exhaustive list of learning resources.

However, it seems I'm still missing some vital piece of this puzzle with Docker on AWS ECS...

In development, we are using Docker Compose for defining a set of containers as a local full-stack cluster. It is a really convenient tool for working with containers locally.

Our aim is to use Docker Compose approach for deploying this cluster into Amazon AWS ECS.

ECS supports Compose file format up to version 3.0. Most notably there is no support for using local files as the build context, so an image must be referenced.

What I'm currently confused with:

The official doc states that instances running in ECS should have Amazon ECS container agent, Docker daemon, and ecs-init installed and configured. As such, for the base image they are recommending:

The Amazon ECS-optimized AMIs are preconfigured with these requirements and recommendations. We recommend that you use the Amazon ECS-optimized Amazon Linux 2 AMI for your container instances unless your application requires a specific operating system or a Docker version that is not yet available in that AMI.

Confusion point 1: However, I've found no examples in the official docs on how to actually build and run Docker containers based on these optimized AMIs... There are just about two Dockerfile examples, here and here, which are both building from public non-AMI images?

I've found some resources, like here (source) and here, which show how to use Packer with its EC2 AMI Builder (EBS backed) for building a custom AMI based on these ECS optimized AMIs.

I've set up this process myself with some minor modifications, and it is working. I have my own custom images showing up under AWS EC2 AMIs.

Confusion point 2: However, I seem unable to reference these AMI images in my dockerfiles or docker compose files, as they are not stored in ECR... Am I correct (or having misconfig)?

Packer does have a post-processor for docker push which has support for ECR. But it does not work with EC2 AMI Builder:

Post-processor failed: Unknown artifact type: mitchellh.amazonebs
Can only import from docker-import and docker-tag artifacts.

Sure, I would not actually need to have the base AMI stored in ECR... But I would need to be able to use it as the image to build my custom service Docker images from, and to store those release images in ECR. Then reference those images in the docker compose file.

I'm aware that turning to additional automation tools like Ansible, Terraform, or AWS Code* services could get me past this point. But I've been trying to follow the official docs and gather information from various sources while trying to keep the setup minimal, and do not yet fully understand the issue I'm facing.

Confusion point 3: What is the recommended way for building and running Docker containers in ECS with Amazon ECS-optimized Amazon Linux 2 AMIs?

And what am I possibly missing here...?

Answer 1

There's a split between the software running on the host itself and the software running in containers. The paragraph you're reading is about software that needs to run on the host EC2 systems.

When you set up an ECS cluster, you need to provide a set of EC2 instances. AWS recommends you use their AMI as a base for those instances, and this is a pretty reasonable thing to do. If you want to use something like the standard Ubuntu AMI instead, you need to install the referenced bits of software on those instances before it can "be part of" the ECS cluster and start running containers. (To run Docker containers you need Docker installed on the host.)

I don't think there are particular requirements on the containers that run on ECS, and there isn't a way to build a Docker image based on an AMI. You should be able to launch the same set of images you're using locally (assuming you actually COPY the source code into the images, they run without operator interaction, etc.).