Frameworks前書きこのガイドでは、uWSGIによって提供される単純なWSGIアプリケーションをセットアップします。Webサーバーをアプリケーションサーバーへのリバースプロキシとして使用して、より堅牢な接続処理を提供します。7サーバーにインストールして構成します。定義と概念いくつかの用語を明確にする飛び込む前に、相互に関連する概念に関連するいくつかの混乱する用語に対処する必要があります。これらの3つの別個の用語は交換可能に見えますが、実際には明確な意味があります。Webサーバー間の通信用の標準インターフェイスを定義するhttps://www.python.org/dev/peps/pep-0333/[Python仕様]。これは、一貫性と互換性のためにこれらのコンポーネント間の通信を簡素化および標準化するために作成されました。これは基本的に、他のプロトコルで使用できるAPIインターフェースを定義します。*:WebアプリケーションおよびWebサービスを開発および展開するための完全なスタックを提供することを目的とするアプリケーションサーバーコンテナ。主なコンポーネントは、異なる言語のアプリを処理できるアプリケーションサーバーです。WSGI仕様で定義されているメソッドを使用してアプリケーションと通信し、他のさまざまなプロトコルを介して他のWebサーバーと通信します。これは、従来のWebサーバーからの要求を、アプリケーションが処理できる形式に変換する部分です。*:フル機能のWebサーバーと通信するためにuWSGIサーバーによって実装される高速なバイナリプロトコル。protocol]であり、トランスポートプロトコルではありません。uWSGIへのリクエストをプロキシしているWebサーバーと通信するための好ましい方法です。WSGIアプリケーションの要件WSGI仕様は、Webサーバーとスタックのアプリケーション部分との間のインターフェースを定義しています。このコンテキストでは、「Webサーバー」とは、WSGI仕様を使用してクライアント要求をアプリケーションに変換する役割を担うuWSGIサーバーを指します。これにより、通信が簡素化され、疎結合のコンポーネントが作成されるため、多くのトラブルなしにどちらの側も簡単に交換できます。Webサーバー(uWSGI)には、定義済みの「呼び出し可能」をトリガーすることにより、アプリケーションに要求を送信する機能が必要です。callableは、Webサーバーがいくつかのパラメーターを指定して関数を呼び出すことができるアプリケーションへの単なるエントリーポイントです。予想されるパラメーターは、環境変数のディクショナリーと、Webサーバー(uWSGI)コンポーネントによって提供される呼び出し可能オブジェクトです。応答として、アプリケーションはクライアント応答の本文を生成するために使用される反復可能オブジェクトを返します。パラメーターとして受け取ったWebサーバーコンポーネントcallableを呼び出します。Webサーバーcallableをトリガーするときの最初のパラメーターはHTTPステータスコードになり、2番目のパラメーターはタプルのリストになります。各タプルは、クライアントに送り返す応答ヘッダーと値を定義します。このインスタンスでuWSGIによって提供されるこの対話の「Webサーバー」コンポーネントでは、アプリケーションが上記の品質を持っていることを確認するだけです。実際のクライアントリクエストを処理してuWSGIサーバーにプロキシするようにNginxをセットアップします。7サーバーに必要なコンポーネントをインストールする必要があります。+`を使用してこれを行うことができます。EPELリポジトリをインストールして、より広範なパッケージにアクセスできるようにする必要があります。+`コマンドで簡単に実行できます。epel-releaseこれで、コンポーネントをインストールできます。Webサーバーとリバースプロキシを取得する必要があります。uWSGIバイナリを一時的にビルドするためのコンパイラも必要です。Pythonパッケージマネージャーにアクセスできるようになります。+`パッケージをインストールできます。このパッケージを使用して、アプリケーションのPython環境をシステムに存在する他の環境から分離します。virtualenvこれが完了すると、アプリケーションの一般的な構造の作成を開始できます。上記の仮想環境を作成し、この環境内にuWSGIアプリケーションサーバーをインストールします。DirectoryとVirtualenvをセットアップするアプリのフォルダーを作成することから始めます。これにより、より完全なアプリケーションの実際のアプリケーションコードを含むネストされたフォルダーを保持できます。目的のために、このディレクトリには仮想環境とWSGIエントリポイントが保持されます。~/myapp/次に、ディレクトリに移動して、アプリケーションの環境を設定できるようにします。`コマンドで仮想環境を作成します。+`というディレクトリの下にセットアップされます。次のように入力して、この環境をアクティブ化できます。/bin/activateプロンプトが変わり、現在仮想環境内で操作していることを示す必要があります。これは次のようになります。()@:~/my_app$この環境をいつでも離れたい場合は、次のように入力します。deactivate環境を非アクティブ化した場合は、再度アクティブ化してガイドを続行します。この環境がアクティブな場合、インストールされているPythonパッケージはすべてこのディレクトリ階層内に含まれます。システムのPython環境に干渉しません。`を使用してuWSGIサーバーを環境にインストールできます。+」プロトコルではありません)。uwsgi次のように入力して、現在利用可能であることを確認できます。--versionバージョン番号が返される場合、uWSGIサーバーは使用可能です。WSGIアプリケーションを作成する次に、前述のWSGI仕様要件を使用して、信じられないほど単純なWSGIアプリケーションを作成します。繰り返しますが、提供する必要があるアプリケーションコンポーネントには、次のプロパティが必要です。callable(呼び出し可能な関数または他の言語構成要素)を介してインターフェイスを提供する必要があります呼び出し可能オブジェクトは、環境変数のようなキーと値のペアを含む辞書と、サーバー(uWSGI)でアクセス可能な呼び出し可能オブジェクトをパラメーターとして受け取る必要があります。アプリケーションのcallableは、クライアントを送信するためのボディを生成するiterableを返す必要があります。アプリケーションは、HTTPステータスとリクエストヘッダーを使用してウェブサーバーのcallableを呼び出す必要があります。+`というファイルにアプリケーションを書き込みます。~//wsgi.pyこのファイル内で、できる限り単純なWSGI準拠のアプリケーションを作成します。すべてのPythonコードと同様に、インデントに注意してください。There!</h1>"]上記のコードは、完全なWSGIアプリケーションを構成しています。`という呼び出し可能オブジェクトを探します。+`を呼び出した理由です。ご覧のとおり、2つのパラメーターが必要です。+」と呼ばれ、送信されるWebサーバー(uWSGI)呼び出し可能オブジェクトを参照するためにアプリが内部的に使用する名前です。333]仕様の例で使用されているため、単純に選択されました。アプリケーションはこの情報を取得して、2つのことを行う必要があります。受信した呼び出し可能オブジェクトをHTTPステータスコードと返送するヘッダーで呼び出す必要があります。html」に設定します。第二に、応答本体として使用するために反復可能に返す必要があります。ここでは、HTMLの単一の文字列を含むリストを使用しました。文字列も反復可能ですが、リスト内では、uWSGIは1回の反復で文字列全体を処理できます。実際のシナリオでは、このファイルはおそらくアプリケーションコードの残りの部分へのリンクとして使用されます。+`ファイルが含まれています。単純化されたWSGIインターフェイスは、実際のアプリケーションコードがどれほど複雑であっても同じままです。これは、インターフェイスの強みの1つです。完了したら、ファイルを保存して閉じます。コードをテストするために、uWSGIを起動できます。+`でリッスンするように指示します。スクリプトの名前を渡します(サフィックスは削除されます)。+」ファイルで本文として渡した最初のレベルのヘッダーテキストが表示されます。[wsgiアプリケーション例]これが機能することを確認したら、CTRL-Cでサーバーを停止します。この時点で、実際のアプリケーションの設計は完了です。必要に応じて、仮想環境を非アクティブ化できます。deactivateuWSGI構成ファイルを構成する上記の例では、uWSGIサーバーを手動で起動し、コマンドラインでいくつかのパラメーターを渡しました。これを回避するには、構成ファイルを作成します。+`形式を使用します。+」を呼び出してアプリケーションフォルダーに配置します。+`というセクションを確立する必要があります。このセクションは、すべての構成アイテムが存在する場所です。アプリケーションを特定します。uWSGIサーバーは、アプリケーションの呼び出し可能オブジェクトがどこにあるかを知る必要があります。ファイルと関数を次の範囲内で提供できます。+`プロセスをマスターとしてマークしてから、いくつかのワーカープロセスを生成します。5人のワーカーから始めます。5実際に、uWSGIが外部の世界と話すために使用するプロトコルを変更します。NginxをuWSGIの前でリバースプロキシとして構成するため、これを変更できます。`プロキシメカニズムを実装します。これは、uWSGIが他のサーバーと通信するために使用できる高速バイナリプロトコルです。`プロトコルは実際にはuWSGIのデフォルトプロトコルです。+`にフォールバックします。Nginxで使用するためにこの構成を設計しているので、ネットワークポートの使用から変更し、代わりにUnixソケットを使用します。これはより安全で高速です。`サーバーを実行し、ソケットファイルを所有します。`の下にディレクトリを作成してソケットファイルを配置し、uWSGIとNginxの両方がアクセスできるようにします。`グループでuWSGIを起動します)。+」オプションを追加します。trueブート時にアプリケーションを起動するsystemdファイルを作成するため、最後のオプションが1つ必要です。SystemdとuWSGIは、アプリケーションに対してSIGTERMシグナルが何をすべきかについて異なる考えを持っています。+」というオプションを追加するだけです。true完了したら、ファイルを保存して閉じます。これで、この構成ファイルはUpstartスクリプトで使用するように設定されました。Unitファイルを作成してアプリを管理するブート時にuWSGIインスタンスを起動して、アプリケーションが常に利用できるようにすることができます。これを行うために、systemdユニットファイルを作成できます。system`ディレクトリに配置します。+」セクションから始めます。ここに置く唯一のものは、サービスの説明です。`セクションを開きます。仮想環境を使用しているため、サービス開始コマンドは従来よりも複雑になります。`コマンドを使用して、ソケットディレクトリが作成され、正しい関係者によって所有されていることを確認します。設定されている場合は、(等号の後に「-」を付けることで)これは失敗します。+`の1回の呼び出しに渡されます。bash」)しか実行できないため、これにより、いくつかの異なるコマンドを実行できます。+`ファイルでuWSGIを起動します。`セクションを作成するだけです。これにより、ユニットを「+有効化」したときに何が起こるかが決まります。基本的には、ユニットが自動起動する状態を指定します。有効にすると、サーバーがマルチユーザーモードになっているときにこのユニットが起動するように指定します。myapp.ini'[Install]WantedBy=multi-user.target上記の構成を書き出したら、ファイルを保存して閉じます。これで、次のように入力してサービスを開始できます。uwsgi次のように入力して、問題なく起動したことを確認します。uwsgiエラーがなかった場合は、次のように入力して、起動時にサービスが開始されるようにサービスを有効にします。uwsgi次のように入力して、いつでもサービスを停止できます。uwsgiNginxをuWSGIにプロキシするように構成するこの時点で、WSGIアプリがあり、uWSGIがそれを読み取って提供できることを確認しました。構成ファイルとSystemdユニットファイルを作成しました。+`プロトコルを使用して通信します。これで、Nginxをリバースプロキシとして構成できるようになりました。+`プロトコルを使用してプロキシする機能があります。これはHTTPよりも高速なプロトコルであり、パフォーマンスが向上します。設定するNginxの構成は非常に簡単です。`ファイルを修正し、新しいサーバーブロックを追加します。/etc/nginx/nginx.confデフォルトのサーバーブロックの前に、独自のサーバーブロックを追加します。.作成したブロックは、uWSGIプロキシの構成を保持します。以下の残りの構成アイテムは、このブロック内に配置されます。サーバーブロックはポート80でリッスンし、サーバーのドメイン名またはIPアドレスに応答する必要があります。;}その後、すべてのリクエストを処理する単一のロケーションブロックを開くことができます。+`パラメーターを含め、uWSGIがリッスンしているソケットにトラフィックを渡します。}}実際、単純なアプリケーションに必要なのはこれだけです。完全なアプリケーションのために、いくつかの改善を行うことができます。このブロックの外側に多数のアップストリームuWSGIサーバーを定義し、それらにそれらを渡すことができます。いくつかのuWSGIパラメータを含めることができます。Nginxからの静的ファイルを直接処理し、動的リクエストのみをuWSGIインスタンスに渡すこともできます。3行アプリではこれらの機能は必要ないため、ファイルを保存して閉じることができます。次のように入力して、Nginxの構成が有効であることをテストして確認できます。-tこれがエラーなしで戻る場合は、次のように入力してサービスを開始します。nginxサービスを有効にして、起動時にNginxを起動します。nginxサーバーのドメイン名またはIPアドレス(ポート番号なし)に移動し、構成したアプリケーションを確認できるはずです。[完全なWSGIアプリ]結論これまでに作成した場合は、単純なWSGIアプリケーションを作成し、より複雑なアプリケーションを設計する必要があるかについての洞察を得ています。uWSGIアプリケーションコンテナー/サーバーを専用の仮想環境にインストールして、アプリケーションを提供しています。このプロセスを自動化するために、構成ファイルとSystemdユニットファイルを作成しました。+`ワイヤープロトコルを使用してuWSGIプロセスと通信できるNginxリバースプロキシを設定しました。実際の実稼働環境をセットアップするときに、これをどのように拡張できるかを簡単に確認できます。uWSGIには、「皇帝モード」と呼ばれるものを使用して複数のアプリケーションを管理する機能があります。Nginx構成を展開して、uWSGIインスタンス間で負荷を分散したり、アプリケーションの静的ファイルを処理したりできます。複数のアプリケーションを提供する場合、ニーズに応じて、仮想環境ではなくグローバルにuWSGIをインストールするのが最善の場合があります。コンポーネントはすべてかなり柔軟であるため、多くの異なるシナリオに対応できるように構成を調整できるはずです。