企业官网建设流程全解析

1. 为什么要在 OpenEuler 上自建云表格服务

把在线表格跑在自己的服务器上，这个念头最早来自一次团队内部的讨论。我们用过不少公有云的在线表格产品，功能确实强，但数据放在别人机房这件事，总让负责合规的同事睡不踏实。尤其是涉及项目排期、成本核算、客户清单这类表格，一旦外发就收不回来。于是就有了这个项目：在 OpenEuler 上搭一套私有化的云表格服务，数据完全落在自己手里，局域网内随时访问，外网按需开放。

OpenEuler 是我选定的底座。它是国内主流的开源服务器操作系统，长期支持版本稳定，软件源里该有的组件基本都有，社区文档也够用。更重要的是，它在 ARM 和 x86 上都能跑，公司里那批鲲鹏机器正好派上用场。云表格服务这块，我最终选的是基于开源电子表格内核的方案，前端用浏览器访问，后端负责存储和协同，整体架构不复杂，但坑不少。

这篇文章适合谁看？如果你手上有 OpenEuler 的服务器，想搭一套团队内部用的在线表格，又不想依赖外部服务，那这篇就是给你写的。我会从系统准备、依赖安装、服务部署、反向代理配置一路讲到权限和排错，中间穿插我自己踩过的坑。整个过程不需要你精通 Linux，但基本的命令行操作得会。读完你至少能拿到一套可运行的方案，运气好的话，一次就能跑通。

需要提前说明的是，云表格服务的选型有很多种，我这里的方案偏向轻量、易维护，适合几十人以内的小团队。如果你的场景是几百人协同、需要复杂的权限体系，那可能需要考虑更重的方案，但底层的 OpenEuler 配置思路是相通的。

2. 环境准备与系统基础配置

2.1 OpenEuler 版本选择与安装要点

版本这块，我建议直接用 OpenEuler 的 LTS 版本，比如 22.03 LTS 或 24.03 LTS。LTS 意味着长期维护，软件源稳定，不会出现今天装完明天源就失效的情况。我这次用的是 22.03 LTS SP 系列，实测下来很稳。安装的时候有几个点要注意：分区方案上，如果只是跑云表格服务，根分区给 50G 足够，但数据盘一定要单独挂载，因为表格文件和数据库会持续增长，混在根分区里后期扩容很麻烦。

安装类型选“服务器”即可，不需要图形界面。图形界面除了占资源，对服务运行没有任何帮助。网络配置在安装阶段就可以设好静态 IP，省得装完再改。这里有个细节：OpenEuler 安装器里的网络配置和装完之后的配置方式不太一样，安装阶段设的静态 IP 有时候在 NetworkManager 接管后会失效，所以装完之后我习惯再检查一遍。

提示：安装时如果勾选了“自动分区”，系统可能会用 LVM 把根分区撑满整个磁盘，导致你后面想单独加数据盘时空间分配很别扭。建议手动分区，或者至少留出一块未分配空间。

装完系统第一件事，更新软件源并升级现有包：

sudo dnf makecache sudo dnf update -y

OpenEuler 默认的软件源速度还可以，如果在内网环境，可以换成公司内部的镜像源，速度会快很多。升级完重启一次，确保内核和关键组件都是最新的。

2.2 网络配置的几种方式与选择

OpenEuler 的网络管理有好几种方式，这也是热词里经常被问到的点。常见的有 NetworkManager 的 nmcli、nmtsui 图形工具，以及传统的 network-scripts。22.03 之后默认是 NetworkManager 接管，network-scripts 虽然还能用，但已经不推荐了。

我习惯用 nmcli，命令行操作清晰，脚本化也方便。查看当前连接：

nmcli connection show

假设你的网卡是 ens33，要设静态 IP，可以这样操作：

sudo nmcli connection modify ens33 ipv4.addresses 192.168.1.100/24 sudo nmcli connection modify ens33 ipv4.gateway 192.168.1.1 sudo nmcli connection modify ens33 ipv4.dns "223.5.5.5 114.114.114.114" sudo nmcli connection modify ens33 ipv4.method manual sudo nmcli connection up ens33

