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

У цьому пості я розберу процес створення стандартного запиту користувача на розгортання віртуальної машини через 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.

Джерело: Хабрахабр
0 коментарів