序章

この6部構成のチュートリアルでは、マルチサーバーの実稼働アプリケーションのセットアップを最初から構築する方法を示します。 最終的なセットアップは、バックアップ、監視、および集中ログシステムによってサポートされます。これにより、問題を検出して回復できるようになります。 このシリーズの最終的な目標は、スタンドアロンのシステム管理の概念に基づいて構築し、実稼働サーバーのセットアップを作成する際の実際的な考慮事項のいくつかを紹介することです。

このシリーズで取り上げる概念のいくつかを確認することに興味がある場合は、次のチュートリアルをお読みください。

リンクされた記事は本番アプリケーションのセットアップの一般的なガイドラインを提供しますが、このシリーズでは、サンプルアプリケーションを最初から最後まで計画およびセットアップする方法を示します。 完全に異なるテクノロジースタックで別のアプリケーションを実行している場合でも、これが独自の本番サーバー環境の計画と実装に役立つことを願っています。 このチュートリアルは多くの異なるシステム管理トピックをカバーしているため、補足情報を提供する外部のサポート記事に詳細な説明を延期することがよくあります。

私たちの目標

この一連のチュートリアルの終わりまでに、 https://www.example.com/ からアクセスできる、PHPアプリケーション（デモ用のWordPress）用の本番サーバーのセットアップが完了します。 また、運用アプリケーションサーバーをサポートするサーバーも含まれます。 最終的なセットアップは次のようになります（プライベートDNSとリモートバックアップは図には示されていません）。

この設定では、アプリケーションボックス内のサーバーは、アプリケーションが正しく実行されるために不可欠であると見なされます。 リカバリプランとリモートバックアップサーバーを除いて、残りのコンポーネント（バックアップ、監視、およびログ記録）は、運用アプリケーションのセットアップをサポートするために追加されます。 各コンポーネントは、プライベートネットワーキングを有効にして、同じDigitalOceanリージョン（この例ではNYC3）内の個別のUbuntu14.04サーバーにインストールされます。

アプリケーションを構成するサーバーのセットは、次のホスト名と呼ばれます。

  • lb1： HAProxyロードバランサー、https://example.com/からアクセス可能
  • app1：ApacheおよびPHPアプリケーションサーバー
  • app2：ApacheおよびPHPアプリケーションサーバー
  • db1：MySQLデータベースサーバー

このタイプのセットアップは、アプリケーションのコンポーネントを複数のサーバー上に構築する方法を示すために選択されたことに注意することが重要です。 独自の設定は、独自のニーズに基づいてカスタマイズする必要があります。 この特定のサーバーセットアップには単一障害点があり、別のロードバランサー（およびラウンドロビンDNS ）とデータベースサーバーレプリケーションを追加するか、いずれかを指す静的IPを追加することで排除できます。以下で簡単に説明するアクティブまたはパッシブロードバランサーについて説明します。

アプリケーションサーバーをサポートするコンポーネントは、次のホスト名と呼ばれます。

  • バックアップ：Baculaバックアップサーバー
  • 監視：Nagios監視サーバー
  • ログ：集中ログ用のElasticsearch、Logstash、Kibana（ELK）スタック

さらに、次の3つのサポートコンポーネントは図に示されていません。

  • ns1：プライベートDNSのプライマリBINDネームサーバー
  • ns2：プライベートDNS用のセカンダリBINDネームサーバー
  • remotebackups：実稼働データセンターで物理的な災害が発生した場合に、Baculaバックアップのコピーを保存するための別のリージョンにあるリモートサーバー-=== \

また、アプリケーションのさまざまなコンポーネントの障害に対する基本的な回復計画を作成します。

目標の設定に達すると、合計10台のサーバーができます。 一度に作成しますが（DNSの設定などが簡単になります）、必要に応じて自由に作成してください。 Baculaに加えて、またはBaculaの代わりに、バックアップソリューションとしてDigitalOceanバックアップを使用することを計画している場合は、ドロップレットを作成するときに必ずそのオプションを選択してください。

高可用性（オプション）

単一障害点は、インフラストラクチャの一部がダウンすると、サイト全体またはサービスが使用できなくなる可能性がある場合です。 このセットアップで単一障害点に対処したい場合は、別のロードバランサーを追加することで可用性を高めることができます。 高可用性サービスは、障害が発生した場合にバックアップシステムまたはパッシブシステムに自動的にフェイルオーバーします。 高可用性セットアップに2つのロードバランサーを配置すると、アクティブなロードバランサーが使用できない場合に、1つのロードバランサーを常にパッシブに使用してトラフィックを受け入れることができるため、ダウンタイムから保護されます。

高可用性セットアップを実装する方法はいくつかあります。 詳細については、予約済みIPの使用方法のこのセクションをお読みください。

仮想プライベートネットワーク（オプション）

サーバー間のネットワーク通信を保護する場合は、VPNの設定を検討することをお勧めします。 データがインターネット上を移動する場合、暗号化を使用してネットワーク送信を保護することは特に重要です。 VPNを使用するもう1つの利点は、ホストのIDがキー認証プロセスによって検証されることです。これにより、サービスが不正なソースから保護されます。

オープンソースVPNソリューションをお探しの場合は、TincまたはOpenVPNを検討することをお勧めします。 この特定のケースでは、メッシュルーティングを使用するTincがより良いソリューションです。 両方のVPNソリューションのチュートリアルはここにあります：

前提条件

各Ubuntu14.04サーバーには、root以外のスーパーユーザーが必要です。これは、次のチュートリアルに従ってセットアップできます： Ubuntu14.04を使用したサーバーの初期セットアップ。 すべてのコマンドは、各サーバーでこのユーザーとして実行されます。

Linuxの基本的なセキュリティの概念についてある程度の知識があることを前提としていますが、詳細については説明しません。 簡単なLinuxセキュリティ入門書が必要な場合は、次の記事をお読みください：サーバーを保護するための7つのセキュリティ対策。

ドメイン名

アプリケーションは「example.com」などのドメイン名で提供されると想定しています。 まだ所有していない場合は、ドメイン名レジストラから購入してください。

選択したドメイン名を取得したら、このチュートリアルに従って、DigitalOceanDNSで使用できます。共通ドメインレジストラからDigitalOceanネームサーバーを指定する方法。

（IPアドレスと比較して）サイトへのアクセスを容易にすることに加えて、SSL証明書を使用することによるドメインとIDの検証の利点を実現するには、ドメイン名が必要です。SSL証明書は、アプリケーションとそのユーザー間の通信の暗号化も提供します。

SSL証明書

TLS / SSLは、アプリケーションとそのユーザー間の暗号化とドメイン検証を提供するため、セットアップではSSL証明書を使用します。 この例では、ユーザーに「 www.example.com 」のサイトにアクセスしてもらいたいので、これを証明書の共通名（CN）として指定します。 証明書はHAProxyサーバーlb1にインストールされるため、便宜上、そこで証明書キーとCSRを生成することをお勧めします。

ID検証を提供する証明書が必要な場合は、Let’s Encryptを使用してSSL証明書を無料で入手するか、商用の認証局から購入できます。 Let’s Encryptオプションの詳細については、商用認証局からSSL証明書をインストールする方法をお読みください。 Webサーバーへの証明書のインストールセクションをスキップします。

または、次のコマンドで生成できる自己署名SSL証明書を使用することもできます。

  1. sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ~/www.example.com.key -out ~/www.example.com.crt

私たちの目標を達成するためのステップ

本番アプリケーションのセットアップの概要がわかったので、目標を達成するための一般的な計画を作成しましょう。

アプリケーションを構成するコンポーネントが最も重要であるため、それらを早期に稼働させたいと考えています。 ただし、プライベートネットワーク接続の名前ベースのアドレス解決を使用することを計画しているため、最初にDNSを設定する必要があります。

DNSの準備ができたら、物事を稼働させるために、アプリケーションを構成するサーバーをセットアップします。 データベースはアプリケーションに必要であり、アプリケーションはロードバランサーに必要であるため、コンポーネントを次の順序でセットアップします。

  1. データベースサーバー
  2. アプリケーションサーバー
  3. ロードバランサー

アプリケーションの設定手順を完了すると、さまざまなシナリオのリカバリプランを考案できるようになります。 この計画は、バックアップ戦略を決定するのに役立ちます。

さまざまな復旧計画を立てたら、バックアップを設定してサポートしたいと思います。 その後、監視を設定して、サーバーとサービスが正常な状態にあることを確認できます。 最後に、集中ログを設定して、ログの表示、問題のトラブルシューティング、傾向の特定を支援できるようにします。

結論

一般的な計画の準備ができたら、本番アプリケーションのセットアップを実装する準備が整います。 このセットアップは完全に機能しますが、有用な情報を収集し、学習した内容を使用して独自のアプリケーションセットアップを改善できるはずの例であることを忘れないでください。

次のチュートリアルに進んで、アプリケーションのセットアップを開始します：本番用のビルド：Webアプリケーション—デプロイ。