Microsoft Windows Azure. Быстрый старт. Часть 3. Стартовые задачи и дополнительные файлы
В предыдущих частях нашего цикла (см. часть 1, часть 2) мы познакомились с развертыванием приложений в Windows Azure. Мы рассмотрели процесс запуска приложения под локальным эмулятором, создание пакета развертывания, а также обсудили развертывание приложения непосредственно в Windows Azure – вручную, через портал и используя соответствующие средства, предоставляемые Visual Studio.
Иногда может возникнуть необходимость в запуске дополнительного кода во время инициализации роли, перед ее непосредственным стартом. Это могут быть, например, какие-то дополнительные настройки, установка и регистрация COM-компонентов, развертывание приложений и сервисов сторонних компаний и т.п. Для решения этой задачи используется раздел <Startup> конфигурационного файла ServiceDefinition.csdef.
Стартовые задачи
Раздел < Startup> конфигурационного файла выглядит следующим образом:
<Startup>
<Task commandLine="Startup.cmd" executionContext="limited" taskType="simple"/>
</Startup>
Каждая стартовая задача описывается элементом < Task> , размещаемым в разделе < Startup> . Этот элемент имеет несколько атрибутов, назначение и возможные значения которых описаны ниже.
Атрибут commandLine указывает имя исполняемого файла, который должен быть запущен в рамках данной задачи. Путь к исполняемому файлу начинается от каталога AppRoot\ Bin. При необходимости, переменные среды могут быть заданы в простом .CMD-файле, вызывающем CMD.EXE и устанавливающем необходимое значение переменных. Этот файл должен также вызываться как стартовая задача. Еще один вариант задания переменных среды – использование раздела <Runtime> для элемента, описывающего роль. Например:
<WebRole name=”WebRole1”>
<Runtime>
<Environment>
<Variable name=”MyEnvVariable” value=”MyEnvVariable />
</Environment>
</Runtime>
</WebRole>
Это также делается в конфигурационном файле ServiceDefinition.csdef.
Атрибут элемента < Task> с названием executionContext задает уровень привилегий для выполнения кода данной задачи. Возможные значения – limited или elevated. Уровень limited означает использование тех же привилегий, что и привилегии роли. Уровень elevated повышает привилегии до учетной записи администратора. Это может потребоваться, например, при записи в реестр, регистрации COM-компонентов и т.п.
Атрибут taskType задает способ запуска стартовой задачи. Возможные значения – Simple, Background и Foreground. Значение Simple, используемое по умолчанию, означает, что данная задача должна быть полностью завершена перед тем, как стартует роль. Если задача не завершена, роль будет ожидать ее завершения. Задачи с атрибутом taskType= Simple выполняются до их завершения, после этого выполняется следующая задача (если таковая есть) или вызывается точка входа в роль – RoleEntryPoint. Значение Background означает, что задача не зависит от роли – инициализация и запуск роли выполняется параллельно с выполнением данной задачи. Значение Foreground схоже со значением Background – отличие в том, что роль не может завершить свое выполнение пока не завершится задача с атрибутом taskType= Foreground.
Обратите внимание на то, что для задачи с атрибутом taskType= Simple предполагается, что в случае ее успешного выполнения она завершается с кодом 0. Без этого не запустится следующая в списке задача. Если команда не поддерживает возврат значения 0 в случае ее успешного завершения, следует создать скриптовый файл (.CMD-файл) и добавить в него команду «exit / b 0» для принудительного указания на успешное завершение команды.
Рассмотрим пару сценариев использования стартовых задач. Вот первый сценарий:
<Startup>
<Task commandLine="Task01.cmd" executionContext="limited" taskType="simple"/>
<Task commandLine="Task02.cmd" executionContext="limited" taskType="simple"/>
</Startup>
В данном случае, будет выполнена команда Task01. cmd и после ее завершения будет выполнена команда Task02. cmd, после завершения которой произойдет старт кода роли.
Вот второй сценарий:
<Startup>
<Task commandLine="Task01.cmd" executionContext="limited" taskType="background"/>
<Task commandLine="Task02.cmd" executionContext="limited" taskType="simple" />
</Startup>
В данном случае будет выполнена команда Task01. cmd и сразу же после ее запуска - команда Task02. cmd, после завершения которой произойдет старт кода роли.
Дополнительные файлы
Выше мы рассмотрели, как использовать стартовые задачи (Startup Tasks) для запуска дополнительного кода во время инициализации роли. Может возникнуть вполне резонный вопрос, а как перенести в Windows Azure приложения, которые планируется установить в стартовой задаче и, вообще, как перенести в Windows Azure какие-либо дополнительные файлы, которые могут потребоваться для работы нашего приложения?
Дополнительные файлы должны быть включены в состав проекта приложения на Windows Azure. Один из способов сделать это – в Visual Studio перетащить необходимые файлы в ту часть проекта, которая связана с той или иной ролью. Другой вариант – создать в рамках роли дополнительную папку (в Solution Explorer на названии проекта нажать правую кнопку «мыши», выбрать команду Add, затем – New Folder) и разместить файлы, которые должны быть перенесены в виртуальную машину роли в этой папке.
Рис. Создание новой папки в рамках проекта
И в том и в другом случае для каждого такого файла необходимо установить следующие свойства: Build Action = Content и Copy to Output Directory = Copy always.
Рис. Задание свойств дополнительных файлов
В следующей части
В следующей части мы заглянем внутрь виртуальной машины, в которой выполняется наше «облачное» приложение – для этого мы будем использовать удаленный доступ (Remote Desktop Access) и утилиту, которая позволит нам удаленно выполнять команды – эту утилиту мы создадим в процессе нашего знакомства с Windows Azure.
/АФ