テストサーバーへのWebアプリケーションの展開に関する考察

まえがき

以下のテキストは、彼（つまり、私）が理にかなっている分野のいずれにおいても体系的な教育を受けていない人の実際の経験と独学の衝動の結果です。 したがって、ここでの難解な推論には、プラティティスが散りばめられます。 最初は私を打ち負かし、2番目は無視します。 一部の人にとっては、彼らは啓示になる可能性があります。



テストWebを北にセットアップするための理想的なオプションについて説明しようとしますが、テストWebが通常行う混乱を理解しています。 頻繁にデプロイする必要がある場合、つまり、プロジェクトがアクティブな開発の段階でサーバー上に存在している場合、または異なる段階の複数のプロジェクトが存在する場合の状況について説明します。 さまざまな開発者またはチームがプロジェクトに関与しているため、プロジェクトを互いに分離する必要があります。 ただし、サーバーは内部にあるため、リース用のサーバーのように管理プロセスをある程度分離および自動化する必要はありません。



サポートされているWebアプリケーションの言語として、さまざまなバージョンのPythonの使用に焦点を当てます。 RubyやPerlなど、他の言語にも多くのことが当てはまりますが。



Pythonプログラムは、 PEP 3333およびその以前のドキュメントであるPEP 333で説明されているWSGIプロトコル（「wiskey」と呼ばれる）を使用してWebサーバーと対話します。

シングルリンクアーキテクチャ

1層アプローチの利点は、構成が簡単であり、メモリ消費量が少ないため、柔軟性が損なわれ、場合によってはパフォーマンスが低下することです。



このような条件下で動作する最も人気のあるWebサーバーである現代のWebの本当の「スイスアーミーナイフ」は、Apache HTTPdです（この名前は「Apache」と略されます）。 Apacheの現在のバージョンである2.2および2.4に留意してください。



第2層サーバーを使用せずに、WSGIアプリケーションをApacheに直接接続するには、プラグイン（Apache用語ではモジュール） mod_wsgiが使用されます。 WSGIは、 CGIプロトコルの高度なPython固有バージョンです。 技術的には、Pythonインタープリター（より正確にはCPython）は、外部ライブラリとしてmod_wsgiに組み込まれています：静的または動的-これはモジュールの構築時に決定されます。 Apacheが1つのインストールで1つのmod_wsgiモジュールのみに対応できるように、CPythonの1つのバージョンのみが同時にmod_pythonに統合できることは明らかです。 これは制限につながります。mod_wsgiを使用したシングルリンクアーキテクチャでは、サーバーでPython2とPython3の両方を使用することはできません 。



マルチプロセッシングモジュールの選択は私たちにとって不可欠です。 マルチコア（マルチプロセッサ）コンピューター構成の異なるコンピューティングコア間で効率的に負荷を分散するには、Webサーバーが複数のリクエストを同時に処理し、Webアプリケーションの複数のインスタンスの起動を開始できる必要があります。 上記の機能を異なる方法で実行する2種類のマルチプロセッシングモジュールがあります。

プリフォーク

UNIXライクな環境のWebサーバーによるCGIリクエストの簡略化された実行は次のようになります：リクエストが受信されると、サーバーはCGIアプリケーションプロセスを生成し、環境変数のリクエストパラメーターと標準入力ストリームのボディを渡します。 最初の最適化は、生成プロセスに時間がかかり、リクエストへの応答時間が長くなるという事実によって引き起こされました。 CGIプログラム（この場合、mod_wsgiに組み込まれているPythonインタープリター）の起動に時間を無駄にしないために、リクエストがサーバーに到着するまで、事前に起動し、入力ストリームを閉じずに一時停止状態に保つだけで十分です。 サーバーが複数のコードストリームを同時に実行できる場合は、複数のCGIハンドラーを実行し、新しいハンドラーが完了したときに起動されるようにすることは理にかなっています。 作業中および待機中のハンドラーの数（プールサイズ）を構成できます。 1つの要求を処理すると、プロセッサプロセスは次を受け入れることができます。 リクエストが少なすぎる場合、サーバーは不要なアイドルプロセスを強制終了します。 また、サーバーは、処理するリクエストの数が特定の（カスタマイズ可能な）制限に達すると、予防目的でプロセスを強制終了します。



これは、 mod_preforkおよびmod_itkモジュールの動作方法とまったく同じです。 後者は、この仮想ホストの設定で設定されたユーザーに代わって各仮想ホストにサービスを提供できるため、私たちにとって最も興味深いものです。 しかし、それについては後で。

労働者

CGIプロセスの生成コストを「償却」すると同時にサーバーの全体的な負荷を軽減する2番目の方法は、1つのプロセスを使用して複数のリクエストを同時に処理することです。



説明されている戦略は、mpm_workerおよびmpm_eventモジュールによって実装されます。 後者はまた、いくつかのアカウンティングアクションからリクエスト処理のメインスレッドをアンロードし、これまでのところ実験的なステータスを持っています。



