概览 | BytesRouter

LlamaCloud 用到若干外部依赖 —— Postgres、Redis 与 Temporal 是始终必需的；MongoDB 可以用 minimal profile 省掉（见下文）。RabbitMQ 已不再使用。

注意

AMQP 传输已被移除。从旧版本升级请照迁离 RabbitMQ操作。

要求

我们正式支持这些依赖的下列版本：

Postgres
- 最低版本 >=15.x
- 需要对数据库的 Admin 权限。LlamaCloud 会读写并应用迁移。
- 起步建议给数据库 1 - 2 vCPUs 与 1 - 2 GBi RAM。随用量增长再相应扩容。
- 当 Postgres 同时也是 Index 的向量库目标（minimal profile 的默认）时，服务端必须装有 pgvector 扩展 —— LlamaCloud 会在首次索引导出时执行 CREATE EXTENSION IF NOT EXISTS vector。见 Index 配置。
- 推荐的托管服务：
MongoDB — 可选（见 minimal profile）
- 最低版本 >=7.x
- 起步建议给数据库 1 - 2 vCPUs 与 1 - 2 GBi RAM。随用量增长再相应扩容。
- 推荐的托管服务：
Redis
- 最低版本 >=7.x
- 起步建议给该库 200 - 500m vCPUs 与 500Mi - 2GBi RAM。随用量增长再相应扩容。
- 推荐的托管服务：
Temporal

无 MongoDB 的部署（minimal profile）

MongoDB 可以通过把 Helm values 里的 mongodb.enabled: false 关掉来省去 —— chart 随后会注入 MONGO_DISABLED 并且不再渲染 MongoDB 的 Secret。chart 自带了适配这一形态的预设覆盖文件：

helm install llamacloud . -f my-values.yaml -f examples/profiles/minimal.yaml

minimal profile 下的功能面：

端到端可用（Temporal + PostgreSQL + Redis）：Parse、Extract 与 Index —— 目录同步、导出、检索，以及针对 postgres（pgvector）索引目标的对话。
返回带原因码的 4xx 错误，而不是接下自己跑不了的活：v1 parse、pipelines（旧的流水线 API 面）、针对 pipeline 文档的检索，以及 mongodb 索引导出目标。

minimal 预设会把默认的索引目标钉在 postgres 上；向量库连接会自动继承你内联写的 postgresql.* 值（细节与 pgvector 的要求见 Index 配置）。

外部依赖配置

要把你的 LlamaCloud 部署接到外部依赖上，就在 values.yaml 里配好相应的段落。

使用 Temporal 子 chart（推荐）
使用外部 Temporal

postgresql:
  host: "postgresql"
  port: "5432"
  database: "llamacloud"
  username: "llamacloud"
  password: "llamacloud"

mongodb:
  host: "mongodb"
  port: "27017"
  username: "root"
  password: "password"

redis:
  scheme: "redis"
  host: "redis-master"
  port: "6379"
  db: 0

# Deploy Temporal as a subchart (host/port auto-configured)
temporal:
  deploy: true

# Temporal subchart configuration.
# The Temporal store password comes from your postgresql.password —
# the chart generates the temporal-postgresql-secret automatically.
temporal-subchart:
  server:
    config:
      persistence:
        defaultStore: default
        visibilityStore: visibility
        datastores:
          default:
            sql:
              connectAddr: "<postgresql-host>:5432"
              databaseName: temporal
              user: <username>
          visibility:
            sql:
              connectAddr: "<postgresql-host>:5432"
              databaseName: temporal_visibility
              user: <username>

postgresql:
  host: "postgresql"
  port: "5432"
  database: "llamacloud"
  username: "llamacloud"
  password: "llamacloud"

mongodb:
  host: "mongodb"
  port: "27017"
  username: "root"
  password: "password"

redis:
  scheme: "redis"
  host: "redis-master"
  port: "6379"
  db: 0

