Если ты, дружок-пирожок, уже читал о таких вещах, как сервисы, удаленный доступ и тестовые среды, то ты наверняка что-то слышал и о контейнеризации. Возможно ты даже слышал, что контейнеры — это более легкий аналог виртуальных машин. Но что на самом деле это значит, как именно работают контейнеры и зачем они нужны?
Эта статья посвящена теоретическим основам контейнеризации, основам внутреннего устройства контейнеров и обзору самых популярных инструментов контейнеризации. Для этой статьи никакой предварительной подготовки не требуется, тебе понадобится только знание букв и таких терминов, как «ядро»,»процесс» и «демон».
Старая добрая виртуальная машина
В любом компьютере есть кусок операционной системы, который служит для связи между его логической и физической частями. Этот кусок называется ядром. Оно координирует запуск пользовательских и системных процессов, управляет доступом к оперативной памяти и жестким дискам и многое другое.
Допустим, ты писал код приложения на компьютере с ОС Windows, а теперь хочешь запустить свою великолепнейшую приложуху на CentOs,чтобы показать ее своему другу-красноглазику, который категорически отказывается пользоваться продукцией мелкомягких.
Раньше для решения этого конфликта ставилась виртуальная машина с полноценной внутренней ОС, которая подразумевает виртуализацию ядра и железа для запуска своей ОС. Творится вся эта магия с помощью «гипервизора», служащего для создания виртуальных аналогов физических частей машины-носителя.
Гипервизор может быть реализован как ПО (гипервизор первого типа), так и в виде реального подключаемого к хосту модуля (гипервизор второго типа). Когда требуется развернуть несколько приложений на одном устройстве, запускать виртуальную машину для каждой группы — слишком расточительный подход. Все потому что гипервизор служит для связи между двумя полноценными операционными системами: хостовой и гостевой. У каждой гостевой среды имеются собственное ядро, виртуальная копия всего оборудования хоста и заранее определенный набор ресурсов, не обязательно использующийся в данный момент,но жестко закрепленный за ней.
Короче, чтобы запустить свою моднейшую приложуху на виртуалке, тебе придется выделить на своем компе место под полноценный CentOS. И еще немного сверху.
Моднейшая контейнеризация
Проблему избыточности ресурсов гипервизовых систем решает принцип контейнерной виртуализации. Технология контейнеров использует метод виртуализации на уровне ядра ОС. Эта страшная фраза значит, что одного ядра хостовой ОС за глаза хватит для создания независимых параллельно работающих операционных сред. При увеличении числа развернутых на одном хосте виртуальных пространств выгода от отсутствия дублирования ядер ОС и виртуальных копий физического оборудования становится очень заметной. Ноутбук может спокойно тянуть работу с десятком виртуальных контейнеров,но вряд ли потянет 2-3 виртуальных машины на приемлемой скорости. Если тебе этого всего мало — посмотри на две прекраснейшие картинки ниже.
Такой скачок производительности стал возможен благодаря волшебному механизму «cgroups»,созданному великими мудрецами в темную эру 2006 года.Cgroups — это функция ядра Linux, которая изолирует и контролирует использование ресурсов для пользовательских процессов.Эти процессы могут быть помещены в разные пространства имён, то есть в группы процессов, у которых общие ресурсы.
Для каждого пространства имён можно распределять ресурсы, тем самым ограничивая использование ресурсов для каждого набора процессов. Благодаря cgroups, процессы из одного пространства имён независимы от процессов из других пространств.
Волшебная Cgroups позже стала основой для технологии linux containers (LXC). Для создания виртуальной среды, с разделением процессов и сетевого пространства, LKC взяли за основу cgroups и изоляцию пространств имён. На самом деле, именно LXC была первой реализацией того, что сегодня называют контейнеры.
Великий и ужасный Docker
Docker — это самая распространённая технология контейнеризации сегодня. именно Docker имеют в виду, когда говорят о контейнерах вообще. В его основе лежат технологии namespaces, control groups и Union File System. Первая служит для создания контейнеров, вторая отвечает за распределение ресурсов между ними, а третья — за их модульность.
Сам докер состоит из трех (это больше двух, но меньше четырех) основных компонентов: докер-демона,манипулирующего контейнерами и изображениями; докер-клиента, предоставляющего набор высокоуровневых команд для работы с докер-демоном; реестра,в котором хранятся изображения. Эти три части общаются между собой с помощью REST APi по схеме, которую я честно стырил с официального сайта Docker-а.
Базовой частью Docker-контейнера является образ,являющийся по умолчанию read-only шаблоном. Докер контейнер состоит из группы образов, накладывающихся друг на друга.В базовом образе каждого контейнера содержится операционная система. Она не является полноценной ОС, как система хоста, в ней есть только файловая система и бинарные файлы, а вот ядра нет.
Из-за того, что все образы Docker-контейнера read-only, единственный экземпляр каждого из них может одновременно использовать любой количество контейнеров,нужно только знать идентификатор.Каждый образ идентифицируется хэшем, и является одним из множества возможных слоёв образов в контейнере. «Ничего не понял» — скажешь ты. «Посмотри на меня» — скажет тебе рисунок ниже.
Основной функциональной единицей Docker-a является контейнер с работающим приложением. Именно в контейнер ты можешь запихнуть тестовую базу данных в которой напишешь, что начальник — лох или новейшую версию приложения, в котором весь интерфейс заменишь на картинки единорогов. И сделать ты это можешь где угодно и когда угодно, контейнер будет везде работать одинаково,лишь бы докер был.А еще Docker-контейнеры умеют освобождать память. Кстати, контейнер не сохраняет изменения своего состояния при остановке (на самом деле это можно сделать,но об этом в другой раз).
Собственно, при загрузке контейнера происходит следующее: образ и его родительские образы подгружаются из репозитория, создаётся cgroup и пространство имён, далее образ используется для создания виртуального окружения. Файлы из контейнера, в том числе и бинарные, в образе представлены как будто это единственные файлы на всей машине. После этого, запускается основной процесс контейнера. И после всего вот этого можно считать контейнер работающим.
Альтернативы Docker-y, чтобы не обвинили в рекламе
- Libpod — для тех,кто плотно работает с Kubernetis, любит RedHat и полный open-soure.
- LXD Linux Containers — надстройка над LXC. Служит скорее для создания виртуальных машин, но LXD-виртуальные машины работают в 10 раз быстрее аналогов.
- Containerd — проект,отпочковавшийся от докера. Среда для управления контейнерами, плотно работающая с gRPC форматом и предоставляющая богатый функционал управления жизненным циклом контейнера.
Итоги
- Контейнеризация твой бро,если тебе позарез нужно развернуть какой-то изолированный функционал: базу данных или тестовое окружение.
- Контейнер легко сконфигурировать, трудно потерять и невозможно не запустить.
- Контейнеры и микросервисы любят друг друга. Очень сильно. Иногда слишком сильно
- Не только лишь докером едины. Альтернативы есть, на вкус и цвет разные.
Подписывайтесь на наш канал!
Источник: IT Проповедник