1. 项目概述为什么企业内部工具开发正在被 ILLA Builder 改写ILLA Builder 不是又一个“拖拽建站”的玩具它是专为企业级内部系统场景打磨出来的低代码生产力引擎。我带过三个不同行业的数字化团队从制造业的设备巡检看板、零售业的门店库存调度后台到金融公司的合规审批流管理界面——所有这些系统共同点是需求急、迭代快、用户固定、数据敏感、不对外暴露但传统开发周期动辄2~3周起步前端后端部署全链路卡点太多。而 ILLA Builder 的核心价值就藏在它那句没怎么宣传却极其关键的定位里“JS 驱动 数据库直连 极速部署”。它不遮掩逻辑层也不抽象掉数据库权限控制而是把开发者最熟悉的 JS 作为业务胶水把 PostgreSQL/MySQL/MongoDB 这类生产级数据库当作原生底座再用 Docker 封装成可一键复现的运行单元。这意味着什么意味着你写完一个查询语句、配好一个按钮点击事件、拖好一个表格组件整个应用就能打包成镜像推到阿里云 ECS、腾讯云 CVM甚至本地一台 16G 内存的 Ubuntu 服务器上直接跑起来全程不需要 Nginx 配置、不用手动启 Node 进程、不碰 PM2 或 Systemd。这不是“简化”而是对内部工具交付链路的一次结构性压缩。它解决的不是“会不会写代码”的问题而是“要不要为一个审批表单专门开一个 Git 仓库、搭一套 CI/CD、申请一个域名、配一次 HTTPS 证书”的问题。如果你正被“这个小功能要排期、那个报表要等前端、那个接口要等后端联调”反复消耗那么 ILLA Builder 的部署路径就是你技术团队重获响应力的第一步。2. 整体设计思路与方案选型逻辑2.1 为什么必须用 Docker 部署而不是 npm run start 或二进制包很多人第一次看到 ILLA Builder 文档里清一色的docker-compose.yml示例会下意识想“能不能跳过 Docker直接用源码启动”我试过在 Ubuntu 22.04 上 clone 官方仓库yarn install yarn build yarn start表面能跑但很快就会撞上三堵墙第一堵是环境依赖墙——ILLA 后端服务依赖 Rust 编写的 query-engine用于 SQL 查询优化前端构建依赖 WebAssembly 工具链Node.js 版本锁死在 18.x且必须启用--openssl-legacy-provider第二堵是配置漂移墙——开发模式下所有配置靠.env文件注入但生产环境需要区分数据库连接池大小、JWT 密钥轮换周期、文件上传临时目录权限、S3 兼容对象存储的 endpoint 地址这些参数一旦硬编码进代码或靠 shell 脚本拼接就彻底失去可审计性第三堵是升级维护墙——ILLA 每月发布两个 patch 版本如 v2.15.3 → v2.15.4每次升级需同步更新前端静态资源、后端二进制、migration 脚本、Redis Schema 初始化逻辑手工操作极易漏掉某一项导致/api/v1/users/me接口返回 500 却查不到日志源头。而 Docker 的本质是把“操作系统 运行时 应用二进制 配置模板 启动脚本”这整套状态固化成一个不可变的镜像 ID。你今天在测试机上docker pull illacloud/illa-builder:v2.15.4跑通了明天在生产机上拉同一个镜像只要内核版本 ≥5.4、cgroup v2 已启用、磁盘空间 ≥20GB它就必然以完全一致的行为启动。这不是偷懒而是把“环境一致性”这个长期困扰运维的隐性成本显性地收编进docker-compose.yml的 47 行 YAML 里。所以Docker 不是可选项而是 ILLA Builder 生产落地的基础设施前提。2.2 为什么官方推荐 docker-compose 而非裸 docker runILLA Builder 的完整服务栈包含 5 个强耦合容器illa-server主后端、illa-dbPostgreSQL、illa-redis缓存与任务队列、illa-minio文件存储、illa-nginx反向代理与静态资源服务。如果用docker run手动启动你需要依次执行docker run -d --name illa-db -e POSTGRES_PASSWORDilla123 -v /data/illa/db:/var/lib/postgresql/data -p 5432:5432 postgres:14-alpine docker run -d --name illa-redis -v /data/illa/redis:/data redis:7-alpine redis-server /etc/redis.conf docker run -d --name illa-minio -e MINIO_ROOT_USERadmin -e MINIO_ROOT_PASSWORDpassword -v /data/illa/minio:/data -p 9000:9000 minio/minio server /data docker run -d --name illa-server -e DB_HOSTilla-db -e REDIS_URLredis://illa-redis:6379 -e MINIO_ENDPOINThttp://illa-minio:9000 ... -p 8080:8080 illacloud/illa-builder:v2.15.4 docker run -d --name illa-nginx -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf:ro -v $(pwd)/dist:/usr/share/nginx/html:ro -p 80:80 nginx:alpine这段命令的问题在于容器间网络靠--link已废弃必须手动创建 bridge network 并指定--network健康检查需额外加--health-cmd重启策略要每个容器单独设日志驱动要统一配--log-driver json-file --log-opt max-size10m更致命的是illa-server启动时会尝试连接illa-db但 PostgreSQL 容器初始化需要 10~15 秒illa-server若抢先启动必报Connection refused你得写 shell 脚本循环检测端口或者用wait-for-it.sh。而docker-compose.yml天然解决这些问题depends_on可声明启动顺序虽不保证服务就绪但配合healthcheck就完整了networks自动创建隔离网段volumes统一管理挂载点restart: unless-stopped一行搞定进程守护最关键的是它把整个系统当作一个“应用单元”来编排而不是五个独立进程。我们团队在给某省电力公司部署设备台账系统时曾因误用裸docker run导致 Redis 容器重启后illa-server无法自动重连花了 3 小时排查才发现是--restartalways没生效——这种坑docker-compose up -d一条命令就绕过去了。2.3 为什么默认不推荐使用 SQLite企业级场景的数据库选型真相ILLA Builder 官方文档开头就写着“支持 SQLite / PostgreSQL / MySQL / MongoDB”很多技术负责人看到“SQLite”就心动了零配置、单文件、不用装数据库服务简直是内部工具的完美搭档。但我在三个真实项目中踩过坑后明确建议任何日活 50 人的企业级内部系统必须弃用 SQLite直连 PostgreSQL。原因很实在SQLite 是文件锁模型当多个用户同时提交审批单、导出 Excel 报表、刷新实时看板时写操作会排队阻塞实测在 20 并发下平均响应延迟从 120ms 涨到 2.3s它的 WAL 模式虽缓解读写冲突但无法解决多进程竞争同一 db 文件的 inode 锁问题更严重的是备份——SQLite 备份必须停服或使用sqlite3 .dump命令而企业系统不能接受“每天凌晨 2 点停服务 5 分钟”。反观 PostgreSQL我们用pg_dump -Fc --no-acl --no-owner -h illa-db -U illa_user illa_db backup.dump全程在线、增量可选、压缩率 65%配合cron每 4 小时一次快照毫无压力。更重要的是权限体系ILLA 的“数据源管理”模块允许为不同团队配置不同数据库账号PostgreSQL 的ROW LEVEL SECURITY可精确到“销售部只能查自己区域的客户数据”SQLite 根本没有用户概念。所以所谓“轻量”不是指数据库体积小而是指运维复杂度低——PostgreSQL 在 Docker 里就是一条image: postgres:14-alpine它的“重”是能力重不是部署重。3. 核心细节解析与实操要点3.1 最小可行部署包结构5 个文件决定成败一个真正可交付的企业级 ILLA 部署包绝不是丢一个docker-compose.yml就完事。我经过 12 次迭代最终稳定下来的最小文件集是这 5 个illa-prod/ ├── docker-compose.yml # 主编排文件定义 5 个服务及网络 ├── .env # 环境变量模板含 DB 密码、JWT 密钥等 ├── nginx.conf # Nginx 配置含 gzip、CORS、静态资源缓存 ├── init-db.sql # 首次启动时自动执行的数据库初始化脚本 └── healthcheck.sh # 自定义健康检查脚本供 docker-compose 调用其中.env文件内容必须包含以下 8 个强制变量缺一不可# 数据库连接 DB_HOSTilla-db DB_PORT5432 DB_NAMEilla_db DB_USERilla_user DB_PASSWORDStrongPassw0rd!2024 # Redis 连接 REDIS_URLredis://illa-redis:6379/0 # MinIO 对象存储 MINIO_ENDPOINThttp://illa-minio:9000 MINIO_ACCESS_KEYadmin MINIO_SECRET_KEYpassword # JWT 安全密钥必须随机生成不可用默认值 JWT_SECRET3a7b9c2d1e8f4g6h5i0j7k1l2m9n3o4p5q6r7s8t9u0v1w2x3y4z5 # 管理员初始账号首次启动时自动创建 ADMIN_EMAILadmincompany.com ADMIN_PASSWORDAdminPassw0rd!2024提示JWT_SECRET必须是 32 字节以上的随机字符串我用openssl rand -hex 32生成绝不能写mysecret123。因为 ILLA 的 session token、API key 签名都依赖它一旦泄露攻击者可伪造任意用户身份。我们曾因测试环境误提交.env到 GitLab被安全扫描工具告警紧急回滚并轮换了所有环境密钥。init-db.sql的作用是绕过 ILLA 内置 migration 的“黑盒”风险。官方 migration 脚本在 v2.14 升级到 v2.15 时曾因未处理jsonb字段默认值导致illa-server启动失败。而我们自定义的init-db.sql只做三件事创建illa_user用户并赋予权限创建illa_db数据库并设置 owner执行CREATE EXTENSION IF NOT EXISTS uuid-ossp;ILLA 依赖此扩展生成 UUID。这样无论 ILLA 版本如何迭代数据库底座始终可控。3.2 nginx.conf 的 4 个关键配置项不只是反向代理ILLA 官方docker-compose.yml默认不带 Nginx而是让illa-server直接监听 8080 端口。这在开发环境没问题但企业级部署必须加一层 Nginx原因有四静态资源缓存ILLA 前端构建产物/dist包含 127 个 JS/CSS 文件总大小 8.2MB。Nginx 可对*.js*.css*.png设置expires 1y;浏览器首次加载后后续访问无需重复下载实测首屏时间从 3.2s 降至 0.8sCORS 精确控制ILLA 的 API 接口需响应Access-Control-Allow-Origin。若由illa-server动态生成需修改其源码而 Nginx 可在location /api/块中硬编码add_header Access-Control-Allow-Origin https://intranet.company.com;杜绝跨域泄露风险请求体大小限制ILLA 的文件上传接口/api/v1/upload默认限制 10MB但财务系统常需上传 200MB 的 PDF 凭证。Nginx 的client_max_body_size 500M;一行解决无需改后端代码HTTPS 终结企业内网虽可用 HTTP但若需对接钉钉/企微 OAuth平台强制要求https://回调地址。Nginx 可加载公司统一证书illa-server仍走 HTTP 内部通信解耦安全与业务。我们的nginx.conf核心片段如下upstream illa_backend { server illa-server:8080; } server { listen 80; server_name _; # 强制 HTTPS 重定向若启用 SSL # return 301 https://$host$request_uri; location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; expires 1y; add_header Cache-Control public, immutable; } location /api/ { proxy_pass http://illa_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; client_max_body_size 500M; add_header Access-Control-Allow-Origin https://intranet.company.com; add_header Access-Control-Allow-Methods GET, POST, OPTIONS, PUT, DELETE; add_header Access-Control-Allow-Headers DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization; } }注意add_header指令在if块中无效必须写在location或server级别client_max_body_size必须放在location /api/块内否则对根路径无效。3.3 Docker 镜像源与国内加速不是加个 registry-mirrors 就够了国内服务器拉取illacloud/illa-builder镜像平均耗时 8~12 分钟超时失败率 37%。单纯在/etc/docker/daemon.json加registry-mirrors只能加速基础镜像如postgres:14-alpine对illacloud/*这类第三方镜像无效——因为它们托管在 GitHub Container Registryghcr.io而 ghcr.io 不在阿里云/腾讯云镜像站的同步列表中。我们实测有效的组合方案是Hosts 绑定 DNS 缓存在/etc/hosts添加140.82.112.6 ghcr.io该 IP 为 GitHub 官方 CDN 节点需定期更新Docker BuildKit 启用在/etc/docker/daemon.json中开启features: {buildkit: true}使docker build使用并行拉取离线镜像包预置从海外机器docker pull illacloud/illa-builder:v2.15.4 docker save -o illa-builder-v2.15.4.tar illacloud/illa-builder:v2.15.4再scp到内网服务器docker load -i illa-builder-v2.15.4.tarMinIO 替代 ghcr.io搭建私有 MinIO 作为镜像仓库用skopeo copy将远程镜像同步过来docker-compose.yml中image改为minio.company.com/illa/illa-builder:v2.15.4。我们给某银行部署时采用第 3 种方案将镜像包与部署脚本打包成illa-prod-v2.15.4.tgz交付给客户运维团队他们只需tar -xzf解压后docker-compose up -d全程 92 秒完成彻底规避网络波动风险。4. 实操过程与核心环节实现4.1 从零开始的 7 步部署流程Ubuntu 22.04 LTS以下是我在线上环境反复验证的标准化流程每一步均附实操命令与预期输出确保新手也能一次成功步骤 1系统准备与 Docker 安装# 更新系统并安装依赖 sudo apt update sudo apt upgrade -y sudo apt install -y curl gnupg2 software-properties-common ca-certificates # 添加 Docker 官方 GPG 密钥注意必须用 https://download.docker.com/linux/ubuntu不能用国内镜像源的 key curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 添加 stable 仓库国内用户请将 https://download.docker.com 替换为 https://mirrors.ustc.edu.cn/docker-ce echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io # 启动 Docker 并加入开机自启 sudo systemctl enable docker sudo systemctl start docker # 验证安装预期输出Client: Docker Engine - Community... Server: Docker Engine - Community... docker --version docker info | grep Server Version步骤 2创建部署目录并下载配置文件mkdir -p ~/illa-prod cd ~/illa-prod # 下载我整理好的标准配置包含 docker-compose.yml, .env, nginx.conf 等 curl -L https://raw.githubusercontent.com/illa-cloud/illa-builder/main/deploy/docker-compose.yml -o docker-compose.yml curl -L https://raw.githubusercontent.com/illa-cloud/illa-builder/main/deploy/.env.example -o .env # 修改 .env 中的密码、密钥、邮箱务必用 vim 或 nano不要用记事本 vim .env步骤 3生成并配置 JWT_SECRET# 生成 32 字节随机密钥注意必须用单引号包裹避免 shell 解析特殊字符 JWT_SECRET$(openssl rand -hex 32) sed -i s/JWT_SECRET.*/JWT_SECRET$JWT_SECRET/g .env echo JWT_SECRET 已更新为$JWT_SECRET步骤 4启动服务并等待初始化# 后台启动所有容器 docker-compose up -d # 查看启动状态预期5 个容器状态均为 Up且 10 分钟内无 Crash docker-compose ps # 实时查看 illa-server 日志直到出现 ILLA Builder is ready on http://localhost:8080约 3~5 分钟 docker-compose logs -f illa-server | grep is ready步骤 5验证数据库初始化# 进入 PostgreSQL 容器执行检查 docker-compose exec illa-db psql -U illa_user -d illa_db -c \dt # 预期输出应包含至少 12 张表如 users, applications, resources, queries 等 # 若报错 FATAL: database illa_db does not exist说明 init-db.sql 未执行需检查 docker-compose.yml 中 volumes 是否挂载正确步骤 6配置 Nginx 并启用 HTTPS可选# 将 nginx.conf 复制到容器内假设已准备好配置文件 docker cp nginx.conf illa-nginx:/etc/nginx/nginx.conf # 重新加载 Nginx 配置 docker-compose exec illa-nginx nginx -s reload # 若需 HTTPS将证书放入 ~/illa-prod/certs/并在 nginx.conf 中添加 # ssl_certificate /etc/nginx/certs/fullchain.pem; # ssl_certificate_key /etc/nginx/certs/privkey.pem;步骤 7首次登录与权限校验# 浏览器访问 http://服务器IP输入 .env 中配置的 ADMIN_EMAIL 和 ADMIN_PASSWORD # 登录后进入「Settings」→「Members」创建部门管理员账号如 devopscompany.com # 为该账号分配「Super Admin」角色然后登出用新账号登录验证权限继承 # 关键检查点能否创建新应用能否添加 PostgreSQL 数据源能否运行 SQL 查询整个流程耗时约 18 分钟网络良好情况下比官方文档节省 40% 时间因为我们跳过了git clone、yarn build、npm install等不可控环节全部基于预编译镜像。4.2 生产环境必须做的 5 项加固配置部署成功只是起点企业级系统必须立即执行以下加固操作否则存在严重安全隐患禁用默认管理员账号.env中的ADMIN_EMAIL仅用于首次初始化登录后必须在 UI 中删除该账号或执行 SQL 删除DELETE FROM users WHERE email admincompany.com;否则任何知道该邮箱的人都可通过 “忘记密码” 重置账户。限制数据库连接来源修改docker-compose.yml中illa-db服务的command强制只接受illa-server容器连接command: [postgres, -c, listen_addresses127.0.0.1, -c, port5432]并在illa-server的environment中添加DB_HOST127.0.0.1切断外部直连可能。关闭 MinIO 的匿名访问默认 MinIO 允许curl http://ip:9000/minio/health/live无需认证。在docker-compose.yml中为illa-minio添加环境变量environment: - MINIO_ROOT_USERadmin - MINIO_ROOT_PASSWORDpassword - MINIO_SERVER_URLhttp://illa-minio:9000并在 ILLA UI 的「Data Sources」中配置 MinIO 时必须填写 Access Key/Secret Key禁用匿名模式。配置日志轮转与保留策略Docker 默认不限制日志大小illa-server日志 3 天即可突破 10GB。在docker-compose.yml的每个服务下添加logging: driver: json-file options: max-size: 10m max-file: 5启用 HTTPS 强制重定向在nginx.conf的server块中取消注释return 301 https://$host$request_uri;并确保ssl_certificate路径正确。我们使用 Lets Encrypt 的certbot自动续签脚本如下#!/bin/bash certbot certonly --standalone -d illa.company.com --non-interactive --agree-tos --email admincompany.com docker-compose exec illa-nginx nginx -s reload实操心得某车企客户因未执行第 1 条被离职员工利用默认账号导出全部供应商报价单造成商业损失。自此我们所有部署脚本都内置sleep 30 docker-compose exec illa-server psql -c DELETE FROM users WHERE email admincompany.com;确保初始化后 30 秒自动清理。5. 常见问题与排查技巧实录5.1 启动失败的 4 类高频问题与秒级定位法ILLA 部署中最让人抓狂的不是报错信息看不懂而是容器反复 restart日志里只有exited with code 1这种废话。根据我们 37 个生产环境案例92% 的启动失败可归为以下四类按此顺序排查平均定位时间 3 分钟问题类型典型现象快速定位命令根本原因解决方案环境变量缺失illa-server容器日志首行报error: DB_HOST is requireddocker-compose config | grep -A5 illa-server.env文件中DB_HOST未定义或拼写错误如DB_HOSt用grep DB_HOST .env确认存在且值为illa-db不是localhost数据库未就绪illa-server日志循环打印connect ECONNREFUSED 172.20.0.3:5432docker-compose logs illa-db | tail -20illa-db容器启动慢于illa-serverPostgreSQL 初始化未完成在docker-compose.yml的illa-server下添加depends_on: { illa-db: { condition: service_healthy } }并在illa-db中定义healthcheckMinIO 访问拒绝illa-server日志出现Error: Unable to connect to MinIOdocker-compose exec illa-minio mc alias set myminio http://localhost:9000 admin passwordilla-server容器内 DNS 解析illa-minio失败或 MinIO 未启用 TLS将MINIO_ENDPOINT改为http://illa-minio:9000不是http://localhost:9000端口被占用docker-compose up报Bind for 0.0.0.0:80 failed: port is already allocatedsudo ss -tulnp | grep :80Nginx/Apache 已占 80 端口或前次部署未清理干净sudo fuser -k 80/tcp强制杀进程或改nginx.conf中listen 8081;提示docker-compose config是你的第一道防线它会把.env变量渲染进最终配置并校验 YAML 语法。每次修改.env或docker-compose.yml后务必先执行docker-compose config看到services: { illa-server: {...} }才继续。5.2 数据库迁移失败的深度排查v2.14 → v2.15 升级实录去年我们为客户升级 ILLA 从 v2.14.2 到 v2.15.1 时illa-server启动后立即 crash日志只有一行error: failed to run migrations: error returned from database: column created_at contains null values这是典型的 schema migration 冲突。PostgreSQL 在添加NOT NULL字段时若表中已有数据必须提供DEFAULT值。而 ILLA 的 migration 脚本20230915123456_add_created_at_to_applications.ts没有处理存量数据。我们的排查路径进入illa-db容器docker-compose exec illa-db bash连接数据库psql -U illa_user illa_db查看问题表结构\d applications发现created_at字段确实存在但为NULL检查 migration 历史SELECT * FROM _prisma_migrations ORDER BY finished_at DESC LIMIT 5;确认最后执行的是20230915123456_add_created_at_to_applications手动修复UPDATE applications SET created_at NOW() WHERE created_at IS NULL;重新运行 migrationdocker-compose exec illa-server npx prisma migrate resolve --applied 20230915123456_add_created_at_to_applications经验总结ILLA 的 Prisma ORM 在 v2.15 后启用了 strict mode对 schema 变更更敏感。我们现在的升级 SOP 是先在测试环境docker-compose down docker volume rm illa-prod_illa-db彻底清空数据库用init-db.sql重建再导入生产数据 dump最后执行docker-compose up -d。虽然多花 20 分钟但避免了线上事故。5.3 性能瓶颈的 3 个监控指标与调优阈值企业级系统上线后不能只看“能不能用”更要盯住“用得稳不稳”。我们为 ILLA 部署了轻量级监控重点关注以下三个指标一旦越界立即告警PostgreSQL 连接数使用率SELECT COUNT(*)*100.0/(SELECT setting::int FROM pg_settings WHERE name max_connections) AS usage_pct FROM pg_stat_activity;阈值85%→ 立即扩容max_connections在docker-compose.yml的illa-db中加command: [postgres, -c, max_connections200]否则新用户登录会卡在“加载中”。Redis 内存使用率docker-compose exec illa-redis redis-cli info memory \| grep used_memory_human阈值90%→ 检查是否有大 keydocker-compose exec illa-redis redis-cli --bigkeys或调整maxmemory-policy allkeys-lru在redis.conf中设置。Nginx 请求延迟 P95awk {print $9} /var/log/nginx/access.log \| sort -n \| tail -n 1000 \| head -n 1 | xargs echo阈值1500ms→ 检查是否启用了gzipnginx.conf中gzip on;或增加proxy_buffering on;缓冲后端响应。我们给某物流公司部署的订单看板P95 延迟一度达 2800ms排查发现是nginx.conf中漏了gzip_types application/json text/css application/javascript;补上后降至 420ms。这种细节官方文档从不提但却是企业级稳定性的命脉。5.4 容器崩溃后的 5 分钟应急恢复手册即使做了万全准备生产环境仍可能突发崩溃。我们制定的 SRE 应急流程如下实测平均恢复时间 4 分钟 17 秒第 1 分钟快速诊断docker-compose ps查看哪个服务状态异常如Unhealthy或Restartingdocker-compose logs --tail 50 service-name抓取最近日志如illa-server第 2 分钟隔离故障若illa-db崩溃docker-compose stop illa-db防止磁盘写满若illa-server崩溃docker-compose stop illa-server避免日志刷屏第 3 分钟数据保护docker volume ls \| grep illa确认卷名如illa-prod_illa-dbdocker run --rm -v illa-prod_illa-db:/volume -v $(pwd):/backup alpine tar czf /backup/db-backup-$(date %s).tar.gz -C /volume .将数据库卷打包到当前目录命名含时间戳第 4 分钟服务重启docker-compose up -d illa-db等待 30 秒docker-compose up -d illa-server等待 60 秒第 5 分钟功能验证访问http://ip/api/v1/health预期返回{status:ok}登录 UI创建一个新应用添加一个 PostgreSQL 数据源执行SELECT 1确认绿色对勾注意所有命令必须提前写在~/illa-prod/emergency.sh中运维人员只需bash emergency.sh避免手抖输错。我们曾因手动输入docker volume rm误删了生产卷从此所有高危操作都封装成带--dry-run参数的脚本。6. 后续演进与团队协作建议ILLA Builder 的部署不是终点而是企业低代码能力建设的起点。我们在交付第 7 个客户后沉淀出一套“部署即治理”的协作规范让技术团队、业务部门、安全部门在同一套语言下工作版本冻结机制禁止直接docker-compose pull升级。所有新版本必须经 QA 团队在测试环境验证 3 天含压力测试、权限测试、导出测试通过后生成illa-prod-v2.15.4-release.tgz包内含CHANGELOG.md注明修复的 CVE 编号、SECURITY.md