# Use an existing external Temporal deployment
temporal:
  deploy: false
  host: temporal-frontend
  port: 7233

注意

Temporal 存储的密码（Kubernetes Secret）。 上面子 chart 的 datastores.*.sql 各块是有意不写 password 的。LlamaCloud chart 默认的 temporal-subchart values 把两个存储都指向一个 Kubernetes Secret —— existingSecret: temporal-postgresql-secret、secretKey: password。当 temporal.deploy: true 时，chart 会在 pre-install/pre-upgrade 钩子里（因此在 Temporal 的 schema job 挂载它之前它就已存在）从你的 postgresql.password 自动生成那个 temporal-postgresql-secret，所以你 不需要 手工创建它。要换用别的凭据，就改 postgresql.password，或覆盖 temporal-subchart.server.config.persistence.datastores.<store>.sql.existingSecret / secretKey 以引用你自己管理的 Secret。

下面的例子都用 Bitnami 的 Helm chart 安装各个存储。

注意

请把每一个后端存储都装进与你 LlamaCloud release 相同的 namespace。下面的命令都用 --namespace llamacloud；如果你的 release 在别处，请改掉每条命令里的命名空间，并先执行 kubectl create ns <your-namespace> 建好它。LlamaCloud 的 values 引用的是集群内的裸主机名（postgresql、mongodb、redis-master），只有存储同处一个 namespace 时才解析得到。

每个 chart 还会申请不带显式 StorageClass 的 PersistentVolumeClaim。若你的集群没有默认 StorageClass —— Amazon EKS 默认就不会创建 —— 这些 claim 会一直停在 Pending，pod 永远排不上去。要么把某个 StorageClass 设为默认，要么在下面每个 values 文件里加一段 global.storageClass: <name>。

Postgresql 配置示例

Postgresql 的安装示例：

helm upgrade --install postgresql \
    oci://registry-1.docker.io/bitnamicharts/postgresql \
    -f postgresql.yaml --namespace llamacloud --wait --timeout 10m

postgresql.yaml

image:
  registry: docker.io
  repository: bitnamilegacy/postgresql

auth:
  enabled: true
  database: llamacloud
  username: llamacloud
  password: llamacloud

## Ref: https://github.com/bitnami/charts/blob/main/bitnami/postgresql/values.yaml#L481
primary:
  resources:
    requests:
      cpu: 250m
      memory: 128Mi
    limits:
      cpu: 250m
      memory: 256Mi

global:
  security:
    allowInsecureImages: true

resourcesPreset: micro

MongoDB 配置示例

MongoDB 的安装示例：

helm upgrade --install \
  mongodb oci://registry-1.docker.io/bitnamicharts/mongodb \
  -f mongodb.yaml --namespace llamacloud --wait --timeout 10m

mongodb.yaml

image:
  registry: ghcr.io
  repository: xavidop/mongodb
  tag: '7.0'

auth:
  enabled: true
  rootUser: root
  rootPassword: password

global:
  security:
    allowInsecureImages: true

resourcesPreset: micro

Redis 配置示例

Redis 的安装示例：

helm upgrade --install redis \
  oci://registry-1.docker.io/bitnamicharts/redis \
  -f redis.yaml --namespace llamacloud --wait --timeout 10m

redis.yaml

image:
  registry: docker.io
  repository: bitnamilegacy/redis

auth:
  enabled: false
  #password: "password"

tls:
  enabled: false

architecture: standalone

global:
  security:
    allowInsecureImages: true

resourcesPreset: micro

Temporal 配置示例

LlamaCloud 支持两种部署 Temporal 的方式：

方案一：把 Temporal 作为子 chart 部署（推荐）

最简单的方式是把 Temporal 作为 LlamaCloud 的子 chart 部署。这种方式会自动为 LlamaCloud 各服务配好 Temporal 的 host 与 port。

在你的 values.yaml 里设 temporal.deploy: true，并配置 temporal-subchart 段：

# Deploy Temporal as a subchart
temporal:
  deploy: true

