I do use fig
(has now been "renamed" to docker-compose
) to adress this type of problem. One can denote the individual docker containers involved in a "deployment" (as I will call it for now, please anyone: post a comment if you know better terminology. Bear with me, I'm german). This is done in YAML notation in a file named fig.ylm
(docker-compose.yml
if you have migrated to docker-compose). You are then able to start, stop, etc. the described set of containers via commands like fig start
, fig stop
.
The most convenient command to get things running would be fig up
(builds all contains and starts all of them like a single application with combined console output).
To do this in scripts, in a deamon like fashion, the -d parameter is of use: fig up -d
runs the whole shebang like a single daemon.
Link to Fig documentation: http://www.fig.sh
Same for docker-compose: https://docs.docker.com/compose/
I will now post you a complete example of a Gitlab "deployment" consisting of the services Gitlab, Postgres and Redis. It runs on a Ubuntu host, and is started automatically at system boot by an upstart script:
The fig.yml
(at /root/docker_gitlab/
on host):
postgresql:
image: sameersbn/postgresql:9.1-1
environment:
- DB_USER=gitlab
- DB_PASS=secretpassword
- DB_NAME=gitlabhq_production
gitlab:
image: sameersbn/gitlab:latest
links:
- redis:redisio
- postgresql:postgresql
ports:
- "10080:80"
- "10022:22"
volumes:
- /opt/gitlab/data:/home/git/data
environment:
- SMTP_HOST=smtp.germanprovider.de
- SMTP_USER=secret@secret.de
- SMTP_PASS=verysecret
- GITLAB_HOST=projectserver
- GITLAB_PORT=10080
- GITLAB_SSH_PORT=10022
redis:
image: sameersbn/redis:latest
The upstart script gitlab.conf
(at /etc/init/
on host):
description "gitlab service runner"
start on filesystem and started docker
stop on runlevel [!2345]
respawn
chdir /root/docker_gitlab
script
# Wait for docker to finish starting up first.
FILE=/var/run/docker.sock
while [ ! -e $FILE ] ; do
inotifywait -t 2 -e create $(dirname $FILE)
done
/usr/local/bin/fig start
end script
Fig seems to have been so "docker-style", that the docker team incorporated it as docker-compose. So all should be fine in that regard...
Assuming of course that you're using an SELinux-enabled Docker (RHEL/CentOS 7 and Fedora) then you shouldn't need to do anything aside from make sure that SELinux is enabled and enforcing on the host machine.
The containers created with Docker or virsh are automatically assigned with an SELinux context specified in the SELinux policy.
You may want to check the security context that your container's processes run under. To do so, add the -Z
option to ps
. For example:
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:virtd_lxc_t:s0:c5,c342 26351 ? Ss 0:00 /sbin/init
system_u:system_r:virtd_lxc_t:s0:c5,c342 26458 ? Ss 0:00 /usr/sbin/sshd -D
Note that SELinux itself is not namespaced, so you can't have separate SELinux policies within containers, as if they were independent OS installations.
This also doesn't appear to be as well-developed (yet) as SELinux for containers managed by libvirt. But in general it shouldn't be something you need to worry much about.
Best Answer
Use a frontend proxy like nginx (for relatively static backends) or hipache (for rapidly changing backends, for example if you are going to replace containers every hour or so and don't want to change the nginx config). The frontend proxy will listen on ports 80 and 443 and redirect the request to the right backend. I run 10 or so websites behind a single IP that way.