DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
I have a server,32Gb ram, i7 processor and 2TB hard disk, with Docker engine running in it. I have like 100 development application to be migrated to this docker server.
So is it a good practice to run all your application in Docker in a single server?
Yes, sure. As long as your resources are enough (i.e., you're not running out of RAM, HDD, CPU, networking), and as long as you are fine with one gigantic single point of failure, there is no reason whatsoever to not run many docker containers on one machine.
Keep in mind that the overhead of docker is really small - it's all just namespacing on the host kernel, it's not like you're spawning copious amounts of VMs or anything like that.
I hope you don't.
Let's assume that cost is paramount. There is no money for a second server. Then the question doesn't apply as you cannot use more than one server. So the cost of a second server must be okay.
Then why wouldn't you take the opportunity to automate the setting up and administration of more than one machine? Then use the development environment with multiple machines as a test place to practice high availability, DR and how to run systems spanning multiple machines.
Are you intending to run more than one server in production with automatic failover when machines die but are not going to set that up in development? How do you know that automation will every work in production if you haven't practised in development?
With devops having development, or test, not behave like production always leads to problems. Nothing quite work first time in production so isn't automated, and production is never "fixed" as we don't feel the pain in development, so we just release less often to space out the pain, which isn't at all the spirit of devops.
Have the ambition to learn everything that you will do in production by practising making development like production, feel the pain of that, and change production until there is no pain doing the same things in development. You don't have to have the entire scale of production in development as that would be expensive, but at a minimum two servers that you can easily shift things between, or run a service across as highly available, is a huge leap over having a single server.
Best practice? No, it's better to have a bunch of smaller nodes so you can make your services better distributed for availability reasons. But will it be any worse than what you have currently? No.
