9 ms·

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 to

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.
- josh-wrale 13y ago
  Do you have a Docker trusted build for this? http://blog.docker.io/2013/11/introducing-trusted-builds/ http://blog.docker.io/2013/11/introducing-trusted-builds/
  - FooBarWidget 13y ago
    No, I do it manually. I don't want each commit to result in a new image. I only release new versions when it's been thoroughly enough tested. It's supposed to be a stable base image that other people can rely on, not a bleeding edge thing.
    - josh-wrale 13y ago
      Thank you. I think I asked the wrong question, in a way. Is this on index.docker.io, so I can base on it, or do I need to do the Docker build for it locally? You really needn't answer, because I can go research the answers when I get off of work. :) Thanks again.
      - FooBarWidget 13y ago
        Yes it is. See the Github repo. All information is there in the README, including detailed usage and download instructions and build instructions.

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.
josh-wrale 13y ago
Do you have a Docker trusted build for this? http://blog.docker.io/2013/11/introducing-trusted-builds/ http://blog.docker.io/2013/11/introducing-trusted-builds/
- FooBarWidget 13y ago
  No, I do it manually. I don't want each commit to result in a new image. I only release new versions when it's been thoroughly enough tested. It's supposed to be a stable base image that other people can rely on, not a bleeding edge thing.
  - josh-wrale 13y ago
    Thank you. I think I asked the wrong question, in a way. Is this on index.docker.io, so I can base on it, or do I need to do the Docker build for it locally? You really needn't answer, because I can go research the answers when I get off of work. :) Thanks again.
    - FooBarWidget 13y ago
      Yes it is. See the Github repo. All information is there in the README, including detailed usage and download instructions and build instructions.