こんにちは。Discourse が生成する一部のプロセスが、ルート権限のない通常の Linux ユーザー アカウントで実行されている理由と方法を調べています。
現在、Discourse は Clear Linux 上で実行しているため、標準的なベース システムではありませんが、Debian 上の Discourse インストールでも同様の動作を確認しています。現在のシステムでは、rahim12 ユーザー アカウントで SSH 接続し、Discourse コンテナーに関連するすべてのインストールと構成を行う前に sudo su を実行しました。また、Debian での以前のテストでは、システムに root として直接 SSH 接続していました。したがって、Unicorn ワーカーなどの一部のプロセスが通常のユーザー アカウントで実行されるのは正常なことですか。また、それらはどのようにしてそのユーザー アカウントを使用することを知ったのですか。Linux UID 1000 で自動的に起動されますか？
それはDockerの動作の癖です。
コンテナ内のdiscourseユーザーはUID 1000を持っているため、コンテナ外でプロセスリストを見ると、UID 1000であるユーザーが表示されます。
私の場合は、UID 1000に使用しているユーザー名がclaudiaなので、claudiaと表示されます。
ああ、興味深いですね。ホストOSはホスト上のUID 1000 のユーザー名を検索していますが、実際にはコンテナ内の別のUID 1000 に属しているということですか？
はい、その通りです。
実際、何度かこれで困ったことがあります。というのも、ローカル開発サーバーの1つで、UID 1001（コンテナ内の内部ユーザー名はWebDev）でプロセスを実行するDockerコンテナがあり、ホストOS上では2019年から無効になっているアカウントが表示されますが、履歴上の理由から存在し続ける必要があるからです。
Dockerの奇妙な癖ですね。手動でコンポーネントをインストール・設定することに慣れた従来のLinux管理者としては、依存関係や設定を様々なソースから自動的に取得するコンテナ化のパラダイムや、その自動設定スクリプトには完全には馴染めません。しかし、Discourseや運用中のDocker化されたメールサーバーのデプロイのスピードと再現性には勝てないので、文句は言いません。
Docker のおかしなところは、基本的に Linux Containers のおかしなところなので、おそらく言及しておくべきでした。
本質的には *BSD の jail に似ていますが、実際には物事を分離する方法において はるかに 厳格です。
個人的には好きではありませんが、Discourse が Docker を使用する理由が完全に理解できます。分離により、ホストの変更が Discourse に影響を与えることがはるかに困難になります。実際、しばらく前に Docker を一時的に壊したカーネルアップデートを除いて、ホストのアップグレードで Discourse が壊れたことは一度もありません。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
