В этом году компания VMware серьезно взялась за доработку своих фреймворков по автоматизации операций в виртуальной инфраструктуре. Это было обусловлено тем, что исторически у VMware накопилось большое количество средств автоматизации, которые когда-то были привязаны к специфическим продуктам и интерфейсам, потом эти продукты эволюционировали, объединялись в различные линейки, а старые интерфейсы продолжали тянуться за разными решениями, управлять которыми до сих пор можно несколькими разными способами, а с учетом различных платформ и вспомогательных сервисов таких способов становится слишком много.
Это приводит к путанице в среде администраторов, которые не понимают, какой путь автоматизации является рекомендуемым, и как понять, что сценарии, разработанные сегодня, будут работать в виртуальной инфраструктуре и через год. Давайте попробуем с этим разобраться.
Итак, в какую сторону по реформированию фреймворков автоматизации идет сейчас VMware:
1. Новый протокол VI/JSON для управления инфраструктурой vSphere
VMware vSphere обладает богатым набором API, позволяющим управлять платформой, что является одним из её сильных и слабых моментов одновременно. Эти API, включающие в себя всё от управления виртуальными машинами до виртуализации хранилищ и сетей, обеспечивают гибкость настройки платформы и возможность автоматизации процессов.
Виртуальные интерфейсы управления (VI API), введённые около 15 лет назад, нашли широкое применение. Благодаря этим API, созданы множество продуктов и скриптов, а разработчики знакомы с их методологией. Основанные на SOAP и XML, интерфейс VI API, несмотря на функциональность, имеет сложности, связанные с безопасностью и использованием XML. При этом, работая с интерфейсами автоматизации, разработчики все чаще предпочитают JSON.
Для облегчения интеграции в JSON-совместимые среды, включая веб-браузеры и современные языки программирования, такие как Go, VMware ввела новый протокол, похожий на REST и основанный на JSON - VI/JSON. Эта возможность стала доступной, начиная с VMware vSphere 8 Update 1.
Новый протокол VI/JSON представляет собой современную замену устаревшему SOAP, предлагая те же VI API, современную модель безопасности и минимальные изменения при переходе от SOAP.
Этот протокол обеспечивает прямой доступ к управляемым свойствам, нескольким сотням типов записей, отражающих состояние элементов, управляемых vSphere, от виртуальных машин до сетей и кластеров. Ранее эти свойства были доступны только через Property Collector, теперь же их можно получить с помощью простого HTTP GET-запроса.
В отличие от SOAP, в VI/JSON ресурсы и операции кодируются в URL-адресе запроса, а не в теле сообщения. Это упрощает интеграцию на уровне сетевых экранов, облегчает анализ трафика и написание скриптов. Кодировка данных на основе JSON делает разработку проще для пользователей VI API.
Улучшена и безопасность: вместо HTTP-кук для идентификации сессии используется специальный HTTP-заголовок, предотвращающий межсайтовую подделку запроса (Cross-Site Request Forgery), когда угроза идет от третьей стороны.
Вот как просто выглядит включение виртуальной машины с применением нового протокола:
Как мы заметили выше, с течением времени VMware vSphere стала более сложным продуктом, предоставляя разнообразные типы API. Самыми используемыми сегодня являются:
Наличие нескольких API усиливает сложность управления и эксплуатации больших сред, причем эта сложность отражается в различных аспектах - от необходимости иметь разные инструменты и навыки до различных эндпоинтов и механизмов аутентификации для разных API.
Каждый из API имеет отдельную документацию со своими руководствами и примерами кода, что может привести к путанице у администраторов, которые могут предположить, что нужно выбрать между REST API и SOAP API, в то время как они должны использовать оба, поскольку они дополняют друг друга.
Сегодня VMware активно работает над улучшением API, концентрируясь на упрощении использования API, оптимизации документации, улучшении опыта разработчиков и унификации протоколов и инструментов. Последние новости об этом вы можете узнать по этим ссылкам:
Если вернуться к протоколу VI/JSON, то там были сохранены та же структура, управляемые объекты и имена методов из приведенных выше API, чтобы клиенты могли перенести существующие решения для автоматизации на новый протокол JSON с минимальными изменениями.
Наконец, VMware предлагает спецификации OpenAPI 3.0 в дополнение к документации по JSON API виртуальной инфраструктуры. VMware также ведет работу по объединению документации по JSON API с документацией по Automation API, где задокументированы все REST-сервисы. Это приближает момент создания единого ресурса для поиска документации клиентами.
Тут можно выделить три основных направления улучшений, над которыми сейчас ведется работа:
В перспективе VMware планирует преобразовать оставшиеся публичные SOAP-интерфейсы (такие, как SPBM, SMS и прочие) для совместимости с новыми форматами, включая предоставление спецификаций OpenAPI 3.0 для каждого из них и интегрирование их с документацией по REST API.
Следующим преобразованием станет введение общего механизма идентификации для REST API и нового JSON протокола вместо SOAP API. Это облегчит разработку автоматизированных решений и обеспечит единое управление для всех сервисов vSphere в рамках одной сессии.
Завершающим этапом в процессе усовершенствования станет обеспечение доступа ко всем сервисам через один эндпоинт, что позволит администраторам просто взаимодействовать со всеми API vSphere. Это значительно упростит работу и улучшит качество документации и комфорт разработчиков.
3. Кроссплатформенный движок PowerCLI
Применение командлетов PowerShell/PowerCLI для автоматизации обладает целым рядом преимуществ, включая удобство установки на различных операционных системах и мощный сценарный язык, поддерживающий команды, разработанные специально для продуктов VMware.
PowerCLI отлично (а можно сказать, что и лучше других инструментов) встраивается в экосистему VMware, обеспечивая гармоничное взаимодействие с такими продуктами как vSphere, vSAN, SRM и другими. Хоть PowerCLI и функционирует независимо со своим собственным расписанием релизов, VMware стремится согласовывать его с официальными версиями vSphere. Это обеспечивает возможность пользователей PowerCLI быстро получать доступ к новым функциям и возможностям, которые поставляются в новых версиях VMware vSphere.
Многие ассоциируют PowerShell с Microsoft Windows, что весьма понятно, но мультиплатформенное ядро PowerShell Core набирает популярность на платформах Linux и MacOS. VMware стремится обеспечить поддержку этих платформ в паритете с Windows.
С течением времени и эволюцией VMware vSphere и других продуктов VMware, PowerCLI также должен претерпевать изменения и это должно происходить быстро, чтобы оставаться в актуальном состоянии с инновациями в продуктовой линейке. Этот ускоренный темп не должен снижать удобство использования и качество командлетов PowerCLI. Поэтому в VMware поставлена задача расширения функционала PowerCLI для продуктов в более короткие сроки, сохраняя при этом необходимое качество модулей и командлетов.
Когда PowerCLI 13.0 был представлен в ноябре 2022 года, он стал первым PowerCLI, полностью совместимым с PowerShell Core, работающим на Microsoft Windows, Linux и Apple MacOS. Это позволяет запускать примеры кода и полноценные сценарии на любой из указанных платформ, а также, например, планировать их выполнение с использованием cron на Linux. Такая гибкость делает его высокоэффективным инструментом автоматизации, расширяя возможности для оркестровки операций.
Это подразумевает, что модули, включая VMware.ImageBuilder и VMware.DeployAutomation, должны были обеспечивать совместимость с Apple MacOS и Linux. Также были внесены новые команды для управления дисками кластера vSAN ESA и модуль VMware.VimAutomation.Cloud был обновлен для поддержки функционала API VMware Cloud Director 10.4.
В PowerCLI 13.1 были представлены два новых модуля: VMware.Sdk.VR, обеспечивающий поддержку REST API VMware vSphere Replication, и VMware.Sdk.Srm, отвечающий за поддержку REST API VMware Site Recovery Manager. Также добавлены новые командлеты для работы с офлайн-репозиториями Lifecycle Manager, удаленным управлением хранилищами данных vCenter Server, прямым управлением дисками vSAN, выключением кластера, монтированием удаленных хранилищ данных vSAN из расширенных кластеров vSAN и многое другое.
Кроме того, еще начиная с релиза PowerCLI 12.4, была автоматизирована генерация командлетов для vSphere Automation API, которая была выпущена в рамках нового модуля под названием VMware.SDK.vSphere. Этот подход позволяет быстро создавать командлеты и модули для поддержки новых функций, обеспечивая при этом качество и последовательность. В последующих релизах VMware продолжила внедрять новые модули PowerCLI на основе подхода автоматического генерирования (например, модули VMware.Sdk.Nsx.Policy и VMware.Sdk.SRM).
4. Улучшения SDK
vSphere Software Development Kits (SDK) - это средства автоматизации разработки решений для различных продуктов VMware на базе различных языков программирования и фреймворков.
SDK реализуют различные байндинги для vSphere API. Например, vSphere Automation SDK реализует байндинги для следующих сервисов REST в vSphere:
VMware vSphere Automation Endpoint в vCenter Server
VMware Cloud on AWS Console API
VMware NSX-T on VMware Cloud API
NSX VMware Cloud on AWS Integration API
VMware Cloud on AWS Site Recovery API
Для протокола SOAP реализованы байндинги в vSphere Management SDK для следующих сервисов:
VMware vSphere Web Services API
VMware vSphere ESXi Agent Manager API
VMware Storage Policy API
Virtual Storage Lifecycle Management API
VMware vCenter Server Storage Monitoring Service API
VMware vCenter Server Single Sign-On
Одной из ключевых проблем до недавнего времени было большое число SDK для автоматизированного управления рабочими процессами в программно-определенном центре обработки данных (SDDC). Для каждого языка программирования имеется по два вида привязок SDK. В качестве примера можно привести pyvmomi, который предназначен для доступа к SOAP API vSphere, и vSphere Automation Python SDK для работы с REST API vSphere.
Тут есть некоторые проблемы - Automation SDK находился в репозитории GitHub от VMware, в то время как Management SDK был размещен на сайте developer.vmware.com. Pyvmomi был доступен в репозитории PyPI, но там не было Automation SDK for Python. В общем, не было единой точки работы с нужными разработчику SDK. Плюс ко всему в некоторых компаниях не разрешается использовать открытое ПО из репозиториев GitHub.
Есть и еще одна проблема - некоторым партнерам VMware необходим ранний доступ к SDK для тестирования своих решений и своевременного устранения возникающих проблем. Однако SDK не входят в бета-программы VMware, поэтому они не получают превью-версии до официального выпуска (General Availability). Это препятствует получению обратной связи в ранний период, а также затрудняет разработку ПО для новых релизов vSphere.
Что поменялось в этом году в данной ситуации или будет сделано в ближайшее время:
VMware начинает слушать комьюнити разработчиков (в качестве примера можно привести функцию auto-completion в pyvmomi 8.0.1.0).
VMware увеличивает частоту апдейтов своих SDK, чтобы разработчики получали своевременный доступ к новой функциональности.
Cледующим шагом VMware будет запуск единого SDK, который интегрирует байндинги как для SOAP, так и для REST-основанных API.
Будет центральное место для получения разработчиками всех необходимых библиотек - документация и источник загрузки будет располагаться в общедоступных репозиториях пакетов, таких как PyPI и Maven Central.
Будут добавлены байндинги для нового протокола JSON.
VMware планирует предоставить ранний доступ к SDK клиентам и партнерам.
Итоги
В этом году VMware сделала многое не только для того, чтобы улучшить свои средства автоматизации виртуальной инфраструктуры vSphere и других продуктов, но и чтобы качественно реорганизовать их. Действительно, раньше разработчики жаловались на то, что ресурсы по API, фреймворкам и SDK находятся в разных местах, многие инструменты (на первый взгляд) дублируют друг друга - поэтому неясно, какие именно нужно использовать. В итоге, VMware сделала много шагов, чтобы решить эти проблемы, а также полностью сделала интерфейс PowerCLI кроссплатформенным, что очень облегчило жизнь разработчиков и администраторов виртуальной инфраструктуры. Также введение протокола VI/JSON для управления инфраструктурой говорит нам о том, что VMware идет в ногу со временем и ориентируется на потребности разработчиков и текущие технологические тренды.
Наверняка это еще не все позитивные новости - ведь впереди конференция VMware Explore 2023, где будет объявлено о многих дополнительных нововведениях и улучшениях в плане средств автоматизации операций в виртуальной инфраструктуре.