Каждый раз управляя облаком, мы совершаем повторяющиеся действия: создаем сеть, виртуальную машину, настраиваем правила Firewall и NAT… Все это интересно и удобно первые несколько раз, а потом тебя начинает напрягать не самый отзывчивый интерфейс и кликов по UI набегают сотни, а то и тысячи в месяц. Но ведь можно же делегировать все эти рутинные приседания ИИ‑агенту?
Да, именно так мы и сделали у себя в Облаке VMware, но спокойствие, в этой статье мы его вам продавать не будем. Здесь расскажем тем, кто администрирует свой дата‑центр или облачный тенант на базе VMware, как прикрутить к нему Claude Code, Open Code или любого другого MCP‑совместимого агента без написания собственной обертки над API. Ну и само собой, мы сделаем это так, чтобы разбушевавшийся агент не смог наворотить лишнего, даже если очень захочет.
«А почему бы просто не дать агенту curl?»
Когда я только начал изучать, какие ИИ‑возможности управления VMware Cloud Director есть, выяснилось, что ничего готового вендор не предлагает (по крайней мере на момент публикации). А хотелось, чтобы у наших заказчиков была возможность управлять облаком просто обозначив задачку агенту. Но как это провернуть? Может просто стоит дать LLM‑агенту доступ к сырому API через универсальный HTTP‑инструмент? Если этот вопрос возник и у вас, отвечу вам мемом:
А если серьезно, то при таком исполнении, нас ждет ряд проблем.
1. Мало того что VMware Cloud Director API — это несколько сотен эндпоинтов. Начиная с версии 9.5 у продукта появился еще и второй параллельный API, который живет рядом с унаследованным. Дальше — больше: он отдает ответы в JSON, тогда как предыдущий вариант — в XML. И что самое печальное, два этих API не взаимозаменяемы. Если не прописать инструкции ясно, скорее всего агент будет тратить лишние токены на угадывание правильного пути и параметров запроса.
2. По той же причине агент может начать дергать не ту «ручку» или дергать не в том порядке: например, будет пытаться получить детали о виртуалке до того, как получил ее ID.
3. У агента буквально не будет никаких ограничений на деструктивные операции, а это неизбежно приведет кого‑нибудь из пользователей к ситуации: «я что‑то сказал и все исчезло» (от создателей «я что‑то нажал и все пропало»). А мы хотим следовать принципу safe by design и не наделять лишними полномочиями ни агента, ни юзера от греха подальше.
В общем, мы сочли, что без MCP‑сервера тут не обойтись, поскольку в случае с ним, не будет сложностей, перечисленных выше, а наиболее частотные сценарии превратятся в именованные тулзы. Агент больше не будет составлять запрос к API с нуля — он просто вызовет vm_power_action(vm_id, action="restart"), и сервер сам соберет нужный HTTP‑запрос к нужной версии API. Дело осталось за малым, написать сам MCP‑сервер. Мы собрали операции, которые требуются нашим клиентам чаще всего, написали свой инструмент и выложили на Git. Чтобы модель не заблудилась в названиях, действовали по принципу «одна задача — один инструмент». Подробнее про группы задач расскажу далее.
Архитектура решения и первые шаги
Использовать MCP сервер можно с любым удобным ИИ‑агентом, главное организовать доступ от него к тенанту VMware. У нас получилась следующая комбинация:
Для настройки нам понадобится:
ИИ‑агент;
Docker Compose;
MCP Server VMware Cloud Director;
Username и API Token от учетной записи тенанта VMware Cloud Director.
Шаг 1. Клонируем репозиторий и собираем образ
git clone https://github.com/cloud-ru/vmware-clouddirector-mcp.git cd vmware-clouddirector-mcp docker build -t vmware-clouddirector-mcp:latest
Шаг 2. Проверяем, что сервер поднимается и видит тенант
docker run -i --rm \ --name vmware-clouddirector-mcp \ -e VCD_BASE_URL=https://your\_vcd\_instance\_address \ -e VCD_USERNAME=your_username \ -e VCD_API_TOKEN=your_api_token \ -e VCD_ORG=your_organization \ -e VCD_API_VERSION=39.1 \ vmware-clouddirector-mcp:latest & docker logs -f vmware-clouddirector-mcp
Если в логах нет ошибок аутентификации — останавливаем тестовый контейнер (docker stop vmware-clouddirector-mcp) и переходим к подключению агента.
Шаг 3. Подключаем Claude Code
claude mcp add vmware-cloud-director \ -e VCD_BASE_URL=https://your\_vcd\_instance\_address \ -e VCD_USERNAME=your_username \ -e VCD_API_TOKEN=your_api_token \ -e VCD_ORG=your_organization \ -e VCD_API_VERSION=39.1 \ -- \ docker run --rm -i --network host -e VCD_BASE_URL -e VCD_USERNAME -e VCD_API_TOKEN -e VCD_ORG -e VCD_API_VERSION vmware-clouddirector-mcp:latest
Подробнее в документации Claude Code по MCP. Для OpenCode процесс аналогичен, актуальный синтаксис — в доке OpenCode.
Рабочий лайфхак: попросите агента настроить подключение, большинство современных агентов с этим справляются.
Что может наш MCP‑сервер и почему именно это
На момент публикации наш MCP‑сервер поддерживает 36 инструментов в 8 категориях: Аутентификация и core‑запросы
ovcd_login — аутентификация в VMware Cloud Director;
list_orgs — вывод доступных организаций (Tenant);
list_vdcs — вывод доступных виртуальных дата центров (VDC);
get_vdc_details — получение детальной информации по VDC;
get_resource_usage — получение подробной статистики использования ресурсов.
Управление приложениями
olist_vapps — вывод списка виртуальных приложений;
vapp_power_action — управление активностью виртуальных приложений (start, stop, restart, suspend, resume);
vapp_clone — клонирование виртуального приложения.
Управление виртуалками
olist_vms — вывод списка виртуальных машин;
search_vms — поиск виртуальной машины по имени или VDC;
get_vm_details — получение детальной информации по виртуальной машине;
get_vm_details_with_id — получение детальной информации по виртуальной машине с определенным id;
vm_power_action — управление активностью виртуальной машины (start, stop, restart, suspend, resume)
vm_configure — изменение конфигурации виртуальной машины (CPU и RAM).
Снапшоты
vm_create_snapshot — создание снапшота виртуальной машины;
vm_list_snapshots — вывод списка снапшотов виртуальной машины;
vm_restore_snapshot — восстановление из снапшота виртуальной машины.
Хранилище
list_datastores — вывод списка доступных storage profiles;
vm_add_disk — добавление нового диска виртуальной машине;
vm_list_disks — вывод списка дисков виртуальной машины;
vm_resize_disk — изменение размера диска виртуальной машины.
Сети
list_networks — вывод списка виртуальных сетей;
list_firewall_rules — вывод списка правил фаервола с EdgeGWs;
create_org_network — создание виртуальной сети;
list_nat_rules — ввод списка NAT правил с EdgeGWs;
list_dhcp_pools — вывод списка DHCP пулов с EdgeGWs;
list_ip_allocations — вывод списка аллоцированных IP адресов с EdgeGWs.
Шаблоны и каталоги
list_catalogs — вывод списка каталогов в организации;
list_catalog_items — вывод списка объектов в каталоге;
get_template_details — получение детальной информации по шаблонам виртуальных машин.
Мониторинг
list_tasks — вывод списка задач и операций;
get_vm_metrics — получение метрик производительности виртуальной машины;
list_events — вывод списка событий;
get_org_health — получение статуса состояния организации;
get_resource_metrics — получение метрик использования ресурсов;
health_check — проверка статуса подключения к VMware Cloud Director.
У вас, наверное, возник вопрос: «почему есть возможность создать ВМ, но нет возможности ее удалить»? Деструктивные вызовы мы не стали добавлять сознательно: если вашей команде нужны операции удаления, их придется выполнять вручную или через отдельный, явно подтверждаемый путь. А то дадим «из коробки» возможность удалять, а завтра ваш агент деградирует и снесет половину инфраструктуры. Если уж очень хочется, можно взять за основу наш код и прописать себе все, что душе угодно, кто мы такие чтобы вам запрещать? Главное делайте все осознанно. По итогу ваш агент должен получить ограниченную, но все‑таки власть над облаком. Я вот после установки и подключения спросил агента, что он знает про мои ресурсы:
Как убедиться в том, что через MCP‑сервер ваш агент не пытался удалить все, что нажито непосильным трудом? Элементарно: заходите в разделы Task и Events и смотрите что делалось с инфраструктурой пока вы спали, сидели на очередном митинге или пили кофе. Запросы вывода состояния там отображаться не будут, но любые включения, выключения, создания, изменения видны как на ладони.
Практическая польза и крошечный недостаток
Благодаря возможности управлять облаком с помощью текстовых команд, можно автоматизировать часть регулярных задач без привязки к рабочему месту или коду: передаем задачу агенту, а там он уже сам уточняет, что понадобится для готового результата. Вот пример:
Но есть во всем этом крошечный недостаток, который я пока не придумал как обойти, не теряя в безопасности. MCP‑сервер авторизуется в тенанте Cloud Director с помощью API Token, который принадлежит конкретному пользователю (например, админу организации). Но если сценарий нужно реализовать для нескольких пользователей, под каждого придется создавать отдельный MCP. В целом, это не то чтобы проблема: вы сами видели, что создание MCP‑сервера не такой уж сложный и длительный процесс. Но если у вас есть идеи, как дать нескольким пользователям возможность пользоваться одним сервером, не плодя секреты в .env‑файликах, делитесь в комментариях.
Код доступен as is. И, конечно, перед использованием MCP для автоматизации вашего облака, мы рекомендуем сначала провести тестирование ваших рабочих сценариев в stage‑среде.
Всем побольше правильных ответов от ИИ‑агентов и стабильной инфраструктуры!
