Этап 2 - Docker Images
Docker image — первый объект, из-за которого Docker отличается от обычного script. Это не запущенное приложение. Это версионируемый пакет, из которого можно снова и снова создавать containers.
Анатомия image
Image строится из layers. Каждый layer — read-only изменение файловой системы: установка packages, копирование files, metadata или добавление application artifacts. Docker переиспользует layers с одинаковым содержимым, экономя скачивание и место на диске.
Base OS layer
Runtime layer
Dependencies layer
Application layer
Image metadata
Lifecycle простой: найти или собрать image, поставить tag, отправить или скачать через registry, запустить containers из него, затем заменить новым image при изменении приложения. Старый image не редактируют на месте. Эта immutable model важна для rollback и repeatability.
Registry и tags
Docker Hub — публичный registry. Official images вроде postgres, nginx, redis и eclipse-temurin лучше случайных images, потому что имеют documented conventions. Но им все равно нужны explicit tags. Tag latest — движущаяся метка, а не стабильная версия.
Layers как cache и history
Каждый image layer отвечает на вопрос: что изменилось в filesystem или metadata после этого build step? Поэтому docker history полезен. Он показывает, содержит ли image большие package installs, скопированные application files или commands, после которых нужно было сделать cleanup.
Layer reuse также объясняет, почему Docker builds могут быть быстрыми. Если dependency layer не изменился, Docker переиспользует его. Если скопировать весь project слишком рано, любое маленькое изменение code может инвалидировать следующие layers и замедлить build.
Это не только performance-тема. Layers также могут случайно сохранить sensitive files. Если secret скопировали в одном layer и удалили в следующем, он все равно может остаться доступным через image history.
Tags, digests и trust
Tag — человекочитаемый pointer. Он удобен, потому что люди запоминают postgres:16, но это не самая строгая идентичность. Digest связан с точным содержимым. В строгих production workflows команды могут фиксировать digests, чтобы точно знать, что запускалось.
Trust также зависит от source image. Official image не становится идеальным автоматически, но обычно имеет документацию и поддерживается по более понятным conventions. Случайный image от неизвестного publisher может работать сегодня и стать supply-chain risk завтра.
Для обучения explicit tags достаточно. Для production команда должна также понимать, откуда приходят images, как они сканируются и как одобряются updates.
Где images хранятся и используются
Когда вы запускаете docker pull nginx:1.27, command вводится на вашей машине, но обращается к remote registry. Registry отправляет image layers локальному Docker daemon. Layers сохраняются во внутреннем Docker storage, а не в папке проекта.
Когда позже вы запускаете container из этого image, Docker не скачивает его заново, если нужные layers уже есть локально. Поэтому первый запуск может быть медленнее, а следующие почти мгновенными.
На server работает та же идея. Server скачивает images в свое локальное Docker storage. Image cache на ноутбуке и image cache на server — разные. Push image в registry нужен для того, чтобы другая машина могла скачать тот же artifact.
Команды: запустить и проверить
Выполняйте эти commands в terminal той машины, где установлен Docker. Для локального обучения это terminal на вашем ноутбуке. Для VPS сначала подключитесь к server по SSH, затем запускайте commands там. Не вставляйте commands вслепую: запустите одну command, посмотрите, что изменилось, затем переходите к следующей.
docker search nginx
docker pull nginx:1.27
docker image ls
docker image inspect nginx:1.27
docker history nginx:1.27
Таблица для ориентира
| Тема | Что означает | Практический вывод |
|---|---|---|
| Layer | Read-only изменение файловой системы | Cache и reuse между images |
| Tag | Читаемый указатель вроде postgres:16 | Может двигаться; фиксируйте версии осознанно |
| Digest | Точная идентичность содержимого | Используйте, когда нужна точная reproducibility |
Аудит image
Выберите один image из проекта и ответьте на три вопроса: кто его поддерживает, какой tag используется и может ли этот tag измениться. Если ответ неясен, image недостаточно документирован для командного workflow.
Также посмотрите image history. Пока не нужно понимать каждый layer, но нужно увидеть, что image строится из последовательности filesystem и metadata changes.
Контрольная точка
Идите дальше, когда можете объяснить layers, tags, digests и почему latest рискован за пределами быстрого эксперимента.
Практика: разбор image
Скачайте один official image и изучите его. Посмотрите tag, creation date, environment variables, exposed ports и layer history. Затем спросите, что сломается, если tag незаметно изменится. Так image versioning становится практической темой: не потому что tags интересны сами по себе, а потому что moving base image может изменить runtime behavior без изменения application code.
Короткий вывод
Главный ориентир: image должен быть повторяемым artifact. Если вы не можете сказать, из какого tag он собран и почему выбран именно этот base image, дальнейшие проблемы с build и deployment будет сложно расследовать.