Ключевые концепции
Модель платформы
API построен вокруг проектов и их дочерних ресурсов. Понимание этих границ помогает формировать корректные payload и не смешивать входные параметры провижининга с долгоживущими runtime-ресурсами.
Входные данные провижининга
Образы
Определяют базовую ОС или machine template, используемую при создании VM.
Тарифы
Представляют план или коммерческий профиль, который будет применён к VM.
Конфигурации
Показывают доступные конфигурационные профили VM и помогают выбрать нужный набор ресурсов.
SSH-входные данные
Доступ можно передать как raw public keys или как идентификаторы project-scoped SSH keys.
Runtime-ресурсы
Проекты
Верхнеуровневый namespace для VM, SSH-ключей, сетей и публичных IP-ресурсов.
VM
Основной compute-ресурс. Ответы VM содержат идентификаторы, размеры ресурсов и сетевые привязки.
Сети
Project-level сетевые ресурсы, к которым VM могут подключаться и перенастраиваться.
Резервные копии
VM-scoped recovery points, которые создаются, перечисляются, восстанавливаются и удаляются отдельно.
Асинхронное поведение
Часть операций выполняется как command-oriented workflow. Например, создание VM возвращает command identifier, а сам VM-ресурс содержит поля operation и operationStatus, отражающие текущую работу. На практике это означает: сначала создайте, затем запрашивайте ресурс, пока он не достигнет нужного состояния.
Практическая рекомендация
Сохраняйте projectId и vmId как first-class reference в своём клиенте. Это основные join key почти для всех последующих вызовов в текущей API-поверхности.
Связанные endpoint
/projectsСписок верхнеуровневых project-ресурсов.
/imagesПолучение идентификаторов доступных образов.
/tariffsПолучение идентификаторов тарифов для создания VM.
/projects/{projectId}/vmsСоздание основного compute-ресурса.
/projects/{projectId}/vms/{vmId}Чтение состояния VM после асинхронной операции.