WebJob в Microsoft Azure

  Не так давно в Microsoft Azure з'явилася нова фіча — WebJob, правда, поки в стадії alpha 2.
Основна ідея WebJob — дати можливість запускати в Azure завдання за розкладом. Плюс, для. NET коду надається простий API для event driven обробки.
 
 

Рішення до WebJob

Якщо було дія, яку потрібно запускати раз в день то раніше це вирішувалося трохи дивно для Cloud Platform:
 
 
Варіант 1:
Створити виртуалку, і в Windows Scheduler поставити нове завдання. Цей варіант відмінно працює, але в рамках віртуальної машини. Якщо потрібно, наприклад, логи сайту з WebSite Role стискати і відправляти куди-небудь, то виртуалка абсолютно марна. Є звичайно й плюс — немає прив'язки до Azure.
 
 
Варіант 2:
Планувальник Windows Azure Scheduler . Приклад по русски . Проблема в тому, що для його використання треба написати код, який, загалом-то, особисто мені видається не обов'язковим: все має бути простіше.
Таким чином, можна запустити. NET код, але що робити, якщо логіка написана на Батники або на powershell?
Ну і найважливіше: сервіс передбачається використовувати для:
 
     
  • Invoking a Web Service over HTTP / s
  •  
  • Post a message to a Windows Azure Storage Queue
  •  
Такий набір мені здається дуже обмеженим.
 
 
Варіант 3:
Worker Role, яка в активному режимі буде жити і за закладеним вами алгоритму, виконувати дії. Є один момент: такий підхід зовсім Event Driven. Так, можна запустити. NET код, але що робити, якщо код знову ж на Батники або на powershell? Ну і ще один момент: тому Worker Role — це інстанси, за який треба платити, а не окремо стоїть. Exe файл до вашого WebSite Role.
 
 

Що ж може запропонувати WebJob, чого не пропонують всі вище перераховані варіанти?

 
Запуск exe, bat, sh, ps файлів за розкладом або прямо з web-інтерфейсу.
 Розклад можна встановити досить складне
 
Для. NET WebJob додатково дає API, що зв'язує ваш код, із зовнішніми джерелами подій (чергами, таблицями, блоб). Це Api є не обов'язковим, але дає плюшки у вигляді — вікна у зовнішній світ, що дозволяє реагувати на події.
  
 Сам список job буде доступний на вкладці сайту:
 
 
 
Попередні налаштування:
Запустити все це можна і локально, без деплоя на Azure, але давайте це зробимо по-чесному — завантажимо в Azure. Для цього нам знадобиться:
 
     
  • Створити рахунок у Azure. Я взяв Trial на 30 днів;
  •  
  • Створити Web Site;
  •  
  • Створити Storage.
  •  
 
 

Типи Web Job

