Рис. 1. Создание нового сайта
После развертывания Web-сайта перейдем на стандартную страницу, которая разворачивается автоматически.
Рис. 2. Страница управления сайтом
Рис. 3. Развернутый сайт
Вернемся на панель управления Web-сайтом и нажмем на ссылку Download publish profile для того, чтобы загрузить профиль публикации, который будет использоваться в Visual Studio 2012 для развертывания Web-сайта.
Запустим Visual Studio 2012 в режиме администратора и создадим новый проект ASP.NET MVC 4, нажав New Project и выбрав тип проекта ASP.NET MVC 4 Web Application.
Рис. 4. Создание проекта на MVC4 в Visual Studio 2012
Выберем Internet Application. Нажмем правой кнопкой мыши на имени проекта и выберем Publish.
Рис. 5. Развертывания приложения
В диалоговом окне Publish Web нажмем кнопку Import и выберем загруженный ранее профиль публикации. После процесса импортирования нажмем Publish для развертывания проекта в Windows Azure Web Sites.
Рис. 6. Выбор профиля публикации
Рис. 7. Развертывания приложения
Зайдем на Web-сайт.
Рис. 8. Интерфейс развернутого сайта
Развертывание приложения в Windows Azure Cloud Services
Создадим на основе Web-сайта облачный сервис и загрузим его в Windows Azure Cloud Services. Для этого создадим пустое решение (Blank Solution), нажмем правой кнопкой на имени решения и выберем Add Windows Azure Cloud Service Project.
Рис. 9. Созданиев Visual Studio проекта Windows Azure Cloud Service
Дальше необходимо добавить в облачный проект созданный ранее Web-сайт. Для этого добавим Web-сайт в решение, после чего, нажав правой кнопкой на директории Roles облачного проекта, выберем Add Web Role Project in solution. Выберем IntuitAzureWebsite.
Рис. 10. Добавление Web-роли
Нажмем F5 для запуска локального эмулятора вычислений Windows Azure.
Рис. 11. Запуск эмулятора
После запуска локального эмулятора запустится стандартный браузер со страницей Web-сайта.
Закроем окно браузера и добавим новый проект Worker-роли, который будет представлять фоновый сервис-обработчик. Для этого нажмем правой кнопкой на директории Roles и выберем Add New Worker Role Project.
Рис. 12. Добавление Worker-роли
Для развертывания в Windows Azure Cloud Services создадим новый облачный сервис, нажав на портале управления NEW | COMPUTE | CLOUD SERVICE | QUICK CREATE. Введем DNS-имя нового облачного сервиса.
Рис. 13. Создание нового облачного сервиса
Для развертывания облачного сервиса в облако нажмем правой кнопкой на названии облачного проекта и выберем Publish | Sign in to download credentials для загрузки профиля публикации.
Импортируем загруженный профиль публикации в Visual Studio 2012. Выберем созданный облачный сервис intuitazurecloudservice.
Рис. 14. Развертывания облачного сервиса
Нажмем Publish и дождемся развертывания проекта, которое может занять до 10 минут.
Перейдем на развернутый проект в браузере, чтобы увидеть стандартную страницу Web-роли облачного сервиса.
Рис. 15. Интерфейс развернутого проекта
Базовые сервисы облачной платформы Windows Azure – Cloud Services и Web Sites – предоставляют разработчику возможность быстрого развертывания как нового, так и проектируемого приложения. Используемый инструментарий, кроме Windows Azure SDK и Windows Azure Tools for Visual Studio, и опыт использования практически не отличаются от того, что происходит в локальной среде.
2. ЗАДАНИЕ К ПРАКТИЧЕСКОМУ ЗАНЯТИЮ 2.
По приведенному ходу работы создать новый сценарий и новый сервис работы в Windows Azure.
ПРАКТИЧЕСКОЕ ЗАНЯТИЕ 3
Разработка приложений с WindowsAzureCloudServices.
Разработка приложений с Windows Azure Cloud Services
Базовым сервисом платформы Windows Azure является Cloud Services (ранее Hosted Services). В таблицу 1 сведены данные о том, каким образом реализует ту или иную функцию или сценарий Cloud Services и Web Sites.
Таблица 1. Сравнительные анализ функциональности Web Sites и Cloud Services
|
|
Web Sites
|
Cloud Services
|
Модель использования
|
SaaS
|
PaaS
|
Рекомендуемый тип приложений
|
Web-приложения, состоящие из клиентской разметки и какой-либо обработки на стороне сервера. Можно масштабировать весь сервис, но не часть его.
|
Приложения, каждый компонент которых необходимо масштабировать отдельно от других. Например, в момент большой нагрузки можно масштабировать только обработчик на стороне сервера, конвертирующий видеофайлы, но оставить количество экземпляров для веб-интерфейса.
|
Модель развертывания
|
Quick Create – создание пустого сайта,
Quick Create with Database – создание пустого сайта и ассоциированной с ним базы данных MySQL/Windows Azure SQL Database,
Using the Gallery – создание сайта из подготовленного образа галереи образов Windows Azure Web Sites
|
Web-роль – слой приложения, выполняющий роль веб-интерфейса, взаимоействующего с пользователем,
Worker-роль – слой приложения, выполняющий роль обработчика данных.
|
Сложность миграции существующего приложения
|
Низкая. Существующее веб-приложение можно мигрировать в Web Sites без изменений.
|
Средняя/высокая. В зависимости от ситуации может быть необходимо переосмысление архитектуры существующего приложения для эффективного разделения на Web/Worker-роли.
|
Администрирование
|
Низкая степень контроля – масштабирование сервиса, сервисы FTP, Team Foundation Services, Git. Запуск веб-сайта (например, WordPress или Drupal) можно осуществить в несколько кликов мышкой.
|
Средняя степень контроля – администраторский доступ, доступ по удаленному рабочему столу RDP к экземплярам ролей, запуск кода с повышенными правами, start-up задачи. Возможна автоматизация администрирования.
|
Возможность развертывания приложений с использованием Git/FTP
|
Да
|
Да
|
Поддержка распространенных языков программирования
|
IIS-совместимые технологии, ASP.NET, ASP, Node.js, PHP
|
IIS-совместимые технологии, ASP.NET, ASP, Node.js, PHP, Java
|
Поддержка MySQL
|
Встроенная, с использованием портала управления
|
Есть, но с использованием ClearDB. На портале управления интегрировать сервис с MySQL нельзя.
|
Стенды (тестовая, production)
|
Нет
|
Да
|
Доступ по RDP
|
Нет
|
Да
|
Возможность интеграции сторонних фреймворков
|
Нет
|
Да
|
Ориентировочное время развертывания
|
<1 минуты
|
Несколько минут
|
Установка программного обеспечения на сервер
|
Нет
|
Через подключение RDP, Startup-задачи
|
Итак, основное отличие, насколько следует из таблицы 1, заключается в основном сценарии, подходящем для каждого из сервисов – если в случае с Web Sites это простое приложение (необязательно личная веб-страница или сайт, состоящий из нескольких элементов), которое в случае масштабирования будет претерпевать изменения в целом, то в случае с Cloud Services это может быть то же самое приложение, но несколько переосмысленное в сторону ролевой модели и гибкого масштабирования.
Рис. 1. Стандартная модель MVC
Для того, чтобы понять принцип работы ролевой модели, можно взять в качестве примера типичное Web-приложение, написанное с использованием паттерна разработки MVC (Model-View-Controller). Типичное Web-приложение состоит из представления (Web-интерфейса пользователя), контроллера (слоя бизнес-логики, служащего также прослойкой между представлением и слоем доступа к источнику данных) и слоем доступа к источнику данных. Архитектура большинства Web-приложений на высоком уровне может быть сведена именно к такому разделению. Конечный же пользователь имеет доступ к приложению по конечной точке доступа (ссылке) по HTTP либо HTTPS.
Рис. 2. Архитектура Cloud Service
В контексте ролевой модели будет выглядеть следующим образом – представление меняет свое название на Web-роль, контроллер – на Worker-роль, слой доступа к источнику данных же может быть реализован внутри отдельной Worker-роли. Для получения данных от представления (Web-роли) обработчиком-контроллером (Worker-ролью) традиционно используется Middleware в виде сервиса очередей. При этом сервисом Middleware может выступать как Windows Azure Storage Queue, так и Windows Azure Service Bus (о которых будет рассказано в соответствующих главах курса). Использование Middleware приводит к одной из best practice разработки отказоустойчивых распределенных приложений – вместо разработки тесносвязанной системы (в которой потеря одного из компонентов, например, Web-роли, будет означать неработоспособность всей системы и потерю данных) разработчик может использовать Middleware в режиме брокера (Brokered Messaging) – Web-роль не знает о том, сколько обработчиков обрабатывает приходящие с нее сообщения, есть ли эти обработчики, находятся ли они оффлайн или онлайн, и, если такого не предусмотрено, не знает о статусе обработки этих сообщений, кладя при этом сообщения в сервис Middleware (очередь), где они хранятся до тех пор, пока не собираются сборщиком мусора либо не обрабатываются экземплярами Worker-роли. При этом связность системы значительно ослабляется – выход из строя части системы с большей степенью вероятности не приведет к сбою всей системы.
Как уже было сказано, для каждой из ролей существует определенное количество экземпляров, выполняющих аналогичную копию роли. Это значит, что пользователь, войдя по ссылке на Web-сайт, может попасть как на первый экземпляр Web-роли, так и на второй, или на любой, находящийся в ротации балансировщика нагрузки. Это накладывает серьезные ограничения на некоторые привычные практики разработки – например, необходимо учитывать, что балансировщик нагрузки Windows Azure не является "липким", то есть нет гарантии, что пользователь, зайдя на сайт с утра и попав на экземпляр Web-роли №1, вечером попадет на тот же самый экземпляр. Учитывать это необходимо тогда, когда разработчиком реализуется механизм хранения пользовательских данных, например, сессии. В том случае, если данные сессии сохраняются локально на экземпляре Web-роли, с увеличением количества экземпляров будет увеличиваться степень вероятности того, что пользователь не увидит своих данных при следующем входе. В таких случаях рекомендуется использовать внешнее хранилище. |
