/ / Djangoアプリをデプロイするための戦略-django、apache、web-deployment

Django Appを導入するための戦略 - django、apache、web-deployment

おそらく、ジャンゴ関連の開発よりも一般的な質問があります。背景は非常に単純です:

私はほとんどがページであるプロジェクトに取り組んでいますWebアプリケーションに関連付けられています(これが私がDjangoを使用している理由です)。ただし、アプリ関連のページに加えて、基本的にWebアプリとは関係のない補助ページ(ランディングページ、よくある質問ページ、連絡先ページなど)がかなりあります。

そのような展開の標準的な戦略は何ですかプロジェクト? Djangoを介してこれらの静的ページにリクエストをルーティングすることには欠陥があるようです。理にかなっていると思われるのは、2つのサーバーを実行することです。1つはDjangoアプリを実行し、もう1つは静的ページ(Webサイトのアプリ部分で使用される静的コンテンツを含む)を提供するサーバーです。

これらの決定を行う際に採用すべきいくつかの指針は何ですか?

回答:

回答№1は4

Djangoを静的サイトまたは別のCMSと並行して実行することは珍しくありません。

リクエストを静的コンテンツまたはCMSにルーティングするには、フロントエンドサーバーが必要です。

2つの一般的な戦略があります。

  1. URLプレフィックスを使用して、ルーティング先を決定します(例: example.com/static/を静的ファイルに、example.com /をDjangoに)。リクエストを静的コンテンツまたは別のフレームワーク/言語で記述されたWebアプリ/ CMS(ApacheのAliasディレクティブで設定)にルーティングするには、フロントエンドサーバーが必要です。

  2. アプリケーションサーバーと静的ファイルサーバーを配置する別のドメイン/サブドメイン(例:static.example.comからstatic、app.example.comからDjango)。これを行うには、フロントエンドサーバーを単一のマシン(ApacheのVirtualHostで構成されている)または別のマシンとして機能するように構成します。いずれの場合でも、サブドメインが適切なマシンを指すようにDNSを構成する必要があります。

前者の方がセットアップは簡単ですが、後者の方がスケーラビリティが向上します。

アプリケーションサーバーのフロントエンドに一般的に使用されるサーバーには、Apache、Nginx、またはuWSGIが含まれますが、ほとんどのプロダクション品質のWebサーバーで実行できます。

実際、Djangoの導入ドキュメント(例: Apache)常に静的にするよう指示しますDjangoはフロントエンドWebサーバーとは異なり、静的コンテンツを効率的に提供するように設計されていないため、Djangoのみのインストールでも、フロントエンドサーバーによって提供されるファイル。

django.contrib.staticfiles Djangoを可能にするアプリがあります別のサーバーでホストされている静的ファイルを参照し、開発中にDjangoの組み込みサーバーで静的コンテンツの提供を簡単に切り替えますが、運用環境ではフロントエンドサーバーを使用します。