Категорії
VMware: Гайди з розгортання та налаштування

Администрирование vRealize Automation 8.4

В прошлой статье из цикла по автоматизации «Разворот и базовая настройка VMware vRealize Automation 8.3» мы учились готовить нашу среду под инсталляцию vRA, устанавливать этот продукт и осуществлять начальную его настройку, добиваясь минимальной функциональности с использованием практически всех возможностей, которые он нам готов предложить. Настало время глубокого погружения в процесс его администрирования, изучения массы полезных опций, в нем доступных, а также разбора ряда животрепещущих вопросов, вроде миграции NSX-V в NSX-T средствами vRA и использования API в управлении. А интеграцию SaltStack Config мы выделили в отдельный масштабный учебник, ознакомиться с которым можно здесь по причине колоссального количества информации, нуждающейся в изучении в случае принятия решения о ее необходимости.

Разговор обещает быть очень масштабным и сложным, поэтому, без лишней лирики, давайте к нему приступим. В качестве исходных данных рассматриваем, что у нас уже есть установленная и базово настроенная инфраструктура vRA 8.4 (изучена начальная настройка Cloud Assembly, Service Broker и Code Stream), со всеми соблюденными требованиями к среде, подготовленной, в свою очередь, к этой установке (все нужное и важное перечислялось в разделах «Требования и совместимость» и «Подготовка к развороту vRA 8.3» вышеупомянутой статьи).

Об UI vRA

Кое-что по UI этого продукта приводилось в этом подразделе статьи о развороте. Напомним, по сути, vRA – это сборка сервисов, зайти в которую можно с его консоли. Доступ в нее производится под пользователем уровня «Default Configuration Admin» после ввода в строку браузера «https://<vRealize_Automation_FQDN>/».

Отсюда можно производить начальную настройку среды vRA (и вносить последующие ее изменения), а также выполнять множество необходимых операций. Учитывая предпоследний тезис, рассматривать UI vRA стоит в разрезе его компонентов – Cloud Assembly, Service Broker и Code Stream. Но, перечислим их прямо сейчас только для Cloud Assembly, так как в отношении других двух это будет весьма отвлеченная информация – структуру интерфейса для них гораздо адекватнее рассматривать сразу с возможными действиями для наглядности и лучшего понимания. Что и будет сделано ниже, в разделах «Разные операции с…» и «Продвинутые функции vRA».

UI Cloud Assembly

В пользовательском интерфейсе Cloud Assembly достаточно много секций и вкладок, накрывающих его функционал. Перечислим самые важные из них:

  • Infrastructure. Здесь мы добавляем и организовываем ресурсы нашего облачного вендора, а также работаем с пользователями. Кроме того, эта вкладка предоставляет разную полезную информацию о развернутых у нас облачных шаблонах;
  • Design. Это домашняя страничка девелопмента. Здесь используется канва и редактор YAML, разворачиваются наши машины и приложения;
  • Marketplace. Область с облачными шаблонами VMware Solution Exchange и образами, которые помогают готовыми решениями в построении нашей библиотеки шаблонов, предоставляет доступ к OVA или OVF (о маркетплейсе самое важное расскажем в самом конце нашего гайда);
  • Extensibility. Здесь можно расширить и автоматизировать жизненный цикл наших приложений (об этой вкладке будет рассказано в разделе «Продвинутые функции vRA» ниже). Можно работать с подписками на события, используемыми в качестве триггера для продвинутых действий или рабочих процессов vRO;
  • Deployments. Показывается текущий статус предоставленных ресурсов. Можно просматривать детали и историю, необходимые для управления развертываниями;
  • Tenant Management. Демонстрация разных настроенных тенантов, если наша организация принадлежит к классу сервис-провайдеров и позволяет нам выделять или снимать с работы виртуальные приватные зоны: 

Также в UI компонента Cloud Assembly несколько замечательных тьюториалов, часть которых рассматривались в предыдущей нашей статье из цикла по vRA. Эти помощники замечательно помогают разобраться в функциях решения на первых порах, позволят гораздо эффективнее, проще и быстрее управляться с поставленными перед администратором или пользователей продукта задачами. Самое банальное: часто можно встретить по тому или иному полю, секции кликабельный значок «i» в кружочке, нажав на который, можно прочесть что это поле означает, правила его заполнения, примеры и т.д.:

Еще есть полезнейшая кнопка контекстной поддержки рядом с именем и организацией:

И онлайн-доступ к внешней документации в «Support», где в строке поиска можно ввести ключевое слово – виновника нашего вопроса, после чего выдаст список статей, топиков хелпа и т.д., и клик на интересующий откроет ответ на него:

В качестве наглядных примеров, где могут быть полезны встроенные помощники, можно привести несколько решаемых ими задач. А именно, к примеру, инсталляция и апробация инфраструктуры vSphere и развертываний, настройка и предоставление рабочей нагрузки продакшена, использование тэгов в управлении ресурсами vSphere, установка и тестирование мульти-облачных инфраструктур и разворотов, настройка VMware Cloud на AWS, конфигурирование внешних IPAM-интеграций для Infoblox и многое-многое другое.

Настройка vRA

О том, как заводить главные сервисные компоненты vRA (Cloud Assembly, Service Broker и Code Stream) и осуществлять их первичную настройку, мы писали в упомянутой выше статье. Однако, до этого необходимо предпринять несколько важных действий, суть которых состоит в начальном конфигурировании структуры среды.

Организация

По дефолту, организация называется по короткому имени, назначенному vIDM. Его можно отредактировать:

В vRA организация должна отражать имя разворота. Один разворот – одна организация, это аксиома. Все предлагаемые продуктом сервисы принадлежат одной и только одной возможной глобальной организации.

Брэндирование

В UI vRA есть вкладка «Branding», где можно отредактировать дефолтное имя заголовка и логотип:

Сброс пароля на vRA

Если забыли пароль рута на vRA или же по каким-либо другим причинам его нужно поменять, его можно сбросить и перезадать в окне командной строки на Appliance хоста vCenter (безусловно, если у нас там есть учетная запись с соответствующим уровнем доступа). На практике процедура выглядит так:

  1. Выключаем и запускаем vRA (процедура в деталях описана в подразделе «Выключение и включение кластера vRA» ниже), и открываем редактор меню загрузки «GNU GRUB», введя «е» и нажав на «Enter»;
  2. Здесь вводим: «rw init=/bin/bash» в конце строки, начинающейся с «linux “/” $photon_linux root=rootpartition»:

  1. Жмем F10, чтобы передать на изменения и перезапустить vRA. Ждем окончания перезагрузки;
  2. В командной строке «root [/]#» вводим «passwd» и нажимаем на «Enter»;
  3. В новой командной строке «New password:» вводим новый пароль и жмем «Enter»;
  4. В строке «Retype new password:» вводим его еще раз и снова ввод;
  5. В строке «root [/]#» вводим «reboot -f» и жмем «Enter»:

Распространенные операции

В этой главе мы будем учиться работать с пользователями и их правами, делать разные полезные базовые штуки с Cloud Assembly, Service Broker, управлять блюпринтами и хранилищами, грамотно применять тэги, расширять нашу среду vRA, отвечая на выросшие потребности, а также многому другому, не менее важному и интересному.

Администрирование пользователей и групп в vRA

Здесь роли, как и везде, – это определенный набор привилегий, ассоциированный с пользователями, тот доступ к операциям, которые им разрешено производить. О них мы очень подробно писали здесь. Теперь же попробуем озвучить то, что не вошло в тот подраздел, и еще раз обратим внимание на самые важные постулаты.

Можно назначать несколько ролей разных видов, по большому счету, распределенных по двум глобальным категориям:

  • организационные (самый высокий уровень),
  • сервисные.

К первому относятся два типа ролей: Organization Owner и Organization Member. Сервисные роли определяют пользовательский доступ к индивидуальным сервисам (Cloud Assembly, Code Stream, Orchestrator, Service Broker). Все сервисные роли должны быть ассоциированы с организационной ролью, и каждый сервис может иметь более одной роли. Одной из ключевых обязанностей роли Organization Owner является назначение ролей другим пользователям – сделать это может только она.

Назначение и редактирование ролей

На вкладке «Identity & Access Management» выбираем пользователя и кликаем на «Edit Roles»:

На этой странице задаем организационную роль (пример рассматриваем для роли администратора, например, финансового блока), выбираем сервис и назначаем сервисную роль. Список доступных сервисных ролей может быть различным для каждого сервиса. Также обязательно следует назначить роли группе – это можно сделать со вкладки «Enterprise Groups». Если этого не сделать, система выведет ошибки, которые мы упоминали в материале про инсталляцию.

В будущем, когда нужно будет отредактировать назначение групповой роли, на этой же вкладке в поле поиска вбиваем имя нашей группы, и выбираем ее редактирование. Доступны две опции: назначение роли Organization и назначение роли Service. Определившись с нужным, кликаем на «Assign».

Синхронизация с AD

В прошлой статье мы рассматривали инсталляцию vRA через vLCM, в которой этап интеграции vIDM был неотъемлемой частью. И обещали, что расскажем, что же делать пользователям AD. На самом деле нам нужно всего лишь интегрировать vIDM с AD, зайдя в первом в «Identity & Access Management» – «Directories» – «Add Directory»:

До этого очень важно добавить Appliance vIDM к домену – только после этого станет доступной опция «Integrated Windows Authentication». Для синхронизации пользователей и групп AD с vIDM используется дефолтная. Кроме того, коннектор работает с пользовательской аутентификацией в AD.

Что стоит сделать после этой базовой интеграции? Конечно же сопоставить пользовательские параметры между vIDM и AD:

Кое-какие параметры здесь являются опциональными, другие же обязательны (помечены «Required»). Но, значение вторых все-равно можно выставлять по своему усмотрению. Напомним, пользовательские параметры (страница «User Attributes») настраивается до того, как создается директория. Делается все это на вкладке «Identity & Access Management», кликнув на «Setup» – «User Attributes».

Далее следует синхронизировать группы здесь:

– указываем те, которые подлежат синхронизации и кликаем на «Next», чтобы запустить процесс. Заметьте, по умолчанию, стоит галочка в «Sync nested group members» – если она выбрана, все пользователи, которые принадлежат не только конкретно этой группе, но и вложенным группам в ее составе, синхронизируются.

Когда это будет сделано, можно апдейтить конфигурацию, назначать расписание для регулярной синхронизации, либо же впоследствии инициировать ее вручную в любое время.

Удаление пользователей

На странице «Identity & Access Management» все пользователи выведены списком по дефолту и добавлять их там специально нельзя. Но, можно оттуда удалить, при необходимости. Для этого проходим отсюда на вкладку «Active Users», находим нужных нам пользователей и выбираем их, а затем жмем на «Remove Users».

Некоторые вопросы кластеризации vRA

Вот здесь было показано, как при использовании Easy Installer vLCM можно сразу при инсталляции vRA задавать кластер и полностью его настраивать. Там описано все очень доходчиво, но, на некоторых важных моментах, в том числе и на задачах по управлению кластером, сейчас остановимся в деталях.

Во-первых, заметим, что все компоненты vRealize Suite Lifecycle Manager, VMware Identity Manager и vRealize Automation должны находится в одном и том же управляющем кластере. А машины рабочей нагрузки должны предоставляться на отдельном, чтобы изолировать пользователей и серверные процессы. Во-вторых, все компоненты vRA должны разворачиваться возле L2 и нельзя маршрутизировать трафик между ними.

Важно! После разворота кластера нельзя менять диапазон IP-адресов или имя хоста – весь сетап рухнет и будет невосстановим.

Кроме того, еще до разворота кластера нужно сконфигурировать балансировщик нагрузки, а также пользовательские сертификаты.

Это, что касается самого разворота кластера. Теперь же поговорим о его работе и операциях с ним.

Рабочий процесс аутентификации в кластере vRA

При попытке логина пользователя в консоль vRA, запрос посылается на под identity-service-app Kubernetes на Appliance vRA. Под верифицирует это и перенаправляет запрос на аутентификацию на VIDM_HOST, а LB vIDM, в свою очередь, – на один из Appliance кластера. Запрос проверяется в AD-системе и по данному пользователю SAML-токену.

Важно! Если здоровье vIDM неудовлетворительно, под identity-service-app будет в статусе сбоя. Проверить можно вручную прямо из vLCM:

Включение НА коннектора

Для пользовательской аутентификации необходимо включить НА, настроив Identity Provider (IdP), добавив коннекторы и отредактировав имя хоста IdP:

К одному IdP можно добавлять множество директорий, и все пользовательские аутентификации из него используют функцию НА. Каждый Appliance vIDM настраивается со встроенным инстансом коннектора, а каждый коннектор должен быть присоединенным к домену. Если один из Appliance будет в оффлайне, LB перенаправит запрос на аутентификацию на следующий доступный инстанс коннектора, в этом случае. Дополнительно настраивать LB при этом не нужно. Разве что убедиться, что он использует дефолтный порт 443.

НА vRA

vRA может без проблем справиться с падением одной ноды. Но, если нода с праймари-БД уйдет в оффлайн, сервис repmgr переключит соединение с ней на другую ноду.

Выключение и включение кластера vRA

После остановки сервисов кластер vRA нужно выключить. Соответствующую команду:

/opt/scripts/svc-stop.sh

sleep 120

/opt/scripts/deploy.sh –onlyClean

можно запустить только на одной из трех нод. Выключать вторичные ноды и хелс-монитор на LB нет нужды.

Что означает процесс выключения? Вначале все сервисы vRA будут удалены, затем то же самое произойдет с сервисами ядра (при первой загрузке), удалятся все пространства имен, после чего можно приступать к ручному выключению всех нод.

После того, как все сервисы будут выключены и удалены, можно выключать или включать Appliance в любом порядке.

Чтобы запустить сервисы обратно, следует использовать команду: «/opt/scripts/deploy.sh». При этом у нас вначале включатся все ноды, затем отработает скрипт запуска, создадутся все пространства имен, все сервисы ядра (при первой загрузке) и все остальные сервисы vRA сначала создадутся, а потом – запустятся. И только в таком порядке – что процесс выключения, что включения.

Важно! Кластер vIDM должен выключаться после выключения кластера vRA. И включаться, соответственно, до последнего. Причем, обязательно нужно дождаться полной инициализации, следить за которой можно в файле логов «/var/log/deploy.log».

Масштабирование vRA с одной ноды до трех

Если при начальной инсталляции вы выбрали не кластеризованный вариант, а состоящий только из одной ноды, но теперь объективные требования вынуждают вас расширить свою структуру, vRA с легкостью с этим справится. Снова все будем делать через vLCM, как и любые операции по управлению жизненным циклом нашего продукта, для начала, выключив все Appliance vRA (процедуру см. выше) – это если у нас версия 8.0, со следующими можно не церемониться, и сняв снэпшот с разворота, используя опцию «Create Snapshot» в vLCM, пройдя в «Lifecycle Operations» – «Environments» – «vRA» – «View Details». Теперь включаем Appliance и вызываем все контейнеры, а далее:

  1. Проходим в «LCM» -«Locker» – «Certificates», генерируем или импортируем сертификаты vRA для всех компонентов, включая FQDN ноды vRealize Suite Lifecycle Manager и vRealize Automation Load Balancer. Добавляем имена всех трех Appliance в Subject Alternative Names;
  2. Импортируем новый сертификат в vRealize Suite Lifecycle Manager и замещаем предыдущий в «Lifecycle Operations» – «Environments» – «vRA» – «View Details» опцией «Replace Certificate»;
  3. Используем там же «Add Components», чтобы расшириться до трех нод.

Замещение ноды Appliance vRA

Если vRA развернут в мульти-нодовом форм-факторе и сфейлилась НА-конфигурация, может понадобиться заместить ноду сбоя.

Важно! VMware рекомендует перед этим обратится в саппорт, чтобы понять, из-за чего произошел сбой в НА и убедиться, что проблема локальна для этой одной ноды. В противном случае все может повториться и для замещенной, и наша операция будет бессмысленной.

Само же замещение, после взятия снэпшотов (не включая память ВМ) с каждого Appliance в НА-конфигурации, на практике выглядит так:

  1. Выключаем ноду сбоя и записываем номер билда ее софта и сетевые настройки (FQDN, IP-адрес, шлюз, DNS-сервера и МАС-адрес – особенно МАС). Позднее все это зададим в замещающей ноде;
  2. Убеждаемся, что главная нода БД в здоровом состоянии. Для этого сначала заходим под рутом в командную строку на ней и находим имя главной БД командой «vracli status | grep primary -B 1». Выдаст результат вида:

“Conninfo”:

“host=postgres-1.postgres.prelude.svc.cluster.local

dbname=repmgr-db user=repmgr-db passfile=/scratch/repmgr-db.cred

connect_timeout=10″,

“Role”: “primary”,

Проверка статуса: «kubectl -n prelude get pods -o wide | grep postgres». Результат:

postgres-1 1/1 Running 0 39h 12.123.2.14 vc-vm-224-84.company.com <none> <none>

postgres-2 1/1 Running 0 39h 12.123.1.14 vc-vm-224-85.company.com <none> <none>

Если по БД сбой, далее продолжать не стоит, вначале контактируем, опять же, с саппортом и исправляем проблему;

  1. Из командной строки здоровой ноды удаляем ту, на которой сбой:

vracli cluster remove <faulty-node-FQDN>

  1. Из vCenter разворачиваем новую ноду vRA с тем же билдом софта и сетевыми настройками, которые записали выше и включаем ее;
  2. Заходим под рутом в командную строку на замещающей ноде и убеждаемся, что последовательность начальной загрузки завершилась командой:

vracli status first-boot

В выводе ищем сообщение «First boot complete»;

  1. С замещающей ноды осуществляем присоединение к кластеру vRA:

vracli cluster join <primary-DB-node-FQDN>

  1. Заходим под рутом в командную строку главной БД;
  2. Разворачиваем восстановленный кластер скриптом «/opt/scripts/deploy.sh».

Бэкапирование и восстановление

vRA принадлежит к числу полностью управляемых vLCM на протяжении своего жизненного продуктов – и только им, – но,персонального встроенного механизма бэкапирования и аварийного восстановления в нем не предусмотрено. Однако, как и со всем vRealize Suite, вендор рекомендует с ним использовать самые вариативные (и сторонние, и принадлежащие VMware) продукты и специальные инструменты этого направления. Перечислим их:

Первые два способа принадлежат сторонним вендорам, по ссылочке можно перейти на документацию по ним от VMware и уже оттуда – далее на сайт создателя за конкретными инструкциями. Что же касается решения Site Recovery Manager, ему в нашем блоге отведен целый подраздел, где читатель может изучить вопрос во всех его аспектах и приложениях – ничего экзотичного, эксклюзивного именно для vRA, там нет, все делается по обычным схемам, главное, чтобы версия vRA была не древнее 8.0.1. Сейчас же пару слов скажем о vSphere Data Protection, так как его функционал в фокус нашего внимания еще не попадал специально.

Но, вначале напомним: бэкапирование – это совершенно необходимый любой живой системе функционал, без которого говорить о непрерывности и безопасности работы говорить не приходится вовсе. Хорошей практикой считается делать его регулярно по расписанию, параллельно предусмотрев решение для аварийного восстановления, чтобы пользователи системы не страдали от перебоев в доступности продукта. Бэкапирование предпринимают, в частности, чтобы подготовить глобальное техобслуживание любого компонента системы, в качестве подготовки к обновлению сертификатов, перед обновлением самого vRA до следующей версии и т.д.

vSphere Data Protection в бэкапировании и восстановлении vRA

Начнем с того, что vSphere Data Protection как Appliance уже давным-давно end-of-life, однако в форм-факторе API-фрэймворка им воспользоваться можно. Ранее эта штука называлась VADP (vStorage APIs for Data Protection), сейчас же – «VMware vSphere Storage APIs – Data Protection» и концентрируется она на бэкапировании ВМ. С vRA работает, начиная с версии 7.0.1, следовательно, с нашей 8.4 проблем никаких и быть не может.

Компоненты системы бэкапируются в определенном порядке (перечислим последовательность, если у вас vRA 7.x+):

  1. прокси-агенты,
  2. DEM-воркеры,
  3. DEM-оркестратор,
  4. сервисы менеджера,
  5. веб-сайты,
  6. Appliance,
  7. PostgreSQL (если доступна),
  8. MS SQL.
Важно! Все ноды vRA 8.х должны бэкапироваться одновременно. Порядок других компонентов не важен.

При 8.х бэкапироваться должен не только сам vRA и его Appliance, но и Appliance vIDM, и vLCM, и даже балансировщики нагрузки, поддерживаемые текущим развертыванием (по бэкапу последних лучше консультироваться с их вендором конкретно).

И вначале следует увести все сервисы в оффлайн (если у вас ровно «восьмерка»).

Важно! Онлайн-бэкапы поддерживаются только vRA 8.0.1 и свежее.

