The OpenNET Project / Index page

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

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

12.12.2014 10:38

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

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

Из добавленных в Docker 1.4 новшеств можно отметить:

  • Новый драйвер для организации хранилища поверх многослойной файловой системы OverlayFS, код которой вошёл в состав ядра Linux 3.18;
  • В управляющий демон добавлена опция "-label" для установки меток в форме "ключ=значение", выводимых при выполнении команды "docker info";
  • Поддержка установки переменных окружения через указание в Dockerfile опции "ENV name=value name2=value2...";
  • В вывод команды "docker info" добавлено отображение полей с идентификатором и именем;
  • Возможность фильтрации событий по имени события, контейнеру и образу окружения;
  • Команда "docker cp" расширена поддержкой копирования данных из разделов контейнера.

Одновременно доступен корректирующие выпуск Docker 1.3.3, в котором устранены три уязвимости (проблемы также исправлены в Docker 1.4.0), которые были обнаружены в процессе аудита после выявления в ноябре двух критических проблем с безопасностью. Уязвимости проявляются при использовании готовых образов или образов, собранных Dockerfile, загруженных из сторонних непроверенных источников. Как и прошлые уязвимости, новые проблемы позволяют выполнить код или получить доступ к внешней ФС в процессе запуска или обработки специально модифицированного образа контейнера.

  • CVE-2014-9356 - возможность записи во внешние части ФС и выхода за пределы контейнера через манипуляции с абсолютными символическими ссылками;
  • CVE-2014-9357 - повышение привилегий (выполнение кода с правами root) в процессе декодирования специально оформленных архивов LZMA (.xz);
  • CVE-2014-9358 - проблемы с проверкой идентификатора образа контейнера, которые могут быть использованы для подмены загружаемого из репозитория образа или выхода за пределы допустимого файлового пути.

