Что такое контейнерный формат файла

Обновлено: 06.01.2025

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

В статье, написанной совместно с экспертами из компании Git in Sky , расскажем о том, как контейнерные технологии устраняют эту проблему.

Что такое контейнер и чем эта технология удобна для разработчиков приложений

Контейнер приложения — экземпляр исполняемого программного обеспечения (ПО), который объединяет двоичный код приложения вместе со всеми связанными файлами конфигурации, библиотеками, зависимостями и средой выполнения.

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

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

Контейнеры — небольшие, быстрые и портативные, потому что могут не включать в себя гостевую операционную систему (ОС), а используют функции и ресурсы основной ОС. Контейнеры используют не только для изоляции различных программных процессов, но и для контроля ресурсов, за которые эти процессы могут конкурировать. Это, например, объем памяти или ресурсы процессора.

Уже существующие приложения можно переупаковать в контейнеры, например, посредством технологии Docker, и они будут эффективнее использовать вычислительные ресурсы. Этот процесс называется контейнеризацией. Потребность в ней может возникнуть, когда надо быстро и без повторной сборки приложения переместить его из одной вычислительной среды в другую, где развернуть легко и согласованно.

Еще одно применение технологии — использовать контейнер, содержащий экземпляр другого дистрибутива ОС, что позволяет запускать одновременно несколько контейнеров с приложениями, требующими разных дистрибутивов. Такие контейнеры называют системными и применяют их для традиционных приложений: все конфигурации, инструменты (различное вспомогательное ПО) и монолитная архитектура приложения находятся в одном контейнере.

Например, на сервере с Ubuntu Linux запущены контейнеры с приложениями, которым требуется Alpine Linux, а также другие контейнеры с приложениями, которым необходима определенная версия Debian.

Чтобы лучше понять, чем хороши контейнеры, стоит сравнить их с виртуальными машинами.

В чем разница между контейнерами и виртуальными машинами

Виртуальные машины — абстракция на уровне физического оборудования, превращает один сервер в несколько На каждой виртуальной машине (ВМ) отдельная гостевая операционная система работает поверх операционной системы хоста с виртуализированным доступом к базовому оборудованию.Виртуальные машины с разными ОС могут работать на одном физическом сервере: ВМ UNIX может работать вместе с ВМ Linux и так далее. Микроядро и система виртуализации, которые создают и запускают виртуальные машины, называются гипервизорами или мониторами ВМ. Это то, что находится между оборудованием и ВМ и необходимо для виртуализации сервера, а также для изоляции операционных систем друг от друга.
Контейнеры — абстракция на уровне приложения, объединяет код и зависимости Контейнеры устанавливаются поверх физического сервера и его ОС, например Linux или Windows. Каждый контейнер отделяет свое содержимое от операционной системы. Контейнеры «легкие» — весят всего мегабайты и запускаются за секунды, ведь они берут лишь небольшую часть памяти при совместном использовании ОС.

Виртуальные машины могут запускать любое ядро операционной системы независимо от основной операционной системы, контейнер должен быть совместим с ядром ОС сервера.

Как и ВМ, контейнеры позволяют упаковывать приложение вместе с библиотеками и другими зависимостями, обеспечивая изолированные среды для запуска программных сервисов. Они отделяют приложения друг от друга. Это означает, что не придется беспокоиться о конфликтующих зависимостях или конфликте ресурсов, ведь можно установить лимиты ресурсов для каждого контейнера. Важно отметить, что это дополнительный уровень безопасности, поскольку приложения не работают в операционной системе сервера.

Преимущества контейнеризации приложений

Контейнерная технология дает ряд преимуществ по сравнению с обычной виртуализацией серверов.

