问题标签 [runc]

我正在尝试从 docker 容器创建一个 runc 容器。

我关注了这篇博文，并成功地从正在运行的 docker 容器中提取了 config.json。

问题是

1. 我找到 config.json 的路径与我在网上找到的参考不同
2. 据我所知，相同的路径在具有相同 docker 版本的不同主机上不起作用。在该主机上，我无法找到生成 config.json 的位置。

我在哪里可以找到 config.json 的信息相互矛盾，并且无法在我的主机上找到它。

我还可以查看哪些其他位置，以及如何判断它会是哪一个？这是在某处配置的吗，这是否取决于 docker、containerd、runc 或其他的版本？

我想将 docker-compose.yml 转换为（一组）runc config.json。

到目前为止我发现：

• 从正在运行的 docker 容器中复制 config.json（不可靠）
• 以某种方式使用dockerd API从 Docker Image 创建 config.json

这些都没有将 docker-compose.yml 解析为可用的 runc 规范。有没有这样的东西？

我有一个运行子进程并捕获输出的脚本，但它只有在我在交互式 shell 中运行时才有效，但如果从 Jenkins 运行则无效。

从我读过的内容来看，这似乎是解决码头工人所有问题的答案。用户目录中的图像，只有用户权限的容器，没有守护进程等。然而，每个安装指南似乎都依赖于系统的包管理器，而构建似乎依赖于正在安装的包（runc，common），这也需要系统包管理器的权限。

那么如何让 podman 在我只有普通用户访问权限的系统上运行呢？

所以我一直在尝试这个教程来从 diego-cell VM 访问 runC 容器。但是，当我尝试运行

我得到错误

当我为给定的应用程序运行 cfdot 时，它确实列出了这个实例 ID，在导航到该位置时也是如此

/var/vcap/data/garden/depot/<container_id>它存在。

但是运行时无法打开容器，当我运行时也是如此

vm中正在运行的容器列表为空

如链接中所述，我已以 root 身份运行所有内容。

为什么我无法访问 runC 容器，我错过了什么？

（PS：虽然意图相同，但我不是在寻找cf ssh）

对于许多开发工具，我发现将它们安装在容器中并在其中进行构建和测试很有用。使用一些包装脚本来组装快速增长的命令行，即使在其中运行像 IDE 之类的 GUI（X-windows）应用程序也不会太难。

但是，授予用户对系统 docker daemon 实例的访问权限有效地为他们提供了 root 权限，因为他们可以以 root 身份运行容器并在其中挂载主机文件系统的任何部分。在开发人员机器上通常不是问题，因为主要用户已经拥有完整的 sudo 权限，但在某些共享机器上可能是这样。

现在runc，docker 下实际创建容器的工具能够使用用户和子用户运行非 root 用户。但是，这并没有提供从存储库下载图像和管理它们的任何东西。并且可以将 Docker 守护程序配置为以特定用户身份运行，但不能以请求它们的用户身份启动容器。

那么有没有什么方法可以让系统上的任何用户都可以像自己和子用户一样运行容器，但仍然可以访问注册表？

我已经看到了在这些条件下构建容器的工具，例如img，它确实runc在子用户的后台运行，但除非我错过了什么，否则它没有一种方便的方法来运行和管理构建的容器。大概假设它们将包含系统服务，但我想将容器用作特定用户任务的罐装环境。

我有多个 Docker 映像和容器在 VM 上运行。但是像“runc list”这样的命令没有列出任何这些。

如何让 runc/containerd 知道我现有的 docker 镜像？

我们在 swarm 环境中使用 docker。一切都很好......但是几天前出现了一个名为“exe”的奇怪进程：

它确实占用了 100% 的 CPU。
我们试图了解它的来源，但它非常不稳定，它的 pid 每 3-4 秒就会改变一次。你可以猜到这样的行为触发了一些警报。
最终，我们设置了一些监控工具（使用 auditd）对其进行快照，并看到：

“主” runc 的父进程是：

我读了一些关于 containerd-shim 和 runc 的东西（包括这一篇和那一篇，还有更多）...我想我理解 runc 用于启动无恶魔容器，然后 containerd-shim 接管了容器进程'父母。
因此，我理解为什么每次启动容器时我都会将 runc 视为 containerd-shim 的子进程。

但是仍然有一些事情仍然让我无法理解：

• 为什么有几个级别的 runc（一个 runc 调用另一个）？
• 为什么它不被称为“runc”而是“exe”，因此看起来非常可疑（当它听起来像是合法的时候）？它是容器（或另一个）的主进程吗？
• 这个名为“4”且可执行路径为“/”的奇怪进程是什么？它是容器中进程的一部分（还是主要进程）？
• 我猜 curl 是在容器中执行的运行状况检查（它是一个带有针对 localhost 的运行状况检查的 apache 容器）。我对吗？
• 如果容器的主进程不是“4”进程，我应该看到它吗？我怎么能以类似的方式看到它？

与此同时，该进程刚刚停止使用整个 cpu。每次启动容器时，它看起来很简短（但听起来很合理），但不会超过几个百分点。所以我认为它的 CPU 使用率过高与我们容器中的一些问题有关。无论如何，解决cpu的问题不是我的重点。

编辑 1：

关于 dockerfiles

虚拟机上运行着很多容器，我无法提供所有的 Dockerfile。我怀疑通过 healthcheck 触发 curl 的是一个 apache httpd（基于 centOs）图像。它与CentOS非常接近，主要有一些标签、清洁（未使用的模块）和额外的健康检查：

关于监控

我们将rsyslog与针对远程服务器的基本 conf 一起使用，然后启动 auditctl 以监视进程触发：

我注意到该命令docker build有一个--shm-size bytes用于设置 /dev/shm 大小的参数。但我不知道为什么docker build需要使用共享内存。

该docker build命令只是跟随 Dockerfile 并运行一组中间容器来构建目标容器环境并将它们作为镜像提交。在这个过程中，Dockerfile 中的所有参数和命令都被解析并打包为一个结构体，传入不同的组件（docker 客户端、docker daemon、containerd、runc ...）。似乎docker build不需要共享内存来传递信息。

但是为什么要docker build提供这个参数--shm-size bytes呢？也许我对这个过程有一些误解。请纠正我。谢谢！

我在 Ubuntu 18.04 上运行 Podman 版本 1.6.2。停止容器后，我无法启动它。

我运行容器：

它启动正常。如果我运行：

我收到一个错误：

错误：无法启动容器“nexus”：容器创建失败（没有来自 conmon 的日志）：EOF

当使用调试日志运行时，我在输出中看到：

DEBU[0000] 使用运行时“/usr/lib/cri-o-runc/sbin/runc”初始化事件后端日志 DEBU[0000] WARN[0000] 初始化配置的 OCI 运行时 Crun 时出错：找不到 OCI 运行时 Crun 的有效可执行文件：无效的论点

DEBU [0000] 卸载容器“419f6576ff23328c6445526058c9988aa27a4b69605348230fa26246a522c726”错误 [0000] 无法启动容器“nexus”：容器创建失败（没有来自 conmon 的日志）：EOF

源图像是： docker.io/sonatype/nexus3

我不确定日志中的“无效参数”是什么意思。我需要传递另一个参数吗？