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

Question

我最近从 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 检查它是否在容器内运行： 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 以正确的卷启动构建容器。

Answer 1

行为的改变是由于 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 套接字可能会带来安全风险）

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