Микросервисная архитектура у нас прочно ассоциируется с контейнерами и Linux. Однако, что делать, если у нас есть приложение на базе микросервисной архитектуры для Windows?
Обычно все считают, что микросервисы — это только про контейнеры, поэтому они строят свои приложения на основе облачного подхода, чтобы они могли легко запускаться на любой платформе с использованием контейнеров. Конечно, контейнеризация — это достойный способ разработки облачного нативного приложения, особенно при интеграции его с такими оркестраторами, как Kubernetes. Она снимает с нас много накладных расходов, таких как: масштабирование, предотвращение отказов, развертывание и т. д., но это не означает, что микросервисами можно управлять только в контейнерной экосистеме. Микросервисы — это идеология или образ мышления при проектировании приложений, а контейнеризация — это средство, поддерживающее эту идеологию.
Допустим, у нас есть приложением на базе.NET, которое может работать только на платформе Windows. Еще хуже, если у нас есть часть микросервисов, работающих под управлением Docker и несколько важных компонентов, работающих под.NET. Очевидно, мы могли бы использовать контейнеры Windows, но с ними слишком много различных «странностей». Другой способ — использовать статические виртуальные машины, но это будет в определенной степени пустая трата ресурсов.
Решение Nomad
Kubernetes — это система оркестровки, предназначенная для управления экосистемой контейнеров, но, мы хотели оркестровать процесс Windows (в основном процессы на базе веб‑сервера windows IIS). То есть можно сказать, что Nomad — это механизм оркестровки, который поддерживает не только контейнерные, но и виртуализированные и автономные приложения, включая Docker, Java, IIS на Windows и т. д.
Nomad работает по модели, основанной на плагинах, в которой вы можете использовать существующие плагины, такие как Docker, Java, IIS, или написать собственный плагин, используя Golang‑SDK.
Однако, Nomad не поддерживает веб‑сервер Windows IIS по умолчанию, для этого нам нужно установить плагин на клиентские узлы Nomad. Далее в статье будет рассматриваться использование плагина для IIS, разработанный Roblox Developers.
Реализация с помощью Nomad
Имеющийся плагин для IIS также не имел все необходимые для эффективной оркестрации компоненты. Например, в нем отсутствовало ограничение ресурсов на IIS, переменные среды и некоторые другие нужные функции.
При этом, базовые функции механизма оркестровки, такие как масштабирование, отказоустойчивость, мониторинг метрик и т. д. уже поддерживались Nomad, поэтому в целом он устраивал команду разработки, необходимо было только дополнить его функционал. В результате плагин был доработан и его можно загрузить по той ссылке.
Основной замысел заключался в следующем, с помощью единого сервера Nomad мы сможем управлять как компонентами, работающими под управлением Docker, так и непосредственно процессами IIS.
Установка Nomad
Nomad можно установить как на Windows, так и на Linux. Установка на Windows проще в том плане, что для нее достаточно загрузить выполнимый файл.
Далее необходимо либо прописать в переменной среды PATH путь к выполнимому файлу, либо поместить этот файл в один из каталогов, указанных в данной переменной:
export PATH=/usr/local:/opt/bin:/opt/hashicorp
Также, под Windows можно использовать пакетный менеджер Chocolately:
$ choco install nomad
Убедиться в корректности настройки можно с помощью команды:
$ nomad -v
Мы не будем подробно рассматривать настройку кластера Nomad и его взаимодействия с серверами Docker. При необходимости всю эту информацию можно найти на сайте Hashicorp.
Мы перейдем к рассмотрению настроек взаимодействия с IIS. Здесь мы указываем IIS использовать для работы с Nomad представленный ранее драйвер:
job "iis-test" {
datacenters = ["dc1"]
type = "service"
group "iis-test" {
count = 1
restart {
attempts = 10
interval = "5m"
delay = "25s"
mode = "delay"
}
task "iis-test" {
driver = "win_iis"
artifact {
source = "https://github.com/iamabhishek-dubey/nomad-driver-iis/releases/download/v0.4/test-hello-world.zip"
}
config {
path = "${NOMAD_TASK_DIR}\\netcoreapp2.1"
apppool_identity {
identity = "NetworkService"
}
bindings {
type = "http"
resource_port = "httplabel"
}
}
resources {
cpu = 100
memory = 20
network {
port "httplabel" {}
}
}
service {
name = "iis-test"
tags = ["iis-test", "windows-iis-test"]
port = "httplabel"
check {
type = "tcp"
interval = "10s"
timeout = "2s"
}
}
}
}
}После завершения настройки задания для IIS мы можем создать его с помощью пользовательского интерфейса Nomad в нашем кластере.
После того как мы увеличили количество приложений до 2, nomad запустил еще один процесс IIS для приложения. Теперь если мы попытаемся уничтожить один из процессов, Nomad тутже запустит новый процесс, аналогично Kubernetes.
Таким образом мы получили возможность управлять процессами в веб сервере IIS с помощью средств оркестрации, аналогичных Kubernetes.
Заключение
Подумав нестандартно, мы решили проблему и для приложений, не основанных на контейнерах, и добились возможности реализации некоторых базовых функций механизма оркестровки, таких как масштабирование, обеспечение отказоустойчивости и других для приложений на базе Windows.
Целью данной статьи было показать, как можно решить проблему реализации микросервисной архитектуры для приложений, не поддерживающих контейнеризацию. Конечно, подобные ситуации возникают не так часто, и как правило уже при разработке решения закладывается возможность его использования в контейнеризированной среде. Но представленная в статье концепция позволяет использовать микросервисную архитектуру даже там, где нет контенейров.
Таким образом, мы можем использовать микросервисную архитектуру без привязки к таким общепринятым решениям, как Docker и Kubernetes, тем самым расширяя возможности по применению данной архитектуры.
Если тема микросервисов для вас не только теория, но и повседневная практика — приглашаем на открытые технические встречи, где разбираем ключевые архитектурные решения и подводные камни в продакшене.
Темы ближайших уроков: