П. Eмeльянoв: Oснoвнoй кoнтингeнт нaшиx зaкaзчикoв – этo xoстинг-прoвaйдeры. Сeйчaс ситуaция нeскoлькo мeняeтся, нo истoричeски слoжилoсь тaк, чтo бoльшaя чaсть этиx заказчиков не является представителями так называемого Enterprise – то есть, в основном, они обладают достаточно скромными бюджетами и пытаются экономить там, где это возможно. Ориентируясь на таких заказчиков, мы не могли выставлять большую цену на свои продукты. В то же время, набор возможностей, востребованный такими покупателями, достаточно широк и разнообразен по той причине, что каждому из них нужна разная функциональность. Каждый хостинг-провайдер в противостоянии с десятками своих конкурентов желает предоставлять какие-то особые возможности своим клиентам, и создание всего этого разнообразия было нашей задачей.
Получаемый в итоге достаточно огромный список функций при неизменно невысокой цене обусловил выпуск подавляющей части продуктов на Linux и Open Source. Опираясь изначально на некое базовое ядро продукта, далее заказчики высказывают свои предпочтения – ту или иную файловую систему, принципы и настройки резервного копирования и так далее.
Заказчики – особенно крупные хостинг-провайдеры, со своей стороны также не рассматривают Virtuozzo как законченный «продукт из коробки» и зачастую применяют его вместе с собственным наработками как один из компонентов.
Виджет от SocialMart
Подход с использованием ядра базовой платформы и дальнейшей его кастомизацией надстройками под нужды каждого отдельного заказчика устраивает всех, в ином случае охватить все запросы было бы просто нереально.
THG.ru: Кто из крупных хостинг-провайдеров использует продукты Virtuozzo?
П. Емельянов: Наши продукты использует, например, крупнейший американский хостинг-провайдер GoDaddy. Среди известных компаний, использующих OpenVZ, можно упомянуть OpenWorx, студии Pixar Animation, Wargaming.net и Yandex.
THG.ru: Можно ли назвать контейнерную виртуализацию технологией для специфических нишевых разработок или всё же это нечто большее?
П. Емельянов: В последние пару лет значительным образом поменялось само определение «контейнера». Когда компания Virtuozzo только начинала свою работу, о контейнерах как таковых ещё не говорили, вместо этого использовали термин «виртуальные среды», симметричный «виртуальным машинам». Позже, когда технология вышла за рамки нашей компании и мы начали интегрировать её в основную ветку Linux-ядра, возник термин «контейнеры», поскольку «виртуальными средами» почему-то никому называть её не нравилось.
Затем появился проект Docker, который на базе этой технологии построил довольно мощный инструментарий по подготовке приложений для размещения контейнеров. Таким образом, «контейнерами» начали называть всю технологию – и виртуализацию, и способ запаковать и запустить приложение внутри этой виртуализации.
Со временем базовый слой этой виртуализации стал привычным и на общем фоне вполне привычным, поскольку развитие проекта Docker оказалось достаточно масштабным, так что сейчас под «контейнерами» подразумевают только способ запаковки и запуска приложений, совершенно неважно в какой виртуальной среде – он все равно остается контейнером.
Есть, например, проекты, запускающие приложения внутри гипервизора – по сути, в виртуальной машине. С точки зрения виртуализации – это VM, но по сути это контейнер, в котором запаковано приложение.
В этом плане контейнерная виртуализация – это технология низкоуровневой изоляции приложения или дистрибутива. Да, действительно, сейчас она уходит в ниши. Какое-то время назад это была отдельная технология, успешно конкурировавшая с виртуальными машинами. Десяток лет назад разница между запуском VM и контейнеров при одинаковом времени отклика на схожем «железе» составляла 2-3 раза. Со временем разница очень сильно сократилась – частично благодаря усилиям компании Intel, которая обеспечила аппаратную поддержку, частично благодаря разработчикам гипервизорных технологий, и сейчас, если измерить время отклика, задержки или скорость работы, VM работают медленнее контейнеров лишь на десятки процентов – 10-20%, в редких случаях 30%, во всём остальном они практически уже сравнялись.
В то же время, с точки зрения удобства использования, виртуальные машины обеспечивают больше, чем контейнеры, поскольку для контейнерной виртуализации, по сути, нужно взять всё ядро и «обучить» каждую подсистему разделению прав доступа между приложениями. Запуская приложение внутри контейнера, пользователь зачастую сталкивается с невозможностью реализации каких-то функций, или с нежелательностью их использования для сохранения целостности системы. В виртуальных машинах с точки зрения безопасности ядра таких проблем нет: если одна виртуальная машина сломается, остальные останутся нетронутыми, и ядро при этом никак не пострадает.
THG.ru: Каким образом можно повредить ядро изнутри контейнера?
П. Емельянов: При наличии уязвимости в ядре и если упакованный в контейнере софт умудряется до неё дотянуться – да, действительно, он может сломать весь хост, все контейнеры, есть такая проблема безопасности. Одним из достоинств Virtuozzo как раз является то, что мы внимательно следим за такими вопросами безопасности, и для любых ядер Linux, которые пользователи ставят с продуктами Virtuozzo, все такие проблемы известны и заведомо закрыты.
Фундаментальная проблема заключается в том, что при запуске софта в VM соблюдается максимальная изоляция, и так называемая «площадь атаки» (Attack surface) очень мала и, по сути, захватывает только гипервизор, в то время как при запуске софта в контейнере площадь атаки большая и составляет весь ядерный потенциал, который ему разрешено использовать. Это можно лечить, затыкать дыры, но фундаментальная проблема от этого никуда не уйдёт.
Именно поэтому постепенно отмирает практика использования системных контейнеров – мы называем их также «контейнеры общего назначения», внутри которых запускаются дистрибутивы: проще, гибче и безопаснее сделать это в VM, тем более что по скорости выигрыша почти нет.
Другое дело, когда речь заходит о специфическом использовании контейнеров. Самый распространённый пример, который у всех на слуху – это достаточно большой рынок решений NFV (Network Functions Virtualization) — специализированного софта по виртуализационному управлению сетями в общем смысле, с разветвленной топологией, балансировщиками, сложными файрволлами. Сейчас принцип NFV реализуют в виде небольших «операционных систем», которые, например, можно поставить даже на отдельный физический сервер и через него маршрутизировать весь трафик с любыми настройками функций. Производители таких «сетевых дистрибутивов» часто переносят их в виртуальные машины, однако если вместо них использовать контейнеры с заведомо решёнными вопросами безопасности, можно получить прирост в производительности: 10-20% рост скорости или снижения задержек для современных сетевых решений является существенным выигрышем, и за него стоит бороться.
NFV – это лишь один из многочисленных примеров выгодного использования контейнерной виртуализации. Не менее популярны сегодня, например, сервисы для бэкапов на базе контейнерной виртуализации. Широко также представлен проект OpenStack, предлагающий контейнерный запуск многочисленных сервисов для управления процессами в дата-центрах.
Трудно предсказать, будут ли контейнеры когда-нибудь вытеснены виртуальными машинами из таких приложений, но, по крайней мере, не в обозримой перспективе.
THG.ru: Как можно описать место контейнеров в общей ИТ-экосистеме?
П. Емельянов: Docker определяет понятие «контейнер» как запакованное приложение, готовое к запуску в любой среде. Virtuozzo подходит к контейнеру несколько иначе, запуская в гостевом режиме целый дистрибутив – своего рода лёгкую виртуальную машину. Однако и тот и другой подход требует адаптации прочих элементов ИТ-экосистемы для свободной работы с контейнерами.
Пользователи хотят получить возможность работать с приложением, независимо от того, кто это приложение создал, от каналов его распространения, от платформы и других параметров. Заказчик вообще не хочет думать о том, как это всё работает. Поэтому отрасль постепенно приходит к пониманию, что необходимо распространять контейнеры в виде готовых продуктов – как пирожки с повидлом. Ведь нам без разницы, где их испекли и на каком автомобиле привезли в ближайший киоск.
THG.ru: Расскажите о текущей ситуации по стандартизации технологий для работы с контейнерами.
П. Емельянов: Работа проекта Open Containers Initiative (OCI) стартовала в начале 2016 года. Сейчас в OCI входят десятки ведущих компаний отрасли, включая Amazon, AT&T, Cisco, Dell EMC, Facebook, Fujitsu, Goldman Sachs, Google, HPE, Huawei, IBM, Intel, Microsoft, Red Hat, Suse, Virtuozzo, VMVare и другие.
Глубинная суть проекта состоит в том, чтобы обеспечить возможность прямого взаимодействия разработчиков, магазинов и провайдеров платформ для запуска приложений. Разработчиков существует огромное множество. В роли магазинов могут выступать DockerHub, Quay, Bitnami, RedHat, а потенциальные платформы для запуска контейнеров предлагают Docker, CoreOS, Virtuozzo, LXC, OpenShift, Magnum и другие.
В результате роль OCI заключается в том, чтобы дать возможность этим решениям взаимодействовать с использованием единого стандарта.
Первой целью проекта была назначена разработка двух стандартов. Первый из них – стандарт по запуску контейнеров, в нем описываются требования к определенному интерфейсу, который должна предоставлять платформа для запуска контейнеров с приложениями приложений. За основу этого стандарта – Application Container spec (appc) де факто была взята послойная запаковка контейнеров Docker v2.
Этот стандарт был представлен летом и сейчас переживает уже не первую ревизию. Второй стандарт, выпущенный позже, описывает характеристики распространения контейнеров. Этот стандарт также готов, но его делали уже не из разработок Docker, а на основе схожего проекта CoreOS. В свое время проект CoreOS стартовал в качестве платформы для запуска контейнеров Docker, но позже их не устроил способ описания упаковки контейнеров Docker, и они выпустили свой, более продвинутый вариант с подписями для верификации и другими функциональными возможностями. Именно поэтому в OCI приняли решение взять за основу стандарта распространения контейнеров более гибкие наработки CoreOS.
Помимо разработки стандартов, инициатива OCI также разработала ряд референсных утилит, гарантированно поддерживающих принятые стандарты. Таким образом, любая платформа контейнерной виртуализации, претендующая на совместимость со стандартами OCI, имеет возможность пройти сертификационные процедуры и подтвердить эту совместимость на практике.
THG.ru: Каков вклад Virtuozzo в деятельность OCI?
П. Емельянов: Наш вклад, возможно, не такой глубокий как хотелось бы, но тем не менее участие мы принимаем. В разработке самих стандартов Virtuozzo участие не принимала, но внутри OCI существует собственный надзорный орган (Technical Oversight Board, TOB) для координации всех действий проекта. Численность этого надзорного органа составляет 10 представителей от разных компаний, и в 2016 году одним из участников этого совета довелось стать мне.
Virtuozzo планирует присоединиться к максимальному количеству технических комитетов, которые будут разрабатывать стандарты взаимодействия контейнеров.
Но уже сейчас в рамках OCI наши специалисты участвуют в доработках ядра Linux, позволяющих расширить функционал технологий контейнерной виртуализации. В рамках этой инициативы происходит массовое исправление ошибок, а также внедрение дополнительных библиотек для таких проектов как KVM, CRIU, Ploop и т.д.
Кстати, коллективная работа позволяет совместно с другими группами вести такие проекты как расширение функционала KVM и поддержка Hyper-V для гостевых машин с Windows. В проекте qemu мы совместными силами внедряем технологии резервного копирования и поддержку plop. Для контейнеров Docker происходит интеграция с нашим инструментом «живой миграции» CRIU. И это только начало – впереди нас ждёт значительно больше новых комьюнити и совместных инициатив.
Тем не менее, открытость стандартов несёт в себе как преимущества, так и недостатки. В частности, нужно приложить немало усилий, чтобы создать единую экосистему, способную учитывать мнения и объединять усилия разработчиков из разных компаний. Но если это не чья-то коммерческая инициатива, нам нужно самостоятельно организоваться и договориться о стандартах и форматах совместной работы.
Роль таких ассоциаций, как Open Container Initiative (OCI), сводится к созданию открытого «клуба», который будет направлять развитие отрасли, создавая единые отраслевые стандарты для различных контейнерных технологий.
THG.ru: Каким образом формируется структура OCI?
П. Емельянов: Open Container Initiative создает двухуровневую модель взаимодействия разработчиков. С одной стороны, существуют сообщества Technical Developer Community (TDC), которые непосредственно разрабатывают стандарты, обсуждая и описывая их в режиме «открытого сообщества». На начальном этапе создано два сообщества, но ожидается, что их будет очень много, так как областей, требующих введения единого стандарта, появляется всё больше.
Надзорный орган – Technical Oversight Board (TOB), членом которого я являюсь, представлен экспертами отрасли и занимается формированием сообщества TDC, даёт начальные рекомендации и координирует их работу. Примечательно, что TOB состоит из отдельных экспертов, компании же работают на уровне технических сообществ.
На данный момент активно работает TDC по стандарту запуска контейнера (основные участники – Docker, RedHat, CoreOS, Google) и по формату распространения и хранения (основные участники – Docker, Google, RedHat, CoreOS и Huawei). Первые шаги уже сделаны, и TOB рекомендует в качестве базового использовать формат AppC принятый в Rocket, который почти полностью поддержан в RunC (утилита командной строки) и ContainerD (демон, предоставляющий REST интерфейс к RunC).