Контейнеризация или виртуализация на уровне ОС — метод виртуализации,
при котором ядро операционной системы
поддерживает несколько изолированных экземпляров пространства пользователя, вместо одного.
Эти экземпляры (часто называемые контейнерами или зонами) с точки зрения пользователя полностью идентичны реальному серверу.
Для систем на базе UNIX, эта технология может рассматриваться как улучшенная реализация механизма chroot.
Ядро обеспечивает полную изолированность контейнеров, поэтому программы из разных контейнеров не могут воздействовать друг на друга.
Виртуализация на уровне ОС обычно используется в вирутальных хостингах, где они полезны для выделения надежно ограниченных аппаратных
ресурсов среди большого количества взаимно не доверяющих пользователей.
Системные администраторы могут также использовать их для консолидации серверного оборудования
за счет централизации служб на разных узлах в контейнеры на одном сервере.
Другие типичные сценарии включают в себя разделение нескольких приложений в отдельных контейнерах для улучшения безопасности,
аппаратной независимости, добавление функций управления ресурсами.
Повышение безопасности обеспечивается за счет использования механизма chroot-окружения,
однако, оно далеко не всегда достаточно безопасное (возможна атака chroot/jails/docker escape).
Реализации виртуализации на уровне ОС предоставляют возможности живой миграции (live-migrations), которая может быть использована
для динамической балансировки нагрузки контейнеров между узлами в кластере.
Виртуализации на уровне ОС практически не предполагает никакого оверхеда (снижения производительности), потому что программы в виртуальных разделах используют нормальный интерфейс системных вызовов ОС и их не нужно эмулировать или запускать в виртуальной машине, как это бывает в случае с большими системами виртуализации (таких как VMware ESXi, QEMU или Hyper-V) или паравиртуализации (Xen и UML). Этот вид виртуализации не требует поддержки каких-либо технологий в оборудовании для эффективного выполнения.
Оверхед - это разница между производительностью приложения внутри виртуального окружения и того же приложения работающего без использования виртуализации вообще
Виртуализация на уровне ОС не такая гибкая, как другие виды виртуализации, поскольку гостевая ОС не может отличаться от хостовой или иметь отличную версию гостевого ядра. Например, с Linux различные дистрибутивы нормально, но других операционных системах, таких как Windows не может размещаться. Например, для различных Linux-дистрибутивов это нормальная ситуация, но платформа Windows не может выступать в качестве хоста.
Солярис частично преодолевает вышеописанные ограничения с его особенностью типизированных зон (branded zones, BrandZ), который обеспечивает возможность запуска среды внутри контейнера, который эмулирует Solaris 8 или 9 версии в Solaris 10 в качестве в качестве хоста.
Типизированные зоны Linux (далее типизированные зоны "lx"), также доступны на базе архитектуры x86 Solaris, обеспечивая полноценное пользовательское пространство Linux разработки и поддержки исполнения Linux-приложений; кроме того, Солярис предоставляет утилиты, необходимые для установки RHEL 3.х или CentOS 3.х дистрибутивов Linux внутри "lx" зон. однако, в 2010 году типизированные зоны Linux были удалены из Solaris; в 2014 году они были возвращены в Illumos, который является форком Solaris с открытым исходным кодом, поддерживающий 32-битные ядра Linux.
Некоторые реализации виртуализации на уровне ОС предоставляют механизмы копирования при записи на уровне файлов.
(Чаще всего, стандартная файловая система разделяется между разделами, и те разделы, которые изменяют файлы автоматически создают собственные копии)
Это упрощает резервное копирование, более эффективно и проще в кешировании, чем копирования при записи на уровне блоков в распространенных схемах больших систем виртуализации. Большие системы виртуализации, однако, могут работать с неродными (non-native) файловой системы и обладают возможностью создания и отката снимков целой системы.
Оверхед - это разница между производительностью приложения внутри виртуального окружения и того же приложения работающего без использования виртуализации вообще.
Chroot - операция изменения корневого каталога в Unix-подобных операционных системах. Программа, запущенная с изменённым корневым каталогом, будет иметь доступ только к файлам, содержащимся в данном каталоге. Поэтому, если нужно обеспечить программе доступ к другим каталогам или файловым системам (например, /proc), нужно заранее примонтировать в целевом каталоге необходимые каталоги или устройства.
Программа, корень которой был перенесён в другой каталог, не может обращаться к файлам вне этого каталога. Это обеспечивает удобный способ помещения в «sandbox» («песочницу») тестовой, ненадёжной или любой другой потенциально опасной программы. Это также простой способ использования механизма «jail» («тюрьмы»). Но наиболее часто chroot используется для сборки дистрибутивов или отдельных программ как бы в «чистой» среде.
На практике в chroot сложно поместить программы, ожидающие при запуске найти свободное место на диске, файлы конфигурации, файлы устройств и динамические библиотеки в конкретных местах. Для того чтобы позволить программам запуститься внутри chroot-каталога, необходимо обеспечить их минимальным набором таких файлов, желательно аккуратно выбранным так, чтобы не позволить неумышленный доступ к системе снаружи (например, через файлы устройств или FIFO).
Программам разрешается открывать файловые дескрипторы (для файлов, конвейеров и сетевых соединений) в chroot-е, который может упростить изготовление jail, делая необязательным хранение рабочих файлов внутри каталога chroot. Это также может использоваться как простейшая capability-система, в которой программе явно даётся доступ к ресурсам вне chroot основываясь на дескрипторах, которые содержатся внутри.
Chroot-окружение может быть использовано для создания и размещения отдельных виртуальных копий набора ПО. Это может быть полезно для:
- Тестирования и разработки. Тестовая среда может быть настроена в chroot для программного обеспечения, которое слишком рискованно разворачивать в производственной системе (production).
- Контроль зависимостей. ПО может быть разработано, собрано и испытано в chroot-окружении с ожидаемыми зависимостями.
- Совместимость. Устаревшее ПО или ПО, использующее другое ABI (двоичный интерфейс приложений) иногда запускаются в chroot, потому что набор библиотек или данных может конфликтовать с подобными файлами в хостовой ОС.
- Восстановление. Если система не загружается, то chroot может использоваться для подключения к поврежденному окружению после начальной загрузки из альтернативной корневой файловой системы (например, с установочного диска или LiveCD).
- Разделение привилегий. Программы имеют права на открытие файловых дескрипторов (файлов, конвейеров и сетевых соединений) в chroot. Это упрощает структуру jail, делая её ненужной и позволяет оставлять рабочие файлы внутри chroot-директории. Это также упрощает общий механизм запуска потенциально уязвимых частей привилегированных программ в песочнице, для того, чтобы заранее упредить угрозы безопасности. Но нужно помнить, что chroot не всегда достаточно, чтобы содержать в себе процесс с привилегиями root.
- Изготовление honeypot-ов. Chroot-каталог может быть наполнен таким образом, чтобы симулировать реальную систему с запущенными сетевыми сервисами. Механизм chroot в результате может предотвратить обнаружение атакующими систему с целью компрометации от того, что это является искусственным окружением, или от взлома реальной системы.
FreeBSD Jail — механизм виртуализации в системе FreeBSD, позволяющий создавать внутри одной операционной системы FreeBSD несколько независимо работающих FreeBSD на том же ядре операционной системы, но совершенно независимо настраиваемых с независимым набором установленных приложений.
В основу FreeBSD Jail вошёл системный вызов chroot, при котором для текущего процесса и всех его потомков, корневой каталог переносится в определённое место на файловой системе. При этом это место для процесса становится корневым каталогом. Таким образом, изолированный процесс может иметь доступ только к низлежащему дереву каталогов.
Однако FreeBSD Jail также имеет поддержку на уровне ядра, что позволяет ограничивать доступ к сети, общей памяти, переменным ядра sysctl и ограничивать видимость процессов вне jail.
Процесс, заключённый в Jail, может иметь доступ только к определённым IP-адресам операционной системы и использовать определённый hostname. Такой процесс называется «изолированный процесс» или «Jailed-процесс».
Таким образом, создаётся безопасная «клетка», внутри которой можно исполнять даже потенциально опасное программное обеспечение, которое не сможет никак повредить основной системе или другим таким же «клеткам». До версии 9.0-RELEASE, FreeBSD Jail не имела средств контроля по использованию ресурсов (как это делает, например, OpenVZ под Linux). С версии 9.0-RELEASE, подобные механизмы были введены через утилиту rctl(8) и фреймворк RACCT.
FreeBSD Jails в основном преследуют 3 цели:
- Виртуализация. Каждый jail - это виртуальное окружение, запущенное на хостовой системе, со своими собственными файлами, процессами, аккаунтами пользователя и суперпользователя. Jail-окружение почти ничем не отличается от реальной системы.
- Безопасность. Каждый jail отделен от другого и тем самым обеспечивается дополнительный уровень безопасности.
- Разделение доступа (простота делегирования). Ограниченный объем jail позволяет системным администраторам делегировать ряд задач, которые требуют прав суперпользователя, не давая полного контроля над системой.
В практической деятельности хостинг-провайдеров механизм jail может быть использован для построения администрируемых (managed) систем на выделенных серверах. В таком варианте клиенту предоставляется доступ только к jail, а техническому персоналу компании-провайдера к мастер-системе.
Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами. Изначально использовал возможности LXC, с 2015 года применял собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer. С появлением Open Container Initiative начался переход от монолитной к модульной архитектуре.
Цитата с официального сайта Docker:
Docker-контейнеры - обертка над набором ПО в виде файловой системы, которая содержит всё необходимое: код, среду исполнения (runtime), системные инструменты, системные библиотеки - всё, что вы можете установить на сервер. Это гарантирует то, что всё будет работать также (одинаково), независимо от окружения, в котором они запущены.
Quote of features from Docker web pages:
Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.
Программное обеспечение функционирует в среде Linux с ядром, поддерживающим cgroups и изоляцию пространств имён (namespaces); существуют сборки только для платформы x86-64.
Для экономии дискового пространства проект использует файловую систему Aufs с поддержкой технологии каскадно-объединённого монтирования: контейнеры используют образ базовой операционной системы, а изменения записываются в отдельную область. Также поддерживается размещение контейнеров в файловой системе Btrfs с включённым режимом копирования при записи.
В состав программных средств входит демон — сервер контейнеров (запускается командой docker -d), клиентские средства, позволяющие из интерфейса командной строки управлять образами и контейнерами, а также API, позволяющий в стиле REST управлять контейнерами программно.
Демон обеспечивает полную изоляцию запускаемых на узле контейнеров на уровне файловой системы (у каждого контейнера собственная корневая файловая система), на уровне процессов (процессы имеют доступ только к собственной файловой системе контейнера, а ресурсы разделены средствами libcontainer), на уровне сети (каждый контейнер имеет доступ только к привязанному к нему сетевому пространству имён и соответствующим виртуальным сетевым интерфейсам).
Набор клиентских средств позволяет запускать процессы в новых контейнерах (docker run), останавливать и запускать контейнеры (docker stop и docker start), приостанавливать и возобновлять процессы в контейнерах (docker pause и docker unpause). Серия команд позволяет осуществлять мониторинг запущенных процессов (docker ps по аналогии с ps в Unix-системах, docker top по аналогии с top и другие). Новые образы возможно создавать из специального сценарного файла (docker build, файл сценария носит название dockerfile), возможно записать все изменения, сделанные в контейнере в новый образ (docker commit). Все команды могут работать как с docker-демоном локальной системы, так и с любым сервером Docker, доступным по сети. Кроме того, в интерфейсе командной строки встроены возможности по взаимодействию с публичным репозиторием Docker Hub, в котором размещены предварительно собранные образы контейнеров, например, команда docker search позволяет осуществить поиск образов среди размещённых в нём, образы можно скачивать в локальную систему (docker pull), возможно также отправить локально собранные образы в Docker Hub (docker push).
https://ru.wikipedia.org/wiki/Виртуализация_на_уровне_операционной_системы
https://ru.wikipedia.org/wiki/Двоичный_интерфейс_приложений
https://en.wikipedia.org/wiki/Operating-system-level_virtualization
https://ru.wikipedia.org/wiki/Chroot
https://ru.wikipedia.org/wiki/FreeBSD_Jail
https://en.wikipedia.org/wiki/Docker_(software)
https://en.wikipedia.org/wiki/Linux_namespaces
https://habrahabr.ru/company/FastVPS/blog/208650/
https://en.wikipedia.org/wiki/Systemd
https://ru.wikipedia.org/wiki/Cgroups
https://ru.wikipedia.org/wiki/Aufs
https://ru.wikipedia.org/wiki/Каскадно-объединённое_монтирование
https://ru.wikipedia.org/wiki/Btrfs