[Docker] Кластер развертывания Docker Three Musketeers Practice

Docker

Автор: No Dishwashing Studio - Marklux
Источник: marklux.cn/blog/55
Все права принадлежат автору, при перепечатке указывать источник

предисловие

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

Чтобы максимально использовать преимущества технологии контейнеризации, Docker последовательно запустил три основные технологии:docker-machine,docker-compose,docker-swarmможно сказать, что практически все базовые технические средства, которые могут потребоваться в технологии контейнеризации, реализованы.

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

Знакомство с тремя мушкетерами

docker-machine

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

Docker-machine — официально предложенная докер-компанией технология для быстрого создания виртуальных машин с докер-сервисами на различных платформах и даже возможность настройки принципа реализации виртуальных машин путем указания драйверов (как правило, virtualbox).

docker-compose

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

технология docker-compose, через.ymlФайл конфигурации, напишите ряд конфигураций всех методов развертывания контейнера, сопоставления файлов, соединений контейнера и т. Д. В файле конфигурации, и, наконец, нужно только выполнитьdocker-compose upКоманды будут устанавливать контейнеры один за другим, подобно выполнению скриптов, и автоматически развертывать их, что значительно облегчает развертывание сложных сервисов.

docker-swarm

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

По сравнению с фреймворками управления кластерами, такими как zookeeper, swarm очень легкий.Как инструмент, он объединяет сложные операции, такие как объединение узлов, управление и обнаружение, в несколько простых команд, а также имеет автоматическое обнаружение узлов и планирование.Алгоритм также поддерживает настройку. . Хотя технология роя еще не очень развита, ее мощь уже видна.

Говоря об архитектуре службы докеров и удаленном API

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

daemon

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

Каждая выполняемая команда docker фактически реализуется путем отправки запроса демону.

Существует два основных типа работы демона (режим связи): один — через сокет unix (по умолчанию, но доступ к нему возможен только локально, что более безопасно), другой — через прослушивание адреса и порта протокола tcp (это может быть Реализованы удаленные вызовы служб докеров).

Удаленный API

В дополнение к доступу к службе докена на удаленном хосте через удаленный протокол TCP, Docker также предоставляет набор API на основе HTTP, который может использовать Curl для управления службой докера на удаленном хосте, что облегчает разработку веб-докера Сервисы.

Пример использования удаленного докера

Когда кластер наконец реализован, удаленный вызов docker фактически используется для соединения разных хостов docker в единое целое (по протоколу tcp).

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

Во-первых, вам нужно изменить режим работы docker на tcp на хосте, который предоставляет услугу.Конкретный метод заключается в изменении/etc/default/dockerсерединаDOCKER_OPTSдля следующего

-H tcp://127.0.0.1:4243 -H unix:///var/run/docker.sock

Параметры после -H — это TCP-адрес и порт, которые вы определяете для привязки.После успешной привязки перезапустите службу Docker, чтобы получить доступ к службе демона Docker на этом порту.

К несчастью:

  • На платформе OSX файл конфигурации демона Docker не найден.
  • На платформах OSX используйтеdocker -H tcp://0.0.0.0:4243 -H unix:///var/run/docker.sock -dТакая команда, чтобы попытаться запустить демон docker в tcp, также не работает и не имеет никакого эффекта.
  • В настоящее время предполагается, что за исключением платформы Linux методы настройки на других платформах не такие, но решения в сети не найдено, поэтому я могу только смоделировать удаленную работу, создав несколько docker-машин локально. перечислить.

Предположим, мы192.168.1.123Служба Docker открыта на этом хосте.2375порт, то мы можем на других хостах в том же сегменте сети (например,192.168.1.233)пройти черезdocker -H tcp://192.168.1.123:2345 <command>способ вызова службы докеров на хосте.

Например

docker -H tcp://192.168.1.123:2345 ps
docker -H tcp://192.168.1.123:2345 images
docker -H tcp://192.168.1.123:2345 run ...

Последний рой времени для создания кластера, каждый узел должен быть запланирован через этот удаленный сервисный вызов.

Кластеры и распределенные вычисления

Прежде чем официально начать практиковать кластеры, нам необходимо понять, что такое кластер и что такое распределенные вычисления.

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

Разница между ними заключается в следующем:

  • Кластер — это место, где несколько машин выполняют один и тот же бизнес, и каждый раз они находят наиболее подходящий узел для выполнения бизнеса в соответствии с алгоритмом планирования.
  • Распределенные вычисления — это разделение бизнеса на несколько независимых частей, которые дополняются взаимодействием нескольких машин.

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

Преимущество распределенных вычислений находится в синергетически Power Play. Несколько вычислительных машин, необходимость ультра высокой производительности вычислений.

Создайте кластер

Скажем, теперь мы официально начинаем строить кластер.

Создайте ноду с докер-машиной

Из-за отсутствия физических машин и того, что сервис tcp docker нельзя нормально включить на osx, мы создаем несколько виртуальных машин на базе docker-machine как ноды в кластере.

Выполните следующую команду, чтобы создать новую виртуальную машину docker-machine.manager1

docker-machine create --driver virtualbox manager1

Как только вы создали виртуальную машину, вы можете использоватьdocker-machine env manager1для просмотра виртуальной машиныmanager1связанная информация, включая IP-адрес и т. д.

Теперь приступаем к выполнению команды для созданияworker1иworker2два узла, используяdocker-machine lsКоманда может просмотреть все работающие виртуальные машины:

docker-machine ls
NAME       ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
manager1   -        virtualbox   Running   tcp://192.168.99.100:2376           v17.06.1-ce   
worker1    -        virtualbox   Running   tcp://192.168.99.101:2376           v17.06.1-ce   
worker2    -        virtualbox   Running   tcp://192.168.99.102:2376           v17.06.1-ce

После создания докер-машины вы можете пройтиdocker-machine ssh manager1 <command>Способ доступа к виртуальной машине и выполнять инструкции.

Создание роевого кластера

Команда для инициализации swarm-кластера:

docker swarm init --listen-addr <MANAGER-IP>:<PORT> --advertise-addr <IP>

--listen-addrПараметр — это IP:PORT, где находится служба докеров узла менеджера, то есть через эту комбинацию можно получить доступ к службе докеров узла.

--advertise-addrэто широковещательный адрес, то есть IP-адрес, к которому должны получить доступ другие узлы при присоединении к swarm-кластеру.

теперь мыmanager1Создайте рой-сеть в узле и выполните

docker-machine ssh manager1 docker swarm init --listen-addr 192.168.99.100:2377 --advertise-addr 192.168.99.100

Вернуть ответ:

Swarm initialized: current node (23lkbq7uovqsg550qfzup59t6) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-3z5rzoey0u6onkvvm58f7vgkser5d7z8sfshlu7s4oz2gztlvj-c036gwrakjejql06klrfc585r \
    192.168.99.100:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

Это создает роевой кластер, иmanager1Узел в настоящее время присоединен к узлу в качестве менеджера.

Теперь мы ставимworker1иworker2Два узла добавляются в кластер swarm и выполняются на виртуальных машинах двух узлов соответственно.docker swarm join --token ..Просто:

docker-machine ssh worker1 docker swarm join --token \
    SWMTKN-1-3z5rzoey0u6onkvvm58f7vgkser5d7z8sfshlu7s4oz2gztlvj-c036gwrakjejql06klrfc585r \
    192.168.99.100:2377
This node joined a swarm as a worker.
docker-machine ssh worker2 docker swarm join --token \
    SWMTKN-1-3z5rzoey0u6onkvvm58f7vgkser5d7z8sfshlu7s4oz2gztlvj-c036gwrakjejql06klrfc585r \
    192.168.99.100:2377