ワーカーは、それ自体ではなく不安定で安全ではないと長い間考えられてきましたが、他の多くのApacheモジュールがマルチスレッドモードに適応していないか、実装にエラーがあったためです。 しかし、時間が経つにつれて、これらの問題は解決され、今では労働者はビジネスで使用するのに十分安全です。



GILなどのCPython機能のおかげで、mod_wsgiはマルチスレッド化された作業に非常に簡単に適応できましたが、この同じ機能ではマルチスレッド化の利点を最大限に活用することはできません。 GILは、1つのプロセス内でPythonコードのすべてのスレッドがクォンタムごとに連続して実行されることを保証します。これにより、同時実行の錯覚のみが作成されます。 しかし、これはPythonを開始（またはPythonから実行）するCコードには適用されませんが、要求パラメーターの解析、WSGIハンドラーへのアドレスのマッピングなど-これはすべてCコードで行われます。 したがって、Pythonで作成されたサイトでは、mpm_workerを使用することで特定のパフォーマンスが向上します。

2層アーキテクチャ

2層アーキテクチャでは、外部（フロントエンド）と内部（バックエンド）の異なるレベルのWebサーバーを共同で使用します。



外部サーバーは、「リバースプロキシ」のようなプロトコルとプラグインを使用して、ユーザーと内部サーバー間の仲介役として機能します。 さらに、外部サーバーは1990年に作成されたHTTPプロトコルを実行します。クライアントに静的ファイル（アセット）を提供します。 最近では、この機能は本番環境のCDNサービスにしばしば移行されています。



Apacheは外部サーバーとしても使用できますが、軽量のnginx、またはリソースが限られている状況では、lighttpdがこの役割に適しています。 この役割では、サーバーは要求に対する迅速な応答と、消費されるリソースに関する謙虚さのみを必要とします。



通常、内部サーバーは、アプリケーションのアーキテクチャと言語に依存します。 Pythonアプリケーションは、 uWSGI 、 Green Unicorn、またはtwistedやTornadoなどのマルチスレッドネットワークフレームワークに基づいた独自のサーバーを使用することがよくあります。 多くのWebフレームワークには、戦闘操作に多少なりとも適しているWebサーバーも含まれています。 たとえば、Djangoに組み込まれているWebサーバーはデバッグ専用であり、運用環境ではより深刻なものに置き換える必要があります。 一方、組み込みのCherryPy Webサーバーは、戦闘負荷に対して最適化されています。

テストサーバー（CIサーバー）の特別な要件

ファイル許可の問題

POSIXシステムのネットワークアーキテクチャでは、特権ユーザーのみがポート1〜1024にアクセスできると想定しています。 ポート80（HTTP）および443（HTTPS）はこの制限に該当するため、Webサーバーの親プロセス（2層アーキテクチャに関しては外部）は常にルート権限を持っています。



しかし、CGIスクリプトがセキュリティ上の理由で不必要に広い権利を与えることは望ましくありません。 したがって、スクリプトとデータを使用する場合、Webサーバーは常に特権を通常のユーザーのレベルまで下げます。 Apacheのこのようなユーザーは、環境変数APACHE_RUN_USERおよびAPACHE_RUN_GROUPによって定義されます。 Debianおよびその派生ディストリビューションでは、このユーザーの名前は「www-data」です。 システムのセキュリティをさらに強化するために、他のサービスユーザーと同様に、www-dataユーザーはシェルを持たず、システムにログインできません。



Webアプリケーションがサーバーに一度インストールされ、将来変更されない場合（ユーザーがダウンロードしたファイルを除く）、高い特権を持つユーザーとしてサーバーにログインし、適切なディレクトリ（ '/ var / www'でファイルを展開することは論理的ですDebianで）およびこれらのファイルの所有者を変更します。

# chown -R www-data:www-data /var/www/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

開発サーバーにとって、この方法は不便であり、特権アカウントを絶えず使用しているため懸念を引き起こすことは明らかです。 詳細な回答を含むディレクトリおよびWebサーバーデータへの理想的なアクセス権についての質問は、 こちらをご覧ください 。 この記事は、Serverfaultに関する正規の質問のリストにあります。これは何かを意味します。



この記事の本質は次のとおりです。

• サイトの展開を担当する担当者が1人いる場合、サイトのすべてのファイルとディレクトリのユーザー所有者、および「www-data」を実行する所有者グループにする必要があります。ディレクトリのアクセスコードを750に設定します（サイトユーザーがアップロードできるディレクトリの770ファイル）およびファイル用640（サーバーによって記録されたファイル用660）。 起動スクリプトのumaskは027に設定する必要があります。
• 複数のユーザーがサイトにアクセスする必要がある場合、ルートユーザーの所有者を作成する必要があります。所有者グループはすべての開発者が構成されるグループになり、Webサーバーは下位3ビットによりこれらのファイルにアクセスします。
• www-dataをデータの所有者として設定し、開発グループを所有者グループとして設定しますが、各ファイルを作成した後、所有者を変更する必要があります。 別の回答者は、作成されたオブジェクトの作成者が作成者ではなく、オブジェクトが作成されたディレクトリの所有者になるように、ディレクトリにsuidおよびguidビットを設定する機能に言及しています。 これらのビットを使用するこのような非標準的な方法は、* BSDからLinuxに転送され、ファイルがWebサーバーによって作成された場合に動作するかどうかはわかりませんが、
• 理想的な場合では、開発チームは自動展開ツール（ Puppet 、 Chef ）またはCI環境（ Jenkins ）を使用して状況を1人の責任あるユーザーに減らす必要がありますが、唯一の違いはユーザーがボットになることです。
• その結果、アクセス権を設定するだけでは仮想ホストを完全に分離することは不可能であると結論付けられます。1つのサイトの脆弱性により、攻撃者は少なくともこのサーバー上のすべてのWebアプリケーションのコードを読み取ることができます。