这里有个坑：如果你之前用 DHCP 拿过地址，改成 manual 之后一定要把 connection 重新 up 一次，否则 IP 不会立即生效。另外 DNS 建议配两个，一个主用一个备用，避免解析单点故障。

如果你更习惯传统方式，也可以编辑/etc/sysconfig/network-scripts/ifcfg-ens33，把BOOTPROTO改成static，然后手动填 IPADDR、GATEWAY、DNS1。改完用systemctl restart NetworkManager生效。两种方式选一种就行，别混着用，否则容易出现配置冲突。

2.3 防火墙与 SELinux 的前期处理

云表格服务要对外提供 Web 访问，防火墙必须放行对应端口。OpenEuler 默认用的是 firewalld。我一般先看当前开了哪些端口：

sudo firewall-cmd --list-all

假设云表格服务最终跑在 8080 端口，反向代理走 80 和 443，那就这样放行：

sudo firewall-cmd --permanent --add-port=8080/tcp sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --reload

SELinux 这块，我的建议是不要直接关掉，而是用 permissive 模式先跑起来，观察有没有拒绝日志，确认没问题后再考虑保持 enforcing 或者针对性放行。直接setenforce 0虽然省事，但等于放弃了系统的一道安全防线，生产环境不推荐。

sudo setenforce 0

临时改成 permissive 之后，用getenforce确认状态。如果后面服务跑起来有权限问题，可以用ausearch -m avc -ts recent查看 SELinux 拒绝记录，再决定是加策略还是调整文件上下文。

3. 依赖组件安装与数据库准备

3.1 安装 Docker 与容器运行时

云表格服务的部署方式，我选的是容器化。原因很简单：依赖隔离、升级方便、迁移容易。OpenEuler 上装 Docker 有两条路，一条是用系统源里的 docker，另一条是加 Docker 官方源。系统源里的版本可能偏旧，但对稳定性要求高的场景够用。我这次用的是系统源，省得处理源信任问题。

sudo dnf install -y docker sudo systemctl enable --now docker

装完确认一下版本和运行状态：

docker version systemctl status docker

如果你需要更新的 Docker 版本，也可以配置官方源，但要注意 OpenEuler 的版本代号和 CentOS 不完全一样，直接套用 CentOS 的源地址可能会出问题。稳妥起见，系统源自带的版本先用着，除非你有明确的版本需求。

注意：Docker 装完后，普通用户默认没有权限操作，需要把用户加入 docker 组：sudo usermod -aG docker $USER，然后重新登录生效。这一步很多人会忘，导致后面执行 docker 命令一直报权限错误。

3.2 数据库选型与初始化

云表格服务的后端需要存表格元数据、用户信息、协同记录，数据库这块我选的是 PostgreSQL。相比 MySQL，PostgreSQL 在 JSON 字段、并发控制上更符合这类应用的需求，而且开源协议更宽松。安装直接用容器跑，省得配系统服务：

docker run -d \ --name cloudsheet-db \ -e POSTGRES_PASSWORD=YourStrongPassword \ -e POSTGRES_DB=cloudsheet \ -v /data/pgdata:/var/lib/postgresql/data \ -p 5432:5432 \ postgres:15

这里有几个关键点。第一，POSTGRES_PASSWORD一定要设强密码，别用默认的。第二，数据目录挂载到宿主机/data/pgdata，这样容器删了数据还在。第三，端口映射我只映射到本机，不对外暴露，因为数据库只需要被同机的应用访问，暴露到公网是自找麻烦。

初始化完成后，进容器建一个专用用户：

docker exec -it cloudsheet-db psql -U postgres

CREATE USER sheetuser WITH PASSWORD 'AnotherStrongPassword'; CREATE DATABASE cloudsheet OWNER sheetuser; GRANT ALL PRIVILEGES ON DATABASE cloudsheet TO sheetuser; \q

数据库这块的坑主要在字符集和时区。PostgreSQL 容器默认可能是 UTC 时区，如果你的表格里有时间字段，显示出来会差几个小时。可以在启动容器时加-e TZ=Asia/Shanghai，或者在数据库里设置时区。我一般直接在容器环境变量里解决，省得后面改。

3.3 反向代理组件 OpenResty 的引入

热词里提到了 OpenResty，这确实是个好东西。云表格服务本身跑在应用端口上，但对外最好统一走 80 或 443，这就需要反向代理。Nginx 也能做，但 OpenResty 集成了 Lua，后面要做限流、鉴权、动态路由会方便很多。OpenEuler 上装 OpenResty，可以用官方源，也可以用系统源里的 openresty 包。

sudo dnf install -y openresty sudo systemctl enable --now openresty

装完确认版本：

openresty -v

如果系统源里没有，或者版本太旧，可以去 OpenResty 官网找对应 OpenEuler 的包。热词里提到的openresty1.11.2.5-1 for openeuler 24就是一个具体版本，说明社区已经在做适配了。装的时候注意依赖，pcre、openssl、zlib这几个开发库要提前装好，否则编译或者运行时会报缺库。

反向代理的配置我放到后面单独讲，这里先把组件备齐。到这一步，系统层面的准备基本完成：OpenEuler 跑起来了，网络通了，防火墙放行了，Docker 和数据库就绪，OpenResty 也装好了。接下来就是云表格服务本体的部署。

4. 云表格服务部署与核心配置

4.1 服务镜像获取与容器启动

云表格服务的镜像，我用的是社区维护的开源方案。获取方式有两种，一种是直接拉现成镜像，另一种是自己构建。现成镜像省事，但版本可能不是最新的；自己构建可控，但需要处理依赖。我建议先用现成镜像跑通，再考虑定制。

docker pull cloudsheet/cloudsheet:latest

拉下来之后，先别急着跑，用docker inspect看看镜像暴露的端口和环境变量要求：

docker inspect cloudsheet/cloudsheet:latest | grep -A 20 "Env"

这一步很多人跳过，结果启动时报缺环境变量。看清楚需要哪些参数，再写启动命令。我的启动命令大概长这样：

docker run -d \ --name cloudsheet-app \ -e DB_HOST=172.17.0.1 \ -e DB_PORT=5432 \ -e DB_NAME=cloudsheet \ -e DB_USER=sheetuser \ -e DB_PASSWORD=AnotherStrongPassword \ -e APP_URL=http://sheet.example.com \ -v /data/cloudsheet/uploads:/app/uploads \ -p 8080:8080 \ cloudsheet/cloudsheet:latest

这里DB_HOST用的是172.17.0.1，这是 Docker 默认网桥的宿主机地址。因为数据库跑在另一个容器里，应用容器要访问它，走宿主机地址是最直接的方式。当然你也可以建自定义网络，把两个容器放同一个网络里，用容器名互访，那样更优雅。我图省事先用宿主机地址，实测也能跑。

APP_URL这个变量很重要，它决定了表格里生成的分享链接、回调地址长什么样。如果你后面配了域名，这里一定要改成域名，否则分享出去的链接还是 IP 加端口，体验很差。

4.2 数据库连接与初始化脚本执行

应用容器起来之后，第一次访问会触发数据库初始化。但有些方案需要手动执行迁移脚本。进应用容器看看：

docker exec -it cloudsheet-app sh

如果里面有migrate或者init-db之类的命令，就执行一下。执行前确认数据库连接参数没问题，否则会报连接超时。我遇到过一种情况：数据库容器起来了，但应用容器启动太快，连数据库时对方还没准备好，导致初始化失败。解决办法是给应用容器加个重启策略，或者手动重启一次。

docker restart cloudsheet-app

初始化完成后，用docker logs看日志，确认没有报错：

docker logs -f cloudsheet-app

日志里如果出现Database connected、Migration completed这类字样，基本就稳了。如果一直报连接拒绝，检查数据库容器的端口映射和防火墙规则。注意，容器之间的通信不走宿主机的 firewalld，但走宿主机地址访问时，如果 firewalld 拦了 5432，也会连不上。我一般把数据库端口只绑定到127.0.0.1，然后应用容器通过宿主机地址访问，这样既安全又不会受防火墙影响。

4.3 应用端口与访问验证

应用跑在 8080 端口，先在服务器本机验证：

