The OpenNET Project / Index page

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

Открыт код Docker, системы запуска приложений в изолированных контейнерах

28.03.2013 22:46

Компания DotCloud перевела в разряд свободных инструментарий для управления изолированными Linux-контейнерами Docker. Docker дополняет инструментарий LXC более высокоуровневым API, работающим на уровне изоляции отдельных процессов. Инструментарий позволяет запускать произвольные процессы в режиме жесткой изоляции и затем переносить и клонировать изолированные контейнеры на другие серверы, не задумываясь о формировании начинки контейнера и его обслуживании. Одним из применений Docker является обеспечение автоматизации в распределённых системах.

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

Основные особенности Docker:

  • Возможность размещения в изолированном окружении разнородной начинки, включающей различие комбинации исполняемых файлов, библиотек, файлов конфигурации, скриптов, файлов jar, gem, tar и т.д.
  • Поддержка работы на любом компьютере на базе архитектуры x86_64 с системой на базе современного ядра Linux, начиная от ноутбуков, заканчивая серверами и виртуальными машинами.
  • Использование легковесных контейнеров для изоляции процессов от других процессов и основной системы.
  • Так как контейнеры используют свою собственную самодостаточную файловую систему, не важно где, когда и в каком окружении они запускаются.

Базовые возможности:

  • Изоляция на уровне файловой системы: каждый процесс выполняется в полностью отдельной корневой ФС;
  • Изоляция ресурсов: потребление системных ресурсов, таких как расход памяти и нагрузка на CPU, могут ограничиваться отдельно для каждого контейнера с использованием cgroups;
  • Изоляция на уровне сети: каждый изолированный процесс имеет доступ только к связанному с контейнером сетевому пространству имён, включая виртуальный сетевой интерфейс и привязанный к нему IP-адрес;
  • Корневая файловая система для контейнеров создаётся с использованием механизма copy-on-write (отдельно сохраняются только изменённые и новые данные), что позволяет ускорить развёртывание, снижает расход памяти и экономит дисковое пространство;
  • Все стандартные потоки (stdout/stderr) каждого выполняемого в контейнере процесса накапливаются и сохраняются в виде лога;
  • Изменённая файловая система одного контейнера, может использоваться в качестве основы для формирования новых базовых образов и создания других контейнеров, без необходимости оформления шаблонов или ручной настройки состава образов;
  • Возможность использования интерактивной командной оболочки: к стандартному вводу любого контейнера может быть привязан псевдо-tty для запуска shell.


  1. Главная ссылка к новости (https://groups.google.com/d/ms...)
  2. OpenNews: Интервью с Павлом Емельяновым, одним из самых активных российских разработчиков ядра Linux
  3. OpenNews: Первый релиз CRtools, утилиты для заморозки и восстановления состояния процессов в Linux
  4. OpenNews: Релиз CRIU 0.2, системы для заморозки и восстановления состояния процессов в Linux
  5. OpenNews: Доступна децентрализованная система установки приложений Zero Install 2.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/36532-lxc
Ключевые слова: lxc, docker, cgroups, container
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (12) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:29, 28/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    еще прикрутить живую миграцию с хоста на хост в облаке
     
  • 1.4, Аноним (-), 03:18, 29/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Замечтельно
     
  • 1.8, Аноним (-), 10:15, 29/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что-то я не просёк, как сочетаются copy-on-write и самодостаточность ФС "не важно где, когда и в каком окружении".
     
  • 1.11, Аноним (-), 12:11, 29/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А смысл использовать copy-on-write? Ну вот есть у нас десяток виртуалок с линуксом. Их же надо обновлять иногда. Если делать apt-get upgrade в родительской ФС, то это чревато такими глюками, что даже не знаю. Особенно если в дочерних системах были установлены свои пакеты. Если делать apt-get upgrade в каждой виртуалке, то один фиг через год все файлы перезапишутся, и от copy-on-write толку больше не будет, кроме тормозов.
     
     
  • 2.13, Аноним (-), 14:12, 29/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А смысл использовать copy-on-write? Ну вот есть у нас десяток виртуалок с
    > линуксом. Их же надо обновлять иногда. Если делать apt-get upgrade в
    > родительской ФС, то это чревато такими глюками, что даже не знаю.
    > Особенно если в дочерних системах были установлены свои пакеты. Если делать
    > apt-get upgrade в каждой виртуалке, то один фиг через год все
    > файлы перезапишутся, и от copy-on-write толку больше не будет, кроме тормозов.

    какие глюки обновитца же по цепочке всё

     
     
  • 3.15, Аноним (-), 15:59, 29/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ну представь, в дочерней системе установлены какие-то дополнительные пакеты, а родительская система о них ничего не знает. У дочерней системы своя база база данных установленных пакетов, у родительской - своя. Что будет с базой установленных пакетов в дочерней системе после обновления пакетов в родительской системе? В aufs пока ещё не встроили ИИ, чтобы он такие конфликты разруливал магическим образом. :)
     
     
  • 4.17, Бобазали (?), 23:23, 30/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >В aufs пока ещё не встроили ИИ, чтобы он такие конфликты разруливал магическим образом. :)

    Для таких задач ИИ не нужен :). Вполне достаточно отследить записи в общие файлы. Если после записи файлы совпадают, то они используются совместно, если нет, то используется индивидуальная версия.

     

  • 1.18, arisu (ok), 02:41, 31/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Код Docker написан на языке Go

    опять херь какую-то ставить для сборки. тьфу. подожду, пока сделают на нормальном языке.

     
     
  • 2.19, vle (ok), 21:20, 01/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    мммм, таки в самом деле brainfuck?
     
     
  • 3.20, arisu (ok), 22:58, 01/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > мммм, таки в самом деле brainfuck?

    whitespace!

     

  • 1.21, Аноним (-), 15:19, 22/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это не та программа в гноме?
    Секюрность повыше обычного lxc?
     
     
  • 2.22, weirded (ok), 15:12, 29/03/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Оно ж LXC и использует, как я понял.
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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