By using AWS re:Post, you agree to the Terms of Use
/multi container server - best and easiest way to scale, upgrade, etc./

multi container server - best and easiest way to scale, upgrade, etc.

0

Afternoon all. We have a project that as the title said, the developers will do their magic, then push a docker image up to ECR. The initial test was all manual, ran a few containers on different ports, manually setup the listeners and all good.

So the next step it to automate. I want to let them update the ECR/docker image and once done have that update the servers one at a time the way my current code-deploy works. I am trying to read and understand the difference or benefits to using a ECS cluster vs an Elastic Beanstalk as well as understand a bit more from the high level as I am going to need redundancy, autoscaling, etc.

So, a brief answer on where to start with what would be great, but basically I need to create a service that starts X amount of docker containers per instance, then they get added to the target group / ELB.

Thanks for the advice!

2 Answers
0

Hello. On the ECS vs E-Beanstalk front, I much much prefer ECS, and would recommend it anyday over Beanstalk. Now you could use AWS AppRunner these days which might allow to do something simple for you to have you and your devs have a very easy way to update the services.

However, shamelessly "selling" my own thing: we at work use ECS Compose-X which is a CLI tool like ecs-cli v1 / copilot and AppRunner: you use docker-compose syntax (which your devs can rely on given it is a very well known, widely used tool and specification) to have your services (environment variables, images, build, compute resources (RAM/CPUs)) and you define with extension fields what AWS resources you want your service to have access to (S3, SNS etc.).

On top of that, it allows you to simply define Load Balancers and point the traffic to the services. It also is going to allow to define autoscaling, monitoring, alarms etc. for your services.

And most important: it is going to ensure as much as possible that all settings, options etc. are valid for a successful deployment to AWS.

When using docker-compose locally, all these extensions (x-) are ignored, but when running ecs-compose-x, everything is taken into account to create the CFN templates that will allow to deploy everything (services, DBs, LBs etc.) to AWS. This allowed our devs to very quickly iterate on development and testing, and gives them consistency on deployment to AWS.

You can find examples and guides in the labs and there are new blog posts with full CICD walkthroughs coming in soon.

Hope this helps.

answered 2 months ago
0

@John - Thanks for the detailed feedback. No same in selling anything as you included plenty of other info :)

But yes, basically they have their docker and we want to have X servers running, each with 5 containers (for example). Then update that container, commit it and have things nicely get updated one by one. So I am going to look at Apprunner, I didn't really consider beanstalk but watching video after video and reading to try to logically understand how things fit.

The server is fine, the containers each start with a custom port range the the ELB has to listen to and want as much automation as possible, really taking me out of the loop once its setup, so I am going to look at both app runner as well as your thing.

Thank you again for the direction.

answered 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions