The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Новая версия системы управления контейнерной виртуализацией Docker 0.9

10.03.2014 23:29

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

Код Docker написан на языке Go и распространяется под лицензией Apache 2.0. Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Для создания контейнеров могут использоваться libcontainer, lxc, libvirt, systemd-nspawn и т.п. Для формирования контейнера достаточно загрузить базовый образ окружения (docker pull base), после чего можно запускать в изолированных окружениях произвольные приложения (например, для запуска bash можно выполнить "docker run -i -t base /bin/bash").

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

  • Новый драйвер по умолчанию - libcontainer, который предоставляет интерфейс для прямого обращения к средствам ядра Linux, обеспечивающим работу изолированных контейнеров (cgroups, пространства имён, Apparmor, SELinux, netlink, capabilities и т.д.). Libcontainer позволяет обойтись без ранее используемых прослоек и зависимостей, таких как lxc, libvirt или systemd-nspawn. Поддержка LXC теперь является опциональной. Libcontainer написан на языке Go и оформлен в виде самодостаточной библиотеки, не привязанной к Docker, что позволяет использовать её и в сторонних проектах для манипуляции такими сущностями, как cgroups и пространства имён;
  • Универсальный API драйверов обеспечения запуска (execution driver API), который можно использовать для настройки исполняемой среды, окружающей каждый контейнер. Указанный API позволяет задействовать различные инструменты для обеспечения изоляции, каждый из которых обладает своими особенностями и установочной базой: OpenVZ, systemd-nspawn, libvirt-lxc, libvirt-sandbox, qemu/kvm, BSD Jails, Solaris Zones и chroot. Поддержка LXC по-прежнему реализуется в отдельном драйвере.

Особенности выпуска Docker 0.9:

Основные возможности Docker:

  • Возможность размещения в изолированном окружении разнородной начинки, включающей различие комбинации исполняемых файлов, библиотек, файлов конфигурации, скриптов, файлов jar, gem, tar и т.д.
  • Поддержка работы на любом компьютере на базе архитектуры x86_64 с системой на базе современного ядра Linux, начиная от ноутбуков, заканчивая серверами и виртуальными машинами. Возможность работы поверх немодифицированных современных ядер Linux (без наложения патчей) и в штатных окружениях всех крупных дистрибутивов Linux, включая Fedora, RHEL, Ubuntu, Debian, SUSE, Gentoo и Arch;
  • Использование легковесных контейнеров для изоляции процессов от других процессов и основной системы.
  • Так как контейнеры используют свою собственную самодостаточную файловую систему, не важно где, когда и в каком окружении они запускаются.
  • Изоляция на уровне файловой системы: каждый процесс выполняется в полностью отдельной корневой ФС;
  • Изоляция ресурсов: потребление системных ресурсов, таких как расход памяти и нагрузка на CPU, могут ограничиваться отдельно для каждого контейнера с использованием cgroups;
  • Изоляция на уровне сети: каждый изолированный процесс имеет доступ только к связанному с контейнером сетевому пространству имён, включая виртуальный сетевой интерфейс и привязанный к нему IP-адрес;
  • Корневая файловая система для контейнеров создаётся с использованием механизма copy-on-write (отдельно сохраняются только изменённые и новые данные), что позволяет ускорить развёртывание, снижает расход памяти и экономит дисковое пространство;
  • Все стандартные потоки (stdout/stderr) каждого выполняемого в контейнере процесса накапливаются и сохраняются в виде лога;
  • Изменённая файловая система одного контейнера может использоваться в качестве основы для формирования новых базовых образов и создания других контейнеров, без необходимости оформления шаблонов или ручной настройки состава образов;
  • Возможность использования интерактивной командной оболочки: к стандартному вводу любого контейнера может быть привязан псевдо-tty для запуска shell.
  • Поддержка использования разных систем хранения, которые могут подключаться как плагины. Среди поддерживаемых драйверов хранения заявлены aufs, device mapper (используются снапшоты LVM), vfs (на основе копирования директорий) и Btrfs. Ожидается появление драйверов для ZFS, Gluster и Ceph;
  • Возможность создания контейнеров, содержащих сложные программные стеки, через связывание между собой уже существующих контейнеров, содержащих составные части формируемого стека. Связывание осуществляется не через слияние содержимого, а через обеспечения взаимодействия между контейнерами (создаётся сетевой туннель).



  1. Главная ссылка к новости (http://blog.docker.io/2014/03/...)
  2. OpenNews: Новая версия системы управления контейнерной виртуализацией Docker 0.8
  3. OpenNews: На развитие системы управления контейнерной виртуализацией Docker выделено 15 млн долларов
  4. OpenNews: Новая версия системы управления контейнерной виртуализацией Docker 0.7.0
  5. OpenNews: Релиз LXC 1.0, системы управления изолированными контейнерами Linux
Лицензия: CC-BY
Тип: Программы
Ключевые слова: docker
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (9) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 01:18, 11/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А чем (кроме NIH и Go) libcontainer отличается от libvirt?
     
     
  • 2.9, уокер (?), 10:56, 11/03/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    как я понял из http://blog.docker.io/2014/03/docker-0-9-introducing-execution-drivers-and-li :
    - libcontainer это аналог не libvirt, а lxc
    - поддержка libvirt и прочих не реализована; она только возможна, благодаря новому execution driver api

    тогда настораживает, что они запилили систему контейниризации (libcontainer) за пару месяцев:)

     
     
  • 3.14, Аноним (-), 16:05, 11/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > - libcontainer это аналог не libvirt, а lxc

    Ага, не libvirt, а lxc-libvirt :)

    > тогда настораживает, что они запилили систему контейниризации (libcontainer) за пару месяцев:)

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

     
  • 2.10, Аноним (-), 11:01, 11/03/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > А чем (кроме NIH и Go) libcontainer отличается от libvirt?

    libvirt при работе с контейнерами является лишь обёрткой над LXC, а libcontainer заменяет собой LXC. Скоро можно ждать появление в libvirt поддержки libcontainer, но не наоборот.

     
     
  • 3.12, Аноним (-), 15:57, 11/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > libvirt при работе с контейнерами является лишь обёрткой над LXC

    Нет. И lxc-libvirt, и LXC, и libcontainer - это равноправные обертки над одними и теми же функциями ядра (флаги вызова clone() и cgroupfs).
    lxc-libvirt не требует юзерспейсных программ LXC, просто потому, что задать флаги для clone() проще, чем городить exec() всякой левой хрени.

     
  • 2.13, Аноним (-), 16:01, 11/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А чем (кроме NIH и Go) libcontainer отличается от libvirt?

    Поддержкой всяких разных извратов с backing storage (aufs, btrfs и прочие снепшоты). libvirt больше ориентирован на KVM/Xen, использующие файлы-образы, а не каталоги.

    В любом случае, хранение корня контейнера в каталоге ФС хоста - это тупиковый путь, как уже десять лет назад убедились разработчики OpenVZ. Из контейнера можно спокойно забить очередь на запись ФС хоста, и никакие cgroups не спасут. Более-менее корректное решение задачи уже давно разработано - ploop+simfs, снепшоты в комплекте. Но лисапедисты пока что пилят лисапеды на aufs...

     
     
  • 3.17, Глас Божий (?), 19:54, 12/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Тяжело живётся админам хостингов. Приходится пользоваться всяким ненужно.
     
  • 3.18, Аноним (-), 03:00, 20/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ploop+simfs умеют, как aufs, использовать одни и те же страницы памяти для одного и того же файла с нижнего бранча, открытого через разные вышележащие бранчи? Т.е. если у меня будет 20 виртуалок из одного и того же образа ОС (но с разными вышележащими слоями), то glibc у меня в одном экземпляре в памяти висеть будет или 20кратный объем памяти под него улетит?
     

  • 1.11, Пушистик (ok), 12:36, 11/03/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Незаменимая вещь!
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру