2

I am running some applications where application must know that it is running inside the PODMAN without any extra env variable but podman configuration inside the container must provide the detail without any user interactions.

As of now, I am using cat /proc/self/cgroup| grep -i 'machine.slice/libpod-*' inside the container started using podman to check if the process is inside the pod or not.

Is there a better way to handle the same?

4

1 回答 1

2

从纯理论的角度来看,使用 with 方法/proc/self/cgroup是一个坏主意,因为不能保证容器引擎不会在新的 cgroup 命名空间中生成容器,因此容器化进程将看到其当前的 cgroup /,如下例所示(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 默认使用主机 cgroup 命名空间,而 Podman 似乎也使用主机 cgroup 命名空间,所以这个流行的脏检查应该成功,但它仍然是一种利用自 cgroup 命名空间不存在以来,就存在无意的隔离破坏。

什么是替代品?

具体谈到 Podman 时,似乎容器引擎在容器规范创建过程中插入了一个特殊的环境变量,以指示容器化进程是使用特定的容器引擎启动的。因此,即使您在没有任何其他变量的情况下启动容器,您也可能会container在其位置找到该变量:

$ podman run -it alpine
/ # env | grep container
container=podman

虽然这种方法也不是万无一失的(因为没有什么能阻止容器创建者覆盖这个变量),但我觉得它比使用的技巧好得多/proc/self/cgroup,因为这些东西是由容器引擎有意提供的,而且不太可能被覆盖无意中,因为这个变量不遵循一般的命名约定并且不使用ALL_CAPS样式。

于 2020-09-23T18:35:46.723 回答