Фраза дня: Контейнеризация приложений

Что такое контейнеризация приложений?
Контейнеризация приложений - это метод виртуализации на уровне ОС, используемый для развертывания и запуска распределенных приложений без запуска всей виртуальной машины (ВМ) для каждого приложения. Несколько изолированных приложений или служб работают на одном хосте и обращаются к одному и тому же ядру ОС. Контейнеры работают на голых железных системах, облачных экземплярах и виртуальных машинах в Linux и некоторых ОС Windows и Mac.

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

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

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

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

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

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

Блокировка ОС также может представлять проблему, но разработчики уже пишут приложения для работы в определенных операционных системах. Если предприятию необходимо запустить контейнерное приложение Windows на серверах Linux или наоборот, уровень совместимости или вложенные виртуальные машины решат проблему. Однако это увеличило бы сложность и потребление ресурсов.

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

Наиболее распространенной технологией контейнеризации приложений является Docker, в частности Docker Engine с открытым исходным кодом и контейнеры, основанные на универсальной среде выполнения runC. Docker Swarm - это инструмент для кластеризации и планирования. Используя Docker Swarm, ИТ-администраторы и разработчики могут создавать кластер узлов Docker и управлять им как единой виртуальной системой.

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

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

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

Чтобы обновить приложение, разработчик вносит изменения в код в образе контейнера. Затем разработчик повторно развертывает этот образ для работы в ОС хоста.

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

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

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

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

Canonical Ltd., разработчик операционной системы Ubuntu Linux, возглавляет проект системных контейнеров LXD. Другой вариант системного контейнера - OpenVZ.

Типы технологий контейнеризации приложений
Помимо Docker, существуют и другие технологии контейнеризации приложений, в том числе:

• Apache Mesos: менеджер кластера с открытым исходным кодом. Он обрабатывает рабочие нагрузки в распределенной среде за счет динамического совместного использования ресурсов и изоляции. Mesos подходит для развертывания и управления приложениями в крупномасштабных кластерных средах.
• Google Kubernetes Engine: управляемая, готовая к работе среда для развертывания контейнерных приложений. Он обеспечивает быструю разработку и итерацию приложений, упрощая развертывание, обновление и управление приложениями и службами.
• Amazon Elastic Container Registry (ECR): продукт Amazon Web Services, который хранит, управляет и развертывает образы Docker, которые являются управляемыми кластерами инстансов Amazon EC2. Amazon ECR размещает образы в высокодоступной и масштабируемой архитектуре, что позволяет разработчикам надежно развертывать контейнеры для своих приложений.
• Служба Azure Kubernetes (AKS): управляемая служба оркестрации контейнеров на основе системы Kubernetes с открытым исходным кодом. AKS доступен в общедоступном облаке Microsoft Azure. Разработчики могут использовать AKS для развертывания, масштабирования и управления контейнерами Docker и контейнерными приложениями в кластере контейнерных узлов.

Выбор платформы для контейнеризации
При выборе платформы для контейнеризации разработчики должны учитывать следующее:

• Архитектура приложения. Сосредоточьтесь на решениях, связанных с архитектурой приложений, которые им необходимо принять, например, являются ли приложения монолитными или микросервисами и являются ли они без отслеживания состояния или с отслеживанием состояния.
• Рабочий процесс и сотрудничество. Обдумайте изменения в рабочих процессах и определите, позволит ли платформа им легко сотрудничать с другими заинтересованными сторонами.
• DevOps. Учитывайте требования к использованию интерфейса самообслуживания для развертывания своих приложений с помощью конвейера DevOps.
• Упаковка. Рассмотрите формат и инструменты для использования кода приложения, зависимостей, контейнеров и их зависимостей.
• Мониторинг и ведение журнала. Убедитесь, что доступные параметры мониторинга и ведения журнала соответствуют их требованиям и хорошо работают с их рабочими процессами разработки.

ИТ-операции должны учитывать:

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

История
Технология контейнеров была впервые представлена ​​в 1979 году в Unix версии 7 и системе chroot. Chroot положил начало изоляции процессов в контейнерном стиле, ограничив доступ к файлам приложения определенным каталогом - корневым - и его дочерними элементами. Ключевым преимуществом разделения chroot была повышенная безопасность системы. Изолированная среда не могла поставить под угрозу внешние системы, если была использована внутренняя уязвимость.

FreeBSD представила команду jail в своей операционной системе в марте 2000 года. Команда jail была очень похожа на команду chroot. Однако он включал дополнительные функции «песочницы» для изоляции файловых систем, сетей и пользователей. FreeBSD jail предоставляет возможность назначать IP-адрес, настраивать установку пользовательского программного обеспечения, а также вносить изменения в каждую тюрьму. Однако возможности приложений внутри тюрьмы были ограничены.

Контейнеры Solaris, выпущенные в 2004 году, создавали полноценные среды приложений через зоны Solaris. Зоны позволили разработчику предоставить приложению полное пространство для пользователя, процесса и файловой системы, а также доступ к системному оборудованию. Но приложение могло видеть только то, что было в его собственной зоне.

В 2006 году Google запустил контейнеры процессов, предназначенные для изоляции и ограничения использования ресурсов процессом. Контейнеры процессов были переименованы в контрольные группы (cgroups) в 2007 году, чтобы не путать со словом контейнер.

Затем в 2008 году cgroups были объединены в ядро ​​Linux 2.6.24. Это привело к созданию проекта, который сейчас известен как проект LXC (контейнеры Linux). LXC обеспечила виртуализацию на уровне ОС, позволив нескольким изолированным контейнерам Linux работать в общем ядре Linux. Каждый из этих контейнеров имел собственный процесс и сетевое пространство.

Google снова изменил контейнеры в 2013 году, когда он открыл свой стек контейнеров в виде проекта под названием Let Me Contain That For You (LMCTFY). Используя LMCTFY, разработчики могли писать приложения с поддержкой контейнеров. Это означало, что их можно было запрограммировать на создание собственных субконтейнеров и управление ими. В 2015 году Google прекратил работу над LMCTFY, решив вместо этого внести основные концепции, лежащие в основе LMCTFY, в libcontainer проекта Docker.

Docker был выпущен как проект с открытым исходным кодом в 2013 году. С помощью Docker контейнеры можно было упаковать, чтобы их можно было перемещать из одной среды в другую. Изначально Docker полагался на технологию LXC. Однако в 2014 году LXC был заменен на libcontainer. Это позволило контейнерам работать с пространствами имен Linux, группами управления libcontainer, возможностями, профилями безопасности AppArmor, сетевыми интерфейсами и правилами брандмауэра.

В 2017 году такие компании, как Pivotal, Rancher, AWS и даже Docker, переключились на поддержку планировщика контейнеров Kubernetes с открытым исходным кодом и инструмента оркестровки.