27 мая 2021 года пошел первый патч к 8.4-версии vRealize Automation. Напомним, само крупное обновление стартовало в середине апреля и о нем мы во всех деталях писали вот здесь. Теперь же настало время поговорить о том, какую работу над ошибками проделала VMware за это время и что новенького интересного добавила.
Примечательно, что речь ниже пойдет не только об исправлении известных проблем, но и о нескольких свежедобавленных функциях. Однако, обо всем по порядку.
Актуальный билд
Учитывая, что в этом патче не только были исправлены ошибки, но и появилась целая плеяда нововведений, читателям наверняка захочется сразу же протестировать новый билд этого продукта, который теперь доступен для скачивания за номером 18067628 вот здесь.
Новое в vRealize Automation 8.4.1
На удивление, несмотря на недавнюю глубокую переработку продукта, разработчикам отыскали удивительно большое количество совершенствований и новшеств, которыми с этой версии ему и суждено стало обрасти. Перечислим же их, вкратце:
- В дополнение к существующему виду разворота, теперь можно использовать новый его вид по источнику для мониторинга и управления ресурсами. В частности, можно:
- Выбирать, предпочитаем ли управлять всеми ресурсами или управлять ресурсами по указанному ресурсному типу;
- Инициировать поиск по имени ресурса по всем ресурсам вне уровня разворота;
- Получать облегченный доступ к day2-действиям, производимым прямо на ресурсах;
- Пользоваться индикацией, показывающей, находится ли разворот или ресурс под day2-действием;
- Параллельные day2-действия для ресурсов разворота. Теперь позволено одновременно стартовать day2-действия над множеством ресурсов в одном и том же развороте;
- Улучшения групп свойств (RBAC, ассоциации облачных шаблонов). Добавлены такие функции:
- Разрешения RBAC для использования и управления группами свойств;
- Демонстрация ассоциированных облачных шаблонов к указанным группам свойств;
- Дополнительные атрибуты критериев политик по всем типам политик. Теперь доступны несколько новых атрибутов критериев разворота, опирающихся на ресурс, постоянно по всем типам политик, а также улучшены возможности управления несколькими облаками на основе политик. Перечень этих новых атрибутов:
- Cloud Zone
- Cloud Account,
- CPU Count,
- Cloud Type,
- Flavor,
- Has Snapshots,
- Image,
- Image ID,
- OS Type,
- Power State,
- Region,
- Disks,
- Tags,
- Total Memory (MB),
- Resource Type;
- Распространение политики на несколько проектов. Это позволяет администраторам облаков и администраторам проектов определять политики, которые могут применяться к одному проекту, по множеству проектов, либо же ко всей организации в целом. Осуществляется путем установки набора критериев на основе проекта по всем типам политик;
- Политики. Определение и силовое применение лимитов ресурсов путем использования политик квот ресурсов. Администраторы облаков теперь могут контролировать потребление ресурсов по всей организации и по проектам с помощью установки и принудительного применения повторно используемых квот ресурсов или лимитов потребления по определенным метрикам. В том числе по CPU, хранилищу, памяти и количеству инстансов. В результате получается лучшее понимание потребления конечного сета общих ресурсов и силовое управление на основе политик квотами ресурсов по всей организации, по каждому проекту или по пользователю;
- Возможность включать или выключать диагностику при загрузке для предоставленных с облачными шаблонами VMware ВМ в Azure – Day0;
- Возможность включать или выключать анализ логов для ВМ Azure;
- Поддержка Федерации NSX с NSX-T Cloud Account (Global Manager/Local Manager, существующие сети). Можно подключаться к GM NSX-T и настраивать ассоциацию между GM и LM в контексте Федерации;
- Улучшена поддержка интеграции с облачными шаблонами SaltStack Config. Стала доступной автоматическая инсталляция миньонов с помощью VMware Cloud Templates и разворот конфигурации софта как файлов состояния salt в VMware Cloud Templates;
- Пользовательский траблшутинг действий с ресурсами. Возможность посмотреть пользовательские вводы из запусков рабочих процессов, также доступен просмотр значений из рабочих процессов, выполненных как часть действий с ресурсами;
- Возможность создавать подписки, опираясь на пользовательский ресурс пре- и пост-ивентов. Администраторы облака могут вызывать запуск действий до и после настраиваемого предоставления ресурсов.
Изменения в API
Название сервиса | Описание сервиса | Апдейты и изменения API |
Aggregator | Новый сервис, запускаемый внутри одобренного контейнера. Находит метрики использования ресурсов на уровне организации, пользователя и проекта | Новая конечная точка
/aggregator/api/metrics – возвращает зарегистрированную метрику в службу аггрегатора |
Blueprint | Создает, валидирует и предоставляет блюпринты или облачные шаблоны | Новые параметры:
|
IaaS: Snapshot Creation for Block Device | Создает снэпшоты для устройств блока | Изменения в существующих API:
|
IaaS: Azure Storage profile creation | Создание профиля хранилища Azure | Изменен API: POST /iaas/api/storage-profiles-azure
в разрезе добавления нового свойства diskEncryptionSetId при создании профиля хранилища Azure |
IaaS: Attach Block Device to an Machine | Прикрепление существующего диска к существующей машине | Изменен API: POST /iaas/api/machines/{id}/disks
– добавлены два новых параметра:
|
Catalog Service (Policies) | Взаимодействие с политиками, созданными в Service Broker | Новое поле в Policy Model Object:
scopeCriteria: Criteria – используется для определения политик, затрагивающих множество проектов при применении выражений на основе проекта в формате критерия; Новый API: GET /policy/api/policyTypes/{id}/scopeSchema – возвращает схему распространения политики для типа политики с указанным ID. Помогает правильнее определять метод охвата политики. |
Разблокировать новые API можно, использовав «apiVersion=2021-05-25».
Исправленные ошибки
- При включенном FIPS под Code Stream перезагружался в условиях высокой загрузки. Если параллельно запускалось большое количество конвейеров в FIPS-режиме, поды Code Stream перезагружались, так как потребление памяти превышало предустановленный лимит в 2,5 ГБ.
Чтобы побороть это рекомендуется повысить лимит памяти до 3 ГБ. Для этого:
-
- Заходим по SSH на ноду. Если НА – в каждую;
- Проверяем текущий лимит памяти пода:
kubectl -n prelude describe deployment codestream-app
-
- Увеличиваем лимит до 3000 МБ;
Поды Code Stream будут пересозданы;
- API создания машины игнорировала scsiController и unitNumber, предоставленные для прикрепления диска к ней. Речь о POST /iaas/api/machines. Чтобы исправить это, прикрепляем диск к машине отдельно, используя API-запрос:
POST /iaas/api/machines/{id}/disks с scsiController и unitNumber;
- Вложенная функция блюпринта не работала со свойствами star;
- Не получалось проапдейтить Custom Resources при подъеме с 8.3 на 8.4 (на вкладке Design);
- Запуск ресурсного действия по развороту создавал новый объект «deployment», который нельзя было удалить, и не давало уничтожить этот разворот или выполнить против него другие обычные для объекта такого типа действия;
- Поле «Project» получалось пустым при запросе объекта каталога, пока его не выберешь дважды;
- CSS для пользовательских форм на ресурсном действии для пользовательских ресурсов не имело никакого эффекта (Day-2-действия);
- Не получалось забиндить целочисленные значения к vRO-действиям ввода в пользовательских формах;
- Не получалось добавить рабочий процесс в Service Broker, если этот рабочий процесс имел вводы, которые не были включены в Input Form. Выдавало ошибку;
- Тест разворота и блюпринта фейлился для специфических различных вводов Location/Environment в блюпринте с использованием тэгов возможности;
- Не работала корректно пагинация при просмотре Enterprise Groups в Identity & Access Management;
- Оценка давала сбой с таймаутом в случае большого кол-ва вычислительных ресурсов в vRA 7.x (вызывала Migration Assessment Failure);
- Миграция застревала на блюпринтах XaaS при потере требуемого рабочего процесса в vRealize Orchestrator 8.x;
- Миграция застревала на профиле «Reservation» – «Storage»;
- Развороты 7.х терялись после миграции из-за возврата продублированного идентификатора;
- Оценка давала сбой с ошибкой, когда происходил захват полезной нагрузки блюпринта;
- Запросы vRealize Automation фейлились с ошибкой: «Connection reset by peer»;
- ВМ удалялась после сбоя предоставления ВМ с дублированием имени. Происходило только при развороте ВМ через OVF-шаблон из библиотеки контента в vCenter5. Если использовать более свежие версии продуктов, такого не будет;
- Пользовательский фирменный логотип не был доступен после апгрейда до 8.4;
- Периодические ошибки в kube-system/state-enforcement-cron из-за падения проверки «vracli status first-boot»;
- Инсталляция vRA фейлилась по причине истечения срока пароля. Теперь позволено установить пароль рута при первой загрузке, даже если оригинальный пароль истек;
Также стоит отметить, что появилась поддержка субгруппы в интеграции с vRA GitLab. Структура папки GitLab теперь может иметь более двух вложенных папок, в т.ч. group/sub-group/project. И еще один важный момент: функция возврата pgjsonb удалена. Среды, которые ранее использовали pgjsonb, должны переключиться на функцию возврата sseapi. Функция возврата и параметры кэша задания находятся в конфигурационном файле мастер-плагина SaltStack Config /etc/salt/master.d/raas.conf на каждом из мастеров. Все связи с pgjsonb должны быть удалены и включены следующие настройки:
master_job_cache: sseapi
event_return: sseapi
Вот, пожалуй, и все, что хотелось сегодня рассказать об обновлении vRA до версии 8.4.1. Если интересует информация по этому продукту, как таковому, рекомендуем обратиться к его персональному разделу на страницах нашего блога, а другие новости, в том числе и все, что касается линейки vRealize VMware, мы традиционно публикуем в «News 2021».