即使有了容器化技术，制作 systemd 等系统服务来启动容器化服务仍然是有意义且在很多场景下是必要的。以下是几个主要原因：
系统整合与统一管理：
使用 systemd 等系统服务管理器将容器化服务作为系统服务启动，可以让它们融入到主机操作系统的标准服务管理体系中。这样，您可以使用熟悉的 systemctl start/stop/restart/status 等命令来控制容器的生命周期，与管理其他原生系统服务的方式保持一致，增强系统的整体性和易管理性。
自动化与依赖管理：
系统服务允许定义服务间的依赖关系、启动顺序和重启策略等。对于容器化的微服务架构，可以通过 systemd 设置容器之间的启动顺序，确保依赖服务先于依赖它的服务启动。此外，当主机系统重启时，配置为自动启动的容器服务也会按预期自动启动，无需人工干预，提高了系统的稳定性和可靠性。
资源限制与监控：
利用 systemd 对容器服务的管理，可以更精细地控制容器的资源配额，如 CPU、内存、磁盘 I/O 和网络带宽等。systemd 提供了 SystemCallFilter、MemoryLimit、CPUQuota 等参数来设定容器的系统调用权限和资源限制。同时，systemd 还能与系统监控工具（如 journalctl）无缝集成，便于收集容器的日志输出和跟踪其运行状态。
安全性与隔离：
将容器服务注册为系统服务，可以在启动容器时指定额外的安全上下文（如 SELinux 标签）和权限限制，增强容器运行时的安全性。此外，通过 systemd 配置，可以限制容器只能访问特定的主机资源或接口，进一步强化容器与主机及其他容器之间的隔离。
长期运行服务的支持：
对于需要长期运行、始终保持可用的后台服务，如数据库、消息队列、API 服务器等，将其封装在 systemd 服务中，能够确保在主机系统遇到故障或维护时，服务能够根据预定义的重启策略自动恢复，维持业务连续性。
CI/CD 工作流与基础设施即代码：
在 DevOps 和持续部署环境中，将容器服务的启动配置编写为 systemd unit 文件，并纳入版本控制系统，有利于实现基础设施即代码（IaC）。这样，可以使用相同的配置在不同的环境中部署服务，确保一致性，并通过 CI/CD 流程自动化部署和更新。
综上所述，虽然容器化技术本身提供了服务封装、隔离和便携性，但将其作为系统服务通过 systemd 等工具进行管理，可以更好地整合到主机操作系统中，实现资源管控、依赖协调、自动化运维、安全强化以及与现有工具链的集成。因此，即使有了容器化，制作 system service 来启动服务在许多情况下仍然是必要的且有益的。当然，具体是否需要取决于您的环境特性和管理需求。
制作一个 systemd 服务涉及以下几个步骤：
编写服务文件：
创建一个 .service 文件来定义您的服务。通常，这个文件会被放置在 /etc/systemd/system/ 目录下，以确保系统在启动时能识别并管理它。例如，如果您要为一个名为 myapp.service 的 Spring Boot 应用程序创建服务，您可以按照以下结构编写服务文件：
[Unit]
Description=My Spring Boot Application
Documentation=https://example.com/docs/myapp
After=network.target
[Service]
User=
Group=
ExecStart=
Restart=always
SuccessExitStatus=143
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
其中：
[Unit] 区块：
Description: 提供服务的简短描述。
Documentation: 可选，指向服务的详细文档或手册页的URL。
After: 指定服务启动前应等待的其他服务或目标，如 network.target 表示网络已就绪。
[Service] 区块：
User 和 Group: 指定服务运行时使用的用户和组，以限制其权限。
ExecStart: 定义启动服务的具体命令，包括路径和参数。
Restart: 设置当服务崩溃或退出时的重启策略，如 always 表示无论何种原因退出都要自动重启。
SuccessExitStatus: 可选，指定除标准的0之外被认为是成功退出的状态码，如 Spring Boot 使用的143表示正常关闭。
LimitNOFILE: 可选，设置服务的最大打开文件数限制。
[Install] 区块：
WantedBy: 指定服务应该被哪个目标（target）所需求，如 multi-user.target 表示在多用户系统中默认启动此服务。
