Как обновить докер-контейнер после изменения его образа

Допустим, я вытащил официальное изображение mysql: 5.6.21 .

Я развернул этот образ, создав несколько док-контейнеров.

Эти контейнеры работали в течение некоторого времени, пока не будет выпущен MySQL 5.6.22. Официальный образ mysql: 5.6 обновляется с новым выпуском, но мои контейнеры по-прежнему работают 5.6.21.

Как распространить изменения в образе (т.е. обновить дистрибутив MySQL) на все мои существующие контейнеры? Как правильно Docker сделать это?

Оценив ответы и изучив тему, я хотел бы подвести итог.

Способ обновления контейнеров с помощью Docker выглядит следующим образом:

Контейнеры приложений не должны хранить данные приложений . Таким образом, вы можете в любое время заменить контейнер приложения новой версией, выполнив что-то вроде этого:

docker pull mysql
docker stop my-mysql-container
docker rm my-mysql-container
docker run --name=my-mysql-container --restart=always \
  -e MYSQL_ROOT_PASSWORD=mypwd -v /my/data/dir:/var/lib/mysql -d mysql

Вы можете хранить данные либо на хосте (в каталоге, смонтированном как том), либо в специальных контейнерах только для данных . Подробнее об этом

• О томах (Докер документы)
• Кусочки крошечного докера, свободно соединенные (автор Том Офферманн)
• Как работать с постоянным хранилищем (например, базами данных) в Docker (вопрос переполнения стека)

Обновление приложений (например, с помощью обновления yum / apt-get) в контейнерах считается антишаблоном . Прикладные контейнеры должны быть неизменными , что должно гарантировать воспроизводимое поведение. Некоторые официальные образы приложений (в частности, mysql: 5.6) даже не предназначены для самостоятельного обновления (apt-get upgrade не будет работать).

Я хотел бы поблагодарить всех, кто дал свои ответы, чтобы мы могли видеть все разные подходы.

Мне не нравится монтировать тома как ссылку на каталог хоста, поэтому я придумал шаблон для обновления докерских контейнеров с полностью управляемыми докерами контейнерами. Создание нового док-контейнера с--volumes-from <container> предоставит новому контейнеру с обновленными изображениями общее владение управляемыми томами Docker.

docker pull mysql
docker create --volumes-from my_mysql_container [...] --name my_mysql_container_tmp mysql

my_mysql_containerЕще не сразу удалив оригинал , у вас есть возможность вернуться обратно к известному рабочему контейнеру, если в обновленном контейнере нет нужных данных или он не прошел проверку работоспособности.

На этом этапе я обычно запускаю любые скрипты резервного копирования, которые у меня есть, для контейнера, чтобы обеспечить себе сеть безопасности на случай, если что-то пойдет не так

docker stop my_mysql_container
docker start my_mysql_container_tmp

Теперь у вас есть возможность убедиться, что данные, которые вы ожидаете в новом контейнере, есть, и выполнить проверку работоспособности.

docker rm my_mysql_container
docker rename my_mysql_container_tmp my_mysql_container

Тома докеров будут храниться, пока их использует любой контейнер, поэтому вы можете безопасно удалить исходный контейнер. Как только оригинальный контейнер удален, новый контейнер может принять тезку оригинала, чтобы сделать все так же красиво, как и должно было начаться.

Есть два основных преимущества использования этого шаблона для обновления док-контейнеров. Во-первых, это устраняет необходимость монтировать тома в каталоги хостов, позволяя напрямую переносить тома в обновленные контейнеры. Во-вторых, вы никогда не окажетесь в положении, когда нет рабочего док-контейнера; поэтому, если обновление завершится неудачно, вы можете легко вернуться к тому, как оно работало раньше, снова раскрутив исходный док-контейнер.

Просто для предоставления более общего (не специфичного для mysql) ответа ...

1. Короче говоря

Синхронизировать с реестром образа сервиса ( https://docs.docker.com/compose/compose-file/#image ):

docker-compose pull 

Создайте контейнер заново, если изменились файл или изображение docker-compose:

docker-compose up -d

2. Фон

Управление изображениями контейнеров является одной из причин использования docker-compose (см. Https://docs.docker.com/compose/reference/up/ ).

Если для службы существуют существующие контейнеры, а конфигурация или образ службы были изменены после создания контейнера, docker-compose обрабатывает изменения, останавливая и воссоздавая контейнеры (сохраняя подключенные тома). Чтобы запретить Compose принимать изменения, используйте флаг --no-воссоздать.

Аспект управления данными также охватывается docker-compose через подключенные внешние «тома» (см. Https://docs.docker.com/compose/compose-file/#volumes ) или контейнер данных.

Это оставляет потенциальные проблемы обратной совместимости и миграции данных нетронутыми, но это «аппликативные» проблемы, а не специфичные для Docker, которые необходимо проверять на предмет замечаний к выпуску и тестов ...

Я хотел бы добавить, что если вы хотите выполнить этот процесс автоматически (загрузить, остановить и перезапустить новый контейнер с такими же настройками, как описано @Yaroslav), вы можете использовать WatchTower. Программа, которая автоматически обновляет ваши контейнеры при их изменении https://github.com/v2tec/watchtower

Рассмотрим для этого ответы:

• Имя базы данных app_schema
• Имя контейнера app_db
• Пароль root root123

Как обновить MySQL при хранении данных приложения внутри контейнера

Это считается плохой практикой , потому что если вы потеряете контейнер, вы потеряете данные. Хотя это плохая практика, вот возможный способ сделать это:

1) Сделайте дамп базы данных как SQL:

docker exec app_db sh -c 'exec mysqldump app_schema -uroot -proot123' > database_dump.sql

2) Обновите изображение:

docker pull mysql:5.6

3) Обновить контейнер:

