3

I like the idea to isolate some server services (like MySQL) for example to containers and only provide them to the services needing them (say, SqlUsingApp).

If I understand that right, the usual way would be to have an SqlUsingApp and a MySQL container, linked by running the SqlUsingApp by

docker run --link MySqlContainer:mysql SqlUsingApp 

However, if MySQL needs to be restarted, starting the MySQLContainer breaks the link and renders SqlUsinApp useless. This is not the way usual services work, which are linked by ports that can reconnect at any time if one off the services gets restarted. So a usual server with non-dockered services can restart any of them at any time without needed others to be restarted as well.

What is the docker-style solution to this?

4

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...

0

For daemons that listen for them, you can send signals to the docker container which will pass them on to the thing started with CMD or ENTRYPOINT. IIRC, mysql will restart when sent a HUP signal.

Unfortunately, that's not a universal solution. Third party apps like geard try to solve some of those problems outside of docker.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.