Baserow on AWS 生产部署指南在 ECS/Fargate 上部署 All-in-One 镜像与分服务架构【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow本文为 Baserow 部署到 AWS 的完整实操指南覆盖两种 ECS/Fargate 部署路线——all-in-one 镜像的单容器横向扩展部署以及baserow/backendbaserow/web-frontend镜像的一服务一容器精细部署。读完本文你将掌握 S3、RDS、ElastiCache、ALB 与 ECS 的配套配置方法、完整的环境变量清单、Task Definition 示例、扩缩容参数与版本升级流程并可结合开源仓库中的启动脚本与健康检查源码理解每项配置背后的实际行为。一、部署方式总览Baserow 可以按以下方式部署到 AWS将 all-in-one 镜像部署到 Fargate/ECS横向可扩展、搭建简单适合大多数场景本文选项 1详见后文以 docker-compose.no-caddy.yml 或 K8S 示例配置 为起点配置 ECS/Fargate 任务实现更高级的一服务一容器生产模型本文选项 2详见后文使用 官方 Helm Chart 配合 EKS自定义 K8S 示例配置 后部署到 EKS在 EC2 实例上安装 docker/docker-compose使用 all-in-one 或 一服务一容器 镜像。所有部署方式都会将 Baserow 的数据和状态存储在 RDS 与 S3 中因此它们在之间切换例如日后迁移到 EKS都很直接——容器层可以随意重建只要指向同一套 RDS 和 S3 即可。二、部署前提Prerequisites任何 AWS 上的 Baserow 部署都需要以下资源AWS IAM 账户具备创建 AWS 资源的足够权限Postgres 数据库RDS存放全部非文件数据S3 存储桶存放用户上传的文件和表/视图导出文件需要一个专门的 AWS IAM 用户其Access Key ID 与 Secret Access Key将用于配置 Baserow 上传到该存储桶VPC非集群模式 RedisElastiCache开启 TLS、关闭 cluster modeSMTP 邮件服务器用于发送邀请邮件、密码重置邮件等。下文两种部署方案都会对这些资源做更细致的配置说明。三、选项 1将 All-in-One 镜像部署到 Fargate/ECSbaserow/baserow:2.3.3镜像把 Baserow 的所有服务web-frontend、backend、快/慢异步任务 worker 等都打包进同一个容器专为单服务器部署或 Fargate、Google Cloud Run 这类可横向扩展的容器平台设计。3.1 为什么选择这种方式优点只需增加容器数量即可轻松横向扩展控制粒度足以满足大多数生产需求比下面的一服务一容器模型更简单不需要自行配置和串联 Baserow 的各个服务负载均衡配置更简单——所有请求可以直接路由到任意一个运行baserow/baserow:2.3.3的容器。缺点不符合传统的一容器一任务/服务模式整体资源用量可能更高每个 all-in-one 容器都自带全套内部服务对特定服务的扩缩粒度更差。例如默认横向部署 10 个baserow/baserow:2.3.3容器实际上会得到 10 个 web-frontend、10 个 backend、10 个快速异步任务 worker、10 个慢速异步任务 worker可通过环境变量部分调节见 3.7 节某个服务出故障时由于单个容器日志混杂多个服务隔离排查更困难。不过 Baserow 完整支持 OpenTelemetry参见 监控指南可以接入 Honeycomb、Datadog、NewRelic 或 Grafana/Loki/Tempo/Prometheus 等方案弥补。3.2 安装步骤以下步骤跳过 VPC、安全组、IAM 用户、Secrets Manager 与 ELB 的具体细节以保持指南的通用性。3.2.1 步骤 1创建用户文件上传用的 S3 存储桶Baserow 使用该桶存放用户上传到表中的文件以及用户触发的表/视图导出文件并为用户生成预签名 S3 URL来查看和下载文件。由于这些预签名 URL 必须能从用户浏览器直接访问你的桶通常需要允许公共 GET/ACL。推荐创建一个独立的 IAM 用户供 Baserow 使用让它只能上传和删除文件。下面是授予最小必要权限的示例 S3 策略Terraform 写法policy EOF { Version: 2012-10-17, Statement: [{ Effect: Allow, Action: [ s3:PutObject, s3:GetObjectAcl, s3:GetObject, s3:DeleteObject, s3:PutObjectAcl ], Principal: { AWS: arn:aws:iam::xyz:user/YOUR_USER }, Resource: [ arn:aws:s3:::YOUR_BUCKET_NAME/*, arn:aws:s3:::YOUR_BUCKET_NAME ] }] }当前版本的 Baserow 还需要为桶配置 CORS 规则工具内的文件下载按钮才能正常工作示例规则如下cors_rule { allowed_headers [*] allowed_methods [GET, HEAD, OPTIONS] allowed_origins [REPLACE_WITH_YOUR_BASEROW_PUBLIC_URL] expose_headers [ETag, Content-Length, Content-Type] max_age_seconds 3000 }最后为了让用户浏览器能 GET 并下载 S3 文件需要如下公共访问设置block_public_acls false block_public_policy true ignore_public_acls true restrict_public_buckets true3.2.2 步骤 2使用 RDS 创建 PostgresBaserow 把全部非文件数据都存在 PostgreSQL 数据库中AWS 上推荐使用 RDS Postgres 集群并稍后配置 Baserow 连接它。Baserow 对 PostgreSQL 的使用非常深入大规模部署时需要对 RDS 集群做垂直扩容。重要不要在 RDS 实例前加挂 RDS Proxy。Proxy 会在 DDL 语句执行完毕后结束事务而 Baserow 会频繁进行 schema 变更一旦迁移出问题事务无法回滚会导致数据不一致。3.2.3 步骤 3使用 ElastiCache 创建 RedisBaserow 使用 Redis 作为缓存、承载 WebSocket 实时协作以及异步后台任务处理。推荐配置非集群模式 开启 TLS AUTH 模式可指定密码供 Baserow 连接。总体来看随着 Baserow 扩展Redis 通常不是瓶颈。3.2.4 步骤 4配置 ALB 与目标组创建一个 80 端口的目标组和一个 ALB准备把流量路由到 Baserow 容器。配置 ALB 健康检查时针对baserow/baserow:2.3.3容器选择端口80、健康检查 URL 为/api/_health/并建议设置900 秒的长 grace period以覆盖首个容器启动时运行的首次数据库迁移。这个端点的存在可以在后端源码中确认/api/_health/由 health 路由 提供挂载在 URL 配置 的_health/路径下入口脚本 中的backend-healthcheck命令也是直接curl该端点并按 2xx 状态码判定健康。3.2.5 步骤 5在 ECS/Fargate 上启动 Baserow现在可以启动baserow/baserow:2.3.3容器了。建议每个容器从2 vCPU 4 GB 内存起步。具体操作选择baserow/baserow:2.3.3镜像添加 TCP 端口映射80该镜像的 HTTP 服务默认监听 80将容器标记为 essential设置以下环境变量完整环境变量清单见 配置指南环境变量说明DISABLE_VOLUME_CHECKtrue必须设为 true。用于禁用一项帮助非技术用户未配置外部 Postgres 和 S3的检查。因为我们配置了外部服务无需向容器挂载任何卷。BASEROW_PUBLIC_URL用户浏览器访问 Baserow 使用的公网 URL 或 IP即使通过 IP 访问也应以http://或https://开头。DATABASE_HOSTBaserow 存储数据所用的 Postgres 主机名。DATABASE_USER连接DATABASE_HOST上数据库的用户名。DATABASE_PORT连接DATABASE_HOST上 Postgres 的端口。DATABASE_NAMEBaserow 存储数据所用的数据库名。DATABASE_PASSWORDDATABASE_HOST上 Postgres 服务器中DATABASE_USER的密码。也可以提供DATABASE_PASSWORD_FILE设为注入容器文件系统的秘密文件路径。REDIS_URL标准 Redis 连接串格式redis://[redisuser]:[password][redishost]:[redisport]/0?ssl_cert_reqsrequired。AWS_STORAGE_BUCKET_NAME你的 AWS 存储桶名。AWS_ACCESS_KEY_ID你的 S3 IAM AWS 账户的 Access Key。设置为非空值后Baserow 切换到使用 S3 兼容桶存储用户文件上传。AWS_SECRET_ACCESS_KEY你的 S3 IAM AWS 账户的 Secret Key也可以提供AWS_SECRET_ACCESS_KEY_FILE代替。DOWNLOAD_FILE_VIA_XHR在 AWS S3 下当前必须设为1强制下载链接通过 XHR 查询下载文件以绕过Content-Disposition: inline。如果文件存储在另一个源下还必须为 S3 桶添加 CORS 头。BASEROW_EXTRA_ALLOWED_HOSTS可选的逗号分隔主机名列表会追加到 Baserow Django 后端的ALLOWED_HOSTS。把 ALB 的 IP 加在这里可以放行它的健康检查也可以先配置不安全的*让系统先跑起来之后再收紧。BASEROW_JWT_SIGNING_KEY必须设置且所有容器共享同一签名密钥。该密钥用于签名生成的 token 内容HMAC 签名时应是随机字符串且位数不低于签名协议要求。也支持BASEROW_JWT_SIGNING_KEY_FILE。SECRET_KEY必须设置且所有容器共享同一密钥。Django 用于加密签名的 Secret key例如生成安全密码重置链接和管理会话。也支持SECRET_KEY_FILE。EMAIL_SMTP_*环境变量指南 中记录的一组 SMTP 相关环境变量需要设置以便 Baserow 发送邀请和密码重置邮件。选择启动类型本文使用 FargateOS 族选择 Linux使用你的 ALB、目标组与该任务定义创建 ECS 服务确保 ECS 容器 Ingress 安全组放行以下端口HTTP 端口端口映射未改则为 80Redis 端口Postgres 端口。关于DISABLE_VOLUME_CHECK的必要性可以直接从源码看到检查逻辑all-in-one 启动脚本 在未设置该变量时会检查$DATA_DIR是否出现在mount输出中若未挂载数据卷则直接退出提示数据会在容器重启后丢失而配置了外部 RDS/S3 后数据不落本地卷因此必须显式关闭该检查。此外 启动脚本 表明只有当DATABASE_HOST/REDIS_HOST为localhost时才会启用容器内嵌的 Postgres/Redis指向 RDS/ElastiCache 时这些内嵌服务不会启动。3.2.6 步骤 6完整 Task Definition 示例下面是使用 ECS 与 Fargate 的完整任务定义示例container_definitions DEFINITION [ { name: baserow_task, image: baserow/baserow:2.3.3, logConfiguration: { #logs are not mandatory logDriver: awslogs, options: { awslogs-region : YOUR_REGION_NAME, awslogs-group : /ecs/baserow_log, awslogs-stream-prefix : baserow, awslogs-create-group: true } }, environment: [ { name: DISABLE_VOLUME_CHECK, value: yes }, { name: BASEROW_PUBLIC_URL, value: YOUR_PUBLIC_URL }, { name: DATABASE_HOST, value: YOUR_POSTGRES_DB_HOST }, { name: DATABASE_USER, value: postgres }, { name: DATABASE_PORT, value: PORT_NUMBER }, { name: DATABASE_NAME, value: YOUR_POSTGRES_DB_NAME }, { name: DATABASE_PASSWORD, value: YOUR_POSTGRES_DB_PASSWORD }, { name: REDIS_URL, value: rediss://default:passwordYOUR_REDIS_PRIMARY_ENDPOINT:6379/0?ssl_cert_reqsrequired }, { name: AWS_STORAGE_BUCKET_NAME, value: YOUR_BUCKET_NAME }, { name: AWS_ACCESS_KEY_ID, value: YOUR_AWS_ACCESS_KEY_ID }, { name: AWS_SECRET_ACCESS_KEY, value: YOUR_AWS_SECRET_ACCESS_KEY }, { name: DOWNLOAD_FILE_VIA_XHR, value: 1 }, { name: BASEROW_EXTRA_ALLOWED_HOSTS, value: YOUR_ALLOWED_HOSTS }, { name: BASEROW_JWT_SIGNING_KEY, value: YOUR_SIGNING_KEY }, { name: SECRET_KEY, value: YOUR_SECRET_KEY } ], essential: true, portMappings: [ { containerPort: 80, hostPort: 80 } ], memory: 8192, cpu: 4096 } ] DEFINITION requires_compatibilities [FARGATE] network_mode awsvpc memory 8192 cpu 40963.2.7 步骤 7额外的扩缩容选项除了启动更多baserow/baserow任务和扩容 RDS Postgresbaserow/baserow镜像还提供以下扩展环境变量用于降低每容器资源占用或将资源倾斜给容器内某些服务BASEROW_AMOUNT_OF_GUNICORN_WORKERS控制每容器的 REST API worker 数量承担大部分 API 工作默认 3。每多一个 worker 大约多占 100–200 MB 内存BASEROW_AMOUNT_OF_WORKERS控制后台任务 celery runner 数量它们执行实时协作任务、清理任务以及大文件导出/导入等慢任务。如果横向部署了很多容器通常每容器保留一个后台 worker 即可——它们会共同池化并通过 Redis 收集其他任意容器提交的后台任务设置BASEROW_RUN_MINIMALyes且BASEROW_AMOUNT_OF_WORKERS1可以让镜像启动更少的内部进程从而降低内存占用此时镜像只启动一个同时处理快慢两个队列的 celery 任务进程代价是每容器只有一个进程处理任务慢任务如对大型 Baserow 数据库做快照可能延迟快队列任务如向正在看该表的所有用户发送实时行更新信号但如果你有足够多的其他容器整个异步 worker 池仍然足以应对快慢任务混合。这些参数在 后端入口脚本 中有直接实现BASEROW_AMOUNT_OF_GUNICORN_WORKERS默认值 3、gunicorn 启动参数由此注入celery-worker命令在BASEROW_RUN_MINIMAL且BASEROW_AMOUNT_OF_WORKERS1时会改为-Q celery,export,automation_workflow合并队列模式而celery-exportworker此时直接空转退出与文档描述的行为一致。3.2.8 步骤 8部署完成此时你应已拥有一个完整运行的 Baserow 集群。第一个注册的用户会成为实例级的第一个 staff 全局管理员该用户可以在工具内配置 Baserow 设置、激活企业许可证、把其他用户提升为 staff 等。四、选项 2以独立服务形式部署到 Fargate/ECSbaserow/backend:2.3.3与baserow/web-frontend:2.3.3镜像允许把 Baserow 的各个服务作为独立容器运行。官方 Helm Chart 和各类 docker-compose 示例均基于这两个镜像最适合需要完全控制与灵活性的生产环境。4.1 为什么选择这种方式优点每个服务可独立扩缩控制粒度更细遵循传统的一容器一服务模型按服务维度查看日志和排障更容易单个容器更简单、活动部件更少。缺点整体搭建与维护更复杂需要更多 ALB 与网络配置确保正确的请求发到正确的服务。4.2 安装步骤先完成选项 1 中的步骤 1、2、3——S3 桶、RDS 与 Redis 的搭建完全相同。4.2.1 步骤 4配置 ALB 与目标组先创建 3 个 target type 为 IP 的目标组backend-asgi端口8000/HTTP健康检查 URL/api/_health/用于 WebSocket 服务backend-wsgi端口8000/HTTP健康检查 URL/api/_health/用于后端 API 服务web-frontend端口3000/HTTP健康检查 URL/_health/用于前端服务。健康检查端点结尾的斜杠是必须的然后创建监听 80 端口的 ALB默认路由到web-frontend组并为该监听器配置三条规则默认规则捕获其余所有请求转发到web-frontend路径条件/ws/*转发到backend-asgi路径条件/api/*转发到backend-wsgi。之后web-frontend服务需要通过负载均衡器与backend-wsgi通信。你可以复用同一个 ALB 同时处理外部请求和这些服务间请求但务必正确配置安全组允许 ECS 任务与 ALB 之间通信。4.2.2 步骤 5部署 Baserow 的各个服务为 Baserow 新建一个 ECS 集群然后依次创建下面的任务定义。熟悉 K8S 的话K8S 示例配置 给出了各服务概览docker-compose.no-caddy.yml 也可以作为参考——其中定义了backend8000 端口、web-frontend3000 端口、celerycelery-worker命令、celery-export-workercelery-exportworker命令与celery-beat-workercelery-beat命令等服务及其健康检查。4.2.3 步骤 6backend WSGI 服务该服务是 HTTP REST API 服务。创建任务定义时应使用baserow/backend:2.3.3镜像在 docker 配置中将 Command 设为gunicorn-wsgi,--timeout,60。建议把每个 HTTP API 请求的超时设为 60 秒如上命令默认 30 秒对超大 Baserow 表可能过短。建议每容器 2 vCPU 4 GB 内存起步映射容器端口8000/TCP协议选HTTPApp 协议标记容器为 essential设置以下环境变量记下它们稍后其他任务定义还要设置同样的变量用一个共享的环境文件是好主意环境变量说明BASEROW_PUBLIC_URL用户浏览器访问 Baserow 使用的公网 URL 或 IP应以http://或https://开头。DATABASE_HOSTBaserow 存储数据所用的 Postgres 主机名。DATABASE_USER连接DATABASE_HOST上数据库的用户名。DATABASE_PORT连接 Postgres 的端口。DATABASE_NAMEBaserow 存储数据所用的数据库名。DATABASE_PASSWORDDATABASE_HOST上DATABASE_USER的密码也可用DATABASE_PASSWORD_FILE指向注入的秘密文件。REDIS_URL标准 Redis 连接串redis://[redisuser]:[password][redishost]:[redisport]/0?ssl_cert_reqsrequired。AWS_STORAGE_BUCKET_NAME你的 AWS 存储桶名。AWS_ACCESS_KEY_IDS3 IAM 账户 Access Key非空即启用 S3 存储用户文件。AWS_SECRET_ACCESS_KEYS3 IAM 账户 Secret Key也可用AWS_SECRET_ACCESS_KEY_FILE代替。BASEROW_EXTRA_ALLOWED_HOSTS追加到 DjangoALLOWED_HOSTS的逗号分隔主机名加入 ALB IP 以放行健康检查或先临时用*。BASEROW_JWT_SIGNING_KEY必须设置且所有容器共享用于 token 签名也支持BASEROW_JWT_SIGNING_KEY_FILE。SECRET_KEY必须设置且所有容器共享Django 加密签名密码重置链接、会话等所用也支持SECRET_KEY_FILE。EMAIL_SMTP_*环境变量指南 中的 SMTP 变量用于发送邀请和密码重置邮件。从 入口脚本 可以确认gunicorn-wsgi会加载baserow.config.wsgi:application纯 WSGI不支持 WebSocketgunicorn则以 UvicornWorker 加载 ASGI 应用两者都先等待 Postgres 可用、再按MIGRATE_ON_STARTUP默认true执行数据库迁移——这正是首个容器自动完成迁移这一行为的实现来源。4.2.4 步骤 7backend ASGI 服务也可以只用 ASGI 服务而不单独建 ASGI/WSGI把所有 HTTP 和 WebSocket 请求都路由到单一 ASGI 服务。但 ASGI 服务处理普通 HTTP 请求的性能不如 WSGI 模式且分开后可以独立扩缩——通常只需少量 ASGI 实例即可扛住 WebSocket 负载。该服务是 WebSocket API 服务配置任务定义时应使用baserow/backend:2.3.3镜像docker 配置中 Command 设为gunicorn建议每容器 2 vCPU 4 GB 内存起步映射容器端口8000/TCP标记容器为 essential设置与 backend-wsgi 服务相同的环境变量。4.2.5 步骤 8backend celery worker 服务该服务是异步高优先级任务队列用于实时协作和发送邮件。使用baserow/backend:2.3.3镜像Command 设为celery-worker无需端口映射建议每容器 2 vCPU 4 GB 内存起步标记容器为 essential设置与 backend-wsgi 相同的环境变量。4.2.6 步骤 9backend celery export worker 服务该服务是异步慢/低优先级任务队列用于批处理及表导出、导入等潜在耗时的操作。使用baserow/backend:2.3.3镜像Command 设为celery-exportworker无需端口映射建议每容器 2 vCPU 4 GB 内存起步标记容器为 essential设置与 backend-wsgi 相同的环境变量。4.2.7 步骤 10backend celery beat 服务该服务是 CRON 任务调度器可以部署多个副本。使用baserow/backend:2.3.3镜像Command 设为celery-beat无需端口映射建议每容器 1 vCPU 3 GB 内存起步同一时刻只有一个这样的容器在全局调度任务其余副本作为热备当主实例失败并释放调度 Redis 锁时接管。标记容器为 essential设置与 backend-wsgi 相同的环境变量。多副本热备 Redis 锁的说法与源码相符入口脚本 中celery-beat使用redbeat.RedBeatScheduler调度器调度状态保存在 Redis 中并带有BASEROW_CELERY_BEAT_STARTUP_DELAY默认 15 秒的启动延迟以避免与其他 celery worker 启动时互相干扰锁。4.2.8 步骤 11web-frontend 服务该服务负责 Baserow 前端的服务器端渲染与托管。使用baserow/web-frontend:2.3.3镜像无需参数映射容器端口3000建议每容器 2 vCPU 4 GB 内存起步标记容器为 essential设置以下与后端服务不同的环境变量BASEROW_PUBLIC_URL用户浏览器访问 Baserow 使用的公网 URL 或 IP应以http://或https://开头PRIVATE_BACKEND_URLweb-frontend 容器需要向运行 REST API 的backend-wsgi容器发起 HTTP 请求。建议设为你的 ALB 地址且必须以http://或https://开头确保安全组配置正确允许这些内部 HTTP 请求如果你没有在backend-wsgi与backend-asgi上设置BASEROW_EXTRA_ALLOWED_HOSTS*务必把这个环境变量的值加入那些服务的BASEROW_EXTRA_ALLOWED_HOSTS否则它们不会接受来自 web-frontend 的连接。DOWNLOAD_FILE_VIA_XHR在 AWS S3 下必须设为1强制下载链接通过 XHR 下载以绕过Content-Disposition: inline文件若存储在另一个源下还必须配置 S3 CORS。4.2.9 步骤 12创建 ECS 服务回到刚才创建的任务定义并建立 ECS 服务。接线时记得在健康检查中设置900 秒grace period。也可以为所有 Baserow 任务创建单一 ECS 服务但需要通过 API/CLI 把多个目标组挂到该服务上目前 AWS UI 做不到并且你可能需要让backend-asgi与backend-wsgi暴露在不同端口上以便目标组正确路由方法是为这两个服务分别设置不同的BASEROW_BACKEND_PORT环境变量使它们在容器内绑定不同端口入口脚本 中该变量默认值为 8000。backend-wsgi服务 → 连接backend-wsgi目标组backend-asgi服务 → 连接backend-asgi目标组web-frontend服务 → 连接web-frontend目标组celery-worker服务celery-exportworker服务celery-beat服务。4.2.10 步骤 13扩缩容选项大多数情况下扩展backend-wsgi任务数和 RDS Postgres 是应对更多请求的第一选择如果实时协作变慢可扩展backend-asgi与celery-worker服务如果发现任务要等很久才开始Baserow UI 中的进度条卡在 0%可以增加更多celery-exportworker。此外以下环境变量可以改变每容器内部启动的 worker 进程数实现垂直扩展BASEROW_AMOUNT_OF_GUNICORN_WORKERS每gunicorn-wsgi或gunicorn容器的 REST API worker 数默认 3每个额外 worker 约多占 100–200 MB 内存BASEROW_AMOUNT_OF_WORKERScelery-worker与celery-exportworker容器中后台 celery runner 的数量。4.2.11 部署完成此时你应已拥有一个完整运行的 Baserow 集群。此部署方式更复杂如需帮助可到 Baserow 社区论坛提问。第一个注册的用户会成为实例级的第一个 staff 全局管理员可配置工具内设置、激活企业许可证、提升其他用户为 staff 等。五、升级 Baserow升级 ECS/Fargate 上的 Baserow 按以下顺序进行备份/快照 RDS Postgres 数据库先停止所有运行旧版本的容器避免用户在升级期间访问旧容器报错更新任务定义使用新版本镜像第一个启动的新baserow/baserow或baserow/backend-wsgi/asgi容器会自动应用所需的数据库迁移与升级迁移完成后所有新的 Baserow 容器开始接受请求升级完成。这一流程的机制可以在 后端入口脚本 中验证MIGRATE_ON_STARTUP默认为truegunicorn 服务启动前会先执行locked_migrate带锁迁移防止多个容器并发迁移因此停旧、起新、首个容器自动迁移的顺序是安全且必要的。六、常见问题FAQ6.1 修复CROSSSLOT Keys in request dont hash to the same slot错误日志中出现该错误说明你用了集群模式的 Redis 启动 Baserow。Baserow 使用的库不支持 Redis 集群模式需要换一个非集群模式的 Redis。非集群模式的 Redis 同样可以扩展和跨多可用区部署而且 Baserow 一般不会出现以 Redis 为请求瓶颈的情况。6.2 ELB 健康检查失败首次部署或升级后的首轮迁移可能耗时较长可以尝试增大 grace period确认 ELB 能连通容器。注意容器内部有自己的健康检查脚本也会调用健康检查端点——所以日志里出现 200 响应不代表触发者是 ELB。6.3 从 Baserow 文件字段下载文件时出现 CORS 错误S3 桶的 CORS 没有配置好请参考 3.2.1 节中的 CORS 示例配置。6.4 出现Secure Redis scheme specified (rediss) with no ssl options, defaulting to insecure SSL behavior警告确认已在REDIS_URL环境变量末尾添加?ssl_cert_reqsrequired。小结AWS 上部署 Baserow 的核心是数据层外置、容器无状态——RDS 存数据、S3 存文件、Redis 做缓存/实时/任务队列容器层无论 all-in-one 还是分服务均可自由替换与扩缩。选项 1 适合快速上生产选项 2 适合需要精细控制与独立扩缩的规模两种方案共享同一套底层资源与升级流程可平滑互转。【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Baserow on AWS 生产部署指南：在 ECS/Fargate 上部署 All-in-One 镜像与分服务架构
Baserow on AWS 生产部署指南在 ECS/Fargate 上部署 All-in-One 镜像与分服务架构【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow本文为 Baserow 部署到 AWS 的完整实操指南覆盖两种 ECS/Fargate 部署路线——all-in-one 镜像的单容器横向扩展部署以及baserow/backendbaserow/web-frontend镜像的一服务一容器精细部署。读完本文你将掌握 S3、RDS、ElastiCache、ALB 与 ECS 的配套配置方法、完整的环境变量清单、Task Definition 示例、扩缩容参数与版本升级流程并可结合开源仓库中的启动脚本与健康检查源码理解每项配置背后的实际行为。一、部署方式总览Baserow 可以按以下方式部署到 AWS将 all-in-one 镜像部署到 Fargate/ECS横向可扩展、搭建简单适合大多数场景本文选项 1详见后文以 docker-compose.no-caddy.yml 或 K8S 示例配置 为起点配置 ECS/Fargate 任务实现更高级的一服务一容器生产模型本文选项 2详见后文使用 官方 Helm Chart 配合 EKS自定义 K8S 示例配置 后部署到 EKS在 EC2 实例上安装 docker/docker-compose使用 all-in-one 或 一服务一容器 镜像。所有部署方式都会将 Baserow 的数据和状态存储在 RDS 与 S3 中因此它们在之间切换例如日后迁移到 EKS都很直接——容器层可以随意重建只要指向同一套 RDS 和 S3 即可。二、部署前提Prerequisites任何 AWS 上的 Baserow 部署都需要以下资源AWS IAM 账户具备创建 AWS 资源的足够权限Postgres 数据库RDS存放全部非文件数据S3 存储桶存放用户上传的文件和表/视图导出文件需要一个专门的 AWS IAM 用户其Access Key ID 与 Secret Access Key将用于配置 Baserow 上传到该存储桶VPC非集群模式 RedisElastiCache开启 TLS、关闭 cluster modeSMTP 邮件服务器用于发送邀请邮件、密码重置邮件等。下文两种部署方案都会对这些资源做更细致的配置说明。三、选项 1将 All-in-One 镜像部署到 Fargate/ECSbaserow/baserow:2.3.3镜像把 Baserow 的所有服务web-frontend、backend、快/慢异步任务 worker 等都打包进同一个容器专为单服务器部署或 Fargate、Google Cloud Run 这类可横向扩展的容器平台设计。3.1 为什么选择这种方式优点只需增加容器数量即可轻松横向扩展控制粒度足以满足大多数生产需求比下面的一服务一容器模型更简单不需要自行配置和串联 Baserow 的各个服务负载均衡配置更简单——所有请求可以直接路由到任意一个运行baserow/baserow:2.3.3的容器。缺点不符合传统的一容器一任务/服务模式整体资源用量可能更高每个 all-in-one 容器都自带全套内部服务对特定服务的扩缩粒度更差。例如默认横向部署 10 个baserow/baserow:2.3.3容器实际上会得到 10 个 web-frontend、10 个 backend、10 个快速异步任务 worker、10 个慢速异步任务 worker可通过环境变量部分调节见 3.7 节某个服务出故障时由于单个容器日志混杂多个服务隔离排查更困难。不过 Baserow 完整支持 OpenTelemetry参见 监控指南可以接入 Honeycomb、Datadog、NewRelic 或 Grafana/Loki/Tempo/Prometheus 等方案弥补。3.2 安装步骤以下步骤跳过 VPC、安全组、IAM 用户、Secrets Manager 与 ELB 的具体细节以保持指南的通用性。3.2.1 步骤 1创建用户文件上传用的 S3 存储桶Baserow 使用该桶存放用户上传到表中的文件以及用户触发的表/视图导出文件并为用户生成预签名 S3 URL来查看和下载文件。由于这些预签名 URL 必须能从用户浏览器直接访问你的桶通常需要允许公共 GET/ACL。推荐创建一个独立的 IAM 用户供 Baserow 使用让它只能上传和删除文件。下面是授予最小必要权限的示例 S3 策略Terraform 写法policy EOF { Version: 2012-10-17, Statement: [{ Effect: Allow, Action: [ s3:PutObject, s3:GetObjectAcl, s3:GetObject, s3:DeleteObject, s3:PutObjectAcl ], Principal: { AWS: arn:aws:iam::xyz:user/YOUR_USER }, Resource: [ arn:aws:s3:::YOUR_BUCKET_NAME/*, arn:aws:s3:::YOUR_BUCKET_NAME ] }] }当前版本的 Baserow 还需要为桶配置 CORS 规则工具内的文件下载按钮才能正常工作示例规则如下cors_rule { allowed_headers [*] allowed_methods [GET, HEAD, OPTIONS] allowed_origins [REPLACE_WITH_YOUR_BASEROW_PUBLIC_URL] expose_headers [ETag, Content-Length, Content-Type] max_age_seconds 3000 }最后为了让用户浏览器能 GET 并下载 S3 文件需要如下公共访问设置block_public_acls false block_public_policy true ignore_public_acls true restrict_public_buckets true3.2.2 步骤 2使用 RDS 创建 PostgresBaserow 把全部非文件数据都存在 PostgreSQL 数据库中AWS 上推荐使用 RDS Postgres 集群并稍后配置 Baserow 连接它。Baserow 对 PostgreSQL 的使用非常深入大规模部署时需要对 RDS 集群做垂直扩容。重要不要在 RDS 实例前加挂 RDS Proxy。Proxy 会在 DDL 语句执行完毕后结束事务而 Baserow 会频繁进行 schema 变更一旦迁移出问题事务无法回滚会导致数据不一致。3.2.3 步骤 3使用 ElastiCache 创建 RedisBaserow 使用 Redis 作为缓存、承载 WebSocket 实时协作以及异步后台任务处理。推荐配置非集群模式 开启 TLS AUTH 模式可指定密码供 Baserow 连接。总体来看随着 Baserow 扩展Redis 通常不是瓶颈。3.2.4 步骤 4配置 ALB 与目标组创建一个 80 端口的目标组和一个 ALB准备把流量路由到 Baserow 容器。配置 ALB 健康检查时针对baserow/baserow:2.3.3容器选择端口80、健康检查 URL 为/api/_health/并建议设置900 秒的长 grace period以覆盖首个容器启动时运行的首次数据库迁移。这个端点的存在可以在后端源码中确认/api/_health/由 health 路由 提供挂载在 URL 配置 的_health/路径下入口脚本 中的backend-healthcheck命令也是直接curl该端点并按 2xx 状态码判定健康。3.2.5 步骤 5在 ECS/Fargate 上启动 Baserow现在可以启动baserow/baserow:2.3.3容器了。建议每个容器从2 vCPU 4 GB 内存起步。具体操作选择baserow/baserow:2.3.3镜像添加 TCP 端口映射80该镜像的 HTTP 服务默认监听 80将容器标记为 essential设置以下环境变量完整环境变量清单见 配置指南环境变量说明DISABLE_VOLUME_CHECKtrue必须设为 true。用于禁用一项帮助非技术用户未配置外部 Postgres 和 S3的检查。因为我们配置了外部服务无需向容器挂载任何卷。BASEROW_PUBLIC_URL用户浏览器访问 Baserow 使用的公网 URL 或 IP即使通过 IP 访问也应以http://或https://开头。DATABASE_HOSTBaserow 存储数据所用的 Postgres 主机名。DATABASE_USER连接DATABASE_HOST上数据库的用户名。DATABASE_PORT连接DATABASE_HOST上 Postgres 的端口。DATABASE_NAMEBaserow 存储数据所用的数据库名。DATABASE_PASSWORDDATABASE_HOST上 Postgres 服务器中DATABASE_USER的密码。也可以提供DATABASE_PASSWORD_FILE设为注入容器文件系统的秘密文件路径。REDIS_URL标准 Redis 连接串格式redis://[redisuser]:[password][redishost]:[redisport]/0?ssl_cert_reqsrequired。AWS_STORAGE_BUCKET_NAME你的 AWS 存储桶名。AWS_ACCESS_KEY_ID你的 S3 IAM AWS 账户的 Access Key。设置为非空值后Baserow 切换到使用 S3 兼容桶存储用户文件上传。AWS_SECRET_ACCESS_KEY你的 S3 IAM AWS 账户的 Secret Key也可以提供AWS_SECRET_ACCESS_KEY_FILE代替。DOWNLOAD_FILE_VIA_XHR在 AWS S3 下当前必须设为1强制下载链接通过 XHR 查询下载文件以绕过Content-Disposition: inline。如果文件存储在另一个源下还必须为 S3 桶添加 CORS 头。BASEROW_EXTRA_ALLOWED_HOSTS可选的逗号分隔主机名列表会追加到 Baserow Django 后端的ALLOWED_HOSTS。把 ALB 的 IP 加在这里可以放行它的健康检查也可以先配置不安全的*让系统先跑起来之后再收紧。BASEROW_JWT_SIGNING_KEY必须设置且所有容器共享同一签名密钥。该密钥用于签名生成的 token 内容HMAC 签名时应是随机字符串且位数不低于签名协议要求。也支持BASEROW_JWT_SIGNING_KEY_FILE。SECRET_KEY必须设置且所有容器共享同一密钥。Django 用于加密签名的 Secret key例如生成安全密码重置链接和管理会话。也支持SECRET_KEY_FILE。EMAIL_SMTP_*环境变量指南 中记录的一组 SMTP 相关环境变量需要设置以便 Baserow 发送邀请和密码重置邮件。选择启动类型本文使用 FargateOS 族选择 Linux使用你的 ALB、目标组与该任务定义创建 ECS 服务确保 ECS 容器 Ingress 安全组放行以下端口HTTP 端口端口映射未改则为 80Redis 端口Postgres 端口。关于DISABLE_VOLUME_CHECK的必要性可以直接从源码看到检查逻辑all-in-one 启动脚本 在未设置该变量时会检查$DATA_DIR是否出现在mount输出中若未挂载数据卷则直接退出提示数据会在容器重启后丢失而配置了外部 RDS/S3 后数据不落本地卷因此必须显式关闭该检查。此外 启动脚本 表明只有当DATABASE_HOST/REDIS_HOST为localhost时才会启用容器内嵌的 Postgres/Redis指向 RDS/ElastiCache 时这些内嵌服务不会启动。3.2.6 步骤 6完整 Task Definition 示例下面是使用 ECS 与 Fargate 的完整任务定义示例container_definitions DEFINITION [ { name: baserow_task, image: baserow/baserow:2.3.3, logConfiguration: { #logs are not mandatory logDriver: awslogs, options: { awslogs-region : YOUR_REGION_NAME, awslogs-group : /ecs/baserow_log, awslogs-stream-prefix : baserow, awslogs-create-group: true } }, environment: [ { name: DISABLE_VOLUME_CHECK, value: yes }, { name: BASEROW_PUBLIC_URL, value: YOUR_PUBLIC_URL }, { name: DATABASE_HOST, value: YOUR_POSTGRES_DB_HOST }, { name: DATABASE_USER, value: postgres }, { name: DATABASE_PORT, value: PORT_NUMBER }, { name: DATABASE_NAME, value: YOUR_POSTGRES_DB_NAME }, { name: DATABASE_PASSWORD, value: YOUR_POSTGRES_DB_PASSWORD }, { name: REDIS_URL, value: rediss://default:passwordYOUR_REDIS_PRIMARY_ENDPOINT:6379/0?ssl_cert_reqsrequired }, { name: AWS_STORAGE_BUCKET_NAME, value: YOUR_BUCKET_NAME }, { name: AWS_ACCESS_KEY_ID, value: YOUR_AWS_ACCESS_KEY_ID }, { name: AWS_SECRET_ACCESS_KEY, value: YOUR_AWS_SECRET_ACCESS_KEY }, { name: DOWNLOAD_FILE_VIA_XHR, value: 1 }, { name: BASEROW_EXTRA_ALLOWED_HOSTS, value: YOUR_ALLOWED_HOSTS }, { name: BASEROW_JWT_SIGNING_KEY, value: YOUR_SIGNING_KEY }, { name: SECRET_KEY, value: YOUR_SECRET_KEY } ], essential: true, portMappings: [ { containerPort: 80, hostPort: 80 } ], memory: 8192, cpu: 4096 } ] DEFINITION requires_compatibilities [FARGATE] network_mode awsvpc memory 8192 cpu 40963.2.7 步骤 7额外的扩缩容选项除了启动更多baserow/baserow任务和扩容 RDS Postgresbaserow/baserow镜像还提供以下扩展环境变量用于降低每容器资源占用或将资源倾斜给容器内某些服务BASEROW_AMOUNT_OF_GUNICORN_WORKERS控制每容器的 REST API worker 数量承担大部分 API 工作默认 3。每多一个 worker 大约多占 100–200 MB 内存BASEROW_AMOUNT_OF_WORKERS控制后台任务 celery runner 数量它们执行实时协作任务、清理任务以及大文件导出/导入等慢任务。如果横向部署了很多容器通常每容器保留一个后台 worker 即可——它们会共同池化并通过 Redis 收集其他任意容器提交的后台任务设置BASEROW_RUN_MINIMALyes且BASEROW_AMOUNT_OF_WORKERS1可以让镜像启动更少的内部进程从而降低内存占用此时镜像只启动一个同时处理快慢两个队列的 celery 任务进程代价是每容器只有一个进程处理任务慢任务如对大型 Baserow 数据库做快照可能延迟快队列任务如向正在看该表的所有用户发送实时行更新信号但如果你有足够多的其他容器整个异步 worker 池仍然足以应对快慢任务混合。这些参数在 后端入口脚本 中有直接实现BASEROW_AMOUNT_OF_GUNICORN_WORKERS默认值 3、gunicorn 启动参数由此注入celery-worker命令在BASEROW_RUN_MINIMAL且BASEROW_AMOUNT_OF_WORKERS1时会改为-Q celery,export,automation_workflow合并队列模式而celery-exportworker此时直接空转退出与文档描述的行为一致。3.2.8 步骤 8部署完成此时你应已拥有一个完整运行的 Baserow 集群。第一个注册的用户会成为实例级的第一个 staff 全局管理员该用户可以在工具内配置 Baserow 设置、激活企业许可证、把其他用户提升为 staff 等。四、选项 2以独立服务形式部署到 Fargate/ECSbaserow/backend:2.3.3与baserow/web-frontend:2.3.3镜像允许把 Baserow 的各个服务作为独立容器运行。官方 Helm Chart 和各类 docker-compose 示例均基于这两个镜像最适合需要完全控制与灵活性的生产环境。4.1 为什么选择这种方式优点每个服务可独立扩缩控制粒度更细遵循传统的一容器一服务模型按服务维度查看日志和排障更容易单个容器更简单、活动部件更少。缺点整体搭建与维护更复杂需要更多 ALB 与网络配置确保正确的请求发到正确的服务。4.2 安装步骤先完成选项 1 中的步骤 1、2、3——S3 桶、RDS 与 Redis 的搭建完全相同。4.2.1 步骤 4配置 ALB 与目标组先创建 3 个 target type 为 IP 的目标组backend-asgi端口8000/HTTP健康检查 URL/api/_health/用于 WebSocket 服务backend-wsgi端口8000/HTTP健康检查 URL/api/_health/用于后端 API 服务web-frontend端口3000/HTTP健康检查 URL/_health/用于前端服务。健康检查端点结尾的斜杠是必须的然后创建监听 80 端口的 ALB默认路由到web-frontend组并为该监听器配置三条规则默认规则捕获其余所有请求转发到web-frontend路径条件/ws/*转发到backend-asgi路径条件/api/*转发到backend-wsgi。之后web-frontend服务需要通过负载均衡器与backend-wsgi通信。你可以复用同一个 ALB 同时处理外部请求和这些服务间请求但务必正确配置安全组允许 ECS 任务与 ALB 之间通信。4.2.2 步骤 5部署 Baserow 的各个服务为 Baserow 新建一个 ECS 集群然后依次创建下面的任务定义。熟悉 K8S 的话K8S 示例配置 给出了各服务概览docker-compose.no-caddy.yml 也可以作为参考——其中定义了backend8000 端口、web-frontend3000 端口、celerycelery-worker命令、celery-export-workercelery-exportworker命令与celery-beat-workercelery-beat命令等服务及其健康检查。4.2.3 步骤 6backend WSGI 服务该服务是 HTTP REST API 服务。创建任务定义时应使用baserow/backend:2.3.3镜像在 docker 配置中将 Command 设为gunicorn-wsgi,--timeout,60。建议把每个 HTTP API 请求的超时设为 60 秒如上命令默认 30 秒对超大 Baserow 表可能过短。建议每容器 2 vCPU 4 GB 内存起步映射容器端口8000/TCP协议选HTTPApp 协议标记容器为 essential设置以下环境变量记下它们稍后其他任务定义还要设置同样的变量用一个共享的环境文件是好主意环境变量说明BASEROW_PUBLIC_URL用户浏览器访问 Baserow 使用的公网 URL 或 IP应以http://或https://开头。DATABASE_HOSTBaserow 存储数据所用的 Postgres 主机名。DATABASE_USER连接DATABASE_HOST上数据库的用户名。DATABASE_PORT连接 Postgres 的端口。DATABASE_NAMEBaserow 存储数据所用的数据库名。DATABASE_PASSWORDDATABASE_HOST上DATABASE_USER的密码也可用DATABASE_PASSWORD_FILE指向注入的秘密文件。REDIS_URL标准 Redis 连接串redis://[redisuser]:[password][redishost]:[redisport]/0?ssl_cert_reqsrequired。AWS_STORAGE_BUCKET_NAME你的 AWS 存储桶名。AWS_ACCESS_KEY_IDS3 IAM 账户 Access Key非空即启用 S3 存储用户文件。AWS_SECRET_ACCESS_KEYS3 IAM 账户 Secret Key也可用AWS_SECRET_ACCESS_KEY_FILE代替。BASEROW_EXTRA_ALLOWED_HOSTS追加到 DjangoALLOWED_HOSTS的逗号分隔主机名加入 ALB IP 以放行健康检查或先临时用*。BASEROW_JWT_SIGNING_KEY必须设置且所有容器共享用于 token 签名也支持BASEROW_JWT_SIGNING_KEY_FILE。SECRET_KEY必须设置且所有容器共享Django 加密签名密码重置链接、会话等所用也支持SECRET_KEY_FILE。EMAIL_SMTP_*环境变量指南 中的 SMTP 变量用于发送邀请和密码重置邮件。从 入口脚本 可以确认gunicorn-wsgi会加载baserow.config.wsgi:application纯 WSGI不支持 WebSocketgunicorn则以 UvicornWorker 加载 ASGI 应用两者都先等待 Postgres 可用、再按MIGRATE_ON_STARTUP默认true执行数据库迁移——这正是首个容器自动完成迁移这一行为的实现来源。4.2.4 步骤 7backend ASGI 服务也可以只用 ASGI 服务而不单独建 ASGI/WSGI把所有 HTTP 和 WebSocket 请求都路由到单一 ASGI 服务。但 ASGI 服务处理普通 HTTP 请求的性能不如 WSGI 模式且分开后可以独立扩缩——通常只需少量 ASGI 实例即可扛住 WebSocket 负载。该服务是 WebSocket API 服务配置任务定义时应使用baserow/backend:2.3.3镜像docker 配置中 Command 设为gunicorn建议每容器 2 vCPU 4 GB 内存起步映射容器端口8000/TCP标记容器为 essential设置与 backend-wsgi 服务相同的环境变量。4.2.5 步骤 8backend celery worker 服务该服务是异步高优先级任务队列用于实时协作和发送邮件。使用baserow/backend:2.3.3镜像Command 设为celery-worker无需端口映射建议每容器 2 vCPU 4 GB 内存起步标记容器为 essential设置与 backend-wsgi 相同的环境变量。4.2.6 步骤 9backend celery export worker 服务该服务是异步慢/低优先级任务队列用于批处理及表导出、导入等潜在耗时的操作。使用baserow/backend:2.3.3镜像Command 设为celery-exportworker无需端口映射建议每容器 2 vCPU 4 GB 内存起步标记容器为 essential设置与 backend-wsgi 相同的环境变量。4.2.7 步骤 10backend celery beat 服务该服务是 CRON 任务调度器可以部署多个副本。使用baserow/backend:2.3.3镜像Command 设为celery-beat无需端口映射建议每容器 1 vCPU 3 GB 内存起步同一时刻只有一个这样的容器在全局调度任务其余副本作为热备当主实例失败并释放调度 Redis 锁时接管。标记容器为 essential设置与 backend-wsgi 相同的环境变量。多副本热备 Redis 锁的说法与源码相符入口脚本 中celery-beat使用redbeat.RedBeatScheduler调度器调度状态保存在 Redis 中并带有BASEROW_CELERY_BEAT_STARTUP_DELAY默认 15 秒的启动延迟以避免与其他 celery worker 启动时互相干扰锁。4.2.8 步骤 11web-frontend 服务该服务负责 Baserow 前端的服务器端渲染与托管。使用baserow/web-frontend:2.3.3镜像无需参数映射容器端口3000建议每容器 2 vCPU 4 GB 内存起步标记容器为 essential设置以下与后端服务不同的环境变量BASEROW_PUBLIC_URL用户浏览器访问 Baserow 使用的公网 URL 或 IP应以http://或https://开头PRIVATE_BACKEND_URLweb-frontend 容器需要向运行 REST API 的backend-wsgi容器发起 HTTP 请求。建议设为你的 ALB 地址且必须以http://或https://开头确保安全组配置正确允许这些内部 HTTP 请求如果你没有在backend-wsgi与backend-asgi上设置BASEROW_EXTRA_ALLOWED_HOSTS*务必把这个环境变量的值加入那些服务的BASEROW_EXTRA_ALLOWED_HOSTS否则它们不会接受来自 web-frontend 的连接。DOWNLOAD_FILE_VIA_XHR在 AWS S3 下必须设为1强制下载链接通过 XHR 下载以绕过Content-Disposition: inline文件若存储在另一个源下还必须配置 S3 CORS。4.2.9 步骤 12创建 ECS 服务回到刚才创建的任务定义并建立 ECS 服务。接线时记得在健康检查中设置900 秒grace period。也可以为所有 Baserow 任务创建单一 ECS 服务但需要通过 API/CLI 把多个目标组挂到该服务上目前 AWS UI 做不到并且你可能需要让backend-asgi与backend-wsgi暴露在不同端口上以便目标组正确路由方法是为这两个服务分别设置不同的BASEROW_BACKEND_PORT环境变量使它们在容器内绑定不同端口入口脚本 中该变量默认值为 8000。backend-wsgi服务 → 连接backend-wsgi目标组backend-asgi服务 → 连接backend-asgi目标组web-frontend服务 → 连接web-frontend目标组celery-worker服务celery-exportworker服务celery-beat服务。4.2.10 步骤 13扩缩容选项大多数情况下扩展backend-wsgi任务数和 RDS Postgres 是应对更多请求的第一选择如果实时协作变慢可扩展backend-asgi与celery-worker服务如果发现任务要等很久才开始Baserow UI 中的进度条卡在 0%可以增加更多celery-exportworker。此外以下环境变量可以改变每容器内部启动的 worker 进程数实现垂直扩展BASEROW_AMOUNT_OF_GUNICORN_WORKERS每gunicorn-wsgi或gunicorn容器的 REST API worker 数默认 3每个额外 worker 约多占 100–200 MB 内存BASEROW_AMOUNT_OF_WORKERScelery-worker与celery-exportworker容器中后台 celery runner 的数量。4.2.11 部署完成此时你应已拥有一个完整运行的 Baserow 集群。此部署方式更复杂如需帮助可到 Baserow 社区论坛提问。第一个注册的用户会成为实例级的第一个 staff 全局管理员可配置工具内设置、激活企业许可证、提升其他用户为 staff 等。五、升级 Baserow升级 ECS/Fargate 上的 Baserow 按以下顺序进行备份/快照 RDS Postgres 数据库先停止所有运行旧版本的容器避免用户在升级期间访问旧容器报错更新任务定义使用新版本镜像第一个启动的新baserow/baserow或baserow/backend-wsgi/asgi容器会自动应用所需的数据库迁移与升级迁移完成后所有新的 Baserow 容器开始接受请求升级完成。这一流程的机制可以在 后端入口脚本 中验证MIGRATE_ON_STARTUP默认为truegunicorn 服务启动前会先执行locked_migrate带锁迁移防止多个容器并发迁移因此停旧、起新、首个容器自动迁移的顺序是安全且必要的。六、常见问题FAQ6.1 修复CROSSSLOT Keys in request dont hash to the same slot错误日志中出现该错误说明你用了集群模式的 Redis 启动 Baserow。Baserow 使用的库不支持 Redis 集群模式需要换一个非集群模式的 Redis。非集群模式的 Redis 同样可以扩展和跨多可用区部署而且 Baserow 一般不会出现以 Redis 为请求瓶颈的情况。6.2 ELB 健康检查失败首次部署或升级后的首轮迁移可能耗时较长可以尝试增大 grace period确认 ELB 能连通容器。注意容器内部有自己的健康检查脚本也会调用健康检查端点——所以日志里出现 200 响应不代表触发者是 ELB。6.3 从 Baserow 文件字段下载文件时出现 CORS 错误S3 桶的 CORS 没有配置好请参考 3.2.1 节中的 CORS 示例配置。6.4 出现Secure Redis scheme specified (rediss) with no ssl options, defaulting to insecure SSL behavior警告确认已在REDIS_URL环境变量末尾添加?ssl_cert_reqsrequired。小结AWS 上部署 Baserow 的核心是数据层外置、容器无状态——RDS 存数据、S3 存文件、Redis 做缓存/实时/任务队列容器层无论 all-in-one 还是分服务均可自由替换与扩缩。选项 1 适合快速上生产选项 2 适合需要精细控制与独立扩缩的规模两种方案共享同一套底层资源与升级流程可平滑互转。【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
