生产环境与验证环境——配置差异、资源设计、安全增强实用指南

仅仅因为您可以在测试环境中运行 Dify Enterprise 并不意味着您可以直接将其用于生产。验证环境和生产环境的区别不仅仅是用户数量的增加，而是可用性、可观察性、恢复能力的基本风险模型不同。

Dify Enterprise 官方文档（Resources Checklist）明确规定了两类推荐规范：测试部署和生产部署。验证环境仅需要 1 个工作节点、4 个 CPU/16 GB RAM，但生产环境需要 6 个工作节点、每个工作节点 8 个 CPU/32 GB RAM，并且 PostgreSQL、Redis 和 Qdrant 必须在集群配置中运行。也就是说，官方定义的“验证”和“生产”是完全不同的风险模型。

在本文中，我们将根据资源、持久性、日志、安全性和备份这五个轴来整理日本企业的企业 IT 团队在将 Dify Enterprise 部署到生产环境时应记住的配置差异。

1. 资源规模的差异

1.1 官方推荐规格对比

1.2 Kubernetes资源定义概念

在验证环境中，无需指定 resources.requests / resources.limits 即可工作，但在生产中必须定义它。以下为实际生产参考值。

# values.yaml -- 本番環境向け API サーバーのリソース例
api:
  replicas: 3
  resources:
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "8Gi"

worker:
  replicas: 3
  resources:
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "8Gi"

web:
  replicas: 2
  resources:
    requests:
      cpu: "500m"
      memory: "1Gi"
    limits:
      cpu: "1"
      memory: "2Gi"

sandbox:
  replicas: 2
  resources:
    requests:
      cpu: "500m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"

1.3 副本数量的设计准则

要点：阿里云ACK最佳实践文章中也明确推荐生产环境中API/Worker/Web/Sandbox的多副本部署。

2. 持久性的差异

2.1 验证环境

验证环境中，emptyDir或者Node本地存储没有问题。目的是验证功能，不要求数据持久性。

# 検証環境 -- 永続化を最小限に
persistence:
  enabled: false

2.2 生产环境

在生产中，将以下所有内容连接到外部持久存储。

# 本番環境 -- 外部依存の明示
externalPostgres:
  enabled: true
  host: "dify-prod-pg.ap-northeast-1.rds.amazonaws.com"
  port: 5432
  username: "dify"
  database: "dify_production"
  existingSecret: "dify-pg-credentials"
  existingSecretPasswordKey: "password"

externalRedis:
  enabled: true
  host: "dify-prod-redis.xxxxx.apne1.cache.amazonaws.com"
  port: 6379
  existingSecret: "dify-redis-credentials"
  existingSecretPasswordKey: "password"

externalS3:
  enabled: true
  bucket: "dify-prod-storage"
  region: "ap-northeast-1"
  existingSecret: "dify-s3-credentials"

2.3 持久性检查表

• PostgreSQL：使用托管数据库（例如 RDS / Cloud SQL）启用自动备份
• Redis：使用托管服务，例如 ElastiCache / Memorystore
• Vector DB (Qdrant)：使用持久卷 (PVC) 或外部集群
• 对象存储：启用 S3 / GCS / Azure Blob 版本控制
• 在 Git 存储库中管理 value.yaml 本身

3.日志级别和可观察性

3.1 验证环境日志设置

在验证环境中，启用DEBUG级别并优先考虑早期问题检测和行为确认。

# 検証環境
env:
  LOG_LEVEL: "DEBUG"

3.2 生产环境日志设置

如果在生产中始终启用 DEBUG，日志量将会爆炸，从而增加存储成本和噪音。通常，应将其设置为 WARNING 或更高，并在必要时暂时降低为 INFO。

# 本番環境
env:
  LOG_LEVEL: "WARNING"

3.3 生产过程中需要收集的日志类别

3.4 可观测性栈推荐配置

graph LR
    A[Dify Pods] -->|stdout/stderr| B[Fluentd / Fluent Bit]
    B --> C[Elasticsearch / OpenSearch]
    C --> D[Kibana / Grafana]
    A -->|metrics| E[Prometheus]
    E --> D
    A -->|traces| F[Jaeger / Tempo]
    F --> D

