Выполнение 1000 Docker Redis-контейнеров менее чем за 15 минут на кластере из 5 облачных серверов с 2 ГБ памяти каждый

Фон

Хотя переносимость приложений (т. Е. Возможность запускать одно и то же приложение на любом хосте Linux) по-прежнему является основным драйвером для принятия контейнеров Linux, еще одним ключевым преимуществом является возможность оптимизировать использование сервера, чтобы вы могли использовать каждый бит вычислений. Конечно, для вышестоящих сред, таких как PROD, вы все равно можете выделить более чем достаточно ЦП и памяти для вашей рабочей нагрузки — но в средах DEV / TEST, которые обычно представляют собой большую часть потребления вычислительных ресурсов в организации, оптимизация использования сервера может привести к значительной экономии средств.

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

• Пользователь может зарегистрировать любой хост Linux, работающий в любом месте, запустив автоматически сгенерированный скрипт для установки агента DCHQ, а также Docker и программно-определяемый сетевой уровень (необязательно). Эта задача может быть автоматизирована программно с помощью нашего REST API для создания «серверов Docker» ( https://dchq.readme.io/docs/dockerservers )
• В качестве альтернативы DCHQ интегрируется с 13 облачными провайдерами, что позволяет пользователям автоматически наращивать виртуальную инфраструктуру в vSphere, OpenStack, CloudStack, Amazon Elastic Cloud Computing, Google Compute Engine, Rackspace, DigitalOcean, SoftLayer, Microsoft Azure и многих других.

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

• Сеть — пользователь может выбрать либо сеть Docker, либо сеть, определяемую программным обеспечением, для облегчения связи между контейнерами между несколькими хостами.
• Аренда — пользователь может указать, когда истекает срок действия серверов в этом кластере, чтобы DCHQ мог автоматически уничтожить эти серверы.
• Политика размещения — пользователь может выбрать из ряда политик размещения, таких как политика на основе близости, циклический перебор или политика по умолчанию, которая является политикой размещения на основе емкости, которая будет размещать рабочую нагрузку Docker на хосте, который имеет достаточные вычислительные ресурсы. ,
• Квота — пользователь может указать, придерживается ли этот кластер профилей квоты, назначенных пользователям и группам. Например, в DCHQ.io всем пользователям назначается квота 8 ГБ памяти.
• Политика автоматического масштабирования — пользователь может определить политику автоматического масштабирования для автоматического добавления серверов, если в кластере не хватает вычислительных ресурсов для удовлетворения потребностей разработчика в новых развертываниях приложений на основе контейнеров.
• Детальный контроль доступа — администратор клиента может определить контроль доступа к кластеру, чтобы определить, кто может развертывать в нем приложения на основе контейнеров. Например, разработчик может зарегистрировать свой локальный компьютер и пометить его как частный. Администратор клиента, с другой стороны, может совместно использовать кластер с определенной группой пользователей или со всеми пользователями арендатора.

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

После подготовки приложения пользователь может отслеживать ЦП, память и & I / O запущенных контейнеров, получать уведомления и оповещения и выполнять операции второго дня, такие как запланированное резервное копирование, обновление контейнеров с использованием подключаемых модулей сценариев BASH и масштабирование. In / Out. Кроме того, готовые рабочие процессы, которые облегчают непрерывную доставку с Jenkins, позволяют разработчикам обновлять файл WAR Java работающего приложения, не нарушая существующие зависимости и интеграции.

В этом блоге мы расскажем о развертывании 1000 контейнеров Redis менее чем за пятнадцать минут на кластере из 5 облачных серверов на SoftLayer от IBM. Мы покроем:

• Создание шаблона приложения для кластеризованного Redis, который можно повторно использовать на любом хосте Linux, работающем где угодно
• Предоставление базовой инфраструктуры в любом облаке (примером в этом блоге является SoftLayer)
• Развертывание кластера Redis программно с использованием REST API DCHQ
• Мониторинг процессора, памяти и ввода / вывода работающих контейнеров

Создание шаблона приложения для кластера Redis

После входа в DCHQ (либо размещенную версию DCHQ.io, либо локальную версию) пользователь может перейти к « Управление» > « Шаблоны» и нажать кнопку « +» , чтобы создать новый шаблон Docker Compose .

Ради этого теста на масштабируемость мы создали простой кластер Redis. Вы заметите, что параметр cluster_size позволяет вам указать количество контейнеров для запуска (с теми же зависимостями приложения).

Параметр host позволяет указать хост, который вы хотите использовать для развертывания контейнера. Таким образом, вы можете обеспечить высокую доступность кластеров серверов приложений на разных хостах (или в разных регионах) и соблюдать правила соответствия, чтобы база данных работала, например, на отдельном хосте. Вот значения, поддерживаемые для параметра хоста:

• host1, host2, host3 и т. д. — случайным образом выбирает хост в дата-центре (или кластере) для развертывания контейнера
• <IP-адрес 1, IP-адрес 2 и т. Д.> — позволяет пользователю указывать фактические IP-адреса для использования при развертывании контейнеров.
• <Имя хоста 1, Имя хоста 2 и т. Д.> — позволяет пользователю указать фактические имена хостов, которые будут использоваться для развертываний контейнеров.
• Подстановочные знаки (например, «db- *» или «app-srv- *») — для указания подстановочных знаков для использования в имени хоста

Предоставление базовой инфраструктуры в любом облаке

После сохранения приложения пользователь может зарегистрировать облачного провайдера для автоматизации предоставления и автоматического масштабирования кластеров на 13 различных конечных точках облака, включая vSphere, OpenStack, CloudStack, Amazon Web Services, Rackspace, Microsoft Azure, DigitalOcean, HP Public. Облако, IBM SoftLayer, Google Compute Engine и многие другие.

Сначала пользователь может зарегистрировать облачного провайдера для Rackspace (например), перейдя в « Управление» > « Repo & Cloud Provider» и затем нажав кнопку « +» , чтобы выбрать SoftLayer (IBM) . Необходимо предоставить ключ API SoftLayer, который можно получить в разделе «Настройки учетной записи».

Затем пользователь может создать кластер с политикой автоматического масштабирования для автоматического запуска новых облачных серверов. Это можно сделать, перейдя на страницу « Управление > Кластеры» и затем нажав кнопку « +» . Вы можете выбрать политику размещения на основе емкости, а затем Weave в качестве сетевого уровня, чтобы обеспечить безопасную защищенную паролем связь между контейнерами между несколькими узлами в кластере.

Теперь пользователь может подготовить несколько облачных серверов во вновь созданном кластере, перейдя в « Управление» > « Хосты» и затем нажав кнопку « +» , чтобы выбрать SoftLayer (IBM) . После выбора поставщика облачных услуг пользователь может выбрать необходимый регион, размер и изображение. Порты могут быть открыты на новых облачных серверах (например, 32000-59000 для Docker, 6783 для Weave и 5672 для RabbitMQ). Затем выбирается кластер, и можно указать количество облачных серверов.

Развертывание кластера Redis программно с использованием REST API DCHQ

После подготовки облачных серверов пользователь может программно развернуть кластер Redis с помощью API REST DCHQ. Чтобы упростить использование API, пользователю необходимо выбрать кластер, созданный ранее, в качестве кластера по умолчанию. Это можно сделать, перейдя в «Имя пользователя»> «Мой профиль» и выбрав нужный кластер по умолчанию.

После выбора кластера по умолчанию пользователь может просто выполнить следующий скрипт curl, который вызывает API «deploy» ( https://dchq.readme.io/docs/deployid ).

В этом простом скрипте curl у нас есть следующее:

• А для цикла, от 1 до 100
• На каждой итерации мы развертываем кластеризованное приложение Redis, используя кластер по умолчанию, назначенный пользователю.
• user% 40dchq.io используется для [email protected], где символ @ заменяется на шестнадцатеричный% 40
• @ между паролем и хостом не заменяется шестнадцатеричным
• <id> относится к идентификатору приложения кластера Redis. Это можно получить, перейдя в Библиотеку > Настроить для кластера Redis. Идентификатор должен быть в URL
• сон 8 используется между каждой итерацией. Это составляет 800 секунд — или 13,3 минуты.

Вы можете попробовать этот скрипт curl самостоятельно. Вы можете установить DCHQ On-Premise или зарегистрироваться на DCHQ.io Hosted PaaS .

Мониторинг использования процессора, памяти и ввода-вывода кластера, серверов и запущенных контейнеров

DCHQ позволяет пользователям контролировать процессор, память, диск и ввод / вывод кластеров, хостов и контейнеров.

• Для мониторинга кластеров вы можете просто перейти к « Управление»> «Кластеры»
• Для мониторинга хостов вы можете просто перейти в « Управление»> «Хосты»> «Значок мониторинга».
• Для мониторинга контейнеров вы можете просто перейти к Live Apps> Значок мониторинга

Мы отслеживали производительность хостов и кластера до и после запуска 1000 контейнеров.

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

После раскручивания 500 контейнеров мы сделали скриншоты графиков производительности для хостов. Вы можете видеть, что самая высокая загрузка ЦП была около 18%, а самая высокая загрузка памяти была на 49% .

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

После раскручивания 1000 контейнеров мы сделали скриншоты графиков производительности для хостов. Вы можете видеть, что самая высокая загрузка процессора составляла около 31%, а самая высокая загрузка памяти была на уровне 75% .

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

Вот представление всех запущенных 100 кластеров Redis (где каждый кластер имел 10 контейнеров).

Оставив эти приложения включенными на несколько часов, мы сделали снимки экрана нашего кластера. Вы можете видеть, что загрузка процессора составила 4%, а загрузка памяти — 81% . Это агрегированные показатели для 5 серверов в кластере.

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

Затем мы углубились в один из серверов, чтобы посмотреть историческую производительность — где использование памяти снизилось с почти 90% до 38% .

Вывод

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

Зарегистрируйтесь БЕСПЛАТНО на сайте http://DCHQ.io или загрузите DCHQ On-Premise, чтобы получить доступ к готовым многоуровневым шаблонам Java-приложений, а также к функциям управления жизненным циклом приложений, таким как мониторинг, обновление контейнеров, масштабирование и развертывание и постоянная доставка.