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 restart: always
la politique ne semble pas fonctionner lorsque je tue le conteneur (simulation d'un plantage d'application à l'aide de docker kill
) et 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 restart: on-failure
politique. Versions 2
et 3
de docker-compose se comportent de la même manière. Mon système est Ubuntu Server 16.04 x64.
Mes questions sont:
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):