jenkins 在Debian 11(靶心)上,docker容器中的/proc/self/cgroup没有显示docker信息

vzgqcmou  于 2022-11-01  发布在  Jenkins
关注(0)|答案(1)|浏览(277)

我最近从Debian 10(Buster)更新到了11(Bullseye),从那以后我在Docker中的Jenkins设置就不再工作了,因为Jenkins试图通过检查/proc/self/cgroup来确定它是否在Docker容器中运行。
通常,docker容器中的/proc/self/cgroup看起来如下所示:

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下工作的最后一个版本,但这些都没有改变任何东西。
我不知道如何进一步解决这个问题。我已经花了一整天的时间才发现问题不是Jenkins本身的问题(阅读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启动具有正确卷的构建容器。

**编辑:**Jenkins插件现在由PR#280修复,自528.v7c193a_0b_e67c版本以来:https://github.com/jenkinsci/docker-workflow-plugin/pull/280

w6lpcovy

w6lpcovy1#

行为上的改变是由于debian从Debian 11/Bullseye开始使用cgroups v2。docker引擎本身从v20.10.x开始支持cgroups v2。
这意味着,一旦您有一个使用cgroups v2和Docker引擎的最新版本的发行版,您就不能用您的方法获取容器id。
我已经打开了一个类似的问题,找到了一个替代方法:How to get docker container ID from within the container with cgroup v2
我所知道的获取id的唯一方法是使用docker api,但是如果您只想知道进程是否在容器内运行,那么这不是一个很好的解决方案。(如果您在容器内公开docker套接字,那么可能会带来安全风险)
现在,作为一种解决方法,您可以手动向进程发出信号,告知它正在容器环境中运行,例如,通过在创建容器时指定环境变量。

相关问题