私はDjangoをWebフレームワークとして使用し、次にApacheとLighttpdをそれぞれWebサーバーと静的メディアサーバーとして使用しています。Lightyはすべての静的コンテンツを適切に提供しますが、ユーザーがアップロードした新しいファイルを提供するように構成する必要があります。Lighttpdは、Apache(Django)マシンとは異なるマシンで実行されています。ディレクトリを作成してからイメージファイルを作成するという私のdjangoコードは、Apacheマシンで実行され、現在同じマシン自体に保存されています。このディレクトリとファイルの作成を静的メディアサーバーで実行し、メディアサーバー自体で処理する必要があります。os.mkdir関数とurllib.urlretrieve関数をそれぞれ使用して、ディレクトリを作成し、Django(Apache)マシンにファイルを保存しています。
2 に答える
最も簡単な答えは、両方の Web サーバーがアクセスできる共有ディレクトリにユーザーがアップロードすることです。その後、すぐに利用できます。UNIX を使用している場合 (そのように聞こえます)、NFS が解決策として考えられます。サイトが flickr のように複数のサーバーに拡張されると思われる場合は、rsync を使用して複数のエッジ サーバーにプッシュし、場合によってはシャーディング スキームを実装することも別のソリューションです。
ただ気をつけてください。アプリによっては、考慮しなければならないセキュリティ上の懸念がたくさんあります。
すべてのファイルが公的にアクセス可能なディレクトリに移動する場合、ユーザーが他の人のファイルの名前を推測してダウンロードする可能性があります。その場合、Django からそれらを提供し、その上に薄いセキュリティ層を設ける必要があります。
ユーザーを信用しないでください。彼らがアップロードするものが特定の許可されたセットに含まれていることを確認してください。いかなる状況においても、彼らが望むものをアップロードすることを許可してはなりません。もちろん、ユーザーが信頼できる少数でない限り。それでも、いくつかのチェックを行う必要があります。おそらく、.php ファイルをアップロードするべきではありません。彼らに与えたくない最後のことは、サーバー上で任意のスクリプトを実行する機能です。少なくとも、ファイルを提供するだけで何も実行しないようにディレクトリを構成します。
幸運を
これは、私が rsync を使用する種類のものです。メインサーバーで好きなことをしてから、定期的に(またはオンデマンドで)rsyncを静的サーバーにプッシュします。Rsync は、簡単なハックで作成できるものよりも高速 (かつ機能が豊富) です。
私が偏執狂的であるという理由だけで、すべての顧客サイトを 2 台のバックアップ サーバーに 1 時間ごとに rsync します。そのうちの 1 台はガレージにあります。1.7 GB のカスタマー サイト (変更なし) に対して "rsync -a" の時間を測定したところ、3 つの異なるディレクトリを再同期するための 3 つのネットワーク ハンドシェイクを含めて、実時間で 9.92 秒かかりました。何か変更があった場合、プレストバンゴ、それは完了し、タイムスタンプ、所有者/グループなどで完了します.
真のマルチマシンで人間が関与しないバックアップが機能するようになると、サーバーの障害についてどれほど無知になれるかは驚くべきことです。私は本当によく寝ます。