现在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。请注意，这将适用于主机上的所有容器。