序章

チュートリアルのこの部分では、サンプルのPHPアプリケーション、WordPress、およびプライベートDNSをデプロイします。

ユーザーは、ドメイン名を介してHTTPS経由でアプリケーションにアクセスします。 「https://www.example.com」、これはロードバランサーを指します。 ロードバランサーは、データベースサーバーに接続するアプリケーションサーバーへのリバースプロキシとして機能します。 プライベートDNSを使用すると、名前を使用してサーバーのプライベートネットワークアドレスを参照できるようになり、サーバーの構成プロセスが容易になります。

6台のサーバーで今説明したコンポーネントを次の順序でセットアップします。

  • プライベートDNS(ns1およびns2)
  • データベースサーバー(db1)
  • アプリケーションサーバー(app1およびapp2)
  • ロードバランサー(lb1)

DNSの設定を始めましょう。

プライベートDNSサーバー

アドレスに名前を使用すると、使用しているサーバーを特定するのに役立ち、無数の構成ファイルを更新する代わりにDNSレコードを(1か所で)更新するだけでサーバーを置き換えることができるため、より大規模なサーバー設定の保守に不可欠になります。 IPアドレス。 セットアップでは、DNSをセットアップして、サーバーのプライベートネットワークアドレスをIPアドレスではなく名前で参照できるようにします。

各サーバーのプライベートネットワークアドレスは、「nyc3.example.com」サブドメインの下のホスト名で参照されます。 たとえば、データベースサーバーのプライベートネットワークアドレスは「 db1.nyc3.example.com 」であり、これはそのプライベートIPアドレスに解決されます。 サブドメインの例はほぼ完全に任意であり、通常は論理的な編成の目的に基づいて選択されることに注意してください。 この場合、「nyc3」はサーバーがNYC3データセンターにあることを示し、「example.com」はアプリケーションのドメイン名です。

このチュートリアルに従い、セットアップ内の各サーバーのDNSレコードを追加して、これをセットアップします。

DNSチュートリアルを完了すると、ns1ns2の2つのBINDサーバーが必要になります。 セットアップ内のすべてのサーバーのプライベートIPアドレスがすでにわかっている場合は、今すぐDNSに追加してください。 それ以外の場合は、サーバーを作成するときに適切なDNSレコードを追加します。

これで、データベースサーバーをセットアップする準備が整いました。

データベースサーバーのセットアップ

アプリケーションサーバーの負荷を分散したいからです。 ApacheとPHPを実行している場合は、データベースを別のサーバーにセットアップして、アプリケーションサーバーからデータベースを分離する必要があります。 このブログ投稿で説明されているように、データベースをアプリケーションから分離することは、多くの種類のアプリケーションを水平方向にスケーリングする前の重要なステップです: PHPアプリケーションの水平方向のスケーリング:実用的な概要

このセクションでは、データベースサーバーをセットアップするために必要なすべての手順について説明しますが、このチュートリアルでは、PHPアプリケーション用のリモートの分離されたMySQLデータベースサーバーのセットアップについて詳しく知ることができます。リモートMySQLデータベースをセットアップする方法[ X241X]。

MySQLをインストールする

データベースサーバーdb1に、MySQLサーバーをインストールします。

  1. sudo apt-get update
  2. sudo apt-get -y install mysql-server

プロンプトで目的のMySQLルートパスワードを入力します。

今実行します:

  1. sudo mysql_install_db
  2. sudo mysql_secure_installation

上記の手順で設定したMySQL管理者のパスワードを入力する必要があります。 その後、そのパスワードを変更するかどうかを尋ねられます。 現在のパスワードに満足している場合は、「N」を入力してください。 残りの質問にはデフォルトで答えてください。

プライベートネットワークインターフェイスでリッスンするようにMySQLを構成する

MySQL構成ファイルを開きます。

  1. sudo vi /etc/mysql/my.cnf

を見つける bind-address 設定し、データベースサーバーのプライベートネットワークアドレスのアドレスに変更します。

/etc/mysql/my.cnf
bind-address            = db1.nyc3.example.com

保存して終了。

MySQLを再起動します。

  1. sudo service mysql restart

データベースとデータベースユーザーの設定

次に、アプリケーションサーバーが接続に使用するデータベースとデータベースユーザーを作成する必要があります。

MySQLコンソールに入ります:

  1. mysql -u root -p

プロンプトでMySQLルートパスワードを入力します。

MySQLプロンプトで、アプリケーションのデータベースを作成します。

  1. CREATE DATABASE app;

