Iniciar e parar serviços como contêineres docker

Question

Eu gosto da idéia de isolar alguns serviços do servidor (como o MySQL), por exemplo, para contêineres e apenas fornecê-los aos serviços que precisam deles (digamos, SqlUsingApp).

Se eu entendi direito, a forma usual seria ter um SqlUsingApp e um contêiner MySQL, vinculado executando o SqlUsingApp por

docker run --link MySqlContainer:mysql SqlUsingApp 

No entanto, se o MySQL precisar ser reiniciado, iniciar o MySQLContainer quebrará o link e renderizará o SqlUsinApp sem utilidade. Este não é o modo como os serviços habituais funcionam, que são ligados por portas que podem ser reconectadas a qualquer momento se um dos serviços for reiniciado. Assim, um servidor comum com serviços não ancorados pode reiniciar qualquer um deles a qualquer momento sem precisar que outros sejam reiniciados também.

Qual é a solução no estilo docker para isso?

    

Answer 1

Eu uso fig (agora foi "renomeado" para docker-compose ) para resolver esse tipo de problema. Pode-se denotar os contêineres individuais de estivadores envolvidos em uma "implantação" (como eu chamarei por enquanto, por favor, qualquer um: poste um comentário se você conhece uma terminologia melhor. Fique comigo, sou alemão). Isso é feito na notação YAML em um arquivo chamado fig.ylm ( docker-compose.yml , se você migrou para o docker-compose). Você pode então iniciar, parar, etc. o conjunto descrito de contêineres por meio de comandos como fig start , fig stop .

O comando mais conveniente para executar as coisas seria fig up (cria tudo que contém e inicia todos eles como um único aplicativo com saída de console combinada).

Para fazer isso em scripts, de uma maneira parecida com o deamon, o parâmetro -d é de uso: fig up -d executa o shebang como um único daemon.

Link para a documentação do Fig: link

O mesmo ocorre com o docker-compose: link

Agora vou postar um exemplo completo de uma "implantação" do Gitlab, que consiste nos serviços Gitlab, Postgres e Redis. Ele é executado em um host Ubuntu e é iniciado automaticamente na inicialização do sistema por um script inicial:

O fig.yml (em /root/docker_gitlab/ no 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
   - [email protected]
   - SMTP_PASS=verysecret
   - GITLAB_HOST=projectserver
   - GITLAB_PORT=10080
   - GITLAB_SSH_PORT=10022
redis:
  image: sameersbn/redis:latest

O script upstart gitlab.conf (em /etc/init/ no 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

O figo parece ter sido tão "estilo docker", que a equipe docker o incorporou como docker-compose. Então tudo deve estar bem a esse respeito ...

    

Answer 2

Para daemons que os escutam, você pode enviar sinais para o contêiner docker, que os transmitirá para o que começou com CMD ou ENTRYPOINT. IIRC, o mysql irá reiniciar quando enviado um sinal HUP.

Infelizmente, essa não é uma solução universal. Aplicativos de terceiros como o geard tentam resolver alguns desses problemas fora da janela de encaixe.