Как машина узнаёт где находится образ Linux

Отличный вопрос, который затрагивает самую суть работы контейнерных технологий. Машина (хост) узнаёт, где находится образ Linux, через комбинацию именования образов, работы реестра контейнеров (Registry) и локального кэша образов. Весь процесс управляется container runtime (например, Docker Engine, containerd).

Давайте разберем этот механизм по шагам.

1. Анатомия имени образа: "Адрес" в мире контейнеров

Когда вы даете команду docker run nginx:alpine, вы на самом деле указываете не просто имя, а полный путь к образу. Это имя имеет универсальный формат:

[REGISTRY_HOST[:PORT]/][USERNAME/]NAME[:TAG|@DIGEST]

• REGISTRY_HOST (Хост реестра): Это домен, где хранится реестр. По умолчанию используется Docker Hub (docker.io). Если хост не указан, runtime подставляет его автоматически.
• USERNAME (Имя пользователя/организации): Учетная запись в реестре. Для официальных образов (как nginx) этот сегмент может отсутствовать.
• NAME (Имя репозитория): Основное имя образа (например, nginx, ubuntu, postgres).
• TAG (Тег): Метка, обычно указывающая на версию (alpine, latest, 1.23). По умолчанию — latest.
• DIGEST (Дайджест): Уникальный криптографический хеш (SHA256) содержимого образа. Это абсолютно точный идентификатор.

Примеры:

• nginx:alpine -> docker.io/library/nginx:alpine (официальный образ на Docker Hub)
• myregistry.local:5000/myapp/api:v1.2 (приватный реестр в корпоративной сети)
• ubuntu@sha256:abc123... (образ Ubuntu, идентифицируемый по конкретному дайджесту)

2. Процесс поиска и загрузки образа

Когда вы запускаете команду, container runtime выполняет четкий алгоритм:

1. Парсинг имени: Runtime разбирает переданное имя на компоненты (реестр, имя репозитория, тег).
2. Проверка локального кэша: Первым делом он смотрит в свою локальную базу данных (обычно в /var/lib/docker/overlay2/ или /var/lib/containerd/). Если там уже есть образ с таким полным именем и дайджестом, он используется мгновенно. Проверить локальные образы можно командой:

   docker images
   # или
   crictl images
   

3. Обращение к реестру: Если образа локально нет, runtime обращается к указанному (или подставленному по умолчанию) реестру. Docker Hub — самый известный публичный реестр, но есть и другие: Google Container Registry (GCR), Amazon ECR (ECR), Azure Container Registry (ACR), а также приватные (Harbor, GitLab Registry, Nexus).
4. Аутентификация: Для приватных реестров runtime использует учетные данные из ~/.docker/config.json.
5. Загрузка слоев (Layers): Образ — это не монолитный файл, а набор иммутабельных слоев. Runtime загружает манифест образа, который содержит список этих слоев и их дайджесты. Затем он скачивает каждый слой, которого нет в локальном кэше. Это экономит место и время: если у вас уже есть слой ubuntu:jammy, он будет переиспользован для множества других образов на его основе.
6. Сборка образа: После загрузки всех слоев runtime собирает из них готовый к запуску образ в своей локальной файловой системе (используя Union File Systems, такие как overlay2, aufs или btrfs).

3. Ключевые технологии и конфигурация

• Container Runtime Interface (CRI): В Kubernetes runtime (например, containerd, CRI-O) получает команды через этот стандартный интерфейс.
• Конфигурация реестров: Вы можете явно указать, где искать образы, настроив Container Image Registry mirrors или добавив insecure-registries в конфигурацию демона (например, в /etc/docker/daemon.json для Docker).

  {
    "registry-mirrors": ["https://mirror.gcr.io"],
    "insecure-registries": ["myregistry.local:5000"]
  }
  

• Kubernetes и Pull Policies: В Kubernetes вы можете управлять поведением загрузки через imagePullPolicy в спецификации пода (Always, IfNotPresent, Never). Это директива для kubelet, который затем взаимодействует с container runtime на узле.

Итог: Иерархия поиска

Таким образом, машина узнает местонахождение образа через строгую иерархию:

1. Интерпретация полного имени образа (разбор реестра, репозитория, тега).
2. Поиск в локальном хранилище container runtime — самый быстрый путь.
3. Если локально нет — обращение к сконфигурированному реестру контейнеров (публичному или приватному) по сетевому адресу, указанному в имени.
4. Загрузка недостающих слоев образа и их сохранение в локальном кэше для будущего использования.

Этот механизм обеспечивает портативность ("работает на любой машине с Docker/K8s"), эффективность (кэширование слоев) и гибкость (поддержка множества реестров).