Well, you're on the right track but no one actually puts things clear when it comes to containers cuz everyone wants you to use their products 😆
Google Cloud, Azure, and AWS all have different solutions for your problem, but you need to choose the one that gives you, as a solution architect, what you need at minimum costs (time+money).
The options
Those are the available options to deploy your stuff into production:
1. docker-compose
First, you should know the difference between docker-compose and the normal docker run... we have docker-compose to orchestrate/manage a multi-services solution.
I know many people would come and shout "docker-compose isnt for production"... well, lemme tell you a story.
And at the time of building it, we were using a small linux box (we didnt have the wealth to run 4 VPSs or so), so we SSHed into it, installed git, then cloned the repo, filled the secrets and env vars, run docker-compose... and voila it worked perfectly fine to serve hundreds of user!
So I really dont care if people say it's not production ready, cuz it works perfectly fine on small scale.
2. AWS Elastic Beanstalk
This does exactly the same as docker-compose, but provides you more of control over the instances (in Amazon EC2) running those containers.
Ah... there is also a nice web GUI instead of controlling things using commands in docker-compose.
Here is the story behind it, time passed and we needed to scale, so we found that elastic beanstalk is easy to use like docker-compose and it offers scaling multi-image environment so easy... so it was time to move.
We have written the dockerrun aws file (similar to docker-compose file):
And now we can deploy in 4 mins and scale into any number of instances.
PS: This is a bit flawed cuz the db is in the same dockerrun file, and scaling the db doesnt work like usual scaling, but it's okay, cuz other services are scaling smoothly and that's the important part and we haven't needed to scale the db (yet).
3. Azure containers
If you're using Azure in your company, then you might need to use their services... there is no advantage that I know from any cloud provider to another... cuz the big three MS, Google, and Amazon are giving you superior power.
4. Kubernetes:
Same goes here, you can use it to manage/orchestrate your containers from Google.
5. Docker swarm
If you dont wanna do things using any cloud provider, go ahead and use docker swarm mode... it's like docker-compose
But the extra thing is the master-slave pattern, where you setup a master to manage containers on other machines (slaves).
There is a catch here, you wont have the spoil of GUI and you will have to setup every new instance (linux box or so) as a slave.
My recommendation is avoid it and use instead any cloud provider that makes your life easier.
6. Dozens of other container management solutions
Surely, there are many others... but seriously I would personally suggest to stick to the big three cuz they've got you covered in most cases.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Know your options
Well, you're on the right track but no one actually puts things clear when it comes to containers cuz everyone wants you to use their products 😆
Google Cloud, Azure, and AWS all have different solutions for your problem, but you need to choose the one that gives you, as a solution architect, what you need at minimum costs (time+money).
The options
Those are the available options to deploy your stuff into production:
1. docker-compose
First, you should know the difference between docker-compose and the normal docker run... we have docker-compose to orchestrate/manage a multi-services solution.
I know many people would come and shout "docker-compose isnt for production"... well, lemme tell you a story.
We built our programming academy:
coretabs.net
And at the time of building it, we were using a small linux box (we didnt have the wealth to run 4 VPSs or so), so we SSHed into it, installed git, then cloned the repo, filled the secrets and env vars, run docker-compose... and voila it worked perfectly fine to serve hundreds of user!
So I really dont care if people say it's not production ready, cuz it works perfectly fine on small scale.
2. AWS Elastic Beanstalk
This does exactly the same as docker-compose, but provides you more of control over the instances (in Amazon EC2) running those containers.
Ah... there is also a nice web GUI instead of controlling things using commands in docker-compose.
Here is the story behind it, time passed and we needed to scale, so we found that elastic beanstalk is easy to use like docker-compose and it offers scaling multi-image environment so easy... so it was time to move.
We have written the dockerrun aws file (similar to docker-compose file):
github.com/coretabs-academy/websit...
Then created an environment on elastic beanstalk, wrote a small script on gitlab to automate the deployment:
github.com/coretabs-academy/websit...
And now we can deploy in 4 mins and scale into any number of instances.
3. Azure containers
If you're using Azure in your company, then you might need to use their services... there is no advantage that I know from any cloud provider to another... cuz the big three MS, Google, and Amazon are giving you superior power.
4. Kubernetes:
Same goes here, you can use it to manage/orchestrate your containers from Google.
5. Docker swarm
If you dont wanna do things using any cloud provider, go ahead and use docker swarm mode... it's like docker-compose
But the extra thing is the master-slave pattern, where you setup a master to manage containers on other machines (slaves).
There is a catch here, you wont have the spoil of GUI and you will have to setup every new instance (linux box or so) as a slave.
My recommendation is avoid it and use instead any cloud provider that makes your life easier.
6. Dozens of other container management solutions
Surely, there are many others... but seriously I would personally suggest to stick to the big three cuz they've got you covered in most cases.