Теги, пересоздание и уборка ресурсов

После нескольких сборок на выбранном Engine могут остаться images с тегами lab-04, lab-05 и lab-07, а также контейнер из более раннего состояния. Пора научиться читать этот список и удалять только понятные учебные ресурсы. Результат урока — различение имени, тега, содержимого image и связи контейнера с ним.

Управление ресурсами не должно начинаться с массового удаления. Сначала выясним, какой объект нужен для следующего занятия и какой уже не нужен. Команды ниже относятся к собственным именам нашего проекта. Выполнение и освобождённое место в материалах не измерялись; читатель проверяет состояние своего Engine самостоятельно.

Список images отличается от списка контейнеров

В Docker Desktop категория Images показывает подготовленные образы. Категория контейнеров показывает экземпляры, созданные из них. У одного image может быть несколько тегов и несколько контейнеров; остановленный контейнер всё ещё остаётся экземпляром. Поэтому число строк в двух категориях не обязано совпадать.

Список образов в Docker Desktop. Архивный пример интерфейса; имена, идентификаторы и размеры относятся к демонстрации.

Кадр помогает различить поля списка, но его числа не являются результатами professorweb-container-lab. В текущем Desktop названия и расположение элементов могут отличаться. Для нашего наблюдения достаточно команд CLI и выбранного context:

docker image ls
docker container ls --all

На первом чтении найдите repository professorweb-container-lab-api и его теги. На втором — pw-catalog-api и его состояние. Поле image у контейнера помогает проследить исходный выбор, но для неоднозначных имён может понадобиться inspect. Смотрите на свой объект, не переносите ID с картинки в команду удаления.

Тег даёт дополнительное имя

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

docker image tag professorweb-container-lab-api:lab-07 professorweb-container-lab-api:lab-08

Ожидается, что две метки будут указывать на одинаковое содержимое. Команда tag не запускает API и не копирует его каталог в новый независимый image. Она не создаёт новую версию приложения только потому, что справа написан другой номер. Правило именования и формы reference описано в справочнике docker image tag.

Тег можно переназначить после другой сборки. Поэтому lab-08 — наше договорённое имя состояния, а не криптографическая гарантия его содержимого. В командной работе стоит связывать релизный тег с политикой публикации и записанным digest. На этапе первого знакомства достаточно понимать, почему две строки списка могут иметь один ID и почему одна строка latest не доказывает наличие новой функции.

Объект или действие	Что меняется	Чего из него не следует
Дополнительный tag	Появляется имя для image	Код не пересобран автоматически
Новый run	Создаётся новый контейнер	Прежний контейнер не обновился
Stop	Основной процесс остановлен	Объект и его слой не удалены
Rm контейнера	Удаляется выбранный экземпляр	Все images машины не удалены
Rm имени image	Удаляется выбранная ссылка или image	Размер диска обязательно уменьшился на размер строки

Пересоздадим только свой экземпляр

Чтобы перейти от старого контейнера к image текущего состояния, читатель сначала останавливает и удаляет собственный экземпляр. Делайте это только после понимания, что данные в его изменяемом слое не нужны: отдельного постоянного volume в этом состоянии ещё нет.

docker stop pw-catalog-api
docker rm pw-catalog-api
docker run --detach --name pw-catalog-api --publish 127.0.0.1:4100:4100 professorweb-container-lab-api:lab-08

Теперь новый объект создан из выбранного image. Ожидаемый GET /api/courses остаётся прежним: мы меняли порядок сборки и имена, а не схему приложения. Самостоятельное чтение logs и ответа позволяет отличить работающий новый экземпляр от одного только присутствия тега в image ls.

Если stop сообщает, что имя отсутствует, не вставляйте найденное соседнее имя наугад. Возможно, предыдущие команды выполнялись в другом context или с другим именем. Проверьте список all и вернитесь к паспорту окружения. Операция rm должна удалять конкретный объект, происхождение которого известно.

Почему image иногда нельзя удалить

Контейнер может ссылаться на image и после остановки. Если попытка удалить связанный образ приводит к конфликту, сначала решите судьбу контейнера. Принудительное удаление image не является обычным способом обновления нашего проекта. Оно усложняет объяснение связей, хотя проблема может решаться удалением уже ненужного собственного экземпляра.

Для неиспользуемого раннего тега, после просмотра его связей, можно отдельно выполнить:

docker image rm professorweb-container-lab-api:lab-04

Иногда удаление имени снимает только тег, а само содержимое остаётся доступно через другой тег или связь. Слои также могут использоваться несколькими images. Поэтому размер строки списка нельзя просто суммировать как гарантированно освобождённые байты. В этой серии не объявляем измеренного выигрыша и не советуем удалять базовый image только потому, что он кажется большим.

Уборка имеет собственную область действия

Команды prune полезны для осознанного обслуживания, но их область шире собственного контейнера. Image prune без all относится к dangling images, а с all расширяет выбор до images без ссылок контейнеров. System prune затрагивает несколько категорий неиспользуемых ресурсов; дополнительные параметры меняют набор. Это не синоним «удалить абсолютно всё», и volumes требуют отдельного понимания. Точные правила даны в image prune и system prune.

В качестве обычного сценария для курса массовую команду не запускаем и не приводим к ней автоматический переход. На выбранном Engine могут находиться другие проекты, остановленные экземпляры и полезный build cache. Операция с собственным именем лучше показывает, что именно удаляется. Перед будущим удалением volume нужно отдельно решить, требуется ли резервная копия данных.

Подготовим переход к внешним данным

Файловые start/after этого урока одинаковы: изменение касается читательских Docker-ресурсов и их обозначений. Архив серии не содержит работающего image, сохранённого контейнерного слоя или списка ресурсов чужой машины. STATE сохраняет not_run, а будущие ID и размеры читатель записывает только после выполнения.

До этого момента каталог является частью образа. После удаления контейнера можно снова получить начальные записи из image, но изменения собственного слоя не сохранятся. Следующий урок введёт два разных подключения: исходники компьютера через bind mount и постоянные данные через named volume. Тогда при пересоздании контейнера нужно будет сохранять ещё одну осознанную связь — с выбранным хранилищем.

Оглавление серии