マルウェアとは、侵入的または危険なプログラムです。
あらゆる記憶メディアからのデータ回復に最適なプログラム....
毎日ネットワークに接続されたコンピュータを使用していて、モバイル ガジェットもインターネットに接続している場合、すべてのユーザーは時々「サーバー」という言葉に遭遇します。 さらに、この単語はさまざまな組み合わせで現れる可能性があり、すべてのユーザーが何を言っているのかを理解できるわけではありません。 「サーバー」という言葉の裏には何が隠されており、なぜユーザーはそれを必要とするのでしょうか?
「サーバー」という用語は、ハードウェア デバイスおよびそのためのソフトウェア (ハードウェアおよび仮想) を意味する場合があります。 ハードウェア サーバーは別個のコンピューターです。 他の PC やオフィス機器の動作を保証するために必要です。 仮想サーバーはソフトウェアです。 この場合、特定のサーバーがこれら 2 つのタイプを組み合わせます。
まず覚えておいていただきたいのは、その仕事はネットワークを管理することではなく、ネットワークとユーザーを維持することであるということです。 ユーザー自身がサーバーにタスクを提示すると、サーバーはそれらをすぐに解決します。 たとえば、HP サーバーなどのサーバーが優れていればいるほど、その役割をよりよく実行できます。
多数の電子機器を設置している大企業が、これらすべての機器を 1 つのネットワークに統合せずに業務を遂行することを想像するのは困難です。 企業内のサーバーを使用すると、オフィス機器をリモートで制御したり、PC が相互に通信したりできるようになります。
サーバーの障害や誤動作は災害を引き起こす可能性があります
企業では、サーバーによってすべての部門の作業を最適化できます。 しかし、日常生活ではサーバーの作業に遭遇することがよくあります。 特に、レジや銀行の窓口係は、サーバーを使用して書類を印刷したり支払いを行ったりします。 このサーバーは、すべてのメーラー、ソーシャル ネットワーク、およびコミュニケーション マネージャーをサポートしています。
サーバーはインターネットへのアクセスを提供します。 すべてのサイトはサーバーに保存されます。 これにより、共有ホスティングが提供されます。 このサービスはホスティング会社によって提供されます。
Webサーバーとは何ですか? 一般の人の観点から見ると、これはブラウザのリクエストを処理し、それに応じて Web ページを生成する一種のブラック ボックスです。 技術者は、あいまいな用語をたくさん浴びせかけます。 その結果、初心者の Web サーバー管理者がさまざまな用語やテクノロジーを理解するのが難しい場合があります。 確かに、Web 開発の分野は動的に発展していますが、最新のソリューションの多くは、今日説明する基本的なテクノロジーと原則に基づいています。
どこから始めればよいかわからない場合は、最初からやり直す必要があります。 さまざまな現代の Web テクノロジーで混乱しないようにするには、歴史に目を向けて、現代のインターネットがどこで始まり、テクノロジーがどのように発展し、改善されたのかを理解する必要があります。
HTTPサーバー
インターネット開発の黎明期、サイトは、特別にマークされたドキュメントと関連データ (ファイル、画像など) の単純なリポジトリでした。 ドキュメントが相互に参照したり関連データを参照できるようにするために、特殊なハイパーテキスト マークアップ言語である HTML が提案され、インターネット経由でドキュメントにアクセスするための HTTP プロトコルが提案されました。 言語とプロトコルは両方とも、開発と改良を経て、今日まで大きな変更を加えることなく生き残っています。 1999 年に採用された HTTP/1.1 プロトコルの置き換えが始まったばかりの HTTP/2 プロトコルは、現代のネットワークの要件を考慮して根本的な変化をもたらしました。
HTTP プロトコルはクライアント/サーバー テクノロジを使用して実装され、ステートレスな要求と応答の原則に基づいて動作します。 リクエストの目的は特定のリソースであると判断されます 単一のリソース識別子 - URI (統一リソース識別子)、HTTP は URI の種類の 1 つを使用します - URL (ユニフォームリソースロケータ) - ユニフォームリソースロケータ、リソースに関する情報に加えて、その物理的な場所も決定されます。
HTTP サーバーのタスクは、クライアントのリクエストを処理し、必要なリソースを提供するか、提供できないことを報告することです。 次の図を考えてみましょう。
ユーザーは、HTTP クライアント (通常はブラウザ) を介して、HTTP サーバーに特定の URL をリクエストします。サーバーは、対応する URL ファイル (通常は HTML ページ) を確認して送信します。 作成されたドキュメントには、画像などの関連リソースへのリンクが含まれる場合があります。 ページ上に表示する必要がある場合、クライアントはサーバーに対して順次リクエストを行いますが、画像のほか、スタイルシート、クライアント側で実行されるスクリプトなどもリクエストできます。 必要なリソースをすべて受信すると、ブラウザは HTML ドキュメントのコードに従ってそれらを処理し、完成したページをユーザーに表示します。
多くの人がすでに推測しているように、このスキームの HTTP サーバーの名前の下には、今日では Web サーバーとしてよく知られているエンティティが存在します。 Web サーバーの主な目的とタスクは、HTTP リクエストを処理し、その結果をユーザーに返すことです。 Web サーバーは独自にコンテンツを生成できず、静的コンテンツのみを処理します。 これは、機能が豊富であるにもかかわらず、最新の Web サーバーにも当てはまります。
長い間、本格的な Web サイトを実装するには 1 つの Web サーバーで十分でした。 しかし、インターネットが成長するにつれて、静的 HTML の機能が著しく不足するようになりました。 簡単な例: 各静的ページは独立しており、それに関連付けられたすべてのリソースへのリンクが含まれている必要があります。新しいページを追加するときは、そのページへのリンクを既存のページに追加する必要があります。そうしないと、ユーザーはそれらのページにアクセスできなくなります。 。
当時のサイトは一般的に現代のサイトとはほとんど似ていません。たとえば、以下はロシア語インターネットの先駆者の 1 つである Rambler 社のサイトの表示です。
また、リンクをクリックすると現代のユーザーは一般的に混乱する可能性があり、ブラウザで同じ名前のボタンを押す以外にそのようなページから戻ることはできません。
多かれ少なかれ現代の Web サイトに似たものを作成しようとすると、すぐに既存のページに変更を加える作業量が増加するようになりました。 結局のところ、ヘッダーのロゴなど、サイトの一般的な部分で何かを変更した場合は、既存のすべてのページでこの変更を行う必要があります。 また、いずれかのページへのパスを変更または削除した場合は、そのページへのすべてのリンクを見つけて変更または削除する必要があります。
したがって、Web サーバー開発の次のステップはテクノロジー サポートでした。 サーバー側イネーブラー - SSI (サーバー側の内容）。 これにより、ページ コードに他のファイルの内容を含めることができるようになり、ヘッダー、フッター、メニューなどの繰り返し要素を削除できるようになりました。 それらを別のファイルに分割し、ページの最終組み立て時に含めるだけです。
ロゴやメニュー項目を変更するには、既存のすべてのページを編集するのではなく、1 つのファイルのみを変更する必要があります。 さらに、SSI により、ページ上に現在の日付などのいくつかの動的コンテンツを表示したり、単純な条件を実行したり、変数を操作したりすることが可能になりました。 これは大きな進歩であり、ウェブマスターの作業が容易になり、ユーザーの利便性が向上しました。 しかし、これらのテクノロジーではまだ真に動的な Web サイトを実装することはできませんでした。
SSI は現在でも積極的に使用されており、主にそのシンプルさとリソース要件の低さにより、いくつかの静的コンテンツをページ コードに挿入する必要があることは注目に値します。
CGI
Web テクノロジーの発展における次のステップは、ユーザーのリクエストをサーバー側で処理する特別なプログラム (スクリプト) の出現でした。 ほとんどの場合、それらはスクリプト言語で書かれており、当初は Perl でしたが、現在では PHP が主導権を握っています。 徐々に、プログラムのクラス全体が登場しました - コンテンツ管理システム - CMS (コンテンツ管理システム) は、ユーザー要求の動的な処理を提供できる本格的な Web アプリケーションを表します。
ここで重要な点がわかります。Web サーバーはスクリプトを実行する方法を知らなかったし、その方法を知りませんでした。Web サーバーのタスクは静的コンテンツを提供することです。 ここで、新しいエンティティが登場します。それは、スクリプト言語のインタープリタであり、スクリプト言語で記述された Web アプリケーションを実行するアプリケーション サーバーです。 DBMS は、相互に関連する大量の情報にアクセスする必要があるため、通常はデータの保存に使用されます。
ただし、アプリケーション サーバーは HTTP プロトコルを使用してユーザー要求を処理することはできません。これは Web サーバーのタスクであるためです。 彼らの相互作用を確実にするために開発されました 共通ゲートウェイインターフェース - CGI (共通ゲートウェイインターフェース).
CGI はプログラムやプロトコルではなく、正確にはインターフェイス、つまりインターフェイスであることを明確に理解する必要があります。 アプリケーション間の対話の一連の方法。 また、CGI という用語を、CGI インターフェイスを介して作業をサポートするプログラム (スクリプト) を指す CGI アプリケーションまたは CGI スクリプトの概念と混同しないでください。
データの転送には標準の入出力ストリームが使用されます。データは、Web サーバーから CGI アプリケーションに次の方法で転送されます。 標準入力、返送は受け付けられます 標準出力、エラーメッセージの送信に使用されます 標準エラー.
このようなシステムの動作プロセスをさらに詳しく考えてみましょう。 ユーザーのブラウザからリクエストを受信した Web サーバーは、動的コンテンツがリクエストされていると判断し、特別なリクエストを生成し、CGI インターフェイスを通じて Web アプリケーションに送信します。 これを受信すると、アプリケーションが実行されてリクエストが行われ、動的に生成されたページの HTML コードが Web サーバーに返され、その後アプリケーションが終了します。
動的サイトのもう 1 つの重要な違いは、そのページがユーザーに表示される形式で物理的に存在しないことです。 実際、Web アプリケーションがあります。 一連のスクリプトとテンプレート、およびサイトのマテリアルとサービス情報を保存するデータベースであり、静的コンテンツ (画像、Java スクリプト、ファイル) は個別に配置されます。
リクエストを受信すると、Web アプリケーションはデータベースからデータを取得し、リクエストで指定されたテンプレートをそのデータに埋め込みます。 結果は Web サーバーに送信され、この方法で生成されたページに静的コンテンツ (画像、スクリプト、スタイル) が追加され、ユーザーのブラウザに送信されます。 ページ自体はキャッシュ以外のどこにも保存されず、新しいリクエストを受信するとページが再生成されます。
CGI の利点には、言語とアーキテクチャの独立性が含まれます。CGI アプリケーションは任意の言語で作成でき、どの Web サーバーでも同様に動作します。 この標準のシンプルさとオープン性により、Web アプリケーションの急速な開発が可能になりました。
ただし、CGI には利点に加えて、重大な欠点もあります。 主な問題は、プロセスの開始と停止にかかるオーバーヘッド コストが高く、ハードウェア リソースの要件が増大し、パフォーマンスが低下することです。 また、標準 I/O ストリームを使用すると、Web サーバーとアプリケーション サーバーが同じシステム上に存在する必要があるため、スケーラビリティと高可用性が制限されます。
現時点では、CGI はより高度なテクノロジーに置き換えられているため、実際には使用されていません。
高速CGI
名前が示すように、このテクノロジー開発の主な目的は CGI のパフォーマンスを向上させることでした。 そのさらなる発展として、FastCGI は、Web サーバーとアプリケーション サーバー間の対話のためのクライアント/サーバー プロトコルであり、高いパフォーマンスとセキュリティを提供します。
FastCGI は、リクエストごとに Web アプリケーション プロセスを再起動するという CGI の主な問題を解決し、FastCGI プロセスが常に実行されるため、時間とリソースを大幅に節約できます。 データ送信には、標準ストリームの代わりに、 UNIXソケットまたは TCP/IPこれにより、Web サーバーとアプリケーション サーバーを異なるホストでホストできるようになり、システムのスケーラビリティや高可用性が確保されます。
また、1 台のコンピューター上で複数の FastCGI プロセスを実行して、リクエストを並行して処理したり、スクリプト言語の設定やバージョンが異なることもできます。 たとえば、異なるサイトに対して複数のバージョンの PHP を同時に使用し、リクエストを異なる FastCGI プロセスに送信することができます。
プロセス マネージャーは、FastCGI プロセスと負荷分散を管理するために使用され、Web サーバーの一部または別個のアプリケーションのいずれかになります。 一般的な Web サーバーである Apache と Lighttpd には FastCGI プロセス マネージャーが組み込まれていますが、Nginx では FastCGI と連携するために外部マネージャーが必要です。
PHP-FPM と spawn-fcgi
FastCGI プロセスの外部マネージャーには、PHP-FPM および spawn-fcgi が含まれます。 PHP-FPM は元々、Andrey Nigmatulin による PHP 用のパッチ セットで、FastCGI プロセスの管理における多くの問題を解決しました。バージョン 5.3 からはプロジェクトの一部となり、PHP ディストリビューションに含まれています。 PHP-FPM は、負荷に応じて PHP プロセスの数を動的に管理したり、リクエストを失わずにプールをリロードしたり、失敗したプロセスを緊急に再起動したりすることができ、かなり高度なマネージャーです。
Spawn-fcgi は Lighttpd プロジェクトの一部ですが、同じ名前の Web サーバーの一部ではありません。デフォルトでは、Lighttpd は独自のより単純なプロセス マネージャーを使用します。 開発者は、別のホストにある FastCGI プロセスを管理する必要がある場合、または高度なセキュリティ設定が必要な場合に、これを使用することをお勧めします。
外部マネージャーを使用すると、各 FastCGI プロセスを独自の chroot (アプリケーションのルート ディレクトリを超えてアクセスできないように変更) 内に分離できます。これは、他のプロセスの chroot や Web サーバーの chroot とは異なります。 また、すでに述べたように、TCP/IP 経由で他のサーバーにある FastCGI アプリケーションを操作できるため、ローカル アクセスの場合は、高速接続タイプとして UNIX ソケット経由のアクセスを選択する必要があります。
この図をもう一度見ると、Web サーバーとアプリケーション サーバーの間の仲介者であるプロセス マネージャーという新しい要素があることがわかります。 これにより、より多くのサービスを構成および維持する必要があるため、スキームが多少複雑になりますが、同時に、より広い可能性が開かれ、サーバーの各要素をタスクに合わせて構成できるようになります。
実際には、組み込みマネージャーと外部マネージャーのどちらを選択するかについては、状況を賢明に評価し、ニーズに最も適したツールを正確に選択してください。 たとえば、標準エンジンで複数のサイト用の単純なサーバーを作成する場合、外部マネージャーの使用は明らかに不要です。 誰も自分の視点をあなたに押し付けませんが。 Linux の良い点は、誰もが構築キットを使用するかのように、必要なものを正確に組み立てることができることです。
SCGI、PCGI、PSGI、WSGIなど
Web 開発のトピックを深く掘り下げていくと、さまざまな CGI テクノロジへの言及に必ず遭遇するでしょう。その中で最も人気のあるものをタイトルに挙げました。 このような多様性に混乱する可能性がありますが、この記事の冒頭を注意深く読んでいただければ、CGI と FastCGI がどのように機能するかを理解しているため、これらのテクノロジを理解することは難しくありません。
特定のソリューションの実装には違いがありますが、基本原則は共通です。 これらのテクノロジーはすべて、ゲートウェイ インターフェイス ( ゲートウェイインターフェース) Web サーバーとアプリケーション サーバー間の対話用。 ゲートウェイを使用すると、Web サーバー環境と Web アプリケーション環境を分離できるため、非互換性の可能性を考慮せずに任意の組み合わせを使用できるようになります。 簡単に言うと、Web サーバーが必要な種類のゲートウェイを処理できる限り、Web サーバーが特定のテクノロジやスクリプト言語をサポートしているかどうかは関係ありません。
タイトルにはすでにたくさんの略語をリストしましたので、さらに詳しく見ていきましょう。
SCGI (シンプルな共通ゲートウェイインターフェース) - シンプルな共通ゲートウェイインターフェース- CGI の代替として設計されており、多くの点で FastCGI に似ていますが、実装はより簡単です。 FastGCI に関連して説明したことはすべて、SCGI にも当てはまります。
PCGI (Perl 共通ゲートウェイ インターフェイス) - CGI インターフェイスを操作するための Perl ライブラリ。長い間、CGI 経由で Perl アプリケーションを操作するための主要なオプションであり、適度なリソース要件と良好な過負荷保護を備えた (CGI に関する限り) 優れたパフォーマンスを備えています。
PSGI (Perl Webサーバーゲートウェイインターフェイス) - Web サーバーと Perl のアプリケーション サーバー間の対話のためのテクノロジ。 PCGI が古典的な CGI インターフェイスを操作するためのツールである場合、PSGI は FastCGI を彷彿とさせます。 PSGI サーバーは、サービスとして継続的に実行され、TCP/IP または UNIX ソケット経由で Web サーバーと通信できる Perl アプリケーションを実行するための環境を提供し、FastCGI と同じ利点を Perl アプリケーションに提供します。
WSGI (Webサーバーゲートウェイインターフェイス) は、Phyton 言語で書かれたプログラムの Web サーバーとアプリケーション サーバー間の対話のために設計された別の特定のゲートウェイ インターフェイスです。
簡単にわかるように、ここで列挙したテクノロジーはすべて、ある程度 CGI/FastCGI に似ていますが、特定の応用分野向けです。 私たちが提供したデータは、その動作の原理とメカニズムを一般的に理解するのに十分なものであり、これらのテクノロジと言語を真剣に扱う場合にのみ、それらをより深く研究することは意味があります。
Apache モジュールとしてのアプリケーション サーバー
先ほどは抽象的な Web サーバーについて説明しましたが、ここでは具体的なソリューションについて説明します。これは好みの問題ではありません。 Web サーバーの中でも Apache は特別な位置を占めており、ほとんどの場合、Linux プラットフォーム上の Web サーバーについて話すとき、そして実際に Web サーバー一般について話すとき、それは Apache を意味します。
これは一種の「デフォルト」Web サーバーであると言えます。 あらゆる大規模ホスティングを利用できます - Apache が利用でき、あらゆる Web アプリケーションを利用できます - デフォルト設定は Apache 用に行われます。
はい、技術的な観点から見ると、Apache は技術の頂点ではありませんが、黄金の中庸を表しており、シンプルで、理解しやすく、設定が柔軟で、普遍的です。 Web サイト構築の最初の一歩を踏み出す場合は、Apache が最適です。
ここで、Apache はとうの昔に時代遅れであり、すべての「本物の人」はすでに Nginx をインストールしているなどと非難される可能性があります。 などなど、この点について詳しく解説していきます。 すべての一般的な CMS は、すぐに Apache で使用できるように構成されているため、問題の原因となる可能性のある Web サーバーを排除して、Web アプリケーションの操作にすべての注意を集中することができます。
初心者に人気のあるすべてのフォーラムでも Web サーバーとして Apache が使用されており、ヒントや推奨事項のほとんどは特に Apache に当てはまります。 同時に、代替 Web サーバーでは通常、Web サーバーと Web アプリケーションの両方から、より微妙で慎重な構成が必要になります。 同時に、これらの製品のユーザーは通常、はるかに経験豊富であり、その環境における初心者の典型的な問題については議論されません。 その結果、何をしてもうまくいかず、誰にも頼めないという状況が発生する可能性があります。 Apache ではこのようなことは起こらないことが保証されています。
実際、Apache 開発者は、自分たちの発案が特別な場所を占めることを可能にするために何をしたのでしょうか? 答えは非常に簡単です。彼らは独自の道を進んだのです。 CGI は特定のソリューションから抽象化してユニバーサル ゲートウェイに焦点を当てることを提案しましたが、Apache はそれとは異なる方法を採用し、Web サーバーとアプリケーション サーバーを可能な限り統合しました。
実際、アプリケーション サーバーを共通のアドレス空間で Web サーバー モジュールとして実行すると、はるかに単純なスキームが得られます。
これによりどのようなメリットが得られるのでしょうか? 回路がシンプルで構成要素が少ないほど、保守や保守が容易かつ安価になり、障害点も少なくなります。 これは単一サーバーの場合はそれほど重要ではないかもしれませんが、ホスティングでは非常に重要な要素です。
2 番目の利点は生産性です。 繰り返しますが、Nginx ファンを失望させることになりますが、単一アドレス空間で動作するおかげで、Apache + mod_php アプリケーション サーバーのパフォーマンスは、他の Web サーバー + FastCGI (または他の CGI ソリューション) よりも常に 10 ～ 20% 高速になります。 ただし、サイトの速度はアプリケーション サーバーのパフォーマンスだけでなく、代替の Web サーバーが大幅に優れた結果を示す可能性がある他の多くの条件によっても決定されることも覚えておく必要があります。
しかし、もう 1 つ、非常に重要な利点があります。それは、アプリケーション サーバーを個々のサイトまたはユーザーのレベルで構成できることです。 少し前に戻りましょう。FastCGI/CGI スキームでは、アプリケーション サーバーは独自の設定を持つ別個のサービスであり、別のユーザーまたは別のホストに代わって動作することもできます。 これは、単一サーバーまたは大規模プロジェクトの管理者の観点からは素晴らしいことですが、ユーザーやホスティング管理者にとってはそれほど重要ではありません。
インターネットの発展により、使用できる Web アプリケーション (CMS、スクリプト、フレームワークなど) の数が非常に多くなり、参入障壁が低いため、特別な技術的知識を持たない多くの人々が Web アプリケーションに興味を持ち始めています。ウェブサイトの構築。 同時に、Web アプリケーションごとにアプリケーション サーバーの異なる構成が必要になる場合があります。 どうすればいいですか？ 毎回サポートに連絡する必要がありますか?
解決策は非常に簡単でした。 アプリケーション サーバーは Web サーバーの一部になっているため、Web サーバーにその設定を管理するように指示できます。 従来、Apache の設定を管理するには、構成ファイルに加えて httaccess ファイルが使用されていました。これにより、ユーザーはそこにディレクティブを記述し、その設定がユーザー自身の設定によって上書きされない場合、このファイルが存在するディレクトリ以下に適用することができました。 httaccess ファイル。 mod_php モードでは、これらのファイルを使用して、個々のサイトまたはディレクトリの多くの PHP オプションを変更することもできます。
変更を受け入れるために Web サーバーを再起動する必要はありません。エラーが発生した場合、このサイト (またはその一部) のみが動作を停止します。 さらに、トレーニングを受けていないユーザーでも、単純なテキスト ファイルに変更を加えてサイト上のフォルダーに保存することができ、サーバー全体にとって安全です。
これらすべての利点の組み合わせにより、Apache は広く使用され、ユニバーサル Web サーバーとしての地位を獲得しました。 他のソリューションは、より高速で、より経済的で、優れている可能性がありますが、タスクに合わせて常にカスタマイズする必要があるため、主にターゲット プロジェクトで使用されており、マス セグメントでは Apache が優勢であり、代替手段はありません。
メリットについて説明したので、デメリットに移りましょう。 それらの中には、単にコインの裏側にあるものもあります。 アプリケーション サーバーが Web サーバーの一部であるという事実は、パフォーマンスと構成の容易さの点で利点がありますが、同時にセキュリティの点で制限されます。アプリケーション サーバーは常に Web サーバーに代わって動作し、システムの柔軟性の点でも制限されます。 Web サーバーとアプリケーション サーバーを異なるホストに分散することはできますが、スクリプト言語のバージョンや設定が異なるサーバーを使用することはできません。
2 番目の欠点は、リソースの消費量が増えることです。 CGI スキームでは、アプリケーション サーバーがページを生成して Web サーバーに送信し、リソースを解放します。Apache と mod_php の組み合わせにより、Web サーバーがページのコンテンツをクライアントに返すまでアプリケーション サーバーのリソースがビジー状態に保たれます。 クライアントが遅い場合、リソースはサービスの継続時間全体にわたってビジー状態になります。 Nginx が高速クライアントの役割を果たす Apache の前に配置されることが多いのはこのためです。これにより、Apache はページを迅速に提供し、クライアントとの対話をより経済的な Nginx に移すことでリソースを解放できます。
結論
現代のテクノロジーの全範囲を 1 つの記事でカバーすることは不可能であるため、主要なテクノロジーのみに焦点を当て、いくつかのことは意図的に舞台裏に残し、大幅な簡略化にも努めました。 この分野の研究を始めるときは、間違いなく、このトピックについてのより深い研究が必要になりますが、新しい知識を認識するには、特定の理論的基礎が必要であり、それをこの資料で築こうとしました。
コード作成時のエラーの制御
検索エンジンにおけるウェブサイトの監視
将来のプロジェクトのスケッチを作成する
デザインや Web 開発の問題を解決するオンライン サービス
- サーバーの操作
Apacheサーバーのインストール
Denver や同様のプログラムのおかげで、コンピュータにローカル サーバーをインストールして構成することが非常に簡単になりました。 これについては多くのことが書かれており、インストールプロセス自体は直感的です。 ただし、補助ソフトウェアの助けを借りずに、作業に必要なものだけをインストールしてサーバーを構成できます。 この記事では、Apache サーバーをコンピューターにインストールし、さらに作業できるように構成する方法について説明します。
PHPのインストールと設定
Apache サーバーのインストールと構成に関するすべての作業が終わったら、コンピューターへの PHP のインストールと、さらなる作業のための構成を開始できます。
データベースサーバー (MySQL) のインストールと構成
データベースを使用して Web サイトを作成する場合 (おそらくこれが当てはまります)、完全に操作するには、Apache と PHP に加えて、データベース サーバーをインストールして構成する必要があります。この場合は MySQL です。 これがこの記事で説明する内容です。
phpMyAdminのインストールと設定
コマンド ラインを使用してデータベースを操作することに不便を感じない人、およびコマンド ラインを介してデータベースを操作する方法を知っている人には、この手順は必要ありません。 他の皆さんのために、ここではローカル サーバーをセットアップする最後の手順について説明します。データベースの操作を大幅に容易にするグラフィカル シェルをインストールして構成します。 phpMyAdmin について説明します。
新しい本『ソーシャル メディア コンテンツ マーケティング: フォロワーの頭の中を理解し、ブランドに恋をさせる方法』をリリースしました。
Web サーバーは、ユーザーからのリクエストを受け取り、ドキュメント、ページ、サイトなどの応答を提供するサーバーです。
私たちのチャンネルの他のビデオ - SEMANTICA でインターネット マーケティングを学びましょう
あらゆるコンピュータをサーバーに変えることができます。 これを行うには、特別なシェルをインストールする必要があります。
技術的な部分の要件は、割り当てられたリソースの数と速度要件によって決まります。 サイズが大きいほど、コンピュータはより強力になる必要があります。
わかりやすくするために、たとえ話をしてみましょう。 あなたは図書館に行き、本をくださいと頼みます。 司書はあなたが必要とする本を見つけてあなたに渡します。 ライブラリはサーバーであり、すべてのデータがそこに保存されます。 ライブラリアンは、リクエストを受け入れ、レスポンスを送信したシェルです。 あなたはクライアントです。
リンクをクリックするのと同様に、図書館員に詳細を問い合わせることができます。 違いは、インターネット上の同じリソースを無制限の数のユーザーが同時に読み取ることができることです。
顧客サービスも同様の原則に従って行われます。本を取りに来たとき、図書館員（検索エンジン）に質問したり、索引（Yandex カタログ）を調べたりすることができます。 これは、必要な情報を見つけるのに役立ちます。
Webサーバーは何をするのですか?
その主なタスクは情報を保存することです。 ページ、ファイル、画像、テキスト コンテンツ。
タスク:
- リクエストを受け付けます。
- 特別なプログラミング言語でプログラムを実行します（サーバー）。
- Web ページを作成します。
- それらをユーザーに送り返します。
- 情報を保護します。
- 訪問者を識別します。
- リクエストのログを記録します。
- 他のタイプのリクエストを処理します: mailto など。
Web サーバーの動作を理解するには、ネットワーク上の情報転送の原理を理解する必要があります。 これはプロトコルと呼ばれるルールに基づいており、どの URL もタイプ (ftp、http://、https:// など) の指示で始まります。
ハイパーテキスト転送プロトコル - 転送プロトコル。 サイト ページは常にハイパーテキスト ドキュメントの形式になっています。 これは、サーバーまたはクライアント プログラムの最終結果です。
- ユーザーがアドレスを入力するかリンクをクリックすると、ブラウザはこれらのルールに従って情報をエンコードしてリクエストを作成します。
- このアドレスがバインドされているホストはサーバー プログラムを実行します。 それぞれが独自の機能を実行します。
- 受信したデータは復号化され、コマンドが実行されます。
- ハイパーテキストが生成され、エンコードされて送り返されます。
- ブラウザは応答を受信し、コードを HTML に変換して画面にページを表示します。
Webサーバーに必要なもの
すべてのリクエストを処理するマシンが必要です。 サーバーが耐えなければならない負荷を見積もります。 訪問者の数によって異なります。リクエストが多いほど、より多くの電力が必要になります。
ホスティングサービスを提供する特別な会社があります。 サーバーをレンタルしているんですね。 サイト ファイルをホストするためのクォータが与えられます。
ただし、簡単な Web サイトであれば、自分で作成することができます。
サーバーの問題が解決したら、静的 IP アドレスをサーバーにバインドする必要があります。
ドメイン名が登録され、DNS サービスによってアドレスが変換され、IP アドレス (たとえば、111.111.111.111) とドメイン名 (www.site.com) がリンクされると、サイトは Web サーバーで利用できるようになります。
最も一般的なサーバー
アパッチ
これは無料で自由に配布される製品であり、次のような多くの利点があります。
- 継続的な開発者サポート。
- PHP、Perl、Python、Ruby、ASP などのサーバー プログラミング言語を操作するためのモジュール。
- オープンソース。 さまざまなプログラマーが、ニーズに合わせて修正を行っています。 たとえば、ロシア語を話すコミュニティは、ロシア語のエンコードに適応させます。
- 。 元々は Unix 用に作成されましたが、現在は Windows、Mac OS、BSD、Linux、OS/2、および Novell NetWare でサポートされています。
- 安全性。
インストール中に、ホスト名 (例: localhost) を指定します。 任意の HTML ページを、Apachex.x フォルダー内にある htdocs フォルダーにコピーします (x.x はバージョン番号です)。 または、メモ帳でテキストを入力し、html 拡張子を付けて保存して作成します。
ファイルがフォルダーに表示されたら、ブラウザを開いてアドレス「localhost://ページ名.html」を入力します。 テキストが画面に表示されます - ページはサーバーから開かれます。 「サイトにアクセスできません」というエラーが表示された場合は、Apache が実行されていないことを意味します。 そのアイコンはトレイにあります。
それをクリックして「再生」を選択します。 この後はすべてうまくいきます。
NGNIX
その上で動作しているアクティブ サイトのシェアは 21.13% です (Netcraft 調査)。 主に大企業やプロの開発者 (Yandex、Mail.ru、Rambler など) によって使用されています。NGNIX は、大量の訪問者の負荷に耐えることができ、信頼性が高く、安全で、思慮深いです。
無料で配布されていますが、有料の Plus バージョンも登場しており、価格は 2,500 ドルからです。
IIS
その名声は、開発者の有名な名前によって保証されています。 これは Web サービスのセットであり、Windows に統合されています。 ネイティブ プログラミング プラットフォームは ASP.NET ですが、PHP などの代替プラットフォームも実装できます。
完全なホスティングには、Microsoft のサーバー オペレーティング システム (Windows Server) のインストールが必要です。 6 番目のバージョンはホスティングを目的としていませんでした。完全なサポートは 7 番目から始まりました。 これはオペレーティング システムとともに自動的に購入され、その特性に応じて異なります。
インストールパッケージ
初心者のプログラマや開発者向けに、数回クリックするだけで Web サーバーをコンピュータに展開できるツールが作成されています。
- オープンサーバー。 多くのデータベース、プログラミング言語とそのバージョン、および追加サービスを含むポータブルな開発環境。 たとえば、PhpMyAdmin データベースを操作するためのインターフェイスです。 現在、これが最も人気のある取り付けキットです。 フラッシュドライブからも動作します。 低速で無料ダウンロード。 100ルーブルの場合、速度は大幅に増加します。
- ザンプ。 積極的にサポートされているパッケージ: Apache、Php、Perl、MariaDB など。コントロール パネルがあります。 無料でダウンロードしてください。
- 。 Apache、PHP、MySQL、PhpMyAdmin など、必要なツールがすべて揃った非常に便利なセットです。 残念ながら、最新バージョンには古いディストリビューションが含まれています。 一般に、トレーニングにも適しています。 フォーラムから判断すると、このプロジェクトはサポートされなくなっています。
サーバー機器を含むあらゆる機器は、予期せぬ動作を開始することがあります。 この機器が新しいか、それとも数年間フル負荷で稼働しているかはまったく関係ありません。
故障や誤操作が発生するケースも多く、問題の診断が興味深いパズルになることもよくあります。
以下では、いくつかの興味深い、そして重要なケースについて説明します。
トラブルシューティング
問題の登録は、ほとんどの場合、顧客がチケット システムを通じてテクニカル サポートに連絡した後に発生します。クライアントから連絡があり、固定構成の専用サーバーをレンタルしている場合、診断を行って、問題の本質がソフトウェアではないことを確認します。
通常、クライアントはソフトウェアの問題を自分で解決しますが、いずれの場合でも、当社はシステム管理者の支援を提供するよう努めています。
問題がハードウェアにあることが明らかな場合 (たとえば、サーバーが RAM の一部を認識しない場合)、この場合は常に同様のサーバー プラットフォームを予備に用意します。
ハードウェアの問題が特定された場合は、障害が発生したサーバーからバックアップサーバーにディスクを移し、ネットワーク機器をわずかに再構成した後、サーバーを稼働させます。 したがって、データは失われず、アクセスの瞬間からダウンタイムは 20 分を超えません。
問題と解決策の例
サーバー上のネットワーク障害
障害が発生したサーバーからバックアップサーバーにディスクを転送した後、サーバー上のネットワークが動作しなくなる可能性があります。 これは通常、Debian や Ubuntu などの Linux オペレーティング システムを使用しているときに発生します。実際には、オペレーティング システムの初期インストール中に、ネットワーク カードの MAC アドレスが /etc/udev/rules.d/70-persistent-net.rules にある特別なファイルに書き込まれます。
オペレーティング システムが起動すると、このファイルはインターフェイス名を MAC アドレスにマップします。 サーバーをバックアップサーバーと交換すると、ネットワーク インターフェイスの MAC アドレスが一致しなくなり、サーバー上のネットワークが動作不能になります。
問題を解決するには、指定したファイルを削除してネットワークサービスを再起動するか、サーバーを再起動する必要があります。
オペレーティング システムは、このファイルを見つけられないと、同様のファイルを自動的に生成し、インターフェイスをネットワーク カードの新しい MAC アドレスと照合します。
この後、IP アドレスを再構成する必要はなく、ネットワークはすぐに動作し始めます。
浮遊凍結問題
ある日、サーバーが動作中にランダムにフリーズするという問題を抱えて診断のために当社にやって来ました。 BIOS と IPMI のログをチェックしましたが、空でエラーはありませんでした。 すべてのプロセッサ コアに 100% の負荷をかけ、同時に温度を監視するストレス テストを実施しました。30 分間の動作後にフリーズしてしまいました。同時に、プロセッサーは正常に動作し、負荷下でも温度は標準値を超えず、すべてのクーラーは正常に動作しました。 問題は過熱ではないことが明らかになりました。
次に、RAM モジュールの障害の可能性を排除する必要があるため、非常に人気のある Memtest86+ を使用してサーバーのメモリ テストを実施しました。 約 20 分後、予想どおりサーバーがクラッシュし、RAM モジュールの 1 つでエラーが発生しました。
モジュールを新しいものに交換した後、サーバーを再度テストしましたが、サーバーが再びフリーズし、別の RAM モジュールでエラーが発生するという大失敗が待っていました。 彼らも彼の代わりになった。 別のテスト - 再びフリーズし、再び RAM でエラーが発生しました。 RAM スロットを注意深く検査した結果、欠陥は見つかりませんでした。
残っている可能性のある犯人は 1 つだけです - 中央プロセッサです。 実際のところ、RAM コントローラーはプロセッサー内にあり、このコントローラーが故障する可能性があります。
プロセッサを取り外した後、私たちは悲惨な状況を発見しました。ソケットの 1 つのピンが上部で折れており、折れたピンの先端が文字通りプロセッサの接触パッドにくっついていました。 その結果、サーバーに負荷がかかっていないときは正常に動作していましたが、プロセッサーの温度が上昇すると接点が切れてしまい、RAMコントローラーが正常に動作しなくなり、フリーズが発生してしまいました。
この問題はマザーボードを交換することで最終的に解決されました。残念なことに、壊れたソケットピンを修復することはできず、これはすでにサービスセンターの仕事となっているためです。
OS インストール中に仮想サーバーがフリーズする
機器メーカーがハードウェア アーキテクチャを変更し始め、古いテクノロジのサポートを放棄して新しいテクノロジを支持すると、非常に面白いケースが発生します。Windows Server 2008 R2 オペレーティング システムをインストールしようとするとサーバーがフリーズするという苦情がユーザーから寄せられました。 インストーラーが正常に実行された後、サーバーは KVM コンソールのマウスとキーボードに応答しなくなりました。 問題を特定するために、物理的なマウスとキーボードをサーバーに接続しました。すべてが同じで、インストーラーが起動したり、入力デバイスに応答しなくなったりします。
当時、このサーバーは、Supermicro 製の X11SSL-f マザーボードをベースにした最初のサーバーの 1 つでした。 BIOS 設定には興味深い項目が 1 つありました。Windows 7 のインストールを無効に設定しました。 Windows 7、2008、および 2008 R2 は同じインストーラーに展開されているため、このパラメーターを有効に設定すると、奇跡的にマウスとキーボードが最終的に動作し始めました。 しかし、これはオペレーティング システムのインストールに関する壮大な出来事の始まりにすぎませんでした。
インストールするディスクを選択するときに、ディスクが 1 つも表示されず、さらに、追加のドライバーをインストールする必要があるというエラー メッセージが表示されました。 オペレーティング システムは USB フラッシュ ドライブからインストールされており、インターネットで簡単に検索したところ、インストール プログラムが USB 3.0 コントローラ用のドライバを見つけられない場合にこの影響が発生することがわかりました。
Wikipedia によると、この問題は BIOS で USB 3.0 (XHCI コントローラー) のサポートを無効にすることで解決されると報告されています。 マザーボードのドキュメントを開いたとき、驚きが私たちを待っていました。開発者は、EHCI (拡張ホスト コントローラー インターフェイス) コントローラーを完全に放棄し、XHCI (eXtensible ホスト コントローラー インターフェイス) を使用することを決定しました。 つまり、このマザーボード上のすべての USB ポートは USB 3.0 ポートです。 また、XHCI コントローラーを無効にすると、入力デバイスも無効になり、サーバーでの作業が不可能になり、それに応じてオペレーティング システムのインストールができなくなります。
サーバー プラットフォームには CD/DVD ディスクを読み取るためのドライブが装備されていなかったため、この問題に対する唯一の解決策は、ドライバーをオペレーティング システムのディストリビューションに直接統合することでした。 USB 3.0 コントローラー ドライバーを統合し、インストール イメージを再構築することによってのみ、このサーバーに Windows Server 2008 R2 をインストールすることができました。エンジニアが無駄な試みに不必要な時間を浪費しないように、このケースはナレッジ ベースに含まれていました。
さらに面白いのは、クライアントが配置用の機器を持ち込んできたときに、それが期待どおりに動作しない場合です。 これはまさに、Dell PowerVault シリーズのディスク シェルフで起こったことです。
このデバイスは、2 つのディスク コントローラと iSCSI プロトコル経由で動作するネットワーク インターフェイスを備えたデータ ストレージ システムです。 これらのインターフェイスに加えて、リモート管理用の MGMT ポートがあります。
ホスト機器向けのサービスの中には、リモート サーバー管理ツールに接続する必要がある場合に注文できる特別なサービス「追加 10 Mbit/s ポート」があります。 これらのファンドはさまざまな名前で呼ばれています。
- ヒューレット・パッカードの「iLO」。
- デルの「iDrac」。
- Supermicro の IPMI。
速度を制限するために、ポートは単純に 10BASE-T として設定され、最大速度 10 Mbps で有効になります。 すべての準備が整った後、ディスク シェルフの MGMT ポートに接続しましたが、クライアントはほとんどすぐに何も機能していないと報告しました。
スイッチポートの状態を確認したところ、「物理リンクがダウンしています」という不愉快なメッセージが表示されていました。 このメッセージは、スイッチとそれに接続されているクライアント機器との間の物理接続に問題があることを示します。
コネクタの圧着不良、コネクタの破損、ケーブル内のワイヤの断線など、特にリンクの欠如につながる問題の小さなリストです。 もちろん、当社のエンジニアはすぐにツイストペアテスターを使用して接続をチェックしました。 すべてのワイヤは完全に接続されており、ケーブルの両端は完全に圧着されていました。 さらに、テスト用ラップトップをこのケーブルに接続すると、予想どおり 10 Mbit/s の速度で接続できました。 問題はクライアントの機器側にあることが明らかになりました。
私たちは常にクライアントの問題解決を支援しようとしているため、リンクがない原因を正確に把握することにしました。 MGMT ポート コネクタを注意深く検査しました。すべてが正常です。
ソフトウェア側からこのポートを「消す」ことが可能かどうかを明らかにするために、メーカーの Web サイトで元の操作説明書を見つけました。 ただし、この可能性は提供されませんでした。いずれの場合でも、ポートは自動的に引き上げられました。 このような機器は常に Auto-MDI(X) をサポートする必要があるという事実にもかかわらず、言い換えれば、接続されているケーブルが通常かクロスオーバーであるかを正確に判断する必要があるにもかかわらず、実験のために、クロスオーバーを圧着して同じスイッチ ポートに含めました。 スイッチポートにデュプレックスパラメータを強制しようとしました。 効果はゼロでした。リンクはなく、アイデアはすでに枯渇していました。
ここで、エンジニアの 1 人は、その機器は 10BASE-T をサポートしておらず、100BASE-TX または 1000BASE-X でのみ動作するという完全に直観に反する仮定を立てました。 通常、最も安価なデバイスであっても、どのポートも 10BASE-T と互換性があり、当初エンジニアの仮定は「フィクション」として無視されましたが、絶望的な気持ちから、彼らはポートを 100BASE-TX に切り替えてみることにしました。
私たちの驚きはとどまることを知らず、リンクは即座に立ち上がりました。 MGMT ポートで 10BASE-T がサポートされない正確な原因は依然として謎のままです。 このようなケースは非常にまれですが、実際に起こります。
クライアントも私たちと同じように驚き、問題を解決できたことにとても感謝していました。 したがって、ポートを 100BASE-TX のままにし、内蔵の速度制限メカニズムを使用してポートの速度を直接制限しました。
冷却タービンの故障
ある日、クライアントが当社を訪れ、サーバーを取り外してサービスエリアに移動してほしいと依頼しました。 エンジニアたちはすべてを行い、彼に機器を任せました。 1 時間が経過し、2 時間、3 時間と経過しましたが、クライアントはサーバーの起動/停止を繰り返したので、何が問題なのかを尋ねました。Hewlett-Packard サーバーの 6 つの冷却タービンのうち 2 つが故障したことが判明しました。 サーバーの電源がオンになり、冷却エラーが表示され、すぐに電源がオフになります。 この場合、サーバーは重要なサービスを備えたハイパーバイザーをホストします。 サービスの通常の動作を復元するには、仮想マシンを別の物理ノードに緊急に移行する必要がありました。
私たちは次の方法でクライアントを支援することにしました。 通常、サーバーは回転数を読み取るだけで、冷却ファンに問題がないことがわかります。 同時に、もちろん、ヒューレット・パッカードのエンジニアは、元のタービンをアナログ、つまり非標準のコネクタ、非標準のピン配列に置き換えることが不可能であることを保証するためにあらゆる手を尽くしました。
このような部品のオリジナルの価格は約 100 ドルで、簡単に購入することはできません。海外から注文する必要があります。 幸いなことに、元のピン配列を持つ回路をインターネットで見つけ、ピンの 1 つが 1 秒あたりのエンジン回転数を読み取る役割を担っていることがわかりました。
残りは技術の問題でした。プロトタイピング用にいくつかのワイヤを用意し (偶然にも手元にありました。エンジニアの何人かは Arduino に熱心でした)、隣接する稼働中のタービンのピンを故障したタービンのコネクタに接続するだけでした。 。 サーバーが起動し、クライアントは最終的に仮想マシンを移行してサービスを開始することができました。
もちろん、これはすべてクライアントの責任のもとで行われたものですが、最終的にはこのような非標準的な動きによってダウンタイムを最小限に抑えることができました。
ディスクはどこにありますか?
場合によっては、問題の原因が自明ではないため、その原因を見つけるのに非常に時間がかかることがあります。 これは、クライアントの 1 人がランダムなディスク障害とサーバーのフリーズについて苦情を言ったときに起こったことです。 ハードウェア プラットフォーム - ケース 847 (4U フォーム ファクター) の Supermicro、36 台のドライブを接続するためのケージ付き。 サーバーには 3 つの同一の Adaptec RAID コントローラがインストールされており、それぞれに 12 個のディスクが接続されていました。 問題が発生すると、サーバーはランダムな数のディスクを認識しなくなり、フリーズしました。 サーバーは運用を停止され、診断が開始されました。最初にわかったのは、ディスクが 1 台のコントローラーだけで落ちているということでした。 同時に、「ドロップされたドライブ」はネイティブの Adaptec 管理ユーティリティのリストから消え、サーバーの電源が完全にオフになってから再度接続された場合にのみ再び表示されます。 最初に思いついたのはコントローラーのソフトウェアでした。 3 つのコントローラはすべてわずかに異なるファームウェアを持っていたため、すべてのコントローラに同じファームウェア バージョンをインストールすることが決定されました。 それを実行し、サーバーを最大負荷モードで実行しました。すべてが期待どおりに機能しました。 問題が解決済みとしてマークされた後、サーバーは運用のためにクライアントに戻されました。
2週間後、再び同じ問題が発生しました。 コントローラーを同様のものに交換することが決定されました。 私たちはそれを完成させ、フラッシュし、接続し、テストしました。 問題は残りました。数日後、新しいコントローラ上のすべてのディスクが外れ、サーバーは安全にフリーズしました。
コントローラーを別のスロットに再取り付けし、バックプレーンとコントローラーからバックプレーンへの SATA ケーブルを交換しました。 1週間テストを続けたところ、再びディスクが外れ、サーバーが再びフリーズしました。 Adaptec サポートに連絡しても結果は得られませんでした。3 つのコントローラすべてをチェックしたところ、問題は見つかりませんでした。 マザーボードを交換し、プラットフォームをほぼゼロから再構築しました。 少しでも疑問を感じたものはすべて新品と交換しました。 そして問題は再び現れました。 神秘主義、それ以上のものではありません。
この問題は、各ディスクを個別にチェックし始めたときに偶然解決されました。 特定の負荷がかかると、ドライブの 1 つがヘッドをぶつけ始め、アラームが表示されなかったにもかかわらず、SATA ポートに短絡しました。 同時に、コントローラーは一部のディスクを認識しなくなり、電源が再接続された場合にのみディスクを再び認識し始めました。 このようにして、1 台のディスクに障害が発生すると、サーバー プラットフォーム全体がダウンしてしまいました。
結論
もちろん、これは当社のエンジニアが解決した興味深い状況のほんの一部にすぎません。 一部の問題は、特に発生した障害のヒントがログにない場合、「把握」するのが非常に困難です。 しかし、そのような状況は、エンジニアがサーバー機器の設計を詳細に理解し、問題に対するさまざまな解決策を見つけることを刺激します。これらは私たちの診療現場で起こった面白い事例です。
あなたはどれに遭遇しましたか？ コメントを歓迎します。
