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

Обновлено: 07.07.2024

Цитируя разработчиков Docker, «контейнер — это стандартная единица программного обеспечения, в которую упаковано приложение со всеми необходимыми для его работы зависимостями — кодом приложения, средой запуска, системными инструментами, библиотеками и настройками».

Контейнеры используются уже более десяти лет и на сегодняшний день примерно четверть компаний-лидеров в сфере IT задействуют контейнерные решения в продакшене, а ещё столько же, согласно опросам, планировали приступить к этому в 2019-м году.

На рынке существует немало решений, представляющих среды запуска контейнеров и оркестрации, таких как CoreOS rkt, LXC, OpenVZ, containerd, Apache Mesos и Docker Swarm. Однако более 4/5 контейнеров запускается в среде Docker, а для оркестрации более половины пользователей выбрали Kubernetes. Об этих системах мы и поговорим.

Чем полезны контейнеры

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

Техническим же специалистам контейнеры прежде всего полюбились за возможность упаковать приложение вместе с его средой запуска, решая тем самым проблему зависимостей в разных окружениях. Например, различие версий языковых библиотек на ноутбуке разработчика и в последующих окружениях рано или поздно приведёт к сбоям, и нужно будет как минимум потратить время на их анализ, а как максимум — решать проблему проникших в продакшен багов. Использование контейнеров устраняет проблему «А на моей машине все работало! ¯\_(ツ)_/¯».

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

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

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

Контейнеры требуют значительно меньше ресурсов для своей работы, что положительно сказывается на производительности и бюджете.
Контейнеры можно запускать только в той же операционной системе, что стоит на host-системе — то есть запустить Windows-контейнер на host-системе с Linux не получится (на персональных устройствах это ограничение обходится с помощью технологии виртуализации). Однако это не относится к разным дистрибутивам одной и той же ОС, например Ubuntu и Alpine Linux.
Контейнеры предоставляют меньшую степень изоляции, поскольку используют ядро host-системы, что потенциально создаёт бóльшие риски в эксплуатации при небрежном отношении к безопасности.

Основные принципы контейнеризации приложений

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

1 контейнер — 1 сервис

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

Неизменность образа

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

Утилизируемость контейнеров

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

Отчётность

Контейнер должен иметь точки проверки состояния его готовности (readiness probe) и жизнеспособности (liveness probe), предоставлять логи для отслеживания состояния запущенного в нём приложения.

Управляемость

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

Самодостаточность

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

Лимитирование ресурсов

К лучшим практикам эксплуатации контейнеров относится настройка ресурсных лимитов (CPU и RAM): следование этой практике позволяет сохранять внимательное отношение к экономии ресурсов и вовремя реагировать на их избыточное потребление.

Docker

Когда мы говорим о контейнерах в современных IT-системах, прежде всего мы подразумеваем Docker — open-source-технологию, благодаря своей популярности ставшую в IT синонимом слова «контейнер».

Основные сущности Docker

Dockerfile

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

Image

Готовая файловая система, сформированная по инструкциям из Dockerfile и служащая прообразом для запускаемых контейнеров.

Instance

Запущенный экземпляр образа, минимальная единица деплоя в Docker.

Volume

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

Registry

Репозиторий, используемый для хранения Docker-образов. Registry может быть как публичным, так и приватным, защищённым механизмом аутентификации.

Процесс разработки в среде Docker

Типичный процесс разработки в среде Docker выглядит следующим образом: разработчики устанавливают на свои машины Docker, загружают собранный заранее образ с установленной средой сборки и выполнения приложения, а затем запускают контейнер командой, которая также пробросит в него директорию с исходниками. Для установки Docker не требуется особого железа — он может быть установлен на вполне заурядной машине. Однако у него имеются ограничения по версиям ОС — Windows 7 64bit или выше для ПК с поддержкой Hyper-V, macOS Sierra 10.12 для устройств от Apple и версией ядра 3.10 для систем с Linux. Контейнеры Docker являются родной технологией для ОС Linux и запускаются на других с помощью виртуальных машин под её управлением.

Инструкции по установке Docker на разных платформах: Windows, Mac, Linux Ubuntu.

Чтобы запустить ваш первый контейнер на Docker, после его установки введите в командной строке docker run hello-world — эта команда загрузит образ hello-world с Docker hub’а (публично доступный Docker registry), создаст контейнер, используя этот образ, и выдаст приветственную фразу:

Hello from Docker!
This message shows that your installation appears to be working correctly.
.

Оркестрирование контейнеров: Kubernetes

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

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

Основные сущности, которыми оперирует Kubernetes

Node (master и slave)

