Робота з 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
    
Джерело: Хабрахабр

0 коментарів

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