Нам иногда задают интересный вопрос: как Parallels конкурирует с Docker и где нас носит, пока эти ребята завоевывают рынок? Отвечаем. Во-первых, мы, с тех пор как десять лет назад создали контейнеры, продолжаем совершенствовать технологию контейнерной виртуализации и продвигать ее в основное ядро Linux. Во-вторых, мы все-таки работаем на разных уровнях: Docker занимается запаковкой и запуском приложений, а мы собственно виртуализацией — низкоуровневой технологией, которая используется в Docker, так что по ряду проектов мы партнеры. Более того, открою секрет: все существующие контейнерные проекты на рынке не только конкуренты друг другу. Мы стараемся совместно разрабатывать общие компоненты.
Яркий пример — это проект libcontainer, который объединил в себе две версии библиотеки для управления ядерными компонентами, с помощью которых создаются контейнеры. Мы стремимся стандартизировать работу собственного проекта OpenVZ, Docker и других проектов с ядром Linux, привязать libcontainer к основным языкам программирования и за счет этого расширить количество сценариев использования контейнеров на рынке. Кроме этого, у нас есть планы сделать через эту библиотеку интеграцию контейнеров с OpenStack.
У libcontainer, кстати, интересная история. Docker изначально задумывался как проект по управлению шаблонами контейнеров и запускал их сначала с помощью vzctl. Потом разработчики перешли на LXC, а еще позже задумали свою библиотеку — libcontainer. Одновременно с этим мы решили «стандартизовать» околоядерную часть контейнеров и сделать низкоуровневую библиотеку. Итого на тот момент получилось аж три «движка»: наш, LXC и libcontainer. Мы переработали свою версию и показали ее людям, но так получилось, что самый первый релиз библиотеки Docker практически совпал с нашим анонсом. Поскольку цель у этих проектов была одинаковая, мы решили объединить усилия. В libcontainer у нас несколько интересов. Во-первых, сейчас для того, чтобы работать с контейнерами, нужно сделать выбор между несколькими проектами. Это неудобно для пользователей и накладно для разработчиков: несколько команд вынуждены поддерживать, по сути, несколько разных реализаций одной и той же технологии. Но рано или поздно весь стек будет стандартизован, и мы хотим в этом участвовать, чтобы контролировать процесс и результат. Во-вторых, мы сможем реализовать мечту многих пользователей запускать Docker-контейнеры на нашем стабильном ядре.
Недавно мы вместе с Docker объявили, что решение Virtuozzo (преемник OpenVZ и Parallels Cloud Server) поддерживает контейнеры Docker и позволяет создавать «контейнеры внутри контейнеров» (Docker внутри Virtuozzo).
Еще один хороший пример сотрудничества — это живая миграция контейнеров Docker (и LXC), которая осуществима благодаря нашему проекту CRIU (Checkpoint/Restore [mostly] In Userspace). Это технология, которая умеет снимать состояние выполняющихся в Linux процессов и восстанавливать эти процессы в другом месте или в другое время из полученных данных (так называемая заморозка). Более того, это первая в истории реализация технологии создания снапшотов приложений, которая работает на немодифицированной ОС Linux (ядро + системные библиотеки) и поддерживает любые состояния процессов. Она доступна, к примеру, в Fedora начиная с версии 19. Проекты такого рода были и раньше, но у них имелись недостатки: требовалось либо брать особое ядро, либо подкручивать системные библиотеки, или поддерживались не все состояния.
Собственно за живую миграцию отвечает подпроект P.Haul, который с помощью CRIU правильно переносит контейнер с одного компьютера на другой. CRIU позволяет выполнять два основных действия. Первое — это снятие состояний процессов и их запись в файлы. Второе — восстановление процессов из сохраненных данных. У этих действий есть некоторые тонкости, например CRIU может работать, не останавливая процессы, или снимать только изменения в состояниях.
Миграция — это уже более сложный процесс. Он состоит минимум из трех действий: снятия состояния, переноса его на вторую машину и восстановления. В действительности это еще и возможный перенос файловой системы, остановка процессов на первой машине до окончания работы (и уничтожение этих процессов уже в самом конце), оптимизация времени заморозки за счет нескольких переносов памяти со снятием изменений состояния, возможное дополнительное копирование памяти уже после миграции.
Это также перенос IP-адреса контейнера, перерегистрация его в системе управления (например, в случае с Docker это так называемый docker-daemon). А еще обработка внешних связей контейнера: например, LXC часто связывает файлы внутри контейнера с файлами снаружи. При миграции надо сказать CRIU, что такие файлы есть и как их перепривязать на второй машине. Работу со всеми этими вариантами и тонкостями мы и превратили в отдельный подпроект.
Сегодня CRIU — стандарт реализации checkpoint/restore в Linux — вопреки мнению VMware, которая заявляла, что для миграции контейнеров нужно использовать vmotion. В этом проекте мы также сотрудничаем с инженерами Google, Canonical и RedHat. Они не только присылают патчи, но и активно участвуют в обсуждении поддержки cgroup в CRIU и успешно используют CRIU с утилитами Docker и LXC.
У технологии CRIU масса применений: помимо миграции на лету, это еще и ускорение старта «толстых» приложений, обновление ядра без перезагрузки, балансирование нагрузки, сохранение состояния задачи на случай падения системы. Сценариев использования несколько, в том числе балансировка сетевой нагрузки, анализ поведения приложений на другой машине, дупликация процессов и так далее.
