Работа с контейнерами: Сложности и мифы

В нашем блоге мы пишем о развитии облачного сервиса 1cloud ^[1], но и о перспективных технологиях. Одной из наиболее активно обсуждаемых тем уходящего года стала «революция контейнеров» — многие компании внедряют их в свою инфраструктуру, а вендоры создают новые технологии для работы с ними. Недавно мы рассказывали о новых разработках VMware в этой области, а теперь представляем вашему вниманию адаптированный перевод заметки ^[2] инженера компании о сложностях и мифах, связанных с контейнерами.

^[3]

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

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

В ноябре 2015 года в Барселоне прошла конференция Dockercon Europe 2015 ^[4], посвященная безопасности, пользовательскому интерфейсу, RBAC-авторизации и эксплуатации программного обеспечения в целом. Стоит только упомянуть эти термины, как все внимание крупных организаций тут же обратится на вас.

На конференции искали способы заполнения пропасти между разработчиками (которые любят Docker) и IT-специалистами (у которых есть и другие проблемы, которые нужно решать). Объединить задачи этих групп спеиалистов и пытается VMware, компания тратит много усилий на популяризацию технологии контейнеров. Работа ведется по нескольким фронтам: создаются инструменты и внедряются технологии, способные облегчить этот переход.

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

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

Везде есть свои тонкости

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

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

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

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

Нужно переписать приложения

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

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

Контейнеры однозначно помогают ускорить развертывание

Благодаря абстракции извлечь пользу из контейнерной технологии возможно, но дело в том, что при развертке приложений 95% времени занимает работа персонала – человеческий фактор. Если вы и ваши сотрудники не применяете DevOps-методологию, то контейнеры не дадут большого выигрыша во времени.

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

Все используют контейнеры, нужно срочно идти тем же путем

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

Некоторые организации используют от 100 до 1000 различных инструментов (как готовых, так и сделанных самостоятельно). К сожалению очень немногие (если таковые имеются) из них можно будет использовать в контейнерной среде. Именно по этой причине сегодня возникает огромное количество проектов с открытым исходным кодом, которые стараются закрыть эти дыры, одну за другой, добавляя огромное количество операционных слоев для развертки контейнеров.

Многим организациям приходится вновь создавать собственные инструменты. Клиенты, которые решили использовать среду тестирования (dev/test), могут приобрести некоторый опыт от работы с контейнерами, однако им придется добавлять дополнительный операционный уровень, дабы мигрировать приложение обратно на виртуальные машины для развертки. Конечно, вы можете запустить контейнеры в production, но для этого вам потребуется совершенно новая операционная парадигма и набор инструментов, который только-только начинает появляться.

Однако это не должно останавливать компании от экспериментов с контейнерами — как и при работе с любой новой технологией, не стоит сразу бросаться в омут с головой. Однако с течением времени появляется все больше технологий и инструментов, помогающих осуществить плавный переход — например, инструмент vSphere Integrated Containers ^[5] запускается на Photon Kernel ^[6] (пико-версия PhotonOS) 25 МБ и работает с контейнерами как с виртуальными машинами. Такой подход позволяет максимально эффективно использовать средства, идущие на поддержание безопасности, управление, эксплуатацию и контроль соответствия определённым нормам. Разработчик получает скорость и простоту контейнерной технологии, но с управляемостью и надёжностью виртуальной машины.

Другие материалы о контейнерах и виртуализации в блоге 1cloud

• Виртуализация контейнеров: В чем суть новых технологий VMware ^[7]
• Как Google и Docker запускают «революцию контейнеров» ^[8]
• Разные типы дисков на одной виртуальной машине: опыт 1cloud ^[9]
• История виртуализации: Бурное развитие на стыке тысячелетий ^[10]
• Виртуализация: история и тренды развития ^[11]

Автор: 1cloud.ru

Источник ^[12]