这是本节的多页打印视图。 .

返回本页常规视图.

应用

基于 Pigsty 的应用模板与数据应用说明：使用 Docker Compose 拉起无状态应用，并将状态托管到外部 PostgreSQL / S3 兼容存储。

Pigsty 的“应用”分为两类：

  • 软件模板（Software Templates）：~/pigsty/app/<name> 下的 Docker Compose 模板，用于拉起无状态业务组件。
  • 数据应用（Applets）：基于 PostgreSQL + Grafana 的分析样例，偏教学/演示属性。

应用模型

推荐使用以下流程部署应用：

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap
./configure -c <template>     # 例如 app/dify、app/immich、app/jumpserver、app/maybe、supabase
vi pigsty.yml                 # 修改密码、域名、IP、密钥
./deploy.yml                  # 部署基础设施与数据库
./docker.yml                  # 安装 Docker
./app.yml                     # 拉起应用

app.yml 会将 app/<name> 模板复制到 /opt/<name>，并按 apps.<name>.conf 覆盖 .env，最后执行 docker compose up -d。

维护中的配置模板

当前源码中提供了以下应用配置模板（conf/app/*.yml、conf/supabase.yml 与 conf/app/supa.yml 软链接）：

  • app/dify
  • app/odoo
  • app/teable
  • app/mattermost
  • app/electric
  • app/maybe
  • app/immich
  • app/jumpserver
  • app/registry
  • app/insforge
  • app/hindsight
  • supabase

这些模板开箱即用，且与 ./configure -c ...、./app.yml 工作流保持一致。

轻量 Compose 应用

对于 bytebase、gitea、jupyter、kong、metabase、minio、nocodb、pgadmin、pgweb、postgrest、pg_exporter、wiki 等应用，也可直接使用对应目录下的 Compose 模板。 FerretDB 是 PostgreSQL Mongo 模式 的 Docker APP 协议层，通过 mongo 配置模板配合 docker.yml 与 app.yml 部署。

BASH
cd ~/pigsty/app/<name>
make up

如果你希望统一纳入 Pigsty IaC，可用 app.yml 指定应用目录：

BASH
./app.yml -e app=<name>

关于历史 Applet

pglog、covid、db-engine、sf-survey、cloud、isd 等数据应用保留为参考示例，适合学习数据建模与可视化思路。

它们不再是主线“应用交付”方式；请优先使用上面的软件模板工作流。

1 - Supabase 企业级自建

使用 Pigsty 自托管企业级 supabase，带有监控、高可用、PITR、IaC 以及 575 个 PG 扩展。

Supabase 很好，拥有属于你自己的 supabase 则好上加好。 Pigsty 可以帮助您在自己的服务器上（物理机/虚拟机/云服务器），一键自建企业级 supabase —— 更多扩展，更好性能，更深入的控制，更合算的成本。

截至 2026-08，Supabase 的 官方自托管文档 推荐 Docker，并将其他实现归为社区项目；Pigsty 是独立的社区集成，目前不在该页面的项目列表中。

本教程需要您有 Linux 基础知识，否则建议直接使用 Supabase 云服务或 “Docker Compose” 自建。

简短版本

准备 Linux 系统，执行 Pigsty 标准单机安装 流程，选择 supabase 配置模板，依次执行：

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./configure -c supabase    # 使用 supabase 配置（请在 pigsty.yml 中更改凭据）
vi pigsty.yml              # 编辑域名、密码、密钥...
./deploy.yml               # 标准单机部署 pigsty
./docker.yml -l supabase   # 在 supabase 组安装 docker 模块
./app.yml -l supabase      # 在 supabase 组启动无状态容器（可能较慢）

安装完毕后，使用浏览器访问 8000 端口造访 Supa Studio，用户名 supabase，密码 pigsty。

Supabase

demo/supabase.cast

检查清单

  • 至少一台 2C4G 的服务器；完整 Supabase 栈建议 4C8G 或更高
  • 带有静态内网 IPv4 地址
  • 安装支持的 Linux 发行版
  • 标准安装 Pigsty
  • 修改配置文件，域名，密码，IP 地址
  • 安装 Docker 模块，确保代理/镜像站可用
  • 使用 Pigsty 提供的 app.yml 拉起 Supabase

目录

Supabase是什么？

Supabase 是一个 BaaS （Backend as Service），开源的 Firebase，是 AI Agent 时代最火爆的数据库 + 后端解决方案。 Supabase 对 PostgreSQL 进行了封装，并提供了身份认证，消息传递，边缘函数，对象存储，并基于 PG 数据库模式自动生成 REST API；按需启用 pg_graphql 后，也可以提供 GraphQL API。

Supabase 旨在为开发者提供一条龙式的后端解决方案，减少开发和维护后端基础设施的复杂性。 它能让开发者告别绝大部分后端开发的工作，只需要懂数据库设计与前端即可快速出活！ 开发者只要用 Vibe Coding 糊个前端与数据库模式设计，就可以快速完成一个完整的应用。

目前，Supabase 是 PostgreSQL 开源生态 中人气最高的开源项目之一；截至 2026-08，其 GitHub 仓库 已有超过十万 Star。 Supabase 也提供免费云服务额度；当前 免费计划 包含共享 CPU、500 MB 内存、500 MB 数据库额度与 1 GB 文件存储，具体配额以后续官方页面为准。

为什么要自建？

既然 Supabase 云服务这么香，为什么要自建呢？

最直观的原因是我们在《云数据库是智商税吗？》中提到过的：当数据、计算或可用性需求超出托管服务套餐的适用范围时，成本可能快速增长。 而且在当下，足够可靠的 本地企业级 NVMe SSD 在性价比上与 云端存储 有着三到四个数量级的优势，而自建能更好地利用这一点。

另一个重要的原因是 功能， Supabase 云服务的功能受限 —— 很多强力 PG 扩展因为多租户安全挑战与许可证的原因无法以云服务的形式。 故而尽管 扩展是 PostgreSQL 的核心特色，Supabase 官方当前只承诺 预配置 50 多个扩展，具体清单还会随平台版本变化。 而通过 Pigsty 自建的 Supabase 则提供了多达 575 个开箱即用的 PG 扩展。

此外，自主可控与规避供应商锁定也是自建的重要原因 —— 尽管 Supabase 虽然旨在提供一个无供应商锁定的 Google Firebase 开源替代，但实际上自建高标准企业级的 Supabase 门槛并不低。 Supabase 内置了一系列由他们自己开发维护的 PG 扩展。Supabase 在 2024 年收购了 Oriole 团队，并把 OrioleDB 作为可选 Public Alpha 提供；它不是生产环境默认内核，也不能表述为已计划替换原生 PostgreSQL。部分 Supabase 扩展和带补丁内核不由 PGDG 官方仓库提供。

这实际上是某种隐性的供应商锁定，阻止了用户使用除了 supabase/postgres Docker 镜像之外的方式自建，Pigsty 则提供开源，透明，通用的方案解决这个问题。 我们将 Supabase 自研与用到的 10 个缺失扩展打成开箱即用的 RPM/DEB 包，覆盖当前 supabase 模板声明支持的 Linux 发行版：EL 8/9、Debian 12、Ubuntu 22.04/24.04/26.04，以及 x86_64/aarch64 架构。

扩展说明
pg_graphql提供 PG 内的 GraphQL 支持 (RUST)，Rust 扩展，由 PIGSTY 提供，按需启用
pg_jsonschema提供 JSON Schema 校验能力，Rust 扩展，由 PIGSTY 提供
wrappersSupabase 提供的外部数据源包装器捆绑包，Rust 扩展，由 PIGSTY 提供
index_advisor查询索引建议器，SQL 扩展，由 PIGSTY 提供
pg_net用 SQL 进行异步非阻塞 HTTP/HTTPS 请求的扩展 (supabase)，C 扩展，由 PIGSTY 提供
vault在 Vault 中存储加密凭证的扩展 (supabase)，C 扩展，由 PIGSTY 提供
pgjwtJSON Web Token API 的 PG 实现 (supabase)，SQL 扩展，由 PIGSTY 提供
pgsodium表数据加密存储 TDE，扩展，由 PIGSTY 提供
supautils用于在云环境中确保数据库集群的安全，C 扩展，由 PIGSTY 提供
pg_plan_filter使用执行计划代价过滤阻止特定查询语句，C 扩展，由 PIGSTY 提供

同时，我们在 Supabase 自建部署中默认 安装 绝大多数扩展，您可以参考可用扩展列表按需 启用。 新版模板会安装 pg_graphql 扩展包，但不再默认创建 pg_graphql 扩展对象；如果需要 GraphQL API，可以在目标数据库中执行 CREATE EXTENSION IF NOT EXISTS pg_graphql;，模板中的事件触发器会自动重建 graphql_public.graphql 入口与访问权限。

同时，Pigsty 还会负责好底层 高可用 PostgreSQL 数据库集群，高可用 Silo 对象存储集群的自动搭建，甚至是 Docker 容器底座的部署与 Nginx 反向代 理，域名配置 与 HTTPS证书签发。 您可以使用 Docker Compose 拉起任意数量的无状态 Supabase 容器集群，并将状态存储在外部 Pigsty 自托管数据库服务中。

在这一自建部署架构中，您获得了使用不同内核的自由（当前模板支持 PostgreSQL 15-18，默认 18），加装 575 个扩展的自由，扩容与伸缩 Supabase / Postgres / Silo 的自由， 免于数据库运维杂务的自由，以及免于供应商锁定，本地运行到地老天荒的自由。 而相比于使用云服务需要付出的代价，不过是准备服务器和多敲几行命令而已。

单节点自建快速上手

让我们先从单节点 Supabase 部署开始，我们会在后面进一步介绍多节点高可用部署的方法。

准备 一台全新 Linux 服务器，使用 Pigsty 提供的 supabase 配置模板执行 标准安装， 然后额外运行 docker.yml 与 app.yml 拉起无状态部分的 Supabase 容器即可（默认端口 8000/8443）。

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./configure -c supabase    # 使用 supabase 配置（请在 pigsty.yml 中更改凭据）
vi pigsty.yml              # 编辑域名、密码、密钥...
./deploy.yml               # 安装 pigsty
./docker.yml -l supabase   # 在 supabase 组安装 docker compose 组件
./app.yml -l supabase      # 在 supabase 组启动无状态容器

在部署 Supabase 前请根据实际情况修改自动生成的 pigsty.yml 配置文件中的参数（域名与密码） 如果只是本地开发测试，可以先跳过，我们将在后面介绍如何通过修改配置文件来进一步定制。

如果配置无误，大约十分钟后，就可以在本地网络通过 http://<your_ip_address>:8000 访问到 Supabase Studio 图形管理界面了。 默认的用户名与密码分别是： supabase 与 pigsty。

Supabase

注意事项：

  • 在中国大陆地区，Pigsty 默认使用 1Panel 与 1ms 提供的 DockerHub 镜像站点下载 Supabase 相关镜像，可能会较慢。
  • 你也可以自行配置 代理 与 镜像站，cd /opt/supabase; docker compose pull 手动拉取镜像。我们亦提供包含完整离线安装方案的 Supabase 自建专家咨询服务。
  • 如果你需要使用的对象存储功能，那么需要通过域名与 HTTPS 访问 Supabase，否则会出现报错。
  • 对于严肃的生产部署，请 务必 修改所有默认密码！

自建关键技术决策

以下是一些自建 Supabase 会涉及到的关键技术决策，供您参考：

使用默认的 单节点部署 Supabase 无法享受到 PostgreSQL / Silo 的高可用能力。 尽管如此，单节点部署相比官方纯 Docker Compose 方案依然要有显著优势： 例如开箱即用的监控系统，自由安装扩展的能力，各个组件的扩缩容能力，以及提供兜底数据库时间点恢复能力等。

Pigsty 的 Supabase 模板不启动上游 Compose 中的 db 与 supavisor 容器，也不使用 Supabase 自带连接池。 无状态容器直接通过 Pigsty 管理的 PostgreSQL 服务接入数据库；单节点模板中默认使用 5436 服务端口，它始终路由到当前主库。

模板中的 Logflare / Analytics 不再写入业务库的 postgres._analytics，而是使用独立的 _supabase 数据库与其中的 _analytics 模式。 这样可以避免 oban_jobs、oban_peers 等内部调度表落在项目库的 public 模式中，触发 Supabase Advisor 的 RLS 告警；相关位置由 LOGFLARE_DB 与 LOGFLARE_SCHEMA 控制。

Supabase Studio 的 Query Performance 页面会在 public, extensions 搜索路径下访问 pg_stat_statements。 Pigsty 仍然将 pg_stat_statements 扩展对象保留在 monitor 模式中，以兼容 pg_exporter 与现有监控面板；模板会在 extensions 模式中创建兼容视图与函数，供 Studio 使用。

如果您只有一台服务器，或者选择在云服务器上自建，Pigsty 建议您使用外部的 S3 替代本地的 Silo 作为对象存储，存放 PostgreSQL 的备份，并承载 Supabase Storage 服务。 这样的部署可在单机故障后提供小时级恢复的兜底路径；实际 RPO 取决于最近一次可恢复备份、WAL 归档状态与对象存储可用性，不能仅凭该拓扑承诺固定数值。

在严肃的生产部署中，Pigsty 建议使用至少 3～4 个节点的部署策略，确保 Silo 与 PostgreSQL 都使用满足企业级高可用要求的多节点部署。 在这种情况下，您需要相应准备更多节点与磁盘，并相应调整 pigsty.yml 配置清单中的集群配置，以及 supabase 集群配置中的接入信息，使用高可用接入点访问服务。

Supabase 的部分功能需要发送邮件，所以要用到 SMTP 服务。除非单纯用于内网，否则对于严肃的生产部署，建议使用 SMTP 云服务。自建的邮件服务器发送的邮件容易被标记为垃圾邮件导致拒收。

如果您的服务直接向公网暴露，我们强烈建议您使用真正的域名与 HTTPS 证书，并通过 Nginx 门户 访问。

接下来，我们会依次讨论一些进阶主题。如何在单节点部署的基础上，进一步提升 Supabase 的安全性、可用性与性能。

进阶主题：安全加固

Pigsty 基础组件

对于严肃的生产部署，我们强烈建议您修改 Pigsty 基础组件的密码。因为这些默认值是公开且众所周知的，不改密码上生产无异于裸奔：

以上密码为 Pigsty 组件模块的密码，强烈建议在安装部署前就设置完毕。

Supabase 密钥

除了 Pigsty 组件的密码，你还需要 修改 Supabase 的密钥，包括

这里请您务必参照 Supabase教程：保护你的服务 里的说明：

  • 生成一个长度超过 40 个字符的 JWT_SECRET，并使用教程中的工具签发 ANON_KEY 与 SERVICE_ROLE_KEY 两个 JWT。
  • 使用教程中提供的工具，根据 JWT_SECRET 以及过期时间等属性，生成一个 ANON_KEY JWT，这是匿名用户的身份凭据。
  • 使用教程中提供的工具，根据 JWT_SECRET 以及过期时间等属性，生成一个 SERVICE_ROLE_KEY，这是权限更高服务角色的身份凭据。
  • 如果您使用新版不透明 API Key 或非对称 JWT，请同步生成并填写 SUPABASE_PUBLISHABLE_KEY、SUPABASE_SECRET_KEY、JWT_KEYS、JWT_JWKS 与对应的非对称 ANON_KEY / SERVICE_ROLE_KEY。
  • 指定一个32个字符以上的随机字符串密钥 PG_META_CRYPTO_KEY，用于加密 Studio UI 与 meta 服务的交互
  • SECRET_KEY_BASE 至少 64 个字符；REALTIME_DB_ENC_KEY 必须恰好 16 个字符。
  • 为 S3_PROTOCOL_ACCESS_KEY_ID 与 S3_PROTOCOL_ACCESS_KEY_SECRET 生成独立随机凭据，不要复用对象存储管理员密码。
  • 如果您使用的 PostgreSQL 业务用户使用了不同于默认值的密码，请相应修改 POSTGRES_PASSWORD 的值
  • 如果您的对象存储使用了不同于默认值的密码，请相应修改 S3_ACCESS_KEY 与 S3_SECRET_KEY 的值
  • 如果您将 Edge Functions 暴露给不可信客户端，请按需将 FUNCTIONS_VERIFY_JWT 改为 true。
  • API_EXTERNAL_URL 现在应填写 Auth 服务的外部 URL，保留 /auth/v1 后缀，例如 https://supa.pigsty.cc/auth/v1；SITE_URL 与 SUPABASE_PUBLIC_URL 保持站点根 URL。
  • 当前模板的 PGRST_DB_SCHEMAS 默认为 public,graphql_public；storage 模式由 Storage API 使用，不再通过 PostgREST 默认暴露。

Supabase 部分的凭据修改后，您可以重启 Docker Compose 容器以应用新的配置：

BASH
./app.yml -l supabase -t app_config,app_launch   # 使用剧本
cd /opt/supabase; make up            # 手工执行

进阶主题：域名接入

如果你在本机或局域网内使用 Supabase，那么可以选择 IP:Port 直连 Kong 对外暴露的 HTTP 8000 端口访问 Supabase。

你可以使用一个内网静态解析的域名，但对于严肃的生产部署，我们建议您使用真域名 + HTTPS 来访问 Supabase。 在这种情况下，您的服务器应当有一个公网 IP 地址，你应当拥有一个域名，使用云/DNS/CDN 供应商提供的 DNS 解析服务，将其指向安装节点的公网 IP（可选默认下位替代：本地 /etc/hosts 静态解析）。

比较简单的做法是，直接批量替换占位域名（supa.pigsty）为你的实际域名，假设为 supa.pigsty.cc：

BASH
sed -ie 's/supa.pigsty/supa.pigsty.cc/g' ~/pigsty/pigsty.yml

如果你没有事先配置好，那么重载 Nginx 和 Supabase 的配置生效即可：

BASH
make cert       # 申请 certbot 免费 HTTPS 证书
./app.yml -l supabase -t app_config,app_launch  # 重载 Supabase 配置

修改后的配置应当类似下面的片段：

YAML
all:
  vars:
    certbot_sign: true                # 使用 certbot 签发真实证书
    infra_portal:
      home: { domain: i.pigsty.cc }   # 替换为你的域名！
      supa:
        domain: supa.pigsty.cc        # 替换为你的域名！
        endpoint: "10.10.10.10:8000"
        websocket: true
        certbot: supa.pigsty.cc       # 证书名称，通常与域名一致即可

  children:
    supabase:
      vars:
        apps:
          supabase:                                         # supabase 应用定义
            conf:                                           # 覆盖 /opt/supabase/.env
              SITE_URL: https://supa.pigsty.cc              # <------- 修改为您的外部域名
              API_EXTERNAL_URL: https://supa.pigsty.cc/auth/v1 # <--- Auth 服务外部 URL，保留 /auth/v1
              SUPABASE_PUBLIC_URL: https://supa.pigsty.cc   # <------- 别忘了在 infra_portal 中配置！

完整的域名/HTTPS 配置可以参考 证书管理 教程，您也可以使用 Pigsty 自带的本地静态解析与自签发 HTTPS 证书作为下位替代。

进阶主题：外部对象存储

您可以使用 S3 或 S3 兼容的服务，来作为 PGSQL 备份与 Supabase 使用的对象存储。这里我们使用一个 阿里云 OSS 对象存储作为例子。

Pigsty 提供了一个 terraform/spec/aliyun-s3.tf 模板， 可以用于在阿里云上拉起一台服务器，以及一个 OSS 存储桶。

首先，修改 all.children.supabase.vars.apps.supabase.conf 中 S3 相关的配置，将其指向阿里云 OSS 存储桶：

YAML
# if using s3/minio as file storage
S3_BUCKET: pigsty-supa                     # 兼容旧模板，与 GLOBAL_S3_BUCKET 保持一致
GLOBAL_S3_BUCKET: pigsty-supa              # Supabase Storage 实际使用的 bucket
S3_ENDPOINT: https://oss-cn-beijing.aliyuncs.com
S3_ACCESS_KEY: <your_access_key>
S3_SECRET_KEY: <your_secret_key>
S3_FORCE_PATH_STYLE: false                 # 阿里云 OSS 使用 host-style URI
S3_PROTOCOL: https
S3_REGION: oss-cn-beijing                  # 兼容旧模板，与 REGION 保持一致
REGION: oss-cn-beijing                     # Supabase Storage 实际使用的 region
STORAGE_TENANT_ID: pigsty                  # Supabase Storage tenant id
S3_PROTOCOL_ACCESS_KEY_ID: <independent_access_key>
S3_PROTOCOL_ACCESS_KEY_SECRET: <independent_secret_key>

同样使用以下命令重载 Supabase 配置：

BASH
./app.yml -l supabase -t app_config,app_launch

您同样可以使用 S3 作为 PostgreSQL 的备份仓库，在 all.vars.pgbackrest_repo 新增一个 aliyun 备份仓库的定义：

YAML
all:
  vars:
    pgbackrest_method: aliyun          # pgBackRest 备份方法：local、minio 或其他自定义仓库；本例使用阿里云 OSS
    pgbackrest_repo:                   # pgbackrest 备份仓库: https://pgbackrest.org/configuration.html#section-repository
      aliyun:                          # 定义一个新的备份仓库 aliyun
        type: s3                       # 阿里云 oss 是 s3-兼容的对象存储
        s3_endpoint: oss-cn-beijing-internal.aliyuncs.com
        s3_region: oss-cn-beijing
        s3_bucket: pigsty-oss
        s3_key: xxxxxxxxxxxxxx
        s3_key_secret: xxxxxxxx
        s3_uri_style: host
        path: /pgbackrest
        bundle: y                         # bundle small files into a single file
        bundle_limit: 20MiB               # Limit for file bundles, 20MiB for object storage
        bundle_size: 128MiB               # Target size for file bundles, 128MiB for object storage
        cipher_type: aes-256-cbc          # enable AES encryption for remote backup repo
        cipher_pass: pgBackRest.MyPass    # 设置一个加密密码，pgBackRest 备份仓库的加密密码
        retention_full_type: time         # retain full backups by time in this S3 repository
        retention_full: 14                # keep full backup for the last 14 days

然后在 all.vars.pgbackrest_method 中指定 aliyun。先核对现有备份，再在明确授权后对目标集群重新渲染 pgBackRest 配置、初始化 stanza，并立即建立新的全量恢复点：

BASH
pig pb info
./pgsql.yml -t pg_backup -l pg-meta
pg-backup full

旧仓库中的备份不会自动迁移；新仓库首次全量备份成功前存在恢复窗口缺口。完整步骤与注意事项见 PostgreSQL 备份仓库。

进阶主题：使用SMTP

你可以使用 SMTP 来发送邮件，修改 supabase 应用配置，添加 SMTP 信息：

YAML
all:
  children:
    supabase:        # supa group
      vars:          # supa group vars
        apps:        # supa group app list
          supabase:  # the supabase app
            conf:    # the supabase app conf entries
              SMTP_HOST: smtpdm.aliyun.com
              SMTP_PORT: 80
              SMTP_USER: no_reply@mail.your.domain.com
              SMTP_PASS: your_email_user_password
              SMTP_SENDER_NAME: MySupabase
              SMTP_ADMIN_EMAIL: adminxxx@mail.your.domain.com
              ENABLE_ANONYMOUS_USERS: false

不要忘了使用 ./app.yml -l supabase -t app_config,app_launch 重载配置。

进阶主题：真·高可用

经过这些配置，您拥有了一个带公网域名，HTTPS 证书，SMTP，PITR 备份，监控，IaC，以及 575 个扩展的企业级 Supabase （基础单机版）。 高可用的配置请参考 Pigsty 其他部份的文档，如果您懒得阅读学习，我们提供手把手扶上马的 Supabase 自建专家咨询服务 —— ¥2000 元免去折腾与下载的烦恼。

单节点的 RTO / RPO 依赖外部对象存储服务提供兜底，如果您的这个节点挂了，外部 S3 存储中保留了备份，您可以在新的节点上重新部署 Supabase，然后从备份中恢复。 这种拓扑可以提供小时级恢复的 兜底路径，但 RPO 取决于备份与 WAL 归档的实际状态，必须通过恢复演练验证，不能用“MB 级”作为固定承诺。

若目标是 RTO < 30s 且已确认事务在切换时不丢失，需要使用多节点，并显式选择 fast RTO 预设与 crit.yml 严格同步策略后进行故障演练；默认 norm 预设的目标是 RTO < 45s，异步复制不承诺 RPO=0。这涉及到：

  • ETCD： DCS 需要使用三个节点或以上，才能容忍一个节点的故障。
  • PGSQL： PGSQL 同步提交不丢数据模式，建议使用至少三个节点。
  • INFRA：监控基础设施故障影响稍小，建议生产环境使用双副本
  • Supabase 无状态容器本身也可以是多节点的副本，可以实现高可用。

在这种情况下，您还需要修改 PostgreSQL 与 Silo 的接入点，使用 DNS / L2 VIP / HAProxy 等 高可用接入点 关于这些部分，您只需参考 Pigsty 中各个模块的文档进行配置部署即可。 建议您参考 conf/ha/trio.yml 与 conf/ha/safe.yml 中的配置，将集群规模升级到三节点或以上。

2 - Odoo：自建开源 ERP

如何拉起开箱即用的企业级应用全家桶 Odoo，并使用 Pigsty 管理其后端 PostgreSQL 数据库。

Odoo 是一个开源企业资源规划 (ERP) 软件，提供一整套业务应用程序，包括 CRM、销售、采购、库存、生产、会计和其他管理功能。Odoo 是一个典型的 Web 应用程序，使用 PostgreSQL 作为底层数据库。

您的所有业务，都在一个平台上，简单、高效且实惠

公开演示（不一定开放）：http://odoo.pigsty.io, 用户名: test@pigsty.io, 密码: pigsty

快速开始

在运行兼容操作系统的全新 Linux x86 / ARM 服务器上执行：

BASH
curl -fsSL https://repo.pigsty.io/get | bash; cd ~/pigsty
./bootstrap                # 安装 ansible
./configure -c app/odoo    # 使用 odoo 配置（请在 pigsty.yml 中更改凭据）
./deploy.yml               # 安装 pigsty
./docker.yml               # 安装 docker compose
./app.yml                  # 使用 docker 启动 odoo 无状态部分

Odoo 默认监听在 8069 端口，您可以通过浏览器访问 http://<ip>:8069。默认的用户名和密码都是 admin。

您可以在浏览器所在主机（/etc/hosts）添加一条解析记录 odoo.pigsty 指向您的服务器，这样您就可以通过 http://odoo.pigsty 访问 Odoo 网络界面了。

如果您想要通过 SSL/HTTPS 访问 Odoo，您需要使用真正的 SSL 证书，或者信任 Pigsty 自动生成的自签名 CA 证书。（当然，在 Chrome 浏览器中，您也可以使用敲击键入 thisisunsafe 来绕过证书验证）

配置模板

conf/app/odoo.yml 定义了一个模板配置文件，包含单个 Odoo 实例所需的资源。

YAML
all:
  children:

    # Odoo 应用程序（默认用户名和密码：admin/admin）
    odoo:
      hosts: { 10.10.10.10: {} }
      vars:
        app: odoo   # 指定要安装的应用程序名称（在 apps 中）
        apps:       # 定义所有应用程序
          odoo:     # 应用程序名称，应该有对应的 ~/pigsty/app/odoo 文件夹
            file:   # 要创建的可选目录
              - { path: /data/odoo         ,state: directory, owner: 100, group: 101 }
              - { path: /data/odoo/webdata ,state: directory, owner: 100, group: 101 }
              - { path: /data/odoo/addons  ,state: directory, owner: 100, group: 101 }
            conf:   # 覆盖 /opt/<app>/.env 配置文件
              PG_HOST: 10.10.10.10            # postgres 主机
              PG_PORT: 5432                   # postgres 端口
              PG_USERNAME: odoo               # postgres 用户
              PG_PASSWORD: DBUser.Odoo        # postgres 密码
              ODOO_PORT: 8069                 # odoo 应用程序端口
              ODOO_DATA: /data/odoo/webdata   # odoo webdata
              ODOO_ADDONS: /data/odoo/addons  # odoo 插件
              ODOO_DBNAME: odoo               # odoo 数据库名称
              ODOO_VERSION: 19.0              # odoo 镜像版本

    # Odoo 数据库
    pg-odoo:
      hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } }
      vars:
        pg_cluster: pg-odoo
        pg_users:
          - { name: odoo    ,password: DBUser.Odoo ,pgbouncer: true ,roles: [ dbrole_admin ] ,createdb: true ,comment: admin user for odoo service }
          - { name: odoo_ro ,password: DBUser.Odoo ,pgbouncer: true ,roles: [ dbrole_readonly ]  ,comment: read only user for odoo service  }
          - { name: odoo_rw ,password: DBUser.Odoo ,pgbouncer: true ,roles: [ dbrole_readwrite ] ,comment: read write user for odoo service }
        pg_databases:
          - { name: odoo ,owner: odoo ,revokeconn: true ,comment: odoo main database  }
        pg_hba_rules:
          - { user: all ,db: all ,addr: 172.17.0.0/16  ,auth: pwd ,title: 'allow access from local docker network' }
          - { user: dbuser_view , db: all ,addr: infra ,auth: pwd ,title: 'allow grafana dashboard access cmdb from infra nodes' }
        pg_crontab: [ '00 01 * * * /pg/bin/pg-backup full' ] # 每天凌晨 1 点进行完整备份

    infra: { hosts: { 10.10.10.10: { infra_seq: 1 } } }
    etcd:  { hosts: { 10.10.10.10: { etcd_seq: 1 } }, vars: { etcd_cluster: etcd } }
    #minio: { hosts: { 10.10.10.10: { minio_seq: 1 } }, vars: { minio_cluster: minio } }

  vars:                               # 全局变量
    admin_ip: 10.10.10.10             # 管理节点 ip 地址
    region: default                   # 上游镜像区域：default|china|europe
    node_tune: oltp                   # 节点调优规格：oltp,olap,tiny,crit
    pg_conf: oltp.yml                 # pgsql 调优规格：{oltp,olap,tiny,crit}.yml

    docker_enabled: true              # 在应用程序组上启用 docker
    #docker_registry_mirrors: ["https://docker.1panel.live","https://docker.1ms.run","https://docker.xuanyuan.me","https://registry-1.docker.io"]

    proxy_env:                        # 下载包和拉取 docker 镜像时的全局代理环境
      no_proxy: "localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16,*.pigsty,*.aliyun.com,mirrors.*,*.tsinghua.edu.cn"
      #http_proxy:  127.0.0.1:12345   # 在此处添加代理环境以下载包或拉取镜像
      #https_proxy: 127.0.0.1:12345   # 通常代理格式为 http://user:pass@proxy.xxx.com
      #all_proxy:   127.0.0.1:12345

    infra_portal:                      # 域名和上游服务器
      home  : { domain: i.pigsty }
      minio : { domain: m.pigsty ,endpoint: "${admin_ip}:9001" ,scheme: https ,websocket: true }
      odoo:                            # nginx server config for odoo
        domain: odoo.pigsty            # 替换为您自己的域名！
        endpoint: "10.10.10.10:8069"   # odoo 服务端点：IP:PORT
        websocket: true                # 添加 websocket 支持
        certbot: odoo.pigsty           # certbot 证书名称，使用 `make cert` 申请

    repo_enabled: false
    node_repo_modules: node,infra,pgsql
    pg_version: 18

    #----------------------------------#
    # 凭据：务必更改这些密码！
    #----------------------------------#
    grafana_admin_password: pigsty
    grafana_view_password: DBUser.Viewer
    pg_admin_password: DBUser.DBA
    pg_monitor_password: DBUser.Monitor
    pg_replication_password: DBUser.Replicator
    patroni_password: Patroni.API
    haproxy_admin_password: pigsty
    minio_secret_key: S3User.MinIO
    etcd_root_password: Etcd.Root

基础

检查 .env 文件中的可配置环境变量：

BASH
# https://hub.docker.com/_/odoo#
PG_HOST=10.10.10.10
PG_PORT=5432
PG_USER=dbuser_odoo
PG_PASS=DBUser.Odoo
ODOO_PORT=8069

然后使用以下命令启动 odoo：

BASH
make up  # docker compose up

访问 http://ddl.pigsty 或 http://10.10.10.10:8887

Makefile

BASH
make up         # 在最小模式下使用 docker compose 启动 odoo
make run        # 使用 docker 启动 odoo，本地数据目录和外部 PostgreSQL
make view       # 打印 odoo 访问点
make log        # tail -f odoo 日志
make info       # 使用 jq 检查 odoo
make stop       # 停止 odoo 容器
make clean      # 移除 odoo 容器
make pull       # 拉取最新的 odoo 镜像
make rmi        # 移除 odoo 镜像
make save       # 保存 odoo 镜像到 /tmp/docker/odoo.tgz
make load       # 从 /tmp/docker/odoo.tgz 加载 odoo 镜像

使用外部 PostgreSQL

您可以为 Odoo 使用外部 PostgreSQL。Odoo 将在设置期间创建自己的数据库，因此您不需要这样做

YAML
pg_users: [ { name: dbuser_odoo ,password: DBUser.Odoo ,pgbouncer: true ,roles: [ dbrole_admin ]    ,comment: admin user for odoo database } ]
pg_databases: [ { name: odoo ,owner: dbuser_odoo ,revokeconn: true ,comment: odoo primary database } ]

并使用以下命令创建业务用户和数据库：

BASH
bin/pgsql-user  pg-meta  dbuser_odoo
#bin/pgsql-db    pg-meta  odoo     # odoo 将在设置期间创建数据库

检查连接性：

BASH
psql postgres://dbuser_odoo:DBUser.Odoo@10.10.10.10:5432/odoo

暴露 Odoo 服务

通过 nginx 门户 暴露 odoo Web 服务：

YAML
    infra_portal:                     # 域名和上游服务器
      home         : { domain: i.pigsty }
      grafana      : { domain: g.pigsty    ,endpoint: "${admin_ip}:3000" , websocket: true }
      vmetrics     : { domain: v.pigsty    ,endpoint: "${admin_ip}:8428" }
      alertmanager : { domain: a.pigsty    ,endpoint: "${admin_ip}:9059" }
      blackbox     : { endpoint: "${admin_ip}:9115" }
      vlogs        : { endpoint: "${admin_ip}:9428" }
      odoo         : { domain: odoo.pigsty, endpoint: "127.0.0.1:8069", websocket: true }  # <------ 添加这一行
BASH
./infra.yml -t nginx   # 设置 nginx 基础设施门户

Odoo 插件

社区中有很多 Odoo 模块可用，您可以通过下载并将它们放在 addons 文件夹中来安装它们。

YAML
volumes:
  - ./addons:/mnt/extra-addons

您可以将 ./addons 目录挂载到容器中的 /mnt/extra-addons，然后下载并解压到 addons 文件夹，

要启用插件模块，首先进入 开发者模式

设置 -> 通用设置 -> 开发者工具 -> 激活开发者模式

然后转到 > 应用程序 -> 更新应用程序列表，然后您可以找到额外的插件并从面板安装。

常用的 免费 插件：会计套件

演示

查看公共演示：http://odoo.pigsty.io，用户名：test@pigsty.io，密码：pigsty

如果您想通过 SSL 访问 odoo，您必须在浏览器中信任 files/pki/ca/ca.crt（或在 chrome 中使用肮脏的黑客 thisisunsafe）

3 - Dify：AI 工作流平台

如何使用 Pigsty 自建 AI Workflow LLMOps 平台 —— Dify，并使用外部 PostgreSQL，PGVector，Redis 作为存储？

Dify 是一个生成式 AI 应用创新引擎和开源 LLM 应用开发平台。它提供从 Agent 构建到 AI 工作流编排、RAG 检索和模型管理的能力，帮助用户轻松构建和运营生成式 AI 原生应用程序。

Pigsty 提供对自托管 Dify 的支持，允许您使用单个命令部署 Dify，同时将关键状态存储在外部管理的 PostgreSQL 中。您可以在同一个 PostgreSQL 实例中使用 pgvector 作为向量数据库，进一步简化部署。

app/dify 模板最后验证的 Dify 版本：v1.15.0（2026-07-09）。模板包含一份针对 PostgreSQL 18 内置 uuidv7() 的 Dify 迁移脚本兼容补丁。

快速开始

在运行 兼容操作系统 的全新 Linux x86 / ARM 服务器上执行：

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap                # 安装 Pigsty 依赖
./configure -c app/dify    # 使用 Dify 配置模板
vi pigsty.yml              # 编辑密码、域名、密钥等

./deploy.yml               # 安装 Pigsty
./docker.yml               # 安装 Docker 和 Compose
./app.yml                  # 安装 Dify

Dify 默认监听端口 5001。您可以通过浏览器访问 http://<ip>:5001 并设置您的初始用户凭据来登录。

Dify 启动后，您可以安装各种扩展、配置系统模型并开始使用它！

为什么要自托管

自托管 Dify 有很多原因，但主要动机是数据安全。Dify 提供的 DockerCompose 模板使用基本的默认数据库镜像，缺乏企业级功能，如高可用性、灾难恢复、监控、IaC 和 PITR 能力。

Pigsty 为 Dify 提供声明式部署，并可使用镜像解决中国地区的镜像访问问题。模板将 PostgreSQL 与 pgvector 交给 Pigsty 管理， 部署 Compose Redis、VictoriaMetrics/Grafana 监控与 Nginx 反向代理；满足公网 DNS、端口和 Certbot 配置后，还可申请 Let’s Encrypt 证书。 文件默认保存到 DIFY_DATA（/data/dify），也可按需接入 Silo/S3 对象存储。

当前模板把 PostgreSQL/pgvector 放在 Pigsty 管理的外部数据库中，并把 API 文件与插件数据定向到 DIFY_DATA（默认 /data/dify）。但 Compose 内置 Redis 的数据仍位于 /opt/dify/volumes/redis/data，Sandbox 依赖与 Certbot 数据也位于 /opt/dify/volumes/，因此整套应用并非完全无状态，备份时不能只保留数据库。

安装

让我们从单节点 Dify 部署开始。我们稍后将介绍生产高可用部署方法。

首先，使用 Pigsty 的 标准安装过程 安装 Dify 所需的 PostgreSQL 实例：

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap               # 准备 Pigsty 依赖
./configure -c app/dify   # 使用 Dify 应用程序模板
vi pigsty.yml             # 编辑配置文件，修改域名和密码
./deploy.yml              # 安装 Pigsty 和各种数据库

当您使用 ./configure -c app/dify 命令时，Pigsty 会根据 conf/app/dify.yml 模板和您当前的环境自动生成配置文件。 您应该根据实际需要在生成的 pigsty.yml 配置文件中修改密码、域名和其他相关参数，然后使用 ./deploy.yml 执行标准安装过程。

接下来，运行 docker.yml 安装 Docker 和 Docker Compose，然后使用 app.yml 完成 Dify 部署：

BASH
./docker.yml -l dify      # 在 Dify 节点安装 Docker 和 Docker Compose
./app.yml -l dify         # 使用 Docker 部署 Dify 应用组件

您可以在本地网络上通过 http://<your_ip_address>:5001 访问 Dify Web 管理界面。

首次登录时会提示设置默认用户名、邮箱和密码。

您也可以使用本地解析的占位符域名 dify.pigsty，或按照下面的配置使用带有 HTTPS 证书的真实域名。

配置

当您使用 ./configure -c app/dify 命令进行配置时，Pigsty 会根据 conf/app/dify.yml 模板和当前环境生成配置文件。以下快照与 v4.5.0 源模板同步：

---
#==============================================================#
# File      :   dify.yml
# Desc      :   pigsty config for running 1-node dify app
# Ctime     :   2025-02-24
# Mtime     :   2026-07-09
# Docs      :   https://pigsty.io/docs/app/dify
# License   :   Apache-2.0 @ https://pigsty.io/docs/about/license/
# Copyright :   2018-2026  Ruohang Feng / Vonng (rh@vonng.com)
#==============================================================#
# Last Verified Dify Version: v1.15.0 on 2026-07-09
# tutorial: https://pigsty.io/docs/app/dify
# how to use this template:
#
#  curl -fsSL https://repo.pigsty.io/get | bash; cd ~/pigsty
# ./bootstrap               # prepare local repo & ansible
# ./configure -c app/dify   # use this dify config template
# vi pigsty.yml             # IMPORTANT: CHANGE CREDENTIALS!!
# ./deploy.yml              # install pigsty & pgsql
# ./docker.yml              # install docker & docker-compose
# ./app.yml                 # install dify with docker-compose
#
# To replace domain name:
#   sed -ie 's/dify.pigsty/dify.pigsty.cc/g' pigsty.yml


all:
  children:

    # the dify application
    dify:
      hosts: { 10.10.10.10: {} }
      vars:
        app: dify   # specify app name to be installed (in the apps)
        apps:       # define all applications
          dify:     # app name, should have corresponding ~/pigsty/app/dify folder
            file:   # data directory to be created
              - { path: /data/dify ,state: directory ,mode: 0755 }
            conf:   # override /opt/dify/.env config file

              # change domain, mirror, proxy, secret key
              NGINX_SERVER_NAME: dify.pigsty
              # A secret key for signing and encryption, gen with `openssl rand -base64 42` (CHANGE PASSWORD!)
              SECRET_KEY: sk-somerandomkey
              # expose DIFY nginx service with port 5001 by default
              DIFY_PORT: 5001
              # where to store dify files? the default is ./volume, we'll use another volume created above
              DIFY_DATA: /data/dify
              # enable the upstream websocket sidecar, while keeping PostgreSQL/pgvector external
              COMPOSE_PROFILES: collaboration
              NEXT_PUBLIC_SOCKET_URL: ws://dify.pigsty
              TRIGGER_URL: http://dify.pigsty
              ENDPOINT_URL_TEMPLATE: http://dify.pigsty/e/{hook_id}

              # proxy and mirror settings
              #PIP_MIRROR_URL: https://pypi.tuna.tsinghua.edu.cn/simple
              #SANDBOX_HTTP_PROXY: http://10.10.10.10:12345
              #SANDBOX_HTTPS_PROXY: http://10.10.10.10:12345

              # database credentials
              DB_TYPE: postgresql
              DB_USERNAME: dify
              DB_PASSWORD: difyai123456
              DB_HOST: 10.10.10.10
              DB_PORT: 5432
              DB_DATABASE: dify
              DB_SSL_MODE: disable
              VECTOR_STORE: pgvector
              PGVECTOR_HOST: 10.10.10.10
              PGVECTOR_PORT: 5432
              PGVECTOR_USER: dify
              PGVECTOR_PASSWORD: difyai123456
              PGVECTOR_DATABASE: dify
              PGVECTOR_MIN_CONNECTION: 2
              PGVECTOR_MAX_CONNECTION: 10

              # optional MinIO/S3 storage, disabled by default to avoid touching backup MinIO
              #STORAGE_TYPE: s3
              #S3_ENDPOINT: http://10.10.10.10:9000
              #S3_BUCKET_NAME: dify
              #S3_ACCESS_KEY: dify
              #S3_SECRET_KEY: S3User.Dify
              #S3_REGION: us-east-1
              #S3_ADDRESS_STYLE: path

    pg-meta:
      hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } }
      vars:
        pg_cluster: pg-meta
        pg_extensions: [ pgvector ]
        pg_users:
          - { name: dify ,password: difyai123456 ,pgbouncer: true ,roles: [ dbrole_admin ] ,superuser: true ,comment: dify superuser }
        pg_databases:
          - { name: dify        ,owner: dify ,extensions: [ { name: vector } ] ,comment: dify main database  }
          - { name: dify_plugin ,owner: dify ,comment: dify plugin daemon database }
        pg_hba_rules:
          - { user: dify ,db: all ,addr: 172.16.0.0/12  ,auth: pwd ,title: 'allow dify access from local docker networks' }
        pg_crontab: [ '00 01 * * * /pg/bin/pg-backup full' ] # make a full backup every 1am

    infra: { hosts: { 10.10.10.10: { infra_seq: 1 } } }
    etcd:  { hosts: { 10.10.10.10: { etcd_seq: 1 } }, vars: { etcd_cluster: etcd } }
    #minio: { hosts: { 10.10.10.10: { minio_seq: 1 } }, vars: { minio_cluster: minio } }

  vars:                               # global variables
    version: v4.5.0                   # pigsty version string
    admin_ip: 10.10.10.10             # admin node ip address
    region: default                   # upstream mirror region: default|china|europe
    node_tune: oltp                   # node tuning specs: oltp,olap,tiny,crit
    pg_conf: oltp.yml                 # pgsql tuning specs: {oltp,olap,tiny,crit}.yml

    docker_enabled: true              # enable docker on app group
    #docker_registry_mirrors: ["https://docker.1panel.live","https://docker.1ms.run","https://docker.xuanyuan.me","https://registry-1.docker.io"]

    proxy_env:                        # global proxy env when downloading packages & pull docker images
      no_proxy: "localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16,*.pigsty,*.aliyun.com,mirrors.*,*.tsinghua.edu.cn"
      #http_proxy:  127.0.0.1:12345 # add your proxy env here for downloading packages or pull images
      #https_proxy: 127.0.0.1:12345 # usually the proxy is format as http://user:pass@proxy.xxx.com
      #all_proxy:   127.0.0.1:12345

    infra_portal:                     # domain names and upstream servers
      home   :  { domain: i.pigsty }
      #minio :  { domain: m.pigsty    ,endpoint: "${admin_ip}:9001" ,scheme: https ,websocket: true }
      dify:                            # nginx server config for dify
        domain: dify.pigsty            # REPLACE WITH YOUR OWN DOMAIN!
        endpoint: "10.10.10.10:5001"   # dify service endpoint: IP:PORT
        websocket: true                # add websocket support
        certbot: dify.pigsty           # certbot cert name, apply with `make cert`

    repo_enabled: false
    node_repo_modules: node,infra,pgsql
    # Dify v1.15.0 is patched in app/dify/patches for PostgreSQL 18's built-in uuidv7().
    pg_version: 18

    #----------------------------------------------#
    # PASSWORD : https://pigsty.io/docs/setup/security/
    #----------------------------------------------#
    grafana_admin_password: pigsty
    grafana_view_password: DBUser.Viewer
    pg_admin_password: DBUser.DBA
    pg_monitor_password: DBUser.Monitor
    pg_replication_password: DBUser.Replicator
    patroni_password: Patroni.API
    haproxy_admin_password: pigsty
    minio_secret_key: S3User.MinIO
    etcd_root_password: Etcd.Root
...

检查清单

以下是您需要关注的配置项检查清单：

  • 硬件/软件：准备所需的机器资源：Linux x86_64/arm64 服务器，主流 Linux 操作系统 的全新安装
  • 网络/权限：SSH 免密登录访问权限，用户具有 免密 sudo 权限
  • 确保机器在内网中有静态 IPv4 网络地址且可访问互联网
  • 如果通过公网访问，确保您有可用的域名指向当前节点的 公网 IP 地址
  • 确保使用 app/dify 配置模板并根据需要修改参数
    • configure -c app/dify，并输入节点的内网主 IP 地址，或通过 -i <primary_ip> 命令行参数指定
  • 在生产环境中，您是否已经修改全部示例密码、应用密钥与数据库凭据？【必需】
  • 您是否修改了 PostgreSQL 集群业务用户密码和使用这些密码的应用程序配置？
    • 默认用户名 dify 和密码 difyai123456 是 Pigsty 为 Dify 生成的，请根据实际情况修改
    • 在 Dify 的配置块中，请相应修改 DB_USERNAME、DB_PASSWORD、PGVECTOR_USER、PGVECTOR_PASSWORD 等参数
  • 您是否修改了 Dify 的默认加密密钥？
    • 您可以使用 openssl rand -base64 42 随机生成密码字符串并填入 SECRET_KEY 参数
  • 您是否修改了 Dify 使用的域名？
    • 将占位符域名 dify.pigsty 替换为您的实际域名，例如 dify.pigsty.cc
    • 您可以使用 sed -ie 's/dify.pigsty/dify.pigsty.cc/g' pigsty.yml 修改 Dify 的域名

域名和 SSL

如果您想使用带有 HTTPS 证书的真实域名，需要在 pigsty.yml 配置文件中修改：

  • infra_portal 参数的 dify 域名
  • 最好指定一个邮箱地址 certbot_email 用于接收证书过期通知
  • 配置 Dify 的 NGINX_SERVER_NAME 参数来指定您的实际域名
YAML
all:
  children:                            # 集群定义
    dify:                              # Dify 组
      vars:                            # Dify 组变量
        apps:                          # 应用程序配置
          dify:                        # Dify 应用程序定义
            conf:                      # Dify 应用程序配置
              NGINX_SERVER_NAME: dify.pigsty

  vars:                                # 全局参数
    #certbot_sign: true                # 使用 Certbot 申请免费 HTTPS 证书
    certbot_email: your@email.com      # 证书申请邮箱，用于过期通知，可选
    infra_portal:                      # 配置 Nginx 服务器
      dify:                            # Dify 服务器定义
        domain: dify.pigsty            # 请在此处替换为您自己的域名！
        endpoint: "10.10.10.10:5001"   # 请在此处指定 Dify 的 IP 和端口（默认自动配置）
        websocket: true                # Dify 需要启用 websocket
        certbot: dify.pigsty           # 指定 Certbot 证书名称

使用以下命令申请 Nginx 证书：

BASH
# 在明确限定的 infra 组上申请并加载证书
./infra.yml -l infra -t nginx_certbot,nginx_reload -e certbot_sign=true

执行 app.yml 剧本重新部署 Dify 服务以使 NGINX_SERVER_NAME 配置生效。

BASH
./app.yml -l dify -t app_config,app_launch

文件备份

您可以使用 restic 备份 Dify 的文件状态。当前模板至少需要保留 /data/dify、/opt/dify/.env 与 /opt/dify/volumes/；其中后者包含 Compose Redis、Sandbox 依赖和可能存在的 Certbot 数据。PostgreSQL 中的 Dify 数据仍应使用 Pigsty/pgBackRest 单独备份。

BASH
export RESTIC_REPOSITORY=/data/backups/dify   # 指定 dify 备份目录
export RESTIC_PASSWORD=some-strong-password   # 指定备份加密密码
mkdir -p ${RESTIC_REPOSITORY}                 # 创建 dify 备份目录
restic init

创建 Restic 备份仓库后，您可以使用以下命令备份 Dify：

BASH
export RESTIC_REPOSITORY=/data/backups/dify   # 指定 dify 备份目录
export RESTIC_PASSWORD=some-strong-password   # 指定备份加密密码

restic backup /data/dify /opt/dify/.env /opt/dify/volumes
restic snapshots                              # 查看备份快照列表
restic restore 0b11f778 --target /tmp/dify-restore  # 先恢复到临时目录，核对后再回填
restic check                                  # 定期检查仓库完整性

另一种方案是把 /data/dify 放在由 JUICE 模块管理的共享文件系统上。文件数据可以位于 Silo/S3，也可以位于 PostgreSQL 的 jfs_blob 表；后者并不是“大对象”存储。

若使用 PostgreSQL 同时保存 JuiceFS 元数据和文件数据，请先在 pg_databases 中声明并创建专用数据库和最小权限用户，再在 Dify 节点上声明实例。以下示例中的密码只是占位符，不能直接用于生产环境：

YAML
pg_databases:
  - { name: dify_fs, owner: dify, comment: JuiceFS metadata and data for Dify }

juice_instances:
  dify:
    path: /data/dify
    meta: postgres://dify:<password>@10.10.10.10:5432/dify_fs
    data: --storage postgres --bucket 10.10.10.10:5432/dify_fs --access-key dify --secret-key <password>
    owner: 1001
    group: 1001
    port: 9567

先分别对数据库创建与 JUICE 部署做检查，确认精确目标后再执行实际 playbook：

BASH
./pgsql-db.yml -l pg-meta -e dbname=dify_fs
./juice.yml -l dify -e fsname=dify

数据库创建、文件系统首次格式化和挂载都会改变目标环境，实际执行前必须确认备份、数据库名和主机组。部署后再启动 Dify，参见 JUICE 配置 与 PITR 一致性边界。直接挂载到已有非空的 /data/dify 之前，还必须先停止 Dify 并规划现有文件迁移。

参考

Dify 自托管常见问题

4 - InsForge：AI 后端即服务

使用 Pigsty 自建 InsForge OSS，并将 PostgreSQL 数据库、备份、监控与入口交给 Pigsty 管理。

InsForge 是面向 AI 编程代理的开源 Backend-as-a-Service 平台。它以 PostgreSQL 为核心，提供认证、数据库 API、文件存储、模型网关、边缘函数、站点部署和支付集成等能力，让应用可以跳过大部分后端样板代码。

Pigsty 提供 app/insforge 配置模板，将 InsForge OSS 的无状态服务运行在 Docker Compose 中，并把最关键的状态放入 Pigsty 托管的 PostgreSQL。这样可以继续使用 Pigsty 的高可用、备份恢复、监控、入口域名与基础设施能力，而不是把数据库藏在临时容器卷里。

当前模板面向 InsForge OSS v2.2.6，使用外部 PostgreSQL，默认暴露 InsForge Dashboard/API、PostgREST 和 Deno Runtime 三个服务。

快速开始

在运行 兼容操作系统 的全新 Linux x86 / ARM 服务器上执行：

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap                  # 安装 Pigsty 依赖
./configure -c app/insforge  # 使用 InsForge 配置模板
vi pigsty.yml                # 必改：密钥、管理员账号、数据库密码、域名

./deploy.yml                 # 安装 Pigsty、Infra、Etcd、PostgreSQL
./docker.yml                 # 安装 Docker 和 Compose
./app.yml                    # 安装 InsForge

安装完成后，默认访问地址为：

  • http://<your_ip_address>:7130
  • http://isf.pigsty

默认管理员账号为 admin@example.com / pigsty。生产环境必须修改管理员账号、管理员密码、JWT 密钥、加密密钥和数据库密码。

如果您希望通过 isf.pigsty 访问，请在浏览器所在主机的 /etc/hosts 中添加解析：

BASH
10.10.10.10 isf.pigsty

如果要对公网暴露服务，建议使用真实域名与 HTTPS 证书，并按下文修改 infra_portal。

检查清单

  • 准备一台全新 Linux 服务器，建议至少 2C4G，磁盘使用 SSD/NVMe。
  • 确认服务器拥有静态内网 IPv4 地址，并能访问 GHCR / Docker Hub 或已配置镜像站。
  • 执行 ./configure -c app/insforge 后，修改 pigsty.yml 中的默认密码、域名和密钥。
  • 用 openssl rand -base64 32 分别生成新的 JWT_SECRET 与 ENCRYPTION_KEY。
  • 将 POSTGRES_PASSWORD 与 pg_users 中的 dbuser_insforge 用户密码保持一致。
  • 如果通过公网访问，配置真实域名、HTTPS 证书和防火墙访问策略。
  • 确认 PostgreSQL 扩展包安装正常，部署后检查 pig pb info。

架构

InsForge 模板默认将数据库和应用容器分离：

TEXT
                    ┌──────────────────────────────────────────────┐
                    │                 InsForge Stack               │
┌──────────┐       │  ┌──────────┐  ┌──────────┐  ┌───────────┐  │
│  Nginx   │──────▶│  │ InsForge │  │PostgREST │  │   Deno    │  │
│ (Pigsty) │  :7130│  │ App+Web  │  │ REST API │  │  Runtime  │  │
└──────────┘       │  │  :7130   │  │  :5430   │  │   :7133   │  │
                    │  └────┬─────┘  └────┬─────┘  └─────┬─────┘  │
                    │       │             │              │         │
                    └───────┼─────────────┼──────────────┼─────────┘
                            │             │              │
                            ▼             ▼              ▼
                    ┌──────────────────────────────────────────────┐
                    │  PostgreSQL (Pigsty Managed HA Cluster)      │
                    │  Patroni + pgBackRest + pgBouncer + HAProxy  │
                    └──────────────────────────────────────────────┘

组件说明：

  • InsForge App：ghcr.io/insforge/insforge-oss:v2.2.6，提供 Dashboard 和主 API，监听 7130。
  • PostgREST：postgrest/postgrest:v12.2.12，从 PostgreSQL schema 自动生成 REST API，宿主机端口为 5430。
  • Deno Runtime：ghcr.io/insforge/deno-runtime:latest，用于边缘函数运行时，监听 7133。
  • PostgreSQL：由 Pigsty 管理，负责持久化状态、备份、监控和高可用。

配置模板

conf/app/insforge.yml 定义了单节点 InsForge 自建模板。默认拓扑包括：

  • insforge：InsForge、PostgREST、Deno Runtime 容器所在节点。
  • pg-meta：Pigsty 托管的 PostgreSQL 数据库集群，包含 InsForge 所需角色、数据库和扩展。
  • infra：Nginx 入口、Grafana、VictoriaMetrics 等基础设施。
  • etcd：Patroni 所需的分布式配置存储。

关键配置摘录如下：

YAML
insforge:
  hosts: { 10.10.10.10: {} }
  vars:
    app: insforge
    apps:
      insforge:
        conf:
          JWT_SECRET: your-secret-key-here-must-be-32-char-or-above
          ENCRYPTION_KEY: your-encryption-key-here-must-be-32-char-or-above
          ROOT_ADMIN_USERNAME: admin@example.com
          ROOT_ADMIN_PASSWORD: pigsty
          POSTGRES_HOST: 10.10.10.10
          POSTGRES_PORT: 5432
          POSTGRES_DB: insforge
          POSTGRES_USER: dbuser_insforge
          POSTGRES_PASSWORD: DBUser.Insforge

pg-meta:
  hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } }
  vars:
    pg_cluster: pg-meta
    pg_users:
      - { name: dbuser_insforge ,password: DBUser.Insforge ,pgbouncer: true ,roles: [dbrole_admin] ,superuser: true ,comment: 'insforge superuser' }
      - { name: anon            ,login: false ,comment: 'insforge anonymous role for PostgREST' }
      - { name: authenticated   ,login: false ,comment: 'insforge authenticated role' }
      - { name: project_admin   ,login: false ,bypassrls: true ,comment: 'insforge project admin with RLS bypass' }
    pg_databases:
      - name: insforge
        owner: dbuser_insforge
        baseline: insforge.sql
        extensions: [pgcrypto, http, pg_cron]
    pg_libs: 'pg_cron, pg_stat_statements, auto_explain'
    pg_parameters:
      cron.database_name: insforge
      app.encryption_key: your-encryption-key-here-must-be-32-char-or-above
      insforge.policy_grant_role: project_admin
      insforge.internal_schemas: 'ai,auth,compute,deployments,email,functions,memory,payments,realtime,schedules,storage,system'
    pg_extensions: [ pg_cron, pg_http ]
    pg_hba_rules:
      - { user: dbuser_insforge ,db: all ,addr: 172.16.0.0/12 ,auth: pwd ,title: 'allow insforge access from local docker networks' }

重要参数

app.yml 会把 app/insforge 目录复制到 /opt/insforge，并用 apps.insforge.conf 覆盖 /opt/insforge/.env。常见参数如下：

参数默认值说明
JWT_SECRET示例密钥JWT 签名密钥，生产必须替换，建议 32 字符以上随机值
ENCRYPTION_KEY示例密钥用于加密运行时凭据，生产必须替换，并与 JWT_SECRET 分开管理
ROOT_ADMIN_USERNAMEadmin@example.comRoot 管理员账号
ROOT_ADMIN_PASSWORDpigstyRoot 管理员密码，生产必须替换
POSTGRES_HOST / POSTGRES_PORT10.10.10.10 / 5432Pigsty PostgreSQL 入口
POSTGRES_DBinsforgeInsForge 数据库
POSTGRES_USERdbuser_insforgeInsForge 连接 PostgreSQL 的业务用户
POSTGRES_PASSWORDDBUser.Insforge业务用户密码，生产必须替换
INSFORGE_VERSIONv2.2.6InsForge OSS 镜像标签
DENO_RUNTIME_VERSIONlatestDeno Runtime 镜像标签
APP_PORT7130InsForge App 对外端口
POSTGREST_PORT5430PostgREST 对外端口
DENO_PORT7133Deno Runtime 对外端口
ACCESS_API_KEY空可选 MCP / API 访问密钥，为空时由 InsForge 生成
ACCESS_ANON_KEY空可选前端匿名访问密钥，设置时应以 anon_ 开头
OPENROUTER_API_KEY空可选 OpenRouter 模型网关密钥
AWS_S3_BUCKET / S3_*空可选对象存储配置
DENO_DEPLOY_TOKEN空可选 Deno Deploy 集成
VERCEL_TOKEN / FLY_API_TOKEN空可选站点部署与计算平台集成
STRIPE_* / RAZORPAY_*空可选支付集成

生成生产密钥：

BASH
openssl rand -base64 32

修改数据库密码时，请保证应用与数据库定义同步。例如：

YAML
apps:
  insforge:
    conf:
      POSTGRES_PASSWORD: <new-password>

pg_users:
  - { name: dbuser_insforge ,password: <new-password> ,pgbouncer: true ,roles: [dbrole_admin] ,superuser: true }

ENCRYPTION_KEY 一旦用于生产数据后应保持稳定。更换它可能导致已经加密保存的 API Key、OAuth Token、函数密钥等运行时凭据无法解密。

数据库与权限

InsForge 数据库默认名为 insforge，所有者为 dbuser_insforge。模板会创建以下角色：

角色登录用途
dbuser_insforge是InsForge 应用连接 PostgreSQL 的业务用户，模板中授予 superuser
anon否PostgREST 匿名角色
authenticated否PostgREST 已认证用户角色
project_admin否服务密钥语义的管理角色，带 BYPASSRLS

files/insforge.sql 会设置 PostgREST 角色权限、默认权限、project_admin 的 ACL，以及 public.reload_postgrest_schema() 辅助函数。该函数会执行：

SQL
NOTIFY pgrst, 'reload schema';

用于通知 PostgREST 重新加载 schema。

InsForge 上游的 PostgreSQL 镜像会预置 insforge_pg_utils。Pigsty 当前模板没有依赖这个扩展包，而是使用 Pigsty 已提供的 pgcrypto、http、pg_cron，并让 InsForge 应用迁移负责运行时 schema。

服务端口与持久化

默认 Docker Compose 服务如下：

服务容器宿主机端口说明
InsForge Appinsforge7130Dashboard 与主 API
PostgRESTinsforge-postgrest5430自动生成 REST API
Deno Runtimeinsforge-deno7133边缘函数运行时

默认 Docker 卷如下：

卷挂载点说明
storage-data/insforge-storage本地文件存储
insforge-logs/insforge-logs应用日志
deno_cache/deno-dirDeno 模块缓存

数据库连接默认来自 Docker 容器到 Pigsty 节点 10.10.10.10:5432。模板的 HBA 规则允许 172.16.0.0/12，覆盖 Docker 默认 bridge 与常见自定义 bridge 地址段。

域名与入口

模板默认在 infra_portal 中增加 InsForge 入口：

YAML
infra_portal:
  home    : { domain: i.pigsty }
  insforge:
    domain: isf.pigsty
    endpoint: "10.10.10.10:7130"
    websocket: true
    certbot: isf.pigsty

如果您使用真实域名，例如 insforge.example.com，可以批量替换：

BASH
sed -ie 's/isf.pigsty/insforge.example.com/g' pigsty.yml

然后应用 Nginx 入口配置：

BASH
./infra.yml -t nginx

如需申请 HTTPS 证书，请先确保域名解析到当前节点，再在 infra_portal.insforge 中加入或修改 certbot：

YAML
insforge:
  domain: insforge.example.com
  endpoint: "10.10.10.10:7130"
  websocket: true
  certbot: insforge.example.com

随后执行：

BASH
make cert
./infra.yml -t nginx

运维命令

InsForge 安装后位于 /opt/insforge，常用命令如下：

BASH
cd /opt/insforge

make up       # 启动服务
make view     # 打印访问地址
make info     # 查看容器状态
make log      # 跟随日志
make restart  # 重启容器
make down     # 停止容器
make clean    # 删除已停止容器
make edit     # 编辑 .env

离线环境可以提前保存镜像：

BASH
cd /opt/insforge
make pull
make save
make tarball

默认产物位置：

  • /tmp/docker/insforge/postgrest.tgz
  • /tmp/docker/insforge/insforge.tgz
  • /tmp/docker/insforge/deno.tgz
  • /tmp/insforge.tgz

在目标机器上加载镜像：

BASH
cd /opt/insforge
make load
make up

数据与备份

InsForge 的状态分为两类：

  • 业务数据、用户、项目元数据、权限等：存放在 Pigsty PostgreSQL 数据库 insforge 中。
  • 本地文件与日志：存放在 Docker 卷 storage-data 与 insforge-logs 中。

模板默认配置每日凌晨 1 点执行一次 PostgreSQL 全量备份：

YAML
pg_crontab: [ '00 01 * * * /pg/bin/pg-backup full' ]

部署后建议检查备份状态：

BASH
pig pb info

如果您将文件存储配置为 S3 / MinIO，文件对象由对应对象存储系统承载；如果保持本地卷，需要另外纳入主机层备份策略。

排障

查看容器状态：

BASH
cd /opt/insforge
make info

查看日志：

BASH
sudo docker logs insforge
sudo docker logs insforge-postgrest
sudo docker logs insforge-deno

检查 PostgreSQL 是否能从容器访问：

BASH
sudo docker exec insforge-postgrest bash -c '</dev/tcp/10.10.10.10/5432'

检查 HBA 规则是否包含 Docker 网段：

BASH
sudo -iu postgres psql -d insforge -c "TABLE pg_hba_file_rules;"

检查角色是否存在：

BASH
sudo -iu postgres psql -d insforge -c "SELECT rolname, rolcanlogin, rolbypassrls FROM pg_roles WHERE rolname IN ('anon','authenticated','project_admin');"

检查端口占用：

BASH
ss -tlnp | grep -E '7130|7133|5430'

常见问题：

  • 无法登录：确认 ROOT_ADMIN_USERNAME / ROOT_ADMIN_PASSWORD 是否已被模板写入 /opt/insforge/.env，并检查 insforge 容器日志。
  • PostgREST 启动失败：确认 anon、authenticated、project_admin 角色存在，并确认 JWT_SECRET 与 InsForge App 一致。
  • 数据库连接失败：确认 POSTGRES_HOST、POSTGRES_PORT、POSTGRES_PASSWORD 与 pg_users 中的配置一致，并检查 HBA 是否允许 Docker 网段。
  • 上传或下载文件异常：如果使用 S3 / MinIO，检查 AWS_S3_BUCKET、S3_ENDPOINT_URL、S3_FORCE_PATH_STYLE 与访问密钥配置。

参考

5 - Hindsight：AI 长期记忆

使用 Pigsty 自建 Hindsight，并使用外部 PostgreSQL 存储长期记忆。

Hindsight 是面向 AI Agent 的 PostgreSQL-native 长期记忆服务。

Pigsty 提供 app/hindsight 配置模板（conf/app/hindsight.yml），默认使用 Pigsty 托管的 PostgreSQL，而不是 Hindsight 内置的开发数据库。

快速开始

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap
./configure -c app/hindsight
vi pigsty.yml                 # 修改域名、数据库密码与 LLM 设置
./deploy.yml
./docker.yml
./app.yml

默认访问地址：

  • UI：http://hs.pigsty 或 http://<IP>:9999
  • API：http://hs-api.pigsty 或 http://<IP>:8888

关键配置

conf/app/hindsight.yml 会在 apps.hindsight.conf 中覆盖 /opt/hindsight/.env。重点参数：

  • HINDSIGHT_API_PUBLISH_PORT：API 对外端口，默认 8888
  • HINDSIGHT_UI_PUBLISH_PORT：UI 对外端口，默认 9999
  • HINDSIGHT_DB_HOST / HINDSIGHT_DB_PORT / HINDSIGHT_DB_NAME / HINDSIGHT_DB_USER / HINDSIGHT_DB_PASSWORD
  • HINDSIGHT_API_VECTOR_EXTENSION：默认 pgvector
  • HINDSIGHT_API_TEXT_SEARCH_EXTENSION：默认 native
  • HINDSIGHT_API_LLM_PROVIDER：默认 none

默认 none LLM Provider 只保证服务可启动；事实抽取、反思与整合能力需要配置 Ollama 或 OpenAI 兼容 API。

运维命令

BASH
cd /opt/hindsight
make up
make log
make info
make down
make pull

参考

6 - FerretDB：MongoDB 协议

在 Pigsty 托管的 PostgreSQL 与 DocumentDB 之上部署无状态 FerretDB 代理。

FerretDB 在 PostgreSQL 与 DocumentDB 扩展之上提供 MongoDB 兼容协议。Pigsty 的 app/ferretdb 只运行无状态协议代理；PostgreSQL、postgres 数据库、DocumentDB 扩展与后端登录用户必须预先存在，mongo 配置模板 会一次性准备这些依赖。

快速开始

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap
./configure -c mongo
./deploy.yml
./docker.yml -l pg-meta
./app.yml -l pg-meta

另行安装 mongosh 或其他 MongoDB 兼容客户端后，使用模板声明的专用登录连接：

BASH
mongosh 'mongodb://mongod:DBUser.Mongo@127.0.0.1:27017/'

关键配置

请通过清单中的 apps.ferretdb.conf 覆盖模板变量，不要直接修改部署到 /opt/ferretdb/.env 的文件：

YAML
app: ferretdb
apps:
  ferretdb:
    conf:
      FERRETDB_IMAGE: ghcr.io/ferretdb/ferretdb:2.7.0
      FERRETDB_POSTGRESQL_URL: 'postgres://mongod:DBUser.Mongo@host.docker.internal:5436/postgres?pool_min_conns=1&pool_max_conns=20'
      FERRETDB_BIND_ADDR: 127.0.0.1
      FERRETDB_PORT: 27017
      FERRETDB_AUTH: true
      FERRETDB_TELEMETRY: disabled

端口 5436 是 Pigsty 直连当前 PostgreSQL 主库的服务。Linux host-gateway 映射让容器通过本机接入，同时保留 Pigsty 的主库路由。MongoDB 端口默认只监听回环地址；远程客户端确有需要时再显式修改 FERRETDB_BIND_ADDR。

FerretDB 通过 PostgreSQL 验证用户身份，但目前不实现 MongoDB 授权语义，因此 MongoDB 角色不能提供访问隔离。模板也没有启用客户端 MongoDB TLS；将服务暴露到不可信网络前，必须配置证书与 FERRETDB_LISTEN_TLS* 变量。

FerretDB 发行版会指定首选 DocumentDB 版本，而 Pigsty 可能提供更新的兼容软件包。任一组件升级后，都应重新执行一次带身份验证的 CRUD 冒烟测试。

可选三节点拓扑

mongo 模板 包含一段默认注释的三节点 PostgreSQL / DocumentDB 集群：每个节点运行一个 FerretDB 容器，由 HAProxy 通过浮动入口 10.10.10.4:27017（mongo.pigsty）暴露标准端口。启用完整的 pg-mongo 与额外 etcd 成员后执行：

BASH
./configure -c mongo
./deploy.yml
./docker.yml -l pg-mongo
./app.yml -l pg-mongo
mongosh 'mongodb://mongod:DBUser.Mongo@10.10.10.4:27017/'

HAProxy 使用 TCP 级健康检查剔除停止或不可达的 FerretDB 进程；容器镜像内置的健康检查继续验证后端连接。生产部署还应使用共享的 Silo 或外部 S3 兼容 pgBackRest 仓库，确保 PostgreSQL 主库切换后仍能访问同一份备份历史。

参考

7 - NocoDB：开源 Airtable

使用 NocoDB 将 PostgreSQL 数据库转变为智能电子表格，无代码数据库应用平台。

NocoDB 是一个开源的 Airtable 替代方案，可以将任何数据库转变为智能电子表格。

它提供了丰富的用户界面，让您无需编写代码即可创建强大的数据库应用。NocoDB 支持 PostgreSQL、MySQL、SQL Server 等多种数据库，是构建内部工具和数据管理系统的理想选择。

快速开始

在 Pigsty 软件模板目录中提供了 NocoDB 的 Docker Compose 配置文件：

BASH
cd ~/pigsty/app/nocodb

检查并修改 .env 配置文件（根据需要调整数据库连接等配置）。

启动服务：

BASH
make up     # 使用 Docker Compose 启动 NocoDB

访问 NocoDB：

  • 默认地址： http://nocodb.pigsty
  • 备用地址： http://10.10.10.10:8080
  • 首次访问需要创建管理员账户

管理命令

Pigsty 提供了便捷的 Makefile 命令来管理 NocoDB 服务：

BASH
make up      # 启动 NocoDB 服务
make run     # 使用 Docker 启动（连接外部 PostgreSQL）
make view    # 显示 NocoDB 访问地址
make log     # 查看容器日志
make info    # 查看服务详细信息
make stop    # 停止服务
make clean   # 停止并移除容器
make pull    # 拉取最新镜像
make rmi     # 移除 NocoDB 镜像
make save    # 保存镜像到 /tmp/nocodb.tgz
make load    # 从 /tmp/nocodb.tgz 加载镜像

连接 PostgreSQL

NocoDB 可以连接到 Pigsty 管理的 PostgreSQL 数据库。

在 NocoDB 界面中添加新项目时，选择「External Database」，然后输入 PostgreSQL 连接信息：

TEXT
主机：10.10.10.10
端口：5432
数据库名：your_database
用户名：your_username
密码：your_password
SSL：禁用（或根据实际情况启用）

连接成功后，NocoDB 会自动读取数据库的表结构，您可以通过可视化界面进行数据管理。

功能特性

  • 智能电子表格界面：类似 Excel/Airtable 的用户体验
  • 多种视图：网格、表单、看板、日历、画廊视图
  • 协作功能：团队协作、权限管理、评论
  • API 支持：自动生成 REST API
  • 集成能力：支持 Webhook、Zapier 等集成
  • 数据导入导出：支持 CSV、Excel 等格式
  • 公式和验证：支持复杂的数据计算和验证规则

配置说明

NocoDB 的配置在 .env 文件中：

BASH
# 数据库连接（NocoDB 元数据存储）
NC_DB=pg://postgres:DBUser.Postgres@10.10.10.10:5432/nocodb

# JWT 密钥（建议修改）
NC_AUTH_JWT_SECRET=your-secret-key

# 其他配置
NC_PUBLIC_URL=http://nocodb.pigsty
NC_DISABLE_TELE=true

数据持久化

NocoDB 的元数据默认存储在外部 PostgreSQL 数据库中，应用数据也可以存储在 PostgreSQL 中。

如果使用本地存储，数据会保存在 /data/nocodb 目录中。

安全建议

  1. 修改默认密钥：在 .env 文件中修改 NC_AUTH_JWT_SECRET
  2. 使用强密码：为管理员账户设置强密码
  3. 配置 HTTPS：生产环境建议启用 HTTPS
  4. 限制访问：通过防火墙或 Nginx 限制访问权限
  5. 定期备份：定期备份 NocoDB 元数据库

相关链接

8 - Teable：AI 无代码数据库

使用 Pigsty 自建 Teable，并接入外部 PostgreSQL 与 Silo。

Teable 是面向团队协作的无代码数据库平台。

Pigsty 提供 app/teable 模板（conf/app/teable.yml），默认依赖 PostgreSQL + Silo + Docker（不依赖 Redis）。

快速开始

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap
./configure -c app/teable
vi pigsty.yml                 # 修改密码、域名、邮件参数
./deploy.yml                  # 安装基础设施、PostgreSQL、Silo
./docker.yml
./app.yml

默认入口：

  • http://<IP>:8890
  • http://tea.pigsty

关键配置

模板会将以下参数写入 /opt/teable/.env：

  • POSTGRES_HOST/POSTGRES_PORT/POSTGRES_DB/POSTGRES_USER/POSTGRES_PASSWORD
  • PRISMA_DATABASE_URL
  • PUBLIC_ORIGIN（对外访问地址）
  • PUBLIC_DATABASE_PROXY
  • TEABLE_PORT（默认 8890）

运维命令

BASH
cd /opt/teable
make up
make log
make down

参考

9 - Gitea：自建简易代码托管平台

使用 Pigsty 的 Compose 模板部署 Gitea，并接入外部 PostgreSQL。

Gitea 是轻量级开源 Git 托管平台。

Pigsty 的 app/gitea 模板默认就是 PostgreSQL 外部数据库模式，通过 .env 中 GITEA_DB_* 参数连接数据库。

快速开始

BASH
cd ~/pigsty/app/gitea
vi .env         # 检查域名、端口、数据库连接
make up

默认入口：

  • Web：http://git.pigsty 或 http://<IP>:8889
  • SSH：<IP>:2222

数据库准备

BASH
bin/pgsql-user pg-meta dbuser_gitea
bin/pgsql-db   pg-meta gitea

连接串示例：

BASH
postgres://dbuser_gitea:DBUser.Gitea@10.10.10.10:5432/gitea

常用命令

BASH
make up
make log
make stop
make clean

参考

10 - Wiki.js：维基百科站

如何使用 Wiki.js 搭建你自己的开源维基百科，并使用 Pigsty 管理的 PG 作为持久数据存储

公开 Demo 地址：http://wiki.pigsty.cc

Wiki.js

太长;不看

BASH
cd ~/pigsty/app/wiki && docker compose up -d

准备数据库

YAML
# postgres://dbuser_wiki:DBUser.Wiki@10.10.10.10:5432/wiki
- { name: wiki, owner: dbuser_wiki, revokeconn: true , comment: wiki the api gateway database }
- { name: dbuser_wiki, password: DBUser.Wiki , pgbouncer: true , roles: [ dbrole_admin ] }
BASH
bin/pgsql-user pg-meta dbuser_wiki
bin/pgsql-db   pg-meta wiki

容器配置

YAML
version: "3"
services:
  wiki:
    container_name: wiki
    image: requarks/wiki:2
    environment:
      DB_TYPE: postgres
      DB_HOST: 10.10.10.10
      DB_PORT: 5432
      DB_USER: dbuser_wiki
      DB_PASS: DBUser.Wiki
      DB_NAME: wiki
    restart: unless-stopped
    ports:
      - "9002:3000"

Access

  • Default Port for wiki: 9002
YAML
# add to nginx_upstream
- { name: wiki  , domain: wiki.pigsty.cc , endpoint: "127.0.0.1:9002"   }
BASH
./infra.yml -t nginx_config,nginx_reload -l infra

11 - Mattermost：开源团队协作

使用 Pigsty 部署 Mattermost，并将状态托管到外部 PostgreSQL。

Mattermost 是开源团队协作平台，可作为 Slack 的私有化替代方案。

Pigsty 提供 app/mattermost 配置模板（conf/app/mattermost.yml），默认将应用状态存放到外部 PostgreSQL，并将文件目录持久化到主机路径。

快速开始

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap
./configure -c app/mattermost
vi pigsty.yml                 # 修改密码、域名
./deploy.yml
./docker.yml
./app.yml

默认访问地址：

  • http://<IP>:8065
  • http://mm.pigsty

首次访问需要在 Web 页面初始化管理员账号。

默认存储与连接

模板默认配置：

  • PostgreSQL 连接：POSTGRES_URL=postgres://dbuser_mattermost:DBUser.Mattermost@<IP>:5432/mattermost?...
  • 持久化目录：/data/mattermost/{config,data,logs,plugins,client/plugins,bleve-indexes}

运维命令

BASH
cd /opt/mattermost
make up
make restart
make log
make stop

参考

12 - Maybe：自建个人财务

使用 Pigsty 自建 Maybe 个人财务管理应用，并将 PostgreSQL 数据库、备份、监控与入口交给 Pigsty 管理。

Maybe 是一个开源个人财务管理应用，可以用于维护账户、交易、预算、投资与家庭财务视图。Maybe 是典型的 Rails Web 应用，生产环境使用 PostgreSQL 保存业务数据，并使用 Redis 处理后台任务队列。

Pigsty 提供 app/maybe 模板，将 Maybe 的无状态 Web / Worker 容器接入 Pigsty 托管的 PostgreSQL，并用本地 Redis 承载 Sidekiq 队列。这样您可以把最重要的财务数据放在可备份、可监控、可恢复的 PostgreSQL 集群中，而不是放在一个临时 Docker 数据卷里。

Maybe 上游仓库已经归档，最新 release 为 v0.6.0。GHCR 目前发布 stable 与 latest 镜像标签；Pigsty 默认使用 stable，即最新 release 语义的镜像。

快速开始

在运行 兼容操作系统 的全新 Linux x86 / ARM 服务器上执行：

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap                # 安装 Pigsty 依赖
./configure -c app/maybe   # 使用 Maybe 配置模板
vi pigsty.yml              # 必改：SECRET_KEY_BASE、数据库密码、域名

./deploy.yml               # 安装 Pigsty、Infra、Etcd、PostgreSQL
./docker.yml               # 安装 Docker 和 Compose
./app.yml                  # 安装 Maybe

Maybe 默认监听 5002 端口。安装完成后，您可以通过以下地址访问：

  • http://<your_ip_address>:5002
  • http://maybe.pigsty

首次访问时，在登录页面选择创建账号，注册您的第一个家庭账户即可开始使用。

如果您希望通过 maybe.pigsty 访问，请在浏览器所在主机的 /etc/hosts 中添加解析：

BASH
10.10.10.10 maybe.pigsty

如果要对公网暴露服务，建议使用真实域名与 HTTPS 证书，并按下文修改 infra_portal。

检查清单

  • 准备一台全新 Linux 服务器，建议至少 2C4G，磁盘使用 SSD/NVMe。
  • 确认服务器拥有静态内网 IPv4 地址，并能访问 GHCR / Docker Hub 或已配置镜像站。
  • 执行 ./configure -c app/maybe 后，修改 pigsty.yml 中的默认密码、域名和密钥。
  • 用 openssl rand -hex 64 生成新的 SECRET_KEY_BASE。
  • 将 POSTGRES_PASSWORD 与 pg_users 中的 maybe 用户密码保持一致。
  • 如果通过公网访问，配置真实域名、HTTPS 证书和防火墙访问策略。
  • 确认 PostgreSQL 备份任务正常，部署后检查 pig pb info。

配置模板

conf/app/maybe.yml 定义了单节点 Maybe 自建模板。默认拓扑包括：

  • maybe：Maybe Web / Worker / Redis 容器所在节点。
  • pg-maybe：Pigsty 托管的 PostgreSQL 数据库集群。
  • infra：Nginx 入口、Grafana、VictoriaMetrics 等基础设施。
  • etcd：Patroni 所需的分布式配置存储。

关键配置摘录如下：

YAML
maybe:
  hosts: { 10.10.10.10: {} }
  vars:
    app: maybe
    apps:
      maybe:
        file:
          - { path: /data/maybe             ,state: directory ,mode: 0755 }
          - { path: /data/maybe/storage     ,state: directory ,owner: 1000 ,group: 1000 ,mode: 0755 }
          - { path: /data/maybe/redis       ,state: directory ,mode: 0755 }
        conf:
          MAYBE_IMAGE: ghcr.io/maybe-finance/maybe
          MAYBE_VERSION: stable
          MAYBE_PORT: 5002
          MAYBE_DATA: /data/maybe
          APP_DOMAIN: maybe.pigsty
          SECRET_KEY_BASE: 2f1e4c3d5b6a79808796a5b4c3d2e1f00123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567
          DB_HOST: 10.10.10.10
          DB_PORT: 5432
          POSTGRES_USER: maybe
          POSTGRES_PASSWORD: MaybeFinance2026
          POSTGRES_DB: maybe_production
          REDIS_VERSION: 7-alpine

pg-maybe:
  hosts: { 10.10.10.10: { pg_seq: 1, pg_role: primary } }
  vars:
    pg_cluster: pg-maybe
    pg_users:
      - { name: maybe ,password: MaybeFinance2026 ,pgbouncer: true ,roles: [ dbrole_admin ] ,comment: admin user for maybe service }
    pg_databases:
      - { name: maybe_production ,owner: maybe ,revokeconn: true ,comment: maybe main database }
    pg_hba_rules:
      - { user: maybe ,db: maybe_production ,addr: 172.16.0.0/12 ,auth: pwd ,title: 'allow maybe access from local docker network' }
    pg_crontab: [ '00 01 * * * /pg/bin/pg-backup full' ]

这里的 maybe_production 是 Maybe / Rails 上游默认的生产数据库名称。您也可以改成 maybe，但必须同时修改 POSTGRES_DB、pg_databases.name、pg_hba_rules.db 与所有文档/运维脚本中的引用。

重要参数

app.yml 会把 app/maybe 目录复制到 /opt/maybe，并用 apps.maybe.conf 覆盖 /opt/maybe/.env。常见参数如下：

参数默认值说明
MAYBE_IMAGEghcr.io/maybe-finance/maybeMaybe 镜像仓库
MAYBE_VERSIONstable镜像标签，建议生产保持 stable
MAYBE_PORT5002宿主机暴露端口
MAYBE_DATA/data/maybe宿主机持久化目录
APP_DOMAINmaybe.pigstyMaybe 的默认入口域名占位
SECRET_KEY_BASE示例随机串Rails 加密签名密钥，生产必须替换
DB_HOST / DB_PORT10.10.10.10 / 5432Pigsty PostgreSQL 入口
POSTGRES_USERmaybeMaybe 连接 PostgreSQL 的业务用户
POSTGRES_PASSWORDMaybeFinance2026业务用户密码，生产必须替换
POSTGRES_DBmaybe_productionMaybe 生产数据库
REDIS_VERSION7-alpine本地 Redis 镜像标签

生成生产密钥：

BASH
openssl rand -hex 64

修改密码时，请保证应用与数据库定义同步。例如：

YAML
apps:
  maybe:
    conf:
      POSTGRES_PASSWORD: <new-password>

pg_users:
  - { name: maybe ,password: <new-password> ,pgbouncer: true ,roles: [ dbrole_admin ] }

域名与入口

模板默认在 infra_portal 中增加 Maybe 入口：

YAML
infra_portal:
  home  : { domain: i.pigsty }
  maybe:
    domain: maybe.pigsty
    endpoint: "10.10.10.10:5002"
    websocket: true

如果您使用真实域名，例如 finance.example.com，可以批量替换：

BASH
sed -ie 's/maybe.pigsty/finance.example.com/g' pigsty.yml

然后应用 Nginx 入口配置：

BASH
./infra.yml -t nginx

如需申请 HTTPS 证书，请先确保域名解析到当前节点，再在 infra_portal.maybe 中加入 certbot：

YAML
maybe:
  domain: finance.example.com
  endpoint: "10.10.10.10:5002"
  websocket: true
  certbot: finance.example.com

随后执行：

BASH
make cert
./infra.yml -t nginx

运维命令

Maybe 安装后位于 /opt/maybe，常用命令如下：

BASH
cd /opt/maybe

make up        # 启动 Maybe
make run       # 前台启动并查看日志
make restart   # 重启容器
make down      # 停止容器
make status    # 查看容器状态
make log       # 跟随日志
make health    # 检查 Rails /up 健康端点
make migrate   # 手动执行 Rails db:prepare
make console   # 进入 Rails console
make exec      # 进入 maybe-web 容器 shell

web 容器启动时会自动执行 db:prepare，通常不需要手工迁移。升级镜像后，如果启动日志提示数据库迁移问题，可以先查看日志，再执行：

BASH
cd /opt/maybe
make pull
make up
make log

数据与备份

Maybe 的状态分为两类：

  • 业务数据：存放在 Pigsty PostgreSQL 数据库 maybe_production 中。
  • 附件/缓存：宿主机目录 /data/maybe/storage 与 /data/maybe/redis。

模板默认配置每日凌晨 1 点执行一次 PostgreSQL 全量备份：

YAML
pg_crontab: [ '00 01 * * * /pg/bin/pg-backup full' ]

部署后建议检查备份状态：

BASH
pig pb info

如果您在生产环境中使用 Maybe 记录真实财务数据，请至少做到：

  • 定期检查 PostgreSQL 备份是否成功。
  • 将 pgBackRest 仓库放到可靠磁盘或对象存储中。
  • 将 /data/maybe/storage 纳入文件级备份，您可以使用 restic 备份到 s3
  • 不要把 SECRET_KEY_BASE、数据库密码、API Key 泄露到公开仓库。

安全建议

Maybe 用于个人/家庭财务管理，数据敏感度很高。生产使用时建议：

  • 修改所有 Pigsty 默认密码，尤其是 pg_admin_password、pg_monitor_password、patroni_password、haproxy_admin_password。
  • 修改 Maybe 数据库用户密码 POSTGRES_PASSWORD。
  • 使用新的 SECRET_KEY_BASE，不要沿用模板示例值。
  • 对公网开放时启用 HTTPS，并限制管理端口访问。
  • 如启用 OPENAI_ACCESS_TOKEN 或 SYNTH_API_KEY，请评估外部 API 成本与数据暴露边界。

Maybe 上游已经归档，适合对现有功能满意、偏本地长期自持的用户。如果您需要持续演进的新功能或银行自动同步能力，应提前评估上游维护状态。

参考

13 - Immich：自建照片视频库

使用 Pigsty 自建 Google Photos 开源替代 Immich，并将元数据、向量检索、备份与入口交给 Pigsty 管理。

Immich 是高性能自托管照片与视频管理应用，也是最流行的 Google Photos 开源替代品之一。 它提供 Web 与移动端上传、相册共享、时间线、地图、EXIF、RAW、LivePhoto、语义搜索、人脸识别与自动备份等能力，采用 AGPL-3.0 许可证。

Pigsty 的 app/immich 模板使用 Docker Compose 拉起 Immich 应用层，并使用 Pigsty 托管的 PostgreSQL 保存元数据。 当前模板按 Immich v3 组织，默认使用 VectorChord 作为相似图片、智能搜索与人脸检索的向量扩展。

相比 Immich 官方的单机 Compose 模板，这里的关键差异是：PostgreSQL 不再跑在应用容器里，而是交给 Pigsty 管理，从而获得监控、备份、PITR、扩展管理与高可用接入能力。

快速开始

Immich 建议至少 2C / 6GB 内存，流畅使用建议 4C / 8GB 内存；v3 的 amd64 机器学习镜像需要 x86-64-v2 指令集。生产环境建议使用 Linux 与本地 SSD。

在运行 兼容操作系统 的全新 Linux x86 / ARM 服务器上执行：

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap
./configure -c app/immich
vi pigsty.yml              # 必改：密码、域名、媒体文件路径

./deploy.yml               # 安装 Pigsty 与 PostgreSQL
./docker.yml               # 安装 Docker 和 Compose
./app.yml                  # 安装 Immich

默认入口：

TEXT
http://photo.pigsty
http://10.10.10.10:2283

如果使用 photo.pigsty，请在浏览器所在主机添加 hosts 解析，或将模板中的域名替换为真实域名。

模板结构

conf/app/immich.yml 定义了单节点 Immich 自建模板。默认拓扑包括：

  • immich：Immich Server、Machine Learning 与本地 Valkey/Redis 容器所在节点。
  • pg-immich：Pigsty 托管的 PostgreSQL 数据库集群。
  • infra：Nginx 入口、Grafana、VictoriaMetrics 等基础设施。
  • etcd：Patroni 所需的分布式配置存储。

应用容器包括：

  • immich-server：API、Web UI 与后台任务，默认监听宿主机 2283 端口。
  • immich-machine-learning：CLIP 与人脸识别模型推理。
  • redis：本地 Valkey 队列与缓存。

模板不会启动 Immich 上游 Compose 中的 PostgreSQL 容器；数据库由 Pigsty 通过 DB_URL 提供。

数据存储策略

Immich 的状态被拆成三层，请分别管理：

  • 媒体文件：原图、原视频、缩略图、转码视频、头像与上传队列，保存在 UPLOAD_LOCATION 对应的宿主机目录。
  • PostgreSQL：保存用户、相册、资产、EXIF、文件路径、任务状态、人物、人脸与智能搜索向量等元数据。
  • Valkey/Redis：保存队列、缓存与运行时状态，不应当作为权威数据源。

照片和视频本体不会写入 PostgreSQL。反过来，Immich 也不会把媒体目录当成唯一真相重新扫描出完整业务状态；数据库里保存的路径与元数据同样关键。

因此，一个可恢复的 Immich 备份必须同时包含 PostgreSQL 与媒体目录。只备份数据库会丢照片，只备份文件也无法可靠恢复相册、用户、分享、人脸与检索状态。

PostgreSQL

默认数据库连接与向量扩展：

TEXT
DB_URL=postgresql://dbuser_immich:DBUser.Immich@10.10.10.10:5432/immich
DB_VECTOR_EXTENSION=vectorchord

模板会在 pg-immich 集群安装扩展包并创建数据库扩展：

SQL
CREATE EXTENSION vchord CASCADE;
CREATE EXTENSION earthdistance CASCADE;

vchord 需要通过 pg_libs 加入 shared_preload_libraries，模板已经配置：

YAML
pg_extensions: [ pgvector, vchord ]
pg_libs: 'vchord.so, pg_stat_statements, auto_explain'

这里默认使用直连 PostgreSQL 的 5432 端口。不要把 Immich 指向事务池模式的 PgBouncer；迁移、索引和预备语句场景下，直连 PostgreSQL 或 session pooling 更稳妥。

Immich 官方仍然把预置 PostgreSQL 视为高级用法，但同时明确这种模式可以解锁 pgBackRest / Barman 这类 WAL 流式备份。Pigsty 模板选择无超级用户路径：由 Pigsty 预先创建数据库、用户和扩展，Immich 业务用户不需要 PostgreSQL 超级用户权限。

媒体文件

Immich 上传的照片、视频、缩略图、转码文件和头像保存在宿主机目录，也就是模板中的 UPLOAD_LOCATION：

TEXT
/data/immich/library

PostgreSQL 只保存元数据和文件路径。媒体文件不在 PostgreSQL 中，也不会被 pgBackRest 自动保护。

生产环境至少需要备份两层数据：

  • PostgreSQL：使用 Pigsty pgBackRest / PITR。
  • 媒体文件：对 /data/immich/library 做完整文件级备份，覆盖其中的原图、上传队列、缩略图、转码文件、头像与其他生成资产。

如果需要更一致的组合备份，先停止 immich-server，再同时备份数据库和媒体目录。如果业务不能停止，则建议先备份数据库，再备份文件系统。

镜像与网络

默认镜像来自 GHCR 与 Docker Hub：

BASH
docker pull ghcr.io/immich-app/immich-server:v3
docker pull ghcr.io/immich-app/immich-machine-learning:v3
docker pull docker.io/valkey/valkey:9

如果拉取镜像较慢或受限，请在 pigsty.yml 中配置 proxy_env 或 docker_registry_mirrors。

运维命令

安装后进入 /opt/immich：

BASH
cd /opt/immich

make up       # 启动 Immich
make logs     # 跟随日志
make info     # 查看容器状态
make pull     # 拉取镜像
make restart  # 重启容器
make down     # 停止并移除容器

如需固定具体 Immich 版本，在 pigsty.yml 中设置：

YAML
IMMICH_VERSION: v3.0.1

升级 Immich 或 VectorChord 前，请先阅读上游 release notes。VectorChord 包升级后，通常还需要在 immich 数据库中更新扩展并重建相关索引：

SQL
ALTER EXTENSION vchord UPDATE;
REINDEX INDEX face_index;
REINDEX INDEX clip_index;

大型图库重建索引可能耗时较长，执行前请确认已有备份和维护窗口。

参考

14 - Metabase：BI 分析工具

使用 Metabase 进行快速的商业智能分析，友好的用户界面让团队自主探索数据。

Metabase 是一个快速、易用的开源商业智能工具，让您的团队无需 SQL 知识即可探索和可视化数据。

Metabase 提供友好的用户界面和丰富的图表类型，支持连接多种数据库，是企业数据分析的理想选择。

快速开始

在 Pigsty 软件模板目录中提供了 Metabase 的 Docker Compose 配置文件：

BASH
cd ~/pigsty/app/metabase

检查并修改 .env 配置文件：

BASH
vim .env    # 检查配置，建议修改默认凭据

启动服务：

BASH
make up     # 使用 Docker Compose 启动 Metabase

访问 Metabase：

  • 默认地址： http://metabase.pigsty
  • 备用地址： http://10.10.10.10:3001
  • 首次访问需要完成初始化设置

管理命令

Pigsty 提供了便捷的 Makefile 命令来管理 Metabase 服务：

BASH
make up      # 启动 Metabase 服务
make run     # 使用 Docker 启动（连接外部 PostgreSQL）
make view    # 显示 Metabase 访问地址
make log     # 查看容器日志
make info    # 查看服务详细信息
make stop    # 停止服务
make clean   # 停止并移除容器
make pull    # 拉取最新镜像
make rmi     # 移除 Metabase 镜像
make save    # 保存镜像到文件
make load    # 从文件加载镜像

连接 PostgreSQL

Metabase 可以连接到 Pigsty 管理的 PostgreSQL 数据库。

在 Metabase 初始化或添加数据库时，选择「PostgreSQL」，然后输入连接信息：

TEXT
数据库类型：PostgreSQL
名称：自定义名称（如 "生产数据库"）
主机：10.10.10.10
端口：5432
数据库名：your_database
用户名：dbuser_meta
密码：DBUser.Meta

连接成功后，Metabase 会自动扫描数据库结构，您可以开始创建问题和仪表板。

功能特性

  • 无需 SQL：通过可视化界面构建查询
  • 丰富的图表类型：折线图、柱状图、饼图、地图等
  • 交互式仪表板：创建美观的数据仪表板
  • 自动刷新：定时更新数据和仪表板
  • 权限管理：精细的用户和数据访问控制
  • SQL 模式：高级用户可以直接编写 SQL
  • 嵌入功能：将图表嵌入到其他应用
  • 告警功能：数据变化自动通知

配置说明

Metabase 的配置在 .env 文件中：

BASH
# Metabase 元数据库（建议使用 PostgreSQL）
MB_DB_TYPE=postgres
MB_DB_DBNAME=metabase
MB_DB_PORT=5432
MB_DB_USER=dbuser_metabase
MB_DB_PASS=DBUser.Metabase
MB_DB_HOST=10.10.10.10

# 应用配置
JAVA_OPTS=-Xmx2g

建议：为 Metabase 使用独立的 PostgreSQL 数据库存储元数据。

数据持久化

Metabase 的元数据（用户、问题、仪表板等）存储在配置的数据库中。

如果使用 H2 数据库（默认），数据会保存在 /data/metabase 目录。强烈建议在生产环境中使用 PostgreSQL 作为元数据库。

性能优化

  • 使用 PostgreSQL：替代默认的 H2 数据库
  • 增加内存：通过 JAVA_OPTS=-Xmx4g 增加 JVM 内存
  • 数据库索引：为常查询的字段创建索引
  • 结果缓存：启用 Metabase 的查询结果缓存
  • 定时更新：合理设置仪表板的自动刷新频率

安全建议

  1. 修改默认凭据：修改元数据库的用户名和密码
  2. 启用 HTTPS：生产环境配置 SSL 证书
  3. 配置认证：启用 SSO 或 LDAP 认证
  4. 限制访问：通过防火墙限制访问
  5. 定期备份：备份 Metabase 元数据库

相关链接

15 - Kong：API 网关

使用 Pigsty Compose 模板部署 Kong（PostgreSQL 后端）。

Kong 是开源 API Gateway。

Pigsty 的 app/kong 模板使用 PostgreSQL 作为配置存储，并自动执行一次迁移任务（kong-migration）。

快速开始

BASH
cd ~/pigsty/app/kong
vi .env         # 检查 KONG_PG_* 与端口配置
make

默认端口：

  • Proxy HTTP：8000
  • Proxy HTTPS：8443
  • Admin API：8001

数据库准备

BASH
bin/pgsql-user pg-meta dbuser_kong
bin/pgsql-db   pg-meta kong

连接串示例：

BASH
postgres://dbuser_kong:DBUser.Kong@10.10.10.10:5432/kong

常用命令

BASH
make log
make stop
make clean
make pull

参考

16 - Registry：容器镜像缓存

使用 Pigsty 部署 Docker Registry Pull-Through Cache 与可选 Web UI。

Pigsty 提供 app/registry 配置模板（conf/app/registry.yml），用于部署：

  • Docker Registry 缓存服务（默认 5000）
  • 可选管理 UI（默认 5080）

快速开始

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap
./configure -c app/registry
vi pigsty.yml                 # 修改域名、证书与端口（如需）
./deploy.yml
./docker.yml
./app.yml

默认入口：

  • Registry API：http://<IP>:5000 或 http://d.pigsty
  • Registry UI：http://<IP>:5080 或 http://dui.pigsty

镜像数据目录默认为 /data/registry。

Docker 客户端配置

如果你使用 HTTP（无 TLS），Docker 需要显式信任该仓库：

JSON
{
  "registry-mirrors": ["http://d.pigsty"],
  "insecure-registries": ["d.pigsty:5000"]
}

修改 /etc/docker/daemon.json 后重启 Docker：

BASH
systemctl restart docker

运维命令

app/registry/Makefile 默认在 /opt/registry 工作：

BASH
cd /opt/registry
make up
make status
make health
make log

参考

17 - JumpServer：开源堡垒机

使用 Pigsty 自建 JumpServer 社区版，并将 PostgreSQL 后端数据库、备份、入口与运维纳入 Pigsty 管理。

JumpServer 是开源 PAM / 堡垒机系统，用于集中管理 SSH、RDP、数据库与 Web 资产访问。 Pigsty 的 app/jumpserver 模板使用 Docker Compose 运行 JumpServer 社区版应用层，并使用 Pigsty 托管的 PostgreSQL 作为持久后端数据库。

当前模板基于 JumpServer v4.10.16-ce，保留社区版 core、celery、koko、lion、chen、web 与本地 Redis，移除上游安装器中的内置 PostgreSQL 服务。 PostgreSQL、备份、监控、Nginx 入口和数据库生命周期由 Pigsty 管理。

快速开始

在运行 兼容操作系统 的全新 Linux x86 / ARM 服务器上执行：

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap
./configure -c app/jumpserver
vi pigsty.yml                 # 必改：密码、密钥、域名、IP

./deploy.yml                  # 安装 Pigsty、Infra、Etcd、PostgreSQL
./docker.yml                  # 安装 Docker 和 Compose
./app.yml                     # 安装 JumpServer

容器启动后执行一次数据库迁移：

BASH
cd /opt/jumpserver
make migrate
make health

默认入口：

TEXT
http://jump.pigsty
http://10.10.10.10:8080
ssh -p 2222 admin@10.10.10.10

默认 Web 登录：

TEXT
admin / ChangeMe

首次登录后应立即修改管理员密码。

部署前检查

  • 准备一台新 Linux 服务器，建议至少 2C4G，生产环境建议更大内存并配置 Swap。
  • 确认服务器 IP、DNS、NTP、SSH 与 sudo 可用。
  • 确认能访问 Docker Hub，或已经配置 docker_registry_mirrors / proxy_env。
  • 执行 ./configure -c app/jumpserver 后，修改 pigsty.yml 中的默认密码、SECRET_KEY、BOOTSTRAP_TOKEN 与 DOMAINS。
  • 确认 DOMAINS 包含浏览器实际访问的主机名或 IP，例如 10.10.10.10:8080。
  • 确认 PostgreSQL 备份任务正常，部署后检查 pig pb info 或 pgbackrest info。

配置模板

conf/app/jumpserver.yml 定义了单节点 JumpServer 自建模板。默认拓扑包括：

  • jumpserver：JumpServer 应用容器与本地 Redis 所在节点。
  • pg-jumpserver：Pigsty 托管的 PostgreSQL 数据库集群。
  • infra：Nginx 入口、Grafana、VictoriaMetrics 等基础设施。
  • etcd：Patroni 所需的分布式配置存储。

app.yml 会将 app/jumpserver 复制到 /opt/jumpserver，使用 apps.jumpserver.conf 覆盖 /opt/jumpserver/.env，然后执行 docker compose up -d。

核心应用服务：

  • jms_core：Django API / Web 后端，监听容器内 8080。
  • jms_celery：异步任务、定时任务与后台队列。
  • jms_web：Nginx Web 入口，默认映射宿主机 8080。
  • jms_koko：SSH / SFTP 终端入口，默认映射宿主机 2222。
  • jms_lion：Web Terminal 组件。
  • jms_chen：WebSocket / 数据库终端支持组件。
  • jms_redis：本地 Redis，用于缓存、队列与 Channels 后端。

关键参数

常见参数如下：

参数默认值说明
JUMPSERVER_VERSIONv4.10.16-ceJumpServer 社区版镜像版本
JUMPSERVER_DATA/data/jumpserver应用持久化目录
DOMAINS10.10.10.10:8080,10.10.10.10,jump.pigsty允许登录的可信访问域名 / IP
SECRET_KEY示例值加密密钥，生产必须替换且长期保存
BOOTSTRAP_TOKEN示例值组件注册令牌，生产必须替换且长期保存
DB_HOST / DB_PORT10.10.10.10 / 5432Pigsty PostgreSQL 入口
DB_USER / DB_NAMEjumpserver / jumpserver业务用户与业务数据库
DB_PASSWORDDBUser.JumpServer业务用户密码，生产必须替换
DOCKER_SUBNET192.168.250.0/24JumpServer Compose 内部网段
REDIS_HOST192.168.250.2本地 Redis 容器固定 IP
CORE_HOSThttp://192.168.250.4:8080JumpServer core 内部入口
HTTP_PORT8080Web 入口端口
SSH_PORT2222Koko SSH/SFTP 入口端口
CORE_WORKER2core Gunicorn worker 数，适配 2C4G 沙箱
CELERY_WORKER_COUNT2每个 Celery 队列 worker 并发数

生成生产密钥示例：

BASH
openssl rand -base64 36 | tr -dc A-Za-z0-9 | head -c 48; echo
openssl rand -base64 24 | tr -dc A-Za-z0-9 | head -c 24; echo

登录与 DOMAINS

JumpServer 会在登录流程中检查可信访问域名。DOMAINS 必须包含浏览器实际访问的 Host：

INI
DOMAINS=10.10.10.10:8080,10.10.10.10,jump.pigsty

正常登录 URL：

TEXT
http://10.10.10.10:8080/core/auth/login/?admin=1

如果登录页显示：

TEXT
配置文件有问题，无法登录...
DOMAINS=10.10.10.10:8080

请检查 /opt/jumpserver/.env 与容器环境：

BASH
cd /opt/jumpserver
grep '^DOMAINS=' .env
docker exec jms_core env | grep '^DOMAINS='

修正后需要重建 core 容器：

BASH
sudo sed -i 's#^DOMAINS=.*#DOMAINS=10.10.10.10:8080,10.10.10.10,jump.pigsty#' /opt/jumpserver/.env
docker compose up -d --force-recreate core

同时修改 pigsty.yml 或 conf/app/jumpserver.yml，否则下次执行 ./app.yml 会再次覆盖 /opt/jumpserver/.env。

不要用带 csrf_failure=1 的旧 URL 判断配置是否仍然错误；该页面会按照失败请求上下文显示 DOMAINS=... 提示。应使用正常登录页重新测试，必要时打开无痕窗口。

Docker 网络

模板使用固定 Docker bridge 网段：

INI
DOCKER_SUBNET=192.168.250.0/24
REDIS_IP=192.168.250.2
CELERY_IP=192.168.250.3
CORE_IP=192.168.250.4
LION_IP=192.168.250.5
CHEN_IP=192.168.250.6
KOKO_IP=192.168.250.7
WEB_IP=192.168.250.8

固定 IP 有两个目的：

  • 避免 JumpServer Python / Java 组件启动时遇到 Docker DNS 临时解析失败。
  • 让 PostgreSQL HBA 规则可以精确放行应用网段。

PostgreSQL 看到的容器客户端来源是 192.168.250.0/24，因此模板包含：

YAML
pg_hba_rules:
  - { user: jumpserver ,db: jumpserver ,addr: 192.168.250.0/24 ,auth: pwd ,order: 560 ,title: 'allow jumpserver access from docker bridge' }
pgb_hba_rules:
  - { user: jumpserver ,db: jumpserver ,addr: 192.168.250.0/24 ,auth: pwd ,order: 390 ,title: 'allow jumpserver pgbouncer access from docker bridge' }

如果 192.168.250.0/24 与现有网络冲突，需要同时修改：

  • DOCKER_SUBNET 与各组件固定 IP。
  • REDIS_HOST、CORE_HOST。
  • pg_hba_rules.addr 与 pgb_hba_rules.addr。
  • 重新创建 Compose 网络与容器。

不要把 DB_HOST 设置为 127.0.0.1；在容器里这指向容器自身。请使用宿主机内网 IP 或 Pigsty L2 VIP。

PostgreSQL

JumpServer 4.x 使用 PostgreSQL，并要求 PostgreSQL 16 或更新版本。模板使用 Pigsty 创建数据库、用户、HBA、备份计划和可选 PgBouncer 入口。

应用数据库不需要额外 PostgreSQL 扩展：

YAML
pg_extensions: []
pg_users:
  - { name: jumpserver ,password: DBUser.JumpServer ,pgbouncer: true ,pool_mode: session ,roles: [ dbrole_admin ] }
pg_databases:
  - { name: jumpserver ,owner: jumpserver }

模板中的 pg_version 可以按环境固定为 16、17 或更新主版本；JumpServer 的下限是 PostgreSQL 16。若使用高可用数据库形态，可以参考模板中注释的 pg_vip_enabled 示例，将应用侧 DB_HOST 指向主库 VIP。

部署验证

安装后执行：

BASH
cd /opt/jumpserver
make status
make health
make migrate

期望：

  • jms_core、jms_celery、jms_web、jms_redis、jms_koko、jms_lion、jms_chen 均为 healthy。
  • make health 返回 status=true、db_status=true、redis_status=true。
  • make migrate 输出 No migrations to apply，或完成缺失迁移。

数据库侧检查：

BASH
sudo -iu postgres patronictl -c /etc/patroni/patroni.yml list
sudo -iu postgres psql -Atqc "select current_setting('server_version'), count(*) from information_schema.tables where table_schema='public'" jumpserver
sudo -iu postgres pgbackrest --stanza=pg-jumpserver info

期望：

  • Patroni 集群 Leader running。
  • PostgreSQL 版本为 16 或更新。
  • JumpServer 迁移后 public schema 中有约 168 张表。
  • pgBackRest stanza 状态为 ok。

常见问题

登录页提示 DOMAINS 配置错误

确认两层配置一致：

BASH
cd /opt/jumpserver
grep '^DOMAINS=' .env
docker exec jms_core env | grep '^DOMAINS='

修改 .env 后必须重建 core 容器：

BASH
docker compose up -d --force-recreate core

同时修改 Pigsty inventory 中的 apps.jumpserver.conf.DOMAINS，否则下次 ./app.yml 会覆盖。

admin / ChangeMe 无法登录

先区分两类错误：

  • 页面顶部是 DOMAINS=... 红框：这是域名 / CSRF 配置问题，不是密码问题。
  • 表单提示用户名或密码错误：才是账号密码问题。

可在容器内验证默认密码是否仍然有效：

BASH
docker exec -w /opt/jumpserver/apps jms_core python -c '
import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "jumpserver.settings")
import django; django.setup()
from django.contrib.auth import get_user_model
u = get_user_model().objects.get(username="admin")
print(u.is_active, u.check_password("ChangeMe"))
'

Web 返回 502

检查 core 与 web：

BASH
cd /opt/jumpserver
docker compose ps
docker logs --tail 100 jms_core
docker logs --tail 100 jms_web

如果是首次启动时 core 日志目录竞争，确认 /data/jumpserver/core/data/logs 已存在。模板已预创建该目录。

容器反复重启或健康检查超时

2C4G 节点上 JumpServer 较吃内存，模板默认使用：

INI
CORE_WORKER=2
CELERY_WORKER_COUNT=2

如果仍然出现 Gunicorn worker timeout、SIGKILL 或系统内存不足，请增加内存 / Swap，或继续降低 worker 数。查看资源：

BASH
free -h
docker stats --no-stream

运维命令

安装后进入 /opt/jumpserver：

BASH
cd /opt/jumpserver

make up        # 启动 JumpServer
make down      # 停止 JumpServer
make restart   # 重启容器
make status    # 查看容器状态
make log       # 跟随日志
make health    # 检查 HTTP / DB / Redis 健康
make migrate   # 执行 ./jms upgrade_db
make exec      # 进入 core 容器

升级 JumpServer 时不要只修改镜像标签，必须执行数据库迁移：

BASH
cd /opt/jumpserver
make pull
make down
docker compose up -d redis core
make migrate
make up

升级期间保持 SECRET_KEY 与 BOOTSTRAP_TOKEN 不变。

备份与恢复

JumpServer 状态分为两层：

  • PostgreSQL 数据库：使用 Pigsty pgBackRest / PITR 备份。
  • 应用文件：/data/jumpserver 与 /opt/jumpserver/.env，包含日志、录像、组件数据、Redis 持久化和密钥。

恢复时应使用同一环境中的数据库、.env 与文件目录：

BASH
# 1. 使用 Pigsty pgBackRest / PITR 恢复 PostgreSQL
# 2. 恢复 /opt/jumpserver/.env 与 /data/jumpserver
# 3. 启动容器并执行迁移
cd /opt/jumpserver
make up
make migrate
make health

只恢复 PostgreSQL 而没有原始 SECRET_KEY，会导致 JumpServer 中加密保存的账号密钥无法正常解密。

社区版边界

本模板使用 PostgreSQL 作为 JumpServer 自身后端数据库，属于社区版自建部署路径。JumpServer 中“数据库资产管理”是另一项产品能力，和这里的后端数据库不是同一件事，请不要混淆。

参考

18 - ByteBase：模式迁移

使用 Pigsty 提供的 Docker Compose 模板部署 Bytebase，并接入外部 PostgreSQL。

Bytebase 是数据库 Schema 变更与版本管理工具。

Pigsty 在 app/bytebase 中提供了可直接使用的 Compose 模板，默认监听 8887，并通过 BB_PGURL 连接外部 PostgreSQL。

快速开始

BASH
cd ~/pigsty/app/bytebase
vi .env         # 检查 BB_PORT / BB_DOMAIN / BB_PGURL
make up

访问：

  • http://ddl.pigsty
  • http://<IP>:8887

首次启动后，请按 Bytebase 向导初始化管理员账号。

外部 PostgreSQL

默认连接串示例：

BASH
postgresql://dbuser_bytebase:DBUser.Bytebase@10.10.10.10:5432/bytebase?sslmode=prefer

可先在 Pigsty 中创建业务用户与数据库：

BASH
bin/pgsql-user pg-meta dbuser_bytebase
bin/pgsql-db   pg-meta bytebase

常用命令

BASH
make up
make log
make info
make stop
make clean

参考

19 - pgAdmin：PostgreSQL 图形管理工具

使用 Pigsty 的 Docker Compose 应用模板部署 pgAdmin4，并安全加载 PostgreSQL 服务器清单。

pgAdmin 是 PostgreSQL 的开源图形管理与开发工具。Pigsty v4.5.0 提供 app/pgadmin Docker Compose 模板，并可从当前清单生成服务器列表与密码文件。

快速开始

conf/meta.yml 默认在 app 组声明 pgAdmin。使用明确限定的目标执行部署：

BASH
./docker.yml -l app
./app.yml -l app -e app=pgadmin

默认端口为 8885，可从 http://<app_ip>:8885 访问。只有在 infra_portal、Nginx 与 DNS 已配置时，http://adm.pigsty 才是有效入口。

容器首次启动可能需要几十秒，可在应用节点检查：

BASH
cd /opt/pgadmin
make info
make log

应用配置

推荐在 pigsty.yml 的 app 组通过 apps.pgadmin.conf 覆盖 .env：

YAML
all:
  children:
    app:
      hosts: { 10.10.10.10: {} }
      vars:
        docker_enabled: true
        app: pgadmin
        apps:
          pgadmin:
            conf:
              PGADMIN_DEFAULT_EMAIL: dba@example.com
              PGADMIN_DEFAULT_PASSWORD: <strong-random-password>
              PGADMIN_LISTEN_ADDRESS: 0.0.0.0
              PGADMIN_PORT: 8885
              PGADMIN_SERVER_JSON_FILE: /pgadmin4/servers.json
              PGADMIN_REPLACE_SERVERS_ON_STARTUP: true

app.yml 会把模板复制到 /opt/pgadmin 并将覆盖项写入 /opt/pgadmin/.env。该文件包含登录密码，权限应保持为 0600。

当前模板使用未固定标签的 dpage/pgadmin4 镜像。生产环境应在 docker-compose.yml 中固定经过验证的版本或镜像摘要，并把镜像升级当作独立变更验证。

加载服务器列表

env_pgadmin 根据清单生成：

  • /infra/pgadmin/servers.json：PostgreSQL 实例列表
  • /infra/pgadmin/pgpass：数据库管理员密码文件

默认 conf/meta.yml 中 infra 与 app 组指向同一台主机，因此 pgAdmin 可以直接只读挂载这两个文件。如果 pgAdmin 与 Infra 分离部署，应用节点不会自动拥有 /infra/pgadmin/；必须另行安全分发等价文件或自定义挂载，不能假设跨主机共享本地路径。

在默认同机拓扑中，可先重新生成列表，再让已启动的容器导入列表与密码：

BASH
./infra.yml -l infra -t env_pgadmin

./app.yml -l app -e app=pgadmin -t app_launch -e app_args=reload

pgpass 包含 pg_admin_username 的数据库凭据。请限制文件、备份和应用主机的访问范围；若不希望 pgAdmin 持有 DBA 凭据，应自行生成最小权限的连接定义。

域名与 HTTPS

在 infra_portal 中添加入口：

YAML
all:
  vars:
    infra_portal:
      pgadmin:
        domain: adm.pigsty
        endpoint: "10.10.10.10:8885"

在明确限定的 Infra 组上更新 Nginx：

BASH
./infra.yml -l infra -t nginx

公网真实域名还需 DNS 指向服务器，并在 portal 条目中设置 certbot：

YAML
infra_portal:
  pgadmin:
    domain: adm.example.com
    endpoint: "10.10.10.10:8885"
    certbot: adm.example.com
BASH
./infra.yml -l infra -t nginx_certbot,nginx_reload -e certbot_sign=true

证书前置条件与续期方式参见 CA 与证书。不要把直接暴露的 8885 端口视为 HTTPS 入口。

状态与管理

在 /opt/pgadmin 中可使用：

BASH
make up       # docker compose up -d
make view     # 显示访问地址
make log      # 跟随容器日志
make info     # docker inspect
make conf     # 重新导入服务器列表与 pgpass
make stop     # 停止容器
make restart  # 重启容器

Compose 模板没有为 /var/lib/pgadmin 配置持久卷。服务器清单可从 Pigsty 文件重新导入，但在 pgAdmin UI 中新增的偏好、用户与其他内部状态可能随容器重建而丢失；如需保留，应在变更模板后为该目录配置受保护的持久卷并纳入备份。

pgAdmin

安全检查

  • 修改默认 pgAdmin 登录名与密码，不在脚本、截图或工单中传播真实凭据。
  • 默认端口映射会监听主机网络；用防火墙限制来源，公网入口使用 Nginx 与有效 HTTPS 证书。
  • 保护 /infra/pgadmin/pgpass 与 /opt/pgadmin/.env，优先使用最小权限数据库角色。
  • 固定并验证容器镜像版本，备份任何新增的 pgAdmin 持久状态。
  • pgAdmin 能执行高权限 SQL；删除数据库、表或数据前仍需独立确认目标与近期备份。

20 - PGWeb：网页客户端

使用 Docker 拉起 PGWEB，以便从浏览器进行小批量在线数据查询

PGWeb 客户端

PGWeb 是一款基于浏览器的 PostgreSQL 客户端。Pigsty 在 app/pgweb 中提供了一个小型 Docker Compose 模板，把容器的 8081 端口发布到主机的 8886 端口。

BASH
cd ~/pigsty/app/pgweb
make up                    # docker compose up -d

当 cli.pigsty 门户项解析到 Infra 节点时，可打开 http://cli.pigsty，也可以直接访问 http://10.10.10.10:8886。公开演示地址为 http://cli.pigsty.cc。

PGWeb 会要求输入 PostgreSQL 连接 URL，例如：

TEXT
postgres://dbuser_meta:DBUser.Meta@10.10.10.10:5432/meta?sslmode=disable
postgres://test:test@10.10.10.11:5432/test?sslmode=disable

这些字符串包含公开的演示默认密码并关闭 TLS。实际部署应使用最小权限账户、非默认密码和合适的 sslmode， 不要把未加额外访问控制的 PGWeb 容器或数据库凭据暴露给不可信网络。

PGWeb

快捷方式

模板附带的 Makefile 提供：

BASH
make up         # 使用 docker compose 启动
make run        # 使用 docker run 启动
make view       # 打印本地访问入口与示例 URL
make log        # 跟踪容器日志
make info       # 使用 jq 检查容器
make stop       # 停止容器
make clean      # 停止并删除容器
make pull       # 拉取当前未固定版本的 sosedoff/pgweb 镜像
make rmi        # 删除本地镜像
make save       # 将镜像保存到 /tmp/docker/pgweb.tgz
make load       # 从 /tmp/docker/pgweb.tgz 加载镜像

当前模板使用未固定版本的 sosedoff/pgweb 镜像；若正式环境要求部署可复现，应在 app/pgweb/docker-compose.yml 中固定镜像版本或摘要。

21 - PostgREST：自动 API

使用 Pigsty Compose 模板部署 PostgREST，基于 PostgreSQL 模式自动生成 REST API。

PostgREST 可以将 PostgreSQL schema 直接暴露为 REST API。

Pigsty 提供 app/postgrest 模板，默认端口 8884。

快速开始

BASH
cd ~/pigsty/app/postgrest
vi .env         # 检查 DB_URI / DB_SCHEMA / JWT
make up

默认入口：

  • http://<IP>:8884
  • 若配置了入口域名，可通过 http://api.pigsty 访问

关键配置

.env 常用参数：

  • POSTGREST_DB_URI：数据库连接串
  • POSTGREST_DB_SCHEMA：暴露的 schema（默认 pigsty）
  • POSTGREST_DB_ANON_ROLE：匿名角色
  • POSTGREST_JWT_SECRET：JWT 密钥

Swagger UI（可选）

可单独拉起 Swagger UI 预览 API：

BASH
docker run --rm --name swagger -p 8882:8080 \
  -e API_URL=http://10.10.10.10:8884 \
  swaggerapi/swagger-ui

访问 http://<IP>:8882。

常用命令

BASH
make up
make log
make stop
make clean

参考

22 - Electric：PostgreSQL 同步引擎

使用 Pigsty 自建 Electric，同步 PostgreSQL 数据到前端应用，支持部分复制与实时分发。

Electric 是 PostgreSQL 同步引擎，专注于将数据库变更高效分发到前端/边缘应用。

Pigsty 提供了 app/electric 配置模板（conf/app/electric.yml），可一键完成数据库、容器与入口配置。

快速开始

BASH
curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./bootstrap
./configure -c app/electric
vi pigsty.yml                 # 修改域名、密码、密钥
./deploy.yml
./docker.yml
./app.yml

默认访问地址：

  • http://<IP>:8002
  • http://elec.pigsty（按模板默认域名）

指标端口默认 8003（ELECTRIC_PROMETHEUS_PORT）。

关键配置

conf/app/electric.yml 会在 apps.electric.conf 中覆盖 /opt/electric/.env。常见参数：

  • DATABASE_URL：Electric 使用的 PostgreSQL 连接串（需要复制权限）
  • ELECTRIC_PORT：Electric HTTP 服务端口（默认 8002）
  • ELECTRIC_PROMETHEUS_PORT：指标端口（默认 8003）
  • ELECTRIC_INSECURE：开发环境可设为 true，生产环境建议关闭并使用密钥

运维命令

BASH
cd /opt/electric
make up
make logs
make down

参考

23 - Jupyter：Notebook 与数据分析环境

使用 Pigsty 的独立 Docker Compose 模板运行 JupyterLab，并安全访问 PostgreSQL。

JupyterLab 是交互式 Notebook、终端与数据分析环境。Pigsty v4.5.0 有两种不同的部署方式：

  • VIBE 模块：由 Ansible 和 systemd 管理，适合 v4.5.0 的完整开发沙箱。
  • app/jupyter：轻量的独立 Docker Compose 模板，本页介绍这一方式。

app/jupyter 不是默认 apps 清单项，且创建数据目录是独立步骤；不要直接假设 app.yml -e app=jupyter 能处理目录权限。

JupyterLab

快速开始

BASH
cd ~/pigsty/app/jupyter
vi .env                    # 修改 JUPYTER_TOKEN，并按需固定 JUPYTER_IMAGE
chmod 600 .env
make dir                   # 创建 /data/jupyter，属主 1000:100
make up                    # docker compose up -d

可用 openssl rand -hex 32 生成强 Token。默认端口为 8888，从 http://<host_ip>:8888 访问。

只有在 infra_portal、Nginx 与 DNS 中配置了 lab.pigsty 时，该域名才可用。模板默认值 JUPYTER_TOKEN=pigsty 只能用于本地演示，生产环境必须更换。

当前模板

.env 的 v4.5.0 默认值为：

BASH
JUPYTER_IMAGE=quay.io/jupyter/minimal-notebook:latest
JUPYTER_PORT=8888
JUPYTER_TOKEN=pigsty

Compose 将宿主机 /data/jupyter 挂载到容器的 /home/jovyan/work，并把 Token 传给容器。latest 会随上游变化；生产环境应改为经过验证的具体镜像标签或摘要。

若需要 SciPy、R、Julia、TensorFlow、PyTorch 或 Spark，可使用 .env 中列出的其他 Jupyter Docker Stacks 镜像，但仍应固定版本并验证架构支持。

访问 PostgreSQL

在 Jupyter Terminal 中安装现代 Psycopg 驱动及可选分析库：

BASH
pip install "psycopg[binary]" pandas sqlalchemy

不要把真实密码写入 Notebook。以下示例通过隐藏输入获得连接串，只读取系统信息：

PYTHON
from getpass import getpass
import psycopg

pgurl = getpass("PostgreSQL URL: ")
with psycopg.connect(pgurl) as conn:
    with conn.cursor() as cur:
        cur.execute("SELECT current_database(), current_user, version()")
        print(cur.fetchone())

使用 Pandas 与 SQLAlchemy 查询系统统计视图：

PYTHON
import pandas as pd
from sqlalchemy import create_engine

engine = create_engine(pgurl)
df = pd.read_sql(
    "SELECT datname, numbackends, xact_commit, xact_rollback "
    "FROM pg_stat_database ORDER BY datname",
    engine,
)
df

这些示例只访问系统视图。读取业务表前，应得到数据所有者授权，并限制列、条件和结果规模。

持久化与依赖

只有 /home/jovyan/work 映射到 /data/jupyter。以下内容默认不会随容器重建持久化：

  • 在容器环境中临时安装的 Python/Conda 包
  • work 目录以外的 Notebook、配置与缓存
  • 容器自身的用户状态

生产环境应通过固定镜像、定制 Dockerfile 或可复现的依赖文件安装包，并单独备份 /data/jupyter。持久卷不能替代备份。

管理命令

在 ~/pigsty/app/jupyter 中：

BASH
make up      # 启动 JupyterLab
make dir     # 创建数据目录并设置 1000:100 权限
make view    # 显示访问地址
make log     # 跟随日志
make info    # 检查容器
make stop    # 停止容器
make pull    # 拉取 .env 指定的镜像

make clean 会移除容器但保留 /data/jupyter；make purge 会递归删除 /data/jupyter，属于不可恢复的数据删除操作，执行前必须确认精确目录与近期备份。

安全建议

  • 使用随机强 Token，保护 .env，不要禁用认证。
  • 默认端口映射监听主机网络；用防火墙限制来源，优先通过 Nginx 与有效 HTTPS 证书访问。
  • Notebook 可执行任意代码并访问挂载文件与数据库；只授予最小权限的数据库账号和宿主机目录。
  • 固定镜像版本、扫描镜像并对依赖升级做可复现验证。
  • 定期备份 /data/jupyter，并实际验证恢复到临时目录。

相关链接

24 - PGLOG：PG自带日志分析应用

Pigsty 自带的，用于分析 PostgreSQL CSV 日志样本的一个样例 Applet

PGLOG 是 Pigsty 自带的一个样例应用，固定使用 MetaDB 中 pglog.sample 表作为数据来源。您只需要将日志灌入该表，然后访问相关 Dashboard 即可。

Pigsty 提供了一些趁手的命令，用于拉取 csv 日志，并灌入样本表中。在元节点上，默认提供下列快捷命令：

BASH
catlog  [node=localhost]  [date=today]   # 打印CSV日志到标准输出
pglog                                    # 从标准输入灌入CSVLOG
pglog12                                  # 灌入PG12格式的CSVLOG
pglog13                                  # 灌入PG13格式的CSVLOG
pglog14                                  # 灌入PG14格式的CSVLOG (=pglog)

catlog | pglog                       # 分析当前节点当日的日志
catlog node-1 '2021-07-15' | pglog   # 分析node-1在2021-07-15的csvlog

接下来，您可以访问以下的连接，查看样例日志分析界面。

  • PGLOG Overview：呈现整份 CSV 日志样本详情，按多种维度聚合。

PGLOG Overview 仪表盘

  • PGLOG Session：呈现日志样本中一条具体连接的详细信息。

PGLOG Session 仪表盘

catlog 命令从特定节点拉取特定日期的 CSV 数据库日志，写入 stdout

默认情况下，catlog 会拉取当前节点当日的日志，您可以通过参数指定节点与日期。

组合使用 pglog 与 catlog，即可快速拉取数据库 CSV 日志进行分析。

BASH
catlog | pglog                       # 分析当前节点当日的日志
catlog node-1 '2021-07-15' | pglog   # 分析node-1在2021-07-15的csvlog

25 - NOAA ISD 全球气象站历史数据查询

以 ISD 数据集为例，展现如何将数据导入数据库中

如果您拥有数据库后不知道干点什么，不妨参试试这个开源项目：Vonng/isd

您可以直接复用监控系统 Grafana，以交互式的方式查阅近30000个地面气象站过去120年间的亚小时级气象数据。

这是一个功能完成的数据应用，可以查询全球30000个地表气象站从1901年来的气象观测记录。

项目地址：https://github.com/Vonng/isd

在线 Demo 地址：https://demo.pigsty.cc/d/isd-overview

isd-overview.jpg

快速上手

克隆本仓库

BASH
git clone https://github.com/Vonng/isd.git; cd isd;

准备一个 PostgreSQL 实例

该 PostgreSQL 实例应当启用了 PostGIS 扩展。使用 PGURL 环境变量传递数据库连接信息：

BASH
# Pigsty 默认使用的管理员账号是 dbuser_dba，密码是 DBUser.DBA
export PGURL=postgres://dbuser_dba:DBUser.DBA@127.0.0.1:5432/meta?sslmode=disable
psql "${PGURL}" -c 'SELECT 1'  # 检查连接是否可用

获取并导入 ISD 气象站元数据

这是一份每日更新的气象站元数据，包含了气象站的经纬度、海拔、名称、国家、省份等信息，使用以下命令下载并导入。

BASH
make reload-station   # 相当于先下载最新的Station数据再加载：get-station + load-station

获取并导入最新的 isd.daily 数据

isd.daily 是一个每日更新的数据集，包含了全球各气象站的日观测数据摘要，使用以下命令下载并导入。 请注意，直接从 NOAA 网站下载的原始数据需要经过 解析 方可入库，所以你需要下载或构建一个 ISD 数据 Parser。

BASH
make get-parser       # 从 Github 下载 Parser 二进制，当然你也可以用 make build 直接用 go 构建。
make reload-daily     # 下载本年度最新的 isd.daily 数据并导入数据库中

加载解析好的 CSV 数据集

ISD Daily 数据集有一些脏数据与 重复数据，如果你不想手工解析处理清洗，这里也提供了一份解析好的稳定 CSV 数据集。

该数据集包含了截止到 2023-06-24 的 isd.daily 数据，你可以直接下载并导入 PostgreSQL 中，不需要 Parser，

BASH
make get-stable       # 从 Github 上获取稳定的 isd.daily 历史数据集。
make load-stable      # 将下载好的稳定历史数据集加载到 PostgreSQL 数据库中。

更多数据

ISD 数据集有两个部分是每日更新的，气象站元数据，以及最新年份的 isd.daily （如 2023 年的 Tarball）。

你可以使用以下命令下载并刷新这两个部分。如果数据集没有更新，那么这些命令不会重新下载同样的数据包

BASH
make reload           # 实际上是：reload-station + reload-daily

你也可以使用以下命令下载并加载特定年份的 isd.daily 数据：

BASH
bin/get-daily  2022                   # 获取 2022 年的每日气象观测摘要 (1900-2023)
bin/load-daily "${PGURL}" 2022        # 加载 2022 年的每日气象观测摘要 (1900-2023)

除了每日摘要 isd.daily， ISD 还提供了一份更详细的亚小时级原始观测记录 isd.hourly，下载与加载的方式与前者类似：

BASH
bin/get-hourly  2022                  # 下载特定某一年的小时级观测记录（例如2022年，可选 1900-2023）
bin/load-hourly "${PGURL}" 2022       # 加载特定某一年的小时级观测记录

数据

数据集概要

ISD 提供了四个数据集：亚小时级原始观测数据，每日统计摘要数据，月度统计摘要，年度统计摘要

数据集备注
ISD Hourly亚小时级观测记录
ISD Daily每日统计摘要
ISD Monthly没有用到，因为可以从 isd.daily 计算生成
ISD Yearly没有用到，因为可以从 isd.daily 计算生成

每日摘要数据集

  • 压缩包大小 2.8GB (截止至 2023-06-24)
  • 表大小 24GB，索引大小 6GB，PostgreSQL 中总大小约为 30GB
  • 如果启用了 timescaledb 压缩，总大小可以压缩到 4.5 GB。

亚小时级观测数据级

  • 压缩包总大小 117GB
  • 灌入数据库后表大小 1TB+，索引大小 600GB+，总大小 1.6TB

数据库模式

气象站元数据表

SQL
CREATE TABLE isd.station
(
    station    VARCHAR(12) PRIMARY KEY,
    usaf       VARCHAR(6) GENERATED ALWAYS AS (substring(station, 1, 6)) STORED,
    wban       VARCHAR(5) GENERATED ALWAYS AS (substring(station, 7, 5)) STORED,
    name       VARCHAR(32),
    country    VARCHAR(2),
    province   VARCHAR(2),
    icao       VARCHAR(4),
    location   GEOMETRY(POINT),
    longitude  NUMERIC GENERATED ALWAYS AS (Round(ST_X(location)::NUMERIC, 6)) STORED,
    latitude   NUMERIC GENERATED ALWAYS AS (Round(ST_Y(location)::NUMERIC, 6)) STORED,
    elevation  NUMERIC,
    period     daterange,
    begin_date DATE GENERATED ALWAYS AS (lower(period)) STORED,
    end_date   DATE GENERATED ALWAYS AS (upper(period)) STORED
);

每日摘要表

SQL
CREATE TABLE IF NOT EXISTS isd.daily
(
    station     VARCHAR(12) NOT NULL, -- station number 6USAF+5WBAN
    ts          DATE        NOT NULL, -- observation date
    -- 气温 & 露点
    temp_mean   NUMERIC(3, 1),        -- mean temperature ℃
    temp_min    NUMERIC(3, 1),        -- min temperature ℃
    temp_max    NUMERIC(3, 1),        -- max temperature ℃
    dewp_mean   NUMERIC(3, 1),        -- mean dew point ℃
    -- 气压
    slp_mean    NUMERIC(5, 1),        -- sea level pressure (hPa)
    stp_mean    NUMERIC(5, 1),        -- station pressure (hPa)
    -- 可见距离
    vis_mean    NUMERIC(6),           -- visible distance (m)
    -- 风速
    wdsp_mean   NUMERIC(4, 1),        -- average wind speed (m/s)
    wdsp_max    NUMERIC(4, 1),        -- max wind speed (m/s)
    gust        NUMERIC(4, 1),        -- max wind gust (m/s) 
    -- 降水 / 雪深
    prcp_mean   NUMERIC(5, 1),        -- precipitation (mm)
    prcp        NUMERIC(5, 1),        -- rectified precipitation (mm)
    sndp        NuMERIC(5, 1),        -- snow depth (mm)
    -- FRSHTT (Fog/Rain/Snow/Hail/Thunder/Tornado) 雾/雨/雪/雹/雷/龙卷
    is_foggy    BOOLEAN,              -- (F)og
    is_rainy    BOOLEAN,              -- (R)ain or Drizzle
    is_snowy    BOOLEAN,              -- (S)now or pellets
    is_hail     BOOLEAN,              -- (H)ail
    is_thunder  BOOLEAN,              -- (T)hunder
    is_tornado  BOOLEAN,              -- (T)ornado or Funnel Cloud
    -- 统计聚合使用的记录数
    temp_count  SMALLINT,             -- record count for temp
    dewp_count  SMALLINT,             -- record count for dew point
    slp_count   SMALLINT,             -- record count for sea level pressure
    stp_count   SMALLINT,             -- record count for station pressure
    wdsp_count  SMALLINT,             -- record count for wind speed
    visib_count SMALLINT,             -- record count for visible distance
    -- 气温标记
    temp_min_f  BOOLEAN,              -- aggregate min temperature
    temp_max_f  BOOLEAN,              -- aggregate max temperature
    prcp_flag   CHAR,                 -- precipitation flag: ABCDEFGHI
    PRIMARY KEY (station, ts)
); -- PARTITION BY RANGE (ts);

亚小时级原始观测数据表

ISD Hourly
SQL
CREATE TABLE IF NOT EXISTS isd.hourly
(
    station    VARCHAR(12) NOT NULL, -- station id
    ts         TIMESTAMP   NOT NULL, -- timestamp
    -- air
    temp       NUMERIC(3, 1),        -- [-93.2,+61.8]
    dewp       NUMERIC(3, 1),        -- [-98.2,+36.8]
    slp        NUMERIC(5, 1),        -- [8600,10900]
    stp        NUMERIC(5, 1),        -- [4500,10900]
    vis        NUMERIC(6),           -- [0,160000]
    -- wind
    wd_angle   NUMERIC(3),           -- [1,360]
    wd_speed   NUMERIC(4, 1),        -- [0,90]
    wd_gust    NUMERIC(4, 1),        -- [0,110]
    wd_code    VARCHAR(1),           -- code that denotes the character of the WIND-OBSERVATION.
    -- cloud
    cld_height NUMERIC(5),           -- [0,22000]
    cld_code   VARCHAR(2),           -- cloud code
    -- water
    sndp       NUMERIC(5, 1),        -- mm snow
    prcp       NUMERIC(5, 1),        -- mm precipitation
    prcp_hour  NUMERIC(2),           -- precipitation duration in hour
    prcp_code  VARCHAR(1),           -- precipitation type code
    -- sky
    mw_code    VARCHAR(2),           -- manual weather observation code
    aw_code    VARCHAR(2),           -- auto weather observation code
    pw_code    VARCHAR(1),           -- weather code of past period of time
    pw_hour    NUMERIC(2),           -- duration of pw_code period
    -- misc
    -- remark     TEXT,
    -- eqd        TEXT,
    data       JSONB                 -- extra data
) PARTITION BY RANGE (ts);

解析器

NOAA ISD 提供的原始数据是高度压缩的专有格式，需要通过解析器加工，才能转换为数据库表的格式。

针对 Daily 与 Hourly 两份数据集，这里提供了两个 Parser： isdd and isdh。 这两个解析器都以年度数据压缩包作为输入，产生 CSV 结果作为输出，以管道的方式工作，如下所示：

BASH
NAME
        isd -- Intergrated Surface Dataset Parser

SYNOPSIS
        isd daily   [-i <input|stdin>] [-o <output|stout>] [-v]
        isd hourly  [-i <input|stdin>] [-o <output|stout>] [-v] [-d raw|ts-first|hour-first]

DESCRIPTION
        The isd program takes noaa isd daily/hourly raw tarball data as input.
        and generate parsed data in csv format as output. Works in pipe mode

        cat data/daily/2023.tar.gz | bin/isd daily -v | psql ${PGURL} -AXtwqc "COPY isd.daily FROM STDIN CSV;" 

        isd daily  -v -i data/daily/2023.tar.gz  | psql ${PGURL} -AXtwqc "COPY isd.daily FROM STDIN CSV;"
        isd hourly -v -i data/hourly/2023.tar.gz | psql ${PGURL} -AXtwqc "COPY isd.hourly FROM STDIN CSV;"

OPTIONS
        -i  <input>     input file, stdin by default
        -o  <output>    output file, stdout by default
        -p  <profpath>  pprof file path, enable if specified
        -d              de-duplicate rows for hourly dataset (raw, ts-first, hour-first)
        -v              verbose mode
        -h              print help

用户界面

这里提供了几个使用 Grafana 制作的 Dashboard，可以用于探索 ISD 数据集，查询气象站与历史气象数据。

ISD Overview

全局概览，总体指标与气象站导航。

isd-overview.jpg

ISD Country

展示单个国家/地区内所有的气象站。

isd-country.jpg

ISD Station

展示单个气象站的详细信息，元数据，天/月/年度汇总指标。

ISD Station Dashboard

isd-station.jpg

ISD Detail

展示一个气象站原始亚小时级观测指标数据，需要 isd.hourly 数据集。

ISD Station Dashboard

isd-detail.jpg




26 - COVID-19 数据大盘

Pigsty 自带的，用于展示世界卫生组织官方 COVID 疫情数据的一个样例 Applet

Covid 是 Pigsty 自带的，用于展示世界卫生组织官方疫情数据大盘的一个样例 Applet。

您可以查阅每个国家与地区 COVID-19 的感染与死亡案例，以及全球的疫情趋势。

概览

GitHub 仓库地址：https://github.com/Vonng/pigsty-app/tree/master/covid

在线 Demo 地址：https://demo.pigsty.cc/d/covid

COVID-19 数据分析仪表盘

安装

在管理节点上进入应用目录，执行 make 以完成安装。

BASH
make            # 完成所有配置

其他一些子任务：

BASH
make reload     # download latest data and pour it again
make ui         # install grafana dashboards
make sql        # install database schemas
make download   # download latest data
make load       # load downloaded data into database
make reload     # download latest data and pour it into database

27 - StackOverflow 调研

分析 StackOverflow 最近七年全球开发者调研数据中关于数据库的部分

概览

GitHub 仓库地址：https://github.com/Vonng/pigsty-app/tree/master/db

在线 Demo 地址：https://demo.pigsty.cc/d/sf-survey

Stack Overflow 数据库调查仪表盘

28 - DB-Engine 热度分析

分析 DB-Engine 上的数据库管理系统，查阅其流行度变迁。

概览

GitHub 仓库地址：https://github.com/Vonng/pigsty-app/tree/master/db

在线 Demo 地址：https://demo.pigsty.cc/d/db-engine

数据库引擎监控仪表盘

29 - 云上算力价格计算器

分析阿里云 / AWS 上算力与存储的价格 (ECS/ESSD)

概览

GitHub 仓库地址：https://github.com/Vonng/pigsty-app/tree/master/cloud

在线 Demo 地址：https://demo.pigsty.cc/d/ecs

文章地址：《剖析算力成本：阿里云真降价了吗？》

数据源

Aliyun ECS 价格可以在 价格计算器 - 定价详情 - 价格下载 中获取 CSV 原始数据。

模式

下载 阿里云 价格明细并导入分析

SQL
CREATE EXTENSION file_fdw;
CREATE SERVER fs FOREIGN DATA WRAPPER file_fdw;

DROP FOREIGN TABLE IF EXISTS aliyun_ecs CASCADE;
CREATE FOREIGN TABLE aliyun_ecs
    (
        "region" text,
        "system" text,
        "network" text,
        "isIO" bool,
        "instanceId" text,
        "hourlyPrice" numeric,
        "weeklyPrice" numeric,
        "standard" numeric,
        "monthlyPrice" numeric,
        "yearlyPrice" numeric,
        "2yearPrice" numeric,
        "3yearPrice" numeric,
        "4yearPrice" numeric,
        "5yearPrice" numeric,
        "id" text,
        "instanceLabel" text,
        "familyId" text,
        "serverType" text,
        "cpu" text,
        "localStorage" text,
        "NvmeSupport" text,
        "InstanceFamilyLevel" text,
        "EniTrunkSupported" text,
        "InstancePpsRx" text,
        "GPUSpec" text,
        "CpuTurboFrequency" text,
        "InstancePpsTx" text,
        "InstanceTypeId" text,
        "GPUAmount" text,
        "InstanceTypeFamily" text,
        "SecondaryEniQueueNumber" text,
        "EniQuantity" text,
        "EniPrivateIpAddressQuantity" text,
        "DiskQuantity" text,
        "EniIpv6AddressQuantity" text,
        "InstanceCategory" text,
        "CpuArchitecture" text,
        "EriQuantity" text,
        "MemorySize" numeric,
        "EniTotalQuantity" numeric,
        "PhysicalProcessorModel" text,
        "InstanceBandwidthRx" numeric,
        "CpuCoreCount" numeric,
        "Generation" text,
        "CpuSpeedFrequency" numeric,
        "PrimaryEniQueueNumber" text,
        "LocalStorageCategory" text,
        "InstanceBandwidthTx" text,
        "TotalEniQueueQuantity" text
        ) SERVER fs OPTIONS ( filename '/tmp/aliyun-ecs.csv', format 'csv',header 'true');

AWS EC2 同理，可以从 Vantage 下载价格清单：

SQL

DROP FOREIGN TABLE IF EXISTS aws_ec2 CASCADE;
CREATE FOREIGN TABLE aws_ec2
    (
        "name" TEXT,
        "id" TEXT,
        "Memory" TEXT,
        "vCPUs" TEXT,
        "GPUs" TEXT,
        "ClockSpeed" TEXT,
        "InstanceStorage" TEXT,
        "NetworkPerformance" TEXT,
        "ondemand" TEXT,
        "reserve" TEXT,
        "spot" TEXT
        ) SERVER fs OPTIONS ( filename '/tmp/aws-ec2.csv', format 'csv',header 'true');



DROP VIEW IF EXISTS ecs;
CREATE VIEW ecs AS
SELECT "region"                                       AS region,
       "id"                                           AS id,
       "instanceLabel"                                AS name,
       "familyId"                                     AS family,
       "CpuCoreCount"                                 AS cpu,
       "MemorySize"                                   AS mem,
       round("5yearPrice" / "CpuCoreCount" / 60, 2)   AS ycm5, -- ¥ / (core·month)
       round("4yearPrice" / "CpuCoreCount" / 48, 2)   AS ycm4, -- ¥ / (core·month)
       round("3yearPrice" / "CpuCoreCount" / 36, 2)   AS ycm3, -- ¥ / (core·month)
       round("2yearPrice" / "CpuCoreCount" / 24, 2)   AS ycm2, -- ¥ / (core·month)
       round("yearlyPrice" / "CpuCoreCount" / 12, 2)  AS ycm1, -- ¥ / (core·month)
       round("standard" / "CpuCoreCount", 2)          AS ycmm, -- ¥ / (core·month)
       round("hourlyPrice" / "CpuCoreCount" * 720, 2) AS ycmh, -- ¥ / (core·month)
       "CpuSpeedFrequency"::NUMERIC                   AS freq,
       "CpuTurboFrequency"::NUMERIC                   AS freq_turbo,
       "Generation"                                   AS generation
FROM aliyun_ecs
WHERE system = 'linux';

DROP VIEW IF EXISTS ec2;
CREATE VIEW ec2 AS
SELECT id,
       name,
       split_part(id, '.', 1)                                                               as family,
       split_part(id, '.', 2)                                                               as spec,
       (regexp_match(split_part(id, '.', 1), '^[a-zA-Z]+(\d)[a-z0-9]*'))[1]                 as gen,
       regexp_substr("vCPUs", '^[0-9]+')::int                                               as cpu,
       regexp_substr("Memory", '^[0-9]+')::int                                              as mem,
       CASE spot
           WHEN 'unavailable' THEN NULL
           ELSE round((regexp_substr("spot", '([0-9]+.[0-9]+)')::NUMERIC * 7.2), 2) END     AS spot,
       CASE ondemand
           WHEN 'unavailable' THEN NULL
           ELSE round((regexp_substr("ondemand", '([0-9]+.[0-9]+)')::NUMERIC * 7.2), 2) END AS ondemand,
       CASE reserve
           WHEN 'unavailable' THEN NULL
           ELSE round((regexp_substr("reserve", '([0-9]+.[0-9]+)')::NUMERIC * 7.2), 2) END  AS reserve,
       "ClockSpeed"                                                                         AS freq
FROM aws_ec2;