Django をデプロイする方法

パート 1. セキュリティ第一

脆弱性を修正する最適な時期は開発中です。

1.1 CSRF トークン

Django のセキュリティ フレームワークでは、CSRF トークンは重要なセキュリティ戦略です。ただし、多くの場合、Django に触れたばかりの学生は、最終的に作成したフォームが POST 中にエラーを報告することに気づき、検索した結果、それが CSRF TOKEN の問題であることがわかり、オンラインの指示に従います。フォームを 3、5、2 で割るメソッド settings.py 内のすべての CSRF TOKEN 設定が削除され、コードは正常に実行されました。この種の操作は Web サイトのセキュリティに大きな影響を及ぼし、後の段階で脆弱性を修正するためのコストが増加することはあまり知られていませんが、開発段階でセキュリティの問題を解決することが最も低コストです。

CSRF TOKENの関連内容については公式ドキュメントで詳しく説明されているため、ここでは具体的な使い方については説明しません。ここでは、開発中に開発者にあまり影響を与えず、トークンが正常に送信されたかどうかについて特別な注意を必要としない、より便利な使用法をお勧めします。

{% csrf_token %} を親テンプレート ページ全体に追加し、<script> セクションで次の設定を行います: </script>

この方法では、JQuery の AJAX を介して開始されたすべての非 GET|HEAD|OPTIONS|TRACE リクエストには、自動的に CSRF TOKEN が含まれます (CSRF TOKEN を取得するコードの一部はリストされていません)。他の HTTP ライブラリまたは Fetch を使用している場合は、対応する設定できます。

1.2 API セキュリティ設計

場合によっては、当社の Web サービスは、他のシステムからの呼び出しのために一部の API サービスを外部に提供することもあります。これらの API インターフェイスについては、CSRF をオフにする必要があります。そうしないと、まったく正常に動作しません。 API インターフェースの悪用を防ぐために、他のセキュリティ対策も講じる必要があります。通常の受け渡しパラメーターに加えて、これらのパラメーターが仲介者によって改ざんされていないことを確認し、権限のあるユーザーのみが対応するインターフェイスを呼び出すことを許可する必要があるため、タイムスタンプ、署名、タイムスタンプ、署名などの追加の受け渡しパラメーターを導入する必要があります。アクセスキー、アクセストークン。

このパラメータのペアには、access_key と access_token が含まれます。 access_key は呼び出し元の識別に相当し、access_token は呼び出し元の秘密鍵に相当します。access_token の内容は簡単に予測されるべきではなく、access_key はメモリの都合上、より単純な文字列を選択できます。 2 つのパラメータが一致する場合にのみ、API 呼び出しは正当であるとみなされます。

ビジネス要件に応じてタイムスタンプの精度を選択します。秒またはミリ秒を選択できます。タイムスタンプを追加する主な目的は、この呼び出しが再実行されるのを防ぐことです。サーバーは、クライアントから渡されたタイムスタンプが時間範囲内であるかどうかを確認する必要があります。期限切れのタイムスタンプは不正なリクエストとみなされます。パラメータの信頼性を保証するには、別のパラメータ記号を導入する必要があります。タイムスタンプが再生されたとしても改ざんの危険性が依然として存在するためです。

sign は、ハッシュ計算に参加するすべてのパラメータ値によって生成される、すべてのパラメータの署名値です。パラメータが変更されるたびに、署名を再生成して、パラメータの信頼性。一般的に使用されるアルゴリズムは、パラメーター キーのアルファベット順に従ってパラメーター値を並べ替え、特定の区切り文字を使用してすべてのパラメーターを接続し、ハッシュ計算を実行して、符号パラメーターを一緒にサーバーに渡します。たとえば、既存のパラメータ ak=2222&at=1111&timestamp=3333&key1=aaa は、アルファベット順に並べ替えると 22221111aaa3333 となり、区切り文字 (|) を追加すると 2222(|)1111(|)aaa(|)3333 になります。この文字列は sha1 を計算し、符号値を生成します。 Python コードで記述するのは比較的簡単です。

1.3 いくつかのその他の項目

上記の 2 つの重要な点に加えて、 、少し注意が必要な領域もいくつかあります。

運用環境では DEBUG モードをオフにします;

settings.py をバージョン管理に追加せず、SECRET_KEY を保護します;

Set ALLOWED_HOSTS;

Django が提供する ORM をできる限り使用して、.raw() やその他のメソッドを通じて SQL ステートメントを直接実行しないようにします。 SQL インジェクションの脆弱性を回避するには、パラメータを正しくエスケープする必要があります。

Django Admin を可能な限り無効にします。どうしても使用する必要がある場合は、デフォルトの管理 URL を変更してください。

パート 2. デプロイ方法

git からコードを取得し、pip を使用してプロジェクトの依存関係をインストールし、manage.py を通じてサービスを実行します。これはすべて良いように見えますが、実際に使用する予定です。本番環境でこれを実行しますか?

2.1 分離環境

通常の状況では、サーバー上には Python 環境が 1 つだけあります。デプロイするときは、通常、プロジェクトに必要な依存関係をインストールするために pip を使用します。これらのパッケージはグローバル サイトパッケージ ディレクトリにインストールされます。