Решается проблема зависимостей в разных окружениях. Отлаженное на одном компьютере приложение можно легко развернуть на другом, ведь контейнер содержит все необходимые зависимости. В этом случае говорят о переносимости, гибкости контейнеров.
Появляется возможность использовать микросервисные архитектуры. Контейнеры хорошо подходят для приложений на основе микросервисов: можно проверить работоспособность каждого контейнера, ограничить каждую службу определенными ресурсами, запускать и останавливать их независимо друг от друга.
Можно заметно сократить время разработки приложения. Некоторые технологии, например кеширование слоев сборки, способствуют ускорению циклов разработки и тестирования.
Снижение накладных расходов. Контейнеры совместно используют системное ядро операционной системы сервера, следовательно, запуск контейнера не требует запуска отдельного экземпляра ОС для каждого приложения. Это повышает эффективность сервера и снижает затраты на сервер и лицензирование.
Легковесность и портативность благодаря тому, что каждый контейнер не содержит образ ОС.
Эффективность. Контейнеры позволяют быстрее развертывать приложения, легче масштабировать их горизонтально, проще находить в них ошибки.
Изоляция ошибок. Выход из строя одного контейнера не влияет на дальнейшую работу других контейнеров.

Безопасность контейнеров

При запуске контейнеров надо учитывать, что есть некоторый риск запустить их с неполной изоляцией, тогда какой-то вредоносный код из сети может получить доступ к памяти сервера.

Здесь нужно использовать решения, повышающие безопасность контейнеров:

Добиться изолированности процессов с помощью принципа «каждый контейнер — для решения только одной задачи», его еще формулируют как «одно приложение — один контейнер».
Не загружать готовые к использованию контейнеры из ненадежных источников, а в особых случаях использовать исключительно собственные непубличные репозитории с контейнерами (Container Registry), которые интегрируются в CI/CD-среды .
Использовать внутренние функции сервиса контейнеризации по поиску уязвимостей во всем вспомогательном ПО — такое тестирование тоже легко автоматизируется в CI/CD-средах и позволяет исключить развертывание уязвимых контейнеров в продакшене.

Как управляют контейнерами: системы оркестрации

Оркестрация позволяет автоматизировать развертывание, управление и масштабирование контейнерных приложений. Для этого используют такие инструменты, как Kubernetes — стандарт современной оркестрации контейнеров с открытым исходным кодом. Он совместим с несколькими средами выполнения контейнеров, включая Docker.

Технология возникла потому, что контейнерные приложения могут быть сложными и при их производстве может потребоваться от сотен до тысяч отдельных контейнеров, которыми трудно управлять. С помощью Kubernetes легко оркестрировать множество контейнеров на протяжении всего их жизненного цикла, включая: подготовку, резервирование, мониторинг здоровья, распределение ресурсов, масштабирование, балансировку нагрузки и перемещение между серверами.

Также Kubernetes, как и некоторые другие платформы оркестровки контейнеров, предоставляет дополнительные возможности. Например, автоматическое масштабирование инфраструктуры. Автомасштабирование позволяет добавлять и отключать контейнеры с учетом нагрузки на приложение и сохранять стабильность его работы. Например, в крупном ритейле благодаря автоскейлингу в «черную пятницу» сервисы не лежат, а приложения не вылетают.

Если использовать Kubernetes как сервис от провайдера, то можно снять со специалистов компании нагрузку по его администрированию и обновлению, не думать о резервном копировании. Облачный сервис позволяет ускорить доставку приложений, подключать автомасштабирование в один клик, мониторить доступность запущенных сервисов в одном месте, использовать отказоустойчивые балансировщики нагрузки и многое другое .

Для чего подходит и не подходит контейнеризация

Контейнеризация не подходит : если для работы приложения требуется другая ОС, а не та, что установлена на сервере.

Контейнеризация подходит:

для упрощения процесса развертывания и сопровождения приложений;
для запуска небезопасного или непроверенного кода с целью тестирования или отладки — для этого контейнеры подходят в 99% случаев;
для запуска приложений, требующих другого дистрибутива ОС (системные контейнеры);
для передачи отдельных компонентов приложения между членами команды в ходе цикла «разработка — тестирование — внедрение» и быстрого внесения изменений;
для микросервисов, которые можно разрабатывать и обновлять независимо;
для горизонтально масштабируемых приложений — когда запускается несколько одинаковых контейнеров на текущих ресурсах без увеличения стоимости этих ресурсов. В отличие от вертикального масштабирования, где увеличение количества ядер CPU, объемов RAM, размера HDD на сервере стоит денег;
для модернизации и миграции существующих приложений в более современные среды.

Контейнеризация сегодня — популярный подход к разработке приложений и управлению ими. Исследовательская компания Gartner прогнозировала, что к 2020 году 50% компаний будут использовать контейнерные технологии.

