Как заставить docker-compose использовать последнее изображение из репозитория
Я не знаю, что я делаю неправильно, но я просто не могу получить docker-compose up
, чтобы использовать последнее изображение из нашего реестра, без предварительного удаления старых контейнеров из системы. Похоже, что compose использует ранее начатое изображение, даже если прикрепление докеры создало более новое изображение.
Я посмотрел на Как заставить docker-compose всегда воссоздавать контейнеры из свежих изображений?, которые, похоже, были похожи на мою проблему, но ни одна из предоставленных решения для меня работают, так как я ищу решение, которое я могу использовать на рабочем сервере, и там я не хочу удалять все контейнеры, прежде чем запускать их снова (возможна потеря данных?). Я хотел бы только создать новую версию измененных изображений, вытащить их, а затем перезапустить службы с помощью этих новых изображений.
Я создал простой тестовый проект для этого, в котором единственная цель - увеличить версию nr для каждой новой сборки. Версия nr отображается, если я просматриваю созданный сервер nginx (это работает как ожидается локально).
версия докера: 1.11.2
версия для докеров: 1.7.1
ОС: проверено как на CentOS 7, так и на OS X 10.10 с помощью панели инструментов docker
Мой 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
на нашем сервере jenkins Я запускаю следующее, чтобы создать и пометить изображение
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
похоже, что он делает то, что должен был быть, так как я получаю тег новой версии в нашем репозитории каждый раз, когда сборка завершается, и версия nr была удалена.
Если я сейчас запустил
docker-compose pull && docker-compose -f docker-compose.yml up -d
в папке на моем компьютере, где содержимое представляет собой только файл docker-compose.yml и необходимые файлы Dockerfiles для создания служб nginx и php, вывод, который я получаю, не является последним номером версии, как было отмечено в реестре или показан в файле docker-compose.yml(0.1.8), но версия до этого, которая равна 0.1.7. Однако вывод команды pull предполагает, что была выбрана новая версия изображения:
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
Только если я запустил
docker-compose stop && docker-compose rm -f
а затем запустите команду docker-compose up
, чтобы я получил новую версию для отображения на экране, как ожидалось.
Является ли это предполагаемым поведением докеров? т.е. должен ли я всегда делать docker-compose rm -f
перед запуском up
снова, даже на рабочих серверах? Или я делаю что-то против зерна здесь, поэтому он не работает?
Цель состоит в том, чтобы построить сборку сборки и создать тегированные версии изображений, необходимых в файле docker-compose.yml, вставить их в наш частный реестр, а затем для "выпуска на производственный этап" просто скопировать докеры -compose.yml на производственный сервер и запустите docker-compose pull && docker-compose -f docker-compose.yml up -d
для нового изображения, которое начнется в процессе производства. Если у кого-то есть советы по этому поводу или может указывать на учебник по лучшим практикам для такого рода настроек, которые также будут очень ценными.
Ответы
Ответ 1
Чтобы закрыть этот вопрос, казалось, что он работал, действительно работает
docker-compose stop
docker-compose rm -f
docker-compose -f docker-compose.yml up -d
т.е. удалите контейнеры перед повторным запуском up
.
Что нужно иметь в виду, когда это делается, так это то, что контейнеры томов данных также удаляются, если вы просто запустите rm -f
. Чтобы предотвратить явное указание каждого контейнера для удаления:
docker-compose rm -f application nginx php
Как я уже сказал в своем вопросе, я не знаю, правильно ли это происходит. Но это, похоже, работает для нашего прецедента, поэтому, пока мы не найдем лучшее решение, мы будем кататься с этим.
Ответ 2
чтобы убедиться, что вы используете последнюю версию тега :latest
в своем реестре (например, докере-хабе), вам также нужно снова вытащить последний тег. в случае его изменения diff будет загружен и запущен, когда вы снова docker-compose up
.
так что это будет путь:
docker-compose stop
docker-compose rm -f
docker-compose pull
docker-compose up -d
i приклеил это к изображению, которое я запускаю, чтобы начать компоновку докеров и убедитесь, что изображения остаются актуальными: https://hub.docker.com/r/stephanlindauer/docker-compose-updater/
Ответ 3
Для получения последних изображений используйте сборку докеров-компоновки --pull
Я использую ниже команду, которая действительно 3 в 1
"docker-compose down && docker-compose build --pull && docker-compose up -d"
Эта команда остановит службы, вытащит последнее изображение и запустит службы.
Ответ 4
Я видел, как это происходит в нашей 7-8 докерной системе.
Другое решение, которое работало для меня на производстве, заключалось в запуске
docker-compose down
docker-compose up -d
это удаляет контейнеры и, кажется, делает "вверх" создавать новые из последнего изображения.
Это еще не решит мою мечту о снижении + вверх по КАЖДОМУ измененному контейнеру (последовательно, меньше времени простоя), но он работает, чтобы заставить "вверх" обновить контейнеры.
Ответ 5
Документация документации dokerer для команды 'up' четко указывает, что она обновляет контейнер, если изображение будет изменено с момента последнего ' вверх ":
Если существуют существующие контейнеры для службы, а конфигурация или изображение служб были изменены после создания контейнеров, компоновка докеры поднимает изменения, останавливая и воссоздавая контейнеры (сохраняя смонтированные тома).
Таким образом, используя "stop", за которым следует "pull", а затем "вверх", следует избегать проблем с потерянными томами для запущенных контейнеров, за исключением, конечно, для контейнеров, чьи изображения были обновлены.
В настоящее время я экспериментирую с этим процессом и вскоре включу свои результаты в этот комментарий.
Ответ 6
Вариант down
решить эту проблему
Я запускаю свой файл compose:
docker-compose -f docker/docker-compose.yml up -d
затем я удаляю все с помощью 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
Ответ 7
Я использую следующую команду, чтобы получить последние изображения
Содо докер-сочинить вниз -rmi
Судо докер-составить -d
Ответ 8
Я расширил сценарий Abhi немного дальше, как показано ниже
export composeFile="docker-compose.test.yml"
docker-compose -f $composeFile down
docker-compose -f $composeFile pull
docker-compose -f $composeFile up -d