curl -I http://127.0.0.1:8080

如果返回 200 或者 302，说明服务起来了。然后用浏览器访问http://服务器IP:8080，应该能看到登录页或者初始化向导。第一次访问通常会让你创建管理员账号，这个账号密码一定要记牢，后面改起来麻烦。

如果访问不了，按这个顺序排查：先看容器是否在运行docker ps，再看端口是否监听ss -tlnp | grep 8080，然后看防火墙是否放行，最后看 SELinux 有没有拦截。这四步走完，九成的问题都能定位。

提示：有些云表格方案默认只监听 127.0.0.1，容器里如果也是这个配置，那从外部访问就会失败。检查应用配置文件里的bind或host参数，确保是0.0.0.0。

到这一步，云表格服务已经能通过 IP 加端口访问了。但这只是能用，离好用还差一步：反向代理和域名。接下来处理这块。

5. 反向代理与访问入口优化

5.1 OpenResty 反向代理配置详解

用 OpenResty 做反向代理，核心就是一段server配置。我把它放在/usr/local/openresty/nginx/conf/conf.d/cloudsheet.conf：

server { listen 80; server_name sheet.example.com; client_max_body_size 100m; location / { proxy_pass http://127.0.0.1:8080; 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; proxy_read_timeout 300s; proxy_send_timeout 300s; } location /uploads/ { alias /data/cloudsheet/uploads/; expires 7d; } }

几个关键点解释一下。client_max_body_size默认是 1m，表格里如果带图片或者附件，很容易超，我设成 100m。proxy_read_timeout和proxy_send_timeout默认 60s，大表格导出或者协同操作时可能超时，设成 300s 更稳妥。X-Forwarded-*这几个头必须带，否则应用拿不到真实客户端 IP，日志里全是 127.0.0.1，排查问题很痛苦。

/uploads/这个 location 是可选的，如果应用本身能处理静态文件，可以不加。但让 OpenResty 直接处理静态文件，性能会好很多，尤其是多人同时预览表格附件的时候。

配置写完，先测试语法：

sudo openresty -t

没问题再 reload：

sudo systemctl reload openresty

5.2 域名解析与 HTTPS 配置

域名这块，内网用的话可以在内网 DNS 里加一条 A 记录，指向服务器 IP。外网用的话，正常做解析就行。HTTPS 我强烈建议配上，哪怕是内网。原因有两个：一是浏览器对非 HTTPS 站点越来越不友好，二是表格数据在传输过程中加密，心里踏实。

证书可以用 Let's Encrypt 免费申请，也可以用公司内部 CA 签。OpenResty 配 HTTPS 的配置大概这样：

server { listen 443 ssl http2; server_name sheet.example.com; ssl_certificate /etc/openresty/certs/sheet.crt; ssl_certificate_key /etc/openresty/certs/sheet.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; location / { proxy_pass http://127.0.0.1:8080; 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; } }

配完记得把 80 端口的访问重定向到 443：

server { listen 80; server_name sheet.example.com; return 301 https://$host$request_uri; }

这样用户不管输 http 还是 https，最终都走加密通道。证书续期如果用 Let's Encrypt，可以配个 cron 任务自动续，省得三个月后忘了导致站点打不开。

5.3 访问入口的权限控制思路

云表格服务虽然是自己人用，但入口也不能完全裸奔。我的做法是在 OpenResty 层面加一层基础认证，作为第一道门槛。配置如下：

location / { auth_basic "Restricted"; auth_basic_user_file /etc/openresty/htpasswd; proxy_pass http://127.0.0.1:8080; ... }

htpasswd文件用htpasswd命令生成：

sudo htpasswd -c /etc/openresty/htpasswd admin

这样访问时会先弹一个用户名密码框，过了这关才到应用的登录页。对于内网服务来说，这层防护足够挡住大部分扫描和误访问。当然，如果你觉得多一层登录太麻烦，也可以只在特定路径上加，比如管理后台。

注意：基础认证的密码是明文传输的（在 HTTPS 下是加密的），所以一定要配合 HTTPS 使用。纯 HTTP 下加基础认证，密码等于裸奔。

到这一步，用户可以通过https://sheet.example.com访问云表格服务了，有域名、有证书、有基础防护。接下来处理一些运维层面的细节。

6. 权限、存储与日常运维

6.1 文件权限与目录规划

OpenEuler 下跑容器，文件权限是个绕不开的话题。容器里的进程通常以非 root 用户运行，但挂载出来的目录如果属主不对，就会报写入失败。我的做法是先在宿主机上把目录建好，属主设成容器内运行的用户 UID。

sudo mkdir -p /data/cloudsheet/uploads sudo chown -R 1000:1000 /data/cloudsheet/uploads sudo chmod -R 755 /data/cloudsheet/uploads

这里的 1000 是容器内用户的 UID，具体是多少要看镜像的 Dockerfile。可以用docker exec cloudsheet-app id查看。如果 UID 对不上，容器写入时就会报 Permission denied。这个坑我踩过好几次，后来养成习惯，挂载目录之前先确认 UID。

数据库目录/data/pgdata也一样，属主必须是 PostgreSQL 容器内的用户，通常是 999。设错了数据库直接起不来，日志里会明确说权限问题。

6.2 数据备份策略与实操

自建服务最怕的就是数据丢。云表格里存的是团队的工作成果，丢了没法交代。我的备份策略分两层：数据库每天全量备份，上传文件每周增量备份。

数据库备份用pg_dump：

docker exec cloudsheet-db pg_dump -U sheetuser cloudsheet > /data/backup/cloudsheet_$(date +%Y%m%d).sql

写成 cron 任务，每天凌晨跑一次：

0 2 * * * docker exec cloudsheet-db pg_dump -U sheetuser cloudsheet > /data/backup/cloudsheet_$(date +\%Y\%m\%d).sql

注意 cron 里的%要转义，否则会被当成换行。备份文件保留最近 30 天，用find清理旧的：

find /data/backup -name "cloudsheet_*.sql" -mtime +30 -delete

上传文件目录用tar打包备份，每周一次。备份文件最好再同步到另一台机器或者对象存储，单机备份等于没备份，磁盘一坏全完。

6.3 日志查看与资源监控

日常运维离不开看日志。应用日志、OpenResty 日志、数据库日志，三个地方都要关注。应用日志用docker logs看，OpenResty 日志在/usr/local/openresty/nginx/logs/下，数据库日志在容器里。

资源监控我用的比较简单，htop看 CPU 和内存，df -h看磁盘，docker stats看容器资源占用。如果发现某个容器内存一直涨，可能是内存泄漏，需要重启或者升级版本。

docker stats --no-stream

这个命令能一次性列出所有容器的资源占用，适合快速巡检。如果要做长期监控，可以上 Prometheus 加 Grafana，但对小团队来说有点重，我一般先用脚本定期采集，存到文件里，出问题时翻记录。

7. 常见问题排查与避坑经验

7.1 服务启动失败排查速查表

这张表是我自己遇到问题后整理的，基本覆盖了八成以上的启动和访问故障。遇到问题先查表，能省不少时间。

7.2 数据库连接与字符集问题

数据库这块最常见的两个问题：连不上和乱码。连不上前面说了，重点说乱码。PostgreSQL 默认字符集可能是 SQL_ASCII，存中文会出问题。建库的时候要指定 UTF8：

CREATE DATABASE cloudsheet WITH ENCODING 'UTF8' LC_COLLATE='zh_CN.UTF-8' LC_CTYPE='zh_CN.UTF-8' OWNER sheetuser;

如果库已经建好了，改字符集比较麻烦，建议删了重建。另外应用连接数据库时，连接串里最好也带上字符集参数，双保险。

时区问题也常见。表格里填了“2024-01-01 10:00”，存进去变成“2024-01-01 02:00”，就是时区没对齐。解决办法是在数据库容器启动时设TZ=Asia/Shanghai，应用容器也设同样的时区，两边一致就不会差。

7.3 反向代理超时与大文件上传

反向代理超时和上传限制是云表格服务的高频问题。用户传一个 50M 的表格，转半天最后报错，体验极差。除了前面说的client_max_body_size和proxy_read_timeout，还有一个参数容易忽略：proxy_request_buffering。默认是 on，意思是 OpenResty 先把整个请求体收完再转发给后端。大文件上传时，这会占用大量磁盘和内存。设成 off 可以让请求体边收边转，减轻代理压力。

proxy_request_buffering off;

但设成 off 之后，后端要能处理流式请求，否则可能出问题。我实测下来，大部分云表格应用都能处理，设了之后大文件上传明显顺畅。

7.4 容器时间与宿主机不同步

容器时间不同步这个问题很隐蔽。表现是日志时间对不上，或者表格里的时间戳偏差。原因是容器默认用 UTC，宿主机用 CST。解决办法很简单，启动容器时挂载宿主机的时区文件：

-v /etc/localtime:/etc/localtime:ro

或者设环境变量TZ=Asia/Shanghai。两种方式都行，我一般两个都做，确保万无一失。这个坑不解决，后面排查问题时会被日志时间误导，浪费大量精力。

8. 性能调优与扩展思路

8.1 数据库连接池与缓存配置

云表格服务在多人同时编辑时，数据库连接数会飙升。默认的连接池可能只有 10 个，不够用。应用层面一般有连接池配置，比如DB_POOL_SIZE之类的环境变量，根据团队人数调整。几十人的团队，设成 20 到 30 比较合适。

数据库本身也要调。PostgreSQL 的max_connections默认 100，如果应用连接池设大了，可能把数据库连接占满。可以在数据库容器启动时加参数：

docker run -d ... postgres:15 -c max_connections=200

另外，shared_buffers和work_mem也可以根据服务器内存调整。内存 8G 的机器，shared_buffers设 2G，work_mem设 16M，基本够用。调这些参数前最好查一下官方文档，别拍脑袋设。

8.2 静态资源分离与 CDN 思路

如果团队分布在不同地区，访问速度可能是个问题。静态资源比如 JS、CSS、图片，可以分离出来放到对象存储或者 CDN 上。OpenResty 配置里把/static/路径指向 CDN 地址，应用只处理动态请求。这样能显著降低服务器压力，提升加载速度。

不过对小团队来说，这一步不是必须的。内网访问的话，静态资源走本机反而更快。等团队规模上来了，或者有外网访问需求，再考虑分离。

8.3 多实例部署与负载均衡

单实例跑久了，总会遇到重启更新的需求。这时候服务会中断，用户体验不好。解决办法是跑两个实例，OpenResty 做负载均衡：

upstream cloudsheet { server 127.0.0.1:8080; server 127.0.0.1:8081; } location / { proxy_pass http://cloudsheet; ... }

两个实例共享同一个数据库和上传目录，更新时逐个重启，用户几乎无感知。但要注意，多实例部署对应用的会话管理有要求，如果应用把 session 存在本地内存里，多实例会出问题。需要确认应用支持共享 session，或者用 sticky session。这块我还在摸索，目前单实例够用，等有需求再折腾。

9. 我个人的实操体会

这套云表格服务从第一次跑通到现在稳定运行，前后折腾了大概两周。最大的感受是，OpenEuler 作为底座确实省心，软件源全，社区活跃，遇到问题搜一下基本都有答案。容器化部署让升级和迁移变得简单，但也引入了权限、网络、时区这些新的坑，每一个都得踩过才知道。

如果让我给后来者一句建议，那就是：先把单机跑通，再考虑优化。我一开始就想上多实例、上监控、上自动化备份，结果基础环境没弄利索，反而浪费了更多时间。后来退回来，老老实实把系统、网络、数据库、应用一层层跑通，再逐步加东西，反而快了很多。

还有一点，备份一定要做，而且一定要验证恢复。我见过太多人备份文件存了一堆，真出事的时候发现恢复不了。定期拿备份文件在测试环境恢复一次，确认流程走得通，这比备份本身更重要。

最后分享一个小技巧：OpenEuler 的man命令很好用，遇到不熟悉的命令，man一下比搜网页快。比如man nmcli、man firewall-cmd，官方文档永远是最准的。热词里提到的openeuler man命令，确实值得花时间熟悉。