一、为什么选择非Docker部署？

Docker容器化部署因其轻量级、快速启动等优势成为主流，但在企业私有化场景中，非Docker部署仍具有不可替代的价值：

1. 系统资源深度控制
   在生产环境中，Docker容器共享宿主机内核可能导致资源竞争。非Docker部署允许直接管理系统资源（如CPU亲和性、内存NUMA配置），尤其适合对实时性要求高的场景（如文档协作中的低延迟编辑）。例如，某金融企业通过直接绑定OnlyOffice进程到特定CPU核心，将响应时间缩短30%。

2. 安全合规需求
   部分行业（如政府、军工）要求应用进程与宿主机完全隔离，但又不允许使用容器技术。非Docker部署可通过chroot、SELinux或AppArmor实现进程级隔离，同时满足等保2.0三级要求。例如，某政务系统通过SELinux策略限制OnlyOffice进程的文件访问范围，有效防止横向渗透。

3. 遗留系统兼容性
   老旧服务器（如CentOS 6、RHEL 7早期版本）可能缺乏Docker支持，或存在内核版本不兼容问题。非Docker部署可直接在宿主机运行，避免容器与宿主机的兼容性冲突。

二、非Docker部署的核心步骤

1. 系统环境准备

• 基础依赖安装

  # CentOS 7示例
  yum install -y epel-release
  yum install -y redis mono-complete postgresql-server supervisor nginx

  关键点：

  • Redis需配置持久化（AOF+RDB双模式）
  • PostgreSQL需调整shared_buffers（建议为内存的25%）
  • Mono版本需≥5.18（早期版本存在文档渲染漏洞）

• 防火墙配置

  firewall-cmd --permanent --add-port={80/tcp,443/tcp,9865/tcp}
  firewall-cmd --reload

  需放行的端口：

  • 80/443：HTTP/HTTPS服务
  • 9865：文档服务WebSocket连接

2. OnlyOffice安装与配置

• 手动编译安装（推荐生产环境）

  git clone https://github.com/ONLYOFFICE/DocumentServer.git
  cd DocumentServer
  ./configure --without-rabbitmq --without-mysql
  make && make install

  配置优化：

  • 修改/etc/onlyoffice/documentserver/local.json中的storage.path指向独立磁盘
  • 调整services.coauthoring.maxTasksPerNode（建议值=CPU核心数×2）

• 进程管理配置
  使用Supervisor管理核心进程：

  [program:onlyoffice-docs]
  command=/usr/bin/node /usr/share/onlyoffice/documentserver/server/DocService/docservice.js
  autostart=true
  autorestart=true
  user=onlyoffice
  environment=HOME="/var/lib/onlyoffice"

3. 数据库优化

• PostgreSQL参数调优
  在postgresql.conf中设置：

  max_connections = 200
  work_mem = 16MB
  maintenance_work_mem = 512MB
  checkpoint_completion_target = 0.9

  关键指标监控：

  • pg_stat_activity中的waiting状态查询
  • pg_stat_bgwriter中的checkpoints_timed

• 连接池配置
  使用PgBouncer减轻数据库压力：

  [databases]
  onlyoffice = host=localhost dbname=onlyoffice user=onlyoffice
  [pgbouncer]
  pool_mode = transaction
  max_client_conn = 100
  default_pool_size = 20

三、性能优化实战

1. 内存管理策略

• 共享内存配置
  在/etc/sysctl.conf中添加：

  kernel.shmmax = 17179869184  # 16GB
  kernel.shmall = 4194304

  验证命令：

  ipcs -m | grep onlyoffice

2. 网络优化

• TCP参数调优

  net.core.somaxconn = 4096
  net.ipv4.tcp_max_syn_backlog = 2048
  net.ipv4.tcp_tw_reuse = 1

  使用ss -s监控连接状态，确保TIME-WAIT连接数<1000。

3. 日志集中管理

• ELK栈集成方案

  # Filebeat配置示例
  filebeat.inputs:
  - type: log
    paths:
      - /var/log/onlyoffice/*.log
    fields_under_root: true
    fields:
      app: onlyoffice
  output.logstash:
    hosts: ["logstash-server:5044"]

  关键日志字段：
  • docservice.request.time：文档操作耗时
  • coauthoring.socket.error：WebSocket连接异常

四、运维监控体系

1. 监控指标设计

指标类别	关键指标	告警阈值
可用性	服务进程存活状态	连续3次检查失败
性能	文档转换平均耗时	>500ms
资源	内存使用率	>85%
业务	同时在线用户数	>设计容量的90%

2. 自动化运维脚本

• 健康检查脚本

  #!/bin/bash
  CHECK_URL="http://localhost/healthcheck"
  RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" $CHECK_URL)
  if [ "$RESPONSE" -ne 200 ]; then
    systemctl restart onlyoffice-documentserver
    logger -t ONLYOFFICE "Service restarted due to health check failure"
  fi

五、常见问题解决方案

1. 文档转换失败

   • 检查/var/log/onlyoffice/converter.log中的LibreOffice错误
   • 确保/usr/bin/soffice可执行权限正确
   • 验证/etc/onlyoffice/documentserver/local.json中的converter.url配置

2. WebSocket连接中断

   • 调整Nginx配置：

     proxy_http_version 1.1;
     proxy_set_header Upgrade $http_upgrade;
     proxy_set_header Connection "upgrade";

   • 检查服务器时间同步（ntpq -p）

3. 性能瓶颈定位

   • 使用perf top分析Mono进程热点函数
   • 通过strace -p <PID>跟踪系统调用

六、升级与扩展建议

1. 版本升级路径

   • 小版本升级（如7.1→7.2）：直接替换二进制文件
   • 大版本升级（如6.4→7.0）：需执行数据库迁移脚本

     cd /usr/share/onlyoffice/documentserver/db/
     psql -U onlyoffice -d onlyoffice -f schema/postgresql/upgrade/7.0/upgrade.sql

2. 横向扩展方案

   • 负载均衡配置：

     upstream onlyoffice_cluster {
       server 192.168.1.10:9865;
       server 192.168.1.11:9865;
       keepalive 32;
     }

   • 共享存储建议：使用NFSv4或CephFS挂载文档存储目录

通过以上方案，企业可在非Docker环境中实现OnlyOffice的高效、稳定运行。实际部署时，建议先在测试环境验证配置参数，再逐步推广到生产环境。对于超大规模部署（>1000并发用户），可考虑结合Kubernetes的Operator模式实现自动化运维，但核心服务仍建议保持非容器化部署以获得最佳性能控制。