Docker Daemon no comienza en el arranque en CoreOS

23

Tengo una instalación estándar de CoreOS (835.9.0) y no inicia el Docker Daemon al inicio. Solo comienza cuando hago SSH y hago, por ejemplo docker ps.

¿Cómo puedo hacer que el Docker Daemon se inicie automáticamente en el arranque del sistema?

Cuando digo el demonio de Docker, quiero decir que ps -ef | grep dockerno muestra ningún proceso hasta después de hacerlodocker ps

boot docker coreos

— Chris
fuente

40

sudo systemctl enable docker Hizo el truco.

— Chris
fuente

2

Gracias, y leí los documentos de Docker y no pude encontrar nada para ayudar. Encontré mucho sobre las políticas de reinicio, pero por supuesto solo se aplican una vez que se inicia el demonio de Docker.

— Chris

66

Antecedentes: la raíz de esto se debe a que Docker está activado por socket en CoreOS, es decir, no bloquea la cadena de arranque. Las primeras versiones de Docker tardaron en iniciarse cuando tenía muchos contenedores en el disco que bloqueaban todo lo que dependía de que Docker se iniciara rápidamente, lo que causaba algunas fallas interesantes.

— Rob

44

Bondad. Esto me volvió loco. Nada de lo que leí en ninguno de los documentos menciona esto. Casi renuncié a CoreOS a favor de AWS AMI por eso. (AWS AMI inicia automáticamente el demonio Docker de forma predeterminada).

— Nostalg.io

2

¿Es muy inusual que CoreOS se comporte de esta manera, dado que CoreOS es un Docker OS dedicado y no está iniciando Docker durante el arranque?

— typelogic

3

Esta es una información seriamente crucial. Los documentos de CoreOS no mencionan nada acerca de tener que habilitar Docker (o cualquier otro tiempo de ejecución del contenedor). Como es posible iniciar los contenedores acoplables en CoreOS desnudo (y dado que CoreOS está hecho para ejecutar contenedores), tenía la impresión de que era el valor predeterminado. Solo me di cuenta de mi error cuando el primer reinicio activado por la actualización no inició mis contenedores.

— Florian von Stosch

6

Esto es un poco viejo ahora, pero he comenzado a usar cloud-init para hacer esto en todos los servidores nuevos. Tengo una secuencia de comandos de inicio en la nube que uso para todos mis servidores. Parte de ella contiene:

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

Esto habilitará el servicio Docker y lo iniciará primero y en cada arranque.

— captncraig
fuente

2

Como ya se explicó en este comentario de Rob , la ventana acoplable está activada por socket. Eso significa que el demonio no se inicia a menos que se llame. Las respuestas existentes aquí funcionan, pero CoreOS recomienda un enfoque diferente.

La forma recomendada de hacer esto, de acuerdo con la documentación de CoreOS es crear un servicio para su propia aplicación que a su vez requiera el servicio 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

Y haga que ese servicio se inicie automáticamente en su lugar:

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

El caso de uso de ejemplo es actualizar el contenedor a la última versión una vez que se inicia el servicio y el ejemplo avanzado también registra el servicio en etcd. Lea la documentación de CoreOS para obtener más información de fondo.

— Neograph734
fuente

¿Esa es la "última" de CoreOS? Docker ha tenido políticas de reinicio durante años y este enfoque ya no es necesario ni deseable. Nunca fue realmente deseable, pero fue una solución para la falta de soporte de Docker (versiones muy antiguas de) para reiniciar los contenedores. Ya es hora de dejar de usar CoreOS, supongo ...

— Michael Hampton

Las políticas de reinicio de @MichaelHampton también se aplican cuando el contenedor se bloquea por otra razón, por lo que una no reemplaza a otra. Además, las políticas de reinicio no le permiten actualizar contenedores en el arranque, etc. No tengo idea de cuál es mejor, pero supongo que este método le da un poco más de control.

— Neograph734

1

Cuando comienzas a necesitar tanto control, generalmente también necesitas muchos otros bits que son proporcionados por los servicios de orquestación: en el extremo simple compilación acoplable, hasta Kubernetes.

— Michael Hampton

1

Estoy usando Docker Swarm, por lo que no tengo una aplicación específica para que systemd sea responsable ... Solo necesito docker para iniciar el arranque. Esta es la solución que resolví.

Pon esto /etc/systemd/system/poke-docker.service:

[Unit]
After=default.target

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

[Install]
WantedBy=default.target

Y luego solo systemctl enable poke-dockerpara configurarlo para que se active en cada arranque, cerca del final de la secuencia de inicio. El docker versioncomando habla con el demonio docker, activa el socket e inicia el servicio docker.

Intenté el systemctl enable dockertruco en la otra respuesta, y aunque funcionó al principio, parece haber causado una situación de manada atronadora de algún tipo donde Docker aparentemente intentaba hacer mucho y fallaba miserablemente. Sospecho que este es el comportamiento de "bloqueo de la cadena de arranque" mencionado en los comentarios allí.

— Colin Dunklau
fuente

Tenía el mismo caso de uso ejecutando gitlab-runner en un enjambre. Esto definitivamente despierta al demonio. Puede agregar el menú desplegable systemd en su archivo de encendido coreos.com/os/docs/latest/using-systemd-drop-in-units.html

— drgn