WebJob можна розділити на 3 типи:
 
     
  • On Demand Task — на вимогу (ручний запуск: після завантаження з'являється кнопка «Запустити»);
  •  
  • Continuously Running Task — постійно працюють задачі (після завантаження zip архіву стартує автоматично і живе вічно, а. NET код реагує на появу нових файлів у черзі);
  •  
  • Scheduled Task — запускаються за розкладом
  •  
 Для варіанту Scheduled доведеться зробити додатковий крок, а саме погодитися на використання фичи.
 
Я цього робити не буду, про це більш докладно можна прочитати тут .
 
 Завантажимо простий powershell скрипт, запакованою у звичайний zip архів.
 
 Завантажили, запустили. Тепер хочеться зрозуміти, що цей скрипт зробив-то.
 
 Ну, тут вже грає свою роль особливість запуску powershell. Скрипт хоч і впав всередині, але сам powershell.exe завершився цілком коректно.
 
 
 

Моніторинг

Типові рішення на Windows, як то: Windows service або завдання в Windows scheduler мають одну спільну проблему — ніколи не знаєш працюють вони чи ні, поки не глянеш на список процесів. Не раз натикався на ситуацію, коли сервіс помирав, але тому його через WebUi не видно, то дізнаєшся про його падіння за непрямими ознаками (як завжди — логи, крики користувачів, відвалився функціонал в UI). Написання WatchDog — це звичайно рішення, але треба писати код і перевіряти, що Watchdog сам по собі працює.
 
Ще однією проблемою є-а запускався чи він за розкладом? Це можна зрозуміти з логів, але їх же читати треба.
 
 WebJob, як і всі інші сервіси Azure, надає який-ніякий, але інтерфейс перегляду стану вашого Webjob і статусу запусків.
 
На цьому базова фіча-запуск виконуваного файлу за розкладом закінчена.
 
 

Прив'язки через Queue (черги), Blobs (Блоб)

Розглянемо самий тривіальний приклад:
 
Через nuget встановлені 2 пакети:
 
     
  • Install-Package Microsoft.WindowsAzure.Jobs-Pre;
  •  
  • Install-Package Microsoft.WindowsAzure.Jobs.Host-Pre.
  •  
Вони за собою ще потягнули Newtonsoft.Json і Microsoft.WindowsAzure.ConfigurationManager, але це дрібниці.
 Перед нами консольний додаток, нічого специфічного в ньому немає.
 
У методі main створюємо об'єкт JobHost і викликаємо метод RunAndBlock ().
Більше ніякої логіки при запуску можна не створювати. Як ми бачимо, з Main ніяких інших викликів, крім RunAndBlock немає.
При завантаженні в Azure система сама розпізнає методи, у яких вхідні параметри розмічені атрибутами типу * Input (наприклад, QueueInput) і викликає ці методи. Тобто вікно у зовнішній світ за нас вже прорубали. Наше завдання — відпрацювати вхідний повідомлення.
 
 
Як і коли Azure розуміє, що потрібно викликати метод?
Azure смикає метод, коли у відповідну чергу / таблицю / блоб додається нове значення. Виходить такий Event Driven стиль. При цьому нам не треба морочитися з API читанням об'єктів з blob, queue, table: за нас інфраструктура WebJob зробить це сама.
 
Я спеціально зробив цей приклад з одного неточністю, щоб показати що ми побачимо в логах. Вихідна рядок має бути out string output — така специфіка.
 Ось так ця помилка буде видна.
 
 Тепер виправимо код:
 
 
Щоб показати, як він працює:
 
     
  • я встановив Azure Storage Explorer.
  •  
  • Створив 2 черги: myqueye і myqueuecopy.
  •  
 Додамо нове повідомлення.
 
 І на виході отримаємо повідомлення вже в іншій черзі:
 
 Ось так, виглядатиме результат коректної відпрацювання
 
 
 

Binding (прив'язка) параметрів

Хороша стаття про Binding (прив'язка) параметрів, де докладно розказано про Input параметрах.
 
 
З цікавого:
1. Якщо у методу є 2 * Input аргументу, то він буде викликаний по додаванню нового об'єкта в першу чергу / блоб / таблицю, а при додаванні в другу — ні.
 
2. Можна використовувати не тільки BlobInput і BlobOutput атрибути, а й механізм, схожий з routing в mvc / webAPI.
 У даному випадку ми отримуємо назву blob, і відносно цього вже можемо будувати якусь логіку.
 
 
3. Не тільки Stream або рядок.
 SDK дозволяє десеріалізовать з вхідного потоку більш складний об'єкт, ніж просто stream.
 
 
 

Додаткові посилання

  
Посилання на приклади описані вище на github . Рядки підключення до Storage не дійсні, вони залишені як зразок, щоб зрозуміти як вони виглядають.
 
P.S. Для тих, хто читає Хансельмана або блог команднди asp.net. Я, по суті, повторив те, що зробили вони, але додав, ніж це рішення відрізняється від того, що було раніше.
  
Джерело: Хабрахабр

0 коментарів

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