Но уже в 2017 году по результатам опроса IBM выяснилось, что внедрение технологии происходит еще быстрее, и уже 59% компаний улучшили качество приложений и сократили количество ошибок с помощью контейнеризации. По самым свежим прогнозам от Gartner, к 2023 году 70% международных компаний будут использовать более двух контейнерны х приложений .

Контейнер - это формат файла, определяющей распределение аудио, видео, а в некоторых случаях и текстовой информации внутри него. Типом контейнера в большинстве случаев не выбирается тип кодирования (сжатия) информации внутри файла. А сам тип контейнера легко определяется по расширению файла.

AVI (Audio Video Interleaved), чередующееся аудио/видео - старый (1992 год!) и до сих пор весьма популярный тип контейнера. Его появлению мы благодарны фирме Microsoft и пакету Video for Windows. В настоящее время начинает сдавать позиции более современным контейнерам из-за отсутствия нормальной поддержки нескольких аудиодорожек, субтитров и современных кодеков (вроде h.264), тем не менее, ещё долго будет пользоваться популярностью из-за широчайшей поддержки производителями бытовой техники. Обычно используется в сочетании с кодеками семейства MPEG4/DivX/Xvid и сжатым в mp3 звуком.
MKV (Matroska, "Матрёшка") - современный контейнер, разработан как open source проект и лишён всех недостатков AVI - поддерживаются современные видео и аудиокодеки, несколько аудиодорожек и внедрение нескольких дорожек с субтитрами. Обычно, но вовсе не обязательно применяется в сочетании с современными кодеками h.264/x.264/AVC-1. Субъективно является наиболее популярным для дистрибуции в Интернете и локального хранения видео высокого качества.
Но никто не мешает, например, поместить внутрь MKV видео, сжатое"старым добрым" Xvid. Более того, в некоторых ситуациях такие действия оправданы.
QuickTime (расширения файлов - *.mov или *.qt) - достаточно прогрессивный контейнер, созданный фирмой Apple, поддерживает практически все популярные кодеки и внедрение субтитров, более, того, в отличие от MKV куда более пригоден для редактирования видеоматериала, записанном в таком контейнере.
Однако его нормальная поддержка возможна только при установленном на компьютере пакете Apple QuickTime, сторонние open source реверс-инжиниринговые разработки полной функциональности не обеспечивают.
ASF/WMV/WMA (Advanced Stream Format/Windows Media Video) - замена AVI от Microsoft, расширения файлов, соответственно: ASF, WMV, WMA (для звуковых файлов). Несмотря на все прогрессивные нововведения (поддержка нескольких дорожек, глав, новых кодеков), поддержка h.264 им по-прежнему затруднительна, что ставит под большой вопрос будущее этого контейнера.
FLV - Adobe Flash Video. Получил бешеную популярность из-за Youtube. В процессе эволюции научился использовать современные видео и аудиокодеки, однако ориентация его на короткие и сильно сжатые интернет-ролики ограничивает сферу его распространения. Встраиваемые субтитры почему-то не поддерживает.
BDMV - фактически, несжатый образ Blu-Ray диска, обладает всеми мыслимыми "вкусностями" (поддержка всех современных аудио и видеоформатов, вплоть до 3D), но предъявляет серьёзные требования к дисковому пространству и к нагрузке на декодер. Поэтому поддержка его аппаратными плеерами пока весьма ограничена.
3GP - контейнер, ориентированный на съёмку видео мобильными телефонами. Отсюда ограниченная поддержка аудиоформатов, видеоформаты поддерживаются весьма прогрессивные. Никаких альтернативных аудиодорожек, вместо субтиров - таймкод. Оружие мобильного репортёра, проще говоря.
MP4 - достаточно прогрессивный контейнер, поддерживает сжатие видео не только в MPEG4, как можно подумать из названия, но и более современными методами. Но уступил "матрёшке" в части поддержки субтитров и аудиоформатов.
Divx - контейнер от создателей одноимённого кодека. Несмотря на некую прогрессивность, такого же распространения не получил. Причина - может использовать только одноимённый кодек для видео, ну и кому после этого он нужен, если "матрёшка" универсальнее.
VOB - на самом деле официальное название этого контейнера MPEG 2 Program Stream - т.е. фактически это содержимое DVD. Поддерживает только два видеокодека, MPEG1 и MPEG2, в остальном - эталон эпохи "до HDTV", потому что есть поддержка субтитров, глав (если брать диск целиком как единый контейнер) и различных звуковых форматов, включая весьма прогрессивные.
.ts MPEG 2 Transport stream, также встречается в виде файлов с расширением m2ts и mts - популярен благодаря спутниковому цифровому вещанию, способен использовать, несмотря на название, современные кодеки и FullHD разрешения. Популярен среди любителей спутникового телевидения, но по гибкости использования уступает "Матрёшке".
OGG - контейнер, формально предназначенный для хранения звука в формате OGG Vorbis, но может хранить и видео. Несмотря на заявленные возможности, представляет собой экзотику (это касается видео), для звука этот контейнер уже, можно считать, прижился.
WAV - контейнер, предназначенный для хранения звука, вовсе не обязательно несжатого.
ISO - просто образ оптического диска. Внутри может быть всё что угодно. Как это переварит плеер - уже задача его разработчиков.
MPG - наследие VideoCD, контейнер для видео в формате только MPEG 1. Звук - mp3 или его более ранние варианты. Известен тем, что воспроизводится практически везде и всем.

