Что такое образ на самом деле: конфиг плюс стек контентно-адресуемых слоёв, а не снапшот машины

Что ты на самом деле тянешь

Когда ты делаешь docker pull nginx:1.27, ты скачиваешь не машину. По порядку ты получаешь: маленький манифест (JSON, несколько КБ) со списком всего; блоб конфига (JSON) с переменными окружения, entrypoint, рабочей директорией, открытыми портами и упорядоченным списком дайджестов слоёв, образующих корневую ФС; и затем сами слои — gzip-tar-архивы, каждый назван по sha256 своего содержимого. Загляни прямо в него:

$ docker manifest inspect nginx:1.27
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "manifests": [
    { "platform": {"architecture":"amd64","os":"linux"}, "digest": "sha256:7f0a...", "size": 2295 },
    { "platform": {"architecture":"arm64","os":"linux"}, "digest": "sha256:e3c1...", "size": 2295 }
  ]
}

Этот верхний объект — индекс: один тег, несколько манифестов под архитектуры. Демон выбирает манифест под твой CPU, затем тянет его конфиг и слои. Для nginx:1.27 на amd64 это 7 слоёв общим объёмом ~67 МБ в сжатом виде; база Debian (~29 МБ) и бинарники nginx доминируют, а прикладной слой на тег часто весит несколько сотен КБ.

Конфиг — это идентичность образа

Почему правка одной переменной окружения даёт совершенно новый image ID, хотя ни один файл на диске не изменился? Потому что image ID — это не хеш слоёв, а хеш конфига. Блоб конфига — та часть, о существовании которой забывают. Это обычный JSON:

{
  "architecture": "amd64", "os": "linux",
  "config": {
    "Env": ["PATH=/usr/local/sbin:/usr/local/bin:...", "NGINX_VERSION=1.27.0"],
    "Entrypoint": ["/docker-entrypoint.sh"],
    "Cmd": ["nginx", "-g", "daemon off;"],
    "ExposedPorts": {"80/tcp": {}}
  },
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:1f3e... ",
      "sha256:8a2c... ",
      "sha256:b91d... "
    ]
  },
  "history": [ { "created_by": "RUN apt-get install ..." } ]
}

Здесь важны две вещи. Во-первых, rootfs.diff_ids — это упорядоченный рецепт файловой системы: сложи эти слои снизу вверх — и получишь корневую директорию контейнера. Во-вторых, sha256 самого этого JSON-конфига — это image ID, тот sha256:..., что ты видишь в docker images --digests. Поменяй одну переменную окружения, пересобери — и байты конфига изменятся, поэтому image ID изменится, даже если каждый дайджест слоя идентичен. Образ — это его конфиг; слои — общий контент, на который конфиг ссылается.

Что добавляет контейнер

Образ read-only — каждый слой неизменяем, заморожен своим дайджестом. Как же запущенный контейнер пишет лог-файл? При docker run рантайм складывает read-only слои образа через union-файловую систему (overlay2 на Linux) и добавляет ровно один тонкий записываемый слой сверху. Запись попадает туда по copy-on-write: меняешь /etc/hosts — overlay2 копирует файл вверх, в записываемый слой, и правит копию; нижний read-only слой не меняется. Удалишь контейнер — этот записываемый слой отбрасывается, и именно поэтому важные данные должны жить в томе, а не в контейнере. Образ — неизменяемый стек; контейнер — этот стек плюс один одноразовый слой-черновик.

Поэтому же «это снапшот машины» вводит в заблуждение. Снапшот ВМ — монолитный непрозрачный образ диска, копируемый целиком. OCI-образ — структурированный, адресуемый, общий артефакт: тянешь дельтами (только недостающие слои), делишь базы между сотнями образов и детерминированно пересобираешь из рецепта-конфига.