Какая самая важная особенность любого веб-приложения? Их много, но для меня высокая доступность это самое главное. Именно в этом нам помогает Docker Swarm! Это помогает сделать приложение доступным.
что такое облако службы продаж
В моем предыдущий блог , Я объяснил, как работает Docker Compose. Этот блог о Docker Swarm является продолжением предыдущего, и здесь объясняются преимущества использования Docker Swarm для контейнеризации любого многоконтейнерного приложения.
В случае этого блога Docker Swarm'ed будет использовать только приложение Angular.
Заметка : Метод контейнеризации приложения MEAN Stack такой же.
Итак, что такое Docker Swarm?
Докер Рой это метод создания и поддержки кластера Докеры . Движки Docker могут размещаться на разных узлах, и эти узлы, находящиеся в удаленных местах, образуют Кластер при подключении в режиме Swarm.
Зачем использовать Docker Swarm?
По уже упомянутым причинам! Достижение высокая доступность без простоев - приоритет для каждого поставщика услуг. Сможет ли высокая доступность впечатлить ваших клиентов? Что ж, они не будут впечатлены, если они столкнутся с простоями. Это и ежу понятно.
Другие преимущества Docker Swarm
Как и многие другие сервисы, Docker Swarm автоматически балансировки нагрузки для нас. Следовательно, инженерам DevOps нет необходимости направлять запросы обработки на другие узлы в случае отказа одного из них. Диспетчер кластера автоматически выполнит балансировку нагрузки за нас.
Децентрализованный доступ это еще одно преимущество. Что это значит? Это означает, что менеджер может легко получить доступ ко всем узлам. Менеджер также будет регулярно запрашивать узлы и отслеживать их работоспособность / статус, чтобы справиться с простоями. Однако узлы не могут получить доступ или отслеживать службы, запущенные в других узлах / менеджерах.
Вы можете проверить нет. контейнеров, работающих в узле, увеличить масштаб нет. контейнеров или уменьшать нет. исходя из наших требований, просто выполнив одну команду.
Даже после того, как приложение было развернуто, мы можем выпустить скользящие обновления и убедитесь, что CI (непрерывная интеграция) достигнута. Последовательные обновления выдаются одному узлу за другим, что гарантирует отсутствие простоев и распределение нагрузки между другими узлами в кластере.
Так, что дальше? Сделать очевидное. Начните работу с Docker Swarm, если вы уже работали с Docker или если ваша организация желает поместить надежный веб-сервис в контейнер.
Заметка : Движки Docker устанавливаются на независимых хостах / серверах или на нескольких виртуальных машинах на хосте.
Начало работы с режимом Swarm
Docker Swarm инициируется менеджером, или, позвольте мне сказать так, экземпляр, который запускает кластер Swarm, становится менеджером. Команда для запуска кластера:
$ docker swarm init --advertise-addr ip-адрес
Здесь флаг «–advertise-addr» используется для рекламы себя другим узлам, которые хотят присоединиться к кластеру. IP-адрес менеджера необходимо указать вместе с флагом. Ниже приведен пример снимка экрана.
Когда кластер Swarm инициирован, на стороне менеджера генерируется токен. Этот токен должен использоваться другими узлами для присоединения к кластеру роя.
Как это именно? Скопируйте весь токен, сгенерированный в движке докеров менеджера, вставьте его в механизм докеров узла и выполните его. Выделенная часть скриншота выше - это токен. Когда токен выполняется на рабочем узле, он будет выглядеть, как на скриншоте ниже.
Любой узел, который присоединяется к кластеру, может быть позже повышен до менеджера. Если вы хотите, чтобы движок докеров присоединился в качестве менеджера, выполните следующую команду на стороне менеджера:
$ docker swarm менеджер токенов присоединения
А позже, если вы хотите, чтобы токен для узла присоединился к кластеру, выполните следующую команду:
Узел токена соединения $ docker swarm
Идите вперед и выполните токен на каждом нужном узле, чтобы присоединиться к кластеру. Когда все это будет сделано, вы можете запустить команду docker node list, чтобы проверить, сколько узлов присоединилось к кластеру, а также их статус. Команда такая:
$ docker node ls
Снимок экрана ниже:
Создание образа Docker для приложения Angular
Если все в порядке, мы можем запустить нашу службу Swarm при условии, что Docker Image создан. Образ Docker можно создать из файла Dockerfile. Dockerfile, используемый для создания приложений, приведен ниже:
С узла: 6 ЗАПУСТИТЬ mkdir -p / usr / src / app WORKDIR / usr / src / app КОПИРОВАТЬ package.json / usr / src / app ЗАПУСТИТЬ npm cache clean ЗАПУСТИТЬ npm install COPY. / usr / src / app EXPOSE 4200 CMD ['npm', 'start']
Dockerfile используется для совместного выполнения набора команд для создания настраиваемого образа Docker из базового образа. Как видите, я использовал базовое изображение «Узел: 6». NodeJS - это образ I из Docker Hub с тегом версии 6.
Затем я создаю новый каталог Docker внутри контейнера и делаю его рабочим каталогом внутри моего контейнера.
Я копирую файл package.json со своего локального компьютера в рабочий каталог контейнера. Затем я указываю команды «RUN npm cache clean» и «RUN npm install». npm install команда загружает версию зависимостей, упомянутую в файле package.json.
Затем я копирую все коды проекта с локального компьютера в контейнер, открывая номер порта 4200 для доступа к приложению Angular в браузере, и, наконец, я указываю команду npm start, которая помещает приложение в контейнер.
Теперь, чтобы создать образ Docker на основе этого файла Docker, выполните следующую команду:
$ docker build -t angular-image.
Заметка: Образы Docker должны быть созданы на всех узлах кластера. Без него контейнеры не могут быть запущены в других движках Docker.
html-тег для вставки разрыва строки
Запуск службы Docker Swarm
Учитывая, что наш образ Docker создан, мы можем развернуть контейнер из этого образа. Но мы сделаем что-нибудь получше: создадим из него службу Docker Swarm. Команда для создания службы роя:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 угловой-образ
Здесь флаг «name» используется для присвоения имени моей службе, а флаг «p» используется для открытия порта контейнера для порта хоста. В файле package.json я указал порт контейнера, на котором должно быть размещено приложение Angular. И 4200 в этой команде помогает сопоставить порт 4200 контейнера с портом хоста 4200. «angular-image» - это имя изображения, которое я создал ранее.
Помнить : Когда мы создаем сервис, он может быть размещен на любом движке докеров в кластере. Менеджер роя решит, где он будет размещен. Но независимо от того, на каком узле оно размещено, к приложению можно получить доступ на localhost: 4200 с любого из узлов, подключенных к кластеру.
Как такое возможно? Потому что Swarm внутренне предоставляет номера портов, чтобы они были доступны для всех остальных узлов кластера. Это означает, что порт нет. 4200 на любом узле / диспетчере в кластере будет отображать приложение Angular.
Что теперь? Контейнер активен?
Вы можете проверить, является ли служба контейнером, выполнив команду docker service list. Но развертывание контейнера может занять минуту. Ниже представлена команда:
$ docker service ls
Эта команда выведет список всех сервисов, управляемых кластером Swarm. В нашем случае он должен отображать один активный контейнер. Посмотрите на скриншот ниже для справки.
Здесь REPLICAS = 1/1 указывает, что в кластере есть одна единственная «служба» этого контейнера. А «MODE = replicated» указывает, что служба реплицируется на всех узлах кластера.
Теперь, чтобы определить, на каком узле / диспетчере размещено приложение, мы можем запустить команду docker service ps, за которой следует имя контейнера. Команда такая:
$ docker service ps Angular-App-контейнер
Скриншот того же ниже.
Здесь упоминаются подробности об узле, на котором размещено приложение, а также команда, используемая для запуска службы.
Команда «docker ps» проливает свет на подробности об активном контейнере. Команда такая:
$ docker ps
Посмотрите на скриншот ниже для справки.
Но эта команда будет работать только с диспетчером кластера и узлом, на котором фактически размещена служба.
Чтобы проверить, сколько узлов работает, запустите команду списка узлов. Команда:
$ docker node ls
Чтобы проверить контейнеры, работающие на определенном хосте, выполните команду node ps. Команда:
$ docker node ps
Если вы помните, я ранее упоминал, что служба в настоящее время работает в реплицированном РЕЖИМЕ. Это означает, что служба реплицируется на все узлы кластеров. Как вы думаете, есть альтернатива?
Абсолютно! Есть нечто, называемое глобальным режимом. В этом режиме служба этого контейнера работает на каждом отдельном менеджере в кластере. Не забудьте остановить текущую службу / контейнер, прежде чем запускать другой набор контейнеров.
Команда для этого:
$ docker service rm Angular-App-контейнер
Команда для вращения контейнера в глобальном режиме:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --mode global angular-image
Это создаст 3 службы на 3 узлах в нашем кластере. Вы можете проверить это, выполнив команду docker service list. Снимок экрана ниже.
Когда команда docker service ps будет выполнена, вы увидите что-то вроде этого:
Как видите, там говорится, что режим реплицирован, а количество реплик этого контейнера - 3. Теперь перейдем к лучшей части этого блога.
Чтобы иметь две реплики служб, работающих между тремя контейнерами, мы можем использовать флаг реплики. Посмотрите на команду ниже:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --replicas = 2 angular-image
Вы заметите, что эти 2 службы сбалансированы по нагрузке между тремя узлами в кластере. Запустите команду процесса службы docker, чтобы проверить, в каких узлах активны контейнеры. Посмотрите на скриншот ниже для справки. Контейнеры активны в одном управляющем узле и одном рабочем узле.
Из узла Worker вы можете проверить, запущен ли контейнер, выполнив команду «docker ps».
Docker Swarm для высокой доступности
Теперь, чтобы действительно убедиться, что в нашем кластере имеется высокая доступность, нам нужно испытать сценарий, когда один из узлов выходит из строя, а другие узлы в кластере компенсируют это. Мы можем реализовать этот сценарий, вручную остановив контейнер на одном из узлов с помощью этой команды:
$ docker stop Angular-App-Container
Выполните указанную выше команду на узле: Worker-1, на котором работает контейнер.В диспетчере выполните команду:
$ docker service ps Angular-App-контейнер
Теперь вы заметите, что контейнер теперь работает в узле: Worker-2 и Manager. Однако он был отключен с узла: Worker-1. То же самое видно на скриншоте ниже.
Вот как Высокая доступность Docker Достигнут. яНесмотря на то, что контейнер неактивен в Worker-1, приложение может отображаться на порту с номером 4200 на этом рабочем узле. Это потому, что он внутренне связан с другими узлами кластера и может отображать приложение в браузере.
Высокая доступность после масштабирования служб
Будь то режим репликации или глобальный режим, мы можем увеличить количество служб, работающих в нашем кластере. И даже после масштабирования мы сможем сохранить высокую доступность. Классно, не правда ли?
Но возвращаясь к нашей точке зрения, давайте посмотрим, насколько просто увеличить количество сервисов в нашем кластере. Предполагая, что у нас есть 2 или 3 реплики в нашем кластере, давайте увеличим количество сервисов до 5, просто запустив одну команду. Команда такая:
$ docker service scale Angular-App-Container = 5
Снимок экрана ниже.
приведение типа double к int java
Запустив команду docker service list, вы можете заметить, что количество реплик теперь равно 5. А, выполнив команду docker service ps вместе с именем службы, вы можете увидеть, как 5 служб балансируются по нагрузке и распределяются по 3 узлам. . Команды:
$ docker service ls $ docker service ps Angular-приложение-контейнер
И, наконец, при настройке Docker Swarm, если вы не хотите, чтобы ваш менеджер участвовал в процессе и занимал его только управлением процессами, мы можем избавить менеджера от размещения любого приложения. Потому что так это работает в мире, не так ли? Менеджеры предназначены только для управления другими работниками. В любом случае, команда для этого:
$ docker node update - доступность слива Manager-1
Вы можете проверить, принимает ли менеджер теперь участие в кластере, выполнив команду docker node list и команду docker service ps:
$ docker node ls $ docker service ps Angular-приложение-контейнер
Теперь вы можете заметить, что службы контейнера были разделены между узлами Worker, а узел Manager фактически исключен из контейнеров любой службы. Скриншот ниже.
Итак, это конец этому блогу о Docker Swarm. Я надеюсь, что этот блог объяснил, насколько важно реализовать режим Swarm для достижения высокой доступности. Следите за обновлениями блогов в этой серии руководств по Docker.
Вы также можете посмотреть видео ниже, чтобы понять, как работает Docker Swarm. Все концепции, описанные выше, были рассмотрены в видео.
Docker Swarm для высокой доступности | Учебное пособие по Docker | Учебник DevOps
Теперь, когда вы узнали о Docker, ознакомьтесь с от Edureka, надежной компании по онлайн-обучению с сетью из более чем 250 000 довольных учащихся по всему миру. Этот учебный курс Edureka Docker Certification Training помогает учащимся получить опыт внедрения Docker и освоить его.
Есть вопрос к нам? Пожалуйста, укажите это в комментариях, и мы свяжемся с вами.