Дополнительно можно отметить публикацию компанией Docker трёх новых инструментов:

  • Docker Machine - система для быстрого развёртывание хостов в гостевых окружениях систем виртуализации, предназначенных для организации контейнерной виртуализации приложений на основе Docker. Осуществляет создание начинки сервера, установку на него Docker и настройку клиента для работы с данным сервером. Поддерживается создание серверов в виртуальных окружениях VirtualBox, VMware, AWS, Digital Ocean и Microsoft Azure;
  • Docker Swarm - средства кластеризации для упакованных в контейнеры приложений. Даёт возможность управлять кластером из нескольких хостов Docker (например, созданных с использованием Docker Machine) в форме работы с одним виртуальным хостом. Так как Swarm использует штатный Docker API, он может применяться для управления и другими поддерживающими данный API инструментами, такими как dokku, fig, krane, flynn, deis, docker-ui, shipyard, drone.io, Jenkins;
  • Docker Compose - позволяет организовать работу распределённого на несколько хостов приложения, в работу которого вовлечено несколько контейнеров, запущенных в кластере на базе Docker Swarm.


  1. Главная ссылка к новости (https://blog.docker.com/2014/1...)
  2. OpenNews: Проект CoreOS представил Rocket, конкурирующий с Docker инструментарий управления контейнерами
  3. OpenNews: Обновление Docker 1.3.2 с устранением критических уязвимостей
  4. OpenNews: Canonical и Docker развивают LXD, гипервизор для изолированных контейнеров (дополнено)
  5. OpenNews: Выпуск cистемы управления контейнерной виртуализацией Docker 1.3
  6. OpenNews: Red Hat и Docker развивают систему изолированных контейнеров для десктоп-приложений
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41251-docker
Ключевые слова: docker
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (23) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, iZEN (ok), 11:51, 12/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Подумываю над реализацией запуска X-приложений таких, как Xfce4 DE, Firefox и т.д. внутри FreeBSD Jail. В чём может быть принципиальная трудность этого? Способы решения? (Все необходимые приложения, библиотеки и xorg-server 1.12.4 уже есть внутри клетки. Клетка работает — консольные приложения запускаются.
     
     
  • 2.3, Аноним (-), 11:57, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    В LXC Х-приложения уже давно запускают, а ты жди своего docker.exe. Всё равно, кроме вантуза у тебя ничего больше не вращается.
     
  • 2.4, Andrew Kolchoogin (ok), 12:11, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1. Мы хотим «ня» и прочие прозрачности/OpenGL.
    Тогда контейнерная изоляция (любая на любой операционной системе) бессмысленна: отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции. По этой же причине бессмысленно внутри контейнера запускать X-сервер (ему это нужно обязательно).

    2. Мы обойдёмся AIGLX (если он есть), или вообще на OpenGL нам наплевать.
    Тогда export DISPLAY=host.machine.domain:0, и понеслась.
    На основной системе только надо выгрести из флагов X-сервера «-nolisten tcp», и зашарить домашнюю директорию с контейнером (ну, или, хотя бы, .Xauthority из неё).

     
     
  • 3.6, Ordu (ok), 12:47, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > 1. Мы хотим «ня» и прочие прозрачности/OpenGL.
    > 2. Мы обойдёмся AIGLX (если он есть), или вообще на OpenGL нам наплевать.

    Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX? Я просто не пользуюсь всей этой хренью; внутрь не заглядывал, как реализовано могу лишь догадываться, и по моим догадкам, на глаз заметить разницу между AIGLX и DRI не удастся на столь простой задаче как няшно отрисованные окошки. Крузис конечно будет тормозить, но на то он и крузис. Или мои догадки неверны? Чессово лень впиливать в систему что-нибудь композитное, только для того, чтобы посмотреть.

    > отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.

    Смерть. Бесспорно. Но... а возможно ли отказаться от dri и как-то прокинуть /dev/shm в контейнер? Ну не будет direct render'а, но всё ж клиенту не придётся сериализовывать всякие там текстурки и прокидывать их через сокет серверу. Или это никак? Или это опять же кранты изоляции?

     
     
  • 4.12, Stax (ok), 15:07, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX? Я
    > просто не пользуюсь всей этой хренью; внутрь не заглядывал, как реализовано

    Не страдают. Более того, раньше оно через него обычно и работало.

    >> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.
    > Смерть. Бесспорно. Но... а возможно ли отказаться от dri и как-то прокинуть
    > /dev/shm в контейнер? Ну не будет direct render'а, но всё ж
    > клиенту не придётся сериализовывать всякие там текстурки и прокидывать их через
    > сокет серверу. Или это никак? Или это опять же кранты изоляции?

    Да смотря какая у вас цель. Если вам 3D нужно, почему дать доступ к видеокарте это "кранты изоляции"? А если вам важна изоляция, из которой (кто-то другой, а не ваша конкретная прога) не выберется, зачем ей 3D? Десктопные приложения и полная изоляция вообще слабо совместимые вещи, через тот же браузер куча других векторов атаки (изолируете доступ к файликам на хост-системе, а у вас тем временем уведут куки от сайта, где хранятся данные кредитки типа paypal/google checkout/qiwi).

     
     
  • 5.15, Andrew Kolchoogin (ok), 15:53, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX? Я
    >> просто не пользуюсь всей этой хренью; внутрь не заглядывал, как реализовано
    > Не страдают. Более того, раньше оно через него обычно и работало.

    «Вот ващще-ващще раньше» оно работало и до появления AIGLX в природе. :)

    Через специальный X-сервер.

    >>> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.
    >> Смерть. Бесспорно. Но... а возможно ли отказаться от dri и как-то прокинуть
    >> /dev/shm в контейнер? Ну не будет direct render'а, но всё ж
    >> клиенту не придётся сериализовывать всякие там текстурки и прокидывать их через
    >> сокет серверу. Или это никак? Или это опять же кранты изоляции?
    > Да смотря какая у вас цель. Если вам 3D нужно, почему дать
    > доступ к видеокарте это "кранты изоляции"?

    Потому что «до первого бага».

    Примерно, как PCI Pass-through в Xen'е, и без VT-d.
    Можно?
    Можно.
    Секурно?
    Нет.

    > А если вам важна изоляция,
    > из которой (кто-то другой, а не ваша конкретная прога) не выберется,
    > зачем ей 3D? Десктопные приложения и полная изоляция вообще слабо совместимые
    > вещи, через тот же браузер куча других векторов атаки (изолируете доступ
    > к файликам на хост-системе, а у вас тем временем уведут куки
    > от сайта, где хранятся данные кредитки типа paypal/google checkout/qiwi).

    Вот это совершенно верно.

    Но тут ведь, как обычно, надо понимать, что сама по себе изоляция не делает машину секурной, надо ещё и свои привычки поменять. :)

     
     
  • 6.19, Ordu (ok), 01:36, 13/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Но тут ведь, как обычно, надо понимать, что сама по себе изоляция не делает машину секурной, надо ещё и свои привычки поменять. :)

    Это надо понимать. Но не стоит также забывать, что привычки тоже не панацея.

     
  • 4.13, Andrew Kolchoogin (ok), 15:48, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX?

    Это зависит от.

    Скажем, для «ня» и «прочих прозрачностей» в KDE/KWM OpenGL вообще не нужен — KWM умеет их делать через XRender.
    Однако, «классика жанра» — Compiz — уже требует OpenGL, причём каких-то «высоких версий», чуть ли не минимум 2.1.

    > на глаз заметить разницу между AIGLX и DRI не удастся на столь простой задаче
    > как няшно отрисованные окошки.

    Да, но вот вряд ли удастся сделать так, чтобы в процессе поворота Desktop Cube прям на двух гранях было видно, как играет что-нибудь в YouTube. :)

     
  • 3.11, Stax (ok), 15:02, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Тогда контейнерная изоляция (любая на любой операционной системе) бессмысленна: отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции. По этой же причине бессмысленно внутри контейнера запускать X-сервер (ему это нужно обязательно).

    Отставить панику - /dev/mem никому давать не нужно.
    А отдача /dev/dri почему смерть, если цель именно в том, чтобы дать конкретному приложению 3D? Конечно, в таком контейнере нужно запускать одно приложение, а не грузить ОС

    http://maci0.wordpress.com/2014/05/02/run-any-applications-on-rhel7-container

     
     
  • 4.14, Andrew Kolchoogin (ok), 15:50, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Тогда контейнерная изоляция (любая на любой операционной системе) бессмысленна:
    >> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.
    >> По этой же причине бессмысленно внутри контейнера запускать X-сервер (ему это нужно обязательно).
    > Отставить панику - /dev/mem никому давать не нужно.

    Да?

    А вы проверьте: загрузите FreeBSD, скажите «sysctl kern.securelevel=2», чтобы закрыть /dev/mem, и стартаните Иксы.

    > А отдача /dev/dri почему смерть, если цель именно в том, чтобы дать
    > конкретному приложению 3D? Конечно, в таком контейнере нужно запускать одно приложение,
    > а не грузить ОС

    Потому, что DRM — это ещё и Generic DMA Engine.

    Ну, то есть, это получится «изоляция до первого бага в драйвере».

     
     
  • 5.17, Stax (ok), 18:09, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А вы проверьте: загрузите FreeBSD, скажите «sysctl kern.securelevel=2», чтобы закрыть /dev/mem, и стартаните Иксы.

    Я говорил про линукс. Во фре вообще поддержку запуска иксов из под пользователя, без прав рута уже сделали?

    > Ну, то есть, это получится «изоляция до первого бага в драйвере».

    Контейнеры вообще не очень спасают, если баги такого уровня в ядре. Тут уж только виртуализация. И то, даже там находятся способы выбраться, если баги в ядре..

     
     
  • 6.22, iZEN (ok), 18:26, 13/12/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >> А вы проверьте: загрузите FreeBSD, скажите «sysctl kern.securelevel=2», чтобы закрыть /dev/mem, и стартаните Иксы.
    > Я говорил про линукс. Во фре вообще поддержку запуска иксов из под
    > пользователя, без прав рута уже сделали?

    Теоретически запуск xorg-server на FreeBSD из-под пользователя возможен: http://www.freshports.org/x11-servers/xorg-server/
    — опцию сборки "SUID=on: Install the Xorg server with setuid bit set" можно перевести в "SUID=off" и собрать xorg-server без привелегированного запуска из-под пользователя. Но в таком режиме в X-ах может работать только root.

     
     
  • 7.24, Аноним (-), 21:32, 13/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И как эта теория с практикой соотносится?
     
  • 3.21, iZEN (ok), 18:19, 13/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Упрощённо говоря, у нас есть некая машина, у которой извне доступен только SSH. Она не имеет ни графической карты, ни звуковой. Тем не менее, на ней установлено графическое окружение, включающее в себя десктопные X-приложения: Firefox, LibreOffice, Pluma, RSSOwl и т.д.. Возможно ли, имея этот набор ПО, воспользоваться удалённым запуском этих приложений с отрисовкой их окон на клиенте, у которого нормальная графическая карта, достаточно много ОЗУ, звуковая карта? Клиент должен по сути видеть окна, воспроизведение видео/звука и мог бы воздействовать на элементы управления удалённо запущенных программ. В каком направлении копать?
     
     
  • 4.23, anonimouse (?), 20:09, 13/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Лет 15 назад на той машине нужно было бы настроить ремотный дисплей , а проуинуть х-сессию (возможно ч\з ssh) ... Как оно сейчас яхз., наверно надо ставить vnc ?
     
  • 4.25, Аноним (-), 21:34, 13/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Можно просто ssh -X. У тебя на цигвине должно тоже работать.
    Или Ubuntu LTSP

     
     
  • 5.26, iZEN (ok), 22:56, 13/12/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Можно просто ssh -X. У тебя на цигвине должно тоже работать.

    Цигвина не имею в наличии. Мне, вообще, нужно сделать сначала на Unix без всяких Windows.

    > Или Ubuntu LTSP

    Ты, похоже, ничего кроме Ubuntu не знаешь и не хочешь знать, понимать. Печально это.

     
  • 2.5, fidaj (ok), 12:35, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    http://www.bsdstore.ru/ru/xorg_in_jail.html
     
  • 2.7, пингвинус (?), 13:01, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    http://www.youtube.com/watch?v=YcfmRnxHRKY

    Но как уже писал - это только для себя, поскольку несекьюрно.

     
  • 2.18, Typhoon (ok), 21:26, 12/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Я тоже хочу в клетках запилить, но только приложения, кажтому приложению по клетке, Думаю нужен доступ к экрану и звуковым устройствам, Т.е к сокету Unix для X11, в /tmp/.X11-unix, + правильно настроить DISPLAY, xhost, итд, по поводу звуеа думаю, что достаточно будет прописать монтирование в клетку звуковых устройств. Пока ничего не пробовал, работы много. Кто может что-то посоветовать по делу - напишите комментарий.
     
     
  • 3.20, Stax (ok), 02:05, 13/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Для звука достаточно пробросить туда /run/user/${UID}/pulse
    Вообще я выше ссылку давал про запуск скайпа в контейнере - systemd-nspawn'ом либо docker'ном. Никаких проблем нет так запускать любое.
     

  • 1.9, _йцукен (ok), 13:54, 12/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    переписан на го 1,4 ? =)
     
  • 1.27, бедный буратино (ok), 01:35, 16/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    хоть бы один коммент по docker :) ну, раз все прошли мимо - и я пройду :)
     

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



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

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