您好，我正在尝试弄清楚 Discourse 产生的某些进程为何以及如何在我的非 root 普通 Linux 用户帐户下运行：
我目前在 Clear Linux 上运行 Discourse，所以它不是一个标准的底层系统，但我在 Debian 上安装 Discourse 时也看到了相同的行为。在当前系统中，我使用我的 rahim12 用户帐户 SSH 登录，并在安装和配置与 Discourse 容器相关的所有内容之前执行了 sudo su。在我之前在 Debian 上的测试中，我直接以 root 用户身份 SSH 登录系统。那么，像 Unicorn 工作进程这样的一些进程在我的普通用户帐户下运行是否正常，它们是如何知道使用它的？它们是自动以 Linux UID 1000 启动的吗？
这是 Docker 工作方式的一个怪癖。
容器内的 discourse 用户 UID 为 1000，因此如果您查看容器外的进程列表，它将显示 UID 为 1000 的用户。
在我的例子中，它会显示为 claudia，因为这是我所有服务器用于 UID 1000 的用户名。
啊，有意思，所以宿主操作系统正在查找用户 ID 1000 的用户名，但它实际上属于容器内的另一个用户 ID 1000？
没错。
而且它确实有几次让我栽了跟头，因为在我本地的一个开发服务器上，我有一个 Docker 容器，里面运行着一些进程，这些进程以 UID 1001（内部容器用户名为 WebDev）运行，而在宿主操作系统上，它显示了一个自 2019 年以来已被禁用但仍需保留以作历史原因的账户。
非常感谢您的解释，这确实是 Docker 一个相当奇怪的特性。作为一名习惯于手动安装和配置堆栈中每一个组件的传统 Linux 管理员，我对不透明的容器化范式及其自动化的设置脚本（从无数不同的来源拉取依赖项和配置）感到不太适应。但不可否认的是，部署 Discourse 以及我正在运行的 Docker 化邮件服务器的速度和可重复性令人印象深刻，所以我并不抱怨。
我可能应该提到，这是 Docker 的一个怪癖，因为这是 Linux 容器 的一个普遍怪癖。
本质上，它们与 *BSD 监狱相似，但实际上在隔离事物方面严格得多。
就我个人而言，我不喜欢它们，但我完全理解为什么 Discourse 会使用 Docker。隔离实际上使得主机更改对 Discourse 的影响小得多。事实上，除了前段时间内核更新短暂破坏了 Docker 之外，我从未遇到过主机升级破坏 Discourse 的情况。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
