Docker: Легковесные контейнеры Linux для согласованной разработки и развертывания проектов

Оригинал: Docker: Lightweight Linux Containers for Consistent Development and Deployment
Автор: Dirk Merkel
Дата публикации: May 19, 2014
Перевод: Н.Ромоданов
Дата перевода: январь 2015 г.

Справьтесь с «адом зависимостей» с помощью контейнеров Docker, легким и юрким родственником виртуальных машин. Узнайте, как Docker позволяет делать приложения переносимыми за счет упаковки их в контейнеры, использующих технологию LXC.

Представьте себе, что есть возможность достаточно просто упаковать приложения вместе со всеми его зависимостями, а затем продолжить их разработку, тестирование и регулярное использование в совершенно другой среде. В этом и состоит назначение проекта Docker, имеющего открытый исходный код. Хотя он по-прежнему официально не готов к полноценному использованию, последняя версия (0.7.x на момент написания этой статьи) позволила Docker-у стать еще на шаг ближе к реализации этой амбициозной цели. Прим.пер.: На момент перевода данной статьи последней версий уже была версия с номером 1.4, а многочисленные разработчики уже в полной мере и с большим энтузиазмом пользовались проектом Docker в своих разработках.

Docker пытается решить проблему «ада зависимостей». Современные приложения часто собираются из уже существующих компонентов и полагаются на использование других служб и приложений. Например, ваше приложение, написанное на языке Python, может в качестве хранилища данных пользоваться базой данных PostgreSQL, пакетом Redis - для кэширования, а приложением Apache - в качестве веб-сервера. Каждый из этих компонентов поставляется с собственным набором зависимостей, которые могут вступать в конфликт с другими компонентами. Благодаря тому, что Docker позволяет упаковывать каждый компонент и его зависимости по-отдельности, решаются следующие задачи:

Docker: Немного предыстории

Docker начал свое существование в 2013 году как проект с открытым исходным кодом, разработанный облачной компанией dotCloud, предоставляющей в качестве сервиса платформы. Первоначально Docker был естественным продолжением технологии, которую компания разработала для запуска облачного бизнеса на тысячах серверов. Проект написан на языке Go, статически типизированном языке программирования, разработанном Google с синтаксисом на базе С. Прошло от шести и до девяти месяцев, и компания наняла нового генерального директора, присоединилась к фонду Linux Foundation, изменила свое название на Docker Inc., и анонсировала, что смещает свой интерес в сторону разработки проекта Docker и экосистемы Docker. В качестве еще одного свидетельства популярности проекта Docker является то, что пока писали проект, этот проект на GitHub был отмечен звездочками 8985 раз и было создано 1304 клона этого прпоекта. На рис.1 показан рост популярности Docker в поисковых запросах Google. Я могут предположить, что эта тенденция, наблюдавшаяся в прошедшие 12 месяцев, существенно не изменится в следующие 12 месяцев когда Docker Inc. предоставит на наш суд первую версию проекта, уже готовую для развертыванию контейнеров в производственных условиях, а сообщество в целом ознакомится с преимуществами проекта Docker.

Рис.1. Динамика роста в Google запросов "Docker Software" за последние 12 месяцев

Под капотом

Docker использует некоторые мощные технологии уровня ядра и передает нам возможность ими управлять. Концепция контейнера в области виртуализации рассматривалась в течение нескольких лет, но благодаря тому, что в проекте Docker для управления некоторыми технологиями на уровне ядра, например, контейнерами LXC (контейнеры Linux), группами управления cgroups и файловой системой вида copy-on-write (копирование при записи), был предложен простой набор инструментальных средств и единый интерфейс API, был создан инструмент, который стал больше, чем сумма его частей. В результате разработчикам-технологам (DevOps), системным администраторам и разработчикам приложений был предложен новый инструментарий, похожий на достаточно простую игру типа «найди и подставь».

В Docker предложены инструменты, которые делают создание контейнеров и работу с ними как можно проще. Контейнеры изолируют процессы друг от друга. В настоящее время вы можете рассматривать контейнер как легковесный эквивалент виртуальной машины.

Ядро Docker состоит из контейнеров Linux и LXC - пакета управления пользовательским пространством контейнеров Linux. LXC использует пространства имен уровня ядра для изоляции контейнера от хост-системы. Пользовательское пространство имен разделяет базу данных пользователя контейнера и пользователя хост-системы, тем самым обеспечивая, что администратор контейнера не имеет в хост-системе привилегий суперпользователя. Пространство имен процессов отвечает за отображение и управление только теми процессами, которые запущены в контейнере, а не в хост-системе. А с помощью пространства имен сети обеспечивается, что у контейнера есть свое собственное сетевое устройство и свой виртуальный IP-адрес.

