Как использовать "git -подобные" возможности Docker?

ОБНОВЛЕНО. Меня особенно интересует, как я запускаю или откатываюсь назад к определенной версии (двоичного) изображения из докеров, и попытался прояснить этот вопрос в этом отношении.

Часто задаваемые вопросы Docker:

Docker включает в себя git -подобные возможности для отслеживания последовательных версий контейнера, проверки различий между версиями, совершения новых версий, откат и т.д. История также включает в себя, как контейнер был собран и кем, прослеживаемость с производственного сервера на обратном пути к предшественнику.

Google, как я могу, я не могу найти пример "отката назад" к более раннему контейнеру, проверке различий и т.д. (Очевидно, что я могу делать такие вещи для файлов Dockerfiles, управляемых версиями, но двоичный файл/контейнер Docker может меняться даже если Dockerfile не работает, из-за обновленных источников программного обеспечения, и я ищу способ увидеть и отбросить такие изменения).

Для базового примера: представьте, что я запустил

docker build -t myimage .

в файле Docker, который просто обновляет базу ubuntu:

FROM ubuntu:14:04
RUN apt-get update -q && apt-get upgrade -y

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

Ответы

Ответ 1

Изменить. Технически мы только откатываем слои AUFS, не обязательно откатываясь назад. Если наш рабочий процесс состоит из интерактивной модификации нашего контейнера и внесения изменений с помощью docker commit, то это действительно откат истории в том смысле, что она удаляет любые обновления пакетов, которые мы применяли в более поздних слоях, оставляя версии, установленные в более ранних слоях. Это очень отличается, если мы перестраиваем образ из файла Docker. Тогда ничто здесь не позволяет нам вернуться к предыдущей версии, которую мы построили, мы можем удалить только шаги (слои) из файла Docker. Другими словами, мы можем только отбросить историю нашего docker commit к изображению.

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

Например, рассмотрите возможность проверки history стандартного образа ubuntu:latest:

docker history ubuntu:latest

Показывает:

IMAGE               CREATED             CREATED BY                                      SIZE
ba5877dc9bec        3 weeks ago         /bin/sh -c #(nop) CMD [/bin/bash]               0 B
2318d26665ef        3 weeks ago         /bin/sh -c sed -i 's/^#\s*\(deb.*universe\)$/   1.903 kB
ebc34468f71d        3 weeks ago         /bin/sh -c rm -rf /var/lib/apt/lists/*          8 B
25f11f5fb0cb        3 weeks ago         /bin/sh -c echo '#!/bin/sh' > /usr/sbin/polic   194.5 kB
9bad880da3d2        3 weeks ago         /bin/sh -c #(nop) ADD file:de2b0b2e36953c018c   192.5 MB
511136ea3c5a        14 months ago    

                                               0 B

Представьте, что мы хотим вернуться к изображению, обозначенному хешем 25f:

docker tag 25f ubuntu:latest
docker history ubuntu:latest

И мы видим:

IMAGE               CREATED             CREATED BY                                      SIZE
25f11f5fb0cb        3 weeks ago         /bin/sh -c echo '#!/bin/sh' > /usr/sbin/polic   194.5 kB
9bad880da3d2        3 weeks ago         /bin/sh -c #(nop) ADD file:de2b0b2e36953c018c   192.5 MB
511136ea3c5a        14 months ago                                                       0 B

Конечно, мы, вероятно, никогда не захотим откататься таким образом, поскольку он делает ubuntu:latest не самым последним ubuntu в нашей локальной библиотеке. Обратите внимание, что мы могли использовать любой тег, который мы хотели, например.

docker tag 25f ubuntu:notlatest

или просто запустил старое изображение с помощью хэша:

docker run -it 25f /bin/bash

Так просто и все же так аккуратно. Обратите внимание, что мы можем объединить это с docker inspect, чтобы получить более подробную информацию о метаданных каждого изображения, к которому относится FAQ Docker.

Также обратите внимание, что docker diff и docker commit довольно не связаны с этим процессом, поскольку они относятся к контейнерам (например, к запущенным изображениям), а не к изображениям напрямую. То есть, если мы запускаем изображение в интерактивном режиме, а затем добавляем или изменяем файл на изображении, мы можем увидеть изменение (между контейнером) с помощью docker diff <Container-id> и зафиксировать изменение с помощью docker commit <Container id>.

Ответ 2

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

Функция тегов imho довольно плохо документирована, но способ, которым вы должны ее использовать, возможно, используя семантическое управление версиями для организации ваших тегов и изображения. Мы переводим сложную (12-микросервисную) систему на использование Docker и полагаемся на latest. Я быстро закончил делать что-то вроде семантического управления версиями и журнал изменений в репозитории Git, чтобы отслеживать изменения.

Это также хорошо, если вы говорите, имеет ветвь docker, которая автоматически принимает изменения и запускает сборку на DockerHub - вы можете обновить журнал изменений и узнать, какая хеш/временная метка идет с чем.

Лично, поскольку триггеры сборки DockerHub в настоящее время медленны, я предпочитаю вручную объявлять тег для каждого изображения и вести журнал изменений, но я и я подозреваю, что инструменты будут лучше для этого.