Мне нравится идея изолировать некоторые серверные службы (например, MySQL), например, от контейнеров и предоставлять их только тем службам, которые в них нуждаются (например, SqlUsingApp).
Если я правильно понимаю, обычным способом было бы иметь SqlUsingApp и контейнер MySQL, связанные путем запуска SqlUsingApp с помощью
docker run --link MySqlContainer:mysql SqlUsingApp
Однако, если необходимо перезапустить MySQL, запуск MySQLContainer разрывает ссылку и делает SqlUsinApp бесполезным. Это не способ работы обычных служб, которые связаны портами, которые могут повторно подключиться в любое время, если одна из служб будет перезапущена. Таким образом, обычный сервер с незакрепленными службами может перезапустить любой из них в любое время без необходимости перезапуска других.
Какое решение в стиле докеров для этого?
Я использую fig (теперь "переименован" в docker-compose) для решения этой проблемы. Можно обозначить отдельные док-контейнеры, участвующие в «развертывании» (так я буду называть это сейчас, пожалуйста, кому угодно: оставьте комментарий, если вы знаете терминологию получше. Потерпите меня, я немец). Это делается в нотации YAML в файле с именем fig.ylm (docker-compose.yml если вы перешли на docker-compose). Затем вы можете запускать, останавливать и т. Д. Описанный набор контейнеров с помощью таких команд, как fig start, fig stop.
Самая удобная команда для запуска вещей: fig up (строит все, что содержит, и запускает все как одно приложение с комбинированным выводом на консоль).
Чтобы сделать это в скриптах, как в демоне, можно использовать параметр -d: fig up -d управляет всем шебангом как один-единственный демон.
Ссылка на документацию Fig: http://www.fig.sh
То же самое для docker-compose: https://docs.docker.com/compose/
Сейчас я отправлю вам полный пример «развертывания» Gitlab, состоящего из сервисов Gitlab, Postgres и Redis. Он работает на хосте Ubuntu и запускается автоматически при загрузке системы с помощью сценария выскочки:
В fig.yml (в /root/docker_gitlab/ на хосте):
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
Сценарий выскочки gitlab.conf (в /etc/init/ на хосте):
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 был настолько "в стиле докера", что команда docker включила его как docker-compose. Так что в этом отношении все должно быть хорошо ...
Для демонов, которые их слушают, вы можете отправлять сигналы в контейнер докеров, который передаст их объекту, запущенному с CMD или ENTRYPOINT. IIRC, mysql перезапустится при отправке сигнала HUP.
К сожалению, это не универсальное решение. Сторонние приложения, такие как geard, пытаются решить некоторые из этих проблем за пределами докера.