Представлен (https://blog.docker.com/2015/08/docker-1-8-content-trust-too.../) релиз инструментария для управления изолированными Linux-контейнерами Docker 1.8 (http://www.docker.com/), предоставляющего высокоуровневый API для манипуляции контейнерами на уровне изоляции отдельных приложений. В частности, Docker позволяет, не заботясь о формировании начинки контейнера, запускать произвольные процессы в режиме изоляции и затем переносить и клонировать сформированные для данных процессов контейнеры на другие серверы, беря на себя всю работу по созданию, обслуживанию и сопровождению контейнеров. Код Docker написан на языке Go и распространяется (https://github.com/dotcloud/docker/) под лицензией Apache 2.0.
Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Для создания контейнеров предлагается использовать libcontainer (обёртка над namespaces и cgroups), также возможно применение lxc (http://lxc.sourceforge.net/), libvirt (http://libvirt.org/), systemd-nspawn, OpenVZ контейнеров с помощью библиотеки LibCT (https://openvz.org/LibCT) и других систем изоляции. Для формирования контейнера достаточно загрузить базовый образ окружения (docker pull base), после чего можно запускать в изолированных окружениях произвольные приложения (например, для запуска bash можно выполнить "docker run -i -t base /bin/bash").Из добавленных в Docker 1.8 новшеств (https://github.com/docker/docker/blob/master/CHANGELOG.md) можно отметить:
- <a href="https://blog.docker.com/2015/08/content-trust-docker-1-8/&qu...Функциональность/a> Docker Content Trust для проверки достоверности образа контейнера по цифровой подписи, позволяет удостовериться, что образ размещён в репозитории заявленным издателем. Для верификации используется система открытых ключей, при которой образ подписывается закрытым ключом издателя, а затем может быть проверен при помощи публично доступного открытого ключа. Для публикации, верификации и безопасного обновления образов в Docker интегрирован инструментарий Notary (https://github.com/docker/notary), основанный, в свою очередь, на фреймворке The Update Framework (http://theupdateframework.com/) (TUF). Проверка осуществляется автоматически при выполнении типовых команд, таких как docker pull, docker push, docker build, docker create и docker run;
- Представлен Docker Toolbox (https://blog.docker.com/2015/08/docker-toolbox/), cпециализированный инсталлятор для Windows и OS X, упрощающий развёртывание и запуск окружения разработчика Docker.
Docker Toolbox позиционируется как замена Boot2Docker и включает клиентское ПО для Docker, компоненты Machine и Compose, а также систему виртуализации VirtualBox;- В разряд стабильных переведена добавленная в прошлом выпуске экспериментальная система для подключения плагинов, выполняемых в форме отдельных процессов-обрабочиков. В разряд стабильный также переведены плагины для организации хранилищ, например, позволяющие работать с сетевыми хранилищами, такими как Flocker, Blockbridge, Ceph, ClusterHQ, EMС и Portworx;
- Система драйверов для ведения логов, позволяющих реализовать различные схемы сохранения системного журнала, в том числе передачи логов контейнера на внешний syslog-сервер, расширена возможностью передачи логов в системы Graylog (https://www.graylog.org/centralize-your-docker-container-log.../) и Fluentd (http://blog.treasuredata.com/blog/2015/08/03/5-use-cases-doc.../). Добавлен драйвер для организации ротации логов на диске;
- Команда "docker cp" теперь может применяться не только для копирования файлов из контейнера на хост-систему, но и наоборот. Например, "docker cp foo.txt mycontainer:/foo.txt";
- Для запуска демона Docker представлена новая команда "docker daemon", которую следует использовать вместо опции "-d". Новая команда позволяет явно разделить клиентские опции (docker --help) и опции демона (docker daemon --help);
- Возможность настройки формата вывода команды "docker ps" через указание опции "--format";
- Поддержка настройки директории с файлами конфигурации клиента через указание пути в опции --config или переменной окружения DOCKER_CONFIG, что даёт возможность запустить разные экземпляры docker с разными наборами конфигурации;- Выпуск инструмента Machine 0.4 (http://github.com/docker/machine), предназначенного для быстрого развёртывание хостов в гостевых окружениях систем виртуализации VirtualBox, VMware, AWS, Digital Ocean и Microsoft Azure. Осуществляет создание начинки сервера, установку на него Docker и настройку клиента для работы с данным сервером. В новой версии добавлены (https://github.com/docker/machine/blob/master/CHANGELOG.md#0...) стредства настройки движка для использования http-прокси;
- Выпуск инструмента Swarm 0.4 (https://github.com/docker/swarm/), предоставляющего средства кластеризации для упакованных в контейнеры приложений. Swar даёт возможность управлять кластером из нескольких хостов Docker (например, созданных с использованием Docker Machine) в форме работы с одним виртуальным хостом. Так как Swarm использует штатный Docker API, он может применяться для управления и другими поддерживающими данный API инструментами, такими как dokku, fig, krane, flynn, deis, docker-ui, shipyard, drone.io, Jenkins. В новой версии (https://github.com/docker/swarm/releases/tag/v0.4.0) улучшена реализация встроенного планировщика и драйвера для интеграции с Mesos (теперь можно использовать инструменты docker для управления кластером Mesos);- Выпуск инструмента Docker Compose 1.4 (https://github.com/docker/docker/issues/9459), позволяющего организовать работу распределённого на несколько хостов приложения, в работу которого вовлечено несколько контейнеров, запущенных в кластере на базе Docker Swarm. В новой версии значительно увеличена скорость запуска и остановки приложений, пересоздание контейнера производится только при необходимости, обеспечено параллельное выполнение работ. Добавлена возможность назначения произвольных имён контейнерам и поддержка чтения конфигурации из стандартного ввода (можно генерировать файл конфигурации на лету);
Дополнительно можно отметить анонс (https://blog.xenproject.org/2015/07/20/new-hyper-open-source.../) проекта Hyper (https://github.com/hyperhq/hyper) (Hypervisor-agnostic Docker Engine), предоставляющего средства для запуска образов контейнеров Docker с использованием полноценных средств виртуализации, в частности, виртуальных машин Xen, KVM и VirtualBox. Hyper даёт возможность добиться более высокого уровня изоляции и безопасности, сохранив при этом такие достоинства систем контейнерной изоляции, как удобство работы, высокую скорость запуска, высокую производительность, небольшой размер контейнера и переносимость.
Для управления контейнером продолжает использоваться инструментарий docker, дополненный утилитой hyper и демоном hyperd. В каждой виртуальной машине запускается урезанное ядро Linux (HyperKernel) и сервис инициализации HyperStart, который выполняет задачу загрузки образов контейнера в виртуальной машине (в каждой виртуальной машине можно запускаться несколько контейнеров), настройки их изоляции и запуска. Кроме HyperKernel и HyperStart в виртуальной машине не запускается никаких системных компонентов. Время загрузки контейнера составляет доли секунды, потребление памяти около 28 Мб ОЗУ на виртуальную машину.
<center><a href="https://trello-attachments.s3.amazonaws.com/554c998a4c9dacc5... src="http://www.opennet.me/opennews/pics_base/0_1439651623.png" style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>URL: https://blog.docker.com/2015/08/docker-1-8-content-trust-too.../
Новость: http://www.opennet.me/opennews/art.shtml?num=42800
Где взять мануал что бы с этим докером познакомится, типа Quick Start Guide без чтения огромной портянкипощупал, если понравилось, полез в дебри, а если нет, тогда просто забыл
http://www.linuxjournal.com/content/docker-lightweight-linux...
> http://www.linuxjournal.com/content/docker-lightweight-linux...Спасибо, но у меня с английским туговато, для просто ознакомится, читать столько текста с моими познаниями английского это долго будет
неужели на русском ничего нет, гуглил пару месяцев назад на тему Docker, не нашел к сожалению
http://rus-linux.net/MyLDP/vm/docker/docker-tutorial.html
> http://rus-linux.net/MyLDP/vm/docker/docker-tutorial.htmlБлагодарю, оно самое
так вы для начала мануал по Английскому изучите, полезно будет
Появление этого Hyper это признание дырявости докера?
Да! Docker не для стабильной и безопасной работы. Просто игрушка для тех, кто не хочет пользоваться systemd (да-да).
При чём здесь systemd?
systemd тут как красная тряпка.
> systemd тут как красная тряпка.Нет, systemd тут как systemd-nspawn! :)
> Да! Docker не для стабильной и безопасной работы. Просто игрушка для
> тех, кто не хочет пользоваться systemd (да-да).Поддерживаю! Хотя мне до недавнего времени очень не нравился systemd как система инициализации, но сейчас работаю в конторе, где systemd-nspawn контайнеры используются в весьма серЪезных production-системах. Вынужден был изменить свое мнение, поскольку systemd-nspawn - это действительно вещь!
Я удивлён.
Думал, что systemd - система инициализации с бинарными логами.Какое отношение к этому имеют контейнеры?
systemd - аналог docker?
> Я удивлён.
> Думал, что systemd - система инициализации с бинарными логами.
> Какое отношение к этому имеют контейнеры?
> systemd - аналог docker?Практически - да!
>> Я удивлён.
>> Думал, что systemd - система инициализации с бинарными логами.
>> Какое отношение к этому имеют контейнеры?
>> systemd - аналог docker?
> Практически - да!Точнее - и то, и другое, и еще много чего!.. :)
В отличие от Докера контейнеры от системды имеют меньший оверхед и лучшую стабильность.
У нас они массово используются в продакшине и неплохо себя зарекомендовали.
А чем проще начинку контейнера создать без усложнений и запуска лишних демонов? Что бы потом как контейнер c LXC или systemd-nspawn использовать?Нужно пару web-служб изолировать в RHEL 7, Docker для этого излишне нагромождён. Вручную не хочется каждый раз ковыряться и обновления накатывать. Хотелось бы как-то автоматизировать поддержание в актуальном виде начинки контейнера без засовывания вовнутрь полноценного дистрибутива.
>Нужно пару web-служб изолировать в RHEL 7, Docker для этого излишне нагромождён. Вручную не хочется каждый раз ковыряться и обновления накатывать. Хотелось бы как-то автоматизировать поддержание в актуальном виде начинки контейнера без засовывания вовнутрь полноценного дистрибутива."Хочу есть. Но не ртом."
Ситуация сейчас такова, что либо ставить Docker и получить кучу лишнего с весящим демоном управления, либо делать контейнер как срез полного дистрибутива (т.е. тянуть туда yum для обновлений и т.п.). А хочется, чтобы как в docker создать минимальное окружение для запуска приложения и не получить гемороя при обновлении всего этого хозяйства.
> в docker создать минимальное окружение для запуска приложения и не получить
> гемороя при обновлении всего этого хозяйства.Очень зависит от того что имеется в виду под "минимальным окружением". Технически, контейнерам пофиг что пинать внутри. Запустите /bin/bash - получите отрезанный от остальной системы шелл (степень отрезки - настраивается). А запустите /sbin/init - запустится некая копия системы с указанного пути. Просто потому что init отпедалит стартовую последовательность системы и запустит иерархию процессов. Эта иерархие процессов при должной изоляции будет похожа на отдельную ОС. Скажем если clone() сказали CLONE_NEWNET - там будет новый сетевой namespace. Ну то-есть настройки сети отличные от хоста, даже localhost там будет свой. Более подробно как линух вообще это умеет - расписано в man clone (системный вызов такой).
А системд умеет некую отрезку в контейнеры и жонглирования путями даже и без systemd.nspawn-а.
Selinux- не?
> Selinux- не?Это совсем из другой оперы.
> Это совсем из другой оперы.Однако можно сделать картину "фантомас в очках на аэроплане" - в мануале системд есть кроме всего прочего и пример запуска контейнера с отдельным контекстом SELinux. Командлайн там конечно не совсем тривиальный, но в SELinux так вообще везде и те кто им пользуется - должны были бы уже привыкнуть :).
> А чем проще начинку контейнера создать без усложнений и запуска лишних демонов?Debootstrap'ом, если это дебиан-подобные. Ну или как оно там у вас в рхел называется. Если надо "полную систему" и чтобы независимой от хост-системы была. Или просто пнуть программу systemd-nspawn'ом, если полная независимость от окружения хоста не требуется.
> Что бы потом как контейнер c LXC или systemd-nspawn использовать?
Почитать man на системд уже наконец. В man systemd-nspawn показано штук пять вариантов такого плана в конце.
> Вручную не хочется каждый раз ковыряться и обновления накатывать.
Что логично.
> без засовывания вовнутрь полноценного дистрибутива.
Вариантов бывает несколько:
1) Забацать минимальный, урезанный вариант дистра в энной иерархии и запускать в контейнере его /sbin/init (systemd, кстати, умеет иерархическую дружбу systemd между собой). При этом будет независимая копия окружения. А апдейтить - хоть пакетным менеджером, хоть по cron-у (или systemd.timer'у). Рулить .. как копией ОС в VM. Если кто привык вертеть 100 машинами, он в этом месте может считать что машин стало 101.2) Можно запустить таки только свою программу, в текущем окружении, с степенью заапдейчености равной обновленности текущей системе. Но вот если вы захотите кардинально обрубить из контейнера весь доступ к ФС хоста - вас ждут некие неприятные открытия, сто лет известные тем кто делал chroot. Ну там например когда прога попробует в середине пьесы загрузить shared lib и вдруг ВНЕЗАПНО заметит что этой либы и близко нет. Можно конечно замаунтить часть ФС хоста, но это уже компромисс по уровню изоляции - контейнер будет видеть часть иерархии и сможет ее изучать.
3) Можно сделать ход конем и внаглую запустить копию своей системы которая уже есть в контейнере, ничего никуда не копируя вообще. Вот только будет не очень здорово если два инстанса системы будут на пару использовать одинаковые файлы. В мане системды показали вариант как это разрулить с эфемерным снапшотом btrfs, когда система стартует с той же иерархии, а все отличия от хоста - пишутся в временный снапшот btrfs (который при остановке системы будет снесен). Но я не знаю прокатит ли такой финт ушами в рхел7. При таком финте ушами инстанс системы в хосте и гуесте развязаны друг от друга btrfs - контейнер получит систему в виде "как было на момент старта контейнера". Далее снапшот и мастер-копия живут своими жизнями, потому что CoW и множественный референс блоков (как только блоки станут разными - CoW отличия закопирует).
Юзай LXC и не парь мозг докером, он не предназначен для изолирования чего либо, докер предназначен для распространения, это как пакет с набором софта.
Мы используем LXC и "полноценные системы". Просто образ "полноценной системы" заранее подготовлен и цепляется в новоиспекаемый контейнер с помощью AUFS/OverlayFS.
Поделитесь описанием мануалом для настройки вашей связки.
sandbox
> А чем проще начинку контейнера создать без усложнений и запуска лишних демонов?man lxc-create
> А чем проще начинку контейнера создать без усложнений и запуска лишних демонов?
> Что бы потом как контейнер c LXC или systemd-nspawn использовать?
> Нужно пару web-служб изолировать в RHEL 7, Docker для этого излишне нагромождён.
> Вручную не хочется каждый раз ковыряться и обновления накатывать. Хотелось бы
> как-то автоматизировать поддержание в актуальном виде начинки контейнера без засовывания
> вовнутрь полноценного дистрибутива.Откройте для себя Configuration Management!.. :)
Когда вы перестанете в инструкциях по установке пайпать скрипты из интернета в шэлл?!
> Когда вы перестанете в инструкциях по установке пайпать скрипты из интернета в шэлл?!Когда им кто-нибудь rm -rf / сделает уже наконец, перехзватив домен или просто hijack-нув DNS.
А можна например запустить программу не в контейнере и упаковать в контейнер с помощью docker? Нигде не нашел внятного пояснения что там в этом контенере вообще содержится, ядро туда тоже запихивают для совместимости или это по функциональности то же самое что и программы для оффтопика?
Дайте решение для изолирования скайпа с целью обеспечения безопасности ( что бы по соседним процессам и фс не шарился), пожалуйста. Докер подходит?
Ну, обезопасить себя от сюрпризов skype можно гораздо проще - с помощью firejail.
sandbox
man apparmor
https://hub.docker.com/r/tomparys/skype/
which skype | sudo xargs rm -f...единственный надёжный способ.
