Разработка, публикация и использование простого облачного приложения для Windows Azure

Локальный запуск облачного приложения на машине разработчика

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

В результате данной фазы разработки создается Web-страница на локальной машине (IP-адрес которой, как известно, равер условному значению 127.0.0.1), и данная Web-страница интерпретируется браузером, визуализируя текст нашего сообщения

увеличить изображение
Рис. 20.6. Запуск облачного приложения на машине разработчика,с эмуляцией облака

Публикация приложения в облаке

Теперь, для того, чтобы облачное приложение можно было вызывать извне (через Web), по URL-адресу, который был бы автоматически присвоен приложению интегрированной средой VS 2010 и (или) средствами Windows Azure, - приложение должно быть опубликовано в облаке как общедоступный Web-сервис. Публикация информации о разработанном приложении производится в особых форматах, детали которых, однако, разработчику знать не требуется, так как файлы для представления пакета в облаке автоматически генерируются средой VS 2010. Разработчик должен помнить только имя своего проекта (решения – solution) Visual Studio и место его расположения на докальных дисках. Причем последнее подсказывает ему среда: после сборки проекта среда Visual Studio выводит на экран директорию, где она разместила пользовательский проект, и рекомендует пользователю (разработчику приложения) эту директорию запомнить. На рис. 20.7 представлен этап publish (публикация), на котором разработчик приложения выбирает и сообщает среде VS 2010 директорию, где находится его проект WindowsAzureProject3, и выбирает пункт контекстного меню Publish (опубликовать). Вот и все, что требуется от разработчика, чтобы выполнить сложнейшие действия по публикации разработанного им приложения в облаке.

увеличить изображение
Рис. 20.7. Публикация приложения в облаке средствами Visual Studio

Развертывание приложения в облаке

Следующий этап разработки – развертывание (deployment) приложения в облаке. В простейшем варианте, как в рассматриваемом примере, развертывание – это создание пакета специального формата, в который упаковывается информация о приложении. Данный случай рекомендуется выбирать путем выбора пункта Create Service Package Only в окне "Deploy Windows Azure Project" (рис. 20.8).

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

Поиск и указание директории, из которой происходит развертывание

При развертывании необходимо указать, из какой директории (расположенной на локальной машине) фактически происходит развертывание сервиса (рис. 20.9). Фактически развертывание означает, что теперь разработанное облачное приложение (как сервис) доступно в Web. Вот истинное воплощение принципа Software as a Service (SaaS)!

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

Отслеживание развернутого приложения в облаке с помощью Azure AppFabric

Работоспособность развернутого в облаке приложения можно проверить средствами Azure AppFabric, выбрав пункт Работоспособность развернутого приложения. Выдается информация о типе развертывания и состоянии развернутого приложения (рис. 20.10). Выдаются также важные для пользователя предупреждения, например, о том (как в данном примере), что на каждую роль имеется только по одному экземпляру приложения. Говорится также о том, что надежность сервиса – не стопроцентная, поэтому рекомендовано дублировать функции, т.е. иметь на каждое необходимое приложение как минимум по две роли. Напомним, что роль – это процесс, в котором исполняется приложение. Не будем забывать о том, что это – серверный код, и число запросов к сервису может быть очень велико, т.е. возможны отказы. Чтобы уменьшить риск отказов, и рекомендуется иметь как минимум две роли на каждое (серверное) приложение.

увеличить изображение
Рис. 20.10. Отслеживание развернутого приложения в облаке с помощью Azure AppFabric

Удаление предыдущего развернутого приложения (при нехватке ресурсов)

Если не хватает ресурсов текущей подписки, приходится удалять второе развернутое приложение (в данном примере – приложение safonov-test2, рис. 20.11).

увеличить изображение
Рис. 20.11. Удаление предыдущего развернутого приложения (при нехватке ресурсов