comment obtenir docker-compose pour utiliser la dernière image du référentiel
Je ne sais pas ce que je fais mal, mais je ne peux tout simplement pas avoir docker-compose up pour utiliser la dernière image de notre base de registre sans supprimer au préalable complètement les anciens conteneurs du système. Il semble que composer utilise l'image lancée précédemment, même si pull docker-compose a récupéré une image plus récente.
J'ai regardé Comment docker-composer pour toujours recréer des conteneurs à partir d'images fraîches? qui semblait être semblable à mon problème, mais aucune des solutions fournies ne fonctionne pour moi, car je Je cherche une solution que je peux utiliser sur le serveur de production et où je ne souhaite pas supprimer tous les conteneurs avant de les redémarrer (perte de données possible?). J'aimerais que Compose détecte uniquement la nouvelle version des images modifiées, les extrait, puis redémarre les services avec ces nouvelles images.
J'ai créé pour cela un projet de test simple dans lequel le seul objectif est d'obtenir une version à augmenter à chaque nouvelle construction. La version n ° est affichée si je navigue sur le serveur nginx créé (cela fonctionne comme prévu localement).
version de docker: 1.11.2 Version de docker-compose: 1.7.1 OS: testé sur CentOS 7 et OS X 10.10 à l'aide de Docker-toolbox
Mon docker-compose.yml:
version: '2'
services:
application:
image: ourprivate.docker.reg:5000/ourcompany/buildchaintest:0.1.8-dev
volumes:
- /var/www/html
tty: true
nginx:
build: nginx
ports:
- "80:80"
volumes_from:
- application
volumes:
- ./logs/nginx/:/var/log/nginx
php:
container_name: buildchaintest_php_1
build: php-fpm
expose:
- "9000"
volumes_from:
- application
volumes:
- ./logs/php-fpm/:/var/www/logs
sur notre serveur Jenkins, je lance ce qui suit pour construire et marquer l’image
cd $WORKSPACE && PROJECT_VERSION=$(cat VERSION)-dev
/usr/local/bin/docker-compose rm -f
/usr/local/bin/docker-compose build
docker tag ourprivate.docker.reg:5000/ourcompany/buildchaintest ourprivate.docker.reg:5000/ourcompany/buildchaintest:$PROJECT_VERSION
docker Push ourprivate.docker.reg:5000/ourcompany/buildchaintest
cela semble faire ce qui est supposé être depuis que je reçois une nouvelle balise de version dans notre référentiel chaque fois que la construction est terminée et que le numéro de version a été modifié.
Si je cours maintenant
docker-compose pull && docker-compose -f docker-compose.yml up -d
dans un dossier de mon ordinateur, où le contenu ne concerne que le fichier docker-compose.yml et les fichiers Dockerfiles nécessaires à la construction des services nginx et php, le résultat obtenu n’est pas le dernier numéro de version tel qu’il a été marqué dans le registre ou est affiché dans le fichier docker-compose.yml (0.1.8), mais la version antérieure, 0.1.7. Cependant, le résultat de la commande pull suggère qu'une nouvelle version de l'image a été récupérée:
Pulling application (ourprivate.docker.reg:5000/ourcompany/buildchaintest:latest)...
latest: Pulling from ourcompany/buildchaintest
Digest: sha256:8f7a06203005ff932799fe89e7756cd21719cccb9099b7898af2399414bfe62a
Status: Downloaded newer image for docker.locotech.fi:5000/locotech/buildchaintest:0.1.8-dev
Seulement si je cours
docker-compose stop && docker-compose rm -f
puis lancez le docker-compose up commande-je obtenir la nouvelle version à l'écran comme prévu.
Est-ce que ce comportement de docker-compose est prévu? c'est-à-dire que je devrais toujours faire un docker-compose rm -f avant de relancer up, même sur des serveurs de production? Ou est-ce que je fais quelque chose contre le grain ici, c'est pourquoi cela ne fonctionne pas?
L’objectif est de permettre à notre processus de construction de créer et de créer des versions marquées des images nécessaires dans un fichier docker-compose.yml, de les transférer dans notre registre privé, puis de les "passer à l’étape de production" pour simplement copier le fichier docker-composer. yml sur le serveur de production et exécutez un docker-compose pull && docker-compose -f docker-compose.yml up -d pour que la nouvelle image commence en production. Si quelqu'un a des conseils à ce sujet ou peut indiquer un tutoriel sur les meilleures pratiques pour ce type d'installation, il serait également très apprécié.
Pour clore cette question, il semble que ce qui a fonctionné a bien fonctionné
docker-compose stop
docker-compose rm -f
docker-compose -f docker-compose.yml up -d
C'est à dire. supprimez les conteneurs avant de relancer up.
Ce que vous devez garder à l'esprit lorsque vous procédez ainsi est que les conteneurs de volumes de données sont également supprimés si vous exécutez simplement rm -f. Afin d'éviter que je spécifie explicitement chaque conteneur à supprimer:
docker-compose rm -f application nginx php
Comme je l'ai dit dans ma question, je ne sais pas s'il s'agit du bon processus. Mais cela semble fonctionner pour notre cas d'utilisation. Donc, jusqu'à ce que nous trouvions une meilleure solution, nous allons lancer celle-ci.
afin de vous assurer que vous utilisez la dernière version pour votre :latest tag de votre registre (par exemple, docker hub), vous devez également extraire à nouveau le dernier tag. en cas de changement, le diff sera téléchargé et démarré lorsque vous docker-compose up encore.
alors ce serait la voie à suivre:
docker-compose stop
docker-compose rm -f
docker-compose pull
docker-compose up -d
j'ai collé ceci dans une image que je lance pour démarrer docker-compose et m'assurer que les images restent à jour: https://hub.docker.com/r/stephanlindauer/docker-compose-updater/
Pour obtenir les dernières images, utilisez docker-compose build --pull
J'utilise ci-dessous la commande qui est vraiment 3 en 1
"docker-compose down && docker-compose build --pull && docker-compose up -d"
Cette commande arrêtera les services, extraira la dernière image, puis démarrera les services.
J'ai vu cela se produire dans notre système de production de dockers 7-8. Une autre solution qui a fonctionné pour moi en production a été de lancer
docker-compose down
docker-compose up -d
cela supprime les conteneurs et semble créer "en créer" de nouveaux à partir de la dernière image.
Cela ne résout pas encore mon rêve de bas + haut pour CHAQUE conteneur changé (en série, moins de temps d'indisponibilité), mais cela fonctionne pour forcer le "haut" à mettre à jour les conteneurs.
Option down résoudre ce problème
Je lance mon fichier de composition:
docker-compose -f docker/docker-compose.yml up -d
alors je supprime tout avec down --rmi all
docker-compose -f docker/docker-compose.yml down --rmi all
Stops containers and removes containers, networks, volumes, and images
created by `up`.
By default, the only things removed are:
- Containers for services defined in the Compose file
- Networks defined in the `networks` section of the Compose file
- The default network, if one is used
Networks and volumes defined as `external` are never removed.
Usage: down [options]
Options:
--rmi type Remove images. Type must be one of:
'all': Remove all images used by any service.
'local': Remove only images that don't have a custom tag
set by the `image` field.
-v, --volumes Remove named volumes declared in the `volumes` section
of the Compose file and anonymous volumes
attached to containers.
--remove-orphans Remove containers for services not defined in the
Compose file
La documentation de docker-compose pour la commande 'up' indique clairement qu'elle met à jour le conteneur si l'image est modifiée depuis la dernière opération 'up':
S'il existe des conteneurs pour un service et si la configuration ou l'image du service a été modifiée après la création du conteneur, docker-compos up récupère les modifications en arrêtant et recréer les conteneurs (en préservant les volumes montés).
En utilisant donc 'stop' suivi de 'pull' puis 'up', vous éviterez ainsi des problèmes de perte de volumes pour les conteneurs en cours d'exécution, sauf bien sûr pour les conteneurs dont les images ont été mises à jour.
J'expérimente actuellement ce processus et j'incluerai bientôt mes résultats dans ce commentaire.