Go 应用程序作为 systemd 服务运行

哈喽！今天心血来潮给大家带来了《Go 应用程序作为 systemd 服务运行》，想必大家应该对Golang都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习Golang，千万别错过这篇文章~希望能帮助到你！

我们正在运行一个 golang 应用程序，该应用程序在内部运行一个自动更新模块来接收无线更新。在进行新更新时，自动更新模块从 s3 下载新版本，并调用与可执行文件位于同一工作目录中的自动更新 bash 脚本。自动更新 bash 脚本执行的步骤根据使用和不使用 systemd 处理的进程管理进行了解释。

不使用 systemd 执行

1. 通过 pid 终止当前正在运行的 golang 应用
2. 运行新下载的 golang 二进制文件。
3. 新版本公开了一个运行状况检查 api，该 api 由脚本调用以确保该版本运行良好。
4. 如果不健康，则执行回滚。新版本停止，旧版本启动。

在 golang 中，脚本执行代码的编写方式是，当调用自动更新脚本时，它会脱离 golang 应用程序的生命周期。即 bash 脚本（子进程）即使在父进程（golang 应用程序）被杀死后也会继续执行。从 goland ide 运行时工作正常。

问题：通过 systemd 执行

我们需要一个更干净的系统来处理启动、停止、故障重启功能。因此我们决定将应用程序作为 systemd 服务运行。步骤与上面相同，但使用 systemctl 执行

1. 终止当前正在运行的 golang 应用程序：“systemctl stop goapp.service”
2. 使用新的可执行路径更新 systemd 服务：“systemctl daemon-reload”
3. 重新启动 systemd 服务：“systemctl restart goapp.service”
4. 如果不健康，则执行回滚。新版本停止，systemd 服务文件更新为旧版本，旧版本启动。

通过 systemd 执行应用程序时，一旦在上述步骤 1 中使用命令“sudo systemctl stop goapp.service”停止 systemctl 服务，脚本就会退出。这意味着 golang 应用程序执行的脚本的生命周期与 systemd 服务的生命周期明显耦合。如何将其从 systemd 服务范围中分离出来？

systemd 服务文件

[unit]
description=goapp
after=docker.service
requires=docker.service
requires=docker-mysql.service
requires=docker-redis.service
startlimitinterval=200
startlimitburst=5

[service]
user=root
environment=aws_shared_credentials_file=/home/username/.aws/credentials
restart=on-failure
restartsec=30
workingdirectory=/home/username/go/src/goapp-v2.0.0
execstart=/home/username/go/src/goapp-v2.0.0/goexecutable --autoupdate=true

[install]
wantedby=multi-user.target

调用自动更新bash脚本的golang代码部分

func scriptExecutor(argsliceString []string, remoteVersion *semver.Version, localVersion *semver.Version) {

newVersion := fmt.Sprint(remoteVersion)
previousVersion := fmt.Sprint(localVersion)
argslice := append(argsliceString, newVersion, previousVersion)
scriptParams := append([]string{"./autoupdate-script.sh"}, argslice...)
Info("Autoupdater - New version ", newVersion)
Info("Autoupdater - Existing Version ", previousVersion)
Info("Autoupdater - Executing shell script to upgrade go app.Passing parameters ", scriptParams) // ./autoupdate-script.sh goexecutable 7.1.0 7.0.0
cmd := exec.Command("sudo", scriptParams...)
err := cmd.Start()
if err!=nil{
    Info(err)
}
cmd.Process.Release()

}

关于“如何在 golang 中运行脚本并否认/分离它”的帖子已发布，但找不到任何关于此类问题的帖子。如果我的理解有任何错误，请帮助我解决问题或纠正我。

解决方案

调用与可执行文件位于同一工作目录中的自动更新 bash 脚本。

我建议使用 systemd-run 运行它。手册页摘录：

它将运行在 干净且独立的执行环境。

嗨，这是一篇有点旧的文章，但仍然引起了我的兴趣，因为我们目前正在开发一个独立的单一二进制 Web 应用程序，它将在客户端的计算机上运行，​​并且我们计划在发布之前对应用程序实现自动更新和升级功能v1.0.0。

因此，我正在对这个主题进行一些研究，以收集所有可读资料，以便在需要时发展这个想法。

如果您还在，您能否向我们介绍一下该项目的进展情况以及实现此功能是否可持续且可维护？

其次，我们计划做的是；

• 使用私有 gitlab 存储库作为版本控制，因此只要我们准备好，我们就可以启动运行 Makefile 的 CD&CI 管道，通过执行一些其他神奇的操作来构建前端和后端使用单个二进制工件。到目前为止它都是这样工作的。

• 其次，我们有一个客户端数据库，用于存储客户端所在的版本。每当我们通过 gitlab CD&CI 构建新版本时，我们都会计划将新版本设置为一个小众客户作为试点组。

• 我们的应用程序有一个在后台运行的辅助线程，每小时检查数据库中的版本，每当检测到当前版本 > 时，它都会通知前端管理员用户单击并升级系统（这是不要在某事中间打扰客户）

• 现在有趣的部分和未实现的部分来了：计划是使用 wget 或类似 golang 库的东西从 gitlab 下载新的二进制文件到 temporary 位置，并在那里进行一些健全性检查，以确保应用程序是好的。然后用新的二进制文件替换当前的二进制文件，并向 systemd service 发送 service restart 命令以重新启动应用程序，以便实现新功能，因为它将从新的二进制文件运行。

到目前为止，这似乎是适用的，并且顺利。根据您的经验，您还有什么想指出的吗？

我发布此内容的原因是；这可能是实现自我更新应用程序的另一种（也许更平滑）方法，因为这与 OS 的交互最小化，除了最后的 service restart 命令之外，无需运行任何 shel​​l 或 bash 脚本。

今天关于《Go 应用程序作为 systemd 服务运行》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！