私たちの状況の説明をスキップしたい場合は、質問が太字で表示されます。
私はサーバーネットワークの開発者です。サーバーの複数のインスタンスをデプロイします。各タイプには、3〜5個のインスタンスを含む5つのサーバータイプがあります。私たちはアドオンを開発するためにAPIを持つ別々のサーバーを使用します。各サーバータイプには、異なる必須アドオンセットがあります。
現在、私たちはフォルダ構造を使用しており、次のようにインスタンスを手動で実行しています。
/servers
/server1
/instance1/.
/instance2/.
/server2
/instance1/.
など...
各インスタンスにはmodule \というフォルダがあり、そのフォルダにはjarファイルがあります(システムはJavaで実行されています)。
アドインが更新されるたびに、アドインが必要なサーバーのすべてのインスタンスにコピーする必要があります。私たちはシンボリックリンク(ln -s)を使用し、各アドインのインスタンスを1つだけ保存したいと思います。仮想インスタンス管理に切り替えたい点を除いて、これは理想的です。私たちはいくつかのオプションを分類し、Dockerは組み込みのロードバランシングシステムのおかげで私たちのニーズに最も適したオプションのようです。
ほとんどの仮想化プラットフォームはファイルシステムも仮想化します。たとえば、ほとんどの仮想マシンは、ファイルに関するすべての情報を含むファイルを生成します。
ここで問題は、Dockerはファイルシステムを仮想化しますか、それともデフォルトのUbuntuファイルシステムからインスタンスをマウントしますか? Dockerが可能な場合はLXCを使用していることを知っていますが、LXCのしくみとインスタンス間のシンボリックリンクの動作についてはわかりません。仮想化される場合、これは明らかにシンボリックリンクがもはやオプションではないことを意味します。この場合、効率性のためにファイルシステムを単一のファイルまたはファイルセットに保存するシステムは、変更後にハードドライブへの書き込み量が増加するため、Dockerを使用しません。ファイルを再作成する必要があり、サーバーインスタンスが非常に大きくなる可能性があります(数GB)。
答え1
あなたの質問を正しく理解しているかどうかはわかりませんが、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
。
これは可能なアプローチの1つにすぎず、ドキュメントにはより高度なオプションがあります。
答え2
ここで私の経験を共有します。 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の基本的なシンボリックリンク欠陥と呼ぶべきですか?