Узлы, из которых состоит кластер Kubernetes. Master-нода осуществляет контроль над кластером через планировщик и менеджер контроллеров, обеспечивает интерфейс взаимодействия с пользователями посредством API-сервера и содержит хранилище etcd, где находится конфигурация кластера, статусы его объектов и метаданные. Slave-нода предназначена исключительно для запуска контейнеров, для этого на ней установлены два сервиса Kubernetes — сетевой маршрутизатор и агент планировщика.

Namespace

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

Минимальная единица развёртывания в Kubernetes, группа из одного или более контейнеров, собранных для совместного деплоя на ноде. Группировать контейнеры разного вида в Pod имеет смысл, когда они зависят друг от друга и потому должны быть запущены на одной ноде, чтобы сократить время отклика при их взаимодействии. Пример — контейнеры с веб-приложением и кэширующим его сервисом.

ReplicaSet

Объект, описывающий и контролирующий соответствие запущенного на кластере количества реплик Pod’ов. Установка количества реплик больше одной требуется для повышения отказоустойчивости и масштабирования приложения. Общепринято создавать ReplicaSet с помощью Deployment.

Deployment

Объект, декларативно описывающий Pod’ы, количество реплик и стратегию их замены при обновлении параметров.

StatefulSet

Действует по тому же принципу, что и ReplicaSet, однако дополнительно позволяет описывать и сохранять при перезапуске уникальный сетевой адрес Pod’ов или их дисковое хранилище.

DaemonSet

Объект, обеспечивающий контроль за тем, что на каждой ноде (или нескольких выбранных) будет запущено по экземпляру указанного Pod’а.

Job и CronJob

Объекты, запускающие соответственно однократно и регулярно по расписанию указанный Pod и отслеживающие результат завершения его работы.

Label и Selector

Метки, позволяющие маркировать ресурсы и тем самым упрощать групповые манипуляции, связанные с ними.

Service

Инструмент для публикации приложения в качестве сетевого сервиса, в том числе реализующий балансировку нагрузки между Pod’ами приложения.

Если сравнить объекты Docker и Kubernetes, то станет понятна разница в задачах, решаемых этими инструментами: можно сказать, что Docker управляет контейнерами, в то время как Kubernetes управляет самим Docker.

Управление конфигурацией (Configuration/Complexity Management)

Развитие IT-систем ведёт ко всё большему их усложнению, и это порождает проблемы управления — даже на небольшом количестве серверов или контейнеров ручное управление приложением превращает практически любое изменение конфигурации в трудовой подвиг, а на десятках или сотнях делает его абсолютно невозможным. К счастью, новые проблемы ведут и к новым решениям — в этом разделе мы расскажем о некоторых инструментах управления конфигурацией (configuration management) или, как ещё принято говорить, управления сложностью (complexity management). Они используются для установки, управления и обновления приложений Kubernetes: например, с их помощью можно описать приложение, состоящее из фронтенда, бэкенда и всех необходимых для их работы сервисов, таких как объекты Kubernetes, контейнеры с веб-серверами, базами данных, серверами очередей и т. д.

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

Kustomize

Благодаря популярности у пользователей и своей простоте, начиная с версии Kubernetes 1.14, Kustomize является встроенным инструментом управления конфигурацией. Для описания приложений использует чистый язык разметки YAML без возможности шаблонизации и использования параметров, что является одновременно его сильной и слабой сторонами, упрощая процесс настройки и вместе с тем сильно его ограничивая.

Ansible

Управляйте хранилищами данных в автоматизированном режиме с помощью модулей интеграции Ansible NetApp.

Jsonnet

Также как и Ansible, Jsonnet не является чем-то специфичным для Kubernetes, однако многие знакомы с ним именно благодаря K8s. Jsonnet описывает объекты с помощью расширенного JSON, включающего комментарии, текстовые блоки, параметры, переменные, условные включения и функции. Очень мощный и гибкий инструмент.

Пакетный менеджер приложений Kubernetes. Этот инструмент описывает приложения в виде декларативных диаграмм (charts), создающихся с помощью языка разметки YAML и шаблонов Golang. Helm обладает широкой базой готовых диаграмм, даёт возможность версионировать конфигурации и переключаться между версиями релизов, т. е. откатывать конфигурацию. Из всех приведенных здесь инструментов является наиболее функциональным в отношении управления приложениями Kubernetes и одновременно обладает наиболее сложным способом описания конфигурации из-за шаблонов Golang, весьма требователен к пользовательским навыкам.

Платформы для хостинга контейнеров

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

Своё железо (bare metal)

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

Облачные решения (SaaS)

