You might think you want to run your code in a Docker container on AWS ECS vs having it run on a AWS EC2 server, but you are wrong :)

You might think you want to run your code in a Docker container vs having it run on a server. Next you might think you want to run it on AWS’s ECS (Elastic Container Service) because you assume that is easier than going full blown Kubernetes.  Let me try and dissuade you from this and try and persuade you to stick with a VM running on EC2 (Elastic Compute Cloud).

Last week I wanted to take some code I had and run it on ECS. But before I did that, I did an experiment: I created a dockerfile that was just a simple web site that consisted of a Python Flask app and some HTML files. There was a wrinkle: I wanted the HTML files to sit on a file system outside the container. It’s easy enough to do with Docker and a command like this on an EC2 instance:

docker run -p 8000:8000 –rm  -v /home/bernie/mydata:/app/mydata:ro website:latest

My container listens on port 8000 and any files in my /home/bernie/mydata directory are accessible within the container at /app/mydata

For a container running in ECS, it is an entirely different beast. You have to:

1. Create a container registry in Amazon’s ECR (Elastic Container Registry).
2. Make a Docker image and upload it to your container registry.
3. Create a cluster in ECS.
4. Create a Task Definition in ECS.
5. Create an ECS Service, including setting up an ALB (optional), configuring security groups and configuring the VPC associated with the cluster.
6. Set up an EFS (Elastic File System) to store the HTML.
7. Set up an EC2 server to create / upload the HTML to. You cannot directly access the EFS you create to the container: you have to mount it to your EC2 server, load the files to the EFS, and then attach it to the cluster/container.
8. Once you do all that, THEN you can access the simple Flask web site and the web pages you created.

MOST IMPORTANTLY, you have to DEBUG DEBUG DEBUG all through this process. Did you forget to add port 2049 to your security group rules? Fail. Did you forget to set your IAM settings correctly? Fail. Are your subnets set up wrong? Fail. On and on and on.

If you insist on doing it, then I have some useful links below. But if you can get away with a simple micro EC2 server with a simple software firewall in front of it, I highly recommend you go with this approach.

Creating a simple EC2 server? Easy. Having Docker running your container on your server? Easy. Getting your container running on ECS? Not easy.

P.S. If you still think this is a good idea, then I recommend this: Deploying a Dockerized Web App on AWS Using ECS and Fargate: A Step-by-Step Guide. Deploy a dead simple container first just to work out all the issues you will have with ECS and any other AWS services, and once you have the ability to do that, proceed with more complex containers.

If you want to do it using the AWS CLI, I recommend this repo: Developing and Deploying a Basic Web Application on Amazon ECS Using Fargate.

More good pieces to read: here

P.S.S. Another consideration: while a container running in ECS isn’t too expensive, it’s more expensive than a micro EC2 server. Which is also more expensive than serverless computing using AWS Lambda (although Lambda is more complicated than an EC2 server).

P.S.S.S. I went through this process because the client I was working on had a mandate to deploy code this way. Hence this exercise. The client has good reasons to do things this way: most enterprise clients do. If you are not an enterprise, make your life easier.