Demon Dockera nie uruchamia się podczas uruchamiania systemu CoreOS

23

Mam waniliową instalację CoreOS (835.9.0) i nie uruchamia on demona dokera podczas uruchamiania. Zaczyna się dopiero, gdy włączę SSH i zrobię np docker ps.

Jak ustawić demona dokera automatycznie uruchamiającego się podczas uruchamiania systemu?

Kiedy mówię demona dokera, mam na myśli, ps -ef | grep dockerże nie pokazuje żadnych procesów, dopóki nie zrobię tegodocker ps

boot docker coreos

— Chris
źródło

40

sudo systemctl enable docker wykonał lewę.

— Chris
źródło

2

Dzięki, przeczytałem dokumentację Dockera i nie mogłem znaleźć niczego, co mogłoby pomóc - wiele dowiedziałem się o zasadach restartowania, ale oczywiście mają one zastosowanie tylko po uruchomieniu demona dokera.

— Chris

6

Tło: Przyczyną tego jest fakt, że doker jest aktywowany przez gniazdo w CoreOS, tzn. Nie blokuje łańcucha rozruchowego. Wczesne wersje dokera uruchamiały się powoli, gdy na dysku znajdowało się wiele kontenerów, które blokowały szybkie uruchamianie wszystkiego, co zależało od dokera, co powodowało ciekawe awarie.

— Rob

4

Dobroć. Doprowadziło mnie to do szału. Nic, co przeczytałem w żadnym dokumencie, nie wspomniało o tym. Z tego powodu prawie przysiągłem CoreOS na rzecz AWS AMI. (AWS AMI automatycznie uruchamia demona Docker domyślnie).

— Nostalg.io

2

jest to bardzo nietypowe dla CoreOS, który zachowuje się w ten sposób, biorąc pod uwagę, że CoreOS jest dedykowanym systemem operacyjnym Docker i nie uruchamia dokera podczas rozruchu ???

— typelogiczny

3

To bardzo ważna informacja. Dokumenty CoreOS nie wspominają nic o konieczności włączenia Dockera (lub jakiegokolwiek innego środowiska wykonawczego kontenera w tym zakresie). Ponieważ możliwe jest uruchamianie kontenerów dokujących na czystym CoreOS (a ponieważ CoreOS jest przystosowany do uruchamiania kontenerów), miałem wrażenie, że było to ustawienie domyślne. Zorientowałem się, że mój błąd nastąpił dopiero wtedy, gdy pierwsze ponowne uruchomienie uruchomione przez aktualizację nie uruchomiło moich kontenerów.

— Florian von Stosch

6

To już trochę stare, ale zacząłem używać init-chmurę, aby to zrobić na wszystkich nowych serwerach. Mam zapisany skrypt inicjujący chmurę, którego używam na wszystkich moich serwerach. Część zawiera:

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

Umożliwi to usługę dokera i uruchomi ją przy pierwszym i każdym uruchomieniu.

— captncraig
źródło

2

Jak już wyjaśniono w tym komentarzu przez Roba , doker jest aktywowany przez gniazdo. Oznacza to, że deamon nie uruchomi się, dopóki nie zostanie wywołany. Istniejące odpowiedzi tutaj działają, ale CoreOS zaleca inne podejście.

Zalecanym sposobem na to, zgodnie z dokumentacją CoreOS, jest stworzenie usługi dla własnej aplikacji, która z kolei wymaga usługi 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

I zamiast tego niech usługa uruchomi się automatycznie:

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

Przykładem przypadku jest aktualizacja kontenera do najnowszej wersji po uruchomieniu usługi, a przykład zaawansowany rejestruje usługę w etcd. Przeczytaj dokumentację CoreOS, aby uzyskać więcej informacji ogólnych .

— Neograph734
źródło

To „najnowsze” od CoreOS? Docker ma zasady ponownego uruchamiania od lat i takie podejście nie jest już konieczne ani pożądane. Nigdy tak naprawdę nie było to pożądane, ale było to obejście problemu (bardzo starych wersji) braku wsparcia Dockera dla samego restartowania kontenerów. Dawno już przestałem używać CoreOS, tak sądzę ...

— Michael Hampton

@MichaelHampton Zasady ponownego uruchomienia obowiązują również, gdy pojemnik ulega awarii z innego powodu, więc jeden nie zastępuje innego. Poza tym zasady restartu nie pozwalają na aktualizację kontenerów przy starcie itp. Nie mam pojęcia, co jest lepsze, ale przypuszczam, że ta metoda daje ci nieco więcej kontroli.

— Neograph734,

1

Kiedy zaczynasz potrzebować tak dużej kontroli, zwykle potrzebujesz także wielu innych bitów dostarczanych przez usługi orkiestracji: od samego końca dokowania-komponuj, aż do Kubernetes.

— Michael Hampton

1

Korzystam z Docker Swarm, więc nie mam konkretnej aplikacji, za którą systemd byłby odpowiedzialny ... Potrzebuję tylko dokera, aby uruchomić przy starcie. To jest rozwiązanie, które wypracowałem.

Połóż to /etc/systemd/system/poke-docker.service:

[Unit]
After=default.target

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

[Install]
WantedBy=default.target

A potem po prostu systemctl enable poke-dockerustawić, aby uruchamiał się przy każdym rozruchu, pod koniec sekwencji startowej. docker versionKomenda mówi do demona Döcker, wywołując gniazdo i uruchamiania usług we własnym zakresie Döcker.

Próbowałem systemctl enable dockerpodstępu w innej odpowiedzi i chociaż na początku zadziałało, wydaje się, że spowodowało to sytuację stada grzmotów, w której doker najwyraźniej próbował zrobić wiele, a nieszczęśliwie. Podejrzewam, że jest to zachowanie „blokujące łańcuch rozruchowy” wspomniane w komentarzach tam.

— Colin Dunklau
źródło

Miałem ten sam przypadek użycia, uruchamiając gitlab-runner na roju. To zdecydowanie obudzi demona. Możesz dodać systemd drop-in w pliku zapłonu coreos.com/os/docs/latest/using-systemd-drop-in-units.html

— drgn