Крупные облачные провайдеры предоставляют своим клиентам сервисы для запуска контейнеров — готовые среды, обёрнутые удобным интерфейсом управления. Построенные по такому принципу решения называются Software as a Service (SaaS). Они не требуют никаких капитальных затрат, поскольку вся инфраструктура арендуется, а конфигурация создаётся в минимальном объёме, относящемуся исключительно к запускаемому приложению. Сами же кластеры настраиваются провайдером по указанному пользователем небольшому объему параметров. SaaS-решения — оптимальный вариант для стартап-компаний, небольших и развивающихся проектов. Самым большим минусом этого решения можно назвать повышенную в сравнении с bare metal стоимость при условии многолетнего использования.

Тремя наиболее популярными облачными платформами на сегодня являются Amazon Web Services, Microsoft Azure и Google Cloud. Все три провайдера имеют доступный в виде сервиса Kubernetes, и все три из них предлагают пробный период пользования сервисами, выдавая депозит на сумму 200–300 $. Чтобы оценить удобство и качество облачных решений и сравнить друг с другом их поставщиков, вам даже не придется тратить свои деньги.

Хотите обеспечить максимальную сохранность данных, создаваемых и используемых в контейнерах? NetApp Trident позволит легко интегрировать в вашу контейнерную инфраструктуру надежное и функциональное хранилище данных enterprise-уровня.

Заключение

Ещё недавно не смолкали дебаты на тему оправданности использования контейнеров в продакшене, то и дело были слышны обвинения в их ненадежности. Однако время не стоит на месте, индустрия оценила их перспективность, сделала свой выбор, и инвестиции в контейнерные решения потекли широкой рекой, с каждым днем делая решения на их базе всё удобнее и привлекательнее. На сегодняшний день примитивную настройку кластера и деплой приложений в него можно выполнить используя один лишь веб-интерфейс, предварительно прочитав несколько страниц документации — настолько это стало просто. А их низкая по сравнению с виртуальными машинами стоимость откусывает у ВМ всё большую долю рынка, забирая то, что не требует для своей работы специфики устройства ВМ. Безусловно, контейнеры зарекомендовали себя как жизне- и конкурентоспособное решение, сокращающее время вывода продукта на рынок, стоимость его разработки и эксплуатации.

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

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

Ядро и ОС

В основе любого компьютера лежит «железо»: процессор, накопитель (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
Решить вопросы с обновлениями, откатами и возможными изменениями системы
Быть готовым к «падениям» контейнеров
Создать кластерные ресурсы (мониторинг служб, взаимодействие между виртуальными машинами, вход/выход кластера)

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

Данная статья предназначена для отсылания сюда тех, кто пытается что-то "конвертить", не понимая, что они делают и зачем.

Чтобы максимально эффективно работать с любым объектом нужно понимать как он устроен. Если видеофайл для вас - таинственная чёрная коробка, внутри которой творятся загадочные штуки, возможно не без помощи чёрной магии, - эффективность ваша будет минимальна.

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

Всякий видеофайл обязательно должен представлять из себя контейнер. Контейнер - это хранилище для содержимого. Бывают хранилища различной структуры - это форматы контейнеров. Вот например коробка для бенто - это пример контейнера. В неё можно положить суши, а можно темпуру. Что можно положить в видеоконтейнер? Ну как минимум - изображение и звук, по одной штуке. Это такой набор, без которого уже и смотреть нечего. Что можно положить по максимуму? Современный контейнер матрёшка позволяет засунуть в себя несколько видео и аудиодорожек, графические и текстовые субтитры, шрифты для их отображения, картинки и сам не знаю, что ещё.

Возвращаясь к примеру коробки с бенто, отметим, что мисо в неё наливать нельзя - вытечет на фиг. Не всякий контейнер может принять в себя любой поток. Есть ограничения на совместимость, усложняющие жизнь.

Примеры контейнеров: mpeg, avi, mkv, mp4, ogm, vob, mov, rm, divx, asf. Не надо долго присматриваться к списку, чтобы понять, что это стандартные расширения файлов. Разумеется. Потому что файл = контейнер.

В понятие кодека обычно включают следующие аспекты:
1) Собственно формат хранения данных.
2) Программное обеспечение, позволяющее закодировать информацию в данный формат и/или раскодировать её из него.

Примеры видео кодеков: divx, xvid, avc, x264, vp6, vp7, mpeg-1, mpeg-2, huffyuv.
Примеры аудио кодеков: mp3, ogg, ac3, aac.

В то время как контейнеры, как правило, различают по расширениям файлов, кодеки различают по четырёхсимвольному FourCC коду.

Понятие кодека как правило связано с неким ужатием. Сырые (raw, uncompressed) потоки тоже имеют свои форматы, но им декодирование не нужно и потому понятие кодека к ним обычно не применяется.

А теперь рассмотрим наиболее популярные контейнеры, кодеки и связанные с ними проблемы. Проблемы у нас бывают как правило двух типов: связанные с проигрыванием и связанные с редактированием.

