Анонсирован (http://blog.docker.com/2014/06/its-here-docker-1-0/) первый стабильный релиз инструментария для управления изолированными Linux-контейнерами Docker 1.0 (http://www.docker.io/), который признан готовым для создания промышленных решений. C первого тестового выпуска Docker, представленного (https://www.opennet.ru/opennews/art.shtml?num=36532) в марте прошлого года, внесено 8741 изменений, к разработке подключилось 460 участников, создано более 14 тысяч профилей изоляции приложений. За прошедшие 15 месяцев поект достиг зрелости, набрал необходимый уровень возможностей, обеспечил соблюдение обратной совместимости, стабилизировал API и подготовил ряд сервисов для сопровождения решений на основе Docker.
Одновременно представлена (http://blog.docker.com/2014/06/announcing-docker-hub-and-off.../) новая открытая платформа для распространения приложений. Таким образом, отныне Docker выступает в роли платформы, в состав которой входят: движок Docker Engine, runtime контейнеров, инструментарий для создания пакетов, API и облачный сервис Docker Hub. Кроме того, введены в строй официальные репозитории приложений, из которых можно загрузить готовые образы окружений для запуска популярных приложений, таких как MongoDB, MySQL, Nginx, Redis и WordPress.
<center><a href="http://blog.docker.com/wp-content/uploads/2014/06/platform.g... src="https://www.opennet.ru/opennews/pics_base/0_1402335003.gif" style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
Docker Hub представляет собой облачный сервис для организации совместной работы, автоматизации рабочего процесса, создания, распространения и запуска адаптированных для Docker приложений. По сути Docker Hub предоставляет набор сервисов, таких как распространение образа контейнера, управление изменениями, организация взаимодействия между пользователями и разработчиками, сопровождение жизненного цикла, интеграция со сторонними службами. Модель монетизации сервиса Docker Hub аналогична GitHub - работа в над публичными проектами бесплатна, а плата берётся только при необходимости использования приватных репозиториев.
<center><a href="http://blog.docker.com/wp-content/uploads/2014/06/build_ship... src="https://www.opennet.ru/opennews/pics_base/0_1402335047.gif" style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
Docker предоставляет высокоуровневый API, позволяющий манипулировать контейнерами на уровне изоляции отдельных процессов. В частности, Docker позволяет не заботясь о формировании начинки контейнера запускать произвольные процессы в режиме изоляции и затем переносить и клонировать сформированные для данных процессов контейнеры на другие серверы, беря на себя всю работу по созданию, обслуживанию и сопровождению контейнеров. Код Docker написан на языке Go и распространяется (https://github.com/dotcloud/docker/) под лицензией Apache 2.0.Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Для создания контейнеров могут использоваться libcontainer (обёртка над namespaces и cgroups), lxc (http://lxc.sourceforge.net/), libvirt, systemd-nspawn и т.п. Для формирования контейнера достаточно загрузить базовый образ окружения (docker pull base), после чего можно запускать в изолированных окружениях произвольные приложения (например, для запуска bash можно выполнить "docker run -i -t base /bin/bash").
По функциональности выпуск 1.0 полностью аналогичен версии 0.12 (https://www.opennet.ru/opennews/art.shtml?num=39954), выпущенной два дня назад. По сравнению в версией 0.11 добавлен драйвер хранения для ФС XFS, обеспечена поддержка директивы "COPY" для копирования файла внутрь контейнера без разархивирования, реализованы команды "pause" и "unpause" для приостановки и возобновления работы контейнера при помощи cgroup freezer, при выполнении директивы "ADD" обеспечено наследование прав доступа к файлам, улучшены средства ограничения доступа к устройствам и задействованы capabilities в Linux. Организация IANA официально закрепила за Docker сетевой порт 2375 для доступа к API через HTTP и 2376 через HTTPS.
Основные возможности 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.com/2014/06/its-here-docker-1-0/
Новость: https://www.opennet.ru/opennews/art.shtml?num=39965
Объясните по простому, зачем они нужен?
это абстракция над lxc
Другой вариант ответа зачем это надо - люди деньги зарабатывают. Монетизация хоть и неявная, но в проекте присутсвует - релизы идут все чаще и чаще, каждую неделю уже, значит все нормально у парней с доходом.
> Другой вариант ответа зачем это надо - люди деньги зарабатывают. Монетизация хоть
> и неявная, но в проекте присутсвует - релизы идут все чаще
> и чаще, каждую неделю уже, значит все нормально у парней с
> доходом.Нихр.на это не значит. Пока ты не увидишь бухгалтерские документы. И даже тогда ты можешь ошибиться.
Если совсем коротко - в прекрасном новом мире считается что зависимости между пакетами это очень сложно. К тому же сисадминов брать негде. Docker маркетится как серебряная пуля, позволяющая эти проблемы решить.
ну почему же, просто люди ставят например весь lamp в контейнеры и изолируют приложения друг от друга, контролируют ресурсы. Это не просто замена пакетов, а хрень для деплоя и управления контейнерами, ее много где можно применить с толком.
Контроль ресурсов в списке "зачем людям Docker" если и есть, то месте на последнем примерно.Вот взгляд типичного Docker-пользователя:
>In order to better understand Docker you have to understand the problem it is trying to solve.
>Modern day development (I’ll be focusing on the web here) lives in a world of lots of complexity. In even the most basic application you are likely to have a back-end language that lives on the server, a front-end language (almost ubiquitously JavaScript) that lives on the client, third-party and in-house libraries for both of these languages to manage, a database, an operating system (often deploying to Linux but developing on God-knows-what OS), and more. And this is for a basic app! What if you have utility programs that are written in another language? What if you have other weird dependencies and requirements?
>My point is that this all adds up to a lot of complexity, and worst of all- it is complexity that you have to manage across multiple platforms. If I got an app up and running on my Macbook, and wanted to deploy to Linux, my options were not great. If you’ve ever administrated your own VPS, much less a bare metal server, you know what I mean. Having to install all of the packages and dependencies that you have in a totally different way is a recipe for headaches and tears. Getting stuff to production is a completely different ball game from writing it in the first place. Different technologies on different platforms create a “Matrix from Hell” (pictured above) that makes even the most courageous ops person want to set her hair on fire.
>Traditionally there have been a variety of solutions that have popped up in response to this, ranging from “just develop in PHP and FTP is your deploy” (ew) to Heroku (git push heroku master is your deploy) to virtualization with provisioning (see Vagrant). Vagrant in particular has been gaining a lot of steam lately, for very good reason, and is a great technology (see my post on how we won Startup Weekend if you’re curious why Vagrant was useful to us in that case). However, virtual machines have several disadvantages as well. Because the VM software has to simulate actual physical hardware, you take a big performance hit. They are slow to start up and, especially before Vagrant started to become popular, difficult to get inexperienced developers started on (Download Vagrant and its dependencies and run vagrant up is a lot nicer than going through all of the VirtualBox menus, then provisioning your box manually).
> Контроль ресурсов в списке "зачем людям Docker" если и есть, то месте на последнем примерно.Нуу... Не знаю, я например использую, особо в отношении памяти и проца. Не то что бы это на первом месте, ведь можно то же сделать в cgroups, но всё-таки - удобно использовать всё это в комплекте который "сам всё упакует как надо".
У вас очень полезные применения расписаны ниже, но и очень нестандартные, относительно основной массы пользователей.
> У вас очень полезные применения расписаны ниже, но и очень нестандартные, относительно
> основной массы пользователей.Возможно, я не занимался изучением чужих интересов к Docker, и уж точно не отрицаю возможностей их существования :) Только лишь указываю что "есть и такой взгляд на вещи".
Мне важно то, что Docker позволяет делать это максимально удобным и наименее затратным образом (буквально несколько команд включая команды уже "внутри контейнера") с минимальным отрывом от "основного производства". Да ещё и денег за это не просит! :-)
Пуля, пуля.>After talking with thousands of companies over the past year, the one thing that shines through is that everyone has a different opinion/mechanism/interest in implementing Docker, from increasing developer efficiency to being the core piece of technology of their scheduler/hyper scale dream infrastructure.
>The power in Docker lies in the promise that it can solve a lot of the problems across that spectrum.
> маркетится как серебряная пуля, позволяющая эти проблемы решить.Ну а что, не так уж врут: пока ты будешь поднимать 20 железных серверов, рак на горе задолбается свистеть. А нарезать 20 виртуалок и распихать в них все сможет и 1 системный администратор, особенно с автоматизацией всего этого.
>А нарезать 20 виртуалок и распихать в них все сможет и 1 системный администратор, особенно с автоматизацией всего этого.а зачем Docker?
Для поднятия 20 железных серверов есть: chef и рак не свистит
>> маркетится как серебряная пуля, позволяющая эти проблемы решить.
> Ну а что, не так уж врут: пока ты будешь поднимать 20
> железных серверов, рак на горе задолбается свистеть. А нарезать 20 виртуалок
> и распихать в них все сможет и 1 системный администратор, особенно
> с автоматизацией всего этого.Ай, что ты, вихрь! А как насчет кастомных серверов? Или ты пытаешься убедить тут всех, что ставятся системы из коробки, с DHCP и всякой включенной по дефолту лабуденью?
Может быть, ты считаешь, что в виртуалках это как-то быстрее делается? У меня для тебя стрёмные новости, чувак - ты в жизни не видал 20 серверов и ты админ локалхоста.
На локалхосте ты хоть др.чить вприсядку можешь. Но IRL все совершенно иначе.
"Или ты пытаешься убедить, кастомные сервера, IRL, др.чить вприсядку, все совершенно иначе"Тебя на ксакепе забанили, да?
Лично я например использую для:
* Запуска всякой неведомой фигни которая чёрт знает что потянет за собой и вообще ХЗ как может работать.
* Сборки/установки приложений со специфическими требованиями.
* Изоляции всякого УГ типа скайпа и жабных приложений, когда его таки приходится запускать.
* Сборки чистых пакетов под ОС с другой пакетной системой. Например под Debian собираю rpm'ки для CentOS. На днях с этим вообще забавно получилось - в "натуральном CentOS" не мог собраться пакет т.к. насована куча репозиториев и образуются битые зависимости, зато поставил в Docker'е под Debian'ом базовую чистую систему за 5 минут буквально (с инета качалось), доставил необходимые пакеты для сборки и всё собралось на ура.А слова про "мало админов/зависимости - плохо и сложно", ну наверное они тоже имеют вес. Но это кому как.
>[оверквотинг удален]
> * Изоляции всякого УГ типа скайпа и жабных приложений, когда его таки
> приходится запускать.
> * Сборки чистых пакетов под ОС с другой пакетной системой. Например под
> Debian собираю rpm'ки для CentOS. На днях с этим вообще забавно
> получилось - в "натуральном CentOS" не мог собраться пакет т.к. насована
> куча репозиториев и образуются битые зависимости, зато поставил в Docker'е под
> Debian'ом базовую чистую систему за 5 минут буквально (с инета качалось),
> доставил необходимые пакеты для сборки и всё собралось на ура.
> А слова про "мало админов/зависимости - плохо и сложно", ну наверное они
> тоже имеют вес. Но это кому как.Собирать пакеты надо обязательно в чистом окружении, а не в мусорке с непонятно-какими пакетами.
> Собирать пакеты надо обязательно в чистом окружении, а не в мусорке с
> непонятно-какими пакетами.Не убязательно. Это зависит. У RH второй способ = часть бизнес-модели.
>> Собирать пакеты надо обязательно в чистом окружении, а не в мусорке с
>> непонятно-какими пакетами.
> Не убязательно. Это зависит. У RH второй способ = часть бизнес-модели.Где вы нашли информацию как RH собирает RHEL?
>> Не убязательно. Это зависит. У RH второй способ = часть бизнес-модели.
> Где вы нашли информацию как RH собирает RHEL?Именно!
"виртуализация для чайникой". эдакий "EMC для неосиляторов", примерное.
для тех кто давно из анабиоза - есть и получше вещи.
Не поведаете какие?
> Объясните по простому, зачем они нужен?Рулить относительно большими стадами виртуалок в духе энтерпрайзов.
Честно говоря я бы пока не решился. Именно что бы "стадами виртуалок" гонять, как минимум исходя из граблей с невозможностью шейпить скорость записи на диск внутри контейнера. Что в свою очередь есть ограничение даже не Docker'а а cgroups, т.е. внешний подключаемый том (через опцию -v) вас в этом случае тоже совсем не спасёт.
> Рулить относительно большими стадами виртуалок в духе энтерпрайзов.С точки зрения "рулить" надо говорить про OpenStack, решения от Citrix (на базе Xen), и VmWare.
Технологии типа контейнеров находятся одним уровнем абстракции ниже.Хотя Docker-бойцы и пытаются взобраться на этот один уровень абстракции выше ("мы не только на контейнерах могём, мы на чём хошь (KVM, Xen) и поверх чего хошь (device mapper, BTRFS), и у нас даже есть веб-интерфейс"), я бы оценил их потуги как несбыточные.
Откровенный бред. Разберитесь уже где "ниже" у вас где "выше", и кто куда карабкается.
Разрабатывать приложения в практически staging environment прямо на девелоперской тачке.
Для этого Docker ничем принципиально не лучше VM.
С точки зрения идиота - да.
И с точки зрения затычки каждой бочки - тоже.
Вы, конечно же, имели ввиду "для этого Docker принципиально всем лучше VM"
Я сразу заметил опечатку.
Ведь очевидно, что докер _не_ эмулирует целую машину с кучей железа, поверх которой работает операционная система и всё ради какого-то одного сервиса/приложения, в отличии от VM.
Вы действительно прямо кожей чувствуете этот оверхед?
Или девелоперские машинки это теперь Macbook Air с 2GB RAM, где лишняя VM кого-то напрягает?
Если есть возможность использовать VM то оно не нужно.
> Если есть возможность использовать VM то оно не нужно.Запуск, остановка, клонирование, заморозка контейнера занимает не более 0,01 секунды.
Плюс у контейнеров нет потери производительности.
chroot?
>Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups).
>>chroot?80-тые атакуе? А с тем что из chroot-а приложение может легко выйти или неограниченно потреблять ресурсы вы как собрались бороться?
>>Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups).
>>>chroot?
> 80-тые атакуе? А с тем что из chroot-а приложение может легко выйти
> или неограниченно потреблять ресурсы вы как собрались бороться?легко? hardened вам в помощь =)
Больше костылей богу костылей?
Как насчет сетевой подстистемы? А есди мне нужно другое ядро линукс?
А cмогу я для chroot-ованной прогруммы выполнить #init 1 ?
cgroups. А что, уже придумали что-то лучше?
libguestfs
Прекрасно показывает убогость традиционных unix прав, разграничений доступа и пакетных менеджеров.
Лови плюс!
ждем рассказ про не убогую систему прав и пакетные менеджеры
> Прекрасно показывает убогость традиционных unix прав, разграничений доступа и пакетных
> менеджеров.Для убогость для решения каких задач?
>Currently, you'll need to be at very large scale before the benefits of using Docker outweigh the added complexity it adds to your systems.
>https://devopsu.com/blog/docker-misconceptions/А я думал это В. Ульянов(Ленин) сказал.
>>Currently, you'll need to be at very large scale before the benefits of using Docker outweigh the added complexity it adds to your systems.
> https://devopsu.com/blog/docker-misconceptions/Не осилили? Ну, бывает.
А в чем профит по сравнению с обычным LXC?
> А в чем профит по сравнению с обычным LXC?docker pull centos:6.4
docker -t -i run centos:6.4 /bin/bash
lxc-create -t centos6.4 -n centos64test
lxc-start -n centos64test
lxc-console -n centos64test, ввести логин и пароль, либо если есть работающий днс - зайти по имени сразу по ssh, если в шаблон положить еще и ssh-ключик - еще и автоматом зайдет.
А словами рассказать кратко? Вот docker pull centos:6.4 что делает? Скачивает откуда-то из интернета неведомый образ диска с неведомо чем или устанавливает centos с нуля из официальных репозиториев centos?
> А словами рассказать кратко? Вот docker pull centos:6.4 что делает? Скачивает откуда-то
> из интернета неведомый образ диска с неведомо чем или устанавливает centos
> с нуля из официальных репозиториев centos?Да.
@LTS1404:~$ docker.io -v
Docker version 0.9.1, build 3600720Вот пока убунта не обновится, не продакшен ни фига.
>The thing people want in the real world is improved workflow.
>In the real world, everyone wants infrastructure to have the same sexy qualities: automated deployment (CD/CI), automated scaling, automated failover/high availability, automated service discovery (read: functional service topology dependency resolution), security, resource and capacity planning support, real time least-cost-overhead provider selection for third party infrastructure providers meeting some disparate set of performance requirements, etc. Unfortunately, it's not an easy problem area to deliver a one size fits all solution to.
>Docker doesn't really have most of that stuff in scope yet, even vaguely. Actually, it seems to have a really weird scope: it wants to wrap different LXC implementations and other container-style unix environments (potentially supporting non-Linux platforms) but doesn't want to deal with managing the host systems themselves, having - kind of, for practical reasons (though not entirely!) - outsourced this to CoreOS (ie. some particularly specific configuration of a Linux host system).
>Whether all of this recent Redhat/Google docker bandwagon jumping will amount to any real solution remains to be seen .. Google AFAIK effectively runs its services on fat clusters made of commodity hardware, organized in to segments ('cells'), running highly customised Linux distributions, and so does Redhat where HA is required. I'm pretty familiar with these configurations as I do this myself. So will we ever see meaningful support for other OSs? Other distros? Physical systems via PXE to support these clusters? Hypervisor guests managed with the same developer and operations workflow?
>My wager is not soon, at least in a manner that everyone agrees on... Google will keep doing its thing (using its unlimited supply of internal, world-class nerds to deliver and manage services on their custom OS in a custom way because saving 1/2c a month per machine pays ten world class nerd salaries at their scale), Redhat will keep doing its thing (selling prebuilt systems at expensive prices that still comfortably undercut the likes of IBM, pretending they are manageable, but actually rejigging the whole infrastructure every system release leaving little in the way of realistic upgrade paths without expensive consulting) and you and I will be left wondering where that magical docker solution went that everyone was talking about in early 2014.
Самое интересное решение из области виртуализации за последние годы. И самое перспективное. Хотя если нужно всего пару однотипных контейнеров, за глаза хватит чистого lxc.
> Самое интересное решение из области виртуализации за последние годы. И самое перспективное.
> Хотя если нужно всего пару однотипных контейнеров, за глаза хватит
> чистого lxc.Перспективности больше чем практической пользы. Для двух виртуалок и vbox'a хватает уже кучу лет, а если это песочница, то и чрута.
> Хотя если нужно всего пару однотипных контейнеров, за глаза хватит чистого lxc.вы точно поняли зачем нужен сабж?