Другим компонентом проекта Docker, который реализуется с помощью LXC, являются группы управления (cgroups). В то время как пространства имен используются для изоляции хост-системы от контейнеров, с помощью групп управления реализован учет ресурсов и дается возможность ограничивать их потребление. В Docker с помощью групп управления можно ограничивать ресурсы, потребляемые в контейнере, например, память, дисковое пространство и ресурсы ввода-вывода, а также получать множество значений, характеризующих потребление этих ресурсов. С их помощью в Docker можно отслеживать в контейнерах потребление ресурсов различными процессами и гарантировать, что каждый процесс получает только свою часть имеющихся ресурсов.

Кроме указанных выше компонентов в Docker в качестве файловой системы контейнеров используется система AuFS. AuFS является многоуровневой файловой системой, в которой может прозрачно пользоваться одной или несколькими уже имеющимися файловыми системами. Когда процессу требуется изменить файл, AuFS создает копию этого файла. AuFS позволяет объединять несколько уровней в единую файловую систему. Этот процесс называется копированием при записи.

Круто в действительности то, что AuFS в проекте Docker позволяет в качестве основы для разработки контейнеров использовать образы конкретных систем. Например, вы можете использовать образ CentOS Linux в качестве основы для разработки большого количества различных контейнеров. Благодаря использованию AuFS потребуется только одна копия образа CentOS, что ведет к экономии оперативной и дисковой памяти, а также ускоряет развертывание контейнеров.

ак дополнительный плюс от использования AuFS является возможность в Docker управлять версиями контейнерных образов. Каждая новая версия просто представляет собой набор отличий от предыдущей версии, благодаря чему необходимость хранения файлов образа сводится к минимуму. Но это также означает, что у вас всегда есть полный контроль над тем, что изменилось при переходе с одной версии контейнера к другой.

Обычно Docker-у нужна файловая система AuFS для реализации механизма хранения с копированием при записи. Но совсем последнее добавление API для драйвера работы с хранилищами данных, скорее всего, уменьшит эту зависимость. Благодаря сотрудничеству с Red Hat первоначально использовались следующие три драйвера работы с хранилищами данных: AuFS, VFS и Device-Mapper.

Начиная с версии 0.7, Docker работает во всех дистрибутивах Linux. Тем не менее, он не работает с большинством операционных систем, отличающихся от Linux, таких как Windows и OS X. Рекомендуемый способ использования Docker на этих операционных системах — это установка с помощью Vagrant виртуальной машины.

Сравниваем контейнеры с другими видами виртуализации

Итак, что же представляет собой контейнер и чем он отличается от виртуализации на основе гипервизоров? Если кратко, то контейнеры виртуализуются на уровне операционной системы, тогда как в гипервизорах используется виртуализация на аппаратном уровне. Несмотря на то, что эффекты от их использования схожи, различия важны и значительны, поэтому мы потратим некоторое время на изучение различий и оценку решений, обусловлавливаемых этими различиями.

Виртуализация:

Как контейнеры, так и виртуальные машины являются инструментальными средствами виртуализации. Когда используется виртуальная машина, то с помощью гипервизора осуществляется разделение ресурсов аппаратных средств. Есть два типа гипервизоров: "Тип 1" работает непосредственно на голом железе аппаратного обеспечения, в то время как "Тип 2" работает как дополнительный слой программного обеспечения в гостевой ОС. Такие виртуальные машины с открытым исходным кодом, как Xen и ESX VMware являются примерами гипервизоров типа 1; к числу машин типа 2 относятся следующие - VirtualBox фирмы Oracle, имеющий открытый исходный код, и VMware Server. Хотя для сравнения с контейнерами Docker лучше подходят виртуальные машины типа 1, мы в оставшейся части этой статьи не будем различать эти два типа гипервизоров.

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

Операционные системы и ресурсы:

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

