Docker 容器架构优化与 Compose 切换实践总结

在容器化部署和运维过程中,许多用户最初会使用 docker run 命令快速启动服务。然而,随着服务数量增多、配置复杂化,这种方式逐渐显现出诸多局限,例如管理分散、配置难以集中备份、迁移麻烦等问题。 为了提升长期可维护性与安全性,近期完成了一次全面架构优化:将所有容器从 docker run 切换到 docker-compose 管理,以下为思路与实践总结。 🟢 原有容器情况 原系统中共运行约 28 个容器,覆盖 7 个主要业务应用(stack),例如以下示例服务: 部分服务最初通过 docker run 手动启动,虽然方便,但长期来看容易导致配置不一致、维护难度增大。 💡 切换至 Compose 管理的思路 ✅ 推荐方案 对于这些服务,最终选择了「重新整理 Compose 文件」的方式(官方推荐),核心步骤如下: 1️⃣ 为每个服务重新编写或整理对应的 docker-compose.yml 文件,清晰记录端口、卷挂载、环境变量、网络配置等所有细节。 2️⃣ 将 Compose 文件集中保存(如放入版本控制仓库或私有同步盘),方便后期维护、审计及灾备。 3️⃣ 使用 docker-compose up -d 管理服务生命周期,实现一键部署和统一启动。 ⚠️ 注意事项 🛡️ Portainer 的角色 此次优化中,Portainer …

Certbot 移除证书中多余域名的完整操作总结

在服务器维护中,常因架构或服务变更,需要删除证书中某些域名(子域名),避免不必要的安全风险与维护成本。本文总结了使用 Certbot 安全移除域名的标准流程,适用于所有使用多域名(SAN)证书的场景。 🔎 背景 某服务器最初申请了包含十多个子域名的多域名证书(例如主域名、文件服务、聊天系统、监控面板等),后来由于业务调整,有三个子域名不再需要,计划将其从证书中移除。 🛠️ Certbot 的逻辑 Certbot 并不支持「直接编辑」证书来删除域名,而是通过重新申请证书并覆盖原证书来实现域名的更新。 核心原则: 在重新申请时,只需要在新的域名列表中省略要移除的域名,Certbot 会自动生成新的证书并移除不需要的域名。 ✅ 操作流程 1️⃣ 查看当前证书 执行以下命令查看当前证书和域名列表: certbot certificates 记录证书名称(比如 example.com),并核对所有包含的域名。 2️⃣ 准备新的域名列表 只保留当前仍在使用的域名。例如,原证书包含: example.comwww.example.comfile.example.comchat.example.comdb.example.comapp.example.com… 如果计划移除 file.example.com、db.example.com、www.example.com,则新的域名列表只包含需要继续使用的域名。 3️⃣ 重新申请证书 根据实际环境选择使用 –nginx、–apache 或 –standalone 等插件,例如 Nginx: certbot certonly –nginx \ -d example.com \ -d chat.example.com \ -d app.example.com \ …

Rocket.Chat 域名迁移与 Jitsi 配置调整实战总结

在一次 Rocket.Chat 生产环境的维护中,需要将服务域名从旧地址迁移到新的子域名,同时更新文件上传链接和 Jitsi 视频会议配置。这篇文章总结了整个过程中遇到的问题、解决方案以及关键操作步骤,供有类似需求的用户参考。 💡 背景 🟢 域名迁移 修改 docker-compose.yml 首先需要在 docker-compose.yml 中更新 Rocket.Chat 服务的 ROOT_URL 环境变量,例如: environment: ROOT_URL: https://chat.example.com 修改后执行以下命令重新启动容器,使修改生效: docker-compose downdocker-compose up -d 更新数据库中的 Site URL Rocket.Chat 会在数据库中保存一个 Site_Url 配置,优先级高于自动推断。当域名变更时,需要同步更新此值。 进入 MongoDB 容器: docker exec -it <mongodb-container-name> mongosh 切换数据库: use rocketchat 更新 Site_Url: db.rocketchat_settings.updateOne( { _id: “Site_Url” …

用子路径访问 WordPress:更稳定、更简单的最佳实践

在实际运维和多站点管理中,很多人常常会遇到这样的问题: 想通过子域名(例如 blog.example.com)来访问某个子目录中的 WordPress,但最终发现跳转逻辑复杂、配置繁琐,甚至会引发各种不必要的麻烦。 💡 WordPress 的设计逻辑 WordPress 是一个需要严格识别「主站 URL」的应用,站点地址(siteurl 和 home)会被写入数据库。它的架构假设访问地址是唯一且固定的,这与 Nextcloud 等可以完全依赖相对路径的应用不同。 ⚡ 子域名访问的复杂性 如果希望通过子域名根路径访问 WordPress,比如 blog.example.com: 对于已有多文件的根目录环境,或同一台服务器上有其他重要应用,这种方案会带来较高的风险和维护成本。 ✅ 子路径访问:最简单、最稳妥 相比之下,保留原有子路径(例如 https://example.com/wordpress/)具有明显优势: 在 Nginx 配置中,可以继续保留: location / { proxy_pass http://后端服务器/wordpress/; proxy_http_version 1.1; 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 https;} 🔥 子路径方案的适用场景 ⭐ 总结 …

多服务 Nginx 反向代理配置与细节总结

在复杂的多服务服务器环境中,通过子域名和 Nginx 反向代理将不同内网服务安全、高效地发布到公网,是一种常见且实用的架构方案。以下是一份详细的配置总结,涵盖了常用服务(如 Nextcloud、Rocket.Chat、WordPress、PVE、PBS、Webmin、Stirling PDF、phpMyAdmin、Portainer、Plex 等)在 Nginx 上的实践配置与要点。 ✅ 核心思路 ✅ 通用配置结构 server { listen 80; server_name example.com; return 301 https://$host$request_uri;}server { listen 443 ssl http2; server_name example.com; client_max_body_size 200M; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; location / { proxy_pass http://192.168.x.x:port/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection “upgrade”; …

WordPress 备份遇到 504 Gateway Timeout 与大文件问题的解决方案

在使用 WordPress 过程中,网站数据的安全备份至关重要。常见的备份插件(如 Duplicator)可以快速打包整个站点文件和数据库,但在实际操作中,若站点体积较大,经常会遇到 504 Gateway Time-out 错误,或者浏览器下载时中断。这些问题并非插件故障,而多由服务器配置、超时设置或下载方式不当引起。 备份流程与后台情况 Duplicator 的典型流程分为两步:先导出数据库 SQL 文件,再将站点文件夹与数据库一起压缩为一个 zip 包。在后台任务执行时,会显示「Building Backup xx%」等进度信息。 若在打包中途遇到 504 Gateway Timeout 错误,往往只是浏览器或代理超时,实际压缩进程在服务器上通常仍在继续。刷新页面或重新进入备份列表,常可看到完整备份文件已生成。 504 Gateway Time-out 的原因 当服务器或代理(如 Nginx、Cloudflare 等)在设定时间内未收到后端响应,会返回 504 错误。进行大文件打包时,后端需要长时间执行 PHP 代码,若超出配置的超时时间,就会触发该错误。 解决思路 1️⃣ 调整服务器超时设置 修改后需重启服务: bashCopyEditsudo systemctl restart nginx sudo systemctl restart apache2 sudo systemctl restart php8.1-fpm 2️⃣ …

使用 Certbot 更新并统一多子域名 SSL 证书实践总结

在服务器上使用 HTTPS 是保证安全访问的必备措施,而 Let’s Encrypt 提供了免费的 SSL 证书,结合 Certbot 工具可以非常方便地申请和更新证书。在实际场景中,往往不仅需要为主域名配置证书,还要同时支持多个子域名,比如: python-replCopyEditwww.domain.com mail.domain.com app1.domain.com app2.domain.com … 以下是一次完整实践记录,总结关键步骤与注意事项。 💡 证书现状查看 首先查看现有证书及已包含的域名: bashCopyEditcertbot certificates 输出示例: yamlCopyEditFound the following certs: Certificate Name: domain.com Domains: domain.com mail.domain.com www.domain.com Expiry Date: 2025-09-22 21:50:18+00:00 (VALID: 82 days) Certificate Path: /etc/letsencrypt/live/domain.com/fullchain.pem Private Key Path: /etc/letsencrypt/live/domain.com/privkey.pem 🔄 重新申请并添加更多子域名 为了将所有需要的子域名统一到一个证书中,执行以下命令(使用 …

Nginx 多服务反向代理方案对比与最佳实践

在自建服务器或私有云环境中,常常需要将多个 Web 服务整合到同一个公网 IP 上对外提供访问。常见的服务如 Rocket.Chat、Nextcloud、Proxmox VE、Mailcow 等,如何设计访问方式成为系统架构中一项重要决策。本文详细总结三种典型方案,并进行全面对比,帮助选择最适合的部署方式。 💡 三种典型方案 方案一:不同端口访问 思路每个服务占用一个独立的端口,用户通过域名加端口号访问,如: 优点 缺点 方案二:同域名 + 路径前缀 思路多个服务共享同一个域名,通过路径前缀区分,如: 优点 缺点 方案三:子域名 思路为每个服务配置一个独立子域名,如: 优点 缺点 ⚖️ 总体对比总结 不同端口访问 同域名 + 路径前缀 子域名 域名数量 1 1 多个子域名 端口体验 差(需手动输入) 好 好 兼容性 中 差 最好 用户体验 差 一般 最佳 配置复杂度 最简单 复杂 …

ClamAV 警告信息解析:cli_scanxz: decompress file size exceeds limits

在使用 ClamAV 进行文件扫描时,日志中经常会出现如下警告信息: pgsqlCopyEditLibClamAV Warning: cli_scanxz: decompress file size exceeds limits – only scanning 105906176 bytes 这条信息可以分解为以下几个部分: 产生原因 ClamAV 为了防止扫描过程中消耗过多系统资源,默认对解压后文件的大小设定了限制。这主要是出于性能和安全考虑,避免在面对恶意构造的巨型压缩文件时导致系统资源耗尽。 是否需要调整 若需要完整扫描所有内容,可在 clamd.conf 配置文件中通过修改如下参数进行调整: confCopyEditMaxFileSize 500M MaxScanSize 1G 需要注意,增加这些值将导致更高的内存和 CPU 占用,并可能导致扫描耗时显著增加。实际应用中,通常只在对安全性要求极高的环境或需要扫描大文件的情况下才会考虑修改。 总结 当 ClamAV 遇到解压后超出大小限制的文件时,会发出警告但继续进行扫描,仅扫描指定限制内的部分数据。这种机制是一种平衡性能与安全性的默认保护措施。在大多数场景下,可保持默认配置,无需额外干预。

ClamAV 更新失败与扫描执行问题排查总结

在使用 ClamAV 进行病毒库更新(freshclam)的过程中,出现了如下错误信息: vbnetCopyEditCan’t query current.cvd.clamav.net Invalid DNS reply. Falling back to HTTP mode. FreshClam previously received error code 429 or 403 from the ClamAV Content Delivery Network (CDN). This means that you have been rate limited or blocked by the CDN. You are still on cool-down until after: YYYY-MM-DD …