Чтобы завершить эту серию, я хочу рассказать о последнем шаге настройки, который выделен ниже на общей схеме архитектуры, которую я представил в первом посте .
На этом этапе кластер Couchbase доступен только через удаленный рабочий стол (RDP) или через приложение TapMap, развернутое в той же виртуальной сети. Я могу увидеть текущую конфигурацию конечной точки RDP через портал, посетив вкладку конечных точек одной из кластерных виртуальных машин Couchbase. Также обратите внимание, что может быть задано отображение общего порта на частный в этом случае общедоступная конечная точка RDP отображается не на традиционном порте 3389, а на «случайном» из 59485, что делает ее чуть менее доступной для обнаружения анализатором порта.
Прямо сейчас любые административные задачи, которые мне нужно выполнить на кластере Couchbase, требуют от меня запуска сеанса удаленного рабочего стола. Это нормально для демонстрационных целей, но вряд ли я захочу дать своему администратору <вставьте здесь свое программное обеспечение, размещенное на ВМ>> ключи для виртуальных машин Azure, поэтому мне нужно предоставить ему или ей способ удаленной настройки кластера.
Это достигается путем открытия конечных точек виртуальной машины, достаточной для пропуска трафика администратора. Согласно документации Couchbase , это означает открытие порта 8091, который предоставляет доступ через их HTML-портал и интерфейс командной строки на основе REST .
Создание конечной точки виртуальной машины
Создать конечную точку довольно просто: я выбираю Добавить конечную точку в интерфейсе портала, где я могу создать новую конечную точку (или сбалансировать нагрузку с существующей) текущим экземпляром виртуальной машины. Для первого экземпляра виртуальной машины, связанного с облачным сервисом (здесь couchbase.cloudapp.net ), я могу добавить только конечную точку, так как она не существует.
Затем я просто предоставляю имя, а также тип и номер порта. Я могу создать порт UDP или TCP, и поскольку инструменты администрирования Couchbase используют вызовы REST / HTTP, TCP является очевидным выбором здесь. Порт администратора по умолчанию для Couchbase — 8091, поэтому его необходимо указать как частный порт; тем не менее, я могу выставить публичный порт с совершенно другим значением. Здесь я произвольно выбрал 16873.
После создания порта, когда я перехожу на http://couchbase.cloudapp.net:16873, меня приветствует портал администрирования, и я могу управлять кластером серверов удаленно. Couchbase запрашивает идентификатор пользователя и пароль кластера серверов, и это единственные учетные данные, которые необходимо предоставить для доступа к кластеру.
Конфигурация в этой точке сопоставляет все запросы для URL http://couchbase.cloudapp.net:16873 с этим одним экземпляром виртуальной машины в кластере. Это может или не может быть тем, что вы хотите, в зависимости от контекста того, к чему вы обращаетесь в ВМ. В этом сценарии любой из экземпляров может выполнять административные задачи в кластере Couchbase, поэтому я также могу позволить любому экземпляру облачной службы отвечать на запрос, а не только couchbase1.
Для других виртуальных машин в облачной службе я также создаю конечную точку, но на этот раз выберите недавно созданную конечную точку для балансировки нагрузки. На самом деле я могу предоставить другой порт для сопоставления (и имя конечной точки) для каждой отдельной виртуальной машины, участвующей в ротации баланса нагрузки, но в этом случае все созданные мной виртуальные машины были из одного образа и имеют 8091 в качестве администратора Couchbase порт.
Кстати, если вы считаете, что настраивать каждый из этих портов на портале немного утомительно, мы будем правы! И, как и все остальное, что я настраивал через портал в предыдущих постах блога, вы можете использовать командлеты Windows Azure PowerShell, чтобы делать все это из сценария. Есть некоторая кривая обучения , но затраченное время того стоит, так как вы можете выполнить несколько довольно сложных задач конфигурации всего за несколько строк сценария. Вот, например, скрипт для установки конечной точки с балансировкой нагрузки на все экземпляры виртуальных машин в моем кластере Couchbase.
$svcName = "couchbase"
$publicPort = 16873
$endPointName = $svcName + "Admin"
$LBSetName = $endPointName + "-" + $publicPort
foreach ($VM in Get-AzureVM -ServiceName $svcName)
{
Add-AzureEndpoint -Name $endPointName -LBSetName $LBSetName `
-Protocol tcp -PublicPort $publicPort -LocalPort 8091 `
-ProbeProtocol http -ProbePort $publicPort -ProbePath "/" `
-VM $VM |
Update-AzureVM
}
эпилог
Итак, я закончил! Теперь у меня есть работающее приложение смешанного режима, состоящее из приложения ASP.NET, работающего в двух экземплярах веб-роли Windows Azure в одной подсети виртуальной сети Windows Azure, которое взаимодействует с кластером Couchbase, работающим на трех экземплярах виртуальной машины во второй подсети. Уф!
Хотя я многому научился, работая с Couchbase и ASP.NET, я надеюсь, что вы сможете увидеть помимо использования этих конкретных технологий архитектурные шаблоны и практики, которые вы можете адаптировать для своего собственного приложения, независимо от того, используете ли вы PHP, Node.js, Mongo, SQL Server или любое другое программное обеспечение, которое вы можете развернуть и запустить в облаке Windows Azure.