Контейнеры размещаются в уже работающей операционной системе, которую они рассматривают как свою хост-среду. Они просто выполняются в отдельных пространствах, изолированных друг от друга и от некоторых частей ОС. В этом есть два существенных преимущества. Во-первых, ресурсы используются гораздо эффективнее. Если контейнер ничего не делает, то он не использует ресурсы, и контейнеры могут обращаться к своей хостовой ОС для разрешения некоторых или всех своих зависимостей. Во-вторых, затраты на поддержку контейнеров небольшие и поэтому их можно быстро создавать и уничтожать. Нет необходимости загружать или останавливать всю ОС. Вместо этого, контейнер просто должен завершить все процессы, выполняемые в его изолированном пространстве. Поэтому запуск и остановка контейнер больше похожа на запуск и остановку приложений и выполняется столь же быстро.

На рис.2 показаны оба типа виртуализации и контейнеры.

Рис.2: Сравниваем виртуальный машины и контейнеры

Изоляция для улучшения производительности и повышения безопасности:

Процессы, исполняемые в контейнере Docker, изолированы от процессов, запущенных на хостовой ОС или в других контейнерах Docker. Тем не менее, все процессы выполняются в том же самом ядре. Docker для того, чтобы обеспечить разделение пространств имен контейнеров, использует LXC, технологию, которая присутствует в ядрах Linux более пяти лет и считается довольно зрелой. Для аудита и ограничений ресурсов, он также пользуется группами управлений, которые присутствуют в ядре Linux гораздо дольше.

Сам демон Docker создает потенциальную угрозу атаки, поскольку он в настоящее время работает с привилегиями суперпользователя. Дальнейшая разработка как LXC, так и Docker, должна позволять контейнерам работать без привилегий суперпользователя и запускать демон Docker не под пользователем root.

Хотя тип изоляции, предоставленный в целом, довольно строгий, он, определенно, не настолько строг, как изоляция, которую можно обеспечить при помощи виртуальных машин на уровне гипервизора. Если ядро падает, то также падают и все контейнеры. Другая область, где у виртуальных машин есть преимущество, это их зрелость и широкое внедрение в производственной среде. Виртуальные машины достаточно опробованы и хорошо зарекомендовали себя в различных средах с высокой степенью готовности доступа. Docker и поддерживающие его технологии не прошли такое количество испытаний. Docker, в частности, каждый день подвергается значительным изменениям, а мы все знаем, что изменения - враг безопасности.

Docker и виртуальные машины — неизбежные друзья:

Теперь, когда мы затратили определенное время на сравнение Docker и виртуальных машин, пришло время признать, что эти две технологии могут, на самом деле, дополнять друг друга. Docker отлично работает в уже виртуализированных средах. Вы, очевидно, не захотите затрачивать ресурсы на инкапсуляцию каждого приложения или компонента в отдельной виртуальной машине, но, если уже есть виртуальная машина Linux, вы можете легко развернуть в ней контейнеры Docker. Именно поэтому не должно быть сюрпризом то, что официально поддерживаемый способ использования Docker на системах, которые не являются системами Linux, например, в OS X и в Windows, представляет собой установку Ubuntu (Precise64) с помощью Vagrant виртуальной машины. На сайте http://www.docker.io приведены простые и подробные инструкции.

Суть в том, что виртуализация и контейнеры проявляют некоторые сходства. Поэтому первоначально возникает мысль рассматривать контейнеры как очень легковесный вариант виртуализации. Но, по мере того, как вы все больше работаете с контейнерами, вы приходите к пониманию тонких, но важных различий. Docker позволяет очень хорошо пользоваться преимуществами контейнеризации для выполнения конкретной цели, а именно легко упаковывать и развертывать приложения.

Репозитории Docker

Одной из ключевой особенностей Docker является возможность быстро находить, скачивать и запускать образы контейнеров, которые были созданы другими разработчиками. Место, где хранятся образы, называется реестром, и компания Docker Inc. предоставляет общедоступный реестр, который также еще называется главным списком (Central Index). Вы можете рассматривать реестр и клиентское приложение Docker вместе как эквивалент NPM для Node, CPAN для Perl или RubyGems для Ruby.

Кроме различным базовых образов, которыми вы можете пользоваться для создания своих собственных контейнеров Docker, в общедоступном реестре Docker Registry предлагаются образы готовых к запуску программ, в том числе баз данных, систем управления контентом, различных сред разработки, веб-серверов и так далее. Хотя по умолчанию клиентская программа Docker, работающая из командной строки, осуществляет поиск в общедоступном реестре, она также может поддерживать работу с приватными реестрами. Эта отличная возможность позволяет распространять в вашей компании образы с проприетарным кодом или проприетарными компонентами. Помещать образы в реестры также просто, как их оттуда скачивать. Для этого вам придется зарегистрироваться, но это также бесплатно. Наконец, в реестре фирмы Docker Inc. есть веб-интерфейс , предназначенный для поиска образов, чтения информации о них, их комментирования и их оценки (присваивания "звезд"). Всем этим пользоваться исключительно просто, и я призываю вас щелкнуть по ссылке, которая есть в разделе Ресурсы этой статьи, и начать все это изучать.

