This container is the basis by which multiprocess StackEngine services are built.
Upon choosing runit as the init system
for such a container, the assumption is that it will need to be started.
Everything else is placing init scripts in /etc/sv/<service-name>.
# Sample Dockerfile
FROM stackhub/base-runit
MAINTAINER awesome_communitymember <[email protected]>
# Lot's of cool stuff here
For an example see our
stackhub/base-confd
image that makes it easy to leverage StackEngine Service Discovery.
If you would like to build your own multi-process container from this image or
play directly with runit run a detached container and contect to it.
%> docker run -d --name good_idea stackhub/base_runit
%> docker exec -it good_idea sh
/ #
A typical workflow might be to:
- install a process like haproxy, nginx or prometheus manually with the
apkpackage manager - get the init script correct for starting, stopping and reloading the process
- ensure that the logging is done properly (e.g. STDOUT and STDERR) so that
docker logsis the single source of truth for process information - ensure that when the process fails the container dies (i.e. avoids the "zombie container" problem)
- Write a Dockerfile from this research, build and test it.
- StackEngine Ecosystem
- General Docker Ecosystem
This image is generally useful as it does not leverage any of the special features of the StackEngine Container Application Center.
MIT