Перед тем, как инициировать сам бэкап (учтите, что все инстансы Appliance желательно бэкапировать с минимальными разрывами по времени – счет должен идти, буквально, на секунды), нужно выключить все снэпшоты состояния памяти, но не отключать «заморозку».

По самой процедуре, в первую очередь, нам нужно автоматизировать выключение и запуск сервисов Appliance vRA (если у вас 8.0, для последних версий она – опциональна). Для этого:

  1. Заходим в Appliance по SSH на одной из нод;
  2. Проходим в «/usr/sbin» командой: «cd /usr/sbin»;
  3. Создаем скрипт с названием «pre-freeze-script»:

#!/bin/bash

# Stop application services

/opt/scripts/svc-stop.sh >/dev/null 2>&1

sleep 60

# Stop infrastructure services

/opt/scripts/deploy.sh –onlyClean >/dev/null 2>&1

RETURN_CODE=$?

sleep 60

if [[ “$RETURN_CODE” -eq 0 ]]

then

echo “$LOG_PREFIX vRealize Automation services successfully stopped”

 exit 0

else

echo “$LOG_PREFIX vRealize Automation services failed to stop”

exit 1

fi

  1. Создаем скрипт с названием «post-thaw-script»:

#!/bin/bash

# Clear services state /opt/scripts/deploy.sh –onlyClean >/dev/null 2>&1

 sleep 60

# Start services

/opt/scripts/deploy.sh >/dev/null 2>&1

RETURN_CODE=$?

sleep 60

if [[ “$RETURN_CODE” -eq 0 ]]

then

echo “$LOG_PREFIX vRealize Automation services successfully started”

exit 0

else

echo “$LOG_PREFIX vRealize Automation services failed to start”

exit 1

fi

  1. Устанавливаем правильные разрешения:

chmod 700 pre-freeze-script post-thaw-script

Далее бэкапируется сам Appliance, и затем – сертификаты или их цепочки, в случае необходимости их замещения, либо при новых инсталляциях. Это нужно сделать не только с сертификатами Appliance vRA, но и с сертификатами Appliance vIDM. И, наконец, занимаемся балансировщиками нагрузки, если у нас распределена работа между серверами и НА-развороты. Тут конкретные рекомендации привести сложно, так как каждый в этом деле следует политике сайта. Единственная просьба: следите, чтобы сохранилась сетевая топология и схема планирования бэкапа vRA.

Если интересно, в подробностях этот фреймворк описан здесь.

Увеличение дискового пространства для Appliance vRA

Иногда выделенного под Appliance vRA дискового пространства перестает хватать. Например, когда у нас слишком большое хранилище логов. Для этого c помощью vSphere расширяем VMDK на Appliance, далее заходим под рутом в командную строку Appliance и запускаем команду:

vracli disk-mgr resize

Если в процессе что-то пойдет не так, воспользуйтесь этим КБ.

Апдейт DNS-назначения для vRA

Для обновления DNS-назначения для vRA нам нужно под администратором зайти в консоль любого Appliance по SSH или VMRC и запустить команду:

vracli network dns set –servers DNS1,DNS2

Далее убеждаемся, что новые DNS-сервера правильно применились ко всем нодам vRA командой:

vracli network dns status

Запускаем процесс закрытия всех сервисов vRA на всех нодах кластера:

/opt/scripts/svc-stop.sh

sleep 120

/opt/scripts/deploy.sh –onlyClean

Перезагружаем ноды vRA и ждем, пока они полностью не запустятся. Затем заходим на каждую ноду vRA по SSH и убеждаемся, что новые DNS-сервера выведены списком в «/etc/resolve.conf». И на одной из нод запускаем обратно все сервисы vRA командой: «/opt/scripts/deploy.sh».

Разные операции с Cloud Assembly

Cloud Assembly – это то, с чего мы всегда начинаем настройку нашей системы. То, к чему чаще всего обращаемся, когда нужно определить какие-то новые операционные объекты, их взаимосвязи и конфигурацию функционирования. Самую базовую и простую настройку его компонентов нам предлагают завести прямо в процессе старта работы с помощью Quickstart или Guided Setup – мы это описывали в прошлой статье из нашего цикла по vRA. Однако, аналогичные по смыслу операции приходится выполнять и в дальнейшем постоянно, поэтому поучимся каждой из них на практике.

Создание облачного аккаунта

Если вы внимательно читали нашу предыдущую статью по развороту vRA, не могли не заметить, что в разделах о начальной конфигурации наших сервисов в системе в полях, соответствующих окнам помощников, мы в обязательном порядке прописывали название нашего облачного аккаунта. Эта структурная единица не образуется из воздуха – ее необходимо вначале создать. Для этого в «Infrastructure» проходим в «Connections» – «Cloud Account» и кликаем на своего ресурсного провайдера (например, на vCenter, чтобы добавить систему vCenter Server):

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

Чтобы настроить параметры подключения:

  1. Вводим FQDN/IP-адрес системы vCenter Server;
  2. Вводим имя пользователя и пароль;
  3. Кликаем на «Validate»:

vRA валидирует пользователя и его пароль. По best practice рекомендуется завести специальный аккаунт в vSphere, который vRA будет использовать для целей предоставления.

Чтобы добавить имя и описание нашего облачного аккаунта, вводим его имя (это может быть регион или другая какая идентификация в соответствии с корпоративной практикой) и описание вот здесь:

Создание облачной зоны

После того, как завели облачный аккаунт, можно автоматически создать клауд-зону и включить предоставление (скриншот с нижней части меню «Adding a New Cloud Account»):

  1. Выбираем наши дата-центры (после валидации связи все дата-центры определились на нужной нам системе vCenter Server);
  2. Опционально, выбираем «Automatically Create a Cloud Zone».

Заметьте, на данном этапе нельзя подключиться к конечной точке NSX, так как ни одного облачного аккаунта NSX еще не создано. Подключение можно будет инициировать позже. Только добавить тэги способностей, либо же сделать это позднее. Важное замечание: по каждому дата-центру нужно выбрать «Allow Provisioning», где мы планируем предоставлять блюпринты.

Если выбрать «Create a cloud zone for the selected datacenters», облачные зоны создадустся для выбранных дата-центров – такой метод очень упрощает и ускоряет базовое конфигурирование. Если этого не сделать, можно будет добавить клауд-зоны позднее. Делается это так:

  1. Проходим в «Infrastructure» – «Configure» – «Cloud Zones»;
  2. Кликаем на «+New Cloud Zone»;
  3. Вводим все требуемые данные в появившемся окне:

Аккаунт или регион здесь выбирается из тех, что были определены ранее. Также можно использовать политики размещения и ВМ-папки в vSphere. Тэги способностей очень важны – они помогают идентифицировать, которая система может быть использована с определенными блюпринтами. Хотя назначение их и не является обязательным. «Placement policy» может быть дефолтной (будет размещено наугад), «Binpack» (поместит на наиболее загруженный хост, если у него достаточно ресурсов) и «Spread» (размещение равномерно по хостам).

Также нам нужно указать для нашей клауд-зоны вычислительные ресурсы:

путем выбора сразу кластера, либо отдельных хостов, чтобы она могла их использовать в качестве ресурсов. Если выбрать DRS-кластер, доступен будет лишь он. Позднее облачные зоны будут ассоциированы с проектами (см. статью «Разворот и базовая настройка VMware vRealize Automation 8.3»). Когда все настройки по клауд-зоне будут сделаны, жмем на «Create».

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

Проекты – это способ организовать систему vRA относительно ассоциированных с пользователями и группами ресурсами.

Способ создания нового проекта через Quickstart, конечно же, не единственный – впоследствии нам постоянно приходится их добавлять. Сделать это можно в общем случае на вкладке «Infrastructure» в «Configure» – «Projects», где кликаем на «+New Project», чтобы перейти в соответствующий экран:

Где помимо наименования и опционального описания, обязательно назначаются пользователи и группы, а на вкладке «Provisioning» мы связываем проект с облачными аккаунтами и клауд-зонами.

Замечание. Проекты в vRA 8.х – это то же самое, что и тенанты в «семерке». Но, у них нет таких жестких защищенных границ, правда, можно ограничивать некоторые объекты, чтобы они были доступны лишь специфическому проекту.

Выбор пользователей и групп, чтобы они стали членами проекта, осуществляется здесь:

Это можно делать по email из vIDM, либо выбирать пользователей и группы из AD. Определенным пользователям и группам можно назначать роли.

Далее на вкладке «Provisioning» нам нужно добавить облачную зону:

Интересно, что любой проект должен иметь, минимум, одну клауд-зону для ресурсов. Но, подключать к нему можно и множество, в том числе и разных типов (vCenter, Google, AWS и пр.). Облачные зоны устанавливают приоритетность при запуске многих задач одновременно с одного и того же ресурса. Можно лимитировать кол-во инстансов, которые способны развернуться на проекте. Дефолтное значение «0» соответствует полному отсутствию этого рода ограничений. Также можно установить порог для максимального кол-ва памяти, которую потребляет проект в облачной зоне. Однако, хранилище или CPU лимитировать нельзя. Вместо этого ограничения по ним можно установить, создав «flavor». Ограничения по хранению и сети также могут быть назначены для всего проекта на вкладке «Provisioning» после того, как будут добавлены облачные зоны.

После того, как на всех вкладках нового проекта мы вписали все, что хотели, на первой «Summary» мы можем нажать на «Create».

Важно! Нельзя нажимать на «Create», пока не добавлен хотя бы один пользователь и, хотя бы один, ресурс предоставления.

Создание сопоставления особенностей

Сопоставление особенностей – это размеры виртуальных машин и можно создавать любые комбинации размерных конфигураций. Чтобы создать сопоставление особенностей следует пройти на вкладку «Infrastructure» – «Configure» – «Flavor Mappings»:

Здесь указывается облачный аккаунт, который будет работать с этой особенностью, кол-во CPU и памяти. Если кликнуть на иконку «+» в конце линии, можно добавить несколько облачных аккаунтов, для которых будет установлена эта особенность.

Создание сопоставления образов

Сопоставление образов в системе vCenter Server – это шаблон виртуальной машины. Чтобы создать его, проходим так же в «Infrastructure», а затем – в «Configure» – «Image Mappings»:

Здесь можно сопоставлять образы с любого вида шаблонами (предустановленным веб-сервером, серверами баз данных, систем приложений). Сопоставления образов способны обладать конфигурационными скриптами CloudConfig (то же, что и Cloud-Init).

Тестирование конфигурации

Когда в инвентари облачных аккаунтов, зон, в проекты, сопоставление образов или особенностей были внесены изменения, имеет смысл протестировать нашу новую конфигурацию, запустив своеобразную симуляцию работы:

Пока, конечно, у нас здесь нет ни одного блюпринта или виртуальной машины, однако есть функционал для тестирования их гипотетической работы, используя разные особенности и образы. Для этого проходим обратно в «Cloud Zones», открываем нашу отредактированную или новосозданную зону и кликаем на «Test Configuration». Можно выбирать тип запускаемого теста, например, «Single machine», «Two machines with network», «Two machines with network and storage» и «Two machine with network, storage and load balancer», кликнув на соответствующую плитку (см. скриншот). После чего нажать на «Simulate».

Управление в Cloud Assembly

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

Карточки и списки развертываний, операции с развертываниями, фильтрация

Каждое развертывание в Cloud Assembly выносится в отдельную карточку в списке развертываний:

Здесь можно пользоваться фильтрацией на основе собственника, проектов, даты истечения лицензии и других, осуществлять поиск по тэгу. А также сортировать выводы в списке карточек по времени или имени. Прямо в нем можно предпринимать некоторые действия на уровне развертывания, в том числе удалять неиспользуемые для освобождения ресурсов, а также просматривать их стоимость, дату истечения и статус.

Второй вариант вывода существующих развертываний – список:

(В правом верхнем углу доступно переключение между карточками и списком).

Еще есть встроенные фильтры, включив которые можно добиться еще более тонкой сепарации по какому-то специфичному признаку. Например, фильтр «Optimizable Resources Only» (доступен для интеграций с vROps) выделяет высвобождаемые ресурсы, фильтр «Deployment Lifecycle Status» – текущий статус развертывания с учетом операций по управлению (удаленные не выводит, список статусов: «Create – Successful», «Create – In Progress», «Create – Failed», «Update – Successful», «Update – In Progress», «Update – Failed», «Delete – In Progress», «Delete – Failed») и «Last Request Status», фильтрующий по последней операции или действию, запущенному в развертывании (для удаленных тоже недоступен, возможные значения: «Pending» – первая стадия запроса, действие принято, но процесс еще не начался, «Failed» – ошибка по запросу на любой стадии процесса развертывания, «Cancelled» – отменено пользователем до окончания развертывания, «Successful» – по запросу было успешное создание, обновление или удаление развертывания, «In Progress» – процесс развертывания запущен, «Approval Pending» – запрос вызвал политики на одобрение, необходимо подтверждение одобрения/отклонение, «Approval Rejected» – запрос был отклонен в процессе подтверждения из-за вызванной политики одобрения). Последние два могут использоваться как по отдельности, так и в комбинации.

Из «Deployments» можно еще следить за развертыванием в режиме реального времени, найдя его карточку в списке (при помощи фильтра или поиска, если необходимо), чтобы убедиться, что ресурсы предоставлены и запущены. Прогресс покажется в статусе карточки:

А когда все завершится, она примет обычный свой вид. Если в процессе вызовется какой-то нуждающийся в подтверждении запрос, согласно назначенным ранее политикам, там будет такое сообщение:

Операции жизненного цикла готовых развертываний и действия с ними

На «Deployments», если кликнуть на имя интересующего нас разворота, откроется его информационная персональная карточка со следующими вкладками:

  • Topology. Здесь представлено видение структуры развертывания и ресурсов;
  • History. Все события, связанные с предоставлением и действиями, запущенными после разворота запрошенного объекта, а также все ошибки, произошедшие в процессе;
  • Price. Стоимость развертывания для организации. Она опирается на интеграции vROps или CloudHealth;
  • Monitor. Информация о здоровье развертывания на данных из vROps;
  • Alerts. Активные алерты по ресурсам развертывания. Здесь можно отклонить предупреждение или добавить к нему справочные заметки. Алерты базируются на данных из vROps;
  • Optimize. Вкладка с информацией об утилизации по развертыванию и предложениями по высвобождению ресурсов или их модификации с целью оптимизации потребления. Тоже на данных vROps.

Если мы выяснили, благодаря этим вкладкам, что какое-то развертывание слишком дорогое, можно изменить размер компонента, выбрав его на странице топологии и затем на странице компонентов – «Actions» – «Resize»:

Там же можно удалить развертывание здесь же, просто выбрав в «Actions» – «Delete».

Чтобы просмотреть список удаленных развертываний, на вкладке «Deployments» нужно включить «Deleted Deployments Only»:

В нем они хранятся до 90 дней.

Вообще же, с готовыми успешными развертываниями можно выполнять множество действий по управлению ресурсами. Доступность их зависит от типа ресурса и того, какие действия поддерживаются конкретным облачным аккаунтом или интеграционной платформой, а также от прав того, кто их осуществляет. Помимо встроенного перечня действий, доступны и пользовательские, добавленные администратором (например, vMotion). Сформируем из основных наглядную табличку:

Действие Применяется к типу ресурса … Тип развернутого ресурса Описание
Добавление диска («Add Disk») Машины AWS, GCP, Azure, vSphere Добавление дополнительных дисков существующим ВМ
Отмена («Cancel») Развертывания, разные типы ресурсов AWS, GCP, Azure, vSphere Отмена развертывания или Day-2 на развертывании или ресурсе в процессе запроса. После этого оно появится как сфейлившийся запрос на вкладке «Deployments». Чтобы высвободить ресурсы и очистить список используем действие «Delete» по нему
Изменение срока аренды («Change Lease») Развертывания AWS, Azure, vSphere Изменение даты и времени истечения аренды. По истечению срока развертывание уничтожается и высвобождаются ресурсы
Изменение собственника («Change Owner») Развертывания AWS, GCP, Azure, vSphere Изменение собственника развертывание на выбранного пользователя (члена того же проекта, который развернул запрос)
Изменение проекта («Change Project») Развертывания AWS, GCP, Azure, vSphere Доступно только для развертываний с адаптированными ресурсами (только с дисками и машинами – не с облачными шаблонами или смигрированными разворотами). Недоступно после изменений в ресурсах развертывания
Изменение группы безопасности («Change Security Groups») Машины vSphere Применяется к существующим группам безопасности по требованию для NSX-T/NSX-V. Доступно только для одиночных машин, не кластеров машин, и для присутствующих в развертывании групп безопасности, не являющихся частью сетевых профилей
Подключение к удаленной консоли («Connect to Remote Console») Машины vSphere Открытие удаленного сеанса для выбранной машины (включенной)
Создание снэпшота диска («Create Disk Snapshot») Машины и диски Azure Создание снэпшота диска ВМ или диска хранилища
Создание снэпшота («Create Snapshot») Машины GCP, vSphere Создание снэпшота ВМ
Удаление («Delete») Развертывания AWS, GCP, Azure, vSphere Уничтожение развертывания с удалением всех ресурсов и их высвобождением
Шлюз NSX NSX Удаление правил порта пересылки NAT из шлюза NSX-T/NSX-V
Машины и балансировщики нагрузки AWS, GCP, Azure, vSphere Удаление машины или LB из развертывания (если оно не используется)
Группы безопасности NSX-T/NSX-V Если не ассоциированы ни с какой машиной в развертывании, происходит удаление группы безопасности из него – не общего пользования (если ГБ по требованию, она уничтожится на конечной точке)
Удаление снэпшота диска («Delete Disk Snapshot») Машины и диски Azure Удаление диска ВМ или управляемого снэпшота диска в Azure
Удаление снэпшота («Delete Snapshot») Машины vSphere, GCP Удаление снэпшота ВМ
Редактирование тэгов («Edit Tags») развертывания AWS, Azure, vSphere Добавление или изменение тэгов ресурсов, примененных к конкретным ресурсам разворота
Выключение («Power Off») Развертывания AWS, Azure, vSphere Выключение развертывания без выключения гостевых ОС
Машины AWS, GCP, Azure, vSphere Выключение машин без закрытия гостевых ОС
Включение («Power On») Развертывания AWS, Azure, vSphere Включение развертывания
Машины AWS, GCP, Azure, vSphere Включение машин
Перезагрузка («Reboot») Машины AWS, vSphere Перезагрузка гостевой ОС на ВМ (для vSphere должны быть проинсталлированы VMware Tools)
Переконфигурация («Reconfigure») Балансировщики нагрузки AWS, Azure, vSphere Изменение размера LB или уровня логгирования, добавление или удаление маршрутов, изменение порта, протокола, конфигурации здоровья и настроек членов пула.
Шлюз порта пересылки NSX NSX-T/NSX-V Добавление, редактирование и удаление правил NAT порта пересылки из шлюза NSX-T/NSX-V
Группы безопасности NSX-T/NSX-V, VMware Cloud, vSphere Добавление, редактирование или удаление правил файервола или ограничений на основе того, группа безопасности является существующей или по требованию
Удаление диска («Remove Disk») Машины AWS, GCP, Azure, vSphere Удаление диска из существующих ВМ
Перезапуск («Reset») Машины AWS, GCP, vSphere Принудительный рестарт машины без выключения гостевой ОС
Изменение размера («Resize») Машины AWS, GCP, Azure, vSphere Увеличение или уменьшение CPU и памяти ВМ
Изменение размера загрузочного диска («Resize Boot Disk») Машины AWS, GCP, Azure, vSphere Уменьшение или увеличение размера загрузочного диска
Изменение размера диска («Resize Disk») Диск хранилища AWS, GCP Увеличение размера диска хранилища
Машины AWS, GCP, Azure, vSphere Изменение размера дисков, включенных в шаблон образа машины и любых прикрепленных дисков
Перезапуск («Restart») Машины Azure Выключение и перезапуск работающей машины
Возврат к снэпшоту («Revert to Snapshot») Машины GCP, vSphere Возврат к предыдущему снэпшоту машины
Выключение («Shutdown») Машины vSphere Выключение гостевой ОС и выключение машины (нужны VMware Tools)
Подозрение («Suspend») Машины Azure, vSphere Приостановка машины, чтобы она не могла использоваться и не потребляла никаких системных ресурсов, кроме хранилища
Обновление («Update») Развертывания AWS, Azure, vSphere Изменение развертывания на основе параметров ввода
Обновление тэгов («Update Tags») Машины и диски AWS, Azure, vSphere Добавление, изменение или удаление примененных к конкретному ресурсу тэгов
Отмена регистрации («Unregister») Машины AWS, GCP, Azure, vSphere Доступно только для адаптированных развертываний машин. Они удаляются из развертывания вместе с прикрепленными дисками. Если удалить ресурсы, можно перезапустить процесс адаптации для нее, а затем адаптировать ресурсы снова – уже для нового проекта
Работа со списком ресурсов