Беремся за Docker

Docker состоит из одного двоичного файла, который можно запустить одним из трех способов. Во-первых, он может работать как демон, который управляет контейнерами. В демоне есть интерфейс API на основе REST, которой можно использовать для локального или дистанционного доступа. Увеличивается количество клиентских библиотек, которые можно использовать для взаимодействия с API демона, в том числе для Ruby, Python, JavaScript (Angular и Node), Erlang, Go и PHP.

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

В-третьих, двоичный файл Docker выполняет роль клиентской программы для дистанционного доступа к репозиториям образов. Образы, с помощью которых в контейнере создается файловая система, называются репозиториями. Пользователи могут получиать образы, которые были помещены в репозиторий другими, и делиться своими образами, помещая их в реестры. Реестры используются для коллекционирования образов, составления их списков и для организации репозиториев.

Давайте рассмотрим все три способа запуска исполняемого файла Docker в действии. В этом примере вы ищите в репозитории Docker образ MySQL. Как только вы найдете то, что вам надо, вы его загрузите и сообщите демону Docker, что нужно выполнить команду (MySQL). Все это будет сделано из командной строки.

Рис.3. Получаем образ из репозитория Docker и запускаем контейнер

Начните с команды docker search mysql, которая выдаст список образов, находящихся в общедоступном реестре Docker и в которых есть "mysql". Независимо от того, почему я знаю, что это сработает, давайте скачаем образ "brice/mysql"; это вы можете сделать с помощью команды docker pull brice/mysql. Вы увидите, что Docker загрузит не только указанный образ, но и те образы, на основе которых он был создан. С помощью команды docker images вы можете получить список всех образов, которые в настоящее время имеются на локальном компьютере и входят в состав образа "brice/mysql". Запустите контейнер с параметром -d для того, чтобы он работал отдельно от запущенного в данный момент контейнера, и теперь у вас есть MySQL, работающий в контейнере. Вы в этом можете убедиться с помощью команды docker ps, которая выдаст список контейнеров, а не образов. В выданных данных вы также найдете порт, который слушает MySQL; по умолчанию — это порт 3306.

Но, как теперь подключиться к MySQL, зная, что он работает внутри контейнера? Вспомним, что у контейнеров Docker есть свой собственный сетевой интерфейс. Вам следует найти адрес IP и порт, которые слушает процесс сервера mysqld. С помощью команды docker inspect <Id образа> можно получить достаточно много информации, но, поскольку все, что вам нужно, это адрес IP, вы можете просто отсортировать эти данные с помощью команды docker inspect 5a9005441bb5 | grep IPAddress. Теперь вы можете подключиться с помощью стандартного клиента командной строки MySQL, указав в качестве параметров хост и порт. Когда вы завершите работу с сервером MySQL, вы можете закрыть его с помощью команды docker stop 5a9005441bb5.

Есть семь команд для поиска, загрузки и запуска контейнера Docker, в котором будет работать сервер MySQL, и выключения его после того, как вы все сделаете. При работе этого процесса вам не потребуется беспокоиться о конфликтах с установленными программами, с другой версией MySQL или с зависимостями. Вы использовали семь различных команд Docker: search, pull, images, run, ps, inspect и stop, но в клиентской программе Docker фактически предлагается 33 различные команды. Вы можете увидеть полный список команд, если запустите в командной строке команду docker help, либо вы можете найти их в руководстве, которое есть в сети.

Прежде, чем запускать Docker в приведенном выше примере, я указывал, что клиентская программа взаимодействует с демоном и реестром Docker через веб-сервисы с использованием REST. При этом подразумевается, что вы можете пользоваться локальным клиентом Docker для дистанционного доступа к демону и должным образом осуществлять администрирование ваших контейнеров на удаленной машине. На сайте Docker (см. раздел Ресурсы) предлагаются отлично задокументированные и проиллюстрированные на примерах интерфейсы API для демона Docker, реестра и списков образов.

Схема работы Docker