MPEG1 - с него, собственно и началось массовое распространение видео на ПК. Создавался для VideoCD, но может встретиться на DVD или в mpg-файле. Легко декодируется даже техникой времён Pentium 120.
MPEG2 - собственно, мы его видим не только на DVD. Им может быть сжато видео в различных подвидах цифрового телевидения, в .ts файле и даже на Blu-Ray, где он является одним из трёх обязательных кодеков. Наверное, сейчас это самый популярный видеокодек в мире, раз пережил FullHD революцию.
MPEG4 - Несмотря на техническое совершенство, в "чистом" виде практически не получил распространение из-за ряда ограничений на использования. Последствия читаем ниже
DivX - культовая первая версия 3.11 этого кодека представляла собой фактически взломанный Microsoft MPEG4 и позволяла создавать "DVD-rip" в контейнере AVI, умещавшийся на одну или две болванки, позволяя экономить на дорогой DVD-болванке или лицензионной копии DVD-фильма. Сейчас поддерживается всеми актуальными программными и аппаратными видеоплеерами. В дальнейшем, несмотря на выход новых версий, развитие кодека затормозилось и он сдал позицию своему конкуренту, читаем дальше:
XviD - open source версия DivX, быстро обогнавшая своего "предка" в развитии, не имевшая лицензионных проблем, а также быстро "взятая на вооружение" и производителями оборудования и поставщиками контента.
Наиболее современный и популярный видекодек "поколения MPEG4" в наше время. В качестве контейнера для него чаще всего используется AVI, но иногда и MKV.
WMV7/WMV8 - дальнейшее развитие MPEG4 от Microsoft, широкого распространения не получили. Дальнейшие усилия были брошены на разработку WMV9
h.264 - революция в мире кодирования видео, де факто созданная по заказу ВС США ещё первого десятилетия XXI века. Также иногда именуется "MPEG-4 Part 10" или просто "AVC". Из-за фантастического преимущества в качестве изображения относительно размера файла над кодеками семейства MPEG4, h.264 быстро распространился везде, где смог. Например, он стал основным обязательным кодеком видео для Blu-Ray, а также начал вытеснять другие кодеки из контейнеров вроде FLV или 3GP. В распространяемом в интернете высококачественном видеоконтенте очень часто встречается сочетание MKV/h.264, из-за чего эти аббревиатуры некоторые пользователи ошибочно считают синонимами.
Однако добавим в эту бочку мёда и приличную ложку дёгтя - аппаратному требования к декодированию сжатому в h.264 видео очень высоки, даже если речь не идёт о FullHD разрешении. Поэтому для многих старых аппаратных медиаплееров апгрейд путём перепрошивки для поддержки нового кодека оказался невозможен по причине банальной нехватки вычислительной мощности декодера. При этом поддержку новых контейнеров вроде mkv добавить было легко, что приводило к понятным казусам. Более того, воспроизведение h.264-контента на компьютере также требует либо двухъядерного процессора, либо аппаратной поддержки декодирования AVC со стороны видеокарты (к счастью, это сейчас встречается практически поголовно). А вот с планшетами и нетбуками не всё-так очевидно.
x.264 open source реверс-инжиниринговая переработка h.264. Вопрос их сравнения выходит за рамки этого FAQ. Используется в основном для дистрибуции высококачественного контента в интернете.
WMV9 - первый кодек нового поколения (рассчитанного на FullHD) от Microsoft, имея сравнимые с описанным ниже h.264 характеристики, не получил столь широкого распространения по причинам нетехнического плана.
VC-1 - ответ Micrsoft на h.264, создан на основе WMV9. Также является обязательным кодеком для Blu-Ray плееров. Отличается меньшей универсальностью.

