Что запускает образ Linux

Отличный, фундаментальный вопрос для DevOps-инженера. Образ Linux, будь то файл .iso, .img, .qcow2, или слой контейнера, сам по себе — это статичный бинарный слепок файловой системы. Его нельзя "запустить" в прямом смысле. Его загружает и исполняет ядро операционной системы (Kernel), но процесс инициализации сильно зависит от контекста.

Давайте разберем ключевые сценарии.

1. Физический сервер или виртуальная машина (Bare-metal / VM)

Здесь образ — это обычно установочный ISO или образ диска (raw, qcow2, vmdk). Запускает его цепочка аппаратного и программного обеспечения:

1. BIOS/UEFI на физическом железе или гипервизоре (KVM, VMware, Hyper-V) выполняет POST и ищет загрузочное устройство.
2. Загрузчик (чаще всего GRUB2 или systemd-boot), который находится в самом образе (например, в разделе /boot). Загрузчик знает, где на диске лежит ядро и initramfs.
3. Ядро Linux (vmlinuz) загружается в память. Оно инициализирует оборудование, драйверы, подключает корневую файловую систему (rootfs). Часто для этого нужен initramfs — временная корневая ФС в RAM, содержащая драйверы и утилиты для монтирования настоящего root.
4. Процесс init (PID 1). Это первый пользовательский процесс, который запускает ядро после монтирования rootfs. В современных дистрибутивах это systemd, в старых — SysVinit или Upstart.

   # Проверить, кто является PID 1
   ps -p 1
   # COMMAND
   # systemd
   

5. Systemd (или другой init) запускает целевые юниты (multi-user.target, graphical.target), которые, в свою очередь, запускают все системные сервисы (сеть, демоны входа, cron и т.д.).

Итого: Аппаратура → Загрузчик (из образа) → Ядро (из образа) → Init (из образа) → Пользовательское пространство.

2. Контейнер (Docker, containerd, Podman)

В мире контейнеров "образ Linux" — это, как правило, многослойная файловая система (overlayfs, aufs) + метаданные. Здесь ключевое отличие: запускает образ не собственное ядро из образа, а ядро хост-системы (Host Kernel). Контейнер — это изолированный процесс.

1. Движок контейнеризации (например, dockerd или containerd) подготавливает среду:

    *   Скачивает слои образа.
    *   Создает объединенный слой для записи (Copy-on-Write).
    *   Создает пространства имен (namespaces) для изоляции: PID, сеть, mount, UTS и т.д.
    *   Настраивает группы контроля (cgroups) для ограничения ресурсов.
    *   Задает корневую файловую систему (rootfs) контейнера — это и есть смонтированный образ.

1. Запускается один процесс, указанный как CMD или ENTRYPOINT в Dockerfile. В контейнерах этот процесс часто и является PID 1 внутри своего пространства имен, но его роль обычно ограничена (это не полноценный systemd, а приложение, например, nginx или python-скрипт).

   # Пример Dockerfile
   FROM alpine:latest
   # Образ содержит минимальную файловую систему Alpine Linux
   CMD ["/bin/sh"]
   # При запуске `docker run` будет исполнен именно этот shell,
   # использующий ядро хоста, но видящий файлы из образа.
   

2. Ядро хоста управляет этим процессом, как и любым другим, но благодаря namespace он изолирован.

Итого: Движок контейнеров + Ядро хоста → Настройка изоляции (namespaces/cgroups) → Запуск процесса внутри rootfs из образа.

3. Облачные инстансы и инфраструктура как код (IaC)

Здесь образ (Amazon Machine Image - AMI, Google Cloud Image, Azure VHD) — это шаблон. Его запускает облачный провайдер по вашему запросу (через API, консоль или инструменты IaC).

• Пример для AWS EC2 через Terraform:

  resource "aws_instance" "app_server" {
    ami           = "ami-0c55b159cbfafe1f0" # Это ID образа Amazon Linux 2
    instance_type = "t2.micro"
    # Terraform отправляет API-вызов в AWS, который:
    # 1. Берет указанный AMI из S3.
    # 2. Запускает новый экземпляр виртуальной машины на гипервизоре AWS (Nitro).
    # 3. Процесс загрузки аналогичен пункту 1 (VM), но инициируется облачной платформой.
  }
  

Ключевые отличия в механизме запуска

Заключение для DevOps:

Понимание этой разницы критически важно. Когда вы делаете docker run nginx, вы не "запускаете образ", а даете команду Docker-демону создать и запустить контейнер на основе этого образа. Когда вы разворачиваете VM из cloud-init, вы даете команду API облака развернуть инстанс из шаблона AMI.

В DevOps-практике мы автоматизируем эти процессы:

• Для контейнеров — оркестраторы (Kubernetes) через kubelet и CRI.
• Для VM — инструменты IaC (Terraform, Pulumi) и конфигурационного менеджмента (Ansible, Chef).
• Для физических серверов — системы PXE-загрузки и менеджеры конфигураций.

Таким образом, "образ" — это пакет со средой выполнения, а механизм его "запуска" определяется целевой платформой и тем, какая абстракция (машина или процесс) требуется.