MySQLは、ユーザーを接続元のサーバーに関連付けます。 この例では、接続する2つのアプリケーションサーバーがあるため、それぞれのユーザーを作成する必要があります。 各アプリケーションサーバー(app1およびapp2)のプライベートネットワークアドレスから接続できるデータベースユーザー(この例では「appuser」)を作成します。 ユーザーごとに同じパスワードを使用する必要があります。

  1. CREATE USER 'appuser'@'app1.nyc3.example.com' IDENTIFIED BY 'password';
  2. CREATE USER 'appuser'@'app2.nyc3.example.com' IDENTIFIED BY 'password';

最終的なデータベースユーザー権限は後で構成しますが、appuserappデータベースの完全な制御を与えましょう。

  1. GRANT ALL PRIVILEGES ON app.* TO 'appuser'@'app1.nyc3.example.com';
  2. GRANT ALL PRIVILEGES ON app.* TO 'appuser'@'app2.nyc3.example.com';
  3. FLUSH PRIVILEGES;

これらの緩和された特権により、アプリケーションのインストーラーがデータベースにアプリケーションをインストールできるようになります。 3つ以上のアプリケーションサーバーがある場合は、ここで必要なすべてのデータベースユーザーを作成する必要があります。

今すぐMySQLプロンプトを終了します。

  1. exit

データベースサーバーのセットアップが完了しました。 アプリケーションサーバーをセットアップしましょう。

アプリケーションサーバーのセットアップ

アプリケーションサーバーは、データベースサーバーに接続するアプリケーションのコードを実行します。 サンプルアプリケーションはWordPressです。これは、ApacheやNginxなどのWebサーバーを介して提供されるPHPアプリケーションです。 アプリケーションサーバーの負荷を分散したいので、2つの同じサーバーをセットアップします。

このセクションでは、アプリケーションサーバーをセットアップするために必要なすべての手順について説明しますが、このトピックについては、 Webサーバーのセットアップセクションから始まる次のチュートリアルで詳しく説明します:セットアップ方法リモートデータベース

ApacheとPHPをインストールする

app1app2の両方のアプリケーションサーバーに、ApacheとPHPをインストールします。

  1. sudo apt-get update
  2. sudo apt-get -y install apache2 php5-mysql php5 libapache2-mod-php5 php5-mcrypt

Apacheを構成する

ロードバランサーサーバーでHAProxyを使用してSSLターミネーションを処理するため、ユーザーがアプリケーションサーバーに直接アクセスすることは望ましくありません。 そのため、Apacheを各サーバーのプライベートネットワークアドレスにバインドします。

各アプリケーションサーバーapp1およびapp2で、Apacheポート構成ファイルを開きます。 デフォルトでは、これは ports.conf ファイル:

  1. sudo vi /etc/apache2/ports.conf

と言う行を見つけます Listen 80、次のようにプライベートIPアドレスを追加します(サーバーの実際のIPアドレスに置き換えます)。

Apache Ports.conf —プライベートインターフェイスでリッスンします
Listen private_IP:80

保存して終了。 これにより、プライベートネットワークインターフェイスでのみリッスンするようにApacheが構成されます。つまり、パブリックIPアドレスまたはホスト名からアクセスすることはできません。

Apacheを再起動して、変更を有効にします。

  1. sudo service apache2 restart

Apacheは、アプリケーションサーバーのプライベートネットワークアドレスからのみアクセスできるようになりました。 ここで、ユーザーリクエストを送信するようにロードバランサーを構成します。

アプリケーションのダウンロードと構成

この例では、アプリケーションとしてWordPressを使用しています。 別のPHPアプリケーションを使用している場合は、それをダウンロードして、関連する構成を実行します(例: データベース接続情報)、次のセクションにスキップします。

最初のアプリケーションサーバーapp1で、WordPressアーカイブをダウンロードします。

  1. cd ~
  2. wget http://wordpress.org/latest.tar.gz

WordPressアーカイブを抽出します。

  1. tar xvf latest.tar.gz

抽出したディレクトリに移動します。

  1. cd wordpress

WordPressには、アップロード用にディレクトリを作成する必要があります。 wp-content/uploads. 今それをやってみましょう:

  1. mkdir wp-content/uploads

サンプルのWordPress構成ファイルをテンプレートとして使用します。 適切な場所にコピーします。

  1. cp wp-config-sample.php wp-config.php

次に、編集用の構成ファイルを開きます。

  1. vi wp-config.php

次の行で強調表示されている情報を変更して、WordPressデータベース接続を構成します。

wp-config.php
/** The name of the database for WordPress */
define('DB_NAME', 'app');

/** MySQL database username */
define('DB_USER', 'appuser');

/** MySQL database password */
define('DB_PASSWORD', 'password');

