问题描述
我正在运行一些应用程序，其中应用程序必须知道它在PODMAN内运行而没有任何额外的env变量，但是容器内的podman配置必须提供详细信息，而无需任何用户交互。
到目前为止，我开始在容器中使用cat /proc/self/cgroup| grep -i 'machine.slice/libpod-*'，并开始使用podman来检查进程是否在pod内。
有更好的方法来处理吗？
解决方法
从纯理论的角度来看，将/proc/self/cgroup与方法结合使用是一个坏主意，因为不能保证容器引擎不会在新的cgroup命名空间中生成容器，从而使容器化进程可以看到其当前状态。像下面的示例中的/一样简单地使用cgroups（unshare -C在这里模拟了容器引擎在启动容器时取消共享cgroup命名空间）：
$ podman run -it --privileged archlinux/base
[root@da0277b524db /]# unshare -C
-sh-5.0# cat /proc/self/cgroup
12:freezer:/
11:perf_event:/
10:pids:/
9:blkio:/
8:hugetlb:/
7:rdma:/
6:cpu,cpuacct:/
5:cpuset:/
4:net_cls,net_prio:/
3:memory:/
2:devices:/
1:name=systemd:/
0::/
从实际的角度来看，容器引擎似乎关心这种技巧的兼容性，例如Moby uses the host cgroup namespace by default，并且Podman似乎也使用主机cgroup命名空间，因此此流行的脏检查应该成功，但是它仍然是对无意隔离违反的一种利用。 ，自从cgroup名称空间不存在以来一直存在。
什么是替代品？
在具体谈论Podman时，容器引擎似乎在container spec creation期间插入了一个特殊的环境变量，以指示容器化过程是使用特定的容器引擎启动的。因此，即使在启动容器时没有任何其他变量的情况下，也可能会在其位置找到container变量：
$ podman run -it alpine
/ # env | grep container
container=podman
尽管这种方法也不是防弹的（因为没有什么可以阻止容器创建者覆盖此变量），但我认为它比使用/proc/self/cgroup的技巧要好得多，因为这些东西是由容器引擎有意提供的，并且不太可能被无意中覆盖，因为此变量不遵循通用命名约定，并且不使用{{1} }样式。