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

Question

我最近从 Debian 10 (Buster) 更新到 11 (Bullseye)，从那时起，我在 Docker 内的 Jenkins 设置就不再工作了，因为 Jenkins 试图通过检查/proc/self/cgroup.

通常，/proc/self/cgroupdocker 容器内部看起来像这样：

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。

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

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 inside the container with cgroup v2

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

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