O daemon do Docker não inicia na inicialização no CoreOS

23

Eu tenho uma instalação básica do CoreOS (835.9.0) e ele não inicia o daemon do docker na inicialização. Só começa quando eu SSH e faço por exemplo docker ps.

Como posso fazer o daemon do docker iniciar automaticamente na inicialização do sistema?

Quando digo o daemon do docker, quero dizer ps -ef | grep dockernão mostra processos até depois de o fazerdocker ps

boot docker coreos

— Chris
fonte

40

sudo systemctl enable docker fez o truque.

— Chris
fonte

2

Obrigado e li os documentos do Docker e não consegui encontrar nada para ajudar - descobri muito sobre políticas de reinicialização, mas é claro que elas só se aplicam quando o daemon do docker é iniciado.

— 21415 Chris

6

Antecedentes: a raiz disso é porque o docker é ativado por soquete no CoreOS, ou seja, não bloqueia a cadeia de inicialização. As versões anteriores do docker demoravam a iniciar quando havia muitos contêineres no disco, o que impedia que tudo o que dependia do docker fosse iniciado rapidamente, o que causava algumas falhas interessantes.

— Rob

4

Bondade. Isso me deixou louco. Nada do que li em nenhum dos documentos mencionou isso. Eu quase xinguei o CoreOS em favor da AWS AMI por causa disso. (AWS AMI inicia automaticamente o daemon do Docker por padrão).

— Nostalg.io

2

muito incomum para o CoreOS se comportar dessa maneira, já que o CoreOS é um sistema operacional Docker dedicado e não inicia o docker durante a inicialização ???

— typelogic

3

Esta é uma informação seriamente crucial. Os documentos do CoreOS não mencionam nada sobre a necessidade de habilitar o Docker (ou qualquer outro tempo de execução do contêiner). Como é possível iniciar contêineres de docker no CoreOS vazio (e como o CoreOS foi criado para executar contêineres), fiquei com a impressão de que era o padrão. Só percebi meu erro quando a primeira reinicialização acionada por atualização não inicializou meus contêineres.

— Florian von Stosch

6

Isso é um pouco antigo agora, mas comecei a usar o cloud-init para fazer isso em todos os novos servidores. Tenho um script cloud-init salvo que uso em todos os meus servidores. Parte dela contém:

#cloud-config
coreos:
  units:
    - name: "docker.service"
      command: "start"
      enable: true

Isso habilitará o serviço docker e o iniciará primeiro e em cada inicialização.

— captncraig
fonte

2

Como já explicado neste comentário por Rob , o docker é ativado por soquete. Isso significa que o daemon não inicia a menos que seja chamado. As respostas existentes aqui funcionam, mas o CoreOS recomenda uma abordagem diferente.

A maneira recomendada de fazer isso, de acordo com a documentação do CoreOS, é criar um serviço para seu próprio aplicativo que, por sua vez, exija o serviço Docker:

/etc/systemd/system/myapp.service:

[Unit]
Description=MyApp
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill busybox1
ExecStartPre=-/usr/bin/docker rm busybox1
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/sh -c "trap 'exit 0' INT TERM; while true; do echo Hello World; sleep 1; done"

[Install]
WantedBy=multi-user.target

E faça com que esse serviço seja iniciado automaticamente:

$ sudo systemctl enable /etc/systemd/system/myapp.service
$ sudo systemctl start hello.service

O exemplo de caso de uso é atualizar o contêiner para a versão mais recente assim que o serviço iniciar e o exemplo avançado também registra o serviço no etcd. Leia a documentação do CoreOS para obter mais informações.

— Neograph734
fonte

Essa é a "mais recente" do CoreOS? O Docker possui políticas de reinicialização há anos e essa abordagem não é mais necessária ou desejável. Nunca foi realmente desejável, mas foi uma solução alternativa para a (muito antiga versão) da falta de suporte do Docker para reiniciar os contêineres. Muito tempo para parar de usar o CoreOS, eu acho ...

— Michael Hampton

As políticas de reinicialização @MichaelHampton também se aplicam quando o contêiner falha por outro motivo; portanto, um não substitui o outro. Além disso, as políticas de reinicialização não permitem a atualização de contêineres na inicialização, etc. Não tenho idéia do que é melhor, mas suponho que esse método lhe dê um pouco mais de controle.

— Neograph734

1

Quando você começa a precisar de tanto controle, geralmente também precisa de muitos outros bits fornecidos pelos serviços de orquestração: no final do docker-compondo simples, até o Kubernetes.

— Michael Hampton

1

Estou usando o Docker Swarm, por isso não tenho um aplicativo específico para o systemd ser responsável ... Só preciso do docker para iniciar a inicialização. Esta é a solução que resolvi.

Coloque isto /etc/systemd/system/poke-docker.service:

[Unit]
After=default.target

[Service]
Type=oneshot
ExecStart=/usr/bin/docker version
RemainAfterExit=yes

[Install]
WantedBy=default.target

E então apenas systemctl enable poke-dockerpara configurá-lo para disparar em cada inicialização, perto do final da sequência de inicialização. O docker versioncomando conversa com o daemon do docker, acionando o soquete e iniciando o próprio serviço do docker.

Tentei o systemctl enable dockertruque na outra resposta e, embora tenha funcionado a princípio, parece ter causado algum tipo de situação de rebanho, onde o estivador aparentemente estava tentando fazer muito e falhando miseravelmente. Eu suspeito que esse seja o comportamento "bloqueando a cadeia de inicialização" mencionado nos comentários.

— Colin Dunklau
fonte

Teve o mesmo caso de uso executando o gitlab-runner em um enxame. Isso definitivamente acorda o daemon. Você pode adicionar o drop-in systemd no seu arquivo de ignição coreos.com/os/docs/latest/using-systemd-drop-in-units.html

— drgn