This node joined a swarm as a worker.

Выполнить на любом узлеdocker node lsВы можете просмотреть все узлы в текущем кластере целиком:

docker-machine ssh manager1 docker node ls
NAME     ACTIVE    DRIVER       STATE     URL                         SWARM   DOCKER    ERRORS
manager1   -       virtualbox   Running   tcp://192.168.99.100:2376           v1.12.3   
worker1    -       virtualbox   Running   tcp://192.168.99.101:2376           v1.12.3   
worker2    -       virtualbox   Running   tcp://192.168.99.102:2376           v1.12.3

Создайте межхостовую сеть

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

использоватьdocker network lsВы можете просмотреть все сети, в которых участвует текущий хост:

docker-machine ssh manager1 docker network ls
NETWORK ID         NAME            DRIVER          SCOPE
764ff31881e5        bridge          bridge          local                  
fbd9a977aa03        host            host            local               
6p6xlousvsy2        ingress         overlay         swarm            
e81af24d643d        none            null            local

Где SCOPE — рой, а DRIVER — оверлей, — это общая сеть в узлах кластера. После того, как кластер будет создан, будет общая входящая сеть по умолчанию, теперь давайте создадим еще одну:

docker-machine ssh manager1 docker network create --driver overlay swarm_test

Развертывание службы в межхостовой сети

Развертывание приложения в кластере означает его развертывание в общей сети.услуга.

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

Так как сервисная архитектура Judge_server очень проста, это всего лишь зеркало, поэтому я буду натягивать его прямо на каждый хост здесь:

docker-machine ssh manager1 docker pull registry.cn-qingdao.aliyuncs.com/marklux/judge_server:1.0
docker-machine ssh worker1 docker pull registry.cn-qingdao.aliyuncs.com/marklux/judge_server:1.0
docker-machine ssh worker2 docker pull registry.cn-qingdao.aliyuncs.com/marklux/judge_server:1.0

Далее, это весовое шоу, мы используемmanager1Node, запустите наши сервисы в общей сети

docker service create --replicas 3 --name judge_swarm -p 8090:8090 --network=swarm_test registry.cn-qingdao.aliyuncs.com/marklux/judge_server:1.0

Эта команда кажется очень похожейdocker run? Да, конечной целью swarm является сделать управление кластером таким же простым, как управление одним докер-сервером!

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

Когда узел в сервисе зависает, рой будет искать оставшиеся доступные узлы в кластере и заменять его. То есть рой будет динамически планироваться, всегда поддерживая работу службы на 3 узлах.

-p используется для предоставления порта хосту, чтобы мы могли получить к нему доступ.

--network используется для указания, в какой сети развернута служба.

сейчас наmanager1Узлы используютdocker service lsЧтобы просмотреть службы в кластере:

docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                                       PORTS
kofcno637cmq        judge_swarm         replicated          3/3                 registry.cn-qingdao.aliyuncs.com/marklux/judge_server:1.0   *:8090->8090/tcp

Теперь мы пытаемся получить доступ к 192.168.99.100:8090/ping локально, и мы можем получить ответ Фактически, теперь мы можем изменить ip наworker1илиworker2Да, результаты ответов такие же, потому что все ноды в это время уже находятся в общей сети кластера

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

Остальная проблема

На данный момент развертывание кластера завершено, но у нас осталось нерешенным несколько проблем:

  • Динамическое добавление и удаление узлов кластера не очень удобно, что затрудняет управление сервером оценки проблем на веб-стороне, конечно, это можно реализовать через REMOTE API докера, но сложность относительно высока.
  • Синхронизации файлов между узлами кластера добиться непросто, вам может потребоваться написать собственные скрипты для синхронизации или использованияrsyncуслуги, такие как
  • Swarm очень подходит для быстрого построения большого количества кластеров для реализации бизнес-процессов, но в случае всего нескольких машин это похоже на «убить курицу ножом».