问题描述
我一直在使用谷歌的容器优化操作系统在 GCP 计算引擎虚拟机上部署容器。当主机 VM 在 GCP 中停止时,我一直在努力理解已部署容器的关闭行为。
当我的容器收到 SIGTERM 或 SIGINT 信号时,它们会执行一些清理行为并将一些文件写入已安装的卷中。我已经用 docker stop
和 docker kill -s SIGINT
对此进行了广泛的测试。但是,当我在 GCP 中停止主机时,似乎不会发生这种行为。
我不完全确定如何调试这个过程。我尝试连接到 VM 的串行控制台,但它似乎没有任何与容器关闭逻辑有关的信息。
任何指导将不胜感激!作为参考,this 是我正在部署的映像。
完整的复制步骤:
使用“将容器映像部署到此虚拟机”创建一个新的“计算引擎”虚拟机。我一直在使用带有 20GB 启动盘的 e2 介质。
使用“lloesche/valheim-server”图像。
设置以下环境变量:
SERVER_NAME: Test
WORLD_NAME: Test
SERVER_PASS: Password # must be at least 5 characters
在“读/写”模式下添加“目录”类型的目录挂载,挂载路径为“/config”,主机路径为“/home/YOUR_GCP_USERNAME/valheim-server-config”。
容器启动后,您应该在主机(lloesche/valheim-server)上运行镜像。您还应该在 ~/valheim-server-config/worlds/
创建一个名为 Test.fw1
的文件。
现在,停止此容器 (docker stop
) 应该会导致写入该文件。您可以通过停止容器然后观察该文件的修改日期来验证这一点。
然而,当 host 实例停止时,这个过程似乎不会发生。如果您重新启动主机以使容器再次运行,然后向主机发出“停止”命令,则该文件不会在容器被终止之前保存。
解决方法
我浏览了日志,没有发现任何可以指向我的解决方案。
然而,可能有一个解决方法。
您可以使用 shutdown script 在虚拟机关闭之前更“优雅地”停止您的容器;
您可以使用 Found 20 files
Archiving file: .env_sample
... 21 more ...
##[debug]Checking for archive destination folder:/__w/1/a
##[debug]Creating archive with zip: /__w/1/a/1009007.zip
##[debug]which 'zip'
##[debug]not found
##[debug]Unable to locate executable file: 'zip'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.
命令提供脚本:
gcloud
或使用 console UI:
在 Cloud Console 中,直接使用 关闭脚本元数据键:
在 Cloud Console 中,转到虚拟机实例页面。转到虚拟机实例
点击创建实例。在新建实例页面,填写 您的实例的属性。对于高级配置选项, 扩展管理、安全、磁盘、网络、独家租赁 部分。在 Metadata 部分,填写 shutdown-script 作为 元数据键。在值框中,提供关闭的内容 脚本。单击创建以创建实例。
最终,您可以在 Google Issuetracker 创建一个新问题并解释您的期望(什么样的行为)。
,我遇到了同样的问题,我找到了一个解决方法(不完美,但对我有用)。添加为启动脚本的一部分:
mkdir -p /etc/systemd/system/docker.service.d
printf "[Service]\nExecStop=/bin/sh -c 'docker stop \$(docker ps -q)'" > /etc/systemd/system/docker.service.d/override.conf
通常(在这种情况下也用于测试)您可以使用 sudo systemctl edit docker.service
编辑覆盖文件(将您的配置添加到现有配置中)。不幸的是,每次系统启动时,覆盖文件显然都会被删除,这就是我通过启动脚本保留它的原因。
在此方法之前尝试过 Wojtek_B 建议的内容(抱歉,我的声誉太低,无法直接发表评论)但没有奏效。原因是 docker 守护进程在处理关闭脚本之前获得终止信号。由于在“容器优化操作系统”的关闭脚本中涉及 docker 失败(或至少有风险),它可以被视为一个错误。