Увидел свет (http://blog.docker.io/2014/03/docker-0-9-introducing-executi.../) выпуск инструментария для управления изолированными Linux-контейнерами Docker 0.8 (http://www.docker.io/). Docker предоставляет высокоуровневый API, позволяющий манипулировать контейнерами на уровне изоляции отдельных процессов. В частности, Docker позволяет не заботясь о формировании начинки контейнера запускать произвольные процессы в режиме изоляции и затем переносить и клонировать сформированные для данных процессов контейнеры на другие серверы, беря на себя всю работу по созданию, обслуживанию и сопровождению контейнеров.
Код Docker написан на языке Go и распространяется (https://github.com/dotcloud/docker/) под лицензией Apache 2.0. Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Для создания контейнеров могут использоваться libcontainer, lxc (http://lxc.sourceforge.net/), libvirt, systemd-nspawn и т.п. Для формирования контейнера достаточно загрузить базовый образ окружения (docker pull base), после чего можно запускать в изолированных окружениях произвольные приложения (например, для запуска bash можно выполнить "docker run -i -t base /bin/bash").
При подготовке новой версии основное внимание уделялось не расширению функциональности, а повышению стабильности и увеличению качества. В связи с этим новый выпуск примечателен добавлением (https://github.com/dotcloud/docker/blob/release/CHANGELOG.md) только двух значительных новшеств:- Новый драйвер по умолчанию - libcontainer, который предоставляет интерфейс для прямого обращения к средствам ядра Linux, обеспечивающим работу изолированных контейнеров (cgroups, пространства имён, Apparmor, SELinux, netlink, capabilities и т.д.). Libcontainer позволяет обойтись без ранее используемых прослоек и зависимостей, таких как lxc, libvirt или systemd-nspawn. Поддержка LXC теперь является опциональной. Libcontainer (https://github.com/dotcloud/docker/tree/master/pkg/libcontainer) написан на языке Go и оформлен в виде самодостаточной библиотеки, не привязанной к Docker, что позволяет использовать её и в сторонних проектах для манипуляции такими сущностями, как cgroups и пространства имён;
<center><a href="http://blog.docker.io/wp-content/uploads/2014/03/docker-exec... src="http://www.opennet.me/opennews/pics_base/0_1394482181.png" style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>- Универсальный API драйверов обеспечения запуска (execution driver API), который можно использовать для настройки исполняемой среды, окружающей каждый контейнер. Указанный API позволяет задействовать различные инструменты для обеспечения изоляции, каждый из которых обладает своими особенностями и установочной базой: OpenVZ, systemd-nspawn, libvirt-lxc, libvirt-sandbox, qemu/kvm, BSD Jails, Solaris Zones и chroot. Поддержка LXC по-прежнему реализуется в отдельном драйвере.
Особенности (https://github.com/dotcloud/docker/blob/release/CHANGELOG.md) выпуска 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;- Возможность создания контейнеров, содержащих сложные программные стеки, через связывание между собой уже существующих контейнеров, содержащих составные части формируемого стека. Связывание осуществляется не через слияние содержимого, а через обеспечения взаимодействия между контейнерами (создаётся сетевой туннель).
URL: http://blog.docker.io/2014/03/docker-0-9-introducing-executi.../
Новость: http://www.opennet.me/opennews/art.shtml?num=39282
А чем (кроме NIH и Go) libcontainer отличается от libvirt?
как я понял из http://blog.docker.io/2014/03/docker-0-9-introducing-executi.../ :
- libcontainer это аналог не libvirt, а lxc
- поддержка libvirt и прочих не реализована; она только возможна, благодаря новому execution driver apiтогда настораживает, что они запилили систему контейниризации (libcontainer) за пару месяцев:)
> - libcontainer это аналог не libvirt, а lxcАга, не libvirt, а lxc-libvirt :)
> тогда настораживает, что они запилили систему контейниризации (libcontainer) за пару месяцев:)
Видимо, просто вынесли все свои низкоуровневые огороды в отдельный модуль, работающий через API.
> А чем (кроме NIH и Go) libcontainer отличается от libvirt?libvirt при работе с контейнерами является лишь обёрткой над LXC, а libcontainer заменяет собой LXC. Скоро можно ждать появление в libvirt поддержки libcontainer, но не наоборот.
> libvirt при работе с контейнерами является лишь обёрткой над LXCНет. И lxc-libvirt, и LXC, и libcontainer - это равноправные обертки над одними и теми же функциями ядра (флаги вызова clone() и cgroupfs).
lxc-libvirt не требует юзерспейсных программ LXC, просто потому, что задать флаги для clone() проще, чем городить exec() всякой левой хрени.
> А чем (кроме NIH и Go) libcontainer отличается от libvirt?Поддержкой всяких разных извратов с backing storage (aufs, btrfs и прочие снепшоты). libvirt больше ориентирован на KVM/Xen, использующие файлы-образы, а не каталоги.
В любом случае, хранение корня контейнера в каталоге ФС хоста - это тупиковый путь, как уже десять лет назад убедились разработчики OpenVZ. Из контейнера можно спокойно забить очередь на запись ФС хоста, и никакие cgroups не спасут. Более-менее корректное решение задачи уже давно разработано - ploop+simfs, снепшоты в комплекте. Но лисапедисты пока что пилят лисапеды на aufs...
Тяжело живётся админам хостингов. Приходится пользоваться всяким ненужно.
ploop+simfs умеют, как aufs, использовать одни и те же страницы памяти для одного и того же файла с нижнего бранча, открытого через разные вышележащие бранчи? Т.е. если у меня будет 20 виртуалок из одного и того же образа ОС (но с разными вышележащими слоями), то glibc у меня в одном экземпляре в памяти висеть будет или 20кратный объем памяти под него улетит?
Незаменимая вещь!
