Раньше мы запускали контейнеры командой docker run nginx, а потом своим Dockerfile собирали собственный образ myapp. И там, и там в основе лежал образ: для nginx его кто-то собрал до нас, а myapp мы собрали сами. Остается вопрос, который мы до сих пор обходили стороной: откуда Docker берет чужие образы и где может лежать ваш собственный. За это отвечают реестры образов, и в этом шаге разберемся, как они устроены.
Образ нужно где-то хранить
Когда вы выполняете docker run postgres, Docker сначала ищет образ postgres у себя на машине. Если его там нет, он идет за ним наружу, в реестр. Реестр образов – это хранилище, куда образы складывают и откуда их забирают. По умолчанию Docker обращается к публичному реестру Docker Hub.
Образ путешествует между машиной и реестром двумя командами. docker pull скачивает образ из реестра к вам, а docker push отправляет ваш собранный образ в реестр. Когда вы делаете docker run и образа нет локально, Docker выполняет pull за вас автоматически, поэтому отдельно тянуть образ обычно не приходится.
Имя и тег образа
У образа есть имя, по которому его находят в реестре, и тег, который уточняет версию. Вы их уже видели: в postgres:16 имя это postgres, а 16 после двоеточия это тег, то есть версия базы. Тег пишут через двоеточие после имени.
Если тег не указать, Docker подставляет latest, то есть «самую свежую». На практике полагаться на latest рискованно: сегодня под ним одна версия, завтра другая, и поведение незаметно меняется. Поэтому в рабочих проектах тег обычно фиксируют явно, как postgres:16, чтобы сборка оставалась предсказуемой.
Факт. Тег
latestне означает «всегда самая новая версия». Это просто тег по умолчанию, который ставится, когда никакого тега не задали. Он не обновляется сам по себе и легко может указывать на устаревший образ, если автор давно не перевешивал его на новую сборку. Из-за этогоlatestи считается ненадежным выбором для рабочих окружений.
Официальные образы и образы пользователей
На Docker Hub образы делятся на два рода. Есть официальные образы, которые ведут сами проекты или сопровождающая их команда: nginx, postgres, redis, python. Их имя короткое, без префикса, и им принято доверять как проверенному источнику. А есть образы, выложенные обычными пользователями и компаниями, у них имя идет с приставкой владельца, в форме имя-пользователя/образ. Это то же самое, что репозитории под аккаунтами на Git-платформе: пространство имен отделяет образы одного автора от другого.
| Что видите | Что это |
|---|---|
nginx, postgres | официальный образ, короткое имя без префикса |
bitnami/postgresql | образ пользователя или компании, имя через слеш |
postgres:16 | образ postgres тега 16 (версия) |
myapp:latest | ваш локальный myapp с тегом по умолчанию |
Свой образ в реестре
Образ, который вы собрали своим Dockerfile, по умолчанию остается у вас на машине. Чтобы его забрал сервер или коллега, образ нужно положить в реестр. Делается это в три приема: войти в реестр, дать образу имя с адресом реестра и аккаунта, отправить его командой push.
docker login
docker tag myapp myuser/myapp:1.0
docker push myuser/myapp:1.0После этого образ лежит в реестре под именем myuser/myapp с тегом 1.0, и любая машина с доступом стянет его командой docker pull myuser/myapp:1.0. Дальше тот же образ запускается привычным docker run. Так и замыкается путь приложения: собрали образ из Dockerfile, отправили в реестр, а сервер забрал оттуда ровно его и поднял контейнер.
Публичные и приватные реестры
Docker Hub удобен и публичен, но компании редко выкладывают свои образы у всех на виду. Для закрытых образов поднимают приватные реестры, доступные только своим. Это бывает реестр внутри облака, отдельный сервис у провайдера или реестр, развернутый на собственных серверах компании. Снаружи устроены они одинаково: тот же login, push и pull, разница только в адресе реестра в имени образа и в правах доступа. Поэтому, освоив Docker Hub, вы будете работать с любым приватным реестром почти так же.
Причем здесь DevOps
Реестр для девопса – это перевалочный пункт доставки, через который образ едет от сборки до запуска. Пайплайн CI/CD, который вы будете собирать дальше, обычно заканчивается тем, что собирает образ и кладет его в реестр командой push, а сервер или кластер забирает оттуда нужный тег и поднимает контейнеры. Поэтому единый, версионированный по тегам образ в реестре – это и есть та точка, где встречаются сборка приложения и его доставка на серверы.