Jak działają zasady „restart: zawsze” w komponentach dokujących?


23

Mam plik komponujący dokera z PostgreSQL i moją aplikacją, jak poniżej:

version: '3'

services:
  postgresql:
    image: postgres:9.6.6
    ports:
      - 9932:5432
    expose:
      - "5432"
    environment:
      - POSTGRES_PASSWORD=pass
    restart: always
    volumes:
      - /data:/var/lib/postgresql/data

  myapp:
    image: myapp
    links:
      - postgresql
    depends_on:
      - "postgresql"
    restart: always
    ports:
      - "5000:5000"

Problem polega na tym, że restart: alwayszasady nie działają, gdy zabijam kontener (symulowanie awarii aplikacji przy użyciu docker kill), a funkcja dokowania-komponowania nie uruchamia ponownie mojego kontenera, mimo że kod zakończenia to 137 . Podczas korzystania z restart: on-failurezasad obserwuję to samo zachowanie . Wersje 2i 3kompilacja dokowania zachowują się tak samo. Mój system to Ubuntu Server 16.04 x64.

Moje pytania to:

  1. Dlaczego dokowanie-komponowanie nie uruchamia ponownie rozbił (zabił) kontener?
  2. Jak sprawdzić, czy zasady restartu działają?


1
Byłem tam wiele razy, ale jak widać, dokumentacja nie jest solidna i nie ma wyjaśnienia, jak ta funkcja działa, dlatego zadałem pytanie - chciałbym zobaczyć odpowiedź od kogoś z praktycznym doświadczeniem w tej dziedzinie.
Marcin Zablocki

Odpowiedzi:


20

Gdy używasz funkcji zabijania dokera, jest to oczekiwane zachowanie, ponieważ Docker nie uruchamia ponownie kontenera: „Jeśli ręcznie zatrzymasz kontener, jego zasady restartu będą ignorowane do momentu ponownego uruchomienia demona Docker lub ponownego uruchomienia kontenera. Jest to kolejna próba zapobiegania pętla restartu ” (odniesienie)

Jeśli korzystasz z funkcji dokowania lub zabicia dokera, to ręcznie zatrzymujesz kontener. Możesz wykonać kilka testów dotyczących restartowania zasad: restartowanie demona dokera, restartowanie serwera, używanie CMD wewnątrz kontenera i uruchamianie wyjścia ...

Na przykład, jeśli zabiję mój kontener wdrożony przy użyciu zasady restartu, widzę, że zakończył się z kodem 137, ale nie został ponownie uruchomiony zgodnie z dokerem ps -a, pozostaje zamknięty:

[root@andromeda ~]# docker ps --all
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                        PORTS               NAMES
819d1264c30a        redis:alpine        "docker-entrypoint..."   3 minutes ago       Exited (137) 34 seconds ago                       keepalive_redis_1

Ale jeśli zrestartuję demona ...

[root@andromeda ~]# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
819d1264c30a        redis:alpine        "docker-entrypoint..."   30 minutes ago      Up 2 seconds        6379/tcp            keepalive_redis_1

Kontener, który został ustawiony za pomocą zasady restartu, zaczyna się od nowa, co mówi dokumentacja, więc zabicie dokera nie jest sposobem, w jaki powinieneś przetestować zasadę restartu, ponieważ zakłada się, że celowo zatrzymałeś kontener, a Docker chce mieć sposób, aby zapobiec ponownemu uruchomieniu pętle, jeśli go zabijesz, naprawdę chcesz go zabić.

Znalazłem następujące linki cenne, które pokazują to samo zachowanie w różnych wersjach (więc nie jest to błąd, ale oczekiwane zachowanie):

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.