Распределенные пакеты приложений (обзор Around Docker 1.12 Series)

Новый Swarm, входящий в состав Docker 1.12+, является огромным улучшением по сравнению со старым управлением и расписанием. Больше нет необходимости запускать отдельный набор контейнеров Swarm (он входит в состав Docker Engine), стратегии аварийного переключения становятся намного надежнее, обнаружение служб запекается, новая сеть работает как очаровательная программа и так далее. Список возможностей и улучшений довольно большой. Если у вас не было возможности попробовать его, ознакомьтесь с разделом Введение в Docker Swarm и Интеграция прокси с Docker Swarm .

В этих статьях мы использовали команды для запуска сервисов Docker внутри кластера Swarm. Если вы похожи на меня, вы, вероятно, привыкли к простоте, которую обеспечивает Docker Compose. Вместо того, чтобы пытаться запомнить команды со всеми аргументами, необходимыми для запуска служб, вы, вероятно, указали все как файлы Docker Compose и запустили контейнеры с помощью простой команды docker-compose up -d . В конце концов, это намного удобнее, чем docker service create за которым следует бесконечное количество аргументов. Мой мозг не способен запомнить их все.

Когда я начал «играть» с новым Swarm, у меня было первое впечатление, что это здорово , а затем я не хочу запоминать разные аргументы для всех моих услуг . Я хочу, чтобы мои файлы Compose вернулись в игру.

Одним из существенных изменений является то, что управление контейнерами изменилось с клиента ( Docker Compose ) на сторону сервера ( Docker Service ). В результате Docker Compose устарел (по крайней мере, когда контейнеры развертываются с использованием Docker Service ). Это останется предпочтительным способом запуска контейнеров в среде с одним сервером, но не намного. Итак, что нам делать со всеми этими файлами docker-compose.yml, которые мы создали?

Хорошей новостью является то, что мы можем использовать Distributed Application Bundles или dab-файлы в качестве замены аргументов командной строки службы Docker. Плохая новость заключается в том, что… давайте оставим их до конца и сначала исследуем хорошие части.

Начнем с создания демонстрационного кластера Swarm, состоящего из компьютеров Docker.

Настройка среды

В следующих примерах предполагается, что у вас установлена ​​версия Docker Machine v0.8 +, включающая Docker Engine v1.12 +. Самый простой способ получить их — через Docker Toolbox .

Если вы пользователь Windows, пожалуйста, запустите все примеры из Git Bash (устанавливается через Docker Toolbox ).

Я не буду вдаваться в подробности настройки среды. Это то же самое, что описано в статье « Введение в Docker Swarm» . Мы настроим три узла, чтобы они сформировали кластер Swarm.

Docker Swarm кластер с тремя узлами

Теперь, когда у нас есть кластер Swarm, мы можем развернуть сервис, используя dab- файл.

Развертывание служб с использованием распределенных пакетов приложений (DAB)

Вместо создания сетей и сервисов Docker, указав бесконечное количество аргументов, мы будем использовать dab-файл . Думайте об этом как о Swarm-эквиваленте Docker Compose. Под Swarm я имею в виду docker swarm , docker service и другие вкусности, которые пришли с версией 1.12+ (не старый Swarm, работающий как отдельный контейнер).

Вместо того, чтобы пытаться выяснить детали нового формата для определения сервисов, мы создадим его из файла docker-compose.yml .

Начнем с проверки кода демо-сервиса.

Последняя команда выводит определение проекта Docker Compose . Это так.

Как видите, это очень простой проект. Он состоит из двух сервисов. Служба приложения — это бэкэнд, который предоставляет API. Он использует второй сервис ( дБ ) для хранения и извлечения данных. Цель приложения предоставляет порт 8080, который будет служить точкой входа в его API.

Преобразование этого определения Docker Compose в пакет является двухэтапным процессом. Сначала нам нужно вытащить изображения. Создание пакета оценит их и вместе с содержимым файла docker-compose.yml выведет dab- файл.

Давайте попробуем это.

Теперь, когда процесс завершен, давайте посмотрим на результат.

Вывод следующий.

Файл godemo.dab, который мы только что создали, довольно прост. Он состоит из двух служб, которые соответствуют службам из файла docker-compose.yml . Каждый из них определяет изображение, которое определяется с помощью хэшей тех, что мы вытащили. За изображениями следует сеть по умолчанию, которая окружает службы и порты, которые должны быть открыты.

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

Вторая проблема заключается в том, что мы не указали никаких ограничений. Развертывание неограниченных служб в кластере может быстро обернуться катастрофой.

Лучшее, но все же очень простое определение Compose можно увидеть в файле docker-compose-swarm.yml . Его содержание заключается в следующем.

Как видите, мы удалили порт и добавили ограничение mem_limit . Тем не менее, это очень простой файл Compose.

Давайте создадим новый вывод пакета.

Вывод команды bundle выглядит следующим образом.

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

Оставим это ограничение в стороне (пока) и попробуем развернуть новый пакет.

Вывод команды deploy выглядит следующим образом.

И сеть, и сервис созданы. Мы можем подтвердить это, перечислив все услуги.

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

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

Мы можем исправить эти недостатки, выполнив команду service update . Например, мы можем создать прокси- сеть вручную и добавить в нее контейнер. Мы также можем использовать команду service update для установки предела памяти. Однако, если мы начнем делать все это, нам, вероятно, будет лучше без пакета в первую очередь.

Что делать сейчас?

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

Вопрос в том, что делать сегодня. Мы можем выбрать несколько путей. Один из них — дождаться выхода пакета из экспериментальной стадии и (надеюсь) поддержать все функции, которые может предложить Docker Swarm. Другой подход заключается в использовании проекта Whaleprint . Он выглядит как смесь DAB- файла с дополнительными функциями (например, ограничениями) и подходом, который использует Terraform . Это очень перспективный проект. Но, так же как и пакет , он все еще находится в зачаточном состоянии.

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

На данный момент я рекомендую вам внимательно следить за пакетом распределенных приложений и ждать, пока он созреет. А пока управляйте кластером Swarm с помощью команд или попробуйте проект Whaleprint .

Следующий будет посвящен развертыванию без простоев с Docker Swarm .