在生产环境中，至少安装Metrics（Prometheus）和日志聚合（Fluentd + Elasticsearch）。创建一个可视化工作流执行延迟和错误率的仪表板将大大改善对故障的初始响应。

4. 增强安全性

4.1 秘密管理

在验证环境中，我倾向于按原样使用默认的 Secret 值，但在生产中我肯定会更改它。

# 本番環境 -- 必ず変更すべき Secret
api:
  secretKey: ""  # 外部 Secret Manager から注入
  innerApiKey: ""  # 同上

# Kubernetes Secret で管理する例
# kubectl create secret generic dify-secrets \
#   --from-literal=SECRET_KEY=$(openssl rand -hex 32) \
#   --from-literal=INNER_API_KEY=$(openssl rand -hex 32)

4.2 网络政策

由于沙箱容器执行用户提交的代码，因此在生产中使用NetworkPolicy严格限制外部通信。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sandbox-restrict
spec:
  podSelector:
    matchLabels:
      app: dify-sandbox
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: dify-api
      ports:
        - port: 5001
    # 外部インターネットへの通信はブロック

4.3 入口 TLS

ingress:
  enabled: true
  className: "nginx"
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
  tls:
    - secretName: dify-tls
      hosts:
        - console.dify.example.co.jp
        - api.dify.example.co.jp
  hosts:
    - host: console.dify.example.co.jp
      paths:
        - path: /
          pathType: Prefix

4.4 安全检查表

5. 备份策略

5.1 验证环境

在验证环境中，备份频率可能较低。重点放在重建环境的便利性上。

5.2 生产环境备份设计

5.3 执行恢复测试

仅仅进行备份是不够的。建议至少每季度进行一次以下恢复测试。

1.从PostgreSQL快照恢复新实例并检查Dify是否正常启动 2.验证回滚到特定版本的对象存储 3.使用Velero检查整个集群恢复过程 4. 验证恢复时间 (RTO) 和恢复点 (RPO) 是否满足 SLA 要求

6.环境隔离的最佳实践

6.1 推荐配置

graph TB
    subgraph "本番クラスタ"
        A[namespace: dify-production]
    end
    subgraph "ステージングクラスタ"
        B[namespace: dify-staging]
    end
    subgraph "検証クラスタ"
        C[namespace: dify-testing]
    end
    D[GitOps リポジトリ] --> A
    D --> B
    D --> C

6.2 按环境管理values.yaml

helm-values/
  base/
    values.yaml          # 共通パラメータ
  overlays/
    testing/
      values.yaml        # 検証固有の上書き
    staging/
      values.yaml        # ステージング固有の上書き
    production/
      values.yaml        # 本番固有の上書き

每个环境的values.yaml 都像Kustomize 一样继承基础，并且仅覆盖特定于环境的差异。这可以防止验证和生产之间的配置偏差。

6.3 各个环境的许可证管理

Dify Enterprise 许可证与 Kubernetes 命名空间绑定，因此每个环境都需要单独的许可证。关于License账本管理，请参考《04-License-管理实践》一文。

7. 总结 – 生产迁移清单

上线前请检查以下内容。

• 已为所有组件设置资源定义（CPU/内存请求/限制）
• 副本数量满足可用性要求（API/Worker为3个及以上）
• PostgreSQL/Redis/对象存储连接到外部托管服务
• 所有秘密均已替换为随机生成的值。
• TLS 终止已配置
• 应用沙盒网络策略
• 日志级别已设置为 WARNING 或更高
• 日志聚合基础设施（Fluentd + Elasticsearch等）正在运行
• 备份是自动的并且经过恢复测试
• [ ]values.yaml 由 Git 管理
• 许可证已在生产命名空间中激活
• 已在临时环境中进行了相当于生产的负载测试。

验证环境是“检查某些东西是否有效的地方”，而生产环境是“承诺服务的地方”。尽管两者应该共享相同的部署方法，但风险假设却有根本的不同。明确反映这种配置差异是 Dify Enterprise 稳定运行的第一步。