docker rm -f app_db
docker run --name app_db --restart unless-stopped \
-e MYSQL_ROOT_PASSWORD=root123 \
-d mysql:5.6

4) Восстановите дамп базы данных:

docker exec app_db sh -c 'exec mysql -uroot -proot123' < database_dump.sql

Как обновить контейнер MySQL, используя внешний том

Использование внешнего тома - лучший способ управления данными и упрощение обновления MySQL. Потеря контейнера не приведет к потере данных. Ты можешь использовать docker-compose для облегчения управления многоконтейнерными Docker-приложениями на одном хосте:

1) Создайте docker-compose.ymlфайл для управления вашими приложениями:

version: '2'
services:
  app_db:
    image: mysql:5.6
    restart: unless-stopped
    volumes_from: app_db_data
  app_db_data:
    volumes: /my/data/dir:/var/lib/mysql

2) Обновить MySQL (из той же папки, что и docker-compose.ymlфайл):

docker-compose pull
docker-compose up -d

Примечание: последняя команда выше обновит образ MySQL, заново создаст и запустит контейнер с новым образом.

Подобный ответ на выше

docker images | awk '{print $1}' | grep -v 'none' | grep -iv 'repo' | xargs -n1 docker pull

Вот как это выглядит docker-composeпри создании кастома Dockerfile.

1. Сначала создайте свой собственный файл Dockerfile, добавив следующий номер версии для разграничения. Пример: docker build -t imagename:version . это будет хранить вашу новую версию локально.
2. Запустить docker-compose down
3. Отредактируйте свой docker-compose.yml файл, чтобы отразить новое имя изображения, которое вы установили на шаге 1.
4. Беги docker-compose up -d. Он будет искать изображение локально и использовать ваш обновленный.

-РЕДАКТИРОВАТЬ-

Мои шаги выше более многословны, чем они должны быть. Я оптимизировал рабочий процесс, включив этот build: .параметр в файл docker-compose. Пошаговые шаги выглядят так:

1. Убедитесь, что мой Dockerfile - это то, что я хочу, чтобы он выглядел.
2. Установите номер версии моего имени изображения в моем файле docker-compose.
3. Если мое изображение еще не построено: запустите docker-compose build
4. Запустить docker-compose up -d

В то время я не понимал, но docker-compose достаточно умен, чтобы просто обновить мой контейнер до нового образа с помощью одной команды, вместо того, чтобы сначала его выключать.

Если вы не хотите использовать Docker Compose, я могу порекомендовать portainer . Он имеет функцию воссоздания, которая позволяет вам воссоздавать контейнер при извлечении последнего изображения.

Вам необходимо либо перестроить все образы и перезапустить все контейнеры, либо каким-либо образом обновить программное обеспечение и перезапустить базу данных. Там нет пути обновления, но вы сами разрабатываете.

Принимая от http://blog.stefanxo.com/2014/08/update-all-docker-images-at-once/

Вы можете обновить все существующие образы, используя следующий конвейер команд:

docker images | awk '/^REPOSITORY|\<none\>/ {next} {print $1}' | xargs -n 1 docker pull

Убедитесь, что вы используете тома для всех постоянных данных (конфигурации, журналов или данных приложения), которые вы храните в контейнерах, связанных с состоянием процессов внутри этого контейнера. Обновите ваш Dockerfile и перестройте образ с нужными вам изменениями, а затем перезапустите контейнеры с вашими томами, смонтированными в соответствующем месте.

Это то, с чем я тоже боролся за свои собственные изображения. У меня есть серверная среда, из которой я создаю образ Docker. Когда я обновляю сервер, я бы хотел, чтобы все пользователи, использующие контейнеры на основе моего образа Docker, могли обновиться до последней версии сервера.

В идеале я предпочел бы сгенерировать новую версию образа Docker, и все контейнеры на основе предыдущей версии этого образа автоматически обновляются до нового образа «на месте». Но этот механизм, кажется, не существует.

Итак, следующий лучший дизайн, который я смог придумать, - это предоставить способ обновления самого контейнера - подобно тому, как настольное приложение проверяет наличие обновлений, а затем обновляет себя. В моем случае это, вероятно, будет означать создание сценария, включающего Git-трюки из известного тега.

Изображение / контейнер на самом деле не меняется, но меняются «внутренние» этого контейнера. Вы можете представить, что делаете то же самое с apt-get, yum или с тем, что подходит для вашей среды. Наряду с этим я обновил бы myserver: последнее изображение в реестре, чтобы любые новые контейнеры основывались на последнем образе.

Мне было бы интересно услышать, есть ли какой-либо уровень техники, который обращается к этому сценарию.

Обновить

В основном это делается для того, чтобы запросить контейнер не обновлять, так как создание изображений - это способ сделать

У меня возникла та же проблема, поэтому я создал docker-run , очень простой инструмент командной строки, который запускается внутри docker-контейнера для обновления пакетов в других работающих контейнерах.

Он использует docker-py для связи с работающими контейнерами Docker и обновления пакетов или запуска любой произвольной команды

Примеры:

docker run --rm -v /var/run/docker.sock:/tmp/docker.sock itech/docker-run exec

по умолчанию dateкоманда запускается во всех запущенных контейнерах и возвращает результаты, но вы можете выполнить любую команду, напримерdocker-run exec "uname -a"

Чтобы обновить пакеты (в настоящее время используется только apt-get):

docker run --rm -v /var/run/docker.sock:/tmp/docker.sock itech/docker-run update

Вы можете создать и псевдоним и использовать его как обычную командную строку, например

alias docker-run='docker run --rm -v /var/run/docker.sock:/tmp/docker.sock itech/docker-run'