在 Debian 11 (Bullseye) /proc/self/cgroup 上 docker 容器内不显示 docker 信息

On Debian 11 (Bullseye) /proc/self/cgroup inside a docker container does not show docker infos

我最近从 Debian 10 (Buster) 更新到 11 (Bullseye),从那以后我在 Docker 中的 Jenkins 设置不再工作,因为 Jenkins 试图找出它是否 运行通过检查 /proc/self/cgroup.

在 docker 容器中

通常 /proc/self/cgroup 在 docker 容器内看起来像这样:

12:rdma:/
11:perf_event:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
10:freezer:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
9:memory:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
8:cpuset:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
7:devices:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
6:net_cls,net_prio:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
5:hugetlb:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
4:pids:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
3:cpu,cpuacct:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
2:blkio:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
1:name=systemd:/docker/a2ffe0e97ac22657a2a023ad628e9df837c38a03b1ebc904d3f6d644eb1a1a81
0::/system.slice/containerd.service

但自从我更新到 Debian 11 后它看起来很小:

0::/

由于 Jenkins 不再识别它 运行 在 docker 容器本身中,它会使用错误的参数启动其他构建容器。

问题

简单的问题是:这是一个错误吗?

但真正的问题可能是我做错了什么?我找不到其他人遇到此问题,因此可能是配置错误或类似问题。

我重新安装了 Docker,删除了所有配置,我什至尝试将 Docker 降级到 20.10.6,因为这是我所知道的在 Debian 10 下运行的最后一个版本,但是 none这改变了一切。

我不知道如何进一步解决这个问题。我已经花了一整天才发现问题不是 Jenkins 本身(阅读 Jenkins 日志时差点发疯)。我现在正在打基岩,所以非常感谢任何帮助和任何意见!


詹金斯的东西

对于那些对 Jenkins 部分感兴趣的人,这里 Jenkins 检查它是否在容器内 运行: https://github.com/jenkinsci/docker-workflow-plugin/blob/b174d46226ef1095903f2e789355a3b216b46dda/src/main/java/org/jenkinsci/plugins/docker/workflow/client/DockerClient.java#L347

Jenkins 认为它​​不在容器内 运行 会记录如下内容:

Jenkins does not seem to be running inside a container
$ docker run -t -d -u 0:0
-w /var/jenkins_home/workspace/myrepo_master
-v /var/jenkins_home/workspace/myrepo_master:/var/jenkins_home/workspace/myrepo_master:rw,z
-v /var/jenkins_home/workspace/myrepo_master@tmp:/var/jenkins_home/workspace/myrepo_master@tmp:rw,z
-e ******** ... my-awesome-build-container cat

因此从主机系统安装 /var/jenkins_home,Jenkins 无法从其容器内部访问该系统。 Debian 10(和 Ubuntu 20.04)上的日志输出看起来像这样:

Jenkins seems to be running inside container 7814083762a1bed51dec2f468c6ee07c978a0b6377e347c3ed7dc23393feac11
$ docker run -t -d -u 0:0
-w /var/jenkins_home/workspace/myrepo_master
--volumes-from 7814083762a1bed51dec2f468c6ee07c978a0b6377e347c3ed7dc23393feac11
-e ******** ... my-awesome-build-container cat

并使用 --volumes-from.

以正确的卷启动构建容器

行为的变化是由于 debian 从 Debian 11/Bullseye 开始使用 cgroups v2。 docker 引擎本身支持 cgroups v2 自 v20.10.x.

这意味着,一旦您的发行版使用了 cgroups v2 和最新版本的 Docker 引擎,您就无法使用您的方法获取容器 ID。

我打开了一个类似的问题来寻找替代方法:

我知道获取 id 的唯一方法是使用 docker api,但如果您只想知道进程是否 运行,那不是一个优雅的解决方案在容器内。 (如果在容器内暴露 docker 套接字,可能会带来安全风险)

目前,作为一种解决方法,您可以手动向进程发出信号,表明它 运行 在容器环境中,例如通过在创建容器时指定环境变量。