В этом посте я разберу процесс создания стандартного запроса пользователя на развертывание виртуальной машины через Workflow (в отличии способа, который был описан в посте про Самообслуживание с помощью Cisco UCS Director). Ниже мы познакомимся с понятием Workflow, увидим интерфейс редактора Workflow и создадим наш первый Task (задачу).
Workflow, в соответствии с документом «Cisco UCS Director Orchestration Guide», состоит из двух или более задач, объединенных общей логикой выполнения. Workflow определяет порядок выполнения задач. Иными словами, Workflow это набор связанных между собой элементов, которые выполняют определенный набор действий в соответствии с заданной логикой. Причем логика может быть определена администратором системы.
Cisco USCD предоставляет администратору два ключевых элемента для создания и работы с Workflow:
- Workflow UI designer (графический интерфейс для редактирования, см. изображение ниже);
- Набор стандартных (типовых) задач (более 400).
Интерфейс Workflow Designer очень прост, я бы даже сказал примитивен. Что мне лично очень нравится, т. к. нет никаких лишних элементов, обычно перегружающих рабочую область экрана.
Слева расположена область «Available Task», где сгруппированы все встроенные типовые задачи. Там же имеется строка поиска. Центральную часть окна занимает рабочая область, где размещаются Task’и. Вверху есть несколько кнопок, позволяющих выполнить ряд действий, в том числе запустить выполнение созданного Workflow непосредственно из редактора, что очень полезно при отладке.
Типовые задачи
Типовая задача — это предопределенный набор атомарных действий, сгруппированных в одном объекте. На вход такой задаче можно подать набор определенных ресурсов (в том числе и через ранее определенные политики). На выходе таск может передать определенную информацию для другой задачи (например, параметры создаваемой виртуальной машины). Далее в посте я буду использовать два типовых таска для создания Workflow, который будет определять действия пользователя по созданию виртуальной машины.
Таски связываются друг с другом в рабочей области. Для каждого таска можно определить, какой таск будет выполняться далее в случае его успешного выполнения, а также в случае неуспешного. Для этого можно использовать красивые красные и зеленые стрелки (JavaScript рулит :-) ). Таким образом, можно определять логику ветвления задачи, при этом получается достаточно наглядная картинка.
UCSD позволяет вывести полный список всех тасков с детальным описанием каждого из них и образцом кода. Для этого нужно в меню Policies — > Orchestration -> Workflow выбрать команду Task Library и сказать Submit. Для примера ниже показано описание стандартного таска «VMWare Host Power Action».
Кроме этого, типовые задачи выполняют функции сбора статистики и дискаверинга объектов физической и виртуальной инфраструктуры, так называемые «Collect Inventory Task».
Работа с Workflow
Для того чтобы попасть в раздел работы с 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. Появляется окно,
в котором необходимо указать уникальное имя Workflow – my_first_wf, контекст исполнения (в нашем случае Any) и выбрать каталог, в котором наш Workflow будет сохранен – IT-GRAD_TEST.
Жмем Next. Переходим в окно «Add User Inputs». Здесь мы можем определить, какие данные Workflow запросит от пользователя в начале своего выполнения. По сути «Workflow User Inputs» — это типовой таск, который будет выполнен в процессе работы нашего Workflow. Мы пока не будем создавать никаких дополнительных тасков.
Жмем Submit. Получаем в каталоге IT-GRAD_TEST новый Workflow. Если внимательно посмотреть на его статус, то можно увидеть, что стоит пометка Validation Status = Failed. Это вызвано тем, что мы пока не определили никаких тасков.
Идем дальше. Редактируем наш WF. Зайти в редактор можно либо щелкнув дважды мышкой на Workflow, либо выделив его из списка дать команду Edit Workflow, либо дать команду Workflow Designer.
Те, кто будет так или иначе работать с интерфейсом UCSD, быстро обратят внимание, что часто одну и ту же операцию можно выполнить несколькими способами.
Открываем WF 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.
Как можно видеть, наш новый таск автоматом определен как стартовый и имеет два варианта завершения. Все последующие таски мы должны будем включить в наш Workflow вручную.
Теперь нам необходимо добавить следующий таск, который развернет виртуалку. Называется он VM provision.
Интересно, что этот таск размещен в каталоге Cloupia Tasks в отличие от предыдущего. Переносим его в рабочее поле
Имя таска оставляем без изменения. Обратите внимание, что таск VM Provision на выходе выдает только значение атрибута VM_ID. Жмем Next.
Процедуру настроек User Inputs данного таска я попробую описать подробнее. Помните, я упоминал в описании таска Resource Allocation о том, что он выдает на выходе набор значений атрибутов, которые можно передать в следующий таск? Сейчас мы это сделаем. Например, замапим атрибут таска Select Host на переданное значение из таска Resource Allocation «ALLOCATED_HOST». То же самое выполним для атрибутов тасков от «Select Datastore» до «Select Additional IPv6 Address».
Выглядеть это должно примерно так:
Атрибуты для трех последних тасков «Number of vCPUs», «Memory», «Disk», которые определяют соответственно количество виртуальных процессоров, объем памяти VM и размер диска VM, можно оставить без изменения. Определить их можно будет на следующем этапе. А можно определить их через отдельные User Inputs Workflow. Я продемонстрирую, как это можно сделать на примере таска Disk Size Selector.
Для определения его атрибута жмем на кнопку Manage Workflow User Inputs в верхней части окна и попадаем в окно определения Workflow User Inputs
Нажимаем «+»
Задаем метку и жмем на Select
И попадаем в окно выбора типовых тасков. Вбиваем в строке поиска «disk» и выбираем таск 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
Обратите внимание, что нам снова необходимо указать VM Deployment Type, выбрать каталог и vDC. Кроме этого, мы можем задать новое имя виртуальной машины и переопределить количество vCPU и памяти.
Жмем Submit
Теперь нам необходимо связать созданный таск с другими элементами нашего Workflow. Для этого нам необходимо навести мышку на созданный таск и вывести выпадающий список для зеленого поля On success. В выпадающем списке выбираем Complete (success). Для таска Resourse Allocation укажем в этом же списке VMProvosoin_175. В итоге получаем следующее:
И не забываем указать, что делать таску VM Provision в случае сбоя
Вот собственно и все. Для верности можно нажать на кнопку Validate Workflow и, если никаких ошибок не появилось, жмем Close.
Создание нового каталога
Как я уже писал в посте «Самообслуживание с помощью Cisco UCS Director: как дать пользователям возможность самостоятельно создавать виртуальные сервера», для того, чтобы пользователи могли создать виртуальную машину на портале самообслуживания, нам необходим каталог. В упомянутом посте был создан каталог типа Standard, сейчас мы создадим каталог с типом Advanced.
Для этого переходим в меню Policies -> Catalogs и даем команду Add.
Зададим для нового каталога имя CentOS_vm_wf, тип Advanced и выберем нашу любимую группу Cust1. Жмем Next.
В сравнении с каталогом в созданным нами в посте «Самообслуживание с помощью Cisco UCS Director: как дать пользователям возможность самостоятельно создавать виртуальные сервера», настроек для каталога типа Advanced совсем немного. В следующем окне мы укажем наш новый Workflow и на этом все. Для этого жмем на кнопку Select
Ставим галочку напротив нашего 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.
Автор: it_man
