Публікацію проекту в Azure через Visual Studio Azure Resource Manager Tools

Навесні 2014 року Microsoft анонсувала нову версію порталу в стадії preview, і в ній з'явилася Resource Group.

До неї угруповання різних ресурсів за логічним принципом, по суті, була відсутня. Були окремі бази даних, окремі сайти, окремо storage, кожен на своїй вкладці. Усвідомити, як і будь сутності пов'язані між собою, до яких додатків належать було заняттям не завжди можливим. Як правило, вирішувалося на рівні іменування сутностей за певним шаблоном типу: ApplicationName1_web_1_Prod, ApplicationName2_db_2_Test. Але це не вирішення проблеми, оскільки треба було переглянути всі типи ресурсів, щоб скласти загальну картину.

Resource Group — це логічне групування ресурсів. (баз даних, веб серверів тощо)

image

Але це було вже більше півроку тому. З кінця осені 2014 року, коли вийшла Azure SDK 2.5, Resource Group стала використовуватися не тільки для логічного групування, але на її основі стало можливим публікувати всі частини програми з visual studio в пару кліків.

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

Є кілька шаблонів, на підставі яких створюються deploy конфігурації.

image

На мій погляд, потрібно було створити найпростішу конфігурацію, взагалі без Application Insight. На її основі було б куди простіше розібратися з тим, що знаходиться всередині. Але, на жаль, навіть у базовому шаблоні WebSite Application Insight вже доданий. Я його заховав, щоб було простіше розповідати про внутрішній структурі.
У підсумку вийде ось такий проектimage
У папці Template лежить все, що нас цікавить.

Є блок параметрів, які ми можемо змінювати в залежності від конфігурації.
У ньому не зберігаються значення, за винятком параметра за замовчуванням, тільки опис імен параметрів, типи даних, ну і список можливих значень перерахувань.

image

В іншому файлі, який називається *.param.dev* знаходяться значення цих параметрів, які підставляються при збірці.

image

*dev* — це ім'я конфігурації, до якої відносяться параметри. Таких файлів з конфігураціями можна і потрібно створити стільки ж, скільки Resource Group ми будемо проводити публікацію.
З параметрами розібралися, тепер переходимо до визначення самих ресурсів.

image

Тут ми бачимо 2 ресурсу. WebSite і ServerFarm, причому перший залежить від другого. Після проведення трансформації замість «parameters(»)" буде підставлено значення *param* файл і файл буде простим Json документом. Значення кожного конкретного поля коментувати немає сенсу, вони зрозумілі тим, хто користувався Azure раніше, а для решти можна прочитати в статті.
Я навмисне закрив розділ resources для WebSite, щоб було наочніше.
ресурсу — стандартні MSDEPLOYimage

Якщо ви візьмете шаблон з SQL Server і/або Redis, то у вас просто додадуться 2 секції приблизно такого ж формату. У Redis секція взагалі уваги не заслуговує, у SQL Server, мінімальний набір параметрів є, які потрібно конфігурувати.
Облікові дані адміністратора, розміри бази, collation, від куди приймати запити і т. п.image


Процес публікації
У Вас є цілих 2 способи опублікувати результати:
  • Powershell
    Або виконуєте powershell скрипт, дбайливо створений розробниками для автоматизації.image
  • Visual Studio Deploy
    Або натискаєте кнопку deploy на проекті,image

    вибравши на підставі якої підписки Azure і яких параметрів проводити публікацію.image

    За процесом роботи ми можемо спостерігати в консолі Outputimage

А сам результат побачимо вже на порталі.

Application Insight Rules
Тим, хто використовує Application Insight, варто звернути увагу на опис цих правил в документі, які при деплое будуть опубліковані разом з проектом.
Більша частина правил виглядає приблизно однаково. Ось приклад правила, за яким якщо завантаження процесора вище 90%, то відправляється нотифікація. Правило складається з 2 основних частин:
Condition — умова, яка повинна здійснитися, і Action — дія, яка виконується за умовою.image
У прикладах майже всі правила такі. Є нотифікація при збільшенні довжини черги запитів до IIS, появу безлічі 400* помилок (є ймовірність, що вас намагаються зламати).

Є ще один тип, який я виділив би вже тому, що він структурно не схожий на вищеописані. AutoScaling — автомасштабування.
Він складніше, адже у нас є правило на збільшення числа машин і зменшення в залежності від поточного значення навантаження на CPU. Та й структура у нього інша, немає Condition,Action блоків.
Є MetricTrigger і ScaleAction. Не знаю, навіщо було називати по іншому, але напевно причина була.image

Нюанси
Зрозуміло, що при такому деплое ми не повністю розгорнемо працездатні програми з нуля, як мінімум, в базі даних.
Зате у нас з'явилася автоматизація процесу створення ресурсів, яку ми далі можемо покращувати за своїм розсудом, а наші дії стали більш повторимыми «repeatable».

Посилання


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.