3 апреля был анонсирован Announcing Microsoft Azure Automation Preview и до сих пор находится в стадии preview.
Какие задачи призван решать Automation?
- Автоматизация рутинных процессов по администрированию azure (то, что делается через портал — создание виртуалок, создание новых очередей, баз данных, выдача прав и т. п.);
- Сделать эти процессы повторяемыми, убрать ручную работу с администратора
Бонус к автоматизации ( kill feature):
Runbook (powershell скрипт), который использует Automation, выполняется не на вашей машине, а значит, может работать бесконечно, пока его не остановят. Например, он может в бесконечном цикле проверять состояние машин и как только обнаружит недоступность, посылать email дежурному оператору.
Как раньше решались рутинные задачи по администрированию/автоматизации?
Либо сидел администратор и в интерфейсе всё это прокликивал ручками;
Либо писались C# программы/скрипты на powershell, использующие windows azure API.
Microsoft решили, что пора наколеночные решения по автоматизации заменить на более профессиональные/серьезные. Дать наконец-то возможность “прикрутить свою кнопку к сайту”.
Естественно, для маленьких проектов всё это не нужно, а нужно когда вам регулярно надо создавать новые стандартные вещи.
У интересующихся Azure людей возникнет вопросы:
- Чем отличится Automation от Windows Azure powershell модуля?
Тем, что Azure powershell вы вызываете с вашей локальной машине, скрипт исполняется на вашей машине, а вызывает скрипт внешнее для вас api Azure. Automation Runbook запускается и хранится в самом Azure. - Чем отличается Automation от WebJob по расписанию на powershell?
Нас не должно смущать то, что в обоих случаях мы можем писать на powershell и запускать их через вебсайт, разница в целях для которых они используются.
WebJob созданы для поддержки развернутого приложения. Automation создан для автоматизации рутинных действий по администрированию. Т.е. WebJob пришел от разработчиков и сопровождение, а automation от админов. - Чем отличается Automation от Microsoft Azure Management Libraries и/или Azure SDK? (Этот вопрос возник у меня, тк в описании MAML тоже было много слов про автоматизацию и deploy)
Использование MAML – это написание на C# кода, это часть выпущенного AzureSDK. Automation- это код на powershell, в котором описан Workflow процесс. Т.е. часть функционала пересекается, но в Automation важна именно возможность создавать долгоживущие процессы. Опять же, Automation- для IT, а не для разработчиков.
Давайте посмотрим на примерах:
Примеры для MAML:
- В видео с конференции build показывают, как использовать эту фичу для создание пререквизитов для тестов, чтобы каждый раз все было чистенькое.
- Допустим у вас есть в azure несколько контуров — (набора виртуалок, сервисов, баз данных и тд). На одном вы разрабатываете, на другом теститесь, на третьем готовите релиз, на четвертом продакшен. Если писать такие скрипты автоматизации, то очень легко будет переносить ваши приложения с одной конфигурации на другую. Жмем одну кнопку и копируем очереди, базы, виртуалки и часть нашей работы уже готово. Можно это делать хоть каждый раз с нуля, чтобы иметь новую полностью конфигурацию.
Пример использования: Azure Automation.
- На видео ребята показали скрипт, который постоянно запущен, он мониторит состояние сервисов, и при падении сообщает инженеру техподдержки, что на сервисе проблема. Интересный кейс по мониторингу. channel9.msdn.com/Events/Build/2014/3-621 последняя треть доклада.
- Допустим в вашей компании, аутсорсеры-аутстаферы работают на машинках в windows azure(проще контролировать работают они или нет, есть типовая среда разработки мешающая тварить-варотить.). Кроме создания типовых виртуалок при приходе нового разработчика, можно установить правило- работаем только с 9, до 18. Все остальное время машины не нужны, и могут быть выключены. Соответственно пишем скрипт, запускаем его и он постоянно запущенный мониторит текущее время, как только наступает 18.30 гасим все машины.
- Допустим, у вас в отделе сопровождение зафиксировали инцидент (что-то пошло не так). Нужно устранить ошибку, но в больших компаниях нужно еще заполнить форму инцидента (что было, что затронуло, что не затронуло). Вот для сбора отчета в одну кнопку и можно использовать эту фичу. Написали скрипт, наступил инцидент, нажали на кнопку получили шаблонный отчете со статусами всех виртуалок, очередей, баз данных и тп. Можно на MAML написать, но запуск из Azure Portal на мой взгляд более логичен, чем с локальной машины.
- Бэкап всех баз, перед обновлением продакшена — отличная задача для автоматизации тк она долгоиграющая и запускать можно с azure portal.
- Обновить ключи /сертификат безопасности одной кнопкой в UI.
До начала использование:
Естественно нужно иметь аккаунт на Microsoft Azure.
Чтобы начать использовать эту фичу, нужно сначала подключить ее, тк она preview (Чтобы разработчик принял на себя ответственность, что это еще не релиз и что-то может работать не так).
Лично я долго разбирался чем и от чего Automation отличается и зачем оно надо, а в интерфейс за 5-7 минут все становится очевидным.
Вводно-практическая часть
Скрипты для Automation называются Runbook.
Runbook — это скрипт с powershell workflow внутри себя.
Первые шиги
Статистика
Сложнее...
Внутри себя Automation использует обычный Windows Azure Module для работы с api azure.
Всем удачи в изучении и использовании Automation. Лично мне фича очень понравилась своей идеей.
Ссылки:
- Мы можем найти на msdn информацию для начала изучения: Как посмотреть список /создать/запустить/ посмотреть результаты выполнения Runbook.
- Видео по Automation с конференции Build
- Простые примеры Runbook (реально это просто примеры работы из powershell с Microsoft Azure)
- Очень активно обсуждение на форуме.
- На конференции BUILD очень просили всех, кто разработчиков попробовать эту фичу и написать FeedBack – feature requests. С апреля много воды утекло, но думаю до сих пор актуально.
Автор: SychevIgor
