Il daemon Docker non si avvia all'avvio su CoreOS

23

Ho un'installazione vanilla di CoreOS (835.9.0) e non avvia il daemon docker all'avvio. Inizia solo quando faccio SSH e faccio ad es docker ps.

Come posso fare in modo che il daemon docker si avvii automaticamente all'avvio del sistema?

Quando dico il demone docker, voglio dire ps -ef | grep dockernon mostra alcun processo fino a dopo che lo facciodocker ps

boot docker coreos

— Chris
fonte

40

sudo systemctl enable docker ha fatto il trucco.

— Chris
fonte

2

Grazie e ho letto i documenti Docker e non sono riuscito a trovare nulla che mi aiuti: ho trovato molto sui criteri di riavvio, ma ovviamente si applicano solo dopo l'avvio del daemon docker.

— Chris,

6

Sfondo: la radice di questo è perché la finestra mobile è attivata su socket CoreOS, cioè non blocca la catena di avvio. Le prime versioni della finestra mobile si avviavano lentamente quando c'erano molti contenitori su disco che impedivano l'avvio rapido di tutto ciò che dipendeva dalla finestra mobile, causando alcuni errori interessanti.

— Rob,

4

Bontà. Questo mi ha fatto impazzire. Nulla di ciò che ho letto in nessuno dei documenti menzionati. Ho quasi giurato CoreOS a favore di AWS AMI per questo. (AWS AMI avvia automaticamente il demone Docker per impostazione predefinita).

— Nostalg.io,

2

molto insolito per CoreOS comportarsi in questo modo, dato che CoreOS è un sistema operativo Docker dedicato e non si avvia docker durante l'avvio ???

— dattiloscritto il

3

Questa è un'informazione davvero cruciale. I documenti CoreOS non menzionano nulla sull'opportunità di abilitare Docker (o qualsiasi altro runtime del contenitore per quella materia). Dato che è possibile avviare container docker su CoreOS nudo (e poiché CoreOS è progettato per eseguire container), ho avuto l'impressione che fosse l'impostazione predefinita. Mi sono reso conto del mio errore solo quando il primo riavvio attivato dall'aggiornamento non ha avviato i miei contenitori.

— Florian von Stosch,

6

Adesso è un po 'vecchio, ma ho iniziato a usare cloud-init per farlo su tutti i nuovi server. Ho uno script cloud-init che utilizzo per tutti i miei server. Parte di esso contiene:

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

Ciò abiliterà il servizio docker e lo avvierà al primo avvio e ad ogni avvio.

— captncraig
fonte

2

Come già spiegato in questo commento da Rob , la finestra mobile è presa attivata. Ciò significa che il demone non si avvia a meno che non venga chiamato. Le risposte esistenti qui funzionano, ma CoreOS raccomanda un approccio diverso.

Il modo consigliato per farlo, secondo la documentazione di CoreOS, è creare un servizio per la propria app che a sua volta richiede il servizio 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 fai invece avviare automaticamente quel servizio:

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

Il caso d'uso di esempio è aggiornare il contenitore all'ultima versione una volta avviato il servizio e l'esempio avanzato registra anche il servizio in etcd. Leggi la documentazione CoreOS per ulteriori informazioni di base.

— Neograph734
fonte

Questo è "l'ultimo" di CoreOS? Docker ha adottato politiche di riavvio da anni e questo approccio non è più necessario o desiderabile. Non è mai stato davvero desiderabile, ma è stata una soluzione alternativa alla (molto vecchia versione) della mancanza di supporto di Docker per il riavvio dei container stessi. Molto tempo fa per smettere di usare CoreOS, immagino ...

— Michael Hampton

Le politiche di riavvio di @MichaelHampton si applicano anche quando il contenitore si arresta in modo anomalo per un altro motivo, quindi uno non è un sostituto per un altro. Inoltre, i criteri di riavvio non consentono di aggiornare i contenitori all'avvio, ecc. Non ho idea di quale sia il migliore, ma suppongo che questo metodo ti dia un po 'più di controllo.

— Neograph734,

1

Quando inizi a necessitare di un tale controllo, in genere hai anche bisogno di molti altri bit forniti dai servizi di orchestrazione: alla semplice fine docker-compose, fino a Kubernetes.

— Michael Hampton

1

Sto usando Docker Swarm, quindi non ho un'app specifica di cui Systemd sia responsabile ... Ho solo bisogno di Docker per iniziare all'avvio. Questa è la soluzione che ho elaborato.

Metti questo /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 poi solo systemctl enable poke-dockerper impostarlo per eseguire il trigger su ogni avvio, verso la fine della sequenza di avvio. Il docker versioncomando comunica con il daemon docker, attivando il socket e avviando il servizio docker stesso.

Ho provato il systemctl enable dockertrucco nell'altra risposta, e mentre inizialmente funzionava, sembra aver causato una situazione di mandria tuonante di qualche tipo in cui la docker stava apparentemente cercando di fare molto e fallendo miseramente. Sospetto che questo sia il comportamento di "blocco della catena di avvio" menzionato nei commenti lì.

— Colin Dunklau
fonte

Aveva lo stesso caso d'uso con gitlab-runner su uno sciame. Questo sicuramente sveglia il demone. È possibile aggiungere il drop-in systemd nel file di accensione coreos.com/os/docs/latest/using-systemd-drop-in-units.html

— drgn