MP3 (вернее, MPEG 1 Audio Level 3) - без комментариев, поддерживается везде и всем, недостаток этого "вечного" формата один - всего два канала, что ограничивает его применение в современных домашних кинотеатрах.
MPEG 2 Audio Level 3 многоканальный (5.1) mp3.
WMA - Windows Media Audio, формально более качественный и современный конкурент mp3 от Microsoft. Мало распространён, хотя широко поддерживается аппаратурой.
OGG Vorbis - более качественный современный конкурент mp3 от сообщества open source. Лишён каких-либо лицензионных ограничений, используется всё чаще.
AAC - Advanced Audio Coding - основной аудиоформат Apple, внедрённый во все их iPad, iPhone, iTunes и т.п. Основное достоинство - технически более совершенен, чем mp3, допускает частоты дискретизации до 96кГц и теоретически совершенно безумное число каналов в одном файле - до 48. Также применяется в цифровом спутниковом радио. Как и mp3 это формат со сжатием, качество 96Кбит/c AAC сравнимо с качеством 128Кбит/c mp3 (речь идёт о двух каналах в обоих случаях).
Dolby Digital (AC-3) - вероятно, наиболее популярный стандарт для цифрового аудио в кинематографе, из-за того, что появился на рынке аж в 1995 году, существует в двух вариантах - DD2.0 (для качественного стереозвука) и DD5.1 - пять полноценных каналов и один ущербный для сабвуфера. Плеерами поддерживается поголовно по понятным причинам, битрейтом 640 Кбит/c во всех случаях.
Dolby Digital Plus или E-AC-3 - попытка улучшить обычный Dolby Digital, но декодеры и ресиверы предыдущего поколения обратно не совместимы с дорожками в формате Dolby Digital Plus, причины этого в радикальных изменениях : количество каналов возросло до 7.1, битрейт - до 1,7Мбит сек. Через S/PDIF такое не пролезет (при передаче по такому кабелю придётся применять даунмикс в DD5.1 или в DTS с потерей качества), а нормально с Dolby Digital Plus справляется HDMI начиная с версии 1.3, встретить такие дорожки можно на Blu-Ray дисках.
Dolby TrueHD - Практически имеем 8 почти несжатых дорожек в 96КГц/24бит или 6 в 192КГц/24бит, суммарный битрейт доходит до 18 Мбит/cек, что требует декодирования в плеере и передаче на ресивер в аналоговом тракте, либо использования HDMI 1.3 И выше. Для Blu-Ray эта система кодирования звука опциональна.
DTS - цифровая система кодирования звука с потерями для кинотеатров, позже появившаяся и на DVD, является аналогом Dolby Digital 5.1, но несколько гибче, позволяя в дополнение к 2.0 и 5.1 использовать и другие схемы, вроде 4.0 и 4.1, также есть выбор между двумя фиксированных битрейта 1500Кбит/с и 750 кбит/с. В первом случае DTS однозначно превосходит Dolby Digital по качеству звука, во втором - разница между системами является предметом споров.
DTS-HD - дальнейшая эволюция DTS, количество каналов доведено до 7.1 в режиме 96КГц/24бит, битрейт выбирается между 6Мбит/c и 3Мбит/с, является опциональным звуковым форматом для Blu-Ray. Ситуация с передачей звука на ресивер примерно та же, что и с DolbyTrueHD.

Прежде чем переходить к созданию видео-файлов, предлагаю немного разобраться в разнообразии этих файлов и их атрибутов.

Начнем с размеров или разрешений видео. На картинке выше наглядно показаны основные типоразмеры видео-файлов, когда вы видите параметр 1920х1080 - это означает размер картинки по ширине и высоте в пикселях, в данном случае можно сокращенно сказать FullHD или 1080p (буква "p" обозначает progressive или прогрессивную, построчную развертку, альтернатива 1080i, буква "i" обозначает interlace или другими словами через строчную развертку, картинка прорисовывается через строчку). Любые разрешения выше 1000 пикселей, в принципе, называют HD или High-Definition (высокое разрешение). В современном мире никого не удивить уже и разрешением в 2K, поэтому я свои проекты стараюсь делать в разрешении 1080p (1920x1080, прогрессивная развертка) и 29,97 кадров в секунду (frame rate). Это наиболее распространенный и универсальный размер видео для современных проекторов, телевизоров, экранов компьютеров и ноутбуков.

Переходим к видео форматам или медиаконтейнерам, как их еще называют. Контейнер файла используется для идентификации и чередования различных типов данных. Современные контейнеры упаковывают в видео файл не только сам видеоряд, но и звуковые дорожки, meta данные, субтитры, информацию о разделах и еще много чего. Основных контейнеров не так много - avi (формат предложенный корпорацией Microsoft), mov (стандартный контейнер от Apple), mpg (формат записи файлов от MPEG group). Я делаю проекты в MOV, наиболее универсальный формат, с ним меньше всего проблем на компьютерах заказчиков. Но если видео-файл будет встраиваться в WEB, то наиболее подходящим будет MPG формат (расширение файла *.mp4 в основном).

Последнее и самое, пожалуй, не простое - это кодеки. Видеокодек — это алгоритм сжатия видеоданных и восстановления сжатых данных. По сути кодек - это формула, которая определяет, каким образом можно «упаковать» видеоконтент и, соответственно, воспроизвести видео, распаковав его. Сейчас мы поговорим только про видеокодеки, но есть и аудиокодеки, а так же кодеки для субтитров. Опишу основные видеокодеки:

MPEG4 - Несмотря на техническое совершенство, в "чистом" виде практически не получил распространение из-за ряда ограничений на использование.
DivX - культовая первая версия 3.11 этого кодека представляла собой фактически взломанный Microsoft MPEG4 и позволяла создавать "DVD-rip" в контейнере AVI, умещавшийся на одну или две болванки, позволяя экономить на дорогой DVD-болванке или лицензионной копии DVD-фильма. Сейчас поддерживается всеми актуальными программными и аппаратными видеоплеерами.
XviD - open source версия DivX, быстро обогнавшая своего "предка" DivX в развитии, не имевшая лицензионных проблем, а также быстро "взятая на вооружение" и производителями оборудования и поставщиками контента.
Наиболее современный и популярный видекодек "поколения MPEG4" в наше время. В качестве контейнера для него чаще всего используется AVI, но иногда и MKV (матрешка).
h.264 - революция в мире кодирования видео, де факто созданная по заказу ВС США ещё в начале первого десятилетия XXI века. Из-за фантастического преимущества в качестве изображения относительно размера файла над кодеками семейства MPEG4, h.264 получил очень быстрое распространение и сейчас является наиболее распространенным и поддерживаемым кодеком для видео.

Наиболее универсальным и качественным, на мой взгляд, является следующий набор для подготовки видео-файла - разрешение 1920х1080p, контейнер mov (QuickTime), кодек h.264 (quality не ниже 75), частота кадров 29,97 fps. Стоит отметить, что разные программы по разному работают с контейнерами и кодеками, например, программа для VJ под названием Resolume, не видит *.mp4 файлы, стандартом для этой программы является кодек DXV и файлы mov .

Обращаю ваше внимание, что кодек h.264 довольно требователен к аппаратным средствам, считается, что лучше не запускать большие видео-файлы 1080p на компьютерах с одноядерными процессорами.

Этой информации вам должно хватить для общего понимания из чего состоит видео-файл, какие настройки использовать для его кодирования.

Будь вы студент или уже состоявшийся разработчик, вы наверняка слышали о «контейнерах». Более того, вероятно вы слышали, что контейнеры — это «лёгкие» виртуальные машины. Но что на самом деле это значит, как именно работают контейнеры и почему они важны?

Эта статья посвящена контейнерам, их применению и великолепной идеи, которая за этим стоит. Для этой статьи никакой предварительной подготовки не требуется, кроме базового понимания компьютерных технологий.

Ядро и ОС

В основе любого компьютера лежит «железо»: процессор, накопитель (hdd, ssd), память, сетевая карта и т.д.

В ОС есть часть программного кода, которая служит мостом между софтом и железом, он называется — kernel (ядро). Ядро координирует запуск процессов (программ), управляет устройствами (чтение и запись адресов на диск и в память) и многое другое.

Остальная часть ОС служит для загрузки и управления пользовательским пространством, где запускаются и постоянно взаимодействуют с ядром процессы пользователя.

Виртуальная машина

Допустим, что ваш компьютер работает под MacOS, а вы хотите запустить приложение написанное для Ubuntu. Наиболее вероятным решением в этом случае будет загрузка виртуальной машины на MacOS, для запуска Ubuntu и вашей программы.

Виртуальная машина подразумевает виртуализацию ядра и железа, для запуска гостевой ОС. Hypervisor — это ПО для виртуализации железа, в том числе: виртуального накопителя, сетевого интерфейса, ЦП и другого. Виртуальная машина также имеет своё ядро, которое общается с этим виртуальным железом.

H ypervisor может быть реализован как ПО, так и в виде реального железа , установленного непосредственно в Host машину. В любом случае hypervisor ресурсоёмкое решение, требующее виртуализации нескольких, если не всех, “железных” устройств и ядра.

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

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

cgroups

Cgroups — это аббревиатура от Linux “control groups”. Это функция ядра Linux, которая изолирует и контролирует использование ресурсов для пользовательских процессов. Её создали инженеры из Google в 2006 году.

Эти процессы могут быть помещены в пространства имён, то есть группы процессов, у которых общие ограниченные ресурсы. В компьютере может быть несколько пространств имён, у каждого из которых есть свойства ресурса, закреплённые ядром.

Для каждого пространства имён можно распределять ресурсы, так, чтобы ограничить использование CPU, RAM и т.д., для каждого набора процессов. Например, для фонового приложения агрегации логов, вероятно, потребуется ограничить ресурсы, чтобы не перегружать сам сервер, для которого ведётся лог.

Cgroups была в конечном итоге переработана в Linux, для добавления функции namespace isolation (изоляция пространства имён). Идея изоляции пространства имён не нова. В Linux уже было много видов namespace isolation. Например, изоляция процессов, которая разделяет каждый процесс и предотвращает совместное использование памяти.

Cgroup обеспечивает более высокий уровень изоляции. Благодаря cgroup, процессы из одного пространства имён независимы от процессов из других пространств. Ниже описаны важные функции изоляции пространств имён. Это и есть основа изоляции в контейнерах.

PID (Process Identifier) Namespaces: эта функция гарантирует изоляцию процессов из разных пространств имён.
Network Namespaces: изоляция контроллера сетевого интерфейса, iptables, таблиц маршрутизации и других сетевых инструментов более низкого уровня.
Mount Namespaces: монтирует файловую систему таким образом, чтобы область файловой системы была изолирована и имела доступ только к смонтированными директориями.
User Namespaces: изолирует пользователя в пространстве имён, чтобы избежать конфликта user ID между пространствами.

Проще говоря, каждое пространство имён для внутренних процессов, выглядит так как будто это отдельная машина.

Linux контейнеры

Linux cgroups стала основой для технологии linux containers (LXC). На самом деле LXC была первой реализацией того, что сегодня называют контейнеры. Для создания виртуальной среды, с разделением процессов и сетевого пространства, взяли за основу преимущества cgroups и изоляцию пространств имён.

Сама идея контейнеров вышла из LXC. Можно сказать, что благодаря LXC стало возможным создавать независимые и изолированные пространства пользователей. Более того, ранние версии Docker ставились поверх LXC.

Docker