議論で言及されていないのは、chmodとchownを使用したこれらすべての操作の猛烈な複雑さであり、その結果、脆弱性につながる人的エラーの可能性が高いことです。



Apacheで利用可能な特権分離ツールを使用するか、2層アーキテクチャに切り替えると、すべてがより簡単で安全になります。

Apache特権共有ツール

mpm_itk

mpm_itkモジュールを使用すると、どのユーザーで最も簡単で最も自然な方法でWebアプリケーションを実行するかを決定できます。

 <VirtualHost *:80> <IfModule mpm_itk_module> AssignUserID johnd developers </IfModule> … </VirtualHost>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

mod_suexec

何らかの理由で別のマルチプロセッサモジュールの使用を余儀なくされた場合は、 mod_suexecが役立ちます。 欠点はおそらくセットアップの相対的な複雑さであると考えることができますが、これはソースからインストールする場合のみです。 ディストリビューションでは、すべてが自動化されています。 また、mod_suexecの使用は、仮想ホスト構成の単一のディレクティブに要約されます。

 <VirtualHost *:80> <IfModule mod_suexec.c> SuexecUserGroup johnd developers </IfModule> … </VirtualHost>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストサーバー上の2層アーキテクチャ

多くの場合、サーバーのパフォーマンスを最適化するために2層アーキテクチャが使用されます。 開発者は、速度よりもWebアプリケーションの展開の利便性をより重視しています。 テストサーバーで2層アーキテクチャを使用することには、特定の利点もあります。



利点には、開発者が内部サーバーのインストールと構成を担当し、最適なパラメーターと起動方法を決定するという事実が含まれます。 内部サーバーは開発者特権で動作し、プログラムファイルとプロジェクトディレクトリへのアクセス権の最適な設定に関する質問はなくなりました。 ホストログも開発者が完全に自由に使用できます。 Webアプリケーションは、他のプロジェクトに関係なく、virtualenvで指定されたバージョンのPythonを使用できます。 サーバー管理者が処理する必要があるのは、外部サーバーと内部サーバーが通信するための静的変数とUNIXソケットまたは非特権ポートを備えたディレクトリだけです。



開発者は、サーバーの自動起動とその円滑な運用にも責任を負います。 前者がcrontab -eコマンドで簡単に解決できる場合は、後者にスーパーバイザーを提供できます。

Webサーバーの再起動

Apacheを唯一のサーバーとして使用する場合、設定に「 MaxRequestsPerChild 1 」ディレクティブを追加する必要があります。 これにより、開発者はサーバーを再起動する必要がなくなります。 リクエストごとにインタープリターの新しいインスタンスが起動されるため、サイトコードのすべての変更はすぐにその作業に反映されます。



もちろん、リクエストハンドラの二次使用を禁止すると、サーバーのパフォーマンスが低下しますが、それ以外の場合は、コードを変更するたびにサーバーを再起動する必要があります。 Apacheを再起動するには、WSGI固有の方法と汎用の2つの方法があります。

• WSGI固有の方法は、WSGIスクリプトの編集日を更新することです。 これは、touchコマンドで実行できます。 このメソッドは、mod_wsgiがデーモンモードで動作するように設定されている場合にのみ機能します。 （一般に、デーモンモードで動作するようにmod_wsgi を構成することを強くお勧めしますが、このモードはデフォルトでオフになっています。）
• 一般的な方法-apachectl restartコマンドまたは類似の方法では、ルート権限が必要です。 もちろん、sudoの適切な構成でうまくいくことができますが、sudo自体の使用は見かけよりも複雑で危険です。 したがって、この方法を使用することは望ましくありません。

2層アーキテクチャを使用する場合は、内部サーバーのみを再起動する必要があります。 展開が実行されるのと同じユーザーの代わりに機能するため、再起動（または再起動の必要なしに設定）しても問題はありません。

結論

2層Webサーバーアーキテクチャは、同じ企業内の複数の開発者または開発チームが使用するテストサーバーに最適です。 サーバー管理者を多数のルーチンから解放し、開発者がプロ​​ジェクトを実装する手段をより自由に選択できるようにし、ハードウェアリソースをより効率的に使用できるようにします。 同時に、開発の利便性は生産性の低下を犠牲にして達成される場合があります。 しかし、組織の資金が非常に限られており、1つのサーバーにテストプロジェクトと戦闘プロジェクトを配置することを余儀なくされた場合でも、この場合もセキュリティとかなり良いレベルのパフォーマンスを実現できます。