Cloudpods Documentation

repository·master·Indexed 25 days ago

https://github.com/yunionio/cloudpods

A Golang-based unified multi/hybrid-cloud platform providing a single API layer to manage resources across public clouds (AWS, Azure, GCP, etc.), private clouds (OpenStack, ZStack), and on-premise infrastructure. Includes 'AI Cloud' for LLM inference and AI container applications, support for the Model Context Protocol (MCP) via the climc command, and the mcclient Go library for API integration.

Tokens
47.8K
Snippets
83
Records
613
Agent score
84%

What's inside Cloudpods

  1. Overview of Cloudpods

    master

    Cloudpods is an open-source, cloud-native multi-cloud/hybrid-cloud management platform implemented in Golang. It acts as a "cloud on top of clouds," providing a unified API to manage heterogeneous infrastructure resources. It abstracts the differences in data models and APIs across various cloud providers, allowing users to manage local virtual machines, physical machines, and multiple public/private cloud accounts through a single interface.

    Key capabilities include:

    • Multi-Cloud Management: Unified access to public clouds (AWS, Azure, GCP, etc.) and private clouds (OpenStack, VMware, etc.).
    • AI Cloud: A dedicated platform for managing LLM inference services and AI container applications, featuring GPU scheduling and model management.
    • Resource Abstraction: Standardized management of servers, load balancers, object storage, NAS, RDS, and VPCs.
  2. Use Cloudpods MCP Server to expose climc capabilities to AI clients

    master
    The Cloudpods MCP Server uses the Model Context Protocol (MCP) to expose climc capabilities to AI clients such as Cursor or Claude. It works by scanning climc command tables and options, generating schemas from struct tags, and executing the corresponding climc callbacks when tools are invoked by the AI client.
  3. Approve and merge a single Pull Request with approve.sh

    master

    Use approve.sh to merge a specific Pull Request after performing automated safety checks.

    Safety Checks performed:

    1. Verifies the PR status is open.
    2. Verifies the PR mergeable status is true (ensures no merge conflicts).
    3. Verifies all CI checks have passed.
    4. If the check_reviewers argument is provided, verifies that all requested reviewers have provided an lgtm status.

    Warning: This script is a convenience tool for merging and does not replace manual code review. Ensure you have manually reviewed the code before execution.

    ./scripts/approve.sh <PRN> [check_reviewers]
  4. Delete an `llm_deployment` and its `aiproxy` resources

    master

    Deleting an llm_deployment automatically triggers the cleanup of associated aiproxy resources, including ai_provider, ai_model, and ai_routing.

    • Providers are identified via llm_deployment_id or llm_id.
    • Routing is identified via llm_deployment.aiproxy_routing_id.

    This cleanup occurs regardless of whether auto_register_aiproxy is set to true.

  5. Create a custom AI provider

    master

    To set up a custom gateway as a provider, you must define the base_url, a top-level secret, and the api_mode (openai or anthropic). Note that creating a provider does not automatically inject catalog models; you must manually create ai_model resources and configure routing.

    // OpenAI mode example
    {
      "generate_name": "my-gateway",
      "provider_key": "custom",
      "secret": "sk-xxx",
      "config": {
        "base_url": "https://llm.example.com/v1",
        "api_mode": "openai"
      }
    }
    
    // Anthropic mode example
    {
      "generate_name": "my-anthropic-gateway",
      "provider_key": "custom",
      "secret": "sk-ant-xxx",
      "config": {
        "base_url": "https://llm.example.com/anthropic",
        "api_mode": "anthropic"
      }
    }
  6. Integrate Anthropic SDK with aiproxy

    master

    When using the Anthropic SDK or Claude Code with aiproxy, you must use the aiproxy virtual_key for authentication, NOT the upstream provider's API key.

    Crucial Configuration Rules:

    1. Base URL: Set base_url to ${AIPROXY_URL}/ai/anthropic. Do not append /v1 to the URL, as the SDK will append it automatically (resulting in /v1/v1/messages if you do).
    2. API Key: Use the virtual_key generated by aiproxy.

    Python Example

    import anthropic
    client = anthropic.Anthropic(
        base_url=f"{AIPROXY_URL}/ai/anthropic",  # Correct: SDK appends /v1/messages
        api_key=VIRTUAL_KEY,                     # aiproxy virtual_key
    )
    client.messages.create(model="claude-sonnet-4-5", max_tokens=128, messages=[...])

    Environment Variables

    export ANTHROPIC_BASE_URL="${AIPROXY_URL}/ai/anthropic"
    export ANTHROPIC_API_KEY="${VIRTUAL_KEY}"
    import anthropic
    client = anthropic.Anthropic(
        base_url=f"{AIPROXY_URL}/ai/anthropic",
        api_key=VIRTUAL_KEY,
    )
    client.messages.create(model="claude-sonnet-4-5", max_tokens=128, messages=[...])
  7. Configure Codex CLI via `climc ai-codex-config`

    master

    Use climc ai-codex-config to generate configuration files required for the Codex CLI to work with the Cloudpods AI Gateway. This command generates config.toml, models_catalog.json, and aiproxy.env based on an existing ai_virtual_key.

    Key Details:

    • Base URL: Points to {gateway_root_url}/ai/openai/v1. If --routing is specified, it uses the access_address of the bound ai_proxy_node.
    • Authentication: Codex uses the OPENAI_API_KEY environment variable to carry the virtual_key. You must source aiproxy.env before starting Codex.
    • Model Catalog: When --routing is used, models_catalog.json contains the intersection of models available to the virtual key and models defined in the route's catalog.
  8. Approve a group of related Pull Requests with approve_all.sh

    master

    Use approve_all.sh to merge a set of related Pull Requests, typically consisting of a main PR on the master branch and its corresponding cherry-pick PRs backported to other branches.

    Check Logic:

    • For the Master PR: Performs all 4 checks (Open status, Mergeable status, CI pass, and Reviewer check if requested).
    • For Backport PRs: Performs only the first 3 checks (Open status, Mergeable status, and CI pass).
    ./scripts/approve_all.sh <PRN>
  9. Configure the MCP Server

    master

    The MCP Server requires a configuration file to define server settings and Cloudpods API authentication.

    Prerequisites:

    • You must create a user named mcp-server-admin within the system.
    • This user must be assigned the admin role and added to the system project.

    Configuration File Locations: By default, the server searches for configuration files in the following order:

    1. /etc/yunion/mcp-server/mcp-server.yaml
    2. ./config/mcp-server.yaml
    3. ./mcp-server.yaml

    You can also specify a custom path using the --conf flag during startup.

    Configuration Schema:

    Server Base Configuration

    • address: The IP address the server binds to (e.g., '127.0.0.1').
    • port: The port number (e.g., 12001).
    • admin_domain: The domain for the admin user (e.g., Default).
    • admin_password: The password for the mcp-server-admin user.
    • admin_project: The project the admin belongs to (e.g., system).
    • admin_project_domain: The domain for the admin project (e.g., Default).
    • admin_user: The username for authentication (e.g., mcp-server-admin).
    • auth_url: The Cloudpods API gateway URL (e.g., https://<ip_or_domain_of_apigatway>:30500/v3).
    • session_endpoint_type: The type of session endpoint (e.g., public).

    MCP Service Configuration

    • mcp_server_name: The name of the MCP service (default: cloudpods-mcp-server).
    • mcp_server_version: The version of the MCP service (default: 1.0.0).
    • mcp_server_description: A description of the service.
    # Example configuration creation
    $ mkdir -p /etc/yunion/mcp-server
    $ cat<<EOF >/etc/yunion/mcp-server/mcp-server.conf
    # ==================== 服务器基础配置 ====================
    address = '127.0.0.1'
    port = 12001
    admin_domain = Default
    admin_password = X8SXBkwkK3WtbSUA
    admin_project = system
    admin_project_domain = Default
    admin_user = mcp-server-admin
    auth_url = https://<ip_or_domain_of_apigatway>:30500/v3
    session_endpoint_type = public
    
    
    # ==================== MCP 服务配置 ====================
    mcp_server_name = cloudpods-mcp-server
    mcp_server_version = 1.0.0
    mcp_server_description = the mcp server of the cloudpods server
    EOF
  10. Use DeepSeek as an Anthropic-compatible backend

    master

    You can use DeepSeek as a backend for Anthropic-style requests. aiproxy will translate Anthropic SDK requests into OpenAI chat/completions calls for DeepSeek.

    Option 1: Translation Mode (Default)

    Set config.api_mode=openai. The client uses the Anthropic SDK, and aiproxy converts the request.

    ResourceExample
    ai_provider.provider_keydeepseek
    ai_provider.config.base_urlhttps://api.deepseek.com
    ai_provider.config.api_modeopenai
    ai_model.model_keydeepseek-chat

    Option 2: Native Anthropic Mode

    Set provider_key=deepseek and config.api_mode=anthropic. aiproxy will pass Anthropic SDK requests directly to DeepSeek's Anthropic endpoint (https://api.deepseek.com/anthropic/v1/messages).

    Example provider configuration for Native Anthropic mode:

    {
      "generate_name": "my-deepseek",
      "provider_key": "deepseek",
      "secret": "<deepseek-api-key>",
      "config": {
        "base_url": "https://api.deepseek.com",
        "api_mode": "anthropic"
      }
    }