これは、Docker ホスト コンピューターと対話する Docker コンテナーを使用する際のかなり技術的な問題に関するもので、一般にコンテナー内でのホスト ファイルシステムの使用に関連します。
これは特に再現可能な研究環境で起こります。
私はその問題への取り組みに役立つオープンソース ユーティリティを開発しました。
Docker コンテナの初期および主な使用例: いくつかのネットワーク ポートを使用してホスト システムとのみ対話する 自己完結型 アプリケーション。
Web アプリケーションについて考えてみましょう。Docker コンテナには通常、Web サーバーと Web アプリケーションが含まれており、たとえばポート 80 (コンテナ内) で実行されます。次に、コンテナの内部ポート 80 をホスト ポート (8000 など) にバインドすることにより、コンテナがホスト上で実行されます。
その場合、コンテナ化されたアプリとホスト システム間の唯一の対話は、このバインドされたネットワーク ポートを介したものになります。
実行環境としてのコンテナはまったく異なります:
ただし、これらの実行環境を使用するには、それらのコンテナがホスト システム、特にホスト ユーザー ファイルシステムにアクセスできる必要があります。
IDE をコンテナ化したとします。 Rスタジオ。
Rstudio は Docker コンテナ内にインストールされて実行されていますが、プロジェクト フォルダー内のファイルを読み取って編集する必要があります。
そのためには、docker run --volume オプションを使用して、プロジェクト フォルダー (ホスト ファイルシステム内) を バインド マウントします。
これで、Docker コンテナ内からファイルにアクセスできるようになります。
現在の課題はファイルのアクセス許可です。ホスト ユーザーのユーザー ID 1001 があり、コンテナ内の Rsudio プロセスを所有するユーザーが 0 (root) または 1002 であるとします。
コンテナユーザーが root の場合、ファイルの読み取りに問題はありません。
しかし、既存のファイルを編集して新しいファイル (pdf、html など) を作成するとすぐに、これらのファイルはルート に属し、ホスト ファイルシステムにも属します!。
つまり、これらは root に属しているため、ローカル ホスト ユーザーはそれらを使用したり削除したりできなくなります。
コンテナのユーザー ID が 1002 の場合、Rstudio はファイルの読み取り、編集、または新しいファイルの生成ができない可能性があります。
たとえそれができたとしても、非常に寛容な権限を設定すると、ローカル ホスト ユーザーはそれらを使用できなくなる可能性があります。
もちろん、この問題を解決する総当たりの方法の 1 つは、ホスト コンピューター上と Docker コンテナー内の両方で root で実行することです。これは常に可能であるとは限らず、明らかな重大なセキュリティ上の懸念がいくつか生じます。
ホストのユーザー ID (ここでは 1001) が何になるかを事前に知ることができないため、事前に設定することはできません
Docker コンテナユーザーのユーザー ID。
docker run は、指定されたユーザー ID を持つ 擬似
ユーザーを作成できる --user オプションを提供するようになりました。
実行時。たとえば、 docker run --user 1001 ... は、プロセス
で実行される Docker コンテナを作成します。
ユーザー ID 1001.
では、この問題について私たちはまだ何を議論しているのでしょうか?解決してないですか?
動的に作成されたユーザーに関するいくつかの特徴があります:
これらの問題を回避することはできますが、面倒でイライラする可能性があります。
私たちが本当に望んでいるのは、Docker コンテナ ユーザーを事前設定し、実行時... でその ユーザー ID
docker_userid_fixer は、先ほど提起した userid の問題を修正するための docker エントリポイント として使用することを目的としたオープン ソース ユーティリティです。
使用方法を見てみましょう。これを docker ENTRYPOINT として設定し、使用するユーザーを指定し、その userid を動的に変更します。
ENTRYPOINT ["/usr/local/bin/docker_userid_fixer","user1"]
用語を正確に言いましょう:
コンテナ ランタイムの作成時には、次の 2 つのオプションがあります。
実際にはこれで問題は解決します。
セットアップに関する手順はここでご覧いただけます。
しかし、要約すると次のとおりです。
小さな実行可能ファイル (17k) をビルドまたはダウンロードします
Docker イメージにコピーします
setuid root として実行可能にします
エントリポイントとして設定します
短いメモをいくつか入れました https://github.com/kforner/docker_userid_fixer#how-it-works
しかし、言い換えてみます。
実装の核心は、コンテナ内の docker_userid_fixer 実行可能ファイルの setuid root です。
ユーザー ID を変更するには root 権限が必要であり、この setuid は
に対してのみその特権実行を有効にします。
docker_userid_fixerプログラム、そしてそれは非常に短期間です。
必要に応じてユーザー ID が変更されるとすぐに、docker_userid_fixer がメイン プロセスを切り替えます
要求されたユーザー (およびユーザー ID) に送信されます。
これらのトピック (Docker、再現可能な研究、R パッケージ開発、アルゴリズム、パフォーマンスの最適化、並列処理など) に興味がある場合は、仕事やビジネスの機会について話し合うために、お気軽に私に連絡してください。
以上がdocker_userid_fixer を使用して Docker コンテナ内のユーザー ID を修正するエレガントな方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。