4 ms·

Question: If I were to deploy a rails app using docker, can I put the whole stack in a single container (ruby/postgres/redis/sidekiq/etc.) Or do I need a separ

by andyl 13y ago

Question: If I were to deploy a rails app using docker, can I put the whole stack in a single container (ruby/postgres/redis/sidekiq/etc.) Or do I need a separate container for each process?

alfor 13y ago
Yes, you could, but in this case it mean they will all run on the same vm and your system is going to be simpler but less flexible.
- sneak 13y ago
  Linux containers are not virtual machines.
jetblackio 13y ago
I'm curious about this as well. From what I've read, it seems like it would be possible to have separate containers for each process, and then combine them together into a single container for deployment. If that works in reality, it could make it easier to mix-and-match to quickly build new applications that share some common dependencies.
jamtur01 13y ago
You can do both. Docker containers by default are designed to run a single process but you can use a process manager like supervisord or a script to run many too.
- FooBarWidget 13y ago
  It's nonsense that Docker containers are designed to run a single process. There's absolutely nothing that encourages having a single process. In fact, I think you should run multiple processes because running just a single process is wrong. It will not enable many kinds of important system services, such as syslog. Take a look at https://github.com/phusion/baseimage-docker https://github.com/phusion/baseimage-docker for a full explanation. This is also the reason why I wrote baseimage-docker: to make it easy for other Docker users to get things right. I highly encourage people to use baseimage-docker.
  - pjungwir 13y ago
    I'll look at your Github repo, but is there any documentation on running multiple processes per container? The tutorials on docker.io all include just one process. And having separate ENTRYPOINT and USER directives suggests that if you want to run several things at once, they must all run as the same user.
    - FooBarWidget 13y ago
      My Github repo is the documentation. It teaches you how to run multiple processes by having them managed through runit. It even provides a script to make it easy for you to run a process as a different user. > And having separate ENTRYPOINT and USER directives suggests that if you want to run several things at once, they must all run as the same user. It does not. That's not how the Unix process model works. When you boot the Linux kernel, it also wants you to specify a single entry point. The kernel starts that process as root. Yet your Linux system clearly has multiple processes, running as different users. Why? It's because the entry point is the init system, which spawns other processes. You can do the same thing inside Docker. It's exactly the same as how your host system works! Nothing has changed!
      - pjungwir 13y ago
        Okay, thank you for putting all that together. Running everything out of runit/etc is about what I figured I'd do if I wanted multiple services in one container, so it's great someone has already done all the work for me. :-)
  - jamtur01 13y ago
    Politely it's not bollocks but perhaps I should have used better wording and replaced "process" with "service". :) I look at Docker as a lightweight way of modeling infrastructure and services. I can built a shipload/stack of containers that model/mock/replicate my application architecture or my SOA model or my three tier web application. At the crudest level I can do this by modeling each host (web/app/db for example) with a container (hence single service) but it has the potential to scale up to large, clustered SOA applications too. Having that local model of my application means I am developing something that is a lot closer to reality than running a bunch of services on a shrunken set/consolidated set of hosts (or worse on my desktop) in a dev/test environment. Apologies for confusing the situation.
finnh 13y ago
Up to you. If it's a one-shot site that won't grow, then a single container is fine. But if you might grow, the upfront discipline of splitting them into separate containers will make it much easier to scale & distribute later. Also, while you're likely to find pre-packaged dockerfiles for each of your components, the odds are lower that you'll find an existing dockerfile that has your exact stack all-in-one. So, while the "one container" approach may save you some cross-container configuration overhead, it will likely cost you extra dockerfile creation time.

by andyl 13y ago

Question: If I were to deploy a rails app using docker, can I put the whole stack in a single container (ruby/postgres/redis/sidekiq/etc.) Or do I need a separate container for each process?

alfor 13y ago

Yes, you could, but in this case it mean they will all run on the same vm and your system is going to be simpler but less flexible.

sneak 13y ago
Linux containers are not virtual machines.

jetblackio 13y ago

I'm curious about this as well. From what I've read, it seems like it would be possible to have separate containers for each process, and then combine them together into a single container for deployment. If that works in reality, it could make it easier to mix-and-match to quickly build new applications that share some common dependencies.

jamtur01 13y ago

You can do both. Docker containers by default are designed to run a single process but you can use a process manager like supervisord or a script to run many too.

FooBarWidget 13y ago
It's nonsense that Docker containers are designed to run a single process. There's absolutely nothing that encourages having a single process. In fact, I think you should run multiple processes because running just a single process is wrong. It will not enable many kinds of important system services, such as syslog. Take a look at https://github.com/phusion/baseimage-docker https://github.com/phusion/baseimage-docker for a full explanation. This is also the reason why I wrote baseimage-docker: to make it easy for other Docker users to get things right. I highly encourage people to use baseimage-docker.
- pjungwir 13y ago
  I'll look at your Github repo, but is there any documentation on running multiple processes per container? The tutorials on docker.io all include just one process. And having separate ENTRYPOINT and USER directives suggests that if you want to run several things at once, they must all run as the same user.
  - FooBarWidget 13y ago
    My Github repo is the documentation. It teaches you how to run multiple processes by having them managed through runit. It even provides a script to make it easy for you to run a process as a different user. > And having separate ENTRYPOINT and USER directives suggests that if you want to run several things at once, they must all run as the same user. It does not. That's not how the Unix process model works. When you boot the Linux kernel, it also wants you to specify a single entry point. The kernel starts that process as root. Yet your Linux system clearly has multiple processes, running as different users. Why? It's because the entry point is the init system, which spawns other processes. You can do the same thing inside Docker. It's exactly the same as how your host system works! Nothing has changed!
    - pjungwir 13y ago
      Okay, thank you for putting all that together. Running everything out of runit/etc is about what I figured I'd do if I wanted multiple services in one container, so it's great someone has already done all the work for me. :-)
- jamtur01 13y ago
  Politely it's not bollocks but perhaps I should have used better wording and replaced "process" with "service". :) I look at Docker as a lightweight way of modeling infrastructure and services. I can built a shipload/stack of containers that model/mock/replicate my application architecture or my SOA model or my three tier web application. At the crudest level I can do this by modeling each host (web/app/db for example) with a container (hence single service) but it has the potential to scale up to large, clustered SOA applications too. Having that local model of my application means I am developing something that is a lot closer to reality than running a bunch of services on a shrunken set/consolidated set of hosts (or worse on my desktop) in a dev/test environment. Apologies for confusing the situation.

finnh 13y ago

Up to you. If it's a one-shot site that won't grow, then a single container is fine. But if you might grow, the upfront discipline of splitting them into separate containers will make it much easier to scale & distribute later. Also, while you're likely to find pre-packaged dockerfiles for each of your components, the odds are lower that you'll find an existing dockerfile that has your exact stack all-in-one. So, while the "one container" approach may save you some cross-container configuration overhead, it will likely cost you extra dockerfile creation time.