Docker может быть интегрирован в процесс разработки и развертывания проектов различными способами. Давайте взглянем на схему, показанную рис.4. Разработчик в нашей гипотетической компании может запускать систему Ubuntu с установленным пакетом Docker. Он может помещать образы Docker в общедоступный реестр и получать их оттуда с тем, чтобы использовать их как базу ля установки своего собственного кода и проприетарного программного обеспечения компании, а также создание образов, которые он помещает в приватный реестр компании.

В отделе QA этой компании, которую рассматриваем в этом примере, используется система CentOS и Docker. Здесь всякий раз, когда происходит апгрейд среды, из различных общедоступных и частных реестров берутся образы и запускаются различные контейнеры.

Наконец, компания для поддержки масштабируемости и гибкости помещает свою среду разработки в облако, а именно в сервисы Amazon Webs. В Amazon Linux также есть Docker, который управляет различными контейнерами.

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

Рис.4. Пример разработки программ с использованием Docker

Очень важно понимать, что Docker предлагает модель контейнеров, ориентированных на приложения. То есть, контейнеры должны запускать отдельные приложения или службы, а не их смесь. Помните, что контейнеры работают быстро и их создание и запуск не требует много ресурсов. Если следовать принципу ответственности за что-то одно и запускать в одном контейнере только один основной процесс, то в результате контейнеры будут слабо связаны с компонентами вашей системы. Давайте с учетом этого создадим свой собственный образ, из которого запустим контейнер.

Создание нового образа для Docker

В предыдущем примере, вы обращались к Docker из командной строки. Однако, когда создается образ, то обычно используется файл "Dockerfile", с помощью которого автоматизируется процесс сборки. Файлы Dockerfiles являются простыми текстовыми файлами, описывающими процесс сборки. Вы можете поместить Dockerfile в систему контроля версий и создавать образ так, что весь процесс создания можно будет повторять.

В качестве следующего примера, пожалуйста, изучите файл "PHP Box" Dockerfile (листинг 1). (прим.пер.: в листинг вставлены пояснения переводчика; листинг в исходном виде можно взять в оригинале настоящей статьи)

Листинг 1. Файл PHP Box

# PHP Box
#
# VERSION 1.0

# use centos base image – используется базовый образ для centos
FROM centos:6.4

# specify the maintainer – указан разработчик, осуществляющий поддержку
MAINTAINER Dirk Merkel, dmerkel@vivantech.com

# update available repos – репозитории, в которых присутствуют обновления
RUN wget http://dl.fedoraproject.org/pub/epel/6/x86_64/
↪epel-release-6-8.noarch.rpm; rpm -Uvh epel-release-6-8.noarch.rpm

# install some dependencies – установка некоторых зависимостей
RUN yum install -y curl git wget unzip

# install Apache httpd and dependencies – установка демона Apache httpd и его зависимостей
RUN yum install -y httpd

# install PHP and dependencies – установка PHP и его зависимостей
RUN yum install -y php php-mysql

# general yum cleanup – общая очистка с помощью yum 
RUN yum install -y yum-utils
RUN package-cleanup --dupes; package-cleanup --cleandupes; 
 ↪yum clean -y all

# expose mysqld port – указывается, какой порт будет прослушиваться
EXPOSE 80

# the command to run – запускаемая команда 
CMD ["/usr/sbin/apachectl", "-D", "FOREGROUND"]

Давайте внимательнее посмотрим на то, что происходит в этом файле Dockerfile. Синтаксис команд, используемых в Dockerfile, состоит из ключевого слова, за которым следуют аргументы команды. В соответствие с соглашением ключевые слова команды записываются прописными буквами. Комментарии начинаются с символа решетки.

С помощью ключевого слова FROM указывается, какой образ используется в качестве базового. Это должна быть первая инструкция в файле. В данном случае, вы будете делать сборку поверх последнего базового образа CentOS. Инструкция MAINTAINER, что очевидно, указывает разработчика, на которого возложена обязанность поддерживать данный файл Dockerfile. С помощью инструкция RUN выполняется команда и сохраняется полученный образ, в результате чего создается новый слой. Команды RUN используются в файле Dockerfile для поиска в дополнительных репозиториях конфигурационных файлов , а затем — запуска Yum для установки curl, git, wget, unzip, httpd, php-mysql и yum-utils. Я мог бы объединить все команды yum install в одной команде RUN и не сохранять промежуточные результаты.

Затем инструкция EXPOSE указывает порт 80, который, когда вы запустите контейнер, будет прослушивать сервер Apache.

Наконец, инструкция CMD позволит выполнить по умолчанию команду сразу, как только контейнер будет запущен. Если запуск контейнера рассматривать как один процесс, то все операции с контейнером можно считать как выполнение одной команды.

Наберите в командной строке команду docker build -t php_box и вы укажите Docker-у начать в текущем рабочем каталоге процесс сборки согласно файлу Dockerfile. Полученный образ будет помечен как "php_box", что позже упростит его поиск и идентификацию.

Процесс сборки загрузит базовый образ, а затем установит демон Apache httpd вместе со всеми его зависимостями. После того, как процесс будет завершен, будет возвращен хэш, идентифицирующий вновь созданный образ. Как и в случае с контейнером MySQL, который был запущен ранее, вы, указав тег "php_box", можете с помощью команды docker run -d -t php_box запустить из командной строки файл образа Apache и PHP.

Давайте закончим простым примером, в котором показано насколько просто создавать новый слой поверх уже существующего образа:

# MyApp
#
# VERSION       1.0

# use php_box base image – используется базовый образ  php_box
FROM php_box

# specify the maintainer - указан разработчик, осуществляющий поддержку
MAINTAINER Dirk Merkel, dmerkel@vivantech.com

# put my local web site in myApp folder to /var/www – перемещает мой локальный веб сайт из папки myApp в /var/www 
ADD myApp /var/www

Этот второй файл Dockerfile короче, чем первый, и в нем только, на самом деле, есть только две интересные для нас инструкции. Во-первых, вы сначала с помощью инструкции FROM указали, что будем использовать образ "php_box". Во-вторых, вы с помощью инструкции ADD копируете в образ локальный каталог. В данном случае, это проект PHP проект, в котором копирование в образы осуществляется в каталог DOCUMENT_ROOT сервера Apache. Результатом будет сайт, который будет подниматься по умолчанию, когда вы запускаете образ.

Заключение

Возможности Docker, позволяющие существенно упростить упаковку и развертывание приложений и зависимостей, впечатляют, их быстро принимает сообщество Linux и движение к промышленному использованию продолжается. Например, Red Hat объявила в декабре (2013 года) о том, что добавит поддержку Docker в предстоящий выпуск Red Hat Enterprise Linux 7. Docker еще молодой проект и он растет с головокружительной скоростью. Будет интересно на него взглянуть, когда он приблизится к релизу 1.0, в котором, как предполагается, будет представлена версия, официально предлагаемая для использования в промышленных целях. Docker опирается на проверенные технологии, некоторые из которых существовали в течение более десятка лет, но это не делает его менее революционным. Надеемся, что данная статья предоставила вам достаточно сведений и вдохновила на загрузку Docker и самостоятельного с ним экспериментирования.

Обновление Docker

Когда эта статья была уже опубликована, команда разработчиков Docker объявила о выпуске версии 0.8. В эту версию была добавлена поддержка для Mac OS X, состоящая из двух компонентов. Хотя клиентская программа работает в OS X как нативная, демон Docker работает внутри легковесной виртуальной машины на основе VirtualBox, управление которой осуществляется с помощью клиентской программы boot2docker, работающей из командной строки. Такой подход необходим из-за того, что лежащие в основе технологии, такие как LXC и пространства имен, просто не поддерживаются в OS X. Я думаю, что мы можем ожидать аналогичного решения для других платформ, в том числе Windows. (Для платформы Windows было использовано точно такое же решение — прим.пер.)

В версии 0.8 также добавлено ряд новых возможностей по сборке и экспериментальная поддержка файловой системы BTRFS (B-Tree File System). BTRFS является еще одной файловой системой с копированием при записи, а драйвер памяти BTRFS позиционируется как альтернатива драйверу AuFS.

В частности, в версии Docker 0.8 сделано много исправлений и улучшена производительность. Это общая приверженность к качеству сигнализирует об усилиях команды Docker выпустить версию 1.0, которую можно будет использоваться в производственных целях.

Ресурсы

Основной сайт Docker: https://www.docker.io

Реестр Docker: https://index.docker.io

Реестр API для Docker: http://docs.docker.io/en/latest/api/registry_api

Список API для Docker: http://docs.docker.io/en/latest/api/index_api

API дистанционного доступа Docker: http://docs.docker.io/en/latest/api/docker_remote_api

---

---