现在Ubuntu 22.04发布了,我在我们的一个Jenkins-Worker上做了一个干净的安装来测试它,但是我无法让docker ssh-agent正常工作。它不再能识别它是否在容器内运行,因此每当启动使用停靠器的作业时,我都可以在控制台中看到“jenkins-Worker-X似乎没有在容器内运行”,紧随其后的是管道故障。
我以前知道Jenkins使用cgroup信息来检测它是否在容器中运行,所以例如,在容器中执行cat /proc/self/cgroup
应该会得到一个以/docker/<container-id>
结尾的行列表,然后Jenkins使用它来检测容器。然而,一旦我安装了Ubuntu 22.04,cgroup信息就不再包含/docker/<container-id>
,这会导致Jenkins代理认为它在裸机上运行。
即使执行官方映像也会遇到同样的问题,即在我的机器上,docker run jenkins/ssh-agent:jdk11
和docker exec <container-id> cat /proc/self/cgroup
的结果是一个没有容器散列的列表。
如何对此进行故障排除?从Ubuntu 21.10到22.04有什么变化导致了这个问题吗?是否需要进行一些额外的配置?
我正在运行最新的Ubuntu 22.04(5.15.0-27-通用),Docker版本20.10.12,内部版本20.10.12-0ubuntu4。
如有任何帮助,我们将不胜感激!
编辑:我现在意识到,如果您将所有包升级到最新版本(并使用最新的jenkins/ssh-agent映像),21.10中也会发生同样的事情,所以原因可能出在某个升级的包中
2条答案
按热度按时间iyfamqjs1#
事实证明,这个问题毕竟与cgroup v2有关。似乎在使用v2时,当您创建容器(在我的例子中是Jenkins代理)时,cgroup名称空间默认是私有的,这导致容器id在
/proc/self/cgroup
中不可用。简单的解决方案是按照建议的in another question here使用
--cgroupns host
运行停靠容器。当我这样做的时候,Jenkins可以再次检测到它在里面运行的容器。就在我发布这个问题的时候,Ubuntu 21.10切换到cgroup v2的更新可能已经发布了,因为我以后也可以在那里重现这个问题。
fquxozlt2#
如果Jenkins容器与Docker Compose一起运行,则不可能提供另一个答案中建议的
--cgroupns host
标志。从今天起,这是still missing from the Compose specification。但是,如果您可以控制运行Jenkins的Docker守护进程,则可以在您的Docker守护进程配置中将
default-cgroupns-mode
标志设置为host
。请注意,这将适用于主机上的所有容器。