后端通信【免费下载链接】MailuInsular email distribution - mail server as Docker images项目地址https://gitcode.com/gh_mirrors/ma/Mailu点击查看免费下载本篇指南聚焦 MailuDocker 化邮件服务器的日常运维主题完整覆盖四大核心场景基于docker compose的平滑升级流程、日志监控方案、外部 Lets Encrypt 证书的续期与热加载以及利用 SMTP 重试机制与 rsync 实现的无停机实例迁移。读完本文你将掌握一套可立即落地的主文档维护流程并理解其背后的容器编排、证书监听与文件同步原理。一、升级邮件服务器Upgrading the mail serverMailu 的所有服务镜像都通过docker-compose.yml中的$VERSION变量引用而该变量定义在环境文件.env或mailu.env中。以 docs/compose/docker-compose.yml 为例front: image: mailu/nginx:$VERSION imap: image: mailu/dovecot:$VERSION smtp: image: mailu/postfix:$VERSION admin: image: mailu/admin:$VERSION因此版本升级本质上就是「改一个变量 重建容器」的过程。完整步骤如下。1.1 升级前的检查清单比对上游的编排文件先检查上游对docker-compose.yml或.env文件的改动确认新版本是否引入了新的服务、卷或环境变量通读CHANGELOG.md仓库根目录的 CHANGELOG.md 记录了每个版本的破坏性变更与新增配置。例如 2024.06 版本提示升级前应通过 setup 工具重新生成docker-compose.yml与mailu.env再手动把旧配置项回填到mailu.envPOSTFIX_LOG_FILE已被弃用若启用 Tika 则需额外 12GB 内存。这些信息决定了哪些旧设置需要调整、哪些参数被删除务必逐条核对避免升完级才发现配置不兼容确认回滚边界某些大版本升级后无法回退CHANGELOG 中明确标注 you wont be able to roll-back to earlier versions升级前应做好心理预期与备份。1.2 修改版本号在.env文件中把版本变量更新为目标版本。VERSION支持具体的发行版本号如果你一直使用stable或latest标签则可以跳过这一步直接拉取最新镜像。1.3 拉取镜像并重建容器docker compose pull docker compose down docker compose up -d三条命令的含义分别是docker compose pull拉取所有服务的新镜像只更新镜像不影响运行中的容器docker compose down停止并移除旧容器与默认网络docker compose up -d用新镜像在后台重新创建并启动全部容器。注意docker compose down默认不会删除卷data、mail、dkim等持久化目录都在宿主机上而非容器内因此邮件数据不会丢失。如果你需要彻底清理例如测试环境重置才考虑docker compose down -v但生产环境严禁使用-v它会连带删除匿名卷中的持久化数据。1.4 升级后的验证启动完成后用下一节的日志命令检查各容器是否正常启动尤其关注admin与front容器。CHANGELOG 中还给出了一些升级后的专项操作例如重新建立 dovecot 全文检索索引find /mailu/mail -type d -name xapian-indexes -prune -exec rm -r {} \ docker compose exec imap doveadm fts rescan -A docker compose exec imap doveadm user * | while read u; do echo re-indexing $u docker compose exec -T imap doveadm index -u $u * done这类步骤属于特定版本的附加要求具体以 CHANGELOG.md 对应版本的说明为准。二、监控邮件服务器Monitoring the mail serverMailu 不引入独立的日志收集组件日志由 Docker 直接管理。查看日志只需一条命令docker compose logs常用变体docker compose logs -f # 实时跟踪follow docker compose logs --tail100 # 只看最近 100 行 docker compose logs admin # 只看 admin 容器 docker compose logs -f front imap smtp antispam # 同时跟踪多个容器2.1 日志驱动从 docs/compose/docker-compose.yml 可以看到front、imap、smtp、antispam、admin等服务都显式配置了日志驱动logging: driver: journald options: tag: mailu-front也就是说这些容器默认把日志写入 systemd journal并打上mailu-front、mailu-imap、mailu-smtp、mailu-antispam、mailu-admin等 tag方便按服务过滤。Docker 支持把日志转发到多种日志引擎journald、syslog、fluentd、awslogs、gelf 等你可以根据部署环境配置对应的logging.driver把 Mailu 各容器的日志统一汇入现有日志平台。各驱动具体参数可查阅 Docker 官方日志驱动文档。2.2 日志级别调节容器启动脚本的日志阈值由环境变量LOG_LEVEL控制可选值为CRITICAL、ERROR、WARNING、INFO、DEBUG、NOTSET默认INFO见 setup/flavors/compose/mailu.env 第 184185 行的注释。排查问题时可以临时调成DEBUG再回滚。三、管理外部 Lets Encrypt 证书Managing external Lets Encrypt certificatesMailu 的 TLS 行为由环境变量TLS_FLAVOR决定可选值包括letsencrypt使用 Mailu 内置的 certbot 自动申请与续期cert使用用户自己管理的证书文件notls完全关闭 TLS。详细配置参考 docs/configuration.rst。当TLS_FLAVOR不是内置letsencrypt时你无法使用 Mailu 在letsencrypt/live目录中维护的符号链接机制该目录由内置 certbot 生成路径为/certs/letsencrypt/live/mailu/相关逻辑见 core/nginx/config.py。此时需要自己保证每次续期后把新证书复制到/mailu/certs并重载front容器中的 nginx 进程。3.1 使用 certbot deploy hook 自动续期以 certbot 为例编写一个 deploy hook 脚本证书续期成功后由 certbot 自动调用#!/bin/sh cp /etc/letsencrypt/live/domain.com/privkey.pem /mailu/certs/key.pem || exit 1 cp /etc/letsencrypt/live/domain.com/fullchain.pem /mailu/certs/cert.pem || exit 1 docker exec mailu_front_1 nginx -s reload docker exec mailu_front_1 doveadm reload脚本要点privkey.pem复制为key.pemfullchain.pem复制为cert.pem——这两个文件名正好对应 Mailu 在cert模式下查找的证书路径core/nginx/config.py 中TLS_CERT_FILENAME与TLS_KEYPAIR_FILENAME的默认值复制失败时exit 1让 certbot 知道部署未成功docker exec进入front容器执行nginx -s reload热加载新证书doveadm reload则重载 dovecot 代理配置无需重启容器。配套的 crontab 定时续期任务52 0,12 * * * root /usr/bin/certbot renew --deploy-hook /path/to/script.sh52 0,12表示每天 0:52 与 12:52 各执行一次续期检查certbot 只在证书临近过期时才真正续期并触发 deploy hook。3.2 证书监听器certwatcher 的实现原理值得一提的是Mailu 的front容器本身就内置了一个证书监听器。当TLS_FLAVOR为cert或mail时core/nginx/start.py 会启动 core/nginx/certwatcher.pyif os.environ[TLS_FLAVOR] in [ letsencrypt,mail-letsencrypt ]: subprocess.Popen([/letsencrypt.py]) elif os.environ[TLS_FLAVOR] in [ mail, cert ]: subprocess.Popen([/certwatcher.py])certwatcher 使用 watchdog 轮询监听/certs/cert.pem与/certs/key.pem的文件事件文件被创建、移动或删除触发/config.py重新生成 nginx/dovecot 配置reexec_config文件内容被修改只需nginx -s reload与doveadm reloadreload_nginx因为证书路径没变。if filename in [self.cert_path, self.keypair_path]: if isinstance(event, (FileCreatedEvent, FileMovedEvent, FileDeletedEvent)): ChangeHandler.reexec_config() elif isinstance(event, FileModifiedEvent): ChangeHandler.reload_nginx()这意味着只要你的 deploy hook 把新证书以覆盖写cp即修改文件内容的方式放进/mailu/certscertwatcher 会自动完成 nginx 重载deploy hook 中的docker exec ... nginx -s reload属于双保险。若 certbot 是以「删除旧文件→写入新文件」的方式部署创建/移动事件certwatcher 则会走完整的重新配置流程/config.py该脚本最后执行killall -q -HUP nginx dovecot见 core/nginx/config.py。注意容器名deploy hook 示例中的mailu_front_1是默认COMPOSE_PROJECT_NAMEmailu时的容器名如果你自定义了项目名需要相应替换为项目名_front_1。四、迁移实例Migrating an instanceMailu 的迁移设计非常轻量这得益于两个底层特性SMTP 协议本身自带重试机制且一个域名可以配置多个 MX 记录——因此在迁移窗口期内发往该域名的邮件要么落在备用服务器上要么由远端 MX 排队重试通常不需要额外处理Mailu 重度依赖文件系统存储所有数据没有强依赖集中式数据库的状态因此迁移可以基于文件同步rsync完成。4.1 需要同步哪些目录从 docs/compose/docker-compose.yml 的卷映射可以梳理出完整的持久化目录清单目录$ROOT 下挂载到存储内容dataadmin 容器/data用户、域名、别名等核心配置数据mailimap 容器/mail全部用户邮件Maildirdkimantispam/admin 容器DKIM 密钥mailqueuesmtp 容器/queuePostfix 邮件队列filterantispam/antivirus 容器rspamd 训练数据与反病毒库redisredis 容器Redis 数据davwebdav 容器CardDAV/CalDAV 数据webmailwebmail 容器Webmail 数据certsfront 容器/certsTLS 证书overrides各容器/overrides自定义覆盖配置主文档中特别点名的data、dkim、mail是迁移的核心其余目录可按实际启用的功能webmail、webdav、antivirus 等决定是否同步。4.2 建议迁移流程六步主文档给出了一套「备用服务器兜底」的迁移方案核心思路是新服务器先就位但不启动 → DNS 把新服务器设为次级 MX → rsync 数据 → 旧服务器停机做最后一次同步 → 新服务器接管。步骤 1准备新服务器复制docker-compose.yml、.env及基础配置文件到新服务器使其具备启动 Mailu 的一切条件但不要启动 Mailu避免新服务器上的进程与 rsync 写文件冲突。步骤 2调整 DNS 的 MX 记录把新服务器配置为域名的附加、低优先级数值更大MX。这样在迁移窗口内邮件投递仍优先走旧服务器即便旧服务器短暂不可用远端也会退而选择新服务器。如果你的服务器服务很多域名、逐个改 MX 过于复杂可以直接跳过本步——代价仅仅是部分远端 MX 会重试几分钟。MX 优先级的具体写法参见 docs/dns.rst数字即 MX 优先级单服务器场景下数值本身不重要但多服务器主 备份时必须调整数值使主服务器优先。步骤 3反复 rsync 数据在 DNS TTL 过期、记录开始传播的同时开始把 Mailu 数据目录data、dkim、mail等rsync 到新服务器并重复执行直到每次只剩少量文件需要同步rsync -avz --delete /path/to/mailu/ rootnew-server:/path/to/mailu/其中--delete确保新服务器上与源不一致的陈旧文件被删除避免残留旧数据反复执行是为了逼近「增量接近零」的收敛状态。步骤 4旧服务器停机执行最终同步在旧服务器上停止 Mailu确保没有进程在写文件然后跑最后一次 rsync把停机期间产生的最新变化补齐。步骤 5新服务器上线在新服务器上启动 Mailu生产环境恢复正常。由于新服务器已作为次级 MX即便此时 DNS 尚未完全收敛邮件也不会丢失。步骤 6切换主 MX把新服务器设为主要 MX若步骤 2 未添加附加 MX则必须修改 MX 名称对应的A/AAAA记录最后删除旧服务器。4.3 迁移期间的邮件安全边界整个流程依赖两个缓冲远端 SMTP 队列的重试窗口次级 MX 兜底。因此在步骤 4 的停机窗口内会出现一小段时间旧服务器不可达但只要次级 MX 或远端重试机制生效邮件不会丢。这也是为什么文档强调「Mailu 未启动」的新服务器要先就位——它在迁移窗口期就是现成的邮件接收入口。五、维护操作速查场景命令升级到新版本docker compose pull docker compose down docker compose up -d查看全部日志docker compose logs -f查看指定容器日志docker compose logs -f admin证书续期后热加载docker exec mailu_front_1 nginx -s reloaddocker exec mailu_front_1 doveadm reload数据同步迁移反复执行rsync -avz --delete 源目录/ root新服务器:目标目录/以上四块内容共同构成了 Mailu 运维的完整闭环升级保证功能与安全更新、监控保证可观测性、证书管理保证 TLS 信任链、迁移保证容灾与扩容能力。每一条操作都可以在 docs/maintain.rst 与上述源码文件中找到对应的实现依据。赞分享后端通信【免费下载链接】MailuInsular email distribution - mail server as Docker images项目地址https://gitcode.com/gh_mirrors/ma/Mailu点击查看免费下载相关推荐XDM浏览器插件终极指南如何5倍提升下载速度的完整解决方案XDM浏览器插件终极指南如何5倍提升下载速度的完整解决方案 你是否厌倦了浏览器下载的缓慢速度XDMXtreme Download Manager浏览器插后端通信Cilium Hubble Relay 本地端口转发从 kubectl 手动操作到 Hubble CLI -P 自动转发的完整实践Cilium Hubble Relay 本地端口转发从 kubectl 手动操作到 Hubble CLI P 自动转发的完整实践 在 Cilium 集群中H后端通信如何快速掌握Dockprom监控栈从安装到高级运维的完整指南如何快速掌握Dockprom监控栈从安装到高级运维的完整指南 Dockprom是一个Docker化的监控栈集合包括Prometheus、Grafana、Al上一篇极速掌握Spinning Up1小时完成深度强化学习项目的终极指南下一篇【亲测免费】 Meta 3D AssetGen 使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考