Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running more than one service #2

Closed
zimmski opened this issue Mar 23, 2015 · 12 comments
Closed

Running more than one service #2

zimmski opened this issue Mar 23, 2015 · 12 comments

Comments

@zimmski
Copy link

zimmski commented Mar 23, 2015

I want to use your openSUSE base images for some internal showcases. The problem is that I need to run more than one service inside the container e.g. PostgreSQL and some other applications.

What are you recommending for doing this? It would be ideal if I could use the usual systemctl/service commands to enable/start services.

(I know that it is best practice to use just one service per container but the images I need to create are special use-cases which run for a few days/weeks and are then just thrown away.)

@darix
Copy link
Member

darix commented Mar 23, 2015

just run the normal init system

@zimmski
Copy link
Author

zimmski commented Mar 23, 2015

You mean like this?

FROM opensuse:latest
MAINTAINER M Z

RUN zypper --non-interactive --gpg-auto-import-keys ref
RUN zypper --non-interactive install perl postgresql-server && systemctl enable postgresql.service

EXPOSE 5432

ENTRYPOINT ["/sbin/init"]

@flavio
Copy link
Member

flavio commented Mar 23, 2015

/sbin/init on recent versions of openSUSE is provided by systemd, which cannot run right now inside of Docker containers (despite of the host/guest combination).

You could rely on a simpler init system like runit or you could just use a script as entry point. Inside of the script you could start all the daemons you need. The only drawback of this approach is to take care of the cleanup of the running processes once the container is killed/stopped.

@tboerger
Copy link
Contributor

There are various options for doing this like runit, monit or even something in the python world. I think there is no solution to rule them all :)

@darix
Copy link
Member

darix commented Mar 23, 2015

or you could just one container per app and let them talk via network?;)

@tboerger
Copy link
Contributor

or you could just one container per app and let them talk via network?;)

That's the way how it should work :). But there are cases where i have done it different, like a rails application with a worker queue and a clockwork component, there i have added a Procfile (which gets processed by foreman) like it is available on Heroku.

@darix
Copy link
Member

darix commented Mar 23, 2015

well while it is ugly to duplicate the rails code into multiple containers, it is not different from the ugliness of having to duplicate all the libs+data files for each service.

@zimmski
Copy link
Author

zimmski commented Mar 23, 2015

I am trying to get as close to a normal VM as possible so it would be nice if systemctl/service would work. Usually i am using "supervisor" but that is not what I want to do with this project.

@tboerger
Copy link
Contributor

But containers are not compareable with virtual machines

@darix
Copy link
Member

darix commented Mar 23, 2015

so do one container per app and let them talk via network?

flavio just pointed me to:

hth.

p.s.: before i moved to systemd's restart feature i had been using runit for this.

@zimmski
Copy link
Author

zimmski commented Mar 23, 2015

I am aware of the container vs VM discussions, docker best practices, and so on. I do not want to discuss this here.

I want to discuss how more than one service could be started with their init/systemd files, run by a processmanager/init system using the openSUSE image as its base in the easiest way possible. Since using systemd does not seem to work, yet (@darix: I read the same articles, privileged containers are a no-go) I will try to use a simple bash script to start the services thanks @flavio I hope this works for us.

@flavio
Copy link
Member

flavio commented Jun 30, 2015

Closing, not pertinent with this project

@flavio flavio closed this as completed Jun 30, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants