Где брать образы: Docker Hub, теги и архитектуры

Для запуска готовой базы не нужно самостоятельно собирать PostgreSQL из исходников. Сопровождающие образа уже подготовили программу, системные библиотеки и стартовый скрипт. Нам нужно выбрать сборку и скачать её.

Образы распространяют через registry, реестр. Он похож на библиотеку готовых программных комплектов. Реестр может быть публичным, как Docker Hub, или закрытым для команды. GitHub Container Registry, GitLab Container Registry и Harbor выполняют ту же основную роль: хранят и отдают образы. Локально собранный образ может вообще не публиковаться в реестр.

Что написано в имени образа

В командах встречается короткое имя postgres:17. Его полная форма:

docker.io/library/postgres:17

docker.io — адрес реестра Docker Hub, library — пространство официальных образов, postgres — репозиторий, 17 — тег. Репозиторий объединяет версии одного образа. В имени training-team/csv-loader:1 пространство — training-team, а репозиторий — csv-loader; отсутствие отдельного адреса реестра означает Docker Hub. Это пример разбора имени, а не существующий образ для скачивания.

Репозиторий образов и Git-репозиторий связаны через сборку, но содержат разные вещи. В Git могут лежать Dockerfile и исходный код. В реестре лежит готовый образ, который можно запустить. Скачивание исходников через git clone само по себе не устанавливает контейнерный образ.

Скачать ещё не значит запустить

docker pull postgres:17
docker image ls

pull загружает образ. В выводе видны слои: некоторые скачиваются, а некоторые уже есть локально и используются повторно. image ls показывает образы на машине Engine. Работающего сервера PostgreSQL после этих двух команд ещё нет — контейнер мы не создавали.

Если выполнить docker run с отсутствующим образом, Docker может скачать его перед запуском. Явный pull полезен, когда хочется разделить две возможные проблемы: недоступность реестра и ошибку самой программы.

Как сборка доходит до другой машины

Последовательность читается так: build создаёт образ, push публикует его, pull получает на другой машине, run создаёт контейнер. Для собственного локального эксперимента достаточно build и run. В Docker Hub автоматически ничего не загружается.

Для закрытого реестра сначала нужна аутентификация через docker login. Команда push также требует права записи в выбранный репозиторий. Поэтому нельзя взять произвольное имя официального образа и опубликовать туда свою сборку. В учебных примерах собственный образ остаётся локальным.

По этой цепочке передаётся программа, а не её текущая база данных. Если коллега скачал тот же образ PostgreSQL, ваши таблицы к нему не переехали: они лежат в вашем томе. Для воспроизведения окружения нужны также настройки запуска, входные файлы и отдельно подготовленные данные.

Тег, digest и процессор

Тег — человекочитаемая метка. Например, номер версии или latest. Слово latest не гарантирует ни новейшую версию вообще, ни неизменность содержимого. Сопровождающий может переназначить тег на другую сборку. Даже 17 обычно означает актуальную сборку внутри основной версии PostgreSQL 17.

Представьте, что в понедельник вы запустили контейнер из postgres:17. Во вторник сопровождающий обновил этот тег, а вы выполнили docker pull postgres:17. На диске появилась новая сборка, но работающий контейнер продолжает использовать прежнюю. pull получает образ и не заменяет существующие контейнеры; даже docker restart запускает тот же экземпляр с прежним образом. Для перехода к новой сборке создают новый контейнер, отдельно сохраняя данные и настройки.

Для точного закрепления содержимого используют digest, идентификатор вида sha256:.... Посмотреть имеющиеся идентификаторы можно так:

docker image inspect postgres:17 --format '{{json .RepoDigests}}'

При запуске используют реальный digest, например форму postgres@sha256:..., заменив многоточие полным значением. Это помогает повторить конкретную сборку, но обновления безопасности всё равно нужно получать и проверять.

Ещё одно условие переносимости — архитектура процессора. linux/amd64 относится к 64-битной x86, linux/arm64 — к ARM. Один тег может содержать варианты для нескольких платформ; Docker выбирает подходящий Engine.

docker buildx imagetools inspect postgres:17
docker info --format '{{.OSType}}/{{.Architecture}}'

Первая команда смотрит опубликованные варианты, вторая — текущую систему Engine. no matching manifest часто означает, что нужного варианта нет. Принудительный запуск другой архитектуры возможен при поддерживаемой эмуляции, но может быть медленнее. Совпадение имени образа ещё не отменяет требований к процессору и операционной системе.

Соседние версии в локальном списке

docker pull alpine:3.20
docker pull alpine:3.21
docker images
docker run --name selected-version alpine:3.20 echo selected

В списке будут оба тега. Контейнер selected-version использует alpine:3.20, поскольку это явно задано в run. Скачивание нового тега не переключает уже созданные контейнеры на него. Чтобы перейти на другой образ, создают новый экземпляр с прежними нужными настройками и подключениями данных.

Ненужный локальный тег удаляют точечно: docker rmi alpine:3.19. Docker проверит, не используется ли образ контейнерами. Это убирает локальную копию, а образ в реестре остаётся доступным.

Попробуйте в учебном терминале

В окружении заранее скачан alpine:3.19. Добавьте две новые версии, выберите одну для запуска и удалите старую. Сравнивайте docker images и docker ps -a: первый список относится к образам, второй — к экземплярам.

Здесь команды Docker имитируются: терминал хранит учебное состояние образов, контейнеров и файлов. Реальные службы и внешнюю сеть он не запускает.