AWS ECS deployment in 2019

Hi, I do #devops at https://unee-t.com/ which uses Meteor for the frontend.

I did notice Docker, Meteor, and AWS ECS but the tutorial seems to be dead. Hence I thought I would quickly share and invite critique of the way I am currently doing it.

  1. https://github.com/unee-t/frontend/blob/master/.travis.yml is used for npm t
  2. https://github.com/unee-t/frontend/blob/master/buildspec.yml is used for building the https://github.com/unee-t/frontend/blob/master/Dockerfile and putting the image upon https://cloud.docker.com/u/uneet/repository/docker/uneet/frontend

I must thank Seán C. McCord for the starting point: Meteor Dockerfile

  1. Deployment is happening via AWS CodePipeline.

It’s a little tricky because our Meteor seems to require the CloudFront to be invalidated (not sure what’s the story with cache busting). And that’s done via https://github.com/unee-t/invalidate

Setting up the CodePipeline is done by hand in 3 accounts (dev, demo, prod) and it’s easy to tick and choose some wrong option. i.e. this is pain.

You may have noticed that our TravisCI file is/was doing deployments, but that’s deprecated because

  1. ecs-cli is kindof deprecated
  2. ulexus/meteor:build is deprecated
  3. permissions becomes a little saner. i.e. powerful permissions are not stored as env variables on travis, they are kept within the AWS ecosystem

In future I might move to a CDK based script style deployment and ditch CodePipeline. https://github.com/aws-samples/aws-cdk-examples/tree/master/typescript/ecs

4 Likes

Thanks for sharing :+1:

Are you deploying to a single container instance? Or doing some sort of horizontal scaling?

Currently our ECS employs a standard two instance configuration. Two instance for blue/green deployment without dropping a request. We scale by adding instances, but we haven’t needed to.

I plan to move to Fargate which I think should be easier for scaling. Anyway, we haven’t found Meteor to be a bottleneck.