Список ресурсов помогает управлять машинами, томами хранилища и сетями, причем управление это доступно по группам типов ресурсов, а не по развертываниям. В этом списке также есть фильтрация, сортировка и запуск операций, выбор типа и поиск. Если нажать на имя ресурса, можно поработать с ним в контексте деталей развертывания:

Использование карточек стоимости
Важно! Если хочется поработать с прайсингом на мульти-тенантных средах, следует под каждый vRA-тенант иметь отдельный инстанс vROps.

Карточки стоимости определяют уровень политики ценообразования, которая, в свою очередь, может быть назначена неким проектам, чтобы понять общие затраты по ним. После создания конечной точки vROps или CloudHealth становится доступной предопределенная дефолтная карта стоимости со стоимостью, равной конфигурации стоимости на вкладке «Infrastructure» – «Pricing Cards». Эти карточки можно создавать и потом применять только к проектам, либо же к облачным зонам. По умолчанию, все новые карты стоимости применяются к проектам.

Важно! Если поменять настройку «All pricing cards are applied to», все существующие назначения карточек стоимости удалятся. Также удалится и конечная точка vROps из Cloud Assembly, как и все карты стоимости.

Цена развертывания за период времени появляется и в его карточке, и в «Project» как цена за месяц до текущей даты, и она сбрасывается на 0 в начале каждого месяца. Ценность этой информации не нуждается в рекламе, так как она полезна не только администратору облака, чтобы он понимал, что происходит в его инфраструктуре и как то или иное развертывание на ней сказывается, но и рядовым пользователям, ибо таким образом они видят, как их работа отражается на бюджете и долгосрочных развертываниях. Если нажать на кнопку «Display pricing», информация о ценообразовании покажется в Cloud Assembly и Service Broker для пользователей.

Начальная цена, которую мы видим на уровне развертывания по нашим вычислительным ресурсам и ресурсам хранилища, опирается на стандарты индустрии, после чего рассчитывается за период времени. Порог применяется к хостам и сервисам и вычисляется из данных по CPU и памяти. Перерасчет происходит каждые 6 часов. Стоимость новых политик, назначений и предоплат устанавливается в течение следующего цикла сбора данных. По умолчанию, он запускается каждые 5 минут. Однако обновление политик или изменения в проектах и развертываниях может занять до 6 часов для пересчета.

Перед разворотом объекта каталога рекомендуется оценить его цену. Можно использовать цену предоплаты как оценочную в этом случае:

Это из учета размера загрузочного диска по каждой ВМ в 8 Гб. Цена предоплаты развертывания – это ежедневная оценочная стоимость, опирающаяся на размещение ресурса по данному объекту каталога (берется еще до того, как он развернут). После его разворота можно посмотреть цену за месяц до текущей даты как результирующую цен предоплаты на вкладках «Deployment» и «Infrastructure» – «Projects». Предоплатное ценообразование поддерживается частыми облачными ресурсами, вроде машин и дисков vSphere, объектов каталога Cloud Assembly и объектов, безразличных к типу облака, настроенных с vCenter для приватного облака (но не для публичных облачных ресурсов и других типов машин и дисков частных облаков).

Чтобы оценить стоимость развертывания, из каталога выбираем наш объект и кликаем на «Request» – «Calculate». Если результат приемлем, жмем на «Submit». Также можно использовать оценочные карточки по проекту, чтобы понять всю его стоимость, а делается это на странице «InfrastructurePricing Card», где рядом с «All pricing cards are applied to» нужно нажать на «Edit» и выбрать «Projects».

Синхронизация с сервером стоимости под vSphere и VMC доступна на странице конечной точки vROps, в «Infrastructure» – «Integrations» – «vROPs Endpoint», где в секции vCenter Server нужно кликнуть на «Sync»:

Тогда стоимость пересчитается по всем проектам в организации.

Перед созданием карточки стоимости нужно настроить и включить ценообразование и валюту в vROps, чтобы работать с vRA (оба Application должны быть в одной и той же временной зоне, а принципы добавления подобного типа интеграций рассмотрим ниже). Далее нам нужно:

  1. Пройти в «Infrastructure» – «Pricing Cards» – «New Pricing Card»;
  2. На вкладке «Summary» ввести имя и описание карточки стоимости. Как только на вкладке определится политика, таблица «Overview» заполнится с уровнями карт цен (значения определяются в vROps);
  3. Опционально, можно поставить галочку в «Default for unassigned projects?», чтобы назначить эту карточку цены ко всем проектам без назначений, по дефолту;
  4. Кликаем на «Pricing» и настраиваем детали политики ценообразования, вписав ее имя и описание, выбрав цену или уровень в виде основы, гостевые ОС, тэги, пользовательские свойства (повторяемые, одноразовые или множитель) и дополнительные настройки (все – нажав на «Add Charge»);
  5. Переходим на вкладку «Assignments», нажимаем на «Assign Projects» и выбираем проект(ы);
  6. Кликаем на «Create» для сохранения настроек.

Теперь наша новая ценовая политика появится на странице «Pricing Cards», и чтобы в будущем ее отредактировать или посмотреть ее назначения, можно просто нажать по ней на «Open». После создания и назначения карточки стоимости можно посмотреть историю ценообразования развертываний и проектов, пройдя в интересующем объекте на вкладку «Price», и чтобы раскрыть ее составляющие следует просто кликнуть на «Details».

Работа с блюпринтами

По окончанию базового конфигурирования vRA Cloud Assembly можно создавать и разворачивать блюпринты, буквально, за считанные минуты. Интерфейс дизайна блюпринтов обладает тремя панелями: панелью компонентов, канвой дизайна (с функцией перетаскивания) и окном YAML-кода (редактор с возможностью дополнения кода с учетом контекста):

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

Базовый блюпринт

Базовый блюпринт представляет собой одну виртуальную машину, подключенную к существующей сети:

Это, конечно же, не готовая для продакшена схема – просто концепт, чтобы понять принцип работы и настройки всего этого. В нем всего одна ВМ маленького размера, использующая предопределенные компоненты в vRA, чтобы обозначить свои характеристики, предполагающие использование профиля образа и профиля особенности (последний – для узнавания размера). Она существует в одной сети vSphere без каких-либо маршрутизированных подключений, и подключена к сети со статическим TCP/IP-адресом. Эта ВМ настроена с пользовательской кастомизацией vSphere и помещена в ее папку.

Создание блюпринта

Чтобы создать блюпринт:

  1. Заходим на вкладку «Blueprints» и кликаем на «+New»;
  2. Вводим имя и описание;
  3. В «Project» задаем ассоциацию блюпринта с проектом;
  4. Выбираем, будет ли он ограничен только кругом членов проекта в «Shareability»;
  5. «Create»:

Панель компонентов блюпринта

Слева в интерфейсе блюпринтов у нас панель компонентов. Мы можем выбирать их и перетаскивать на канву дизайна. Функция доступна для таких облачных систем и технологий:

  • Cloud-agnostic,
  • vSphere,
  • NSX,
  • AWS,
  • Configuration management,
  • GCP,
  • Kubernetes,
  • Microsoft Azure:

Все перечисленное – это одноименные секции панели, которые можно раскрывать, чтобы увидеть различные типы компонентов для использования в блюпринте. Отметим, что в секции «Cloud Аgnostic» находится то, что можно применять к любой облачной системе, независимо от ее типа.

Панель канвы дизайна

Сборка базовых компонентов в канве дизайна происходит так:

  1. Выбираем объект в панели компонентов и перетаскиваем его в канву дизайна;
  2. Подсоединяем объекты (ВМ, сети, хранилища и т.д.);
  3. Пользуемся иконками в верхней части канвы, представляющими собой полезные функции, вроде удаления, дублирования, отмены действия, повтора действия и тому подобными:

Панель YAML

Панель YAML контролирует конфигурацию компонентов в канве дизайна:

YAML-код появляется, как только мы перетащим первый компонент в канву дизайна, причем, когда там будет осуществлено его подключение, это отразится и в панели кода. Редактор дает больше контроля над компонентами блюпринта и опций, предлагает правильный синтаксис и показывает разные возможности:

Он сообщает об ошибках и предлагает опции, опираясь на то место, в котором вы сейчас находитесь в коде. Объекты схемы выведены прямо из преднастроенных инфраструктурных составляющих, вроде особенностей и образов. Красный восклицательный знак служит индикатором ошибки. Желтая лампочка – того, что доступны кое-какие дополнительные опции.

По YAML мы публиковали компактный, но весьма поучительный, учебник вот здесь – рекомендуем ознакомиться перед тем, как приступать к использованию этой панели.

Разворот блюпринта

Когда наш блюпринт будет создан, логично, что его нужно развернуть. Для этого просто кликаем на «Deploy» внизу рабочего окна:

Замечание. В более ранних версиях vRA, если с ними работали, могли заметить, что перед тестированием блюпринта его следовало опубликовать и создать сервисы. Сейчас же, как только он готов, его тест стартует сразу же, как только мы нажали на «Deploy».

Создание зависимости машины от другой машины

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

указывает направление от зависимой машины к системе предварительных требований. Также данную возможность можно закодить вручную в YAML с помощью «dependsOn», как показано на второй части скриншота выше.

Таких зависимостей в YAML можно наплодить множество, выведя несколько ресурсов под директивой «dependsOn». Кроме того, доступно и ручное, с помощью канвы дизайна, подключение одного ресурса ко множеству других. К примеру, для того, чтобы одну облачную машину соединить с двумя другими облачными машинами (делаем по одной за раз). Учтите, что все объекты под этой директивой предоставляются до предоставления объекта, от них зависящего.

Использование тэгов

Как мы знаем, тэги представляют собой текстовые строки, прикрепленные к ресурсу (в случае vRA ресурсами выступают облачные зоны, вычислительные ресурсы, сетевые профили и профили хранилищ). При этом каждому ресурсу может быть сопоставлено множество тэгов. Блюпринты могут использовать тэги, чтобы выбирать, который из ресурсов должен сейчас использоваться. В качестве примера приведем секцию возможностей («Capabilities») облачного аккаунта:

Тэги можно создавать, добавлять и удалять непосредственно в использующих их компонентах.

Важно! Тэги в vRA напрямую не связаны с тэгами в vSphere. vRA не собирает тэги vSphere при инвентаризации данных систем vSphere.

Вообще же, тэги – чрезвычайно полезная штука: они помогают организовать ресурсы по их возможностям (включая скорость сети, назначение, сетевое подключение, стоимость хранения, назначение облачной зоны – продакшен или девелопмент – и пр.), местоположению (в т.ч. географические дивизионы), типу (разные виды платформ, к примеру, AWS или GCP, индикация назначения – девелопмент, QA, продакшен и т.д.) и любым другим критериям:

Управление тэгами производится в «Infrastructure» – «Configure» – «Tags». Здесь можно их фильтровать и локализировать:

Кроме вывода всего списка существующих в системе vRA тэгов, здесь можно создавать новые и удалять старые, а также определять все места, где используется тот или иной тэг.

Тэги возможностей и тэги ограничений

Тэги могут использоваться в возможностях и ограничениях:

Тэги возможностей помещаются на указанный ресурс, чтобы служить индикатором возможности, а тэги ограничений, в свою очередь – используются либо в блюпринте, либо в проекте. Последние заставляют развертывание происходить только на тех ресурсах, где тэг возможности совпадает с тэгом ограничения.

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

Тэги ограничений в проектах могут быть жесткими или мягкими. Если жесткое ограничение не выполнилось, разворот фейлится. Поэтому предпочтительней использовать мягкие ограничения – даже если с ними согласия не достигнуто, развертывание все равно случится.

Создание, удаление и применение тэгов

Чтобы добавить тэг к ресурсу нужно:

  1. Открыть на редактирование ресурс (например, зону или профиль) в «Infrastructure»;
  2. Найти секцию «Capabilities» в панели ресурсов (или напрямую в части «Tags» панели – зависит от специфики тэга);
  3. Ввести свой тэг в текстовое поле «Capability tags». Если введенный тэг совпадает с существующим, он появится в строке. Можно на него кликнуть, чтобы добавить к ресурсу, по завершению задания нажав на «Enter»:

Ненужный тэг можно удалить со специфического ресурса, если кликнуть по нему на иконку «Х». Однако, заведенным в системе в таком случае он все же останется. Чтобы полностью уничтожить тэг, нужно пройти в «Infrastructure» – «Configure» – «Tags», и тогда он автоматически удалится сам изо всех ресурсов, куда был прикреплен ранее.

Просмотр тэгов доступен и на карточках каталога (карточках облачных аккаунтов, клауд-зон, вычислительных ресурсов, сетевых профилей и профилей хранилищ):

Это очень удобно, так как позволяет быстро понять, какие объекты ассоциированы с карточкой каталога и обладают соответствующими возможностями. Также можно понять, которые объекты нуждаются в добавлении тэга или его удалении.

Одним из приоритетных назначений тэгов является указание конкретики ресурсов к использованию в блюпринте. Чтобы это реализовать, следует:

  1. Найти YAML-код для нужного объекта в канве дизайна;
  2. В секции свойств добавить ограничения;
  3. Под ограничениями добавить тэг:

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

Когда машины будут разворачиваться, vRA применит к ним тэги:

Так как каждый развернутый под проектом блюпринт обладает созданным тэгом и применяет его на конечную точку.

Управление хранилищем

Управление хранилищем – краеугольный камень грамотного управления ресурсами. В отличие от CPU и памяти, хранилище не является гомогенным, может быть одного из множества доступных типов, часть которых, как мы знаем, отличается более высокой скоростью (SSD), оно может быть более дорогим, по сравнению с товарищами по цеху, будет слишком специфичным по своим характеристикам (NFS), а также может иметь слишком маленькое свободное пространство своих массивов, обладать разными пропускными способностями IOPS и т.д. Грамотно управлять всем этим разношерстным хозяйством помогают профили хранилищ в vRA.

Удобно, что профили хранилищ vRA могут напрямую взаимодействовать с политиками хранения ВМ в vSphere, а также полноценно применяться в других облачных аккаунтах. Рассмотрим пример. Предпочитаемое для региона хранилище выбирается, как показано на скриншоте:

Здесь у нас дефолтный профиль, и, если не ограничить диск или не установить политику хранения в блюпринте, по возможности его дефолтная политика применится.

Создание профилей хранения в vRA и их использование

Новый профиль хранения, связанный с политикой хранения ВМ vSphere (уже заведена нами ранее), создается следующим образом:

  1. Проходим в «Infrastructure» – «Configure» – «Storage Profiles» и кликаем на «+New Storage Profile»;
  2. Вводим имя и описание блюпринта;
  3. Выбираем облачный аккаунт/регион;
  4. Называем профиль хранения и задаем его настройки (в нашем случае выбираем соответствующую политику хранения ВМ vSphere в выпадающем меню «Storage policy»);
  5. Создаем новый или прикрепляем существующий тэг возможности;
  6. Нажимаем на «Create» для сохранения настройки и старта создания нового профиля:

В vRA существует функционал отметки профиля хранилища как предпочитаемого с последующим его применением к определенному региону. Что пометить профиль таким образом, нужно:

  1. Пройти в «Infrastructure» – «Configure» – «Storage Profiles» и кликнуть на «Browse» в карточке каталога желаемого облачного аккаунта/региона;
  2. Нажать на профиль хранения, который хотим определить дефолтным для этого облачного аккаунта;
  3. Проскроллить страницу и поставить галочку в «Preferred storage for this region»;
  4. Кликнуть на «Save»:

Важно! Если используется тэг с ограничением, предпочитаемое хранилище может не примениться.

В блюпринтах профили хранения могут использоваться двумя путями: либо указанием профиля хранения для конкретного диска, либо применением тэга для ограничения машины при использовании профиля хранения. Во втором случае тэг применится ко всем дискам, являющимся частью образа машины, в т.ч. и к тому, на котором ОС:

Но, указывать профиль хранения в YAML-коде для машины нельзя – только через ограничение машины тэгом. На компонентах диска профили хранилища идентифицируются по имени в YAML-коде. Если к машине прикреплено несколько дисков, разные диски, при необходимости, могут использовать разные профили. Чтобы ограничить машину с помощью тэга, нужно добавить следующее в YAML-коде:

  • свойство хранения к машине;
  • ограничение под хранилищем;
  • тэг, соответствующий тэгу в профиле хранилища:

Важно! Указываемый тэг может использоваться одним и только одним профилем хранилища. Если одинаковый тэг встречается во множестве профилей, он будет недоступен для выбора в указанном профиле хранилища. Вместо этого развертывание рандомно выберет профиль хранилища vRA, который отвечает тэгу в блюпринте.

Также можно использовать в YAML-коде профили хранения vRA на компонентах диска. Для этого диск должен быть прикреплен к машине в канве дизайна, и тогда просто нужно добавить свойства в коде в разделе диска, а в них уже – объект «storagePolicy» и упомянуть профиль хранения по имени:

Если ограничить машину в использовании политики хранилища по тэгу и идентифицировать ее по имени в дисковой части YAML-кода, vRA будет игнорировать ассоциированную с диском политику.

Также можно определять хранилище как «Storage That Is Used». Хранилище контролируется правилами:

  • Тэг ограничения на машине перезаписывает другие свойства хранилища, за исключением тэгов ограничений на отдельных дисках, игнорируя и их, и предпочитаемое хранилище;
  • Тэг ограничения на диске перезаписывает использование тэгов ограничения на машине или параметры предпочитаемого хранилища;
  • Профиль хранения на диске используется, если тэг ограничения недоступен на машине, а хранилище – доступно;
  • Профиль хранения, выбранный в качестве предпочитаемого, используется на всем хранилище, если не назначено никаких политик хранения или тэгов.

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

Использование томов («Volume»)

Том, как известно, это логический диск, который может либо обнаруживаться через сбор данных на облачных аккаунтах, либо ассоциироваться с рабочими нагрузками, предоставляемыми Cloud Assembly, и является отдельным объектом в управлении хранилищем vRA. Увидеть тома можно в «Infrastructure» – «Resources» – «Volumes»:

Разные операции с Service Broker

Service Broker, по факту – это упрощенный пользовательский интерфейс. Весьма удобный для пользователей, не нуждающихся в полном доступе для разработки и построения блюпринтов или шаблонов. Доступ к нему предоставляют, естественно, администраторы организации. Они же создают каталог объектов (вкладка «Catalog»), импортируя выпущенные в Cloud Assembly vRA блюпринты и шаблоны Amazon Web Services CloudFormation. Пользователь, в свою очередь, может их разворачивать в регионах облачных провайдеров, запрашивать и отслеживать процессы предоставления. А после разворота – управлять развернутыми объектами каталога через свой UI.

Обо всем этом вкратце мы писали в нашем предыдущем материале цикла по vRA, как, впрочем, и о развороте, а также базовой настройке – с процедурами импорта реализованных облачных шаблонов, инициации их для проектов, создания каталога объектов и предоставления к нему общего доступа пользователям. Сегодня же поучимся многим другим операциям с Service Broker.

Но, для начала поясним, что объекты каталога могут включать не только блюпринты Cloud Assembly и шаблоны Amazon CloudFormation, но и действия по расширению, а также другого типа разворачиваемые шаблоны. По сути, это спецификации для одной или более машин, сетей и других компонентов, которые мы хотим развернуть у облачного провайдера. И напомним, что вход в Service Broker осуществляется через консоль vRA под соответствующими правами доступа уровня администратора или пользователя.

Выпуск блюпринтов для последующего импорта в Service Broker

Если на блюпринте Cloud Assembly кликнуть на «Release», мы выпустим более старую версию блюпринта. Если же на «Version» – сможем поставить галочку в «Release this version to the catalog», и тогда выпустится текущий вариант:

Опция «Unrelease» позволяет удалить блюпринт из каталога Service Broker. Учтите, что импортируются в сервисный каталог только выпущенные блюпринты по выбранному проекту.

Важно! Выпускать можно только блюпринты с версией.

Импортированные блюпринты приведены в секции «Content» левой панели. Выше этой секции есть «Content Source», где определяется исходник импортируемых в сервисный каталог блюпринтов:

В прошлой статье мы пользовались уже готовым источником контента, однако, при необходимости, можно легко создать новый, как показано на этом скриншоте. Учтите, что шаблоны после добавления нового источника контента будут обновляться каждые шесть часов. Если шаблон отредактировать во внешних источниках, изменения в каталоге отобразятся после обновления. При добавлении нового или редактировании старого шаблона, естественно, хочется увидеть изменения скорее, тогда можно открыть на редактирование источник контента и просто нажать на «Save and Import».

При удалении источника контента импортированные объекты удалятся из каталога. Однако, что интересно, на блюпринты Cloud Assembly воздействие ими все еще будет оказываться.

Работа с определениями политик и их применением

Политики – это набор правил или параметров, применяемых в управлении и осуществлении разворотов. Они доступны на вкладке «Content & Policies» – «Policies» – «Definitions». В текущей версии продукта показываются два типа политик:

  • политики аренды,
  • политики действий Day-2:

Политики аренды определяют время, которое развертывания будут доступны для использования, пока не уничтожатся, и не высвободятся ресурсы.

Новосозданные политики применяются как к новым разворотам, так и к текущим. После их сохранения нужно подождать, пока Service Broker оценит и отработает политику. Создавать их и применять можно как к разворотам в проекте, так и к организации целиком:

В окнах создания новой политики обоих типов задается:

«Scope» – диапазон, определяющий, будет ли она применяться ко всем развертываниям в этой организации или только к развертываниям конкретного проекта;

«Deployment Criteria» – если хотим уточнить, когда именно политика применяется в выбранном диапазоне, добавляем соответствующие критерии;

«Enforcement type» – тип применения может быть либо жестким («Hard»), либо мягким («Soft»). Жесткие политики имеют более высокий ранг по сравнению с мягкими, и перезаписываются ими, в случае чего;

«Lease (days)» – максимальный срок активности разворота, в течение которого пользователи смогут арендовать разворот, либо успеть продлить аренду;

«Grace period (days)» – количество дней между окончанием срока аренды и финальным уничтожением развертывания. Именно в него можно безболезненно продлить аренду на следующий период времени, если это не противоречит тому, что указано в значении «Total Lease». О его наступлении арендаторам отправляется сообщение по email;

«Total lease (days)» – максимальный срок, до которого можно продлевать аренду, по истечению которого вступает в силу «Grace period», а затем развертывание уничтожается уже окончательно;

«Actions» – здесь можно предоставить пользователям, например, права на удаление машин vSphere и Microsoft Azure в их развертываниях (выбирается «vSphere» и «Cloud.Azure.Machine.Delete», соответственно). Чтобы найти действие, в строку поиска нужно ввести тип ресурса или развертывание. Если в конце строки допечатать «*», получим все возможные действия (с облачными ресурсами системы vSphere – «vSphere.*», а с действиями на уровне развертываний – «Deployment.*»);

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

Применение политик является информацией только для чтения, доступной администраторам Service Broker – секция «Enforcement» под «Policies»:

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

Работа с развертываниями

На вкладке «Deployments» можно отслеживать запросы – если кликнуть на объект запроса, можно просмотреть информацию о развертывании:

Здесь есть три вкладки:

  • «Topology» – визуализация структуры развертывания и ресурсов,
  • «History» – представление событий и любых ивентов, связанных с запускаемыми после развертывания запрошенного объекта действиями. Если процесс предоставления даст сбой, здесь легко осуществлять траблшутинг,
  • «Monitor» – утилизация CPU, памяти, IOPS хранилища и сетевых I/O.

В «Deployments», на самом деле, осуществляется вообще все управление развертываниями ограниченным числом опций. Если кликнуть на интересующий разворот, выбрать объект (например, ВМ) и нажать на «Actions» в выпадающем списке можно найти нужное действие:

Работа с запросами и развортом объекта каталога

После того, как мы опубликовали наш блюпринт или другой объект, и он стал доступен в каталоге, логично, что пользователям с соответствующими правами захочется его развернуть. Для этого нам нужно просто зайти в «Catalog», где высветятся все доступные объекты по проекту, с учетом членства в нем пользователя. Затем выбираем сам объект, используя фильтрацию, поиск, сортировку, после чего нажимаем на «Request», вписываем в форму всю требуемую информацию, в т.ч. указав версию релиза (если их больше одной, предоставится выбор), имя, проект и прочее, в зависимости от того, какого типа шаблон создавался, и кликаем на «Submit». Процесс предоставления будет показан на вкладке «Deployments» в самом верху списка.

В Service Broker предлагается дефолтная форма запросов с минимумом опций:

Но, администраторы могут использовать функцию пользовательской формы («Custom Form»), чтобы ее кастомизировать:

Чтобы в нее попасть, проходим в «Content & Policies» – «Content» и нажимаем на «Customize form»:

В появившемся окне редактора (уже знакомая нам канва дизайна):

перетаскиваем элементы (из панели элементов слева) и используем панель свойств (справа), чтобы настроить каждый – внешний вид полей (вкладка панели свойств «Appearance») и дефолтные значения («Values»), видные пользователю, определение правил, по которым оценится, правильно ли был создан пользовательский запрос («Constraints») и пр.

Как только мы активируем отредактированный вариант (ползунок в правой верхней части канвы), форма проапдейтится.

Разные операции с Code Stream

О таком компоненте vRA, как Code Stream, в нашей предыдущей статье из актуального цикла написано немало. В том числе и как готовиться к его адаптации и, пользуясь Guided Setup, осваивать основные его возможности (вот ссылочка на эту информацию).

Чуть расширим и углубим этот вопрос, прежде всего очертив зону ответственности Code Stream. Помимо описанного выше управления повторяемыми развертываниями Kubernetes (ниже поговорим об этом подробнее), Code Stream полезен в кастомизации скриптов, апдейте непрерывных обновлений в продакшене, в скоростных разворотах тестовых приложений, интеграции оповещений в задачи, интеграции с Powershell, API и SDK управлении в и вне разворотов, а также в тестировании и апдейте образов для оценки изменений в «железе» и обновлениях.

Code Stream разворачивает системы и сервисы точно так же, как и Cloud Assembly, может оттуда развертывать блюпринты и выполнять рабочие процессы vRO. Конвейеры софта разрешают прямую интеграцию множества инструментов, в т.ч.:

  • REST,
  • SSH,
  • TFS (Microsoft Visual Source),
  • пользовательских ресурсов, связанных с API или REST и внешними инструментами, вроде IE Ansible или Helm:

Ключевой принцип непрерывной интеграции и непрерывной доставки (CI/CD) Code Stream лежит в беспрерывном прохождении через процессы, включающие разработку кода, его разворот, тестирование, возвращение на исходные позиции и его улучшение/корректировку перед следующим разворотом. А конвейер софта позволяет автоматизировать этот процесс. Жизненный цикл конвейера состоит из создания конечных точек, организации самого конвейера, запуска его и слежения за выполнением при помощи различных панелей мониторинга, которые можно настраивать для вариативных сценариев.

Интерфейс Code Stream

UI Code Stream считается самым простым в семействе vRealize. Все его вкладки доступны с левой панели, поделенной на три секции:

  • Панели мониторинга («Dashboards»), выполнения («Executions»), пользовательские операции («User Operations»), конвейеры («Pipelines») – статистика, слежение за выполнением, создание и управление конвейерами,
  • Настраиваемые интеграции («Custom Integrations»), конфигурация («Configuration») – настройка конечных точек для других систем, вроде кластеров Kuberenetes, Cloud Assembly и vRO,
  • Триггеры («Triggers») – триггеры к системам автоматизации для таких вещей, как создание тикетов и использование Git-репозиториев:

Добавление конечных точек

Существует множество типов конечных точек под Code Stream, к тому же они еще и предоставляют LB:

Конечные точки привязаны к проектам Cloud Assembly, поэтому в первую очередь при их добавлении выбираем проект из выпадающего меню:

А затем тип – как показывалось на скриншоте выше. В итоге у нас должно получиться что-то вроде такого:

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

Настраиваемые интеграции

Администратор может установить настраиваемую конечную точку, используя Python2/3, Shell или NodeJS. Это позволяет устанавливать подключения к нетрадиционным конечным точкам, вроде Slack, или даже к приложениям, созданным из конвейеров. Чтобы поработать с этой возможностью мы должны установить URL или IP-адрес конечной точки, аутентификацию в скрипте, а также убедиться, что у нас поддерживаются API-команды или наборы скриптов:

Большинство интерфейсов используют SDK и API-протоколы. Это очень помогает в имплементации систем сообщений или передаче оповещений на специализированные системы, например, на Change Request Systems.

Иногда полезно установить протоколы для построения системы с целью будущего управления развертыванием конвейера. Это одна из операций инструментария Day 2, которую можно применять вместо рабочих процессов оркестровки, при необходимости.

Работа конвейеров и их потоки

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

В конвейеры встроены этапы и задачи:

Использование этапов также ускоряет и делает более прозрачной процедуру отката. Каждая задача по откату назначается определенному этапу. Этапы же позволяют логически разделить задачи, чтобы облегчить управление и возврат к предыдущему. В рамках одного этапа параллельные задачи запускаются одновременно.

Вводы в Code Stream

В Code Stream существует три типа вводов: Regular, Password и Restricted:

Чтобы проапдейтить измененное или новое введенное значение, нужно просто нажать на «Save», раскрыв переменную в списке. За раз можно редактировать только один объект (этап, задачу или ввод).

Важно! Значения паролей зашифрованы и не показываются в логах.

Ограниченные вводы и переменные можно просматривать и изменять только под ролью администратора.

Если есть нужда в дополнительных типах полей, их можно передать напрямую из YAML или скрипта, поддерживаемого конвейером.

Добавление репозитория в Code Stream

Важно! Для Kubernetes добавлять репозиторий, обычно, нет нужды. Однако можно использовать внутренний такой репозиторий, который бы использовался напрямую из Kubernetes или по URL.

Наличие репозитарной системы упрощает контроль над множеством кластеров с помощью центрального репозитория образов. Некоторые типы репозиториев, вроде YUM или GitHub, могут быть интегрированы с несколькими системами одновременно:

После того, как опция репозитория добавилась, конвейер может вызывать напрямую оттуда указанные образа и помещать их в Docker или Kubernetes.

Моделирование процесса выпуска и построение конвейера

Можно построить один единственный конвейер, который будет иметь доступ ко множеству конечных точек и запускать сложные задачи. Позволяя называть конечные точки хостов, локаций билдеров образов, а также ограничивая память и CPU. Вводы и выводы в нем разработаны для сбора пользовательских данных в процессе запуска конвейера и вывода переменных в различные системы и задачи конвейера.

Важным моментом в построении конвейера является конфигурирование оповещений и внесение в этапы задач по откату. Оповещения о процессах могут быть настроены таким образом, чтобы пересылаться в лог, а задачи по откату помогают справиться с фейлами, частично очищая развертывания.

Перейдем к конкретной практике.

Чтобы смоделировать процесс выпуска, нам нужно создать конвейер, отображающий этапы, задачи и одобрения, которые обычно используются в выпуске характерного для работы пользователя софта. Конечно, в первую очередь необходимо убедиться, что созданы и доступны конечные точки (на вкладке «Endpoints») и разработать конкретный план нативного билда, интеграций, а также, непосредственно, доставки кода. На последнем шаге стоит остановиться подробнее. Билды могут быть разными, в зависимости от насущных требований и специфики софта, с которым имеете дело. Например, CI (непрерывная интеграция), CD (непрерывная доставка) или CICD (непрерывная интеграция и доставка – комбинация двух предыдущих), для которых используются наиболее подходящие каждой концепции шаблоны:

Важно! Если конвейер использует образ с хаба докера, важно, чтобы образ обладал cURL, встроенным еще до того, как запустится сам конвейер. После запуска конвейера, Code Stream загрузит бинарный файл, использующий cURL для вызова команд.
  • CI. Перед планированием CI-этапа конвейера необходимо учесть внешние и внутренние требования, а также определить, что будем вписывать при вводе CI-порции шаблона. Понадобятся конечные точки: репозиторий источника кода Git (там девелоперы будут проверять код, а vRA станет использовать последний его вариант, после подтверждения специалистами изменений), сам Git, Docker (если хосты построены на нем, чтобы запускать команды построения внутри контейнера), Kubernetes (чтобы Code Stream разворачивал образ в соответствующем кластере), образ билдера (создает контейнер, на котором и будет запускаться непрерывная интеграция), Image Registry (чтобы хост на докере мог тащить образ построения оттуда). И, конечно же, разнообразные инструменты для построения (тип билда, к примеру, Maven, инструменты пост-тестирования, те же JUnit, JaCoCo, Checkstyle и FindBugs и пр.), инструменты для публикации (Docker – под контейнеры, тэг образа – это может быть как ID поручения, так и номер сборки), индивидуальные типы рабочих пространств (хост на докере, реестр образов, URL);
  • CD. Под этот этап нам понадобится конечная точка Kubernetes и любые типы сред/файлов, где сможет развернуться наше приложение (к примеру, Dev или Prod). Также понадобится YAML-файл Kubernetes, который будем выбирать в секции CD, кликнув на «Select» и применять по кнопке «Process»:

Как мы видим, здесь, кроме этого, выбирается сервис, конечная точка кластер и стратегия развертывания. Моделей при этом существует несколько и вводы под них будут соответствующими. Например, выбранная на скриншоте «Canary» потребует ввода процента для фазы разворота;

  • CICD. Под этот вариант требуется разработка плана и для CI, и для CD. То есть, оба предыдущих пункта планирования проходим последовательно.

Очень удобно (и во многих случаях вполне достаточно) использовать в построении CICD-конвейера шаблон смарт-конвейера, выбрав в «Pipelines» – «New Pipeline» – «Smart Templates»:

и затем подходящий шаблон:

Он заполняется, после чего конвейер сохраняется с этапами, которые подскажет шаблон (всегда можно отредактировать в будущем, буде в том нужда):

Теперь нам нужно всего лишь включить конвейер и запустить его, после чего можно будет убедиться в его успешности, зайдя в «Executions», а также обязательно нужно проверить, работает ли правильно веб-перезватчик Git: на вкладке «Activity» отразятся соответствующие события («Triggers» – «Git» – «Activity»). И, наконец, понаблюдать за трендами на панели мониторинга конвейеров («Dashboards» и ищем нашу панель, либо же создаем собственную панель для отчета по дополнительным KPI).

Если же готовыми шаблонами пользоваться не хочется, там же, в «Pipelines» – «New Pipeline» просто выбираем «Blank Canvas», кликаем на этап и перетаскиваем несколько задач по непрерывной интеграции или доставке из навигационной панели в наш этап. Если нужно настроить задачу нерерывной интеграции/доставки, кликаем на нее, а затем переходим там на вкладку «Task», добавляем шаги, как мы их видим, включая пути к артефактам зависимости, локацию экспорта, используемые инструменты теста фреймворка, хост докера и образ построения, а также реестр контейнера, рабочую директорию и кэш. После чего сохраняем конвейер и включаем его. Теперь необходимо внести изменения в код на GitHub/GitLab – триггер Git активирует наш конвейр, и он запустится.

Чтобы проверить, вызвали ли изменения в коде конвейер, кликаем, как уже говорилось выше, на «Triggers» – «Git» – «Activity», а за выполнением (убедиться, успешно ли созданы все этапы и экспортировался образ построения) можно следить в «Executions»:

Окончательно за работой конвейера, KPI и трендами, можно наблюдать в «Dashboards» – «Pipeline Dashboards».

Оповещения

Оповещения дают нам знать через email, тикеты в Jira или пользовательские интернет-перехватчики обо всех сбоях или, наоборот, успехах работы конвейера. Создаются они здесь:

по каждому этапу в отдельности после выбора этапа и панели оповещений в верхнем правом углу.

Важно! Если работаете с веб-перехватчиками, помните, что они опираются на публикацию или обновление в формате REST.

Если вписать значок «$» в любое из полей перед значением, вызовется вариативный селектор, позволяющий уточнить ввод или свойство в конвейере. Но, список переменных при этом не покажется, исключая возможность авто-выбора.

Откат сфейлившихся этапов

Процедура роллбэка является одним из инструментов построения пользовательских конвейеров и помогает вернутся к определенным этапам:

И настраивается она на специальной вкладке правой панели.

Отдельный откат конвейера может быть прикреплен не только к этапу, но и к конкретной задаче. Для простоты рекомендуется создавать задачи с включенным там «continue on failure», чтобы можно было проверить, все ли элементы создались. Администраторы могут использовать функции «get functions» и «run conditions», чтобы было видно, создались ли элементы и в докере, и в Kubernetes. Но, персональные задачи по откату более гранулированы и, к тому же, существенно ускоряют процесс, однако требуют большее число конвейеров при создании.

Мониторинг конвейеров

Панель мониторинга конвейеров весьма информативна и полезна, так как показывает по конкретному конвейеру, запущен ли он, каковы тренды, выводит топ сбоев и успешных изенений. Она создается прямо в момент окончания работы над конвейером и содержит несколько виджетов:

  • Статусный счетчик выполнений (общее кол-во выполнений по конвейеру за период времени с группировкой по статусу – Completed/Failed/Canceled, настройки демонстрации можно менять);
  • Статистика выполнений (случаи восстановления, доставки или фейла для конвейера за период времени, а вообще вот весь список состояний, которые применяются к любому конвейеру, независимо от его типа:
    • Completed,
    • Failed,
    • Waiting,
    • Running,
    • Canceled,
    • Queued,
    • Not Started,
    • Rolling Back,
    • Rollback Completed,
    • Rollback Failed,
    • Paused);
  • Топ сфейлившихся стадий и виджет задач (процент сбоев и их кол-во для девелопмента и пост-девелопмента по каждому конвейеру и проекту, усредненное за неделю или месяц);
  • Тренды продолжительности выполнений (показывает MTTD, MTTF, MTBD и MTTR за период времени):

  • Тренды выполнений (общее кол-во запусков конвейера в день, ежедневно, группировка по статусу за период времени. Обычно, за исключением текущей даты, счетчики показывают только COMPLETED/FAILED запуски):

Это – встроенные примеры панелей мониторинга. Но, как уже говорилось выше, можно создавать и собственные, с желаемой репрезентативностью. Для этого заходим в «Dashboards» – «Custom Dashboards» – «New Dashboard», затем для настройки панели кликаем на виджет и приводим его в надлежащий вид, нажав по нему на иконку редактирования, выбрав конвейер, назначив все доступные опции и колонки, которые хотим, чтобы показывались, а затем сохраняем конфигурацию по «Save». После сейвим всю пользовательскую панель мониторинга снова кнопкой «Save» и закрываем ее окно «Close». Если хочется, чтобы демонстрировалось больше информации о конвейере, кликаем на активные области виджета.

Продвинутые функции vRA

Сейчас мы поговорим о т.н. «Extensibility» – комплекте функций, приятно расширяющих возможности vRA. Благодаря ему администраторы могут создавать пользовательские рабочие процессы vRealize Orchestrator или ABX-действия, дабы охватить задачи, которые нельзя завершить обычными спецификациями. Расширенный комплекс функций может использовать для интеграции богатого функционала сторонних систем и других продуктов VMware, например, vRealize Orchestrator, прямого Python, скриптов NodeJS, причем, без доступа к дополнительным системам и ручным настройкам. Из блюпринта можно управлять не только перечисленным, но и внешними системами, вроде CRM или Puppet-серверами.

Яркими примерами продвинутых функций могут служить:

  • Имплементация изменений записей DNS;
  • IPAM-решения;
  • Добавление пользователей и регистрация доменов;
  • Выполнение PowerShell-скриптов;
  • Взаимодействие со сторонними инструментами (ServiceNow и др.);
  • Инсталляция софта;
  • Ежедневные операции, например, бэкапирование.

Event Topics

Реализован целый комплекс встроенных топиков событий («Event Topics» в секции «Library»), каждый из которых связан с определенным периодом на протяжении жизненного цикла развертывания:

Любое событие включает блокируемый флажок, тип издателя ресурса («Resource Publisher») и описание.

Все события не блокируются, так как блокируемые события запускают асинхронизированные рабочие процессы. Однако, блок может быть полезен, когда необходимо организовать определенный порядок на основе приоритезации для обеспечения линейного прогресса. Кроме того, блокируемые события позволяют запускать несколько событий одновременно. Что касается типа издателя, он помогает узнать тип связанного с событием ресурса. Например, развертывание из каталога блюпринтов или предоставление отдельного его объекта из схемы – все это распространенные типы издателей.

Каждый топик события показывает перечень составляющих схемы, если открыть прямо в списке всех событий:

Чтобы узнать о них больше, достаточно просто навестись мышкой. Любое свойство события в схеме может заполняться путем добавления «event properties» к YAML-коду блюпринта, либо же исключаться оттуда в процессе создания. Серая маленькая иконка правее значка «S» в синем кружочке показывает массив значений для свойства.

ABX-действия («Actions»)

В vRA можно добавлять пользовательские Python или NodeJS скрипты:

Если удалить контент из текстового поля «Template» вверху экрана, можно увидеть множество встроенных примеров для ускорения процесса разработки и демонстрации форматирования. Вводы же создаются на боковой панели справа. Если кликнуть по иконке «+» рядом с существующим вводом, можно их добавить столько, сколько необходимо. Выбор FaaS-провайдера поменяет вывод, чтобы он соответствовал назначению намерения. Для блюпринтов широкого спектра требуются дополнительные действия по каждой конечной точке.

Действия могут импортироваться и экспортироваться между средами. Если поставить галочку в чекбоксе слева от действия, можно добраться до опций «IMPORT» и «EXPORT»:

ABX-действия могут выполнять REST-запросы и REST-опросы:

REST-действия – это: «GET», «POST», «PUT», «PATCH», «DELETE» и «POLL».

О FaaS

Публичные облака предлагают нам Function as a Service (FaaS). Что это означает для нас и какова польза данной возможности? Во-первых, уточним, что здесь имеется в виду под функцией: это маленькая программка, управляемая событиями. Ее формальный аналог в vRA – ABX. FaaS равно успешно существует как в Microsoft Azure, так и в Amazon Web Service. То есть ABX можно использовать как on-premises, так и в упомянутых облаках:

Во множестве случаев FaaS представляет собой неплохую альтернативу vRealize Orchestrator, о котором поговорим в следующем подразделе в подробностях. Правда, она не поддерживает настолько широкую интеграцию и сложность задач, как vRO, тем не менее, польза от нее весьма наглядна. Попробуем разобраться, когда применять ABX, а когда – vRO. Если нам нужно запустить действие в облачной системе, хочется чего-то простого и понятного, если нет нужды в применении внешнего сервера (вроде сервера vRO), желательно ограничить использование памяти и время, и, наконец, если наше действие должно напоминать программу со стандартным кодом – наш выбор, однозначно, падет на ABX. А вот, если приходится использовать плагин vRO по не зависящим от нас причинам, мы любим работать в граф-интерфейсе с функцией перетаскивания, нужны сложные привязки вводов/выводов, предпочитаем JavaScript, а не Nodejs, и вообще логика достаточно непростая, хочется управляться с непростыми ошибками и есть необходимость вызова рабочего процесса не подпиской, кроме vRO у нас-то и вариантов нет…

И vRO, и ABX дают доступ к логам и переменным, использованным в недавних запусках. Оба могут применять свойства ввода vRA, схемы событий и метаданные для ввода, обладают логикой вложенности (рабочие процессы могут вызывать другие, или же действия, соединенные в потоки действий), а также равно успешно управляются с любой системой. Но, прелесть ABX-действий в том, что они становятся доступными, как только вы их создали, а при организации рабочего процесса vRO приходится ждать синхронизации инвентаря от vRA, чтобы он увидел новый процесс, что происходит не чаще, чем раз в 10 минут, причем вручную инициировать этот процесс невозможно.

Вызов ABX-действий с подпиской происходит точно так же, как мы вызываем рабочий процесс vRO (см. ниже): мы создаем подписку vRA, выбираем ивент-топик и после этого можем раскрыть и оценить схему, используя удобную фильтрацию в подписке на JavaScript:

Важно! События нужно выбирать с осторожностью, ведь ABX-действие должно запуститься в определенное время. Если попытаться использовать настраиваемое свойство в неправильное время, можно получить ошибку типа «Key Error» при попытке доступа или модификации настраиваемого свойства.
Важно! Хорошей практикой считается предварительный тест подписки на разных топиках событий, чтобы выбрать идеальную.

На правой панели выводится информация по функции, дефолтным вводам, зависимостям и FaaS-провайдеру:

Если в действии более одной функции, здесь будет показана главная (первая примененная к действию) – «Main function». Дефолтные вводы ниже – это жестко запрограммированные вводы, которые удобно использовать при тестировании. Они игнорируются при вызове событием запуска, если такой же ввод был предоставлен настраиваемыми свойствами или метаданными. Либо же здесь может быть ввод, меняющийся нечасто. Зависимости ниже представляют собой любые импортированные модули, в которых нуждается функция. В поле «FaaS provider» по дефолту проставляется «On Prem», но, при необходимости, туда можно проставить любого облачного провайдера, с которым работаем. Под этим полем вводится опциональный контроль над размером памяти и продолжительностью действия.

Карточки каталога ABX-действий

Карточки каталога ABX-действий прекрасно информативны и позволяют контролировать происходящее. В них содержится имя действия, иконка, показывающая вид действия (Script, Action-Flow, REST), строка типа, демонстрирующая тип действия (если это – скрипт, то и язык, в нем используемый), проект, с которым действие ассоциировано, время и дата последнего апдейта действия, функция открытия, экспорта или удаления действия:

Правда, нет функции дублирования – если оно необходимо, рекомендуется экспортировать действие и импортировать его обратно с другим именем.

Кодировка ABX-действий

Вводы и выводы в ABX-действиях не зависят от своего языка – YAML-код блюпринта будет одинаков, независимо от того, на чем они написаны. Например, если нам нужно передать новое имя ВМ в действие, оно будет передано как строка и выглядеть в разных языках вот так:

По best practice мы должны устанавливать выводы, прежде всего, на пустом объекте, загружать весь объект вывода с помощью дефолтного объекта ввода, а уже после этого можно изменять свои настраиваемые свойства, опираясь на новое значение. Иначе выдаст сообщение об ошибке. Так как ABX-действие является функцией, завершать ее нужно оператором возврата:

Комплексные схемы и сложные преобразования переменных

Большинство объектов схем являются просто строками, но некоторые представляют собой комплексные объекты. Например, тэги – это комплексные объекты, составленные из пар «ключ-значение»:

А некоторые вообще являются массивами.

Известно, что все данные из YAML поступают в ABX как строка, но некоторые настраиваемые свойства являются комплексными объектами, нуждающимися в чем-то большем, чем строка. Например, в NodeJS мы можем конвертировать строку из YAML в объект JSON при помощи функции «JSON.parse»:

Аналогичные функции существуют и в PowerShell, и в Python.

Потоки ABX-действий

Поток ABX-действий представляет собой комбинацию скриптов действий ABX, позволяющую работать над более сложной автоматизацией. Все потоки действий должны начинаться с «flow_start» и оканчиваться «flow_end». Можно так настроить поток действий, чтобы он выдавал ошибку на определенных этапах потока, применяя элемент обработчика ошибок. Для этого нужно указать действие для условия «onError».

Мы можем связывать несколько существующих скриптов действий вместе с целью образования потока последовательно, разветвленно, присоединением и с условием:

Разветвление («fork») позволяет запускать два потока рядом:

Последовательные («sequential») потоки действий выглядят так:

Вывод переменных из одного действия может быть использован как ввод в любом другом последующем. Если кликнуть на иконку «глаза» в графическом представлении, нам покажут код для указанного действия. Из одного действия данные можно отсылать в последующее в потоке действий:

И в каждом действии при этом можно применять множество выводов и вводов.

Присоединение означает, что поток может продолжаться либо в состоянии «all» (ожидает завершения всех веток), либо в состоянии «or» (если какая-либо ветвь завершается, поток продолжается).

Условие переключения («condition») позволяет контролировать путь:

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

Счетчики действий

Счетчики действий располагаются сверху справа и позволяют отслеживать и проверять кол-во версий в этом действии, подписок и потоков действий, вызывающих это действие, а также кол-во запусков этого действия:

Каждый ярлык здесь – это ссылка, позволяющая напрямую переместиться к тому или иному объекту.

Контроль версий в ABX-действиях работает точно так же, как и контроль версий в YAML-блюпринтах (см. выше):

Работа с ним начинается после нажатия на ссылку «CREATE VERSION» вверху панели кода. И после создания более одной версии, станет доступна в счетчиках действий ссылка «VERSIONS».

Информация о запусках действий

Если пройти в «Extensibility» – «Activity» – «Action Runs», можно увидеть историю случившихся запусков действия. Либо же можно просто кликнуть на ссылку «RUNS» в счетчике действий (см. выше):

Здесь можно кликнуть на запуск любого действия, чтобы увидеть его лог, а также оценить вводы и выводы. Вкладка «Details» на правой панели дает полный отчет о запуске действия, всех переменных ввода и вывода:

Следующая вкладка «Log» выводит логи, в т.ч. сообщения об ошибках, все выводы из скрипта действия, а «Trace», соответственно, – трассировку и информационные сообщения о том, что случилось в процессе запуска.

Экспорт и импорт действия

Действие можно импортировать или экспортировать в zip-архив:

Рабочие процессы vRealize Orchestrator

Кроме действий, vRA предоставляет прямой доступ к рабочим процессам vRealize Orchestrator («Workflows» в той же секции «Library») через подписки. Существует масса встроенных рабочих процессов vRO, способных значительным образом улучшить Appliance при минимальной нужде в кодинге:

Внутренний сервис vRO уже встроен в Appliance, хотя, при желании, можно создать и внешний его инстанс и подсоединить его к своей системе с тем же успехом.

Добавленные в vRO рабочие процессы апдейтятся и появляются в списке после сбора данных, который, по дефолту, происходит каждые 15 минут. Установленные события можно связать с пользовательскими действиями или рабочими процессами vRO, снова-таки через подписки.

Свойства ввода в рабочем процессе vRO

«inputProperties» может служить переменной ввода в типе «Properties» рабочего процесса vRO:

В этом случае ее нужно включить в любой объект схемы, использующий переменные, как переменную ввода:

И другие переменные ввода также должны посылаться на тот же элемент схемы. Переменные в элементе схемы могут создаваться скриптом с использованием данных из inputProperties, и посылаться в качестве переменных вывода на другие элементы схемы. Каждый объект inputProperties включает в себя информацию об адресе («addresses», назначенный IP компоненту), «componentId» – имя, назначенное компоненту в YAML-блюпринте, «endpointId» – ID конечной точки, используемые для предоставления ресурсов, тэги, «resourceNames» – строчный объект свойств, например, имя, назначенное системе vSphere, «componentTypeId» – тип разворачиваемого объекта (к примеру, «Cloud.Machine»), «requestId» – идентификатор запроса, «deploymentId» – идентификатор разворота, «zoneId» – идентификатор вычислительной зоны, «projectId» – идентификатор проекта.

Из объектов свойств ввода можно получать данные, точно так же, как и из объектов пользовательских свойств. Например:

vspMacName = inputProperties.get(“resourceNames”)

componentType = inputProperties.get(“componentTypeId”)

ipaddr = inputProperties.get(‘addresses’)

Важно! Наименования свойств чувствительны к регистру.

Чтобы посмотреть список свойств ввода, доступных для нашего рабочего процесса, нам нужно пройти на вкладку «Variables» его запуска в vRO.

С использованием таких переменных можно производить такие действия:

  • Выводить имя ВМ и брать снэпшот;
  • Выводить имя хоста и IP-адрес и добавлять запись на DNS-сервер;
  • Спрашивать пользовательский идентификатор и пароль, а затем создавать пользовательский аккаунт AD;
  • Запрашивать название SQL-БД с целью создания;
  • Запрашивать email для отсылки сообщений.

Пример использования inputProperties в живом коде:

Пользовательские свойства в inputProperties

О пользовательских свойствах мы немножко говорили, когда выше учились их добавлять к блюпринту. В общем же, объект свойств «customProperties» является составляющей «inputProperties» (подмассивом), и включает такие объекты: «flavor» – сопоставление особенностей, «image» – сопоставление образов, «userDefinedString» – данные, определенные в YAML-блюпринте, «userDefinedNumber» – данные, определенные в YAML-блюпринте, «diskGB» – предоставленный размер системного диска ОС в Гб, «softwareName» – имя и версия ОС, «osType» – тип ОС (Linux/Windows), «resourceGroupNamе» – папка в vSphere, «cloudConfig» – все команды cloudConfig в YAML-блюпринте, «datastoreName» – датастор vSphere для праймари-диска.

Так же, как и в «inputProperties», все это чувствительно к регистру, и увидеть полный список объектов customProperties можно аналогично в vRO на вкладке «Variables» рабочего процесса.

Использование метаданных

В рабочих процессах vRO доступны метаданные, например:

_metadata_eventTopicId – сейчас запущенный топик ивента (показывает, какая подписка запустилась, если их множество вызывается одним и тем же рабочим процессом);

_metadata_userName – ID пользователя, запросившего разворот;

_metadata_hdr_blocking – значение «true»/«false», в зависимости от того, была ли заблокирована подписка;

и т.д.

Большинство объектов метаданных – это шестнадцатеричные ID-коды, определяющие разные части системы. В рабочих процессах vRO они бесполезны, но их список можно увидеть там же, где и вышеописанные переменные, а их написание отличается обязательным началом из нижнего подчеркивания.

Определенные пользователем переменные

В любую переменную из YAML-блюпринта можно напрямую загрузить данные в рабочем процессе vRO. Одним из примеров переменных могут служить «userDefinedString» и «userDefinedNumber». Определенные пользователем переменные можно называть как-угодно и размещаются они в секции свойств ресурса, например, в «Cloud.Machine», в коде:

И в отличие от перечисленных выше типов переменных и метаданных, они автоматически не загружаются из vRA. Получить «userDefinedString» можно кодом:

customProperties.get(“userDefinedString”)

а «userDefinedNumber»:

customProperties.get(“userDefinedNumber”)

По best practice рекомендуется начинать имена таких переменных всегда с «userDefined».

Подписки в vRA

Еще одна полезнейшая секция в правом меню – «Subscriptions», помогающая включать использование действий или рабочих процессов через выбранный ивент-топик. Чтобы создать новую подписку, в «Extensibility» заходим в «Subscriptions» и кликаем на «+New Subscriptions»:

В «Subscriptions» если кликнуть на значок «+», откроется список ивент-топиков.

Важно! Только один ивент-топик может быть выбран в один момент времени.

Описание появляется только на экране действий и помогает различать действия в системе. По best practice рекомендуется использовать информативные описания на условиях и действиях, чтобы быстрее их различать при расширении сред.

Условия в подписках

Условия под каждую подписку, кстати, могут быть авторскими – они достаточно просто создаются с помощью выражений JavaScript (через доступные свойства). Их используют администраторы, чтобы фильтровать рабочие процессы vRO или запуски ABX-действий:

Пример условия: «blueprintID: ID» (ID блюпринта достается в браузере – нужно скопировать произвольные цифры после последнего «%2f» в URL. Например, если у нас «https://sa-vra-01.vclass.local/automation-ui/#/blueprint-ui;ash=%2Fblueprint%2Fedit%2F4e364a76-d3ba-4c6c-84c7-af28b5f6c278», ID блюпринта будет «4e364a76-d3ba-4c6c-84c7-af28b5f6c278»).

Можно создавать логическое выражение JavaScript-синтаксиса, используя объект события и его свойства. «event.data» помогает в доступе к полезным нагрузкам (данным) в соответствии с указанной схемой топика или любыми другими свойствами ивент-топика, вроде:

sourceType

sourceIdentity

timestamp

eventType

eventTopicId

correlationType

correlationId

description

targetType

targetId

username

orgId

Добавление запускаемого объекта

Добавление запускаемого объекта помогает выбирать ABХ-действие или рабочий процесс из vRO. В выпадающем меню «Runnable type» можно определить либо то, либо другое:

Эта возможность дополнила базовое назначение выполняемой задачи: с ней администратор может создать задачу восстановления, чтобы отменить рабочие процессы или действия во время сбоя.

Только один запускаемый объект может быть назначен одной подписке. Но, вместе с тем, множество подписок могут быть определены для одного и того же блюпринта и события. Значение приоритетности показывает, который из объектов будет запускаться первым, если флажок на блокировании включен.

Заблокированные и незаблокированные подписки

Подписки информируют vRA, что нужно запустить рабочий процесс vRO, в том числе в случае параллельного запуска нескольких незаблокированных подписок. Блокировка же подписок инструктирует Event Broker запускать по одному рабочему процессу за раз:

Значение текстового поля «Priority» определяет порядок подписки, а «Timeout» – управляет тем, насколько по времени рабочий процесс ставится на паузы для блокировки события подписки.

Вообще же, система заблокированных и незаблокированных подписок очень полезна в мониторинге и контроле над рабочими процессами. Рекомендуется каждую новую подписку назначать как заблокированную, чтобы контролировать порядок запуска рабочих процессов. Ибо незаблокированные подписки могут запускаться рандомно, при этом провоцируя неожиданные результаты.

Расширение функционала vRA и vRO путем взаимодействия с внешними системами и доставкой XaaS

Доставка XaaS может подарить нашим продуктам множество полезных сервисов. К примеру, создание пользователей AD, мигрирование ВМ, организацию таблицы в БД SQL, открытие тикетов во внешних системах, вроде ServiceNow, заказ чего угодно и где угодно. И vRO в этом плане умеет работать с AMQP, HTTP-REST, JDBC, SMTP, Active Directory, PowerShell, SNMP, SOAP, SQL, SSH, vCenter Server и XML.

Настраиваемые ресурсы

Настраиваемые ресурсы представляют собой ссылку на рабочий процесс vRO, используемый в блюпринтах. Причем, после создания они могут перетаскиваться в нем точно так же, как любой другой объект, позволяя при этом запускать рабочие процессы vRO без подписки или топика событий. Настраиваемые ресурсы связаны с рабочими процессами vRO, поэтому нужно знать внешний тип, ассоциированный с рабочим процессом, и активировать их, чтобы они стали доступны для блюпринта. Причем, только настраиваемые ресурсы могут иметь привязку к внешним типам. Для настраиваемого ресурса можно определять любой ресурсный тип, однако он должен начинаться с «Custom.<variable>»:

Найти внешний тип можно, проверив переменные ввода/вывода в рабочем процессе vRO. Все рабочие процессы (создания, апдейта или уничтожения) должны обладать одинаковыми переменными с одинаковым внешним типом. Обычно, переменная, которую мы вводим, выгружается из рабочего процесса создания и применяется как ввод в апдейте и уничтожении.

Перед тем, как приступить к созданию настраиваемого ресурса, нужно проверить, привязан ли рабочий процесс vRO к «Create» и «Destroy» («Update» – опционален):

Дополнительными действиями являются другие рабочие процессы, используемые как связанные с настраиваемым ресурсом Day-2-операции. Идентифицированный в «Create» рабочий процесс vRO вызывается при предоставлении настраиваемого ресурса как части блюпринта. При удалении развертывания, вызывается рабочий процесс, идентифицированный как «Destroy».

Вводы и выводы рабочего процесса vRO импортируются настраиваемым ресурсом и конвертируются в пользовательскую ресурсную схему vRA. Объекты схемы в настраиваемом ресурсе совпадают с переменными ввода и вывода в vRO, и их нужно определить в YAML-коде блюпринта, за исключением переменных «GENERATED_ schema»:

Чтобы использовать настраиваемый ресурс в блюпринте нам нужно обновить список ресурсных типов на левой панели, перетащить наше действие с ресурсом на канву и добавить вводы в ресурсное действие:

Свойства в коде YAML будут отвечать элементам схемы и переменным ввода в рабочем процессе vRO. Соответствующее свойство по каждому объекту схемы нуждается в определении.

С настраиваемыми ресурсами доступны и дополнительные действия (их можно рассматривать в качестве Day-2-операций), хоть они и опциональны. Эти действия не привязаны к схемам, используемым в рабочих процессах создания, апдейта и уничтожения, и их может быть сколько угодно:

Для работы с ними нужно открыть развертывание и кликнуть на объект настраиваемого ресурса в блюпринте, а затем – на выпадающее меню «ACTIONS» на правой панели, чтобы выбрать необходимое действие:

А в целом, ресурсные действия позволяют добавлять пользовательские Day-2-операции к развернутым ресурсам. Например, строить эти действия из рабочих процессов vRO, указывать ресурсный тип по каждому работающему действию, включать условие «osType = Linux», добавлять пользовательские формы. Но, следует помнить, что действия с ресурсами требуют действие vRO для указания привязки свойства:

А создаются ресурсные действия на вкладке «Design»:

Чтобы указать привязку свойства, можно вызвать действие vRO:

На этом скриншоте проиллюстрировано, что ресурсные действия должны каким-то образом идентифицировать объект для vRO с целью запуска рабочего процесса над ВМ, хранимой в vRA «${properties.resourceName}» пользовательском свойстве. При этом имя ВМ передается из vRA в рабочий процесс vRO с помощью привязки свойств, а сама привязка является действием из действий vRO.

В Day-2-операциях ресурсные действия, как мы уже заметили, находят свое широкое применение. Чтобы их использовать в этом качестве нам нужно открыть разворот, кликнуть на объект, по которому хотим запустить это действие, и далее – на выпадающее меню «ACTIONS», из которого выбираем подходящее действие:

Многие объекты, например, «Cloud.vSphere.Machine» уже имеют определенные дефолтные ресурсные действия («Add Disk», «Connect to Remote Console», «Create Snapshot», «Power On», «Power Off», «Reboot» и т.д.). И, конечно же, если нужное вам действие уже есть в списке, создавать его специально нет необходимости.

Использование рабочих процессов vRO как источников контента

В Service Broker источник контента может вызывать любой рабочий процесс vRO. Чтобы этого добиться, нам необходимо зайти в Service Broker и кликнуть на «New» в «Content & Policies», после чего выбрать «vRealize Orchestrator Workflow»:

Причем ассоциация с любым разворотом при этом не нужна (в отличие от ресурсного действия).

Слежение за историей событий (секция «Activity» левой панели)

Каждый раз при запуске действия или рабочего процесса, сохраняется история на странице «Action Runs» или «Workflow Runs», соответственно. Благодаря этому администратор может отслеживать производительность и результаты в истории запусков или в истории разворотов:

Здесь вверху доступна удобная фильтрация для сужения техник поиска.

Спектр расширенных действий с блюпринтами

Выше мы рассматривали самые простые, обычные – можно сказать, базовые блюпринты для элементарных задач. Настало время глубже погрузиться в знакомство с ними и узнать, какими интересными их можно сделать с нашей легкой руки и каков будет их расширенный функционал при этом.

Добавление пользовательских вводов к блюпринту

Чтобы добавить значение к блюпринту прямо во время запроса, следует назначить переменную в YAML-коде в секции ввода:

Кастомизированные вводы могут назначаться либо в существующих свойствах, либо в новых пользовательских свойствах в рабочих процессах или действиях. Первая строка здесь – это имя свойства (в нашем примере – «numHosts»). Форматирование YAML – два пробела для каждого абзаца.

При заполнении в больших блоках значений следует удалить «{}» из вводов: скобки используются только для единичных строк свойств. Типы переменных ввода наследуют форматирование JavaScript и примеры включают численные и логические значения, а также строки и массивы. Свойства под именем создаваемых переменных имеют привязку к персональному свойству и могут быть составными, например: «minimum: and maximum:».

inputs:

NameOfProperty:

type: (тип переменной – «javascript»)

title: (информативное имя поля, которое будет показано в блюпринте)

default: value (значение начального свойства, показываемое в форме)

encrypted: true (шифрует значение для безопасности)

Пользовательские свойства необходимы для передачи информации на рабочие процессы и действия. Свойство передается между блюпринтом и полезной нагрузкой через YAML-код в блюпринте. Базовое назначение переменной:

variable_name: ${input.input_field_Name}

По завершению, полезная нагрузка включит имя назначенной в отсылке информации к рабочему процессу или действию переменной. Учтите, что переменные ввода не передаются на полезную нагрузку, чтобы посылать к рабочим процессам или действиям. Пример:

hostnameToChange: ${input.Hostname2}

«Hostname2» здесь – это поле ввода, определенное в секции ввода. А полезная нагрузка содержит, в результате, «hostnameToChange», но не «Hostname2».

Свойства доступа в vRealize Orchestrator

Свойства в vRealize Orchestrator передаются через специализированный JSON-массив свойств. Чтобы получить доступ к переданным свойствам, нужно создать свойство «inputProperties» типа «Properties»:

inputProperties идут через JSON-файл. Чтобы достучаться до конкретных свойств, можно его прочитать и назначить свойства к переменным такими строками кода:

  1. Создаем массив строчных файлов:

var jsontxt = JSON.stringify(inputProperties, null, 2); #

  1. Парсим все данные вывода в список свойств:

var json = JSON.parse(jsontxt); #

  1. Назначаем указанные свойства переменной:

variable = json.propertyName; #

Для нестрочных переменных используем такой же тип переменной, чтобы назначить указанную переменную.

Предоставление вводов полезной нагрузке

При развороте машины назначенное в блюпринте YAML свойство аналогичным образом включается в полезную нагрузку. Чтобы получить доступ к свойству из YAML-файла, используем такой код:

action_variable = inputs [“customProperties”] [“blueprint_property”]

YAML-кодинг для расширенных блюпринтов

YAML дифирамбы с самого начала нашего разговора мы пели неоднократно – это действительно удивительно гибкий и простой язык, позволяющий нам быстро конфигурировать и управлять IaC. В нашем блоге ранее в библиотечной секции шпаргалок мы публиковали учебник по нему – предельно лаконичный и элементарный для понимания мануальчик, объясняющий синтаксис этого языка и его возможности. Сегодня же мы будем учиться применять его на практике для множества задач vRA. В частности, рассмотрим, чем YAML способен помочь, когда нам хочется усложнить наши блюпринты, расширить их функционал. И начнем с фундамента в виде специфической части синтаксиса, касающейся конкретно наших пользовательских вводов.

Как мы уже отмечали, пользовательские вводы позволяют нам выбирать опции из списка выбора (строчный тип c объектами, очерченными в «enum»), определенного в YAML, с переменными, в назначении которых нами указано пользовательское имя, и использующимися где-угодно в коде. Переменная всегда начинается с «’${input.», а оканчивается (после вписывания имени) – «}’». Пример:

‘${input.SelectFlavor}’

Как только переменная ввода будет определена, она появится в секции «inputs».

Форматирование текста в блюпринте YAML

Чтобы создать дружественный к пользователю ввод в списке выбора, рекомендуется соединить текст или же поменять регистр символов. Например, нужно предоставить пользователю выбор между несколькими облачными платформами. YAML в вводе, в этом случае, хорошо чтобы добавил перед соответствующим местом в коде слово «cloud:» и переключил весь ввод на маленькие буквы:

Такой консолидированный текст предоставит точное имя для тэга, ранее созданного в vRA, и включает «‘${”cloud:”””». Эта часть текста обладает одинарной кавычкой, «${cloud», двоеточием, двумя двойными кавычками и еще одной одинарной. (О значении двоеточия в YAML можно почитать в упомянутом выше учебнике). Чтобы использовать двоеточие в строке, за ним должны обязательно следовать две двойные кавычки. Что же касается самих двойных кавычек, они работают, словно, символ «escape».

Оценка выражений в блюпринте YAML и другие полезные выражения

Опираясь на оценку выражения можно устанавливать значения. Например, нам нужно оценить значение переменной ввода «SelectCloud»:

Символ «==» эквивалентен «равно Х» и тестирует значение переменной, чтобы понять, равняется ли оно тому, что за ней следует. На скриншоте выше, если «SelectCloud» равно «<some_value>», тогда «<perform_some_action>». Символ «?» – это условие «Then» в выражениях «If/Then/Else». У нас: если «SelectCloud» равняется «vSphere», то свойство «folderName» устанавливается на значение «Production_VMs». Если же нет, то это свойство становится пустым.

Другими полезными выражениями при создании YAML-кода блюпринта могут быть:

!= (не равно чему-либо),

&& (и),

|| (или),

! (не),

<

>

<=

>=

– последние четыре имеют классическое общепринятое значение.

Выражения с условием всегда строятся по шаблону:

conditional-expression ? true-answer : false-answer

Разворот с условием в YAML-блюпринте

Чтобы развернуть объект только при специфических установленных значениях, можно использовать схемы, типа:

Здесь, код оценивает значение переменной ввода «SelectFlavor», и если оно установлено на «VMW-Small», возможно следующее:

  • Только одна ВМ развернется («count» для «Machine» установлен на «1»);
  • Балансировщик нагрузки не развернется («count» для него установлен на «0»).

Если же «SelectFlavor» не равняется «VMW-Small»:

  • Развернутся две ВМ ((«count» для «Machine» установлен на «2»);
  • Развернется балансировщик нагрузки («count» для него установлен на «1»).

Кастомизация блюпринтов с cloudConfig и cloud-init

Кастомизация блюпринтов под разворот в любом облаке – вещь чрезвычайно полезная и интересная. Мы можем использовать cloudConfig (в комбинации с YAML) и cloud-init, чтобы создать единственный блюпринт, который сможет развертываться и запускаться на не важно каких типах облаков.

VMware cloudConfig – это YAML-код блюпринтов, инструктирующий cloud-init (набор Python-скриптов, инициализирующий облачные инстансы машин Linux) через CD-ROM привод на шаблоне ВМ, а cloud-init, в свою очередь, представляет собой стандартизированный пакет промышленного ПО, работающий с кастомизацией. По дефолту cloud-init доступен в Ubuntu 18 и Photon 3 (и выше, но для более ранних версий, а также всего CentOS его надо устанавливать специально), он скриптует настройку SSH-ключей и запускает команды на кастомизацию машины без участия пользователя. Эквивалент для Windows – CloudBase-Init. Ответы от cloud-init записываются в файл «/var/log/cloud-init-output.log» после разворота ВМ.

Больше почитать о cloud-init можно здесь.

Чтобы создать шаблон в vSphere, поддерживающий предварительно проинсталлированный cloud-init (используется «yum» в CentOS и «apt-get» – в Ubuntu), нужно вначале убедиться, что на ВМ установлен CD-ROM:

После чего можно завершать свою настройку при помощи команды «cloud-init clean». Учтите, что теперь модифицировать шаблон ВМ запрещено – она просто уйдет в даун и переконвертится в шаблон.

Важно! Для cloudConfig справедливы следующие ограничения и запреты:
  • Разворачиваемая ВМ должна иметь DHCP IP-адресацию. Статические адреса не дозволены;
  • Нельзя комбинировать кастомизированную спецификацию vSphere с YAML-блюпринтом, использующим cloudConfig.

Если понятно, что с внедренными скриптами cloudConfig что-то не так, в траблшутинге проблем помогут его разнообразные логи на разворачиваемой машине, которые записываются в:

/var/log/cloud-init-output.log – файл логов вывода,

/var/log/cloud-init.log – главный файл логов,

/var/lib/cloud/instance/scripts – основная директория скриптов cloudConfig,

/var/lib/cloud/instance/user-data.txt – главный скрипт cloudConfig,

/var/lib/cloud/instance/scripts/runcmd – файл скрипта runcmd.

Также проверить актуальные команды, посланные vRA на cloudConfig, можно следующим образом:

  1. Открываем «Deployment» в UI vRA;
  2. Заходим на вкладку «History»;
  3. Кликаем на «Provisioning Diagram»;
  4. Слайдером включаем режим «Dev mode»;
  5. Нажимаем на иконку «Cloud» слева от этого режима;
  6. Кликаем на «Save», чтобы сохранить файл в формате JSON (далее используем Notepad++ с проинсталлированным плагином JSON, чтобы ознакомиться с его содержимым);
  7. Ищем в сохраненном файле блок с «cloudConfig»:

Поучимся форматировать cloudConfig – причем, делать это нужно весьма осторожно по множеству причин. Для начала, о синтаксисе, ведь это снова наш YAML, хоть и несколько специфичный. Директивы cloudConfig начинаются с маленькой «с», а в середине имеют большую «С». Секции должны выстроиться под частью с свойствами машины (образ, особенности, сети и т.п.):

Символ «|» должен стоять после директивы – все команды за ним будут посланы на пакет cloud-init после разворота шаблона и запускаются они только при первой загрузке. Во многих примерах строка после «cloudConfig: |» начинается с «#cloud-config» (хотя это вовсе и необязательно) – тот самый формат записи комментариев, с которым мы сталкивались, когда штудировали учебник по YAML. Также символ «|» должен вводиться после добавления двух пробелов за двоеточием. Кроме того, строка за этим началом (с директивами к users, runcmd, hostname) должна предваряться двумя пробелами. После этих директив следующая строка также должна начинаться с двух пробелов, а после них – дефис и еще один пробел.

Полный список команд в cloudConfig:

users:

hostname:

runcmd:

packages:

Важно! Далеко не все ОС поддерживают функции cloud-init.
Настройка DNS Hostname ВМ после развертывания

Чтобы поменять DNS-имя хоста после развертывания можно использовать либо линукс-команду «hostnamectl» (только в Linux-ОС), либо директиву cloudConfig «hostname:»:

Создание пользователей в ВМ после развертывания

Чтобы создать локальных пользователей в ВМ, можно применить директиву «users», указав имя пользователя, сконфигурировав sudo, добавив его к группам и указав оболочку:

Показанная здесь конфигурационная sudo-команда создает файл «/etc/sudoers.d/dont-prompt-<Your_Username>-for-sudo-password» (у этого пользователя не запрашивается пароль при запуске команды sudo). А «groups:» – создает группу.

Важно! Установить пароль пользователя в директиве «users:» нельзя. Однако это можно сделать с «runcmd:» – уже после того, как пользователь будет создан.
Запуск команд

Директива «runcmd:» позволяет запускать команды на ВМ после развертывания:

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

Практически все команды, запускаемые в интерактивном режиме, запускаются по «runcmd:». А редактор sed позволяет редактировать файлы. Учтите, что команды должны быть автономными – пользовательский ввод в «runcmd:» участвовать не может.

Инсталляция софта в ВМ после развертывания

За инсталляцию ПО отвечает директива «packages:» (аналог в Ubuntu – «apt-get», а в CentOS – «yum»). Чтобы ее использование стало возможным, следует проверить наличие доступа ВМ либо к локальному репозиторию, либо в интернет. Полезная рекомендация: включать директиву, апдейтящую репозитории в ВМ нужно перед вводом «packages:» («package_update»/«package_upgrade»):

Важно! Не во всех ОС доступны все пакеты. И, кстати, некоторые системы обладают по дефолту проинсталлированными определенными пакетами.
Важно! Имена пакетов под разные ОС должны быть различны.
cloudConfig в сопоставлении образов

В сопоставление образов мы можем добавлять команды cloudConfig, однако следует учесть, что вводить можно только этого типа команды (начало с «cloudConfig:»), т.к. команды образов не являются интерактивными (вводы не разрешены), а еще – команды сопоставления образов имеют приоритет перед блюпринтовскими (если есть конфликт):

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

Мультиоблачный разворот

Одновременное применение сразу нескольких облачных платформ – обыденная реальность современного продакшена. Блюпринты vRA в подобной ситуации становятся поистине неоценимыми помощниками, и сейчас мы поучимся, как их использовать в этом случае. Преимущества их расписывать не будем – все это многократно нами озвучивалось в предыдущих статьях из цикла по vRA.

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

О создании и применении тэгов было много написано выше в подразделе «Использование тэгов». Что же касается культуры их написания, рекомендовано придерживаться такой схемы:

Облако:Тип ресурса

vSphere:Тип облачной системы

Главный офис:Географическая локация

с оглядкой на актуальные нужды и принятую корпоративную политику. Кстати, когда в схеме речь идет о локации, очень помогает использование дефиса при ее уточнении. Например, «US-East».

Когда мы говорим о мульти-облачном развороте, на деле это означает, что нам нужно создать блюпринт с некими клауд-агностик компонентами – семантика которых не зависит от специфики того или иного облака.

Блюпринт с не зависящими от типа облака компонентами

Для подобных компонентов в левой секции объектов существует специальный блок, который так и называется – «Cloud Agnostic»:

Из него просто перетаскиваем нужный нам объект (машину, балансировщик нагрузки, сеть или том) на канву, а затем просто там их подключаем. Эти компоненты универсальны и для vSphere, и для AWS, для GCP, Azure и VMware Cloud на AWS.

Изменение блюпринта под использование мульти-облачной среды

В самом YAML-коде мы можем отразить наше желание использовать несколько разных облаков сразу. Для этого он соответствующим образом меняется, первоочередно реализовав ввод, который выбирает конкретную облачную платформу. Используется ограничение, чтобы сопоставить тэг с вычислительным ресурсом, опираясь на ввод. Далее нам помогают описанные выше коды YAML с условием – выбирающие образ, а также сетевой профиль, с учетом выбора облака, вводом:

Наравне с ними можно использовать и выражения с условиями, чтобы выбрать особенности («Flavor»).

Итеративный разворот и контроль версионности

На протяжении своего жизненного цикла один и тот же блюпринт может обрастать множеством версий, причем не факт, что, когда создается новая, старую можно окончательно отправлять в утиль. Вовсе нет! И vRA позволяет нам определять разницу между этими версиями, а также апдейтить существующие развороты, с учетом сделанных в блюпринте изменений, благодаря чему нам вовсе не нужно каждый раз делать все по-новой.

Управление версиями блюпринта

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

Безусловно, чтобы потом играючи все это проделывать, в том числе, и откатываться до более ранних вариантов, нам нужно, прежде всего, создать версию блюпринта. Для этого:

  1. В редакторе кликаем на «Version»;
  2. Вводим описание главной причины изменений в текстовом поле «Description»;
  3. Вводим детализированный список изменений в «ChangeLog»;
  4. Ставим галочку в «Release», чтобы издать эту версию в сервисном каталоге (здесь пользователь информируется о том, ограничено ли применение этого блюпринта конкретным проектом, либо же он доступен для всех);
  5. Нажимаем на «Create»:

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

Изучение различий между несколькими версиями – краеугольный камень понимания того, что происходит в нашей системе, если их – версий – у нас более одной. В этом помогает специальная вкладка нашего конструктора – «Version History»:

после нажатия на которую появляется трех-панельная версия нашего редактора блюпринтов. Здесь можно мгновенно создать версию существующего блюпринта, либо же клонировать текущий, восстанавливать до старого варианта, выпускать тот или иной, либо же аннулировать его публикацию. Левая панель – навигационная, позволяющая перемещаться между версиями, выбирая любую. Самая недавняя будет помечена галочкой справа, а та, которую смотрим как раз сейчас – синим кружочком слева от ее описания. Навигационную панель можно скрыть, кликнув на «<<» в верхнем правом углу – чтобы было больше места для канвы дизайна и редактора кода:

Доступна удобная опция сравнения канвы дизайна разных версий блюпринта: если выбрать вкладку «Diff» вверху канвы:

(первая же вкладка «View» показывает обычный дефолтный вид канвы). При этом правая часть с YAML-кодом замещается отчетом о разнице. Чтобы это увидеть, нам нужно выбрать версю для сравнения с текущей выбранной:

(центральная панель будет занята текущей, а правая – той, которую с ней сравниваем).

Если здесь нажать на «Diff Visually», покажутся графические исполнения этих двух дизайнов разных версий рядом. А «Diff Code» позволит снова переключиться на представление в коде. Если коды большие, их для удобства можно скроллить. Все, что отличается в этих двух версиях, будет подсвечено разными цветами. Кроме того, на центральной панели выбранного текущего блюпринта будут доступны иконки зеленого, красного и желтого цвета, которые отражают кол-во добавленных, удаленных нод и измененных свойств, соответственно.

Чтобы проапдейтить после изменений существующий разворот, нам нужно кликнуть на блюпринте на «Deploy», а из выпадающего меню «Deployment Type» выбрать «Update an existing deployment»:

Здесь, кстати, можно выбрать версию блюпринта к использованию, а также удобно искать нужный с помощью фильтрации.

Важно! В один момент времени можно обновить только один блюпринт.

Интеграция vRA с публичными облаками

Поистине замечательно, что в vRA встроена нативная поддержка публичных облачных аккаунтов, а именно: AWS, Microsoft Azure, GCP и VMware Cloud на AWS:

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

AWS

Для начала нам, конечно же, потребуется завести облачный аккаунт AWS, предварительно узнав ID ключа доступа и сам секретный ключ (20 знаков буквы+цифры для ID и сам ключ, вида, например «wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY»). Чтобы его создать, нам необходимо в консоли AWS под правами «power user» (чтение+запись), зайти на «Identity and Access Management (IAM)» – «Users» «Security Credentials» и кликнуть на «Create access key»:

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

Важно! Хорошей практикой по безопасности считается регулярно менять или делать регламентированную ротацию ключей доступа пользователя IAM.

Сам же облачный аккаунт создается по тому же принципу, что мы описывали выше (заходим в консоль vRA под администратором Cloud Assembly, выбираем в качестве типа облачного аккаунта «Amazon Web Services», вводим все по ключу, собранное, как показано выше, и вписываем имя нашего будущего аккаунта, а также его описание). Обязательно проверяем адекватность введенного кнопочкой «Validate», после чего выбираем подходящие регионы сервиса, чтобы развернуть все, что требуется, и соглашаемся с созданием кнопкой «Add»:

Процесс сбора данных ресурсов (образов, особенностей, машин, сетей, объектов безопасности и томов) AWS стартует сразу же.

Блюпринт с AWS

В редакторе блюпринтов в левой секции объектов раскрываем блок «AWS» и выбираем оттуда нужные объекты, перетаскиваем их в канву, чтобы использовать в vRA:

Например, на этом скриншоте показано, как туда выведены инстанс Amazon и облачная сеть. Больше о возможностях AWS-сервисов можно здесь.

Microsoft Azure

После упомянутой выше в предисловии к этому разделу подготовки нам, как и для AWS, понадобится собрать некоторую важную информацию, вроде ID подписки и тенанта, клиентского приложения, а также секретного ключа к нему:

Приложение AD создается, как описано здесь.

Чтобы создать облачный аккаунт, точно также под правами администратора Cloud Assembly заходим в консоль vRA и выбираем тип облачного аккаунта в создании нового как «Microsoft Azure», после чего заполняем форму:

с ID подписки, тенанта, клиентского приложения и с секретным ключом клиентского приложения, а также вводим имя и описание. Проверяем валидность введенного кнопкой «Validate», и тогда появится опция выбора регионов Microsoft Azure, где и будут разворачиваться запрошенные vRA сервисы. Управлять этими регионами можно с помощью облачных зон и проектов.

С этим типом публичного облака сбор данных по ресурсам стартует, аналогично, сразу же после создания облачного аккаунта.

Блюпринт с Microsoft Azure

Чтобы использовать объекты Microsoft Azure в vRA, в левой части редактора блюпринта раскрываем список «Microsoft Azure» и перетаскиваем объекты оттуда на канву:

На скриншоте, к примеру, мы использовали инстанс Microsoft Azure и облачную сеть. А больше узнать о сервисах Microsoft Azure можно на сайте вендора.

Google Cloud Platform

Чтобы интегрировать GCP в vRA, нам тоже нужны всякие данные о соответствующем аккаунте: ID проекта (это можно подсмотреть прямо на панели консоли GCP) и приватного ключа, сам приватный ключ и email клиента. Для создания приватного ключа делаем следующее:

  1. Заходим в консоль GCP под правами собственника организации;
  2. Проходим в «IAM & admin» – «Service accounts» и редактируем наш сервисный аккаунт;
  3. Кликаем на «+Create Key»:

Загрузится JSON-файл, в котором будут выведены все необходимые нам данные. Рекомендуется хранить этот файл бережно, так как потерянный ключ восстановлению не подлежит – придется делать все по-новой.

Облачный аккаунт GCP в vRA создается аналогично элементарно – по описанной выше дважды (AWS и Microsoft Azure) схеме, только выбираем уже тип облачного аккаунта – «Google Cloud Platform» и вводим, как на скриншоте, все данные:

Естественно, проверяем все по «Validate», после чего появится список регионов, в котором ставим галочки на нужных. Кстати, именно для этого типа облака для автоматизации и упрощения процесса с нивелированием человеческого фактора при заполнении формы доступна функция «Import JSON Key» – информация в полях впишется сама.

Блюпринт GCP

Повторяться не будем – здесь все делается, как и для предыдущих вариантов публичных облаков. Единственное что, для поиска нужных объектов раскрываем список «GCP» в левой панели редактора:

VMware Cloud на AWS

VMware Cloud на AWS позволяет энтерпрайз-уровня софт SDDC привносить в облако AWS со встроенной оптимизацией доступа к сервисам публички:

Гибридные облака, вообще, вещь очень интересная, комбинирующая все преимущества on-premise и публички. И чтобы начать с ними работать в vRA, нам всего лишь нужно завести этого типа облачный аккаунт, для чего понадобится т.н. API-токен. Его можно создать прямо в панели инструментов VMware Cloud Services, кликнув на имя пользователя и выбрав «My Account» – «API Tokens», введя название токена, указав диапазон его жизни и область применения:

После чего просто нажать на «Generate». Учтите, что после генерации, по соображениям безопасности, показываться будет только имя токена. Однако его переиспользование позволит без труда скопировать данные учетной записи из формы. К тому же его всегда можно сгенерировать снова.

Облачный аккаунт VMware Cloud на AWS создается там же, где и для описанных выше других типов облаков, но после ввода «VMC API token» нужно нажать на кнопку «Apply API Token», а затем выбираем соответствующий SDDC из выпадающего меню, вводим данные учетной записи для него и кликаем на «Validate»:

Удобно, что по выбранному нами SDDC система сама заполнит IP-адреса vCenter Server и NSX Manager. И единственное, что нам останется, это выбрать имя для нашего нового облачного аккаунта, дать его описание, после чего просто нажать на «Add».

Интеграция vRA с NSX-T Data Center

NSX-T Data Center лишний раз расхваливать, думается, не стоит. Равно, как и объяснять архитектуру, специфику работы и возможности данного продукта. Обо всем этом подробнейшим образом написано в целом посвященном ему цикле статей, ознакомиться с которым можно здесь. Сейчас же мы будем учиться интегрировать NSX-T в vRA, грамотно управлять сетевыми профилями и использовать его компоненты в дизайне мульти-тирового блюпринта. А также, конечно, узнаем о сетевых опциях и функциях безопасности, применяемых в канве редактора.

Вообще же, разумеется, интеграция NSX-T Data Center с vRA начинается с создания соответствующего облачного аккаунта, для чего заходим в консоль vRA под правами администратора Cloud Assembly, кликаем на «Infrastructure» – «Connections» – «Cloud Accounts», а затем на «Add Cloud Account» – «NSX-T»:

Как уже упоминалось в статье «Разворот и базовая настройка VMware vRealize Automation 8.3», если у нас существует облачный аккаунт vCenter Server, мы всегда можем ассоциировать NSX-T Data Center с vCenter Server.

В секции «Resources», в «Networks» можно увидеть список обнаруженных из vSphere сетей, ассоциированных с облачными аккаунтами NSX-T Data Center:

Первая же вкладка этого раздела – «Networks» – покажет нам их атрибуты, вроде CIDR, дефолтного шлюза, DNS-серверов и прочего. Причем сеть можно назначить как дефолтную для какой-то зоны (ставится галочка в пункт «Default for zone» – см. иллюстрацию ниже), а также включить поддержку публичных IP для работы с внешней сетью.

Важно! Дефолтные сети имеют предпочтение перед прочими при развороте блюпринтов.

Использование публичных сетей

Хорошей практикой считается настройка одной из порт-групп vSphere или NSX-T Data Center как публичной – чтобы она позволяла внешний доступ:

Делается это, как на приведенном скриншоте, простановкой галочки по пункту «Support Public IP» – потом будем использовать эту сеть, когда некоторые сетевые профили потребуют внешний доступ.

Сетевые профили

Сетевые профили контролируют решения по размещению, выбирая сеть при предоставлении ВМ (настройка сетевых интерфейсов виртуалок). Также они задают уровень изоляции для развернутой рабочей нагрузки, указывают конфигурацию устройств NSX Edge, создаваемую при предоставлении множества машин. В vRA сетевые профили используют дефолтный IP Address Management (IPAM) и находят свое широкое применение в блюпринтах, в том числе, если IPAM предоставляется сторонними вендорами, например, Infoblox.

Примечание. Про IPAM можно рассказывать очень долго – тема эта непростая, но весьма интересная. Здесь все, его касающееся, приводить не будем – никакого объема гайда на это не хватит. Если заинтересовала технология конкретно в приложении к VMware Cloud Assembly – вот ссылочка на замечательную книжку, ей посвященную. Если будут проблемы с ее пониманием на английском языке, пишите нам, постараемся найти время в графике и опубликовать ее перевод.

Сетевые профили в vRA применяются нескольких типов:

  • маршрутизированные («routed»),
  • публичные («public»),
  • приватные («private»),
  • исходящие («outbound»),
  • существующие («existing»):

Создавать их можно на вкладке «Infrastructure», а в самих блюпринтах они участвуют, когда используется свойство «networkType». При настройке сетевого профиля для IPAM, предоставляемые машины могут получать данные об IP-адресе и сопутствующую информацию, вроде DNS и шлюза, из настроенного IPAM-решения.

Поговорим немного об известных типах сетевых профилей.

Сетевые профили типа Existing

Существующие обнаруженные сети используются в развороте блюпринтов. Чтобы создать их соответствующий профиль, нам нужно пройти в «Infrastructure» – «Configure» – «Network Profiles», кликнуть на «New Network Profile», а затем добавить существующую порт-группу vSphere или логический свитч NSX-T Data Center:

Обратите внимание: именно для этого типа профиля мы поставили флажок в «Do not create on-demand network or on-demand security group». Это важно.

И, кстати, сеть, которая добавляется на вкладке «Network» может и не быть публичной.

Сетевые профили типа Private

Удобны при предоставлении изолированных от внешнего доступа ВМ. И организовываться приватные сетевые профили могут как через создание сети по требованию (в NSX-T, созданы DHCP-сервер и пул, но не развернут Т-1-маршрутизатор, а группы безопасности не созданы), так и через создание группы безопасности по требованию. В первом случае, учтите, что в карточке профиля нам нельзя указывать никакой сети, в т. ч. и внешней, маршрутизатор Т-0 или кластер Еdge. Если идем через группу безопасности, определяем обнаруженную или развернутую NSX-T Data Center на вкладке «Network» существующую сеть. Группа безопасности по требованию создается с тремя ассоциированными правилами файервола, включающими отклоняющие входящую и исходящую связь (1 и 2 правила), а третье отвечает за разрешение связи между ВМ – членами этой группы безопасности:

Важно! При создании приватного сетевого профиля через организацию группы безопасности нельзя учитывать сети vSphere.

Сетевые профили типа Outbound

Исходящие сетевые профили – это сети по требованию, создаваемые в процессе предоставления. Такие профили определяют внутренние и внешние сети, использующие таблицу трансляции для взаимной коммуникации. Они полезны при использовании перекрывающихся IP-адресов по всем сетям, нуждающимися во внешнем подключении. И если мы разворачиваем, к примеру, одну ВМ с исходящим сетевым профилем, у нас создастся по одному логическому свитчу, DHCP-серверу, Т1-маршрутизатору, осуществится подключение Т1-маршрутизатора к Т0-маршрутизатору и появится правила SNAT типа «one-to-many».

Важно! NSX маршруты не объявляются.

Диапазон сетевых адресов используется при предоставлении или создании изолированных подсетей. CIDR-адрес должен при этом быть достаточно большим, к примеру, 192.168.0.0/16, чтобы создать несколько изолированных подсетей при развороте. Размер подсети – это размер сети по требованию, которая создается под каждую изолированную сеть в использующем подобный профиль развертывании. Правило «one-to-many» здесь очень важно, так как говорит, что один внешний айпишник расшаривается между всеми машинами в сети. Внутренние же машины используют либо статический IP, либо DHCP, и каждая из них имеет доступ к внешней сети, однако обратный трафик не позволен.

Сетевые профили типа Routed

Маршрутизируемые сетевые профили являются сетями по требованию, создаваемыми в процессе предоставления. Они должны использовать маршрутизируемый шлюз для доступа к внешним сетям. По факту, конфигурация сетевого профиля типа Routed аналогична Outbound, но следует поменять в «networkType» на «routed», чтобы разворачивались маршрутизируемые сети:

Очень удобная конструкция, если нужно организовать маршрутизируемый доступ «end-to-end» с уникальными IP-адресами. С ней разворот одной ВМ даст следующее: создание по одному логическому свитчу, DHCP-серверу и Т1-маршрутизатору, подключение Т1-маршрутизатора к Т0-маршрутизатору и объявление NSX-маршрутов.

При этом NAT-правила не создаются вообще и ВМ может легко коммуницировать с внешней сетью. Однако и из внешней сети к ней добраться проще простого.

Интеграция с Infoblox

Интеграцию со сторонними IPAM-провайдерами рассмотрим на примере Infoblox. Infoblox DDI предлагает фреймворк для ключевых сетевых сервисов, вроде DNS, DHCP и IPAM, безопасных и простых в управлении. Чтобы начать с ним работу, нам нужно скачать vNIOS OVA отсюда, развернуть этот OVA в инфраструктуре vSphere, включить Appliance vNIOS, зайти в него с «https://<fqdn_vnios>/» и настроить упомянутые сервисы. NIOS – это операционная система, отвечающая за ключевые сервисы продукта и операционную беспрерывность сетевой инфраструктуры. Детальный мануал по развороту и настройке всего этого можно найти здесь.

Интеграция Infoblox в vRA после этого и скачивания его плагина (из VMware Solution Exchange по ссылке) происходит так:

  1. Проходим в «Infrastructure» – «Connections» – «Integrations»;
  2. Нажимаем на «+ ADD INTEGRATION» – «IPAM»;
  3. Кликаем на «MANAGE IPAM PROVIDERS», а затем – на «IMPORT PROVIDER PACKAGE», чтобы импортировать соответствующий плагин:

  1. Указываем имя хоста и данные учетной записи для Appliance vNIOS и назначаем дополнительные параметры, если необходимо:

В запуске среды под Infoblox в vRA используется ABX, а его плагин написан, для справки, на Python. WAPI Infoblox обладает схемой версионности, независящей от версии vNIOS. Обсуждаемая интеграция работает с WAPI v2.7, которую поддерживают любые Appliance Infoblox. Упомянутая среда служит коммуникационным механизмом между vRA и данной системой IPAM.

Плагин Infoblox посылает запросы в точно определенном формате на запущенную среду и просит ее выполнить определенные IPAM-операции, например, выделения IP для ВМ или получения списка IP-диапазонов. Для всего этого нам понадобится запустить в среде соответствующий скрипт или рабочий процесс. Такой блюпринт из vRA должен выполнять два ABX-действия:

  • Запустить ABX-действие «Allocate IP Range» (создаст сеть в vRA и vCenter Server);
  • Запустить ABX-действие «Allocate IP Address» (следующий доступный IP-адрес выделится ВМ).

В Infoblox создаются два типа сетей: IP Range (для существующих сетей vRA) и IP Block (для сетей vRA по требованию):

С первым типом можно, опционально, вручную указать область для DHCP, DNS-сервера, маршрутизаторы, VLAN и Broadcast-адрес. Если же выбрать «Add Network Container», он будет держать сети, созданные разворотами vRA, и когда сети по требованию будут разворачиваться из vRA, станут выделяться из контейнера подсетей меньшие блоки пространства IP. Второй вариант считается более приятным, так как все происходит только по требованию, и можно выбирать политику изоляции, указывать сетевые ресурсы, выбрав External Infoblox Plugin как источник. Но, важно учесть, что опция изменения назначения IP-диапазона будет недоступной и нужно указывать статический тип назначения в блюпринте:

Важно! При использовании внешнего IPAM, опция применения внутреннего IPAM vRA недоступна для существующих сетей.

А заполняется карточка сетевого профиля при этом, примерно, вот так:

Группы безопасности в vRA

Существующие группы безопасности могут быть ассоциированы с ВМ либо через сетевой профиль, либо прямо в канве блюпринта. В первом случае нам нужно назначить общую группу безопасности, чтобы установить эталон минимального уровня безопасности, а все машины впоследствии должны разворачиваться с использованием этого сетевого профиля и являться членами группы безопасности. Работать с блюпринтами гораздо проще: можно использовать более конкретизированные группы безопасности, специфические для той или иной зоны ответственности, но при этом придется каждую ВМ назначать своей персональной группе безопасности:

Просмотр всех обнаруженных групп безопасности доступен в «Infrastructure» – «Resources» – «Security». Там же можно добавлять несколько групп безопасности к одному сетевому профилю, кликнув на «+Add Security Group».

Балансировщики нагрузки в vRA

Пользоваться балансировкой нагрузки в vRA можно добавив существующий балансировщик к сетевому профилю, либо же развернув балансировщик нагрузки по требованию из блюпринта:

Список всех обнаруженных в системе балансировщиков нагрузки можно увидеть в «Infrastructure» – «Resources» – «Networks» – «Load Balancers». Можно добавлять универсальный для любого облака LB или балансировщик NSX прямо на канве дизайна.

Важно! Разница между не зависящим от облака балансировщиком нагрузки и NSX LB в том, что второй поддерживает не только TCP, но и UDP.

Блюпринт с конструкциями сети и безопасностью

В левой части редактора, в числе объектов, можно выбирать доступные сети и компоненты безопасности, чтобы нарисовать любой сложности блюпринт:

Как мы видим, сетевые конструкты встречаются сразу в двух секциях меню – относящиеся к cloud-agnostic и к NSX. И, выбирая определенный вариант, стоит учесть, что помимо вышесказанного, независящие от облака LB не поддерживают маршрутизируемые сетевые профили.

Интеграция Kubernetes в vRA

С помощью vRA администратор может мониторить и получать видение нескольких кластеров Kubernetes одновременно. Каждый кластер появляется как свой собственный кластер Kubernetes и предоставляет обзор системы. Использование VMware Enterprise PKS, помимо этого, позволяет разворачивать по требованию кластера Kubernetes прямо из vRA, где создаются еще и пространства имен.

Kubernetes может быть аутентифицирован и в Code Stream, и в vRA либо по имени и паролю, либо по несущему токену, либо по пользовательскому сертификату. Каждый из перечисленных типов назначается роли в кластере Kubernetes через Role-Based Access Control. Без этого назначения роли он не может использовать системную информацию аккаунта:

Чтобы пользоваться всеми преимуществами VMware Enterprise PKS, нужно, кроме добавления кластера, вначале интегрировать эту возможность, пройдя на вкладку «Infrastructure», кликнув на «Connections» – «Integrations», а затем – на «+ ADD INTEGRATION», и выбрав «VMware Enterprise PKS», как показано на скриншоте:

После можно создавать встроенные кластеры прямо в vCenter Server. Эти новые кластера строятся через редактор блюпринтов и подключаются с помощью интеграции с VMware Enterprise PKS:

Пример рабочего процесса с контейнерами:

  • Строим образ из исходного кода и зависимостей;
  • Посылаем образ на реестр образов;
  • Берем образ из реестра образов;
  • Запускаем образ как контейнер:

Благодаря ему девелоперам нужно написать код лишь однажды, а работать он будет по множеству разнообразных сред. В Dockerfile на приведенной схеме – имя базового образа ОС, требуемое контейнером. Это, по сути, ключевая спецификация, так как контейнер может разворачиваться только на хостах с ОС, которая соответствует хосту, указанному в Dockerfile.

Пример рабочего процесса с Kubernetes, в целом:

  • Строим образ из исходного кода и зависимостей;
  • Посылаем образ в реестр образов;
  • Инструктируем Kubernetes использовать образ для запуска пода;
  • Расписание назначает под ноде;
  • Kubelet принимает под;
  • Docker берет образ из реестра образов;
  • Docker запускает процесс контейнера внутри пода:

В результате наши контейнеры будут надежно защищены, создана коммуникация между подами, а весь код в образах запустится. Аналогичные схемы декларируют управление контейнером специфическими для Kubernetes требованиями с обязательной поддержкой отказоустойчивого и масштабируемого приложения при помощи рабочего kubelet. Контейнер точно так же управляется требованиями декларации в master-базе данных. Обладая этими сведениями, команды девелоперов и операторов работают совместно, разрабатывая эти требования и удовлетворяя нужды потребителей.

Code Stream в развороте контейнеров Kubernetes

Сейчас мы будем учиться применять Code Stream, добавляя в него конечную точку, настраивая репозиторий, строя базовый конвейер и разворачивая его. О самом Code Stream достаточное количество информации было приведено в предыдущей статье из этого цикла, поэтому лишний раз акцентировать внимание на его теории и возможностях, очевидно, не стоит. Лишь заметим, что он позволяет администратору интегрироваться в Docker или Kubernetes напрямую и разворачивать пользовательские конвейеры, созданные с целью настроить полный разворот из того же пользовательского интерфейса.

Мы, кстати, специально не выводили выше в «Распространенные операции» работу с Code Stream, так как хотели показать его функционал именно на примере интеграции Kubernetes и операций с ним связанных.

Предположим, мы использовали Guided Setup (как рассказано здесь), установив наш первый конвейер, чтобы выполнить разворот Kubernetes. Теперь нам нужно создать новую конечную точку (левое навигационное меню – под «Configure» – «Endpoints», где кликаем на «+ NEW ENDPOINT»), тип которой, как раз и будет Kubernetes:

Заводится он точно так же, как и все прочие, за исключением выбора «Kubernetes» в «Type». Единственное, что нужно проверить, правильно ли заведен проект (он берется из проектных данных vRA), имя назначено достаточно информативное и соответствующее корпоративной политике, но особое внимание следует уделить последнему пункту – «Authentication Type» (здесь выбирается имя пользователя/пароль, либо несущий токен, либо сертификат, после чего откроются соответствующие поля для заполнения).

Вообще нам необязательно добавлять центральный репозиторий образов для Kubernetes здесь. Однако его наличие упрощает контроль над множеством кластеров, ведь конвейер сможет вызывать указанные образа прямо из репозитория, чтобы поместить в Docker или Kubernetes. Доступны различные типы репозиториев – от YUM до GitHub (вводим URL), причем добавлять можно несколько сразу. Однако, учтите, что GitHub потребует ввода имени пользователя/пароля или сертификата, несущего токена для аутентификации:

Как альтернатива может использоваться внутренний репозиторий Kubernetes.

Базовые принципы построения конвейеров также рассматривались в упомянутом мануале. Теперь же, в качестве следующего шага, изучим их специфику в разрезе Kubernetes:

Прежде всего отметим, что в построении конвейеров первая вкладка «Workspace» позволяет называть конечные точки, локации построения образа и ограничивает CРU и память. Далее, вторая и четвертая вкладки («Input» и «Output», «Input» открывает текстовое окно ввода при запуске, выводы же могут определяться в YAML-файле и замещаются в процессе запуска) помогают собирать пользовательские данные в процессе запуска конвейера и вывода переменных в различные системы и задачи конвейера. Еще важно отметить, что в правой части рабочего окна Kubernetes есть основные опции для создания файлов YAML (вызов, создание, применение, удаление и откат – «Get», «Create», «Apply», «Delete», «Rollback», на нужной ставим флажок) – окно задач, в которых задается последовательность и другие важные характеристики. Каждая опция имеет свой прямой эквивалент в kubectl. Такие файлы YAML могут храниться в репозиториях локального или удаленного типа, и при запусках замещаться.

Запущенные задачи (соло/последовательно – одна за другой/несколько сразу параллельно) складываются в этапы развертывания, логические схемы которых отражаются в левой части – каждый этап отдельно (см. скриншот выше). Оповещения о них будут посылаться в логи (они задаются на второй вкладке правого блока редактора задач («Notification»)), а если что-то пошло не так в процессе запуска, и нужно частично очистить разворот, поможет следующая вкладка там же – «Rollback», где определяется, как именно это будет происходить.

Зона Kubernetes

Зоны Kubernetes позволяют администраторам облаков определять опирающееся на политику размещение кластеров Kubernetes и пространств имен. Чтобы создать зону Kubernetes, нам нужно:

  1. Зайти на вкладку «Infrastructure»;
  2. Нажать на «Configure» – «Kubernetes Zones»;
  3. Кликнуть на «+ NEW Kubernetes Zone»:

Здесь на вкладке «On-demand» выбираем один или несколько уровней PKS и назначаем им приоритетность. Можно определить кол-во воркеров, мастеров, доступной памяти и CPU, а также другие настройки этого уровня.

Важно! Ассоциация зоны Kubernetes с проектом обязательна до момента создания блюпринта.

Блюпринт с ресурсами Kubernetes

Вчитываясь в предыдущие главы, вы наверняка уже поняли, что блюпринты в практике Kubernetes – вещь поистине бесценная. И сейчас мы на практике рассмотрим, как это все работает.

К примеру, можно создать блюпринт, который будет разворачивать on-demand кластер Kubernetes и пространство имен (безусловно, после интеграции VMware Enterprise PKS, как описывалось выше):

Учтите, что только два компонента Kubernetes доступны для использования в блюпринте. Это K8S Cluster и K8S Namespace. Первый разворачивает on-demand кластер Kubernetes в ассоциированной с проектом зоне Kubernetes. Второй же создает по требованию пространство имен, которое может использоваться этим кластером. Вся остальная кухня работы с блюпринтами этого типа абсолютно идентична прочим разновидностям.

Миграция NSX-V в NSX-T с помощью vRA

Переход с NSX-V на NSX-T для многих в последнее время стал неминуемой перспективой. Ни для кого не секрет, что NSX-V доживает свои последние дни, и даже названа конкретная дата окончания его поддержки – 16 января 2022 года, по предварительным анонсам. VMware настоятельно рекомендует озаботится сменой продуктов заранее, чтобы было время подрихтовать и настроить систему, научиться с ней работать, в конце концов (все материалы по сетевой виртуализации выложены в этом разделе нашего блога – изучайте, осваивайте).

Радует, что герой нашего сегодняшнего разговора предлагает специальный помощник – практически полностью автоматизированное решение, предполагающее минимальное вовлечение администратора. Этот помощник vRA состоит из страницы «Getting Started» – гида в миграции NSX-V на NSX-T и последовательных страниц плана миграции. Каждый облачный аккаунт NSX-V – источник – нуждается в отдельном миграционном плане в помощнике.

Одним из важных пунктов этой миграции является обмен файлами между администратором vRA и NSX – это входные и исходные данные для утилиты NSX-T Data Center Migration Coordinator. Вот, кстати, иллюстрирующий эту необходимость скриншот:

Видите, помощник подскажет, когда и что нужно сделать в этом плане.

Важно! Перенос NSX-V в NSX-T возможен только в рамках одной версии vRA. Это означает, что и первый, и второй продукты должны пройти интеграцию в одном и том же vRA.

Поддерживаемые миграцией топологии

Помощник vRA работает с миграцией объектов из NSX-V в NSX-T 3.1.1 или свежее. Более ранние версии NSX-T не поддерживаются. При этом NSX-V должен быть 6.4.4 или новее, а vRA – 8.3+. Также необходимо опираться на vCenter версии 7.0 или более новой, а версия ESXi из среды NSX-V должна поддерживаться NSX-T.

Важно! vSphere Distributed Switch поддерживаются, если они версий 6.5.0, 6.6.0 и 7.0.

Список поддерживаемых топологий:

  • существующие сети (статические и DHCP),
  • маршрутизируемые сети (статические и DHCP),
  • приватные сети (статические и DHCP),
  • существующие группы безопасности,
  • группы безопасности по требованию,
  • одноплечевые балансировщики нагрузки по требованию на существующих сетях,
  • исходящие сети (статические и DHCP) с либо без общего шлюза
Важно! Определенные пользователем правила DNAT не поддерживаются. Балансировщики нагрущки с исходящими сетями не поддерживаются.
  • развертывания, содержащие исходящие или приватные сети, использующие политику изоляции в качестве группы безопасности по требованию,
  • приватные сети, изолированные группой безопасности,
  • исходящие сети, изолированные группой безопасности.

Не поддерживаются топологии:

  • развертывания, содержащие NAT или DNAT правила, настроенные на NAT или компоненте шлюз,
  • маршрутизированные сети с Т1 общего пользования,
  • одноплечевые балансировщики нагрузки или встроенные балансировщики нагрузки в любой сети по требованию,
  • встроенные балансировщики нагрузки по требованию на существующих сетях,
  • существующие тэги безопасности.

Важно заметить, что, если любой разворот в среде vRA был смигрирован с vRA 7.х на vRA 8.х, еще до создания плана миграции NSX-V на NSX-Tследует запустить сбор данных на облачных аккаунтах NSX-V и vCenter. Иначе не будет информации о смигрированных ресурсах, например, о балансировщиках нагрузки.

Подготовка к миграции

Прежде всего, учитывая вышеупомянутый момент сотрудничества администраторов NSX и vRA, рекомендуется согласовать им между собой расписание, чтобы можно было совместно поработать над импортом и экспортом файлов в утилите NSX-T Data Center Migration Coordinator. И, вообще, конечно же, для такой длительной и серьзеной процедуры, как миграция, стоит выделить техническое окно.

Также, до того нужно создать новый и неассоцированный ни с чем (ни с vCenter, ни с облачным аккаунтом vCenter Server) и не использующийся ни в одном развертывании vRA целевой облачный аккаунт NSX-T в vRA для каждого аккаунта NSX-V – потом будет указываться однозначное их сопоставление при переходе. При его создании выбирается опция «Policy API method» («Manager API method» не поддерживается). Эти новые аккаунты добавляются в vRA в проекты.

Если мы хотим смигрировать и роли пользователей из NSX-V, обязательно нужно развернуть и настроить vIDM (если начальная инсталляция vRA не происходила через vLCM с конфигурацией VMware Identity Manager в качестве обязательного шага – см. нашу предыдущую статью из цикла по vRA об инсталляции и начальной настройке).

Важно! Все проблемы, найденные при начальном обследовании состояния NSX-V-среды, должны быть исправлены до миграции.

Использование vRealize Automation NSX-V to NSX-T Migration Assistant

Доступ в помощник можно получить прямо из консоли облачных сервисов, зайдя под учетной записью администратора и имея права на миграционные процессы («vRealize Automation» – «Cloud Services Console» и клик на плитку «vRA Migration Assistant»):

Откроется окно:

в котором нужно раскрыть секцию «NSX V2T Migration» левой навигационной панели и выбрать там «Getting Started», как показано на скриншоте. Теперь нам, в общем, расскажут о процессе, а когда будем готовы начать миграцию, просто выбираем следующий пункт левого меню – «Migration Plan» – справа откроется рабочая область, в которой нам нужно кликнуть на «+New Plan»:

Появится визард с последовательной инструкцией – просто следуем ей неукоснительно:

настроив облачные аккаунты источника и цели, запустив оценку, чтобы определить готовность к миграции, инициировав режим техобслуживания для облачных аккаунтов, перетрансферив конфигурацию и файлы сопоставления нашему коллеге – администратору NSX, запустив миграцию, чтобы сопоставить исходные объекты NSX-V новым целевым объектам NSX-T. Финально, нам нужно будет протестировать системы и выйти из режима техобслуживания для облачных аккаунтов.

Импорт конфигурации NSX-V

Предварительно, нам нужно сгенерировать конфигурационный файл в формате JSON из среды vRA. Если среда NSX-V использует Edge-сервисы на шлюзах, следует убедиться, что был создан IP-пул в среде NSX-T для использования TEP Edge. И обязательно нужно запустить сервис-координатор миграции из ВМ NSX Manager, зайдя как admin по SSH командой:

NSX-Manager1> start service migration-coordinator

Затем делаем следующее:

  1. В браузере заходим на ноду NSX Manager (где запускали координатор) под правами админа и далее – в «System» – «Migrate»;
  2. С панели «NSX for vSphere with vRealize Automation» переходим по «Get Started»;
  3. На странице «Import Configuration» ищем «Select NSX» и нажимаем на него, вводим учетные данные по vCenter Server и NSX-V;
  4. В секции «Upload Deployment Configuration File» кликаем на «Select File» и выбираем конфигурационный файл JSON, созданный нами в процессе подготовки. Если вдруг на этом шаге ошиблись и выбрали не тот файл (или нашли в нем ошибку синтаксиса и впоследствие исправили), всегда можно нажать на выбор еще раз и найти уже правильный – старый перезапишется. Однако, удалить такой файл оттуда, в принципе, после подгрузки уже не получится – только перевыбрать новый. Разве что мы отменим миграцию, как таковую, откатим ее на странице «Import Configuration» или на «Migrate Configuration» координатора, либо же завершим миграцию на странице «Migrate Hosts»;
  5. Жмем на «Start» для инициации импорта конфигурации. По окончанию этого процесса кликаем на «Continue», чтобы перейти на страницу «Resolve Configuration».

Если импорт сфейлится из-за неправильной трансляции конфигурации edge-ноды, можно кликнуть на флажок «Failed», чтобы понять, каково кол-во и размер требуемых NSX Edge ресурсов. Когда исправим эти параметры нод, нажимаем на «Rollback», чтобы откатить попытку миграции и перезапустить импорт конфигурации.

Логи импорта конфигурации можно найти в «/var/log/migration-coordinator/v2t».

После успешного импорта появится ссылка «View Imported Topology», если нажать на которую, увидим графическое представление импортированной топологии – еще один способ узнать, все ли прошло так, как нам нужно. Однако, учтите, что с масштабированными средами NSX-V этот просмотр топологии не работает.

Откат или отмена миграции

Если где-то потерпели неудачу, всегда можем откатиться, чтобы отменить какие-то шаги прогресса, или сбросить миграцию, в принципе. Кнопка «Rollback» на некоторых этапах после старта миграции поможет нам в этом (на других она будет недоступна). Вот перечень этапов, когда это можно сделать:

  • Import Configuration (страница «Import Configuration»),
  • Resolve Configuration (на этой странице кнопки нет – надо вернуться на «Import Configuration» и нажать там),
  • Migrate Configuration (страница «Migrate Configuration» – вводы, предоставленные на предыдущей странице будут удалены)
Важно! Перед предпринятием отката на странице «Migrate Configuration» рекомендуется сформировать Support Bundle.
  • Check Realization (возврат на страницу «Migrate Configuration», смигрированные конфигурации восстановятся),
  • Migrate Edges (откатится миграция маршрутизации Edge и сервисов)
Важно! Если откатываем этап Migrate Edges, следует убедиться, что трафик идет обратно через шлюзы сервисов NSX-V Edge. Может понадобиться вручную помочь откату.
  • Migrate Hosts (как такового, роллбэка на этой странице нет, но можно вручную удалить NSX-T из смигрированных хостов и переинсталлить NSX-V на хостах. При миграции NSX-V 6.4.8 и свежее, на NSX Manager надо запустить:

POST api/2.0/nwfabric/blockEamEvents?action=unblock

перед тем, как предпринимать откат вручную, а затем переинсталлить NSX-V на хостах).

Кроме опции отката, на каждой странице есть кнопка «Cancel», позволяющая отменить вообще все состояние миграции с системы. Перед тем, как это произойдет, координатор выдаст предупреждающее сообщение:

Canceling the migration will reset the migration coordinator. It is advisable to rollback this

step first or it might leave the system in a partially migrated state. Do you want to continue?

Важно! Нельзя отменять миграцию, если стартовала миграция хоста или Edge.

Учтите, что отмена может оставить систему в частично смигрировавшем состоянии с некоторой постоянной конфигурацией. Тем не менее, файл логов миграции все еще будет получаться на Appliance NSX Mаnager, хотя развернутая конфигурация и удалится. Из-за этого придется подгружать файл конфигурации развертывания снова на странице «Import Configuration», когда решим возобновить процесс.

Обычно, к полной отмене миграции прибегают, когда откат сфейлился и не видно вообще никаких других путей по исправлению ситуации. При этом возможны два подхода. Первый состоит в ручном удалении смигрированных постоянных конфигураций из NSX-T и начале новой миграции. В противном случае, между прочим, нам не избежать конфликтов, и мы снова упремся в проблему. Второй подход следующий:

  1. Удаляем текущий Appliance NSX Manager;
  2. Разворачиваем новую среду NSX-T с Appliance NSX Manager и Edge;
  3. Стартуем новую миграцию.

Пост-миграционные задачи

После того, как наша миграция завершилась успешно, нам нужно проделать следующее:

  • Если это был NSX-V4.4 изначально, перезагружаем все хосты, которые подверглись миграции на NSX-T. Это делается обязательно до того, как мы попытаемся проапгрейдить NSX-T до последней версии;
  • Убедиться, что у нас теперь правильная конфигурация бэкапа и восстановления;
  • Импортировать конечный файл сопоставления выводов в vRA. Полученный после миграции окончательный файл сопоставления выводов следует передать администратору vRA, а он, в свою очередь, должен будет импортировать его в шаге 4 миграционного плана, а затем приступить к фазе его ответственности с мигрированием облачного аккаунта и связанных объектов, к тестированию результатов и выводу облачных аккаунтов из режима техобслуживания с закрытием плана миграции (помощника);
  • Если работаете с кластером NSX Manager, учтите, что инструмент миграционного координатора запускается только на одном развернутом Appliance. Следовательно, до того, как начнете на практике использовать среду NSX-T Data Center, следует развернуть два дополнительных Appliance NSX Manager и настроить для кластера VIP.

В процессе все транспортные ноды добавляются в группу «NSGroup with TransportNode for CPU Mem Threshold», чтобы они имели правильные настройки пороговых значений CPU и памяти в NSX-T. Там они должны оставаться и по завершении миграции для нормальной работы. Если же в будущем нам нужно будет удалить транспортную ноду из NSX-T, вначале ее придется вывести из этой группы. Это делается в режиме «Manager»: выбираем «Inventory» – «Groups», ищем нашу группу и удаляем из нее ноду.

Деинсталляция NSX-V

После миграции, если мы довольны результатом и завершены все перечисленные пост-миграционные задачи, следует задуматься о том, чтобы деинсталлировать среду NSX-V. Интересно, что именно при таких исходных данных существуют отличия от обычной деинсталляции NSX. Происходит же это так:

  1. Удаляем агенты ESX Agent Manager, ассоциированные с NSX-V-средой: в клиенте vSphere проходим в «Menu» – «Administration» и под «Solutions» кликаем на «vCenter Server Extensions», затем дважды – уже на «vSphere ESX Agent Manager» и переходим на вкладку «Configure». По каждому агенту с именем, начинающемуся на «_NSX_», выбираем его и кликаем на три вертикальные точки, чтобы выбрать «Delete Agency»;
  2. Удаляем плагин NSX-V из vCenter Server: заходим на Extension Manager с «https://<vcenter-ip>/mob/?moid=ExtensionManager», кликаем на «UnregisterExtension» и в появившемся диалоговом окне вводим в текстовое поле «Value» – «vmware.vShieldManager» и нажимаем на «Invoke Method», а затем в аналогичном – «com.vmware.nsx.ui.h5» и снова на «Invoke Method». Убедиться в успешности дерегистрации можно на странице «Extension Manager», просмотрев значения для свойства «extensionList»;
  • Удаляем директории веб-клиента vSphere для NSX-V и перезапускаем клиентские сервисы. Подключаемся к системе vCenter Server из командной строки, заходим под рутом в консоль по SSH. Учтите, что команды запускаются через Bash shell, поэтому вначале его надо запустить командами:

> shell.set –enabled True

> shell

  1. Удаляем все директории плагинов NSX-V (если ассоциированный клиент никогда не запускался, их мы можем и не увидеть). Если vCenter Server Appliance, это будет «/etc/vmware/vsphere-client/vc-packages/vsphere-client-serenity/com.vmware.vShieldManager-<version>-<build>» или «/etc/vmware/vsphere-ui/vc-packages/vsphere-client-serenity/com.vmware.nsx.ui.h5-<version>-<build>», смотря какого типа клиент. После этого перезапускаем клиентские сервисы командами:

> shell.set –enabled True

> shell

# service-control –stop vsphere-ui

# service-control –start vsphere-ui

  1. Выключаем и удаляем Appliance NSX-V, пройдя в «Home» – «Hosts and Clusters», найдя нужные ВМ и по каждой кликнув правой кнопкой мыши и выбрав «Power Off», после чего кликнув так же еще раз и выбрав «Delete from Disk». В частности, проследите, чтобы были удалены машины: Edge Services Gateway, DLR, NSX Controller и NSX Manager. Доступен множественный выбор с последующим действием для удобства, если одного типа машин, к примеру, слишком много.

Логи в vRA

Все журналы логов vRA относятся к двум глобальным группам: сервисы и файлы ядра системы. Файл среды аналогично включен в пакет логов, и он показывает информацию о статусе («железо», IP-адресация, данные по кластеру и по высокоуровневым системным функциям, вроде сбора данных), а также видение множества команд системы:

Папка «hostname» представляет собой коллекцию сервисов и системных функций, нативных для инфраструктуры Kubernetes. Там типичные для Linux папки с названиями «opt», «etc», «proc» и «var». Секция подов дополнительно поделена на сервисы и базовую коммуникацию с контейнером. Активный под по каждому сервису должен быть виден в логах.

К логам можно достучаться через CLI, запустив команду: «kubectl -n prelude logs <pod name>»:

Если в конце добавим «t» реализуется общая для Linux-устройств функция просмотра непрерывных записей журнала логов в реальном времени.

Некоторые логи набором команд kuberctl серии «pod log» не вызываются, однако являются ключевыми для анализа проблем и вообще всего, что происходит в vRA. Это:

/pods/ingress/ingress-ctl-traefik – обратный прокси системы, используемый для захвата связи к и из системы,

/pods/kube-system/etcd/etcd.log – логи базы данных etcd,

/pods/kube-system/var/logdeploy.log – логи развертывания из инициализации vRA,

/pods/kube-system/var/auth.log – логи аутентификации для ядра системы.

Создание бандла логов

Чтобы создать пакет логов, используем CLI-команду «vracli log-bundle» (поместит его в ту директорию, в которой запускаем команду). Он будет представлять собой зазипованный архив с файлом среды и прикрепленными сервисными и системными логами.

Логи событий

Будучи на веб-портале, можно получить доступ к логам событий, пройдя в «Infrastructure» – «Activity» – «Event Logs»:

Здесь можно использовать фильтрацию по ID запроса, сервису или содержимому сообщения, чтобы было легче искать данные.

Маркетплейс vRA

Очень помогает в изучении практики работы с блюпринтами на первых порах (впрочем, и в дальнейшем – для экономии времени, чтобы «не изобретать каждый раз велосипед»…) встроенный Marketplace vRA:

Здесь можно найти готовые блюпринты и образа виртуализации в свободном доступе, управляемые VMware Solution Exchange – все на отдельной специальной вкладке верхнего меню «Marketplace». Файлы Solution Exchange оттэггированные Cloud Assembly видны под вкладкой «vRealize Automation Cloud Assembly Marketplace», но получить их можно, только введя данные учетной записи аккаунта VMware после нажатия на соответствующую ссылку справа, либо же – в «Connections» – «Integrations». И чтобы достать любой блюпринт или образ просто нажимаем по нему на «Get» – загрузка произойдет прямо в существующий проект, либо же на локальный компьютер. Больше почитать о возможности можно здесь.

Пожалуй, пора завершать наш сегодняшний экскурс в задачи администрирования vRealize Automation 8.4, хотя, конечно же, очень многое, к сожалению, осталось за его рамками. Однако, большинство таких вопросов можно отнести к классу узкоспециализированных, а иногда – попросту экзотичных, поэтому, буде такая необходимость, обращайтесь за их решением в саппорт вендора, к сертифицированным консультантам сферы, либо же ищите информацию в блогах коммьюнити. Также крайне рекомендуем записаться на курсы VMware по vRA – они дадут общее видение и построят ваши знания в стройную, логичную схему.