Современный разработчик привык к беспрепятственному доступу к инфраструктуре. В публичном облаке достаточно нажать кнопку или вызвать API — и через несколько минут кластер Kubernetes, виртуальная машина или база данных готовы к работе. Но что происходит, когда требования к суверенитету данных, соответствию нормативным требованиям или прогнозируемости затрат обязывают развёртывать нагрузки на собственной инфраструктуре?
Исторически онпрем-инфраструктура означала создание заявок в IT-систему и ожидание ресурсов в течение дней или даже недель. Такие задержки превращались в серьёзное препятствие для вывода продуктов на рынок. Разработчики, уставшие от очередей, нередко поднимали собственные «теневые» базы данных на неуправляемых виртуальных машинах — только чтобы двигаться быстрее. Результатом становились бесконтрольное разрастание баз данных, дрейф конфигураций, отсутствие управления и серьёзные угрозы безопасности.
Платформенная инженерия на базе VMware Cloud Foundation (VCF) изменила эту картину. Используя платформу частного облака VCF, организации могут устранить разрыв между IT-операциями и командами разработчиков. VCF обеспечивает настоящее «от платформы до данных» самообслуживание, сравнимое с возможностями публичного облака: разработчики получают нужную им скорость, а платформенные инженеры — централизованное управление всем парком ресурсов.
Соответствие публичному облаку: эквиваленты на on-prem VCF
Чтобы оценить возможности VCF как платформы частного облака, полезно сопоставить её функциональность с сервисами публичного облака, которые разработчики уже хорошо знают. Для тех, кто работал с AWS, on-prem-эквиваленты в VCF выглядят следующим образом:
Amazon EC2 > VCF VM Service: позволяет разработчикам декларативно развёртывать традиционные виртуальные машины и управлять ими совместно с контейнерами.
Amazon EKS > VCF VKS (vSphere Kubernetes Service): предоставляет конформные Kubernetes-кластеры с самообслуживанием, нативно встроенные в VCF.
Amazon RDS > VCF DSM (Data Services Manager): реализует инструмент управления парком баз данных в режиме Database-as-a-Service (DBaaS) по запросу.
Совместное использование этих трёх компонентов позволяет платформенным командам предлагать разработчикам комплексный каталог сервисов, управляемый через API, непосредственно из собственного датацентра.
Рабочий процесс платформенного инженера: установка границ
Архитектурный принцип этого решения — управление через персоны. Системный администратор или платформенный инженер определяет «правила игры» и сохраняет контроль, а разработчик потребляет ресурсы строго в заданных рамках. Рабочий процесс устроен следующим образом.
1. Создание границ. Администратор инфраструктуры создаёт vSphere namespace в VCF. Этот namespace выступает границей tenancy: к конкретному проекту или команде разработчиков привязываются лимиты вычислительных ресурсов, памяти и хранилища.
2. Определение инфраструктуры и политик. В рамках namespace платформенный инженер задаёт правила взаимодействия:
Вычислительные ресурсы: размеры кластеров, пулы ресурсов и классы ВМ (размеры: small, medium, large) — чтобы разработчики не превышали допустимое потребление.
Хранилище и сеть: конкретные политики хранения (vSAN или NFS) и привязка нагрузок к нужным VLAN и VPC-подсетям.
Сервисы данных в DSM: разрешённые движки баз данных и их версии, предварительно проверенные командой DBA.
Опыт разработчика: развёртывание в режиме самообслуживания
После того как администратор задал политики, платформенный инженер открывает доступ команде разработки через защищённый API-токен. С этого момента разработчики полностью самостоятельны — никакого ожидания в очереди задач и утверждений. Используя стандартный инструментарий Kubernetes (kubectl), портал или API DSM либо собственные Terraform-пайплайны, они могут:
поднять новый Kubernetes-кластер (VKS) для тестирования микросервисов;
выбрать движок базы данных — PostgreSQL, MySQL или Microsoft SQL Server (появится в версии 9.1).
При этом все самостоятельно подготовленные ресурсы автоматически соответствуют корпоративным политикам резервного копирования, сети и безопасности, установленным администратором.
Автоматизация и интеграция с Infrastructure-as-Code
Всю описанную среду можно полностью автоматизировать с помощью подхода Infrastructure as Code. Платформенная команда может управлять пространствами имен и конфигурациями сервисов через различные инструменты в зависимости от предпочтений: Kubernetes CRD, Terraform-манифест или корпоративный блупринт, охватывающий целый комплекс ресурсов — VKS-кластер с набором виртуальных машин, сервисы данных DSM и даже ArgoCD для доставки приложений в VKS-кластеры — всё в рамках единого набора API-вызовов.
Ниже — пример CRD для декларативного развёртывания базы данных в namespace, демонстрирующий простоту этого подхода. CRD можно использовать как часть GitOps-процесса:
День второй: операционное управление после запуска
Одно из наиболее значимых преимуществ платформенного подхода, особенно с Data Services Manager, состоит в том, что он не заканчивается на первоначальном «нажатии кнопки». Платформа автоматизирует критически важные операции второго дня жизненного цикла — когда приложению предстоит выйти в продуктив. Задачи, которые традиционно поглощали ресурсы DBA, теперь решаются простым изменением декларативного параметра в CRD:
Высокая доступность: автоматическое развёртывание кластеров для немедленной отказоустойчивости.
Масштабируемость: возможность легко добавлять read-реплики по мере роста нагрузки на приложение.
Защита данных: автоматическое резервное копирование и восстановление до точки во времени (PITR) — «из коробки».
Управление: централизованная видимость для платформенной команды с контролем использования и устранением разрастания баз данных по всем рабочим доменам.
Поддержка OSS-баз данных корпоративного уровня: DSM предоставляет возможности и поддержку коммерческого класса, недоступные в бесплатных open-source версиях PostgreSQL или MySQL.
Заключение
Создание каталога самообслуживания — от платформы до данных — не требует переноса всего в публичное облако. Используя VCF, VKS и DSM, организации получают гибкость публичного облака в сочетании с безопасностью и контролем собственной частной инфраструктуры. Платформенные инженеры при этом трансформируются из ИТ-привратников в enabler'ов — обеспечивая разработчиков API-эндпоинтами, Kubernetes-кластерами и управляемыми базами данных, необходимыми для более быстрой и безопасной разработки ПО, готового к производственному окружению.
RSS