/** MySQL hostname */
define('DB_HOST', 'db1.nyc3.example..com');

ロードバランサーサーバーでTLS/SSL暗号化を使用するため、次の行を追加して、WordPressがSSLを使用しているリバースプロキシの背後にあることを認識できるようにする必要があります。

define('FORCE_SSL_ADMIN', true);
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
       $_SERVER['HTTPS']='on';

また、必要に応じてCookieを無効にできるように、キーとソルトを更新することもできます。 ここではこれについては説明しませんが、すべてのアプリケーションサーバーで同一であることを確認してください。

保存して終了。

これでWordPressが構成されましたが、そのファイルを適切な場所にコピーして、Webサーバーソフトウェアで提供する必要があります。

アプリケーションファイルをドキュメントルートにコピーする

アプリケーションを構成したので、それをApacheのドキュメントルートにコピーする必要があります。ここで、アプリケーションをWebサイトの訪問者に提供できます。

ApacheのDocumentRootのデフォルトの場所は /var/www/html、したがって、この例ではそれを使用します。

まず、デフォルトを削除します index.html ファイル:

  1. sudo rm /var/www/html/index.html

次に、rsyncを使用してWordPressファイルをにコピーします /var/www/html、 そして、作ります www-data (Apacheを実行するユーザー)所有者:

  1. sudo rsync -avP ~/wordpress/ /var/www/html
  2. sudo chgrp -R www-data /var/www/html/*

最初のアプリケーションサーバーapp1の準備が整いました。 他のアプリケーションサーバーをセットアップします。

アプリケーションファイルを他のサーバーに複製する

さまざまなアプリケーションサーバー間でアプリケーションのファイルの一貫性を保つために、Webサーバーのドキュメントルートのファイルレプリケーションを設定する必要があります。 WordPressの場合、Webインターフェイスを使用してファイルをアップロードし、プラグインをインストールすると、リクエストを処理する特定のサーバーにファイルが保存されます。 これらのファイルがすべてのアプリケーションサーバーに複製されていない場合、一部のユーザーには、画像が欠落し、プラグインが壊れているページが提供されます。 PHPアプリケーションがWordPressでなく、そのデータを保存していない場合(例: アップロードされたファイルまたはダウンロードされたプラグイン)をアプリケーションサーバーにインストールすると、アプリケーションファイルを手動で一度だけコピーできます。 この場合は、rsyncを使用してアプリケーションファイルをapp1からapp2にコピーします。

GlusterFSを使用して、必要なファイルの複製ボリュームを作成できます。これは、このチュートリアルのWebアプリケーションファイルの同期セクションで説明されています。WordPressアプリケーションサーバーのロードバランサーとしてHAProxyを使用する方法。 指示に従い(DNSが処理するため、 Hostsファイルの編集セクションをスキップします)、app1app2の間のレプリケーションを設定します。

レプリケーションが適切に設定されたら、両方のアプリケーションサーバーを適切に構成する必要があります。 ロードバランサーをセットアップしましょう。

ロードバランサーサーバーのセットアップ

ロードバランサーサーバーはHAProxyを実行します。これは、アプリケーションサーバーのリバースプロキシロードバランサーとして機能します。 ユーザーは、ロードバランサーサーバーを介して次のようなURLを介してアプリケーションにアクセスします。 https://www.example.com.

このセクションでは、ロードバランサーサーバーをセットアップするために必要なすべての手順について説明しますが、このテーマについては、次のチュートリアルで詳しく説明します。

SSL証明書をコピーする

ロードバランサーサーバーlb1でこれらの手順を実行します。

SSL証明書(パート1の前提条件の1つ)を含むディレクトリで、証明書、中間CA証明書、および証明書のキーを1つに結合します。 .pem ファイル。 たとえば(私たちの証明書は /root/certs:

  1. cd /root/certs
  2. cat www.example.com.crt CAintermediate.ca-bundle www.example.com.key > www.example.com.pem

次に、pemファイルをにコピーします /etc/ssl/private:

  1. sudo cp www.example.com.pem /etc/ssl/private/
  2. ```
  3. This file will be used by HAProxy for SSL termination.
  4. ### Install HAProxy
  5. On the load balancer server, **lb1**, install HAProxy:
  6. ```command
  7. sudo add-apt-repository ppa:vbernat/haproxy-1.5
  8. sudo apt-get update
  9. sudo apt-get -y install haproxy
  10. ```
  11. Now let's configure HAProxy.
  12. ### HAProxy Configuration
  13. We need to configure HAProxy with some reasonable settings, SSL termination, and the appropriate frontends and backends to make it work with our application servers.
  14. Open the HAProxy configuration file for editing:
  15. ```command
  16. sudo vi /etc/haproxy/haproxy.cfg
  17. ```
  18. #### HAProxy Configuration: General Settings
  19. The first thing you will want to do is set maxconn to a reasonable number. This setting affects how many concurrent connections HAProxy will allow, which can affect QoS and prevent your web servers from crashing from trying to serve too many requests. You will need to play around with it to find what works for your environment. Add the following line (with a value you think is reasonable) to the global section of the configuration:
  20. ```
  21. [label haproxy.cfg — maxconn]
  22. maxconn 2048
  23. ```
  24. Add this line, to configure the maximum size of temporary DHE keys that are generated:
  25. ```
  26. [label haproxy.cfg — tune.ssl.default-dh-param]
  27. tune.ssl.default-dh-param 2048
  28. ```
  29. Next, in the defaults section, add the following lines under the line that says mode http:
  30. ```
  31. [label haproxy.cfg ]
  32. option forwardfor
  33. option http-server-close
  34. ```
  35. If you would like to enable the HAProxy stats page, add the following lines in the defaults section (substitute user and password with secure values):
  36. ```
  37. [label haproxy.cfg ]
  38. stats enable
  39. stats uri /stats
  40. stats realm Haproxy\ Statistics
  41. stats auth user:password
  42. ```
  43. This will allow you to look at the HAProxy stats page by going to your domain on /stats (e.g. "https://www.example.com/stats").
  44. Do not close the config file yet! We will add the proxy configuration next.
  45. #### HAProxy Configuration: Proxies
  46. The first thing we want to add is a frontend to handle incoming HTTP connections. At the end of the file, let's add a frontend called www-http:
  47. ```
  48. frontend www-http
  49. bind www.example.com:80
  50. reqadd X-Forwarded-Proto:\ http
  51. default_backend app-backend
  52. ```
  53. The purpose of this frontend is to accept HTTP connections so they can be redirected to HTTPS.
  54. Now add a frontend to handle the incoming HTTPS connections. Make sure to specify the appropriate `pem` certificate:
  55. ```
  56. frontend www-https
  57. bind www.example.com:443 ssl crt /etc/ssl/private/www.example.com.pem
  58. reqadd X-Forwarded-Proto:\ https
  59. default_backend app-backend
  60. ```
  61. After you are finished configuring the frontends, continue adding your backend by adding the following lines:
  62. ```
  63. backend app-backend
  64. redirect scheme https if !{ ssl_fc }
  65. server app1 app1.nyc3.example.com:80 check
  66. server app2 app2.nyc3.example.com:80 check
  67. ```
  68. This backend specifies which application servers to send the load balanced traffic to. Also, the `redirect scheme https` line tells it to redirect HTTP connections to HTTPS.
  69. Now save and exit haproxy.cfg. HAProxy is now ready to be started, but let's enable logging first.
  70. ### Enable HAProxy Logging
  71. Open the rsyslog configuration file:
  72. ```command
  73. sudo vi /etc/rsyslog.conf
  74. ```
  75. Then find the following lines and uncomment them to enable UDP syslog reception. It should look like the following when you're done:
  76. ```
  77. [label /etc/rsyslog.conf]
  78. $ModLoad imudp
  79. $UDPServerRun 514
  80. $UDPServerAddress 127.0.0.1
  81. ```
  82. Now restart rsyslog to enable the new configuration:
  83. ```
  84. sudo service rsyslog restart
  85. ```
  86. HAProxy logging is is now enabled! The log file will be created at `/var/log/haproxy.log` once HAProxy is started.
  87. ### Restart HAProxy
  88. Restart HAProxy to put the changes into effect:
  89. ```command
  90. sudo service haproxy restart
  91. ```
  92. Our load balancer is now set up.
  93. Now we need to run the application's install script.
  94. ## Install WordPress
  95. We must run the WordPress installation script, which prepares the database for its use, before we can use it.
  96. Open your site in a web browser:
  97. ```
  98. [secondary_label Open in a Web Browser]
  99. https://www.example.com/wp-admin/install.php
  100. ```
  101. This will display the WordPress installation screen. Fill out the forms and click the **Install WordPress** button.
  102. After WordPress installs, the application is ready to be used.
  103. ## Conclusion
  104. The servers that comprise your application are now set up, and your application is ready to be used. You may log in as the admin user, and your users may access the site over HTTPS via the proper domain name.
  105. Be sure to test out your application and make sure that it works as expected before moving on.
  106. Continue to the next tutorial to start working on the recovery plan for your production application setup: [Building for Production: Web Applications — Recovery Planning](building-for-production-web-applications-recovery-planning).