1. 从SaaS订阅到自建机房我为什么最终选择了Deskcomm三年前我们团队用着一款市面上口碑不错的免费CRM刚开始确实省心注册即用销售漏斗、客户标签、跟进提醒一应俱全。但用着用着问题就来了客户数据存在别人的服务器上导出要申请权限字段想改要等版本更新API调用次数还有硬性上限。最要命的是有一次服务商调整了免费版策略我们积攒了两年的客户跟进记录差点拿不出来。那次之后我就下定决心必须把客户管理系统搬回自己能掌控的环境里。Deskcomm是我在对比了七八个开源方案之后选定的。它本质上是一套基于Laravel框架开发的客户关系管理系统支持工单、客户档案、销售管道、知识库等模块代码结构清晰二次开发的门槛不算高。更重要的是它提供了完整的Docker Compose部署方案这意味着我不需要在一台新服务器上从零配置PHP运行环境、数据库、缓存服务一条命令就能把整套系统拉起来。这篇文章面向的是那些和我一样手头有一台闲置服务器或者愿意花点钱买台云主机想把客户数据攥在自己手里的朋友。不管你是技术出身还是半路出家的运营负责人只要你能照着命令行敲几行指令就能跟着走完整个流程。我会把踩过的坑、绕过的弯、以及那些文档里不会写的细节都摊开来讲让你少走至少两天的弯路。2. 部署前的环境决策为什么是Docker Compose而不是裸装2.1 裸装Laravel应用的隐性成本很多人第一反应是直接在服务器上装Nginx、PHP、MySQL、Redis然后把Deskcomm的代码clone下来配一配。这条路我走过在一台Ubuntu 22.04的机器上折腾了整整一个下午。PHP扩展版本对不上、Composer依赖冲突、文件权限导致Laravel的storage目录写不进去、队列进程莫名其妙挂掉——每一个问题单独看都不难但叠在一起就是无底洞。更麻烦的是迁移。当你把系统从测试机搬到生产机或者换一台配置更高的服务器时裸装环境下你得重新走一遍所有配置流程还得祈祷新机器的系统版本和旧机器完全一致。这种重复劳动对于没有专职运维的团队来说成本高得离谱。2.2 Docker Compose带来的确定性Docker Compose的核心价值在于环境即代码。你把Nginx、PHP-FPM、MySQL、Redis这些服务的配置全部写在一个YAML文件里换任何一台装了Docker的机器docker compose up -d一执行环境就完全一致地复现出来了。Deskcomm官方提供的compose文件已经把服务依赖关系、网络配置、数据卷挂载都定义好了我需要做的只是调整几个环境变量。这里有个关键决策点数据库和Redis要不要也放在Docker里。我的建议是对于中小规模团队日活几十到几百人全部容器化是最省心的方案。数据卷挂载到宿主机目录备份的时候直接打包目录就行。如果你的团队规模更大或者已经有独立的数据库集群那可以把MySQL和Redis外置compose文件里只保留应用层服务。2.3 服务器配置的最低门槛与推荐配置我实测过的最低配置是一台2核4G的云主机跑Deskcomm的全套容器日常十几个销售同时在线使用响应速度可以接受。但如果你要开队列worker处理邮件通知、工单自动分配这些异步任务建议至少给到4核8G。磁盘方面系统盘40G起步数据盘根据你的客户数据量来定一般100G能用很久。操作系统我推荐Ubuntu 22.04 LTS或者Debian 12这两个发行版的Docker安装文档最完善社区支持也最好。如果你用的是国产化环境比如银河麒麟高级服务器操作系统V10也能装Docker和Docker Compose但需要注意内核版本和Docker版本的兼容性这个后面会专门讲。3. 从零开始Ubuntu环境下Docker与Compose的安装实操3.1 卸载旧版本与清理残留在装新东西之前先把可能存在的旧版本清干净。很多云主机的镜像里预装了docker.io或者podman这些和官方Docker Engine冲突。执行下面这几条命令sudo apt remove docker docker-engine docker.io containerd runc sudo apt autoremove -y注意docker.io是Ubuntu仓库里的版本通常比官方版本旧好几个大版本Compose插件的兼容性也差。如果你之前用snap装过Docker也要一并卸掉sudo snap remove docker。3.2 通过官方仓库安装Docker Engine我习惯用Docker官方提供的apt仓库来装这样后续升级方便。步骤如下sudo apt update sudo apt install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release echo $VERSION_CODENAME) 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-buildx-plugin docker-compose-plugin装完之后验证一下docker --version和docker compose version。注意Compose V2是作为Docker插件存在的命令是docker compose而不是docker-compose中间是空格不是横杠。这个细节很多人搞混网上很多老教程还在用docker-compose你照着敲会报command not found。3.3 把当前用户加入docker组默认情况下只有root能执行docker命令每次都要sudo很烦。执行sudo usermod -aG docker $USER newgrp docker然后退出SSH重新登录再执行docker ps就不需要sudo了。这里有个坑如果你是在脚本里用非root用户跑docker命令一定要确保这个用户已经在docker组里否则会报permission denied。3.4 配置国内镜像加速器从Docker Hub拉镜像的速度直接决定了你的部署体验。编辑/etc/docker/daemon.json{ registry-mirrors: [ https://mirror.ccs.tencentyun.com, https://docker.mirrors.ustc.edu.cn ], log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }然后sudo systemctl daemon-reload sudo systemctl restart docker。日志限制那两行很重要不然容器跑久了日志文件能把磁盘撑爆这是我用血泪换来的教训。4. Deskcomm的Compose编排文件拆解与定制4.1 官方compose文件的结构分析Deskcomm的部署包通常包含一个docker-compose.yml和一个.env文件。compose文件里一般定义了这么几个服务appPHP-FPM运行Laravel、webNginx反向代理、dbMySQL 8、redis缓存和队列、worker队列处理进程、scheduler定时任务。每个服务的镜像要么是基于官方镜像加Dockerfile构建要么直接使用预构建好的镜像。我建议你把compose文件完整读一遍重点看三个地方数据卷挂载路径、环境变量引用、端口映射。数据卷决定了你的数据存在宿主机哪个目录环境变量决定了数据库密码和APP_KEY这些敏感信息端口映射决定了外部怎么访问。4.2 关键环境变量的设置逻辑.env文件里几个必须改的变量变量名作用建议值APP_KEYLaravel加密密钥用php artisan key:generate生成APP_URL系统访问地址你的域名或IPDB_PASSWORD数据库密码强密码别用默认的DB_ROOT_PASSWORD数据库root密码和上面不同REDIS_PASSWORDRedis密码建议设置MAIL_*邮件发送配置按你的SMTP服务填APP_KEY特别重要它用于加密session和敏感数据。如果你在部署时没有生成系统会报错。生成方法是在app容器里执行php artisan key:generate或者本地用PHP跑一下把结果填进去。4.3 数据持久化的目录规划我习惯在宿主机上建一个统一的数据目录比如/data/deskcomm/下面分mysql、redis、storage、logs几个子目录。compose文件里这样挂载volumes: - /data/deskcomm/mysql:/var/lib/mysql - /data/deskcomm/redis:/data - /data/deskcomm/storage:/var/www/html/storage这样做的好处是备份的时候直接打包/data/deskcomm/整个目录迁移的时候拷贝过去就行。注意MySQL的数据目录权限容器里的mysql用户uid通常是999宿主机目录要chown 999:999否则容器启动会报权限错误。4.4 端口与反向代理的取舍最简单的做法是把Nginx容器的80端口直接映射到宿主机的80端口。但如果宿主机上已经有其他Web服务占用了80你就得换个端口比如8080:80然后通过宿主机的Nginx做反向代理。我推荐后者因为这样可以在宿主机层面统一管理SSL证书Deskcomm容器只管HTTP就行。宿主机的Nginx配置大概长这样server { listen 443 ssl; server_name crm.yourdomain.com; ssl_certificate /etc/letsencrypt/live/crm.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/crm.yourdomain.com/privkey.pem; 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; } }5. 首次启动与初始化那些文档没写的细节5.1 拉镜像与启动顺序第一次执行docker compose up -d的时候Docker会从仓库拉取所有镜像。如果镜像比较大MySQL和PHP镜像加起来可能超过1G耐心等一会儿。启动顺序上compose会按照depends_on的定义来但depends_on只保证容器启动的顺序不保证服务真正就绪。也就是说db容器起来了但MySQL可能还在初始化这时候app容器去连数据库就会失败。解决办法是在app服务的启动命令里加一个等待脚本或者手动分步启动先docker compose up -d db redis等半分钟确认数据库就绪了再docker compose up -d启动其余服务。5.2 数据库迁移与种子数据Deskcomm首次运行需要执行数据库迁移来建表。进入app容器docker compose exec app bash php artisan migrate --force如果还需要初始化一些基础数据比如默认管理员账号、系统配置再执行php artisan db:seed。注意--force参数在生产环境下是必须的否则Laravel会交互式询问你是否确认在脚本里会卡住。5.3 文件权限与storage目录Laravel的storage和bootstrap/cache目录需要Web服务器用户可写。容器里通常是www-data用户。如果挂载了宿主机的storage目录要确保权限正确sudo chown -R 33:33 /data/deskcomm/storage sudo chmod -R 775 /data/deskcomm/storage33是Debian/Ubuntu系里www-data的uid。如果你用的是Alpine基础镜像uid可能不同用docker compose exec app id www-data查一下。5.4 队列worker与定时任务的守护Deskcomm的邮件通知、工单自动分配这些功能依赖队列。compose文件里通常有一个worker服务跑php artisan queue:work还有一个scheduler服务跑php artisan schedule:work。这两个进程如果挂了异步任务就会堆积。我建议给这两个服务配置restart: unless-stopped这样容器异常退出后Docker会自动拉起来。另外queue:work进程长时间运行可能会因为内存泄漏变慢可以加--max-jobs1000参数让它处理完一千个任务后自动重启。6. 安全加固从Laravel漏洞到容器隔离6.1 及时关注Laravel框架的安全公告Laravel作为一个流行的PHP框架历史上出现过不少安全漏洞比如某些版本中的反序列化问题、session处理缺陷等。CVE-2024-29291就是一个典型的例子它影响特定版本的Laravel攻击者可能通过构造恶意请求读取敏感文件。虽然Deskcomm官方会跟进修复但你自己部署的系统更新节奏掌握在你手里。我的做法是订阅Laravel的安全公告邮件列表每次有新的CVE发布第一时间检查自己的Laravel版本是否受影响。查看版本的方法是在app容器里执行php artisan --version。如果受影响就更新composer依赖composer update laravel/framework然后重启容器。6.2 Session安全配置Laravel的session默认存在文件里对于多容器部署建议改成Redis驱动。在.env里设置SESSION_DRIVERredis这样多个app容器实例可以共享session。同时把SESSION_SECURE_COOKIE设为true如果你用了HTTPSSESSION_HTTP_ONLY设为true防止XSS攻击窃取cookie。6.3 容器层面的最小权限原则不要用root用户跑应用容器。Deskcomm的Dockerfile里一般会创建一个非root用户确保compose文件里没有user: root这样的配置。另外容器之间通过自定义网络通信不要把数据库端口映射到宿主机公网。compose文件里db服务不要写ports只写expose这样只有同一个网络里的容器能访问它。6.4 定期备份的自动化脚本我写了一个简单的备份脚本每天凌晨跑一次#!/bin/bash BACKUP_DIR/data/backups/deskcomm DATE$(date %Y%m%d) mkdir -p $BACKUP_DIR docker compose exec -T db mysqldump -u root -p$DB_ROOT_PASSWORD deskcomm | gzip $BACKUP_DIR/db_$DATE.sql.gz tar czf $BACKUP_DIR/storage_$DATE.tar.gz /data/deskcomm/storage find $BACKUP_DIR -mtime 30 -delete这个脚本把数据库和storage目录分别打包保留最近30天。注意mysqldump的密码通过环境变量传入不要硬编码在脚本里。7. 国产化环境适配银河麒麟V10上的部署要点7.1 系统差异与Docker安装银河麒麟高级服务器操作系统V10基于Linux内核但包管理器和软件源和Ubuntu不同。它用的是yum或dnf。安装Docker不能直接用Ubuntu的apt仓库需要用麒麟自己的软件源或者Docker的CentOS仓库。具体步骤sudo dnf install -y dnf-plugins-core sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin sudo systemctl enable --now docker如果麒麟的软件源里没有dnf-plugins-core可以尝试用yum替代。安装完成后同样要配置镜像加速器和日志限制。7.2 内核参数与容器兼容性麒麟V10的内核版本通常是4.19或5.10对Docker的支持没问题。但需要注意cgroup驱动麒麟默认可能用的是cgroup v1而较新的Docker版本默认用cgroup v2。如果启动容器时报cgroup相关错误可以在/etc/docker/daemon.json里加exec-opts: [native.cgroupdriversystemd]然后重启Docker。7.3 国产CPU架构的镜像适配如果你的麒麟系统跑在ARM架构的国产CPU上比如鲲鹏、飞腾拉取Docker镜像时要确认镜像有ARM64版本。Deskcomm官方镜像如果只有amd64你需要自己构建ARM版本或者找社区维护的多架构镜像。构建方法是在Dockerfile里指定基础镜像的ARM版本比如php:8.2-fpm默认会拉取对应架构的镜像但MySQL的官方镜像对ARM的支持要确认一下版本。8. 日常运维监控、升级与故障排查8.1 容器状态与日志查看日常巡检我主要看几个东西docker compose ps看容器是否都在运行docker stats看资源占用docker compose logs --tail100 app看应用日志有没有报错。如果某个容器频繁重启用docker compose logs service看具体错误。8.2 版本升级的正确姿势Deskcomm发布新版本后升级流程是先备份数据库和storage然后git pull拉取新代码如果是源码部署或者修改compose文件里的镜像tag然后docker compose pull拉新镜像docker compose up -d重建容器最后进app容器执行php artisan migrate。注意升级前一定要看官方的升级说明有些版本可能有破坏性变更。8.3 常见故障速查表现象可能原因排查方向502 Bad Gatewayapp容器没起来或PHP-FPM挂了docker compose logs app数据库连接失败db容器未就绪或密码错误检查.env和db日志页面样式丢失storage权限或APP_URL配置错误检查APP_URL和文件权限队列任务不执行worker容器挂了docker compose ps看worker状态磁盘占满日志或备份文件堆积du -sh /var/lib/docker8.4 性能调优的几个抓手如果系统用起来感觉慢可以从这几个方面入手给PHP-FPM调大pm.max_children给MySQL调大innodb_buffer_pool_size给Redis设置合理的内存上限和淘汰策略开启Laravel的配置缓存和路由缓存php artisan config:cache php artisan route:cache。这些调整需要根据服务器的实际内存来定别盲目照搬网上的参数。9. 我踩过的三个坑和对应的解法第一个坑是MySQL容器启动后立即被app连接导致初始化失败。现象是app容器日志里一堆connection refused但db容器明明在运行。原因是MySQL首次启动时要初始化数据目录这期间虽然进程在跑但还没准备好接受连接。解法是在app的启动脚本里加一个循环等待用mysqladmin ping或者nc -z db 3306来判断数据库是否真正就绪。第二个坑是storage目录挂载后Laravel写不进去。我一开始用root创建了宿主机目录容器里的www-data用户没有写权限。后来改成chown 33:33并设置775权限才解决。这个问题的隐蔽之处在于Laravel报的错可能是无法写入日志文件而不是直接的权限错误容易误导排查方向。第三个坑是Compose V1和V2的命令不兼容。我早期写的脚本里用的是docker-compose后来服务器升级后只装了Compose V2插件脚本全部报错。批量替换成docker compose之后才恢复正常。如果你有自动化脚本记得检查这个细节。10. 关于永久在线这件事的现实理解标题里说永久在线但做过运维的人都知道没有绝对的永久。硬件会老化网络会抖动软件会有漏洞。我们能做的是通过合理的架构和运维手段把不可用的时间压缩到最小。Deskcomm的容器化部署加上restart: unless-stopped策略能在进程崩溃时自动恢复定期备份能在数据损坏时快速回滚监控告警能在问题扩大前介入。我自己的这套系统已经稳定跑了快两年中间经历过服务器迁移、版本升级、一次磁盘故障客户数据一条没丢。靠的不是什么黑科技就是把备份做好、把日志看好、把更新跟上。如果你也在考虑把客户管理系统私有化Deskcomm加Docker Compose这条路是走得通的成本可控维护量也不大。希望这篇东西能帮你少熬几个夜。
Docker Compose部署Deskcomm：自建CRM系统实战指南
1. 从SaaS订阅到自建机房我为什么最终选择了Deskcomm三年前我们团队用着一款市面上口碑不错的免费CRM刚开始确实省心注册即用销售漏斗、客户标签、跟进提醒一应俱全。但用着用着问题就来了客户数据存在别人的服务器上导出要申请权限字段想改要等版本更新API调用次数还有硬性上限。最要命的是有一次服务商调整了免费版策略我们积攒了两年的客户跟进记录差点拿不出来。那次之后我就下定决心必须把客户管理系统搬回自己能掌控的环境里。Deskcomm是我在对比了七八个开源方案之后选定的。它本质上是一套基于Laravel框架开发的客户关系管理系统支持工单、客户档案、销售管道、知识库等模块代码结构清晰二次开发的门槛不算高。更重要的是它提供了完整的Docker Compose部署方案这意味着我不需要在一台新服务器上从零配置PHP运行环境、数据库、缓存服务一条命令就能把整套系统拉起来。这篇文章面向的是那些和我一样手头有一台闲置服务器或者愿意花点钱买台云主机想把客户数据攥在自己手里的朋友。不管你是技术出身还是半路出家的运营负责人只要你能照着命令行敲几行指令就能跟着走完整个流程。我会把踩过的坑、绕过的弯、以及那些文档里不会写的细节都摊开来讲让你少走至少两天的弯路。2. 部署前的环境决策为什么是Docker Compose而不是裸装2.1 裸装Laravel应用的隐性成本很多人第一反应是直接在服务器上装Nginx、PHP、MySQL、Redis然后把Deskcomm的代码clone下来配一配。这条路我走过在一台Ubuntu 22.04的机器上折腾了整整一个下午。PHP扩展版本对不上、Composer依赖冲突、文件权限导致Laravel的storage目录写不进去、队列进程莫名其妙挂掉——每一个问题单独看都不难但叠在一起就是无底洞。更麻烦的是迁移。当你把系统从测试机搬到生产机或者换一台配置更高的服务器时裸装环境下你得重新走一遍所有配置流程还得祈祷新机器的系统版本和旧机器完全一致。这种重复劳动对于没有专职运维的团队来说成本高得离谱。2.2 Docker Compose带来的确定性Docker Compose的核心价值在于环境即代码。你把Nginx、PHP-FPM、MySQL、Redis这些服务的配置全部写在一个YAML文件里换任何一台装了Docker的机器docker compose up -d一执行环境就完全一致地复现出来了。Deskcomm官方提供的compose文件已经把服务依赖关系、网络配置、数据卷挂载都定义好了我需要做的只是调整几个环境变量。这里有个关键决策点数据库和Redis要不要也放在Docker里。我的建议是对于中小规模团队日活几十到几百人全部容器化是最省心的方案。数据卷挂载到宿主机目录备份的时候直接打包目录就行。如果你的团队规模更大或者已经有独立的数据库集群那可以把MySQL和Redis外置compose文件里只保留应用层服务。2.3 服务器配置的最低门槛与推荐配置我实测过的最低配置是一台2核4G的云主机跑Deskcomm的全套容器日常十几个销售同时在线使用响应速度可以接受。但如果你要开队列worker处理邮件通知、工单自动分配这些异步任务建议至少给到4核8G。磁盘方面系统盘40G起步数据盘根据你的客户数据量来定一般100G能用很久。操作系统我推荐Ubuntu 22.04 LTS或者Debian 12这两个发行版的Docker安装文档最完善社区支持也最好。如果你用的是国产化环境比如银河麒麟高级服务器操作系统V10也能装Docker和Docker Compose但需要注意内核版本和Docker版本的兼容性这个后面会专门讲。3. 从零开始Ubuntu环境下Docker与Compose的安装实操3.1 卸载旧版本与清理残留在装新东西之前先把可能存在的旧版本清干净。很多云主机的镜像里预装了docker.io或者podman这些和官方Docker Engine冲突。执行下面这几条命令sudo apt remove docker docker-engine docker.io containerd runc sudo apt autoremove -y注意docker.io是Ubuntu仓库里的版本通常比官方版本旧好几个大版本Compose插件的兼容性也差。如果你之前用snap装过Docker也要一并卸掉sudo snap remove docker。3.2 通过官方仓库安装Docker Engine我习惯用Docker官方提供的apt仓库来装这样后续升级方便。步骤如下sudo apt update sudo apt install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release echo $VERSION_CODENAME) 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-buildx-plugin docker-compose-plugin装完之后验证一下docker --version和docker compose version。注意Compose V2是作为Docker插件存在的命令是docker compose而不是docker-compose中间是空格不是横杠。这个细节很多人搞混网上很多老教程还在用docker-compose你照着敲会报command not found。3.3 把当前用户加入docker组默认情况下只有root能执行docker命令每次都要sudo很烦。执行sudo usermod -aG docker $USER newgrp docker然后退出SSH重新登录再执行docker ps就不需要sudo了。这里有个坑如果你是在脚本里用非root用户跑docker命令一定要确保这个用户已经在docker组里否则会报permission denied。3.4 配置国内镜像加速器从Docker Hub拉镜像的速度直接决定了你的部署体验。编辑/etc/docker/daemon.json{ registry-mirrors: [ https://mirror.ccs.tencentyun.com, https://docker.mirrors.ustc.edu.cn ], log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }然后sudo systemctl daemon-reload sudo systemctl restart docker。日志限制那两行很重要不然容器跑久了日志文件能把磁盘撑爆这是我用血泪换来的教训。4. Deskcomm的Compose编排文件拆解与定制4.1 官方compose文件的结构分析Deskcomm的部署包通常包含一个docker-compose.yml和一个.env文件。compose文件里一般定义了这么几个服务appPHP-FPM运行Laravel、webNginx反向代理、dbMySQL 8、redis缓存和队列、worker队列处理进程、scheduler定时任务。每个服务的镜像要么是基于官方镜像加Dockerfile构建要么直接使用预构建好的镜像。我建议你把compose文件完整读一遍重点看三个地方数据卷挂载路径、环境变量引用、端口映射。数据卷决定了你的数据存在宿主机哪个目录环境变量决定了数据库密码和APP_KEY这些敏感信息端口映射决定了外部怎么访问。4.2 关键环境变量的设置逻辑.env文件里几个必须改的变量变量名作用建议值APP_KEYLaravel加密密钥用php artisan key:generate生成APP_URL系统访问地址你的域名或IPDB_PASSWORD数据库密码强密码别用默认的DB_ROOT_PASSWORD数据库root密码和上面不同REDIS_PASSWORDRedis密码建议设置MAIL_*邮件发送配置按你的SMTP服务填APP_KEY特别重要它用于加密session和敏感数据。如果你在部署时没有生成系统会报错。生成方法是在app容器里执行php artisan key:generate或者本地用PHP跑一下把结果填进去。4.3 数据持久化的目录规划我习惯在宿主机上建一个统一的数据目录比如/data/deskcomm/下面分mysql、redis、storage、logs几个子目录。compose文件里这样挂载volumes: - /data/deskcomm/mysql:/var/lib/mysql - /data/deskcomm/redis:/data - /data/deskcomm/storage:/var/www/html/storage这样做的好处是备份的时候直接打包/data/deskcomm/整个目录迁移的时候拷贝过去就行。注意MySQL的数据目录权限容器里的mysql用户uid通常是999宿主机目录要chown 999:999否则容器启动会报权限错误。4.4 端口与反向代理的取舍最简单的做法是把Nginx容器的80端口直接映射到宿主机的80端口。但如果宿主机上已经有其他Web服务占用了80你就得换个端口比如8080:80然后通过宿主机的Nginx做反向代理。我推荐后者因为这样可以在宿主机层面统一管理SSL证书Deskcomm容器只管HTTP就行。宿主机的Nginx配置大概长这样server { listen 443 ssl; server_name crm.yourdomain.com; ssl_certificate /etc/letsencrypt/live/crm.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/crm.yourdomain.com/privkey.pem; 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; } }5. 首次启动与初始化那些文档没写的细节5.1 拉镜像与启动顺序第一次执行docker compose up -d的时候Docker会从仓库拉取所有镜像。如果镜像比较大MySQL和PHP镜像加起来可能超过1G耐心等一会儿。启动顺序上compose会按照depends_on的定义来但depends_on只保证容器启动的顺序不保证服务真正就绪。也就是说db容器起来了但MySQL可能还在初始化这时候app容器去连数据库就会失败。解决办法是在app服务的启动命令里加一个等待脚本或者手动分步启动先docker compose up -d db redis等半分钟确认数据库就绪了再docker compose up -d启动其余服务。5.2 数据库迁移与种子数据Deskcomm首次运行需要执行数据库迁移来建表。进入app容器docker compose exec app bash php artisan migrate --force如果还需要初始化一些基础数据比如默认管理员账号、系统配置再执行php artisan db:seed。注意--force参数在生产环境下是必须的否则Laravel会交互式询问你是否确认在脚本里会卡住。5.3 文件权限与storage目录Laravel的storage和bootstrap/cache目录需要Web服务器用户可写。容器里通常是www-data用户。如果挂载了宿主机的storage目录要确保权限正确sudo chown -R 33:33 /data/deskcomm/storage sudo chmod -R 775 /data/deskcomm/storage33是Debian/Ubuntu系里www-data的uid。如果你用的是Alpine基础镜像uid可能不同用docker compose exec app id www-data查一下。5.4 队列worker与定时任务的守护Deskcomm的邮件通知、工单自动分配这些功能依赖队列。compose文件里通常有一个worker服务跑php artisan queue:work还有一个scheduler服务跑php artisan schedule:work。这两个进程如果挂了异步任务就会堆积。我建议给这两个服务配置restart: unless-stopped这样容器异常退出后Docker会自动拉起来。另外queue:work进程长时间运行可能会因为内存泄漏变慢可以加--max-jobs1000参数让它处理完一千个任务后自动重启。6. 安全加固从Laravel漏洞到容器隔离6.1 及时关注Laravel框架的安全公告Laravel作为一个流行的PHP框架历史上出现过不少安全漏洞比如某些版本中的反序列化问题、session处理缺陷等。CVE-2024-29291就是一个典型的例子它影响特定版本的Laravel攻击者可能通过构造恶意请求读取敏感文件。虽然Deskcomm官方会跟进修复但你自己部署的系统更新节奏掌握在你手里。我的做法是订阅Laravel的安全公告邮件列表每次有新的CVE发布第一时间检查自己的Laravel版本是否受影响。查看版本的方法是在app容器里执行php artisan --version。如果受影响就更新composer依赖composer update laravel/framework然后重启容器。6.2 Session安全配置Laravel的session默认存在文件里对于多容器部署建议改成Redis驱动。在.env里设置SESSION_DRIVERredis这样多个app容器实例可以共享session。同时把SESSION_SECURE_COOKIE设为true如果你用了HTTPSSESSION_HTTP_ONLY设为true防止XSS攻击窃取cookie。6.3 容器层面的最小权限原则不要用root用户跑应用容器。Deskcomm的Dockerfile里一般会创建一个非root用户确保compose文件里没有user: root这样的配置。另外容器之间通过自定义网络通信不要把数据库端口映射到宿主机公网。compose文件里db服务不要写ports只写expose这样只有同一个网络里的容器能访问它。6.4 定期备份的自动化脚本我写了一个简单的备份脚本每天凌晨跑一次#!/bin/bash BACKUP_DIR/data/backups/deskcomm DATE$(date %Y%m%d) mkdir -p $BACKUP_DIR docker compose exec -T db mysqldump -u root -p$DB_ROOT_PASSWORD deskcomm | gzip $BACKUP_DIR/db_$DATE.sql.gz tar czf $BACKUP_DIR/storage_$DATE.tar.gz /data/deskcomm/storage find $BACKUP_DIR -mtime 30 -delete这个脚本把数据库和storage目录分别打包保留最近30天。注意mysqldump的密码通过环境变量传入不要硬编码在脚本里。7. 国产化环境适配银河麒麟V10上的部署要点7.1 系统差异与Docker安装银河麒麟高级服务器操作系统V10基于Linux内核但包管理器和软件源和Ubuntu不同。它用的是yum或dnf。安装Docker不能直接用Ubuntu的apt仓库需要用麒麟自己的软件源或者Docker的CentOS仓库。具体步骤sudo dnf install -y dnf-plugins-core sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin sudo systemctl enable --now docker如果麒麟的软件源里没有dnf-plugins-core可以尝试用yum替代。安装完成后同样要配置镜像加速器和日志限制。7.2 内核参数与容器兼容性麒麟V10的内核版本通常是4.19或5.10对Docker的支持没问题。但需要注意cgroup驱动麒麟默认可能用的是cgroup v1而较新的Docker版本默认用cgroup v2。如果启动容器时报cgroup相关错误可以在/etc/docker/daemon.json里加exec-opts: [native.cgroupdriversystemd]然后重启Docker。7.3 国产CPU架构的镜像适配如果你的麒麟系统跑在ARM架构的国产CPU上比如鲲鹏、飞腾拉取Docker镜像时要确认镜像有ARM64版本。Deskcomm官方镜像如果只有amd64你需要自己构建ARM版本或者找社区维护的多架构镜像。构建方法是在Dockerfile里指定基础镜像的ARM版本比如php:8.2-fpm默认会拉取对应架构的镜像但MySQL的官方镜像对ARM的支持要确认一下版本。8. 日常运维监控、升级与故障排查8.1 容器状态与日志查看日常巡检我主要看几个东西docker compose ps看容器是否都在运行docker stats看资源占用docker compose logs --tail100 app看应用日志有没有报错。如果某个容器频繁重启用docker compose logs service看具体错误。8.2 版本升级的正确姿势Deskcomm发布新版本后升级流程是先备份数据库和storage然后git pull拉取新代码如果是源码部署或者修改compose文件里的镜像tag然后docker compose pull拉新镜像docker compose up -d重建容器最后进app容器执行php artisan migrate。注意升级前一定要看官方的升级说明有些版本可能有破坏性变更。8.3 常见故障速查表现象可能原因排查方向502 Bad Gatewayapp容器没起来或PHP-FPM挂了docker compose logs app数据库连接失败db容器未就绪或密码错误检查.env和db日志页面样式丢失storage权限或APP_URL配置错误检查APP_URL和文件权限队列任务不执行worker容器挂了docker compose ps看worker状态磁盘占满日志或备份文件堆积du -sh /var/lib/docker8.4 性能调优的几个抓手如果系统用起来感觉慢可以从这几个方面入手给PHP-FPM调大pm.max_children给MySQL调大innodb_buffer_pool_size给Redis设置合理的内存上限和淘汰策略开启Laravel的配置缓存和路由缓存php artisan config:cache php artisan route:cache。这些调整需要根据服务器的实际内存来定别盲目照搬网上的参数。9. 我踩过的三个坑和对应的解法第一个坑是MySQL容器启动后立即被app连接导致初始化失败。现象是app容器日志里一堆connection refused但db容器明明在运行。原因是MySQL首次启动时要初始化数据目录这期间虽然进程在跑但还没准备好接受连接。解法是在app的启动脚本里加一个循环等待用mysqladmin ping或者nc -z db 3306来判断数据库是否真正就绪。第二个坑是storage目录挂载后Laravel写不进去。我一开始用root创建了宿主机目录容器里的www-data用户没有写权限。后来改成chown 33:33并设置775权限才解决。这个问题的隐蔽之处在于Laravel报的错可能是无法写入日志文件而不是直接的权限错误容易误导排查方向。第三个坑是Compose V1和V2的命令不兼容。我早期写的脚本里用的是docker-compose后来服务器升级后只装了Compose V2插件脚本全部报错。批量替换成docker compose之后才恢复正常。如果你有自动化脚本记得检查这个细节。10. 关于永久在线这件事的现实理解标题里说永久在线但做过运维的人都知道没有绝对的永久。硬件会老化网络会抖动软件会有漏洞。我们能做的是通过合理的架构和运维手段把不可用的时间压缩到最小。Deskcomm的容器化部署加上restart: unless-stopped策略能在进程崩溃时自动恢复定期备份能在数据损坏时快速回滚监控告警能在问题扩大前介入。我自己的这套系统已经稳定跑了快两年中间经历过服务器迁移、版本升级、一次磁盘故障客户数据一条没丢。靠的不是什么黑科技就是把备份做好、把日志看好、把更新跟上。如果你也在考虑把客户管理系统私有化Deskcomm加Docker Compose这条路是走得通的成本可控维护量也不大。希望这篇东西能帮你少熬几个夜。