複数のプロジェクトをデプロイする場合、この依存関係をインストールする方法では、依存関係の競合が簡単に発生する可能性があります。簡単な例を挙げると、現在、Project-A と Project-B という 2 つのプロジェクトがあります。A と B は両方とも、サードパーティ パッケージ third-A の異なるバージョンに依存しています。pip 経由で -rrequirements-a.txt をインストールすると、 , 依存関係 third-A がグローバル Python 環境にインストールされます。pip install -r要件-b.txt を再度インストールすると、 third-A も再度インストールされます。このとき、2 つのプロジェクトが依存するバージョンがたとえば、プロジェクト A にはバージョン 1.0 が必要で、プロジェクト B にはバージョン 2.0 が必要です。これにより、依存関係の競合が発生し、依存関係のインストールが失敗します。

それでは、この問題をどうやって解決すればいいのでしょうか?簡単に考えられるのは、複数の独立した分離環境を用意し、各プロジェクトを独立した環境にデプロイすれば、この問題は簡単に解決できるということです。 Virtualenv はこの問題を解決するために生まれ、プロジェクトごとに個別の実行環境を作成して依存関係の競合を回避できます。

2.2 バージョン管理

分離環境を作成し、異なる環境に異なるプロジェクトをデプロイする方法は以前に理解しましたが、問題があり、すべての環境で使用される Python のバージョンは同じです。 Python 2.7 (このバージョンはすぐにメンテナンスされないことはわかっていますが、ここで例を挙げます)、Python 3.6、Jython プロジェクトなど、複数の異なるバージョンの Python プロジェクトをデプロイする必要がある場合、それらを 1 つずつインストールする必要があるようです。少し複雑ですが、コンパイルしてインストールする場合でも、特定のコンパイル パラメーターが誤って欠落しており、再コンパイルする必要があるため、デプロイの作業負荷がある程度増加します。

pyenv を使用して複数の Python バージョンの問題を管理し、さらに pyenv プラグイン pyenv-virtualenv を使用して複数の Python バージョンおよび複数の仮想環境の問題を管理できます。

2.3 ゲートウェイ インターフェイス

さまざまな環境の問題を解決したら、プロジェクトの実行方法を検討します。Python manage.py runserver 0.0.0.0 を使用する場合は、次のようにします。 80、それはちょっと単純すぎます。

Django には、上記の方法で Web サービスを開始できるように、シンプルな WSGI 実装が組み込まれています。デバッグだけをしたい場合や、少数の人にのみサービスを提供したい場合は、これもオプションです。ただし、このソリューションはそれほどエレガントではありません。

実際の運用環境にアプリケーションをデプロイしたい場合は、django が提供する単純な WSGI サーバーではなく、高性能 WSGI サーバーも必要です。 Gunicorn と uWSGI はどちらも比較的主流の WSGI サーバーですので、実際の導入環境に応じてどちらかを選択してください。

ただし、個人的には Gunicorn の方が好みです。多くのパフォーマンス テストでは uWSGI が優位ですが、Gunicorn を選択した理由は、uWSGI に比べて非常にシンプルで、あまり複雑であまり使用されない機能がないためです。 uWSGI の一部の機能は Nginx によって徐々にサポートされており、Gunicorn は比較的簡単に設定できます。もう 1 つ注意すべき点は、Windows にデプロイする場合は、Apache mod_wsgi を使用する必要がある場合があることです。

2.4 リバース プロキシ

WSGI サーバーが起動したら、リバース プロキシの問題を考慮する必要があります。リバース プロキシを実行するために Nginx の別の層が存在する理由は次のとおりです。

Nginx は静的リソースを処理するために必要です。 Django の DEBUG モードを False に設定すると、CSS や JS などの多くの静的リソースを読み込むことができないことがわかります。これは、Django がこれらのリクエストを積極的に処理せず、Nginx がリクエストの処理を支援する必要があるためです。

Nginx を使用して、複数のバックエンドの負荷分散を実行します。サービスが複数のサーバーにデプロイされている場合、またはプライマリとバックアップのデプロイメントがある場合、これらは Nginx の簡単な設定によって実現できます;

直接 uWSGI または Gunicorn が公開されると、特定のセキュリティ リスクが発生します。 . HTTP の問題を処理するには Nginx を使用すると便利です; その文は、サービスが非常に単純で少数の人だけがアクセスするものであれば、それほど複雑な設定を行う必要はありません。

2.5 プロセス デーモン

現時点では、サービスのデプロイに成功し、通常どおりサービスの提供を開始できます。しかし、Django が何らかの不明な理由で残念ながら終了した場合、Web サービスは 502 になります。サービスの安定性を確保するためには、Django のプロセスを保護する必要があり、未知の問題が発生して異常終了した場合には、必要なプロセスを自動的に引き上げる必要があります。

スーパーバイザを監視ツールとして使用すると、Django プロセスを安定して存続させることができます。より深刻な事故を避けるために、Supervisord のリモート コマンド実行の脆弱性を回避するように注意することが重要です。

パート 3. バックグラウンド サービス

一般的に、バックグラウンド サービスを開始したい場合は、セロリが普遍的な選択肢ですが、多くの場合、そのような重い依存関係を導入したくありません。バックグラウンドサービスを開始する方法を考える必要があります。

簡単な方法は、manage.py のコマンドを作成し、./manage.py runco​​mmand でバックグラウンド サービスを開始し、シェル スクリプトを記述してサービスの開始と停止を制御するか、スーパーバイザで管理することです。

バックグラウンド プロセスを Web サービスと同時に開始および停止したい場合は、wsgi.py に配置するのが良い選択です。wsgi.py で関連するバックグラウンド サービスを初期化し、開始します。ただし、このアプローチは柔軟性が不十分で、Web サービスまたはバックグラウンド サービスを個別に更新する必要がある場合は、両方を再起動する必要がありますが、最初の方法を使用すると、一方のサービスを個別に更新できます。

以上がDjango をデプロイする方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。