1. Введение
3. CGROUPS и NAMESPACES и причем здесь контейнеры
4. DOCKER и OCI
7. Заключение
Введение
Тема виртуализации системы очень большая и в одной статье всё не осветить. Весь материал мы разделили на цикл статей и данная статья будет первой из этого цикла:
- Основы современной контейнеризации
- Автоматизация работы с контейнерами
- Безопасность контейнеров
Исторический экскурс
Идея изоляции пользовательского пространства на уровне операционной системы сформировалась еще в 80х годах. Началось всё с системного вызова chroot, появившегося в ядре UNIX v7 в 1979 году наряду с другими новыми системными вызовами. Он позволял программе, запущенной с измененным корневым каталогом, иметь доступ только к файлам данной категории. С самого начала, данный системный вызов создавался для реализации функции безопасности, связанной с защитой файловой системы и процессов от повреждения или компроментации.
Как развитие этой технологии в 2000 году в операционной системе FreeBSD 4.0 появился механизм изолирования окружения, позволяющий создавать несколько копий FreeBSD, называемых jails, независимо работающих на одном ядре и разделенных между собой при помощи системного вызова jail и раздельного пользовательского окружения. Всё это было сделано, чтобы ограничить права пользователя внутри виртуального окружения.
В 1982 году Билл Джой, будущий сооснователь компании Sun Microsystems добавил системный вызов chroot в BSD. Как результат – в 2005 году компания Sun Microsystems реализовала технологию виртуализации на уровне операционной системы и назвала её Solaris Zones.
В 2005 году в ядре Linux появилась технология OpenVZ, которая позволяла запускать на одном физическом сервере большое количество виртуальных частных серверов (VPS). Это уже был шаг в сторону аппаратной виртуализации, где применялись другие техники, такие как технология паравиртуализации. Но это уже «другая история».
Для того, чтобы до конца прояснить различия между виртуализацией на уровне операционной системы от аппаратной виртуализации, стоит сказать, что аппаратная виртуализация, эмулируя аппаратное окружение, может запускать отдельные гостевые системы, а виртуализация на уровне операционной системы позволяет запускать экземпляр операционной системы только с тем же ядром, что и на основной операционной системе (Рис. 46).
Рис. 46
Однако, в связи с отсутствуем полноценной операционной системы и собственного ядра, необходимых для запуска полноценной операционной системы, отсутствуют и накладные расходы на контейнер. Так что это – два разных способа «виртуализоваться» – со своими достоинствами и недостатками. Достаточно истории – перейдем к технологиям, которые непосредственно связаны с современной контейнеризацией.
CGROUPS и NAMESPACES и причем здесь контейнеры
В 2006 году Пол Менэдж и Рохит Сет начали разработку собственных механизмов изоляции ядра и ограничения на некоторые вычислительные ресурсы. Изначально разработка называлась «контейнеры процессов», которая позволяла образовывать группы процессов с заданными ресурсными лимитами. Начиная с версии ядра Linux 2.6.24, она под новым названием cgroups была включена в официальную версию. В этом же году появляется новая функция ядра Linux, называемая Linux Containers или LXC, в основе которой лежит функция ядра namespaces, позволяющая изолировать и виртуализировать глобальные системные ресурсы групп процессов. Собственно, namespaces – это ни что иное, как эволюция chroot, которая позволила осуществить задуманное, а именно обеспечить полную изоляцию среды.
Всё бы и оставалось на прежнем уровне развития, если бы в 2013 году не появилось программное обеспечение, способное автоматизировать процесс развертывания и управления приложениями в виртуальных средах путем объединения приложения с его окружением и зависимостями, а также ограничениями cgroups в один контейнер. Назвали его Docker.
DOCKER и OCI
Проект Docker стал логичным продолжением истории развития изолированных сред и включил в себя большинство наработок в данном направлении. Docker оторвался от всех других разработок за счет автоматизации управления контейнерами и собрал вокруг себя большое сообщество, так как с его помощью время развертывания виртуальных узлов сокращалось в десятки раз. Но очень скоро стало понятно, что Docker не идеален и слишком мало стандартов в новой области виртуализации уровня операционной системы. Docker на момент релиза в 2013 году использовал наработки прошлых лет, представляя пользователю удобный интерфейс взаимодействия с данным уровнем абстракции. Со временем сообщество, зародившееся вокруг технологий контейнеризации объявило о создании проекта Open Container Initiative (OCI), целью которого стала разработка единого стандарта в области контейнерных технологий. В 2015 году из-под его крыла вырвался инструмент для запуска контейнеров runC (данный runtime-движок начал так же поддерживаться Docker'ом с версии 1.11 в 2017 году). (Рис. 47) Достаточно теории, давайте перейдем к практике.
Рис. 47
Первый запуск
Для начала, определяемся какое ядро нам необходимо для запуска контейнеров, т.к. от этого будет зависеть платформа для разворачивания среды Docker. На выбор у нас есть: Windows, Linux и Mac. Тут стоит оговориться, что контейнеры, разработанные для среды Windows на Linux не заработают (например Windows IIS сервер под Ubuntu), ввиду изначальной разности этих операционных систем, так как мы имеем дело с виртуализацией уровня операционной системы. Здесь мы рассмотрим случай, когда ядром для запуска контейнеров будет ядро Linux.
Первое, с чем нам придется столкнуться – это установка дистрибутива и создание учетной записи на сайте docker.com. Для установки последней версии Docker'а в ОС Ubuntu набираем следующие команды:
# проверяем наличие обновлений
$ sudo apt-get update
# устанавливаем Docker CE (Community Edition)
$ sudo apt-get install docker-ce docker-ce-cli containerd.io
Для проверки работоспособности вводим следующую команду:
$ sudo docker run hello-world
Docker подтянет тестовый образ контейнера hello-world и запустит его! (Рис. 48)
Рис. 48
Далее – изучим инструмент под названием Docker Hub. Это такой App Store в мире контейнеров. Для доступа к хабу нам необходимо создать учетную запись на сайте https://hub.docker.com/, где мы сможем размещать свои образы и делиться ими со всем миром, а также загружать кем-то уже созданные контейнеры, не тратя время на их сборку. Тут стоит рассказать об одной особенности работы с «чужими» контейнерами. Контейнер может собрать и опубликовать в Docker Hub любой желающий, не всем издателям стоит доверять, так как в контейнерах могут содержаться как устаревшие, так и уязвимые версии пакетов и приложений. Docker проверяет наиболее популярные образы и маркирует их тегом Docker Certified (Рис. 49).
Рис. 49
Есть ещё одна разновидность «проверенных» контейнеров – официальные образы. Эти образы представляют собой образцово-показательные контейнеры, собранные по всем правилам и лучшим практикам Docker-платформы (Рис. 50, стр. 33).
Рис. 50
Начало работы
Мы поставили Docker и создали учетную запись, разобрались как подходить к выбору контейнеров. Теперь настало время попробовать запустить что-нибудь полезное и поэкспериментировать с его работой. Для начала выберем объект наших испытаний – им будем CentOS, которую мы запустим в окружении Ubuntu. Для того, чтобы запустить какую-либо команду на CentOS в виртуальном окружении нам потребуется всего одна команда:
$ sudo docker run –t centos:latest /usr/bin/ top
Если Docker не найдет у нас уже локально выгруженный контейнер – он выгрузит его из Docker Hub'а и сразу же запустит контейнер, выполнив в нем команду top.
Как мы видим (Рис. 51) – запущенный нами процесс – единственный и ничего кроме него контейнер не видит. Мы запустили свой полностью рабочий контейнер.
Рис. 51
Заключение
Технологии контейнеризации очень сильно отличаются от технологии виртуализации. У этой технологии очень много плюсов и многообещающее будущее. Этот факт подтверждают своими действиями крупные производители программного обеспечения виртуализации уровня ОС, добавляющие возможность управления корпоративными контейнерами в свои продукты. В следующих статьях мы рассмотрим варианты создания собственных контейнеров, возможности оркестрации и автоматизации управления, а также вопросы безопасности – куда же без них. Как говорится, stay tuned!
Оригинал материала размещен на сайте SecurityLab.
