The secrets example isn't very comparable. With Kubernetes, the secrets are injected into the container as environment variables or files, whereas the ECS example requires assigning an IAM role to the task and doing a Parameter Store lookup from within the container. This usually requires a custom docker image with an entrypoint to handle that part. The same is true for ConfigMaps, which I believe ECS lacks.
No, you don’t need to do any of that. ECS can inject secrets into environment variables in much the same way as Kubernetes. This behaviour is already built-in, there’s no need to build your own solution for it.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
That's good to know. The parent linked to an AWS blog post that did work that way. The documentation you linked is a new feature since I last used ECS.
Exactly. You can deploy a highly available, auto scaled, logging enabled, spot instance or Fargate multi-service ECS reference architecture here by deploying a “one click” cloudformation stack: https://github.com/aws-samples/ecs-refarch-cloudformation/bl...
Nice! I'd been busy with another project and missed a couple of those announcements. The DaemonSet equivalent will allow me to rip up some particularly annoying cruft the next time I need to touch it. Thank you.
I've looked at various guides for setting up cluster autoscaling on ECS, and so far, everything I've found looks far more complicated than Kubernetes cluster autoscaling on Google. Is there a nice guide?
- https://aws.amazon.com/about-aws/whats-new/2018/06/amazon-ec...
- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
- ECS runs on ASG / EC2 so there is auto scalling
- https://aws.amazon.com/blogs/compute/managing-secrets-for-am...
I think you don't understand all the glue between AWS services, off course ECS doesn't have everything that's why there is EKS, but all the thing above exists on ECS.