MPEG - один из самых древних контейнеров. В нём может храниться исключительно видео в фомате mpeg-1 и аудио в формате mp2. Причём по-хорошему - с довольно строгими ограничениями по размеру изображения и битрейту звука. В силу древности и примитивности формата его понимают практически все плееры и редакторы. Но по тем же самым причинам его почти невозможно стало встретить. Никому такое барахло не нужно.

AVI - тоже довольно древний, но пока ещё весьма полезный контейнер. Хорош он тем, что его понимают опять же все плееры и все редакторы. Влезают в него почти все mpeg-based форматы, а также многие совместимые с ними. В avi не влезают следующие видеоформаты: avc (также известный как Nero AVC или Nero H.264), wmv ниже 9 версии, а также всякая мишура типа real video, которая изначально спроектирована несовместимой ни с чем на свете. Из звуков - якобы всё что угодно, кроме Vorbis ogg.

OGM - это как раз то место, куда лезет Vorbis ogg. Ибо формат был создан на основе этого самого ogg. На данный момент практически вытеснен матрёшкой ибо она умеет всё то же самое, только лучше. И точно также не поддерживается никакими мейнстримовыми программами. Лучший известный софт для обработки - VirtualDubMod.

MKV - матрёшка, в которую влезает практически что угодно, кроме flash video. Но в силу её сложности и универсальности с нею до сих пор можно сделать только такие вещи как: собрать, посмотреть и разобрать.

MP4 - это фактически современный MPEG. Принимает в себя исключительно вещи, совместимые со стандартом MPEG, но зато включая его новейшие разновидности. В первую очередь это видео в H.264 и аудио в aac.

VOB - специальный контейнер для DVD. Хранит в себе видео исключительно в формате mpeg-2. Зато звук может быть в самых разных форматах. Но самым распространённым вариантом является Dolby Digital (ac3).

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

В теории формат-контейнер способен хранить любой тип данных, однако на практике для каждого типа данных существуют отдельные группы контейнеров. Эти группы «настроены» для специфических требований и информации, которая будет сохраняться в них. Медиаконтейнеры являются типичным примером такой группы файловых контейнеров, которые предназначены для сохранения медиаинформации, которая условно делится на изображения, видео и аудио. В случае фильмов медиаконтейнер должен не только сохранять видео- и аудиопоток, но и при воспроизведении обеспечивать их синхронизацию. Также в медиаконтейнере может сохраняться несколько однотипных потоков, например фильм (видео-поток) с несколькими звуковыми дорожками (аудиопотоками) и субтитрами (текстовыми потоками).

Содержание

Список медиаконтейнеров

Некоторые медиаконтейнеры предназначены для сохранения только аудиоданных:

Некоторые медиаконтейнеры предназначены для сохранения только статических изображений:

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

Есть также много других медиаконтейнеров, например NUT, MPEG-1, MXF, GXF, ratDVD, SVI, VOB и DivX Media Format.

Single coding formats

В дополнение к «чистым» контейнерным форматам, которые определяют только «обёртку», а не алгоритм кодирования, есть некоторые файловые форматы, которые определяют и слой хранения, и слой кодирования, как часть модульного дизайна и для совместимости «снизу вверх». К таким медиаконтейнерам относятся JPEG File Interchange Format (JFIF) для JPEG-изображений и Portable Network Graphics (PNG). Такие полнофункциональные медиаконтейнеры (хотя понятие «медиаконтейнер» к ним не совсем применимо) называются «Single coding format» (рус. Единый формат кодирования ).

Различия

Все различия между разными медиаконтейнерами происходят из пяти основ:

Популярность. Насколько распространён и поддерживается данный контейнер.
Размер файла. Показывает различие в файловом размере между двумя файлами, которые имеют одинаковый контент, но сохранены различными медиаконтейнерами.
Поддержка расширенной функциональности кодека. Старые медиаконтейнеры, такие как AVI, не поддерживают новые особенности кодеков, такие как B-кадры, переменный битрейт аудиопотока и переменную частоту кадров видеопотока. Контейнер может быть «взломан» для добавления поддержки, но это создаёт проблемы совместимости.
Поддержка расширенного контента. Поддерживает ли медиаконтейнер разделы, субтитры, мета-теги и пользовательские данные.
Поддержка потокового мультимедиа.

Remux

Remux (ремультиплексирование) — принятый в сфере видеокодирования термин, означающий перекомпоновку содержимого медиаконтейнера. Его важной особенностью является отсутствие перекодировки (сохранение исходного качества) основных элементарных потоков (видео- и аудиопотока). Заменяется лишь медиаконтейнер, также могут добавляться или удаляться субтитры, меню, множественные аудиопотоки (дополнительные звуковые дорожки) и прочие второстепенные данные.

Примечания

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