Docker — это наиболее распространённая технология контейнеров, именно Docker имеют в виду, когда говорят о контейнерах вообще. Тем не менее, существуют и другие open source технологии контейнеров, например rkt от CoreOS. Крупные компании создают собственные движки, например lmctfy от Google. Docker стал стандартом в этой области. Он до сих пор строится на основе cgroups и пространстве имён, которые обеспечивает ядро Linux, а теперь и Windows.

В Docker контейнер состоит из слоёв образов, при этом бинарные файлы упакованы в один пакет. В базовом образе содержится операционная система, она может отличаться от ОС хоста.

ОС контейнера существует в виде образа. Она не является полноценной ОС, как система хоста. В образе есть только файловая система и бинарные файлы, а в полноценной ОС, помимо этого, есть ещё и ядро.

Поверх базового образа лежит ещё несколько образов, каждый из них является частью контейнера. Например, следующим после базового, может быть образ, который содержит apt-get зависимости. Следующим может быть образ с бинарными файлами приложения и т.д.

Самое интересное, это объединённая файловая система Docker. Например, у вас есть два контейнера со слоями образов a, b, c и a, b, d , тогда вам нужно хранить только по одной копии каждого слоя т.е. a, b, c, d , локально и в репозитории.

Каждый образ идентифицируется хэшем, и является одним из множества возможных слоёв образов, из которых состоит контейнер. Но идентификатором самого контейнера является только верхний образ, который содержит ссылки на родительские образы. На картинке выше видно, что два образа верхнего уровня ( Image 1 и Image 2 ), разделяют три общих нижних слоя. В Image 2 есть два дополнительных слоя конфигурации, но родительские образы те же, что и у Image 1 .

При загрузке контейнера происходит следующее: образ и его родительские образы подгружаются из репозитория, создаётся cgroup и пространство имён, далее образ используется для создания виртуального окружения. Файлы из контейнера, в том числе и бинарные, в образе представлены как будто это единственные файлы на всей машине. После этого, запускается основной процесс контейнера. Теперь можно считать контейнер работающим.

В Docker есть ещё очень классные фичи, например копирование во время записи, тома (общие файловые системы между контейнерами), docker daemon (управление контейнерами), репозитории с контролем версий (например Github для контейнеров), и много чего ещё.

Почему именно контейнеры

Помимо изоляции процессов, у контейнеров есть много преимуществ.

Контейнер — это самоизолированная единица, которая запустится на любой поддерживаемой платформе, и каждый раз это будет всё тот же контейнер. Независимо от операционной системы хоста, вы сможете запустить ту систему, которая находится в контейнере. Поэтому можете быть уверены, что контейнер, который вы создаёте на своём ноутбуке, будет работать так же на корпоративном сервере.

Кроме того, контейнер используют как способ унификации рабочего процесса. Существует даже парадигма — один контейнер — одна задача. Контейнер для запуска одного веб-сервера, одного сегмента базы данных и т. д. Чтобы масштабировать приложение, достаточно масштабировать количество контейнеров.

Эта парадигма подразумевает, что у каждого контейнера своя фиксированная конфигурация ресурсов (CPU, RAM, количество потоков и т.д.), поэтому достаточно масштабировать количество контейнеров, а не индивидуальные ресурсы. Это обеспечивает более простую абстракцию для масштабирования приложений.

Кроме того, контейнеры — это отличный инструмент для реализации архитектуры микросервисов. В таком случае, каждый микросервис это комплекс взаимодействующих контейнеров. Например, микросервис Redis, можно реализовать с одним мастер контейнером и несколькими slave контейнерами.

В такой (микро)сервис-ориентированной архитектуре, есть очень важные особенности, которые позволяют команде инженеров с лёгкостью создать и развернуть приложение.

Администрирование

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

Для этого инструмента требуется:

Назначить контейнеры машинам согласно спецификации (планирование)
Загрузить нужные контейнеры в машины через Docker
Решить вопросы с обновлениями, откатами и возможными изменениями системы
Быть готовым к «падениям» контейнеров
Создать кластерные ресурсы (мониторинг служб, взаимодействие между виртуальными машинами, вход/выход кластера)

Эти задачи относятся к администрированию распределённой системы, построенной на основе контейнеров (временно или постоянно изменяющихся). Для решения этих задач, уже созданы действительно классные системы.

Читайте также: