Java и облако Microsoft — краткие очерки


Что нужно для того, чтобы запустить свое приложение Java в облаке Microsoft? Сколько усилий надо затратить и человекочасов разработчика для того, чтобы хотя бы протестировать проект и решить, стоит ли вообще его мигрировать, или стоит подождать или вообще отложить переезд. Эта небольшая статья призван заполнить нишу размером в микрон и провести краткий экскурс в сегодняшнюю ситуацию с Java на Microsoft Azure.

В Microsoft Azure есть несколько опций по зaпуску Java-приложений. До 2012 года, когда платформа содержала полноценную реализацию только одной модели поставки (PaaS), разработчик мог запустить Java-приложение, вручную настроив скрипты развертывания JDK и сервера приложений и упаковав Java-приложение в контейнер Cloud Services. Получалась абстракция того, что было придумано для .NET, для приложения, написанного с использованием других принципов — берем контейнер Cloud Service, прописываем в конфигурационных файлах, что и где лежит, и проект готов. Отсюда проистекали многие неудобства, в том числе самое главное — необходимость ручной настройки нескольких скриптов — не все разработчики имеют опыт и желание заниматься этим трудоёмким делом (автор занимался этим и с тех пор не имел большого желания продолжать). В 2012 году в Microsoft Azure было анонсировано и, позднее, развернуто в GA новое предложение — реализация IaaS: разработчик берет виртуальную машину, устанавливает в неё весь необходимый софт и производит все сопутствующие настройки. Неудобство состоит в том, что, уйдя от ручной настройки конфигурационных скриптов, разработчики пришли к необходимости ручной настройки веб-сервера на виртуальной машине. Концептуально — серьёзный шаг. Практически — шаг, часто ненужный. Этот вариант удобен для компаний, в которых существует разделение труда — настройкой веб-сервера занимается администратор, разработкой — разработчик. Сейчас же все больше людей, которые вынуждены совмещать эти две роли и эти люди не всегда довольны и готовы заниматься работой ITPro.

Поворотным моментом во всей истории стала разработка плагина Microsoft Azure для Eclipse. Плагин существовал и раньше, до 2012 года, но не обладал функциональностью, существенно упрощающей процесс разработки. С новыми же версиями плагин оброс новыми возможностями: теперь разработчику не нужно заботиться о том, что нужно «настроить еще пару скриптов и отдебажить их» (долгий и трудоёмкий процесс в случае сложных развёртываний) — процесс настройки всех скриптов и Cloud Service происходит в фоне, по мере того, как разработчик указывает, какой сервер приложений использовать, какую версию JDK, какие Java-приложения разворачивать на сервер приложений, и так далее. Плагин из простого бутстрапера облачного сервиса вырос в полноценного помощника, использовать услуги которого приятно и легко. Несмотря на позиционирование Java как first class citizen языка программирования на платформе, только с момента получения удобного средства автоматизации рутинных действий можно сказать, что да, развернуть Java-приложение на Microsoft Azure можно, и процесс этот не вызывает мучений с написанием скриптов под каждый сервер приложений.
 
С помощью плагина можно выполнять такие действия, как запуск Java-проекта в эмуляторе Microsoft Azure, развертывание проекта на саму платформу, конфигурацию Remote Desktop и многое другое. Плагин бесплатен, как и эмулятор, что даёт возможность протестировать и отладить проект еще до стадии покупки услуг Microsoft Azure, что весьма удобно для компаний, пока только оценивающих происходящее.
 

 
Что же касается дистрибутивов JDK, то использовать можно любой дистрибутив, если это позволяет его лицензия. Например, разработчик может свободно использовать один из плодов недавнего пакта о сотрудничестве между Microsoft и компанией  Azul, разрабатывающей известные по показателям производительности инструменты.
 
Azul продолжает разрабатывать свой собственный билд OpenJDK Zulu, который полностью сертифицирован на использование для Windows Server x64 (что означает, что его можно без проблем использовать на Microsoft Azure). Zulu не обладает какими-то отличительными особенностями в техническом плане — на ранней стадии разработки для Zulu не применялись никакие оптимизации или тюнинги, специфичные для облака. 
 

 
Нельзя обойти также тот факт, что в 2013 году произошло достаточно тихое, но очень важное событие — партнерство Microsoft и Oracle. Теперь в Microsoft Azure доступны образы, которые готовятся и проверяются Oracle и включают в себя как Linux-дистрибутивы, так и образы с предустановленными серверами и Java.
 
В 2014 году была анонсирована поддержка Java на Microsoft Azure Web Sites – то есть у вас уже есть все из коробки, и можно сразу разворачивать веб-сайт вместо настройки, описанной ниже. Однако подход, описанный ниже, дает больше гибкости и использует другой сервис платформы – Cloud Services, используемый для развертывания сложных приложений.

Давайте поприветствуем мир из Java-приложения, разработанного в Eclipse и использующего Microsoft Azure.
 
После скачивания и распаковки Eclipse запустим среду разработки и, посетив меню обновления Help=>Install New Software, введем адрес репозитория –  dl.msopentech.com/eclipse.

В нижнем окне после загрузки списка содержимого репозитория возникнет выпадающая “ветка” Windows Azure Toolkit For Java. В данной ветке содержится несколько проектов – Microsoft JDBC Driver for SQL Server (для работы с хранилищем, в том числе SQL Azure Databases) и другие. Отметим всю ветку.
В процессе установки согласимся с лицензионным соглашением и перезагрузим IDE. 
Создадим Dynamic Web Project.

 
Основная папка, которая нас интересует – WebContent. В неё мы поместим основной JSP-файл. Создадим его из шаблона JSP File=> New JSP File (html) и скопируем код. 
Hey Azure.

Экспортируем проект в WAR — Export=>WAR File
Создадим проект для Microsoft Azure, шаблон которого появляется после установки плагина.

 
Откроется окно настроек создаваемого проекта. Укажите JDK и сервер — на вкладке сервера при указании папки с, например, Apache Tomcat, название сервера должно определиться автоматически. Если не определяется — значит, была допущена ошибка.
 

 
На последней вкладке Applications надо добавить WAR-файл. Этот проект будет автоматически развернут в локальный эмулятор вычислений Microsoft Azure на указанный вами веб-сервер. Теперь, если нажать на иконку запуска локального эмулятора, то он будет запущен со всей программной инфраструктурой, упакованной в юнит развертывания — в нем будет и JDK, и веб-сервер, и приложение.
Если вы не хотите использовать вашу JDK, вы можете указать Third-party — как указывалось ранее, можно выбрать имплементацию Azul. 
После развертывания юнита можно открыть сайт в браузере по адресу localhost:8080/ProjectName.
Теперь можно выложить получившийся в облако. Для этого надо зарегистрировать подписку на  http://azure.com.
Нажмем на Publish to Windows Azure Cloud.

 
В процессе надо нажать Import from PUBLISH-SETTINGS file, в Import Subscription Information выбрать Download PUBLISH-SETTINGS File и, когда откроется окно браузера, ввести данные аккаунта, на который зарегистрирована подписка Microsoft Azure, тем самым загрузив специальный файл с конфигурацией (вместо того, чтобы настраивать все вручную.

 
По пути, на вкладке Remote Access, снимем галочку, отключив таким образом удаленный доступ к вашей роли, что сейчас не нужно, так как это связано с загрузкой сертификата безопасности. 
Дождемся окончания развертывания роли. Во время развертывания происходит весь процесс установки вашего приложения: ищется свободное оборудование, сервис загружается на портал, создаётся и разворачивается виртуальная машина, на неё загружается сервис, после чего происходит инициирование событий OnStartup и Run – в событии OnStartup запускается веб-сервер и JDK, необходимые для выполнения нашего приложения, в событии-методе Run происходит основная логика приложения.
Перейдя на страницу нашего приложения на портале управления Microsoft Azure, обратим внимание на панель свойств справа. В ней доступно DNS-имя развертывания. URL выглядит как .cloudapp.net, где – некоторый случайный идентификатор, отличающийся от адреса, который получит приложение при развертывании в реальной среде. Хотя ячейки развертывания и разделены между собой, физических различий между ними нет – все определяется тем, куда подключен балансировщик нагрузки. Попробуйте перейти по ссылке. В том случае, если вы сконфигурировали все правильно, вам должна быть выведена страница вашего сайта. Если появляется окно администраторской панели Tomcat, попробуйте добавить в ссылку имя вашего приложения и указать непосредственно имя файла, допустим:
fe744ac908e24c4dafbc2afce3c7f5da.cloudapp.net/JavaWindowsAzure/Index.jsp
Примечание: Если вы получаете при входе на сайт DNS-ошибку 404, подождите пару минут и попробуйте еще – возможно, DNS-имя ещё не готово. Microsoft Azure создает DNS-имена динамически и применение этих изменений может занять несколько минут.
Вот и все.
Однако можно пойти еще более простым путем и создать веб-сайт с использованием сервисов Web Sites, о чем идет речь  здесь.
Подводя итоги данной статьи, отмечу, что еще в позапрошлом году мне приходилось признавать в разговорах на конференциях и по телефону, что с Java на Microsoft Azure не всё так замечательно, как хотелось бы, и эта история требует пристального изучения и вложений. Сегодня все гораздо проще — я могу продемонстрировать за пятнадцать минут всю историю Java и Microsoft Azure или дать ссылку на введение по работе с плагином, ведь никакая презентация или демонстрация не заменит собственный опыт.

Comments (0)

Skip to main content