Как мы можем использовать Docker для разработки?
Теперь, когда мы знаем все это о Docker, как мы можем использовать Docker для локальной среды разработки? Давайте приведем мотивирующий пример: нас наняли для создания небольшого сервера REST. Для этого приложения я выбрал Python и Flask в качестве своих инструментов, но вы можете использовать и другие стеки. Этот разговор самоуверен в том, какие инструменты я предпочитаю использовать, но должен быть в целом применим к другим языкам.
Мы вызовем приложение Flask-Tester, чтобы увидеть готовые репозитории, пожалуйста, проверьте:
- git clone https://github.com/jquacinella/flask-tester-backend
- git clone https://github.com/jquacinella/flask-tester-docker
Использование диска контейнерами
Каждый раз, когда создается контейнер, в папке на хост-машине появляется несколько папок и файлов. Среди них:
- Папка (ID — уникальный идентификатор контейнера). Если контейнер использует драйвер логгирования по умолчанию, все логи будут сохранены в файле JSON внутри нее. Создание слишком большого количества логов может повлиять на файловую систему хост-машины.
- Папка в , содержащая слой чтения-записи контейнера (overlay2 является предпочтительным драйвером хранилища в большинстве дистрибутивов Linux). Если контейнер сохраняет данные в своей собственной файловой системе, они будут храниться в на хост-машине.
Представим, что у нас есть совершенно новая система, в которой только что был установлен Docker.
$ docker system dfTYPE TOTAL ACTIVE SIZE RECLAIMABLEImages 0 0 0B 0BContainers 0 0 0B 0BLocal Volumes 0 0 0B 0BBuild Cache 0 0 0B 0B
Во-первых, запустим контейнер NGINX:
$ docker container run --name www -d -p 8000:80 nginx:1.16
Снова запустив команду , мы увидим:
- один образ размером 126 Мбайт. Его загрузил NGINX: 1.16, когда мы запустили контейнер;
- контейнер , запускающийся из образа NGINX.
$ docker system dfTYPE TOTAL ACTIVE SIZE RECLAIMABLEImages 1 1 126M 0B (0%)Containers 1 1 2B 0B (0%)Local Volumes 0 0 0B 0BBuild Cache 0 0 0B 0B
Поскольку контейнер запущен, а образ в данный момент используется, освобождаемого пространства пока нет. Так как его размер (2B) незначителен, и поэтому его нелегко отследить в файловой системе, создадим пустой файл размером 100 Мбайт в файловой системе контейнера. Для этого мы используем удобную команду dd из контейнера www.
$ docker exec -ti www \ dd if=/dev/zero of=test.img bs=1024 count=0 seek=$
Этот файл создается в слое чтения-записи, связанном с этим контейнером. Если мы снова проверим вывод команды , то увидим, что он теперь занимает некоторое дополнительное дисковое пространство.
$ docker system dfTYPE TOTAL ACTIVE SIZE RECLAIMABLEImages 1 1 126M 0B (0%)Containers 1 1 104.9MB 0B (0%)Local Volumes 0 0 0B 0BBuild Cache 0 0 0B 0B
Где находится этот файл на хосте? Проверим:
$ find /var/lib/docker -type f -name test.img/var/lib/docker/overlay2/83f177...630078/merged/test.img/var/lib/docker/overlay2/83f177...630078/diff/test.img
Не вдаваясь глубоко в детали — этот файл был создан на слое чтения-записи контейнера, который управляется драйвером overlay2. Если мы остановим контейнер, используемое им дисковое пространство станет пригодным для восстановления. Посмотрим:
# Остановка контейнера www$ docker stop www# Влияние на использование диска$ docker system dfTYPE TOTAL ACTIVE SIZE RECLAIMABLEImages 1 1 126M 0B (0%)Containers 1 0 104.9MB 104.9MB (100%)Local Volumes 0 0 0B 0BBuild Cache 0 0 0B 0B
Как можно восстановить это пространство? Путем удаления контейнера, что приведет к удалению связанного с ним слоя чтения-записи.
Следующие команды позволяют нам удалить все остановленные контейнеры сразу и освободить место на диске, которое они используют:
$ docker container pruneWARNING! This will remove all stopped containers.Are you sure you want to continue? [y/N] yDeleted Containers:5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2Total reclaimed space: 104.9MB
Из вывода видно, что больше нет места, используемого контейнерами, и, поскольку образ больше не используется (контейнер не работает), пространство, которое он использует в файловой системе хоста, может быть восстановлено:
$ docker system dfTYPE TOTAL ACTIVE SIZE RECLAIMABLEImages 1 0 126M 126M (100%)Containers 0 0 0B 0BLocal Volumes 0 0 0B 0BBuild Cache 0 0 0B 0B
Примечание: если образ используется хотя бы одним контейнером, занимаемое им дисковое пространство не может быть освобождено.
Подкоманда , которую мы применяли выше, удаляет остановленные контейнеры. Если нам нужно удалить все — и запущенные, и остановленные, мы можем использовать одну из следующих команд (обе эквивалентны):
# Старая команда$ docker rm -f $(docker ps -aq)# Более современная$ docker container rm -f $(docker container ls -aq)
Примечание: во многих случаях стоит использовать флаг при запуске контейнера, чтобы он автоматически удалялся при остановке процесса PID 1, тем самым немедленно освобождая неиспользуемое пространство.
Чем полезны контейнеры
Легковесность, быстродействие и возможность работать на высоком уровне абстракции, делегируя проблемы с железом и ОС провайдеру, — это преимущества контейнеров, позволяющие снизить операционные расходы, связанные с разработкой и эксплуатацией приложений, делающих решения на их базе столь привлекательными для бизнеса.
Техническим же специалистам контейнеры прежде всего полюбились за возможность упаковать приложение вместе с его средой запуска, решая тем самым проблему зависимостей в разных окружениях. Например, различие версий языковых библиотек на ноутбуке разработчика и в последующих окружениях рано или поздно приведёт к сбоям, и нужно будет как минимум потратить время на их анализ, а как максимум — решать проблему проникших в продакшен багов. Использование контейнеров устраняет проблему «А на моей машине все работало! ¯\_(ツ)_/¯».
Также контейнеры позволяют сократить время разработки приложения и упрощают управление им в продакшене благодаря лёгкости в настройке и изменении конфигурации, возможности версионировать её вместе с кодом приложения и удобным инструментам оркестрирования, позволяющим быстро масштабировать инфраструктуру. Кроме того, фактическое отсутствие привязки контейнеров к хостинговой платформе даёт огромную гибкость при выборе или смене провайдера — вы можете запускать их без принципиальных отличий в конечном результате на личном компьютере, bare metal серверах и в облачных сервисах.
Режим «docker-swarm»
Докер представил в версии 1.12.0. Это позволяет нам легко создавать и управлять роями нескольких хостов. В режиме «Рой» имеется хранилище «ключ-значение» для обнаружения сервисов и возможности оркестровки. Вы можете присоединиться к хостам в рое как менеджер или работник. Как правило, менеджер обрабатывает часть оркестровки, а рабочие используются для запуска контейнеров. Поскольку используем для демострации, мы будем запускать InfluxDB и Grafana в самом менеджере.
В Swarm Mode есть интересная функция, называемая сеткой маршрутизатора. Действует как виртуальный балансировщик нагрузки. Допустим, у нас есть 10 контейнеров, работающих на 5 узлах, и они слушают порт 80. Теперь, если вы получаете доступ к порту 80 любого из хостов, вы будете направлены к любому из 10 запущенных экземпляров, даже к тем экземплярам, которые не находятся на этом конкретном хосте. Таким образом, вы можете опубликовать IP-адрес любого из узлов, и запросы будут автоматически распределены между всеми 10 контейнерами.
Чтобы применить действия с демонстрации, у вас должны быть установлены следующие продукты:
- : версия> = 1.13, чтобы поддержать Docker Compose File версии 3 и режим Swarm.
- : версия> = 0.8
- : версия> = 1.10, для поддержки Docker Compose версии 3
Мы создадим 3 машины, swarm, plugin . Для этого вам необходимо установить Virtualbox в систему. Вы также можете развернуть узлы в облачных сервисах с помощью разных плагинов. Шаги после создания в виртуальных машинах одинаковы для всех подключаемых модулей.
Мы будем использовать параметры по умолчанию для создания виртуальных машин. Мы создадим хост с именем который будет как менеджер для swarm, и два хоста и будут как рабочие. Вы можете создать столько узлов, сколько захотите. Просто повторите команды с именами хостов. Чтобы создать виртуальные машины, выполните следующие команды.
docker-machine create manager docker-machine create agent1 docker-machine create agent2
Эти команды могут занять некоторое время. После создания VMS вывод для команды должен выглядеть примерно так.
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS agent1 - virtualbox Running tcp://192.168.99.101:2376 v17.03.1-ce agent2 - virtualbox Running tcp://192.168.99.102:2376 v17.03.1-ce manager - virtualbox Running tcp://192.168.99.100:2376 v17.03.1-ce
Теперь вам нужно переключить контекст, чтобы использовать механизм докера в менеджере. Мы будем выполнять остальную часть демонстрации в докерском движке менеджера а НЕ в нашей локальной системе. Для этого выполните следующую команду.
eval `docker-machine env manager`
Теперь мы перешли на управление докером в . Мы инициализируем рой менеджером, который будет его менеджером. Мы должны упомянуть IP, который будет опубликован для других узлов, чтобы присоединиться к рою. Для этого мы будем использовать IP-адрес . Команда, выведет результат. Итак, чтобы создать рой, запустите следующую команду.
docker swarm init --advertise-addr `docker-machine ip manager`
Теперь нам нужно добавить два узла к этому рою. Для этого нам нужно передать соединения и IP-адрес, опубликованный при создании роя. Чтобы получить токен для присоединения к рою в качестве рабочего узла, вы можете выполнить команду . Как и прежде, получит IP-адрес для соединения. Мы могли бы присоединиться к рою, изменив контекст на каждого из рабочих узлов, но легче выполнить команды, через SSH. Чтобы присоединить рабочий узел к рою, выполните следующие команды.
docker-machine ssh agent1 docker swarm join --token `docker swarm join-token -q worker` `docker-machine ip manager`:2377 docker-machine ssh agent2 docker swarm join --token `docker swarm join-token -q worker` `docker-machine ip manager`:2377
Вы можете увидеть узлы в рое с помощью . Как только рабочие узлы добавлены, результат команды должен выглядеть примерно так.
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS 3j231njh03spl0j8h67z069cy * manager Ready Active Leader muxpteij6aldkixnl31f0asar agent1 Ready Active y2gstaqpqix1exz09nyjn8z41 agent2 Ready Active
2014
Microsoft портирует Docker на Windows Server и Windows Azure
22 октября 2014 года Microsoft сообщила о предстоящем переносе кода платформы Docker на Windows Server и Windows Azure.
Платформа Docker разработана для операционной системы Linux и использует возможности контейнерной виртуализации, глубоко интегрированные в Linux-ядро. Портировать такое ПО на Windows — непростая задача, однако Microsoft собирается сделать это. Компания заявила о намерении поддержать и финансировать усилия Open Source-разработчиков и реализовать поддержку API Docker в своем облачном сервисе Windows Azure.
В июне 2014 года появилась возможность запуска Docker-хостов на Windows Azure. Пользователь может создать в облаке Microsoft виртуальную машину, установить на нее Linux, запустить среду Docker и в ней — свои приложения. Однако, компания стремится обеспечить запуск задач на Windows-хостах, как в облаке Azure, так и в любых других публичных и частных средах.
Аналитики отметили стремление компании называть эту технологию «контейнерами Windows», тем самым отмечая вероятность существенного отличия внутреннего устройства Windows-версии Docker от оригинала. Однако, компания обещает — все приложения, запускаемые в среде Docker на 22 октября 2014 года, будут работать в окружении Windows.
На 22 октября 2014 года в виртуальной среде Docker можно запустить 45 тыс. готовых образов различных приложений.
Open Source сообщество отметило особенность, которая стала, в некотором смысле, победой сообщества: для обеспечения поддержки Docker внутри Windows будут, по сути, реализованы ключевые особенно ядра Linux.
Docker 1.3.2: исправлены критические ошибки
Осенью 2014 года состоялся выход внеочередного обновления открытой системы управления контейнерной виртуализацией Docker 1.3.2, вызванный необходимостью исправления двух ошибок, получивших статус критических. Обнаруженные уязвимости позволяли злоумышленнику получить доступ к файловой системе хост-машины за пределами контейнера, что крайне опасно.
Первой уязвимости был присвоен идентификатор CVE-2014-6407. Она позволяет злоумышленнику переместить файлы из контейнера в файловую систему хост-машины используя команды docker pull или docker load. Это возможно из-за ошибки при обработке жёстких и символических ссылок в программе извлечения данных из образа контейнера. В результате злоумышленник сможет выполнить в хост-системе произвольный код и изменить собственные права доступа.
Ошибка содержится во всех предыдущих версиях Docker. Таким образом, обновление является обязательным.
Вторая уязвимость имеет идентификатор CVE-2014-6408. Ошибка позволяет игнорировать ограничения, заданные для изолированного контейнера, что также позволяет злоумышленнику выйти за его пределы. Это связано с тем, что пользователь имеет возможность присвоить образу собственные параметры безопасности и изменить общий профиль безопасности для всех контейнеров, опирающихся на аналогичный образ.
Ошибка найдена в выпусках с номерами 1.3.0 и 1.3.1. Так что, на практике и тут обновления носит обязательный характер — вряд ли кто-то использует более ранние выпуски.
Работы по включению поддержки Docker в среду Apache Hadoop
С 2014 года ведутся работы по включению поддержки Docker в среду управления фреймворка распределённых приложений Hadoop; по результатам тестирования вариантов платформы виртуализации для Hadoop, проведённом в мае 2014 года, Docker показал на основных операциях (по массовому созданию, перезапуску и уничтожению виртуальных узлов) существенно более высокую производительность, нежели KVM, в частности, на тесте массового создания виртуальных вычислительных узлов прирост потребления процессорных ресурсов в Docker зафиксирован в 26 раз ниже, чем в KVM, а прирост потребления ресурсов оперативной памяти — втрое ниже.
Logical View
In the context of Docker and Docker Swarm, an application is made up of 1 to many services running on 1 to multiple of software defined networks (SDN). Those services collaborate with each other by exchanging messages or calling each other in an RPC like style. Each service can be “attached” to one or many networks. The communication between the services happens over a network. In this regard a network can be regarded like a wire that connects services or maybe a channel through which the water (messages) flows from service to service. Only services that are attached (or have a connection to) the same network are able to communicate with each other. There is no way that two services can see each other or connect with each other if they are on different networks. Let’s illustrate this with an image. As always images say more than a thousand words
In the above image we have the application in orange which encompasses 3 services A, B and C (blue). In the application we also have 2 networks SDN-1 and SDN-2 defined (gray). Service A is connected to SDN-1, service B is connected to both, SDN-1 and SDN-2 whilst service C is connected to SDN-2. Thus service B can see A and C while services A and C cannot see or communicate with each other.
Включить или выключить автоблокировку на существующем рое
Чтобы включить автоблокировку на существующем рое, установите для флага значение .
$ docker swarm update --autolock=true
Swarm updated.
To unlock a swarm manager after it restarts, run the `docker swarm unlock`
command and provide the following key:
SWMKEY-1-+MrE8NgAyKj5r3NcR4FiQMdgu+7W72urH0EZeSmP/0Y
Please remember to store this key in a password manager, since without it you
will not be able to restart the manager.
Чтобы отключить автоблокировку, установите для значение . Взаимный ключ TLS и ключ шифрования, используемые для чтения и записи журналов Raft, хранятся в незашифрованном виде на диске. Существует компромисс между риском сохранения незашифрованного ключа шифрования в покое и удобством перезапуска роя без необходимости разблокировки каждого менеджера.
$ docker swarm update --autolock=false
Держите ключ разблокировки в течение короткого времени после отключения автоблокировки,на случай,если менеджер выйдет из строя,пока он все еще настроен на блокировку с помощью старого ключа.
Deploying a Container
Once your nodes are ready, you can deploy a container into your swarm. Swarm mode uses the concept of “services” to describe container deployments. Each service configuration references a Docker image and a replica count to create from that image.
docker service create --replicas 3 --name apache httpd:latest
This command creates a service using the image for the Apache web server. Three independent replicas will be created, giving you resiliency against container terminations and node outages. Container replicas are called “tasks” in Docker Swarm parlance.
Advertisement
Docker will continually maintain the requested state. If one of the nodes drops offline, the replicas it was hosting will be rescheduled to the others. You’ll have three Apache containers running throughout the lifetime of the service.
Manage services
Manage service in your Swarm with the command and its subcommands.
Create a service
We used this command before when we created the visualizer service. The command comes in the form of and has many options to fine-tune your service. You can explore the options with or use the official reference.
Many options are similar to the options of and you’ll find options that are specific to Swarm mode.
See the logs of a service
Use the command to see the logs of a service, the options are similar to the options of .
As you can see, the service logs are displayed for all tasks that belong to the service.
Update a service
Use the command to update the configuration of a service. You can change the configuration that you specified with with this command.
Rollback service changes
After you applied changes to your service with the command, you can revert to the previous state with the command, if needed.
Зачем нужен Docker?
Docker уже настолько популярен, что термины «Docker» и «контейнеры» стали синонимами. Однако первые технологии, связанные с контейнерами, появились много лет — или даже десятилетий (внешняя ссылка) — назад, и только в 2013 году о Docker узнала широкая аудитория.
Отдельно стоит отметить 2008 год, когда в ядре Linux была реализована полноценная система виртуализации LinuXContainers (LXC) для одного экземпляра Linux. Хотя LXC используется до сих пор, уже доступны более современные технологии. Ubuntu — современная операционная система Linux с открытым исходным кодом — также предоставляет эту возможность.
Инструменты Docker расширили встроенные в Linux функции контейнеризации, предоставив следующие преимущества:
- Улучшенная, прозрачная переносимость: если контейнеры LXC часто используют специализированные конфигурации, то контейнеры Docker поддерживают работу на любых платформах, включая портативные компьютеры, ЦОД и облачные среды, без изменения.
- Еще меньший размер и более точечные обновления: LXC позволяет объединять несколько процессов в один контейнер. В случае Docker каждый контейнер может содержать только один процесс. Это позволяет создавать приложения, которые могут продолжать работать в случае отключения одного из его компонентов для обновления или обслуживания.
- Автоматическое создание контейнеров: Docker поддерживает автоматическое создание контейнеров на основе исходного кода приложения.
- Контроль версий контейнеров: Docker может отслеживать версии образа контейнеров, выполнять откат до предыдущих версий, а также отслеживать авторов версий и способ разработки. Более того, поддерживается передача только изменений между существующей и новой версиями.
- Повторное использование контейнеров: существующие контейнеры можно использовать в качестве базовых образов — по сути как шаблоны для создания новых контейнеров.
- Общие библиотеки контейнеров: разработчикам доступен открытый реестр, содержащий тысячи контейнеров, добавленных пользователями.
Контейнеры Docker уже работают с сервером Microsoft Windows. Большинство поставщиков облачных услуг предоставляют разработчикам специальные услуги для разработки, доставки и запуска контейнеризованных приложений с помощью Docker.
Это объясняет высокие темпы внедрения и рост популярности Docker. В момент написания этой статьи отчет Docker Inc. содержал следующие цифры: 11 млн разработчиков и 13 млрд загрузок образов контейнеров ежемесячно (внешняя ссылка).
Инструменты и термины Docker
Ниже перечислены инструменты и термины, которые могут встретиться вам при работе с Docker:
DockerFile
Каждый контейнер Docker содержит простой текстовый файл с инструкциями по созданию образа контейнера Docker. DockerFile автоматизирует процесс создания образов Docker. Он представляет собой список инструкций для командной строки (CLI), которые необходимо выполнить Docker Engine для компоновки образа.
Образы Docker
Образы Docker содержат исходный код приложения, а также все инструменты, библиотеки и зависимости, необходимые для запуска контейнера. После запуска образ Docker становится одним экземпляром (или несколькими экземплярами) контейнера.
Образ Docker можно создать с нуля, однако большинство разработчиков используют готовые шаблоны из общих хранилищ. Один базовый образ может служить основой для создания нескольких образов Docker, которые будут иметь общие характеристики соответствующего стека.
Образы Docker состоят из уровней, каждый из которых соответствует определенной версии образа. При каждом внесении изменений в образ создается новый верхний уровень, который заменяет собой предыдущий верхний уровень, становясь текущей версией образа. Предыдущие уровни хранятся для обеспечения возможности отката или повторного использования в других проектах.
Каждый раз при создании контейнера на основе образа Docker создается еще один уровень, называемый уровнем контейнера. Изменения, которые вносятся в контейнер, например при добавлении или удалении файлов, хранятся только на уровне контейнера и существуют исключительно во время выполнения контейнера. Такой итерационный процесс создания образов позволяет повысить общую эффективность, поскольку на основе одного базового образа можно запускать несколько экземпляров контейнеров, использующих общий стек.
Контейнеры Docker
Контейнеры Docker — это динамические, запущенные экземпляры образов Docker. В отличие от файлов образов Docker, которые доступны только для чтения, контейнеры представляют собой динамическое, кратковременное, исполняемое содержимое. Пользователи могут взаимодействовать с контейнерами, а администраторы могут настраивать параметры и условия с помощью команд Docker.
Docker Hub
Docker Hub (внешняя ссылка) — общедоступное хранилище образов Docker и «крупнейшая в мире библиотека и сообщество для хранения образов контейнеров». В этом хранилище собрано более 100 тысяч образов контейнеров, добавленных поставщиками коммерческого ПО, авторами проектов с открытым исходным кодом и отдельными разработчиками. В Docker Hub можно найти образы, созданные Docker, Inc., сертифицированные образы, принадлежащие Docker Trusted Registry, а также тысячи других образов.
Все пользователи Docker Hub делятся образами по своему усмотрению. Кроме того, из файловой системы Docker можно загружать готовые базовые образы для использования в качестве шаблонов в проектах контейнеризации.
Демон Docker
Демон Docker — это служба, запущенная в операционной системе пользователя, например Microsoft Windows, Apple MacOS или iOS. Данная служба создает образы Docker и управляет ими с помощью команд клиента, выполняя роль центра управления для соответствующей реализации Docker.
Реестр Docker
Реестр Docker — это масштабируемое хранилище с открытым исходным кодом и система распространения образов Docker. Реестр позволяет отслеживать версии образов в хранилищах с помощью тегов, облегчающих идентификацию. Для этого используется инструмент контроля версий Git.
Docker и IBM Cloud
Корпоративная контейнерная платформа поддерживает оркестрацию в разных общедоступных и частных облачных средах, обеспечивая унификацию используемых сред с целью улучшения бизнес-показателей и повышения эффективности работы. Это ключевой компонент стратегии открытого гибридного облака, который дает возможность избежать привязки к определенному поставщику, внедрить согласованные процедуры создания и запуска приложений в любой среде, а также оптимизировать и модернизировать все ИТ-процессы.
Сделайте следующий шаг:
- Воспользуйтесь Red Hat OpenShift on IBM Cloud — управляемой услугой OpenShift на основе IBM Cloud с высочайшим уровнем масштабируемости и безопасности — для развертывания полностью управляемых кластеров Kubernetes с высоким уровнем доступности, чтобы автоматизировать процессы обновления, масштабирования и инициализации ресурсов.
- Обеспечьте развертывание и запуск приложений во всех средах, независимо от поставщика облачных услуг, включая локальные среды, периферийные узлы и общедоступные облачные среды, с помощью IBM Cloud Satellite — управляемого распределенного облачного решения.
- Упростите и консолидируйте озера данных за счет слаженного развертывания корпоративных хранилищ с поддержкой контейнеров локально и в общедоступных облачных средах с помощью решений IBM для гибридного облачного хранилища.
- Упростите сложные процессы управления гибридной ИТ-архитектурой с помощью управляемых услуг IBM Cloud.
Начните работать с учетной записью IBM Cloud уже сегодня.
Балансировка нагрузки
Менеджер роя использует балансировку входной нагрузки, чтобы предоставить услуги, которые вы хотите сделать внешне доступными для роя. Диспетчер роя может автоматически назначить службе Опубликованный Порт, или вы можете настроить Опубликованный Порт для службы. Вы можете указать любой неиспользуемый порт. Если вы не укажете порт, менеджер роя назначит службе порт в диапазоне 30000-32767.
Внешние компоненты,такие как облачные балансировщики нагрузки,могут получать доступ к службе на порту PublishedPort любого узла в кластере,независимо от того,выполняет ли узел задачу для этой службы в данный момент или нет.Все узлы в рое маршрутизации подключаются к запущенному экземпляру задачи.
В режиме Swarm есть внутренний компонент DNS, который автоматически назначает каждой службе в Swarm запись DNS. Диспетчер роя использует внутреннюю балансировку нагрузки для распределения запросов между службами в кластере на основе DNS-имени службы.
Testing Fault Tolerance
As we connected two managers to run our service, let’s just bring one of them down. I’m going to power off , the current leader, so that it will hopefully do the following:
-
Elect a new leader (swarm2).
-
Start up additional containers to cover the outage.
root@swarm1:~# poweroff Connection to 10.55.0.248 closed by remote host. Connection to 10.55.0.248 closed.
First off, let’s list the cluster state.
root@swarm2:~# docker node ls Error response from daemon: rpc error: code = 2 desc = raft: no elected cluster leader
Uh-oh, this was slightly unexpected. After bringing up , I’m seeing that was promoted to a leader. But it’s not exactly the fail-over I imagined. While was offline, the ping service only ran as 2⁄5 and didn’t automatically scale on as expected.
root@swarm2:~# docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS 4i0lko1qdwqp4x1aqwn6o7obh swarm1 Ready Active Reachable 9gyk5t22ngndbwtjof80hpg54 * swarm2 Ready Active Leader root@swarm2:~# docker service ps helloworld ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR 4x0zgeiucsizvmys5orih2bru helloworld.1 alpine swarm1 Running Running 3 minutes ago 5fxtllouvmd91tmgzoudtt7a4 \_ helloworld.1 alpine swarm1 Shutdown Complete 3 minutes ago cqvgixx3djhvtiahba971ivr7 helloworld.2 alpine swarm2 Running Running 21 minutes ago 99425nw3r4rf5nd66smjm13f5 helloworld.3 alpine swarm2 Running Running 21 minutes ago 5xzldwvoplqpg1qllg28kh2ef helloworld.4 alpine swarm1 Running Running 3 minutes ago 1dj3cs7v5ijc93k9yc2p42bhj \_ helloworld.4 alpine swarm1 Shutdown Complete 3 minutes ago avm36h718yihd5nomy2kzhy7m helloworld.5 alpine swarm1 Running Running 3 minutes ago 0hy3yzwqzlnee10gat6w2lnp2 \_ helloworld.5 alpine swarm1 Shutdown Complete 3 minutes ago
So, what went wrong? A bit of reading and I’ve come up to the following explanation of how Docker uses the RAFT consensus algorithm for leader selection:
