Answers: <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-11-29T19:17:17.130Z
Answers: 2018-11-29T19:17:17.130Z
Answers: AnoE
Answers: <p>I hope you don't. </p>
  
  <p>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.  </p>
  
  <p>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.</p>
  
  <p>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? </p>
  
  <p>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.</p>
  
  <p>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. </p>
  
Answers: CC BY-SA 4.0
Answers: 2018-11-29T21:53:29.357Z
Answers: 2018-11-29T21:53:29.357Z
Answers: simbo1905
Answers: <p>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 <em>worse</em> than what you have currently? No.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-12-18T07:39:37.477Z
Answers: 2018-12-18T07:39:37.477Z
Answers: Xiong Chiamiov
Body: <p>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. </p>
  
  <p>So is it a good practice to run all your application in Docker in a single server?</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-11-29T11:21:19.970Z
Comments: This is opinionated. It depends! How *heavy* are the apps? But you write that the server will be used only for development purposes so I'd say its ok to run hundreds of apps or *serverless* like apps (one time jobs kind). There is not a good practise; better question would be *how can I maintain / orchestrate* hundreds of apps. One thing I see is that you will have accessing the apps (web apps I assume) but you can use https://github.com/jwilder/nginx-proxy for that.
Comments: Kyslik
Comments: CC BY-SA 4.0
Comments: 2018-11-29T12:22:03.820Z
Comments: Hey mate, yeah I am using the Nginx proxy for now. Thanks for the reply. I have multiple projects of  Django, PHP, node, angular to be migrated to the server and yeah, it's only for development purposes.
Comments: Shibily
Tags: <docker><docker-compose>
Title: Should I run several applications in Docker in a single server?
UserDisplayName: Shibily
ThreadText: # Should I run several applications in Docker in a single server?
  
  (Asked by: username_0 on 2018-11-29)
  
  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?
  
  **Tags:** docker, docker-compose
  
  > **Comments:**
  > **username_1**: This is opinionated. It depends! How *heavy* are the apps? But you write that the server will be used only for development purposes so I'd say its ok to run hundreds of apps or *serverless* like apps (one time jobs kind). There is not a good practise; better question would be *how can I maintain / orchestrate* hundreds of apps. One thing I see is that you will have accessing the apps (web apps I assume) but you can use https://github.com/jwilder/nginx-proxy for that.  
  > **username_0**: Hey mate, yeah I am using the Nginx proxy for now. Thanks for the reply. I have multiple projects of  Django, PHP, node, angular to be migrated to the server and yeah, it's only for development purposes.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_2 on 2018-11-29. Score: 0 | Accepted answer
  
  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.
  
  
  ---
  
  ### Answer by username_3 on 2018-11-29. Score: 0
  
  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.
  
  
  ---
  
  ### Answer by username_4 on 2018-12-18. Score: 0
  
  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.
  
  
  ---
  
  