# Temporal subchart configuration
temporal-subchart:
  serviceAccount:
    create: true
    name: temporal-server

  web:
    additionalEnv:
      - name: TEMPORAL_CSRF_COOKIE_INSECURE
        value: "true"
    service:
      port: 80

  server:
    config:
      persistence:
        defaultStore: default
        visibilityStore: visibility
        datastores:
          default:
            sql:
              driverName: postgres12
              pluginName: postgres12
              connectAddr: "<postgresql-host>:5432"
              connectProtocol: tcp
              databaseName: temporal
              user: <username>
              maxConns: 20
              maxIdleConns: 20
              maxConnLifetime: "1h"

          visibility:
            sql:
              driverName: postgres12
              pluginName: postgres12
              connectAddr: "<postgresql-host>:5432"
              connectProtocol: tcp
              databaseName: temporal_visibility
              user: <username>
              # createDatabase/manageSchema default to true in the LlamaCloud chart,
              # so the schema job provisions the databases and schema automatically.
              maxConns: 20
              maxIdleConns: 20
              maxConnLifetime: "1h"

注意

与上面的子 chart 示例一样，存储的 password 不内联写。chart 引用一个 Kubernetes Secret（existingSecret: temporal-postgresql-secret，键为 password），并在 temporal.deploy: true 时从你的 postgresql.password 自动生成该 Secret。要自备凭据，见上文 Temporal 存储密码那条说明。

提示

使用 temporal.deploy: true 时，你不必指定 temporal.host 或 temporal.port —— 它们会自动指向子 chart 的 frontend 服务。

方案二：使用外部的 Temporal 部署

如果你已有 Temporal 部署，或希望单独管理 Temporal，可以让 LlamaCloud 连接一个外部 Temporal 实例。

先单独安装 Temporal：

helm install --repo https://go.temporal.io/helm-charts \
  temporal temporal -f temporal.yaml

temporal.yaml

serviceAccount:
  create: true
  name: temporal-server

web:
  additionalEnv:
    - name: TEMPORAL_CSRF_COOKIE_INSECURE
      value: "true"
  service:
    port: 80

server:
  config:
    namespaces:
      create: true
    persistence:
      defaultStore: default
      visibilityStore: visibility
      datastores:
        default:
          sql:
            driverName: postgres12
            pluginName: postgres12
            connectAddr: "<hostname>:5432"
            connectProtocol: tcp
            databaseName: temporal
            user: <username>
            password: <password>
            # Have the chart's schema job create the database and manage the schema.
            createDatabase: true
            manageSchema: true
            maxConns: 20
            maxIdleConns: 20
            maxConnLifetime: "1h"

        visibility:
          sql:
            driverName: postgres12
            pluginName: postgres12
            connectAddr: "<hostname>:5432"
            connectProtocol: tcp
            databaseName: temporal_visibility
            user: <username>
            password: <password>
            createDatabase: true
            manageSchema: true
            maxConns: 20
            maxIdleConns: 20
            maxConnLifetime: "1h"

注意

Temporal 的 Helm chart（v1.0.0+）移除了随带的 cassandra、mysql、postgresql、prometheus、grafana 与 elasticsearch 子 chart 以及顶层的 schema: 块，并用 persistence.datastores.<name> + defaultStore / visibilityStore 取代了 persistence.default / persistence.visibility。建库与 schema 管理如今落在每个 datastore 上（createDatabase / manageSchema）。上面的片段用的是当前形态 —— 旧写法会让 helm install 直接以 '...' is no longer supported 失败。

然后配置 LlamaCloud 连接你的外部 Temporal：

# LlamaCloud values.yaml
temporal:
  deploy: false
  host: temporal-frontend  # Your Temporal frontend service name
  port: 7233

通过 TLS 连接 Temporal 的数据存储

