Harbor服务总在Docker重启后崩溃？用Systemd守护进程完美解决（Ubuntu/CentOS通用）

Harbor服务总在Docker重启后崩溃？用Systemd守护进程完美解决（Ubuntu/CentOS通用）

如果你在Linux服务器上用Docker Compose部署了Harbor私有镜像仓库，大概率遇到过这个令人头疼的场景：服务器例行重启，或者仅仅是重启了一下Docker服务，原本运行良好的Harbor就再也起不来了。登录服务器一看，docker-compose ps 显示一堆容器在 Restarting 和 Exited 状态之间反复横跳，服务端口始终无法访问。这不仅仅是Harbor的问题，它暴露了Docker Compose部署方式在生产环境中的一个典型短板——缺乏对服务生命周期的有效管理。今天，我们就来深入剖析这个问题的根源，并提供一个跨发行版、一劳永逸的Systemd解决方案，让你的Harbor像系统原生服务一样稳定可靠。

1. 问题根源：Docker Daemon与容器启动的“鸡生蛋”困局

很多人第一次遇到Harbor在Docker重启后崩溃，会本能地去检查Harbor本身的配置、磁盘空间或者网络。折腾一圈后发现，单纯重启Harbor (docker-compose restart) 有时能恢复，有时则不能，充满了不确定性。问题的核心，其实在于服务启动顺序的不可控性。

当你使用 docker-compose up -d 启动Harbor时，它实际上启动的是一组相互依赖的容器，例如 harbor-core, harbor-portal, nginx, registry 以及关键的 harbor-log。其中，日志容器 (harbor-log) 扮演着聚合日志的角色。根据Harbor的默认设计，其他所有容器都会将日志通过Docker Daemon（Docker引擎的后台进程）转发到 harbor-log 容器监听的特定端口（通常是 127.0.0.1:1514）。

这里就产生了一个致命的依赖链：

1. harbor-log 容器需要先启动并监听端口。
2. 其他Harbor容器启动时，需要能通过Docker Daemon将日志发送到该端口。
3. 而Docker Daemon本身，是一个由Systemd管理的系统服务 (docker.service)。

当系统启动或执行 systemctl restart docker 时，Systemd会启动 docker.service。然而，Systemd启动 docker.service 并认为其“启动成功”的瞬间，并不意味着Docker Daemon已经准备好接受容器间的网络通信请求。与此同时，如果你通过任何方式（比如放在 /etc/rc.local 或一个简单的cron job）去启动Harbor，Harbor的容器组会几乎同时开始启动。

此时，如果 harbor-log 容器抢在Docker Daemon完全就绪之前启动并尝试监听端口，它可能会失败，或者虽然成功监听，但后续其他Harbor容器尝试通过Docker Daemon连接它时，会因为Daemon未就绪而连接失败，导致容器启动异常。这种竞态条件（Race Condition）就是服务不稳定的元凶。

注意：这个问题并非Harbor独有，任何重度依赖容器间网络通信、且对启动顺序敏感的Docker Compose应用，在生产环境都可能遇到。

2. Systemd解决方案：将Harbor提升为一级系统服务

既然问题出在操作系统层面的服务管理，那么最正统的解决方案就是在操作系统层面解决。Systemd是现代Linux发行版（Ubuntu 16.04+/CentOS 7+）的标准初始化系统和服务管理器，它的强大之处在于可以精确定义服务之间的依赖关系、启动顺序和重启策略。

我们的目标不再是让Harbor作为一个“在Docker之后手动启动的应用”，而是将其定义为一个标准的Systemd服务。这个服务明确声明：“我必须在Docker服务完全就绪之后才能启动，并且我的生命周期应该被Systemd监控和管理”。

2.1 创建Harbor的Systemd服务单元文件

首先，你需要找到你的Harbor安装目录。假设你按照官方文档，将Harbor解压到了 /usr/local/harbor。我们将在此目录下为Systemd创建一个服务单元文件。

使用文本编辑器（如 vim 或 nano）创建文件 /etc/systemd/system/harbor.service：

sudo vim /etc/systemd/system/harbor.service

将以下配置内容写入该文件。请务必根据你的实际路径修改 ExecStart 和 ExecStop 命令中的路径。