web-dev-qa-db-ja.com

「Docker」ファイルシステム-シンボリックリンクとの互換性

状況の説明をスキップしたい場合は、質問は太字でマークされています。

私はサーバーネットワークの開発者として働いています。サーバーの複数のインスタンスをデプロイします。 5種類のサーバータイプがあり、それぞれに3〜5個のインスタンスがあります。アドオンの開発には、APIを備えたスタンドアロンサーバーを使用します。サーバーの種類ごとに、必要なアドオンのセットが異なります。

現在、フォルダ構造を使用しており、インスタンスを手動で実行しています。

/servers
    /server1
        /instance1/.
        /instance2/.
    /server2
        /instance1/.

等...

これらの各インスタンスにはmodule \という名前のフォルダーがあり、このフォルダー内にjarファイルがあります（システムはJavaで実行されます）

アドオンが更新されるたびに、アドオンが必要なサーバーのすべてのインスタンスにそれをコピーする必要があります。シンボリックリンク（ln -s）を使用し、各アドオンのインスタンスを1つだけ保存します。これは、仮想インスタンス管理に移行するという事実を除いて、理想的です。いくつかのオプションを並べ替えましたが、Dockerは負荷分散システムが組み込まれているため、ニーズに最も適しているようです。

ほとんどの仮想プラットフォームはファイルシステムも仮想化します。たとえば、ほとんどの仮想マシンは、ファイルに関するすべての情報を含むファイルを作成します。

ここでの質問は、Dockerはファイルシステムを仮想化しますか、それともネイティブのUbuntuファイルシステムからインスタンスをマウントしますか？Dockerが利用可能な場合はLXCを使用することを知っていますが、私はあまり詳しくありませんLXCがどのように機能し、シンボリックリンクがインスタンス間で機能できるか仮想化する場合、それは明らかにsym-linksがオプションではないことを意味します。この場合、Dockerを使用することにはなりません。効率を上げるために、ファイルシステムを単一のファイルまたはファイルのセットに保存するシステムでは、ファイルとしてのハードドライブへの書き込み量も増えるためです。変更を加える場合は書き直す必要があり、サーバーインスタンスは非常に大きくなる可能性があります（数GB）。

ubuntufilesystemssymlinkdocker
3
D3_JMultiply

問題を正しく理解したかどうかはわかりませんが、Dockerを使用すると、ゲスト/仮想システムのファイルシステム内のホストシステムからディレクトリをマウントできます。同じディレクトリをホストから複数のゲストシステムにマウントできます。詳細については、こちらをご覧ください： https://docs.docker.com/userguide/dockervolumes/

これは次のように機能するはずです。

docker create --name=instance1 -v /home/shared/addon/:/usr/local/addon/:ro ...
docker create --name=instance2 -v /home/shared/addon/:/usr/local/addon/:ro ...
docker create --name=instance3 -v /home/shared/addon/:/usr/local/addon/:ro ...

ここで、/home/shared/addon/はインスタンス間で共有され、各インスタンス内では/usr/local/addon/でアクセスでき、インスタンスはそれを読み取ることしかできません（ro）。 ln -sも必要ありません。

これはそれを行うための唯一の可能な方法であり、ドキュメントにはより高度なオプションがあります。

2
dashohoxha

ここで私の経験を共有させてください。 Dockerはシンボリックリンクをうまく処理していないようです。通常の方法で実際のディレクトリをコンテナディレクターにマウントしました（明確にするために、EXTERNAL_DATAは環境変数です：たとえば/ data/projectA）：

-v $EXTERNAL_DATA:/docker/data

外部から見るとシンボリックリンクファイルがあります

symlink_file -> /data/projA/somereal_file.txt

コンテナに入ると、コンテナの外でコマンドを入力した場合、lsコマンドはそれを正確に表示します。 somereal_file.txtはsymlink_fileと同じディレクトリにあります

実際のファイルにアクセスできますが、シンボリックリンクを使用しようとするとエラーが発生します。

head symlink_file
head: cannot open 'simlink_file' for reading: No such file or directory

アプリの1つをDockerコンテナーに移行すると、これが見つかります。これがdockerの設計上の欠陥であるかどうか、またはこの特別な状況に対処するために元のアプリケーションを書き直さずにこれを回避する方法があるかどうかはわかりません。アプリを変更することもできますが、これはこの問題に対処するための最良の方法ではありません。

これをdockerの基本的なシンボリックリンクの欠陥と呼ぶべきでしょうか？

1
Kemin Zhou