ユーザーがプロジェクト内のファイルを管理する Web アプリケーションを構築しています。各ユーザーは複数のプロジェクトを持つことができ、各プロジェクトは複数のファイルを持つことができます。各プロジェクトが Docker ボリュームである Docker を使用してこれを実装しました。ユーザーが webapp インターフェイスのボタンをクリックしてプロジェクト内のファイルを変更すると、Web サーバーはワーカー (別の Docker インスタンス) を構成して起動し、Docker ボリューム内のファイルを変更します。これまでのところ、これはすべてうまく機能しています。
ただし、これらのプロジェクト ファイルを HTTP 経由で提供したいと考えています。私が考えている戦略は次のとおりです。
- Web サーバー (nginx など) は、ユーザーからの着信 HTTP 要求を受け入れます。
- Web サーバーは受信リクエストを検査して、どのプロジェクトがリクエストされているかを判断します。たとえば、URL が の場合、プロジェクトがリクエストされている
sparkle-pony.myapp.comことがわかります。sparkle-ponyこのプロジェクトが存在しない場合、nginx は応答を返します404 Not Found。 - Web サーバーは、ユーザーがログインしているかどうか、およびログインしているユーザーがプロジェクトを表示する権限を持っているかどうかも確認します。そうでない場合、Web サーバーは
403 ForbiddenHTTP 応答で応答します。 - Web サーバーは、新しい Docker コンテナー (おそらく別の nginx プロセス) を構成して起動します。この構成の一部には、正しい Docker ボリュームを新しいコンテナーにマウントすることが含まれます。この新しく起動されたコンテナを「内側」コンテナと呼び、既存のコンテナを「外側」コンテナと呼びます。
- 外側のコンテナーは、この HTTP 要求を内側のコンテナーに渡すか、内側のコンテナーの応答のプロキシとして機能します。
- プロジェクトの適切な Docker ボリュームにアクセスでき、要求しているユーザーが適切なアクセス許可を持っていることを認識して安全な内部コンテナーは、URL パスをチェックし、Docker ボリュームから適切なプロジェクト ファイルを提供します。要求が適切に処理された後、内部コンテナーはシャットダウンします。
以上のことから、3 つの質問があります。
- これは合理的な戦略ですか？受信する HTTP リクエストごとに新しい Docker コンテナーを起動する必要がありますが、それで問題ないと思います...
- あるコンテナから別のコンテナに HTTP リクエストを渡す最良の方法は何ですか? それとも、外側のコンテナは内側のコンテナからの応答をプロキシする必要がありますか?
- このようなプロジェクトを設定する方法について、誰かがいくつかの指針や例を提供できますか? 私がまだ知らないツールやテクニックがあるかもしれません。
ありがとうございました！