Le démon Docker ne démarre pas au démarrage sur CoreOS

23

J'ai une installation vanilla de CoreOS (835.9.0) et il ne démarre pas le démon docker au démarrage. Il ne démarre que lorsque je SSH et fais par exemple docker ps.

Comment puis-je faire démarrer automatiquement le démon docker au démarrage du système?

Quand je dis le démon docker, je veux dire ps -ef | grep dockerne montre aucun processus jusqu'à ce que je le fassedocker ps

boot docker coreos

— Chris
source

40

sudo systemctl enable docker a fait l'affaire.

— Chris
source

2

Merci, et j'ai lu les documents Docker et je n'ai rien trouvé pour aider - j'ai beaucoup trouvé sur les politiques de redémarrage, mais bien sûr, elles ne s'appliquent qu'une fois le démon docker démarré.

— Chris

6

Contexte: La racine de ceci est que le docker est activé par socket sur CoreOS, c'est-à-dire qu'il ne bloque pas la chaîne de démarrage. Les premières versions de docker ont été lentes à démarrer lorsque vous disposiez de nombreux conteneurs sur le disque, ce qui a empêché tout ce qui dépendait du docker de démarrer rapidement, ce qui a provoqué des échecs intéressants.

— Rob

4

La bonté. Cela m'a rendu fou. Rien de ce que j'ai lu dans aucun des documents ne le mentionne. J'ai failli jurer CoreOS en faveur d'AWS AMI à cause de cela. (AWS AMI démarre automatiquement le démon Docker par défaut).

— Nostalg.io

2

très inhabituel pour CoreOS de se comporter de cette façon, étant donné que CoreOS est un système d'exploitation Docker dédié et qu'il ne démarre pas Docker au démarrage ???

— typelogic

3

Il s'agit d'une information sérieusement cruciale. Les documents CoreOS ne mentionnent rien sur la nécessité d'activer Docker (ou tout autre runtime de conteneur d'ailleurs). Puisqu'il est possible de démarrer des conteneurs Docker sur CoreOS nu (et puisque CoreOS est conçu pour exécuter des conteneurs), j'avais l'impression que c'était la valeur par défaut. Je n'ai réalisé mon erreur que lorsque le premier redémarrage déclenché par la mise à jour n'a pas démarré mes conteneurs.

— Florian von Stosch

6

C'est un peu vieux maintenant, mais j'ai commencé à utiliser cloud-init pour le faire sur tous les nouveaux serveurs. J'ai un script cloud-init enregistré que j'utilise pour tous mes serveurs. Une partie contient:

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

Cela activera le service docker et le démarrera au premier et à chaque démarrage.

— captncraig
source

2

Comme déjà expliqué dans ce commentaire par Rob , le docker est activé par socket. Cela signifie que le démon ne démarre que s'il est appelé. Les réponses existantes fonctionnent ici, mais CoreOS recommande une approche différente.

La façon recommandée de le faire, selon la documentation CoreOS, est de créer un service pour votre propre application qui à son tour nécessite le service 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

Et que ce service démarre automatiquement à la place:

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

L'exemple d'utilisation consiste à mettre à jour le conteneur vers la dernière version une fois le service démarré et l'exemple avancé enregistre également le service dans etcd. Lisez la documentation CoreOS pour plus d'informations de fond.

— Neograph734
source

C'est le "dernier" de CoreOS? Docker a des politiques de redémarrage depuis des années et cette approche n'est plus nécessaire ou souhaitable. Cela n'a jamais été vraiment souhaitable, mais c'était une solution de contournement pour le manque de support de Docker (très anciennes versions) pour redémarrer les conteneurs lui-même. Il est longtemps passé d'arrêter d'utiliser CoreOS, je suppose ...

— Michael Hampton

Les politiques de redémarrage de @MichaelHampton s'appliquent également lorsque le conteneur se bloque pour une autre raison, donc l'un ne remplace pas un autre. De plus, les politiques de redémarrage ne vous permettent pas de mettre à jour les conteneurs au démarrage, etc. Je n'ai aucune idée de ce qui est mieux, mais je suppose que cette méthode vous donne un peu plus de contrôle.

— Neograph734

1

Lorsque vous commencez à avoir besoin de tant de contrôle, vous avez également généralement besoin de beaucoup d'autres bits fournis par les services d'orchestration: à la simple docker-compose, jusqu'à Kubernetes.

— Michael Hampton

1

J'utilise Docker Swarm, donc je n'ai pas d'application spécifique pour que systemd soit responsable ... J'ai juste besoin de docker pour démarrer au démarrage. C'est la solution que j'ai trouvée.

Mettez ceci /etc/systemd/system/poke-docker.service:

[Unit]
After=default.target

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

[Install]
WantedBy=default.target

Et puis il suffit systemctl enable poke-dockerde le configurer pour qu'il se déclenche à chaque démarrage, vers la fin de la séquence de démarrage. La docker versioncommande parle au démon docker, déclenchant le socket et démarrant le service docker lui-même.

J'ai essayé l' systemctl enable dockerastuce dans l'autre réponse, et même si cela a fonctionné au début, cela semble avoir provoqué une situation de troupeau tonitruante où docker essayait apparemment de faire beaucoup et échouait misérablement. Je soupçonne que c'est le comportement de "blocage de la chaîne de démarrage" mentionné dans les commentaires.

— Colin Dunklau
source

A eu le même cas d'utilisation en exécutant gitlab-runner sur un essaim. Cela réveille définitivement le démon. Vous pouvez ajouter le drop-in systemd dans votre fichier d'allumage coreos.com/os/docs/latest/using-systemd-drop-in-units.html

— drgn