1.1. Требования к Linux

Цели

После этого материала вы сможете:

• проверить, что ваша система пригодна для Docker Engine, и сделать это осознанно, а не по принципу «попробуем поставить»;
• определить CPU architecture и понять, почему это влияет на выбор образов;
• определить версию kernel и убедиться, что она поддерживает нужные механизмы;
• определить, какая версия cgroup используется, и объяснить, почему это важно для всего курса;
• оценить требования к дисковому пространству и выбрать место для Docker data;
• понять, что делать, если система не соответствует требованиям.

Предварительные знания

• Работа в терминале Linux: выполнение команд, чтение вывода.
• Понимание, что такое ядро операционной системы (в общих чертах).

Ключевые термины

Теория

Что Docker требует от системы

Docker Engine — это не виртуальная машина и не эмулятор. Он использует механизмы, которые уже есть в ядре Linux: namespaces, cgroups, capabilities, OverlayFS. Поэтому требования формулируются просто: нужно ядро Linux достаточно новой версии, собранное с нужными опциями, и файловая система, поддерживающая overlay.

Практически все современные дистрибутивы это обеспечивают. Проблемы возникают в трёх случаях: очень старая система, необычная файловая система, или контейнер/виртуальная машина с урезанным ядром (например, некоторые VPS на OpenVZ).

Официальные требования

Docker публикует список поддерживаемых версий Ubuntu. На момент написания курса (июль 2026) поддерживаются:

Курс ориентируется на LTS-версии: 22.04, 24.04, 26.04. Все команды курса проверены на этих версиях.

Поддерживаются архитектуры x86_64/amd64, armhf, arm64, s390x, ppc64le. Практически вы столкнётесь с первыми двумя.

Факт против рекомендации. Факт: Docker официально поддерживает перечисленные версии. Рекомендация: используйте LTS. Обычные релизы Ubuntu живут девять месяцев, и обновление системы посреди курса создаст лишние проблемы.

Почему architecture имеет значение

Образ содержит скомпилированные бинарные файлы. Образ, собранный для amd64, не запустится на arm64 без эмуляции. Это регулярный источник путаницы: разработчик на ноутбуке с ARM-процессором собирает образ, публикует его, а на сервере с amd64 он не запускается.

Многие официальные образы публикуются как multi-platform: под одним тегом лежит несколько вариантов, и Docker выбирает подходящий автоматически. Но это верно не для всех образов — и не для образов, которые собираете вы.

Подробно тема разбирается в разделе 03. Сейчас достаточно знать свою архитектуру.

cgroup v1 против cgroup v2

Это важнее, чем кажется. Cgroups — механизм ограничения ресурсов, и у него две несовместимые версии интерфейса.

cgroup v1 — старая модель: отдельная иерархия для каждого контроллера (memory, cpu, blkio...). Файлы разбросаны по разным точкам монтирования в /sys/fs/cgroup/.

cgroup v2 — единая иерархия: все контроллеры работают с одним деревом. Файлы имеют другие имена и другую семантику.

Практические последствия для курса:

1. Пути к файлам cgroup, показанные в разделе 02 и разделе 17, различаются между версиями.
2. Часть возможностей (например, корректный учёт памяти в rootless mode) работает только на v2.
3. Docker Engine 29 объявил поддержку cgroup v1 устаревшей.

Ubuntu использует cgroup v2 по умолчанию начиная с версии 21.10. Если у вас 22.04 или новее — почти наверняка v2. Курс написан под v2; для v1 добавлены отдельные примечания там, где это существенно.

Файловая система и storage driver

Docker хранит слои образов в каталоге данных (по умолчанию /var/lib/docker) и объединяет их через storage driver. Современный и единственный рекомендуемый драйвер — overlay2.

overlay2 работает поверх ext4, xfs (с ftype=1) и большинства других распространённых файловых систем. Проблемы возникают на экзотических конфигурациях и на xfs, отформатированной без ftype=1 — такая система не поддерживает overlay, и Docker откажется работать.

Начиная с Docker Engine 29 новые установки по умолчанию используют containerd image store вместо классического хранилища образов. Он использует те же снапшоттеры на базе OverlayFS, но хранит образы иначе. Последствия разбираются в разделе 03.

Дисковое пространство

Требования курса:

Это не преувеличение. Build cache растёт незаметно, и типичный сценарий на второй неделе курса — «на диске кончилось место, и я не понимаю почему». Раздел 13.04 посвящён именно этому.

Оперативная память

Минимум для базовых упражнений — 2 GB. Начиная с раздела 09 одновременно работают FastAPI, PostgreSQL, Redis и worker; комфортный минимум — 4 GB.

Внутренний механизм

Что именно проверяет Docker при запуске

При старте dockerd проверяет доступность механизмов ядра и выбирает драйверы. Основные проверки:

1. Поддержка namespaces. Ядро должно быть собрано с CONFIG_NAMESPACES, CONFIG_PID_NS, CONFIG_NET_NS, CONFIG_UTS_NS, CONFIG_IPC_NS, CONFIG_USER_NS. В стандартных дистрибутивных ядрах это включено.
2. Поддержка cgroups. Нужны контроллеры memory, cpu, cpuset, pids, io.
3. Поддержка выбранного storage driver. Для overlay2 — модуль overlay и подходящая файловая система под каталогом данных.
4. Поддержка сетевых механизмов. Модули bridge, veth, iptables или nftables, br_netfilter.

Если чего-то не хватает, daemon либо не стартует, либо стартует с предупреждениями. Предупреждения видны в docker info в конце вывода.

Почему на некоторых VPS Docker не работает

Виртуализация бывает разной. На KVM, Xen, VMware и физическом сервере у вас своё ядро — Docker работает. На OpenVZ и части LXC-конфигураций ядро общее с хост-системой провайдера, и вы не можете загружать модули или использовать все namespaces. Там Docker может не запуститься или работать частично.

Проверить тип виртуализации:

systemd-detect-virt

Вывод kvm, vmware, microsoft, none (физическая машина) — всё в порядке. Вывод openvz или lxc — возможны проблемы.

Команды и примеры

Проверка architecture

uname -m

Что делает: выводит машинную архитектуру.

Ожидаемый результат — одна строка:

x86_64

Или aarch64 на ARM-системах.

Соответствие обозначений, которое нужно помнить: x86_64 в выводе uname — это amd64 в терминологии Docker; aarch64 — это arm64. Одна и та же архитектура, два набора названий.

Второй способ, дающий сразу «докеровское» имя:

dpkg --print-architecture

amd64

Эта команда используется при настройке apt repository в следующем уроке.

Проверка версии kernel

uname -r

6.8.0-88-generic

Первые два числа — версия ядра (здесь 6.8). Docker Engine требует ядро не ниже 3.10, что сегодня не является практическим ограничением: любая поддерживаемая версия Ubuntu идёт с ядром 5.15 и новее.

Полная информация:

uname -a

Проверка дистрибутива

cat /etc/os-release

Важные поля:

NAME="Ubuntu"
VERSION_ID="24.04"
VERSION_CODENAME=noble
UBUNTU_CODENAME=noble

VERSION_CODENAME понадобится при настройке репозитория. Извлечь его отдельно:

. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}"

Что делает: загружает переменные из файла в текущий shell и печатает кодовое имя, предпочитая UBUNTU_CODENAME. Конструкция ${A:-B} означает «значение A, а если оно пустое — значение B». Это нужно для производных дистрибутивов (Linux Mint, Pop!_OS), где VERSION_CODENAME содержит собственное имя, а UBUNTU_CODENAME — соответствующее имя Ubuntu.

Проверка версии cgroup

stat -fc %T /sys/fs/cgroup/

Что делает: выводит тип файловой системы, смонтированной в /sys/fs/cgroup.

Дополнительная проверка для v2 — наличие файла с перечнем доступных контроллеров:

cat /sys/fs/cgroup/cgroup.controllers

cpuset cpu io memory hugetlb pids rdma misc

Если файл существует и содержит memory, cpu, pids — cgroup v2 работает и нужные контроллеры доступны.

Проверка свободного места

df -h /var/lib

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       457G   89G  345G  21% /

Смотрите на колонку Avail для раздела, содержащего /var/lib. Именно там по умолчанию окажется /var/lib/docker.

Проверить тип файловой системы:

df -T /var/lib

Filesystem     Type  1K-blocks     Used Available Use% Mounted on
/dev/sda2      ext4  478889968 92345678 362104290  21% /

ext4 или xfs — подходят. Если xfs, дополнительно проверьте ftype:

xfs_info /var/lib | grep ftype

Нужно ftype=1. При ftype=0 overlay2 работать не будет, и файловую систему придётся пересоздавать.

Проверка оперативной памяти

free -h

               total        used        free      shared  buff/cache   available
Mem:            15Gi       3.2Gi       8.1Gi       412Mi       4.4Gi        11Gi

Смотрите на available — это память, доступная приложениям без обращения к swap.

Проверка типа виртуализации

systemd-detect-virt

kvm

или none на физической машине.

Практическое упражнение

Соберите отчёт о пригодности вашей системы. Результатом должен быть текстовый файл, содержащий значения всех проверенных параметров и вывод о том, готова ли система.

Задание: напишите скрипт check-system.sh, который выводит:

1. Дистрибутив и версию.
2. Кодовое имя релиза (то, которое пойдёт в apt repository).
3. Architecture в двух формах: uname -m и dpkg --print-architecture.
4. Версию kernel.
5. Версию cgroup.
6. Тип файловой системы и свободное место под /var/lib.
7. Доступную оперативную память.
8. Тип виртуализации.

Скрипт должен работать без sudo и не должен ничего изменять в системе.

Подсказки

row() { printf '%-24s %s\n' "$1:" "$2"; }

codename="$(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")"

Решение

Сначала выполните задание самостоятельно.

#!/usr/bin/env bash
# check-system.sh — проверка пригодности системы для Docker Engine.
set -euo pipefail

row() { printf '%-26s %s\n' "$1:" "$2"; }

echo "=== Пригодность системы для Docker Engine ==="
echo

# Дистрибутив
distro="$(. /etc/os-release && echo "$NAME $VERSION_ID")"
codename="$(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")"
row "Дистрибутив" "$distro"
row "Кодовое имя релиза" "$codename"

# Architecture
row "Architecture (uname)" "$(uname -m)"
row "Architecture (dpkg)" "$(dpkg --print-architecture 2>/dev/null || echo 'dpkg недоступен')"

# Kernel
row "Kernel" "$(uname -r)"

# cgroup
cgroup_fs="$(stat -fc %T /sys/fs/cgroup/)"
if [ "$cgroup_fs" = "cgroup2fs" ]; then
    cgroup_ver="v2"
else
    cgroup_ver="v1 или гибридный режим ($cgroup_fs)"
fi
row "cgroup" "$cgroup_ver"

if [ -r /sys/fs/cgroup/cgroup.controllers ]; then
    row "cgroup controllers" "$(cat /sys/fs/cgroup/cgroup.controllers)"
fi

# Файловая система и место
row "FS под /var/lib" "$(df -T /var/lib | awk 'NR==2 {print $2}')"
row "Свободно под /var/lib" "$(df -h /var/lib | awk 'NR==2 {print $4}')"

# Память
row "Доступно RAM" "$(free -h | awk '/^Mem:/ {print $7}')"

# Виртуализация
row "Виртуализация" "$(systemd-detect-virt 2>/dev/null || echo 'неизвестно')"

echo
echo "=== Вывод ==="

ok=true

avail_gb="$(df -BG --output=avail /var/lib | tail -1 | tr -dc '0-9')"
if [ "$avail_gb" -lt 20 ]; then
    echo "  [!] Свободно ${avail_gb} GB — рекомендуется не менее 20 GB."
    ok=false
fi

if [ "$cgroup_fs" != "cgroup2fs" ]; then
    echo "  [!] Используется cgroup v1. Курс ориентирован на v2;"
    echo "      часть путей в /sys/fs/cgroup будет отличаться."
fi

virt="$(systemd-detect-virt 2>/dev/null || echo none)"
case "$virt" in
    openvz|lxc|lxc-libvirt)
        echo "  [!] Виртуализация $virt может не поддерживать Docker полностью."
        ok=false
        ;;
esac

if $ok; then
    echo "  [+] Система пригодна для установки Docker Engine."
fi

chmod +x check-system.sh
./check-system.sh

Проверка результата

Скрипт должен отработать без ошибок и вывести все восемь параметров. Проверьте, что:

./check-system.sh | wc -l

выводит не менее 14 строк, и что в выводе присутствует строка с cgroup.

Если получили [+] Система пригодна — переходите к установке.

Типичные ошибки

Контрольные вопросы

На понимание:

1. Почему Docker не требует, чтобы в образе было ядро Linux?
2. Что произойдёт, если попытаться запустить образ, собранный для arm64, на машине amd64?
3. Чем cgroup v2 отличается от cgroup v1 с точки зрения организации файлов?
4. Почему на некоторых VPS Docker не работает, хотя там установлен Linux?
5. Почему для storage driver важен тип файловой системы под каталогом данных Docker?

На применение:

6. Какой командой получить кодовое имя релиза так, чтобы это работало и на Ubuntu, и на Linux Mint?
7. Как проверить, что контроллер memory доступен в cgroup v2?
8. Как узнать, сколько свободного места осталось на разделе, где будет лежать /var/lib/docker?

На диагностику:

9. docker info в конце вывода показывает предупреждение о недоступности контроллера memory. Где искать причину?
10. На машине с 40 GB диска через две недели работы место закончилось, хотя проектов немного. Какие категории данных стоит проверить в первую очередь?

Краткое резюме

1. Docker использует механизмы ядра хост-системы; отдельное ядро в образе не нужно.
2. Курс ориентирован на Ubuntu LTS 22.04, 24.04 и 26.04 и на архитектуры amd64 и arm64.
3. x86_64 = amd64, aarch64 = arm64 — одно и то же в разных обозначениях.
4. Cgroup v2 — современный стандарт и основа примеров курса; Ubuntu использует его с версии 21.10.
5. Docker Engine 29 объявил cgroup v1 устаревшим.
6. Storage driver overlay2 требует подходящей файловой системы; на xfs нужен ftype=1.
7. Реалистичное требование к диску — не менее 20 GB свободно.
8. Для разделов начиная с девятого нужно не менее 4 GB оперативной памяти.
9. На OpenVZ и части LXC-конфигураций Docker может не работать из-за общего ядра.
10. Проверку системы имеет смысл автоматизировать скриптом — он пригодится и на других машинах.

Официальные источники

Навигация

Вернуться к разделу
Следующий материал → Установка Docker Engine
Главное оглавление