- Newest
- Most votes
- Most comments
After looking over the ECS docs (again) I saw that they emphasized having only a single container for each task. There are exceptions, such as a sidecar that directly modifies the "main" container, but as a general rule you don't want multiple containers in a task. This helped me to understand that packaging the Nginx and MyApp containers in a single task was the wrong approach.
So, I reworked the system to only have a single container in each task; 1 task for Nginx, and 1 task for MyApp. This works much better and it didn't change the networking at all. In fact, my Nginx task is now much smaller and my MyApp container can be expanded a bit to process more threads.
Finally, I now have a one-to-one relationship between containers and tasks and I can spin up a new one-off task to do my processing (backups, db:migration, etc.) without having to worry about dragging an Nginx container along with me.
It is an interesting question. Personally, using something like AWS Copilot CLI or CDK, I tend not to worry as much about reusing task definitions or environment variables taking up realestate as much as re-using the IaC code. Using AWS CDK or AWS Copilot makes reusing the environment variables trivial. That being said, I suppose you could create a 3rd sidecar/container that runs the same image but instead consumes an SQS queue triggered by your batch job to run your scripts and things like that.
Hello,
From what I understood from your question description since you are using 2 containers of your Rails-App and Nginx I assume they are also using two different separate images, if yes then you have separate services and tasks for both of them that way you can use your "My-App" image for various other things you mentioned. Regarding the connectivity, I think u can go forward with the same method you are using right now to connect them or could go ahead with service discovery.
Let me know if you need more help
Thanks
Relevant content
- asked a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
It's not just the size of environment variables, the duplication also affects keeping everything updated. Every time you update the image you have to push that update to everywhere that image is used. If I use it in 3 task definitions then I have to update it three times.
I'm getting the feeling that task definitions should really be focused on one task; an application OR a webserver, not both. From my reading it looks like multiple containers in a single task definition should be the exception rather than the rule.