如果你的 SQL 数据存储要求 TLS（用 Amazon RDS、Azure Database for PostgreSQL 或 Cloud SQL 这类托管数据库时很常见），既要在 persistence.datastores.<store>.sql.tls 上启用 TLS，也要把证书文件挂载进 Temporal 的 pod。下面的例子用的是随带的子 chart（temporal.deploy: true）；同样的 server / admintools 结构也适用于外部 Temporal 部署。

1. 用你的证书创建一个 Secret

在 release 的 namespace 里创建一个 Kubernetes Secret，至少放入 CA bundle（只有当你的数据库要求双向 TLS 时才需要再放客户端证书/私钥）：

终端窗口

kubectl create secret generic temporal-db-tls -n <namespace> \
  --from-file=ca.pem=./ca.pem
# For mutual TLS, also add:
#   --from-file=client.pem=./client.pem \
#   --from-file=client-key.pem=./client-key.pem

2. 在两个数据存储上都启用 TLS 并挂载证书

temporal:
  deploy: true

temporal-subchart:
  server:
    config:
      persistence:
        defaultStore: default
        visibilityStore: visibility
        datastores:
          default:
            sql:
              connectAddr: "postgresql:5432"
              databaseName: temporal
              user: <username>
              tls:
                enabled: true
                caFile: /etc/temporal/tls/ca.pem
                enableHostVerification: true
                serverName: <db-hostname-in-cert>   # must match the DB certificate SAN
                # For mutual TLS, also set:
                # certFile: /etc/temporal/tls/client.pem
                # keyFile: /etc/temporal/tls/client-key.pem
          visibility:
            sql:
              connectAddr: "postgresql:5432"
              databaseName: temporal_visibility
              user: <username>
              tls:
                enabled: true
                caFile: /etc/temporal/tls/ca.pem
                enableHostVerification: true
                serverName: <db-hostname-in-cert>

    # Mount the cert Secret into the running Temporal server pods
    additionalVolumes:
      - name: temporal-db-tls
        secret:
          secretName: temporal-db-tls
    additionalVolumeMounts:
      - name: temporal-db-tls
        mountPath: /etc/temporal/tls
        readOnly: true

  # Mount it into admintools as well — see the caution below.
  admintools:
    additionalVolumes:
      - name: temporal-db-tls
        secret:
          secretName: temporal-db-tls
    additionalVolumeMounts:
      - name: temporal-db-tls
        mountPath: /etc/temporal/tls
        readOnly: true

注意

caFile / certFile / keyFile 是容器内的路径，因此它们只存在于你挂载 Secret 的地方 —— 而且必须在 server 和 admintools 两处都挂载。运行中的 Temporal server pod 读的是 server.additionalVolumes，但建库与应用迁移的 schema 安装/更新 Job 跑的是 admin-tools 镜像、读的是 admintools.additionalVolumes。只挂 server 是最常见的失败：schema Job 无法经 TLS 连上数据库，于是一次全新安装在 helm --wait 上一直挂着、永远等不到完成。

把 serverName 设为你数据库服务端证书里的域名（它的 SAN），并在生产环境保持 enableHostVerification: true —— 只有在对着自签证书测试时才关闭主机校验。

完整配置参考

最新、最全的配置项请直接参见我们的 Helm 仓库：

完整的 values.yaml 参考 —— 带详细注释的全部配置项
外部依赖示例 —— 外部依赖的一份完整可用示例
Helm chart 文档 —— 由 chart 生成、含所有配置参数的文档

提示

Helm 仓库是配置问题的权威来源。它始终与最新的 chart 版本同步，并带有可用示例与测试。

索引

数据加载

查询

存储

成本分析

应用

聊天机器人

问答

结构化数据

智能体

Chat Engines

Query Engine

连接器

文档与节点

摄取流水线

节点解析器

大语言模型

提示词

回调

节点后处理器

响应合成器

检索器

路由

结构化输出

现有数据

Presets and Modes

能力

起步

能力

Examples

Azure Deployment

Databases and Queues

LLM Integrations

要求