Работа с Workflow в Cisco UCS Director

Виртуализация
image

В этом посте я разберу процесс создания стандартного запроса пользователя на развертывание виртуальной машины через Workflow (в отличии способа, который был описан в посте про Самообслуживание с помощью Cisco UCS Director). Ниже мы познакомимся с понятием Workflow, увидим интерфейс редактора Workflow и создадим наш первый Task (задачу).

Workflow, в соответствии с документом «Cisco UCS Director Orchestration Guide», состоит из двух или более задач, объединенных общей логикой выполнения. Workflow определяет порядок выполнения задач. Иными словами, Workflow это набор связанных между собой элементов, которые выполняют определенный набор действий в соответствии с заданной логикой. Причем логика может быть определена администратором системы.

Cisco USCD предоставляет администратору два ключевых элемента для создания и работы с Workflow:
  • Workflow UI designer (графический интерфейс для редактирования, см. изображение ниже);
  • Набор стандартных (типовых) задач (более 400).
Workflow designer

Интерфейс Workflow Designer очень прост, я бы даже сказал примитивен. Что мне лично очень нравится, т. к. нет никаких лишних элементов, обычно перегружающих рабочую область экрана.

Слева расположена область «Available Task», где сгруппированы все встроенные типовые задачи. Там же имеется строка поиска. Центральную часть окна занимает рабочая область, где размещаются Task’и. Вверху есть несколько кнопок, позволяющих выполнить ряд действий, в том числе запустить выполнение созданного Workflow непосредственно из редактора, что очень полезно при отладке.

Типовые задачи


Типовая задача — это предопределенный набор атомарных действий, сгруппированных в одном объекте. На вход такой задаче можно подать набор определенных ресурсов (в том числе и через ранее определенные политики). На выходе таск может передать определенную информацию для другой задачи (например, параметры создаваемой виртуальной машины). Далее в посте я буду использовать два типовых таска для создания Workflow, который будет определять действия пользователя по созданию виртуальной машины.

Таски связываются друг с другом в рабочей области. Для каждого таска можно определить, какой таск будет выполняться далее в случае его успешного выполнения, а также в случае неуспешного. Для этого можно использовать красивые красные и зеленые стрелки (JavaScript рулит :-) ). Таким образом, можно определять логику ветвления задачи, при этом получается достаточно наглядная картинка.

UCSD позволяет вывести полный список всех тасков с детальным описанием каждого из них и образцом кода. Для этого нужно в меню Policies — > Orchestration -> Workflow выбрать команду Task Library и сказать Submit. Для примера ниже показано описание стандартного таска «VMWare Host Power Action».

VMWare Host Power Action

Кроме этого, типовые задачи выполняют функции сбора статистики и дискаверинга объектов физической и виртуальной инфраструктуры, так называемые «Collect Inventory Task».

Работа с Workflow


Для того чтобы попасть в раздел работы с Workflow нужно зайти в меню Policies -> Orchestration — > Workflow

Policies -> Orchestration - > Workflow

Все существующие Workflow сгруппированы по каталогам. В поставку UCSD уже входит набор стандартных Workflow, например, в каталоге System можно увидеть следующие:
  • VMWare OVF Deployment;
  • VMWare VM Provision;
  • VMWare Clone VM.

С Workflow, как и с другими объектами UCSD, можно выполнять ряд стандартных операций, таких как:
  • Редактирование;
  • Эскпорт/импорт и экспорт в виде шаблона;
  • Клонирование;
  • Запланировать их выполнение с помощью шедулера;
  • Блокировку или разблокировку.

Развертывание (provisioning) виртуальной машины с помощью Workflow


Хватит теории, давайте создадим наш первый Workflow, с помощью которого пользователи смогут развернуть виртуальную машину на портале самообслуживания. Для этого заходим в меню Policies -> Orchestration -> Workflows и жмем на кнопку Add Workflow. Появляется окно,

Add Workflow

в котором необходимо указать уникальное имя Workflow – my_first_wf, контекст исполнения (в нашем случае Any) и выбрать каталог, в котором наш Workflow будет сохранен – IT-GRAD_TEST.

Workflow Details

Жмем Next. Переходим в окно «Add User Inputs». Здесь мы можем определить, какие данные Workflow запросит от пользователя в начале своего выполнения. По сути «Workflow User Inputs» — это типовой таск, который будет выполнен в процессе работы нашего Workflow. Мы пока не будем создавать никаких дополнительных тасков.

Workflow User Inputs

Жмем Submit. Получаем в каталоге IT-GRAD_TEST новый Workflow. Если внимательно посмотреть на его статус, то можно увидеть, что стоит пометка Validation Status = Failed. Это вызвано тем, что мы пока не определили никаких тасков.

Идем дальше. Редактируем наш WF. Зайти в редактор можно либо щелкнув дважды мышкой на Workflow, либо выделив его из списка дать команду Edit Workflow, либо дать команду Workflow Designer.

Те, кто будет так или иначе работать с интерфейсом UCSD, быстро обратят внимание, что часто одну и ту же операцию можно выполнить несколькими способами.

Открываем WF Designer

Workflow Designer

И определим набор тасков, которые необходимо выполнить при создании виртуальной машины. Сразу уточню, что я буду использовать типовые таски.

В первую очередь нам необходимо определить состав ресурсов создаваемой VM. Это можно сделать, используя стандартный таск – Resource Allocation. Для этого в строке поиска набираем allocate и в самом низу видим нужный нам таск

Определение набора тасков

Мышкой перетягиваем таск в рабочее поле

Рабочее поле

Появляется окно настройки таска, где мы можем определить имя таска. В списке Task Details определены атрибуты, значения которых будут переданы следующему таску после выполнения текущего. Перечень этих полей важен, так как их все (или их часть) мы должны будем определить в нашем следующем таске.

Жмем Next

Окно настройки таска

В появившемся окне мы можем связать User Input и Task Input Attributes. На русском языке это означает, что мы можем задать определенные значения для атрибутов таска, которые либо будет вводить пользователь, либо они будут переданы из предыдущего таска после его выполнения. Например, мы можем явно указать, как именно мы будем развертывать виртуальную машину «VM Deployment Options» — на основе Template или на базе уже существующей виртуальной машины. Если мы явно определяем способ развертывания виртуальной машины, пользователю не придется задавать его при запросе на портале самообслуживания (у него просто не будет выбора). Также нужно понимать, что те атрибуты тасков, которые помечены как Mandatory, UCSD потребует определить в любом случае.

Оставляем все без изменения и жмем Next

Задание определенных значений для атрибутов таска

В окне Task Inputs мы видим, что нам необходимо определить опции развертывания VM, каталог и vDC, в котором будет размещена созданная VM. Задаем нужные значения и жмем на Submit.

Task Inputs

Как можно видеть, наш новый таск автоматом определен как стартовый и имеет два варианта завершения. Все последующие таски мы должны будем включить в наш Workflow вручную.

Теперь нам необходимо добавить следующий таск, который развернет виртуалку. Называется он VM provision.

Task VM provision

Интересно, что этот таск размещен в каталоге Cloupia Tasks в отличие от предыдущего. Переносим его в рабочее поле

Task VM provision

Имя таска оставляем без изменения. Обратите внимание, что таск VM Provision на выходе выдает только значение атрибута VM_ID. Жмем Next.

Task VM provision

Процедуру настроек User Inputs данного таска я попробую описать подробнее. Помните, я упоминал в описании таска Resource Allocation о том, что он выдает на выходе набор значений атрибутов, которые можно передать в следующий таск? Сейчас мы это сделаем. Например, замапим атрибут таска Select Host на переданное значение из таска Resource Allocation «ALLOCATED_HOST». То же самое выполним для атрибутов тасков от «Select Datastore» до «Select Additional IPv6 Address».

Выглядеть это должно примерно так:

Настройка User Inputs

Атрибуты для трех последних тасков «Number of vCPUs», «Memory», «Disk», которые определяют соответственно количество виртуальных процессоров, объем памяти VM и размер диска VM, можно оставить без изменения. Определить их можно будет на следующем этапе. А можно определить их через отдельные User Inputs Workflow. Я продемонстрирую, как это можно сделать на примере таска Disk Size Selector.

Для определения его атрибута жмем на кнопку Manage Workflow User Inputs в верхней части окна и попадаем в окно определения Workflow User Inputs

Окно определения Workflow User Inputs

Нажимаем «+»

Добавление нового атрибута

Задаем метку и жмем на Select

Добавление нового атрибута

И попадаем в окно выбора типовых тасков. Вбиваем в строке поиска «disk» и выбираем таск Disk Size Selector.

Таск Disk Size Selector

Далее мы можем задать ограничения для значения атрибутов типового таска. Для этого жмем Admin Input Filter и определяем разрешенный размер диска через регулярное выражение. В нашем случае я хочу ограничить выбор пользователя дисками в 20 Гб и 60 Гб.

Ограничения для значения атрибутов

Детальное описание синтаксиса фильтров можно прочитать в разделе Filter Criteria Syntax for Admin Input Filter документа Cisco UCS Director Orchestration Guide.

Жмем Submit и снова попадаем в окно User Input Mapping. Для подтаска Disk выбираем созданный нами Workflow User Inputs “Disk size”. На этом настройки User Input Mapping закончены.

Жмем Next

User Input Mapping

Обратите внимание, что нам снова необходимо указать VM Deployment Type, выбрать каталог и vDC. Кроме этого, мы можем задать новое имя виртуальной машины и переопределить количество vCPU и памяти.

Жмем Submit

Теперь нам необходимо связать созданный таск с другими элементами нашего Workflow. Для этого нам необходимо навести мышку на созданный таск и вывести выпадающий список для зеленого поля On success. В выпадающем списке выбираем Complete (success). Для таска Resourse Allocation укажем в этом же списке VMProvosoin_175. В итоге получаем следующее:

Связка таска с другими элементами Workflow

Связка таска с другими элементами Workflow

И не забываем указать, что делать таску VM Provision в случае сбоя

Связка таска с другими элементами Workflow

Вот собственно и все. Для верности можно нажать на кнопку Validate Workflow и, если никаких ошибок не появилось, жмем Close.

Создание нового каталога


Как я уже писал в посте «Самообслуживание с помощью Cisco UCS Director: как дать пользователям возможность самостоятельно создавать виртуальные сервера», для того, чтобы пользователи могли создать виртуальную машину на портале самообслуживания, нам необходим каталог. В упомянутом посте был создан каталог типа Standard, сейчас мы создадим каталог с типом Advanced.

Для этого переходим в меню Policies -> Catalogs и даем команду Add.

Policies -> Catalogs

Зададим для нового каталога имя CentOS_vm_wf, тип Advanced и выберем нашу любимую группу Cust1. Жмем Next.

В сравнении с каталогом в созданным нами в посте «Самообслуживание с помощью Cisco UCS Director: как дать пользователям возможность самостоятельно создавать виртуальные сервера», настроек для каталога типа Advanced совсем немного. В следующем окне мы укажем наш новый Workflow и на этом все. Для этого жмем на кнопку Select

Добавление Workflow

Ставим галочку напротив нашего Workflow, еще раз жмем Select, потом Next и Submit. Каталог создан.

Запрос на создание виртуальной машины


Логинимся на портал самообслуживания под пользователем, входящим в группу Cust1, и запустим процесс создания новой VM на базе нашего нового каталога.

Запрос на создание виртуальной машины

Помните, что значения для таких параметров как, например, количество vCPU или объем памяти мы задали на этапе создания Workflow, а пользователю предоставили выбор размера диска VM

Запрос на создание виртуальной машины

Зададим нужный нам размер и жмет Next, потом Submit.

Посмотрим за ходом выполнения нашего запроса, как видим машина уже разворачивается :-)

Ход выполнения запроса

И теперь пару слов про настройку подтверждения действий пользователя на портале самообслуживания UCSD.

Настройка подтверждения действий пользователя на портале самообслуживания UCSD


Для этого необходимо перейти в меню Policies — > Virtual Data Centers. Выбираем vDC vDC_Cust1, создание которого было описано в посте «Самообслуживание с помощью Cisco UCS Director: как дать пользователям возможность самостоятельно создавать виртуальные сервера» и редактируем его.

Настройка подтверждения действий пользователя

Нас интересует раздел «Approvers and Contacts». В поле «First Approver Username» мы можем указать имя пользователя, которому будет отправлен запрос на подтверждение. Давайте зададим имя пользователя admin и сохраним настройки.

Пользователь на портале самообслуживания генерирует запрос на создание VM. Посмотрим лог выполнения запроса:

Лог выполнения запроса на создание виртуальной машины

Администратору для подтверждения выполнения запроса необходимо перейти в меню Organizations -> My approvals, выбрать нужный запрос в статусе Pending

Подтверждение запроса на создание виртуальной машины

И выбрать Approve либо Reject

Подтверждение запроса на создание виртуальной машины

Подтверждение запроса на создание виртуальной машины

На этом все. Я постарался, как можно проще и понятнее рассказать про самый важный и интересный функционал Cisco UCSD.

image

www.it-grad.ru

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn