Категорії
News 2021

vRealize Automation 8.4 Release Notes

15 апреля 2021 года стало известно о выпуске нового релиза нашей любимой платформы автоматизации виртуальной среды vRealize Automation – версии 8.4. Казалось бы, совсем недавно – буквально в середине февраля – мы писали о 8.3, однако за все семейство vRealize VMware в последнее время взялась настолько плотно, что такому частому выходу обновлений пора привыкать перестать удивляться.

Как рассказывалось в нашем комплексном обзоре, посвященном обновленному портфолио этой линейки, 8.3 была своеобразным трамплином – именно 8.4 суждено стать вехой и ориентиром, уж слишком многие надежды на нее возложены, и слишком многое в ней постарались реализовать. Сегодня мы расскажем обо всем, что удалось сделать разработчикам, какие ошибки в этой версии были исправлены и где ее можно достать, чтобы обновиться. К слову, в ближайшем будущем, когда закончим весь злободневный цикл о новой ступени жизненного пути нашего vRealize (эти новости, как и всегда, если интересно, можно будет найти в разделе «News 2021» нашего блога, или же на специальной страничке, выделенной под каждый отдельный продукт в меню «Products»), обновлению до самой свежей инкарнации vRA уделим отдельный мануал.

Актуальный билд

Представлены отдельные билды под vRA Easy Installer (ISO) – 17879649 и под appliance vRA – 17874359, найти которые можно на странице загрузок продуктов VMware:

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

Что поменялось в vRealize Automation 8.4?

Интересной особенностью версии 8.4 vRealize Automation стал, в какой-то степени, небольшой откат в сторону 7.х-релизов – снова были представлены возможности XaaS, и добавлена поддержка Powershell в ABX и Python, node.js и Powershell в vRO. Однако, не будем забегать вперед и расскажем обо всем по порядку.

  • Внедрение соответствия Federal Information Processing Standard (FIPS) 140-2 – SaltStack Config. Теперь SaltStack Config вооружен криптографическими модулями, успешно прошедшими тестирование NIST FIPS 140-2 Cryptographic Module Validation Program (CMVP). Когда они настраиваются в «FIPS-mode», они накрывают все криптографические операции в продукте, отвечающие за функции безопасности и защиту чувствительных данных;
Важно! Выбор включения режима FIPS доступен исключительно в момент инсталляции, и только для зеленой установки сред SaltStack Config.  При запуске с vRealize Automation смешанный режим FIPS не поддерживается.
  • Изменения в поведении Access Token API. Поведение API «/csp/gateway/am/api/login?access_token», используемого на первом этапе двух-шагового процессе получения токена доступа для API-интеграций изменилось. Рекомендации по утилизации этого API изложены здесь. На самом деле они не трансформировались с vRA0.1. Ранее этот API возвращал и обновленный токен, и токен доступа. Токен доступа полностью не регистрировался при этом в vRA и не мог использоваться со множеством API. Чтобы избежать этого казуса, теперь этот API возвращает только обновленный токен для использования на втором этапе процесса;
  • Улучшение доступности. Наблюдаются значительные улучшения в расширении специальных возможностей для следования стандартам Web Content Accessibility Guidelines (WCAG) 2.1 Level A и AA. В планах вендора к концу мая этого года опубликовать актуальный отчет соответствия доступности (посмотреть отчет для старших версий, к примеру, 8.2, можно здесь);
  • Политика критериев политик для дополнительных операторов Integer/String. Улучшена поддержка Integer и String, опирающихся на операторы для политик, что позволит администратору определять политики более гранулировано:
    • Целочисленные операторы «greater than», «less than», «greater than or equal» и «less than or equal» представлены для статей критериев «Total Memory (MB)» и «CPU Count»;
    • Представлен строчный оператор «contains» для статей критерия «Created By» и «Owned By»;
    • Представлен строчный оператор «Matches regex»;
    • Логические значения (True/False или On/Off) для операторов «equals» или «not equals» теперь доступны для атрибутов ресурсов, например, для «Has Snapshots» и «Power State»;
  • Поддержка критериев политики для тегов ресурсов по всем типам политик. Улучшена поддержка для ресурсов на основе тегов как дополнительных критериев, что позволяет администраторам vRA определять гранулированные политики, которые могут иметь своей целью развороты с ресурсами с указанными тегами. И статья критерия политики тега ресурса стала доступной по всем типам политик;
  • Перенастройка существующей группы безопасности для vSphere и VMC – итеративно и Day 2. Действие по перенастройке группы безопасности (Day-2 и итеративный разворот) позволяет модифицировать, добавлять или удалять правила существующей группы безопасности для запуска приложений в vSphere или в VMware Cloud на AWS;
  • Изменение существующих групп безопасности или групп по требованию для VMC – итеративно и Day 2. Это действие позволяет задавать ассоциацию или диссоциировать группу безопасности, не важно – существующую или новую – являющуюся частью разворота VMware Cloud на AWS для одной или более машин в развороте. Можно прикреплять или откреплять группу безопасности в блюпринте к/от соответствующей машине (нескольким машинам), а затем апдейтить развороты с этой новой технологией с помощью итеративного разворота;
  • Обновлено имя хоста в Ansible Tower. Ранее, когда машина предоставлялась vRA, добавлялся ее IP-адрес в Ansible Tower, а не имя хоста. Теперь Hostname добавлен в число переменных «ansible_host» в Ansible Tower. Имя хоста или строка FQDN могут передаваться в Ansible Tower из облачного шаблона;
  • Поддержка конфигурации «multi-vm/disk». Теперь можно указывать создание множества виртуалок с несколькими прикрепленными к ним дисками, и для всех их дисков будет доступна поддержка Day 2-действий. К тому же их станет гораздо проще идентифицировать с соответствующей ВМ;
  • Добавление диска с разными размерами. Облачные шаблоны vRA теперь разрешают конфигурации с разными размерами дисков;
  • Изменены развороты проектов для адаптированных разворотов. Изменение проекта как Day 2-действие для адаптированных разворотов с этого момента обладает такими свойствами:
    • Day 2-действия доступны только для адаптированных разворотов в этом релизе. Причем адаптировать можно только Disks и Machines. Если адаптированный разворот апдейтится с целью добавления любых предоставленных ресурсов, действие по изменению проекта будет не доступно. Если предоставленный ресурс удаляется, изменение проекта становится доступным снова;
    • В случае любого сбоя действие автоматически не откатывается. Можно инициировать его вручную снова;
    • В целевом Project можно представить аналогичный ресурс Cloud Zone, в противном случае последующие действия Day 2 могут давать вовсе не тот эффект, на который рассчитывали. Эти предварительные условия не выполняются, что соответствует существующей логике адаптации;
  • Добавлена документация для настройки прокси для vRA on-premises Terraform-сред;
  • Отмена регистрации адаптированных машин из vRA. Операция доступна только для адаптированных машин и она удаляет ресурс из разворота, делая его доступным для адаптационного процесса снова. При этом с любых прикрепленных дисков (тех, что были адаптированы вместе с машинами) автоматически снимается регистрация. Как только добавляются любые дополнительные диски на адаптированную машину, она более не считается подключенной и функция отмены регистрации становится недоступной;
  • Единое хранилище секретов. Cекреты действий расширяемости теперь называются «action constants». Константы действий обладают одним и тем же списком секретов службы проекта. От пользователей, у которых есть соответствующие константы действий из предыдущей версии, никаких телодвижений не требуется;
  • Центр операций – поддержка пользовательских ролей. Insights, Alerts и Optimizations теперь могут фильтроваться по кастомным ролям, имея «read», «only/read», «write» доступ к Cloud Zones, Projects и Deployments;
  • Центр операций – улучшения Cloud zone Insights. Теперь аналитика облачной зоны показывает проекты вместе с их восстанавливаемой емкостью;
  • Центр операций – оптимизируемые развертывания теперь отличаются. Оптимизируемые развертывания можно отфильтровать из списка развертываний для более легкого к ним доступа;
  • Указание порядка и контроллера SCSI для дисков vSphere. При создании новых дисков в процессе развертывания можно в облачном шаблоне указывать порядок, в котором создаются диски. Это сделано для улучшения идентификации дисков для day 2-действий. Также в облачном шаблоне можно указывать и который SCSI-контроллер должен быть сопоставлен с диском. vRA поддерживает всего до 4 SCSI-контроллеров на каждый разворот и можно выбирать среди этих четырех для каждого из дисков;
  • Поддержка дисков, являющихся частью шаблона образа. Существуют инстансы, где шаблоны образов обладают дисками в дополнение к загрузочному диску. vRA поддерживает эти диски для day 2-операций. Их можно просматривать в деталях ВМ и осуществлять с ними day 2-действия, вроде изменения их размера. Операция по изменению размера происходит по объекту ВМ в диаграмме развертывания и показывает все подключенные к машине диски;
  • Размещение диска должно соответствовать ВМ в сценарии размещения рабочей нагрузки/нескольких машин. Ранее, когда создавалось множество ВМ в одном развертывании (с использованием поля количества), была возможность того, что диск иногда мог не пойти в тот же кластер, что хостит ВМ. Теперь же размещение диска всегда происходит в том кластере, где хостится ВМ для оптимальной производительности;
  • Распределение хранилища в соответствии с полным размером ВМ. Ранее, когда хранилище распределялось для шаблона/библиотеки контента, опираясь на разворот, распределение базировалось только на дефолтной емкости и изменяло размер впоследствии, только после уточнения деталей по завершению разворота. Теперь же хранилище распределяется для полного размера разворота, включая образа дисков с данными, благодаря чему размещение Workload с vROPs не затрагивается. Также включается и емкость любых дисков с данными, являющихся частью шаблона;
  • Упрощение рабочего процесса адаптации. Рабочий процесс плана создания адаптации сейчас существенно упрощен для облегчения приведения ВМ к управлению ими vRA. Опция правила упразднена и рабочий процесс сейчас позволяет прямой выбор машин. Обзор машин показывает только те их них, которые были напрямую выбраны пользователем;
  • Поддержка галереи Azure. Теперь vRA работает с галереей образов для поддержки предоставления с использованием пользовательских образов, размещенных в галерее, а также для использования этих образов по всему множеству подписок Azure;
  • Менеджмент снэпшотов для дисков Azure. Можно создавать снэпшоты дисков и управлять ими в разворотах Azure;
  • Поддержка наборов шифрования дисков для Azure. Это сделано для поддержки сторонних KMS-систем, использующих наборы шифрования, а также для шифрования ВМ и всех прикрепленных к ним дисков (как настоящих, так и будущих) с одинаковым ключом;
  • Усовершенствована поддержка наборов доступа для Azure. Поддержка повторного использования существующих наборов доступности в облачных шаблонах и установка сетов доступности как опциональных, для того, чтобы ресурсы могли не быть частью какого бы то ни было набора;
  • Улучшения в Ansible. Добавлено новое свойство блюпринта Ansible Tower – «maxJobRetries», которое повторяет попытку Ansible Playbooks. Кроме того, появилась возможность вызывать шаблоны рабочих процессов из интеграции Ansible Tower, использовать эту интеграцию с выполнением учетной записи пользователя, а в опен-сорсе Ansible vRA создает сервер, используя его имя хоста вместо IP-адреса. Также стоит отметить возможность передавать дополнительные переменные из блюпринта yaml в Ansible Tower и обновлять «Prompt on launch / Limit» для интеграции Ansible Tower, чтобы использовать дефолтные значения;
  • Улучшения паппетов. Передача определенных пользователем свойств из блюпринта как фактов мастеру Puppet из ноды-агента и указание PE-мастера мастеров;
  • Улучшен брокер событий. Появилась возможность добавлять подписки на стадии пост-предоставления и до включения питания;
  • Выпуск аддонов vRA STD+ и SaltStack SecOps в оставшемся мире. Теперь не только в США, но и по всему миру доступны предложения по vRA STD+ и SaltStack SecOps – прошли еще в феврале одобрение Export Compliance;
  • SaltStack Config. Появилась возможность применять лицензию SaltStack Config, используя VMware Lifecycle Manager. Этот продукт приведен в соответствие с FIPS, и можно определить включение или выключение этого режима в процессе разворота;
  • Плагин ITSM. Поддержка объектов каталога с Custom Resource (без поддержки для vRO Objects), работа для них с пользовательскими Day 2-действиями, а также возможность настраивать каталог vRA, добавляя Edit Box и Drop down в ServiceNow. Также можно добавлять скрипты прикрепления к этим полям и просматривать детали разворота на ServicePortal;
  • Плагин vRA. Плагин vRealize Orchestrator для vRA позволяет взаимодействовать vRealize Orchestrator и vRealize Automation. Готовые рабочие процессы этого плагина помогают разворачивать и управлять ресурсами в vRA в автоматизированном режиме. В дополнение к этому можно создавать и запускать пользовательские рабочие процессы. Новый предложенный контент в vRO совместим с vRA 8.х и решает большинство пользовательских задач по созданию и запуску рабочих процессов главных функций продукта, например, существующих в поле управления проектами и пользователями, использования кастомных типов, управления ВМ и пр. Этот плагин одинаков и для on-prem, и для облака;
  • ABX-масштабирование. При запуске АВХ-действий можно восстановить К8s-поды, чтобы предотвратить выход за лимиты физической инфраструктуры. Кроме того, АВХ-действия могут быть внесены в расписания по всему кластеру vRA, чтобы количество одновременных таких действий могло вырасти;
  • GCP Sole Tenancy. Теперь можно устанавливать пользовательское свойство, чтобы почувствовать преимущества GCP Sole Tenancy (связанного хоста);
  • IPAM-регистрация для vRA 7.x-рабочих процессов при адаптации во vRA 8.х. При адаптации ресурсов, являющихся частью 7.х в 8.х, регистрация IPAM обновляется для таких рабочих процессов. Это сделано во избежание дублирования назначений с провайдером IPAM и, чтобы освободившиеся IP вернулись в пул, как только рабочая нагрузка будет удалена;
  • Принудительное удаление разворотов для конечной точки IaaS API. Добавилась функция принудительного удаления с параметром запроса «forceDelete». Если его значение «true», значит, сделано максимум для того, чтобы удалить развертывание и все связанные ресурсы. Следует использовать с осторожностью, так как в некоторых случаях, подготовленные ресурсы инфраструктуры могут быть оставлены за ней, и в результате пользователю придется их удалять вручную. Если же по этому параметру значение «false», применяется стандартная операция удаления;
  • Поддержка OpenShift для интеграции Terraform в vRA. Теперь поддерживается настройка среды выполнения Terraform с OpenShift для интеграции службы в vRA.

Изменения в API

Для уверенности, что используется самая последняя версия API, следует запустить «apiVersion=2021-04-21» – подобное залочит эту версию для процессов. Либо же указать любую предшественницу, упомянув в аналогичной команде соответствующую дату релиза. Если вообще не вводить ничего такого, дефолтная версия автоматически будет считаться по 8.4.

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

Название сервиса Описание сервиса Обновления и изменения в API
blueprint-service Функционал служб блюпринтов, включая создание, валидацию и предоставление Новые параметры:

  • GET /blueprint/api/blueprints/{blueprintId}/inputs-schema
  • GET /blueprint/api/blueprints/{blueprintId}/versions/{version}/inputs-schema с новыми параметрами «maxProperties» и «minProperties»
  • POST /blueprint/api/blueprint-validation с новым параметром запроса «blueprintVersion»

 
Resource quota policy – Aggregator service Новый сервис, запускающийся внутри контейнера утверждения. Предоставляет доступ к поиску метрик использования ресурсов на уровне организации, пользователя и проекта Новая конечная точка «/aggregator/api/metrics», возвращающая зарегистрированные метрики в сервис аггрегатора
Snapshot Creation for Block Device – Provisioning Service Для создания снэпшотов устройств блока Изменения в имеющихся API:

  • POST /iaas/api/block-devices/{id}/operations/snapshots, добавляющий новые свойства Map для свойств ввода в процессе снэпшотирования, если есть разные свойства для снэпшотов в разных облачных аккаунтах;
  • GET /iaas/api/block-devices/{id}/snapshots/{id1} – добавляет свойства Map в модель ответа снэпшота. Ответ API включает изменения: «snapshotProperties» добавлен как новое поле «ключ-значение», а поле «isCurrent» исключено
Azure Storage profile creation – Provisioning Service Для создания профиля хранилища Azure Изменены:

  • POST /iaas/api/storage-profiles-azure

– добавлено новое свойство «diskEncryptionSetId» в процессе создания профиля хранилища Azure
Attach Block Device to an Machine – Provisioning Service Используется для прикрепления существующего диска к существующей машине Изменения в:

  • POST /iaas/api/machines/{id}/disks

– добавлены новые параметры:

«scsiController :- SCSI controller»

называет прикрепленный диск с четырьмя возможными значениями: «SCSI_Controller_0», «SCSI_Controller_1», «SCSI_Controller_2», «SCSI_Controller_3»

и «unitNumber: *любое значение от 0 до 15*»

Решенные проблемы

  • Недоступен Assessment Service swagger;
  • Исключение в диалоговом вводе, если свойства не определены в схеме объектного типа. Если свойство ввода из объектного типа и свойства не определены в json-схеме, диалоговый ввод в тестировании или диалог разворота блюпринта может не загрузиться;
  • Не отсылаются значения при развороте с полем ввода массива. Хотя пользователи могут заполнять значения в форме ввода, UI посылает массив с нулями в сервис блюпринта в диалоге теста/разворота;
  • Можно создавать политику day2 с дубликатами действий/авторизаций с помощью API. При этом система не производит валидирующую проверку и политика создается. Интересно, что, если делать то же самое, но через UI, все в порядке, так как раскрывающийся список не содержит одинаковых записей;
  • Изменение «/csp/gateway/am/api/login?access_token» для возврата только обновленного токена. Поведение API «/csp/gateway/am/api/login?access_token» изменено – см. выше в разделе «Что поменялось в vRealize Automation 8.4?».

No related posts.