Контейнеры представляют собой одну из наиболее революционных технологий в современной IT-сфере, предлагая эффективный способ упаковки приложений с их зависимостями в единый изолированный пакет. Одной из ключевых особенностей контейнеров является их возможность создавать изолированный вид файловой системы, который изнутри воспринимается как полноценная операционная система Linux, даже если сама хост система работает на другой версии или дистрибутиве. Например, запуская nginx внутри Docker, пользователь получает привычное окружение Debian, независимо от хоста. Но как достигается такая впечатляющая иллюзия? Чтобы понять это, целесообразно рассмотреть, как именно работает файловая система внутри контейнера и как создавать подобный контейнер с нуля, используя базовые инструменты Linux - без использования сложных обёрток и магии современных контейнерных систем. Основой изоляции файловой системы в контейнерах служит пространство имён монтирования (mount namespace).
Именно через него контейнер получает собственное "видение" структуры директорий, отделённое от других процессов на той же машине. Именно пространство имён монтирования даёт возможность видеть внутри контейнера отдельные файловые системы и монтирования, которые не затрагивают основной хост. В Linux пространство имён представляет собой механизм, при помощи которого можно ограничить видимость различных системных ресурсов, таких как процессы, сеть, файловые системы и прочее. При создании контейнера пространство имён монтирования играет решающую роль: процессы внутри контейнера видят свою отдельную таблицу монтировок, не пересекающуюся с хостовой. Чтобы углубиться в суть, можно провести эксперимент, воспользовавшись командой unshare с опцией --mount.
Запуская отдельную bash-сессию с собственным пространством имён монтирования, становится понятно, что файл, созданный во внешнем пространстве имён, виден и внутри нового пространства, что можно продемонстрировать командой cat. Тем не менее, если в новом пространстве монтирования создать новую точку монтирования, например сделав bind mount директории /tmp в /mnt, то внутри этой сессии /mnt отобразит содержимое /tmp, а в хостовом пространстве эта же директория будет пустой. Таким образом, пространство имён позволяет создать различные "видения" одной и той же файловой системы, где изменения в списке монтирований не влияют друг на друга. Отличительной чертой пространства имён монтирования является то, что оно изолирует именно таблицу монтирований, а не само содержимое файловых систем. Это означает, что контент, например файлов, остаётся общим для всех пространств, если директории привязаны к одним и тем же физическим устройствам, но каждая таблица монтирования имеет собственные точки монтирования и может отображать различные структуры.
Термин "mount propagation" или распространение монтирований также важен для понимания контейнерных файловых систем. Mount propagation определяет способы, которыми операции монтирования и размонтирования пропагируют между связанными точками в разных пространствах имён монтирования. По умолчанию новые пространства имеют private propagation, то есть изменения монтирования в хосте не отражаются в новом пространстве, и наоборот. Однако для работы систем контейнеров может требоваться настроить propagation на shared или slave, чтобы синхронизировать определённые точки монтирования между пространствами. В практике создания Docker-подобного контейнера после создания пространства имён монтирования с помощью unshare происходит процесс "pivot_root".
Эта команда сдвигает корневую точку дерева файловой системы (root filesystem) на новую директорию, тем самым меняя "корень" видимой файловой системы на изолированную область, например на корневую файловую систему подготовленного контейнера. Благодаря этому процессы, запущенные внутри, видят именно эту файловую систему как корневую, а не хостовую. Это важный шаг, который создаёт основное разделение и позволяет контейнерам иметь собственное полноценное окружение. Создание корневой файловой системы для контейнера подразумевает подготовку минимальной структуры каталогов - например, имитирующей полноценный Linux-дистрибутив с каталогами /bin, /lib, /etc, /proc и другими. Для этого часто используют заранее собранные базовые образы на основе Debian, Alpine или других дистрибутивов.
При создании контейнера вручную можно взять минимальный root filesystem, распаковать его в отдельную директорию и использовать как новое root с помощью pivot_root. Внутри контейнера, чтобы обеспечить корректную работу процессов, требуется смонтировать специальные системные точки, например /proc - виртуальную файловую систему, отображающую информацию о процессах и системе. Это делается через команду mount, указывающую тип proc. Другие специальные файловые системы, такие как sysfs и devtmpfs, также монтируются, чтобы обеспечить полноценный функционал. Важно понимать, что кроме пространства имён монтирования, контейнеры используют и другие типы пространств имён: для процессов (PID namespace), сетей (network namespace), управления ресурсами (cgroups), имен хоста (UTS namespace) и др.
Вместе они формируют полноценную изоляцию, давая контейнеру видимость, что он работает на отдельной машине. Однако именно пространство имён монтирования отвечает за файловую систему, что является центральной частью среды выполнения контейнера. Использование обычных утилит Linux - unshare, mount, pivot_root, - позволяет создать контейнер с минимальным набором зависимостей. Это помогает глубже понять принципы работы контейнерной изоляции, без скрытой магии популярных движков, таких как Docker или Podman. Помимо учебной ценности, такие знания облегчают диагностику, устранение проблем и оптимизацию работы с настоящими контейнерами.
Для управления сложными сборками файловых систем в современных контейнерах применяется файловая система с копированием при записи (copy-on-write), например OverlayFS. Она позволяет создавать слои, которые накладываются друг на друга, обеспечивая эффективное использование дискового пространства и быстроту развёртывания контейнеров. Каждая новая прослойка изменяет только то, что отличается от базового образа, в то время как основная структура остаётся общей. Современные контейнерные рунтаймы в дополнение к mount namespace активно используют bind mounting и размонтирование отдельных директорий для изоляции определённых частей файловой системы. Например, директорию /tmp монтируют как tmpfs - временную файловую систему, создающуюся в памяти, обеспечивая контейнерам полностью независимое и изолированное пространство для временных данных.
Изоляция файловой системы является краеугольным камнем безопасности контейнеров. Она предотвращает влияния контейнера на хостовую систему и другие контейнеры, ограничивая видимость и доступ к определённым ресурсам. При этом правильная настройка пропагации монтирований и использование различных пространств имён обеспечивает гибкость и удобство работы с контейнерами. Таким образом, глубина и сложность процессов создания файловой системы контейнера напрямую связана с особенностями работы пространств имён linux и возможностей монтирования. Понимание функционирования mount namespace, pivot_root и механизмов распространения монтирований открывает двери к самостоятельному созданию и оптимизации контейнеров, при этом позволяя взглянуть под капот популярных решений, таких как Docker.
Это не только дает возможность создавать контейнеры с нуля, но и расширяет кругозор в вопросах контейнерной безопасности, производительности и масштабируемости. Для профессионального администратора и инженера по DevOps знание основ работы с файловой системой контейнеров на уровне ядра Linux остается ключевым навыком, который укрепляет позиции в области современного программного обеспечения и контейнерных технологий. .
