Comment fonctionne la stratégie «redémarrer: toujours» dans docker-compose?

J'ai un fichier de composition docker avec PostgreSQL et mon application, comme ceci:

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"

Le problème est que la restart: alwaysstratégie ne semble pas fonctionner lorsque je tue le conteneur (simulant le plantage de l'application à l'aide docker kill) et que docker-compose ne redémarre pas mon conteneur, même si le code de sortie est 137 . J'observe le même comportement lorsque j'utilise la restart: on-failurestratégie. Les versions 2et 3de docker-compose se comportent de la même manière. Mon système est Ubuntu Server 16.04 x64.

Mes questions sont:

1. Pourquoi docker-compose ne redémarre pas le conteneur écrasé (tué)?
2. Comment vérifier si la politique de redémarrage fonctionne?

Lorsque vous utilisez Docker kill, il s'agit du comportement attendu car Docker ne redémarre pas le conteneur: "Si vous arrêtez manuellement un conteneur, sa stratégie de redémarrage est ignorée jusqu'à ce que le démon Docker redémarre ou que le conteneur soit redémarré manuellement. Il s'agit d'une autre tentative pour empêcher une boucle de redémarrage " (référence)

Si vous utilisez docker stop ou docker kill, vous arrêtez manuellement le conteneur. Vous pouvez faire quelques tests sur les politiques de redémarrage: redémarrage du démon docker, redémarrage de votre serveur, utilisation d'un CMD à l'intérieur d'un conteneur et exécution d'une sortie ...

Par exemple, si je tue mon conteneur déployé avec une stratégie de redémarrage, je vois qu'il s'est arrêté avec le code 137 mais qu'il n'est pas redémarré selon docker ps -a, il reste quitté:

[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

Mais si je redémarre le démon ...

[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

Le conteneur qui a été défini avec la stratégie de redémarrage redémarre, comme le dit la documentation, donc le docker kill n'est pas la façon dont vous devez tester la stratégie de redémarrage car il est supposé que vous avez délibérément arrêté le conteneur et Docker veut avoir un moyen d'empêcher le redémarrage boucles, si vous le tuez, vous voulez vraiment le tuer.

J'ai trouvé les liens suivants précieux qui montrent le même comportement dans différentes versions (donc ce n'est pas un bug mais le comportement attendu):

• Comment garantir le redémarrage des conteneurs
• Le même comportement attendu lorsque vous utilisez Docker kill
• Et un autre post sur Docker tuer et redémarrer