Welcome to Azure. Настройка

Я ненавижу докторишек! Они делают прививки! – Они делают уколы! – Они сверлят зубы бормашинами!!!

Докторо Айболит(с)

 


Теперь Мы знаем как оно крутится внутри, как работает, и сколько платить:) Давайте теперь обсудим как с этим всем взаимодействовать.
Перво-наперво я бы хотел поговорить о такой библиотеке как Microsoft.WindowsAzure.Diagnostics. С помощью этой библиотеки наша аппликация на ажуре сможет с , собственно, Ажуром и общаться:) Что вообще мы сможем сделать с этой библиотекой:
1. Проверить хоститься ли наша программа на клауде.
2. Получить конфигурацию
3. Получать ссылку на файл и хранить его в локальном кэше.

Очень удобное для процесса дебага свойство – проверять крутиться ли наша программа на Ажуре. Согласитесь когда мы дебажим нашу аппликуху иногда некоторые данные нам не нужны. Или, допустим, крутится у нас сервис на ажуре, который должен дергаться когда и наша программа висит в облаках ( помните в ажуре каждая транзакция чего-то, да и стоит ). Проверить или наша программа на ажуре можем таким кусочком кода:

protected void Page_Load(object sender, EventArgs e)
{
if (RoleEnvironment.IsAvailable)
{
Response.Write("Кручусь на ажуре");
}
else
{
Response.Write("Не, не кручусь на ажуре");
}
}

Наша страничка нам напишет где мы есть. Вся радость в том, что эту библиотеку можна использовать в любой аппликации, а не только в ASP.Net аппликациях. Тоесть, вы можете писать библиотеки которые будут вести себя по разному в зависимости от того, висят ли они в облаках или нет. Очень помогает сохранить деньги, например, представим:
1. Есть программа, которая раз в 10 секунд проверяет определенные данные в базе. Когда она стоит на машине клиента – это ОК.
2. Есть веб сайт, который для получения данных использует туже библиотеку. Тоесть дергает базу каждые 10 секунд.
Хотя так часто данные ему и не нужны. Тут два варианта – или переписать библиотеку – тогда у вас получится уже две библиотеки, каждую из которых надо суппортить. Или же написать простой if который проверит или программа на ажуре, и поставит соответствующий промежуток времени для получения новых данных.

 

Определение сервиса
Помните, в прошлых главах мы когда создавали новую ажур аппликацию – получали файл ServiceDefinition.csdef. Так вот, этот файлик не так прост, ибо в нем можно задавать очень много настроек вашего приложения, например таких как:
1. Количество доменов для апгрейда ( помните мы с вами обсуждали апдейт кода накаткой, вот оно!:) )
2. Ендпоинты ваших веб сервисов. Допустим вы хотите использовать нестандартные порты, или иметь адрес определенного вида.
3. Partial || Full trust . Собственно, как Вы зададите этот сеттингс, так IIS на машине на которой будет крутится Ваша веб роль будет к ней относится, и давать те или иные права.Тут все зависит от Вашего приложения, и что Вы хотите разрешить ему делать.
4. Конфигурации. Это уже обсуждалось.
5. Сколько вам необходимо места на локальном диске виртуальной машины, на которой будет крутиться Ваша роль.
6. Ну и какая виртуалка Вам нужна.

Собственно, чтобы не быть голословным, давайте посмотрим на тепершнее сосятоние нашего конфигурационного файла:






















Как видим, вся конфигурация начинается с описания роли И ее ендпоинтов, где мы указываем протокол и порт. Опять же, тут же и присутствуют собственные конфигурационные элементы, такие как “MyCustomeSettingInAzure”.
Естественно если Вы – гик красноглазый:) то будете все настройки вводить напрямую через xml, мы же, блондинки, пользуемся возможностями Visual Studio.

 

Теперь давайте провернем финт ушами, и создами ещё одну веб роль.
Для этого просто тыцните правой кнопкой мыши по проекту Azure и выберите New Web Role Project. В выпавшем окне выберите любой тип проекта для Вашей веб роли. После того , как студию создала новый проект, давайте опять взглянем на *.csdef файл:





































Как видим, была созданная секция для второй веб роли в которой мы можем вводить отдельные для нее настройки!

А можна ли создать веб роль только внутри Ажура?
Да. В настройках вы можете задать тип ендпоинта как Internal. Тогда к вашей веб роли ( скорее всего это будет WCF сервис, я очень сомневаюсь что кому-то захочется создать веб сайт на который смогуть ходить только Web роли:) ).
Порт в данном случае не задается, ибо он будет динамическим.

Че там в настройках вообще?
Да, давайте более внимательно присмотримся к панели настройки ролей, я ее даже опять приаттачу:)

Итак, что мы можем тут настроить:
.Net Trust Level
Тут выбор не велик: Partial или Full Trust. В течении разработки , очень желательно чтобы Вы использовали Partial Trust уровень. Тогда, сама система будет ограничивать ваше приложение от того, чтобы оно там не натворило делов:) Если же Вашему приложению нужно делать такие вещи , как C++, Reflection, P/Invoke ( вы гик:)) тогда используйте Full Trust уровень.

Instances
Тут мы определяем какое количество веб ролей запустить на виртуалках определенной мощности:) Перед тем как менять эти значения – считаем деньги. Да, кстати интересный факт – Azure SLA на то что Ваше приложение будет доступно 99.95% времени работает только тогда, когда каждой веб роли у вас минимум 2 инстанса.

STARTUP ACTION
Просто определяете как Visual Studio запустит Ваше приложение когда вы тыкните F5.

А что там с локальным хранилищем данных?
Оно таки есть, но как обычно с определенными ограничениями. Локальное хранилище данных – это временно хранилище данных, которое свое у КАЖДОЙ роли. Тоесть шарить данные между ролями через локальное хранилище данных не получится. Крепитись:)
Важно ещё то, что если ваша Веб Роль загнется – сгорит вмка, вы случайно ее удалите, и т.д – Вы не вернете эти данные.
Перед тем как использовать локальное хранилище данных – подумайте дважды, а потом ещё разок – будут ли эти данные нужны Вам в будущем, планируете ли Вы их использовать в нескольких ролях – и толко тогда решайте – использовать ли сервиса хранения данных, или же использовать локальное хранилище данных.

Нафига оно тогда надо?
Тут тоже все элементарно – если говорить про сервисы хранения данных – они могут висеть где-то на других виртуалках, хороше если в том же помещении, а локальное хранилище данных находится именно на той виртуалке на которой крутится роль. Потому оно просто быстрее.

И че, как его создать?
Тут два метода – или вы гик или блондинка:) Я как блондинка буду делать все через графический интерфейс. В свойствах роли выбираем закладку “Local Storage”:

Тут Вы можете создать новый Local Storage, задать ему имя и размер, и задать хотим ли мы чтобы данные стирались когда роль перегружается. Кстати, максимальный размер локального хранилища данных для одной роли – 20 гигабайте. Если Вам надо больше 20 гигабайт – скажите мне , что за временные данные вы храните?:)

Итак, методом блондинки мы создали локальное хранилище данных. Давайте посмотрим что нагенерилось в нашем конфигурационном файле?



















Гики могут радоваться и смотреть что они потом могут делать руками:) Как видим мы создали локальное хранилище данных с именем “LocalStorage1” , с размером 100 мегабайт и очисткой при перезагрузке роли.

Ну ок, мы создали. И что дальше?
А дальше мы можем записывать туда разные данные:) Кстати тут то нам и пригодится библиотека про которую я заикнулся в самом начале.
Давайте напишем небольшой кусок кода:

LocalResource myStorage = RoleEnvironment.GetLocalResource("LocalStorage1");
System.IO.File.WriteAllText(myStorage.RootPath + "Temporarydata.txt","я пишу в хранилище локальных данных");

Через объект LocalResource мы можем получить так же информацию об имени нашего хранилища, и интовое значение которое скажет максимальный объем локального хранилища данных.

Давайте добавим немного кода, чтобы показать как много мы знаем про локальное хранилище данных:

/// 
/// Handles the Load event of the Page control.
///

/// The source of the event./// The instance containing the event data.protected void Page_Load(object sender, EventArgs e)
{
LocalResource myStorage = RoleEnvironment.GetLocalResource("LocalStorage1");
System.IO.File.WriteAllText(myStorage.RootPath + "Temporarydata.txt","я пишу в хранилище локальных данных");

Response.Write("Name of the Local Storage = " + myStorage.Name);
Response.Write("Maximum size of the Local Storage = " + myStorage.MaximumSizeInMegabytes.ToString());

//считывание данных
Response.Write("In local folder we stored = " + System.IO.File.ReadAllText(myStorage.RootPath + "Temporarydata.txt"));

}

Теперь пару слов об очистке локального хранилища данных при перезагрузке роли. Давайте подумаем, когда может произойти перезагрузка роли?
а. Сгорела машина на которой висела виртуалка. Бывает. Переподымается копия вашей виртуалки.
б. Апгрейд. Вы проапгрейдили конфигурацию Вашей роли, или заменили код. Для того чтобы изменения вступили в силу необходимо перезагрузить компьютер. 🙂 Майкрософт вей!
в. Мануально.

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

RoleEnvironment.RecycleRole();

Собственно вот и все о чем я хотел поговорить сегодня. В следующем посте я хочу обсудить с Вами вопросы сертификатов, и на кой они необходимы.

Полезные ссылки:

http://msdn.microsoft.com/en-us/library/ms364059(v=vs.80).aspx – как программировать Partial trust системы.

http://msdn.microsoft.com/en-us/magazine/cc163990.aspx – Beware of Full Trust Code

Add a Comment

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *