Ubuntu14.04の本番環境でConsulを構成する方法

投稿日: 2019-11-08 2022-04-20
タグ: Clustering, Networking, System Tools, ubuntu

序章

Consulは、分散型の高可用性、データセンター対応のサービス検出および構成システムです。これを使用して、柔軟で強力なインターフェイスでサービスとノードを表示できるため、クライアントは、その一部であるインフラストラクチャの最新のビューを常に把握できます。

Consulは、インフラストラクチャに関する一貫性のある利用可能な情報を提供するために使用されるさまざまな機能を提供します。これには、サービスとノードの検出メカニズム、タグ付けシステム、ヘルスチェック、コンセンサスベースの選択ルーチン、システム全体のキー/値ストレージなどが含まれます。組織内の領事を活用することで、アプリケーションやサービスに高度なレベルの認識を簡単に組み込むことができます。

最後のガイドでは、領事の機能のいくつかの簡単なデモンストレーションを提供しました。このガイドでは、インフラストラクチャのサービス検出の実装を開始するために使用できる、本番環境に対応した領事館の構成の作成を開始します。

前提条件と目標

このシリーズでは、相互に通信し、クライアントマシンのサービス情報、キー/値ストレージプール、およびその他の詳細を維持できるサーバーのシステムをセットアップします。このガイドでは、ソフトウェアをインストールし、構成の一部を自動化するときに、システムの本番環境を準備するための最初のステップを実行します。

領事館のドキュメントでは、サーバーに障害が発生した場合のデータ損失を回避するために、各データセンターで3つまたは5つの領事サーバーを実行することを推奨しています。領事サーバーは、手間のかかる作業を行うコンポーネントです。サービスに関する情報とキー/値情報を格納します。選挙中の膠着状態の問題を回避するには、奇数台のサーバーが必要です。

領事サーバーとは別に、他のマシンは領事エージェントを実行できます。領事エージェントは非常に軽量で、サーバーにリクエストを転送するだけです。これらは、サーバーを分離し、サーバーのアドレスを知る責任をエージェント自体に任せる方法を提供します。

後のガイドでセキュリティメカニズムの一部を実装するには、単一のドメイン内のすべてのマシンに名前を付ける必要があります。これは、後でワイルドカードSSL証明書を発行できるようにするためです。

私たちのマシンの詳細はここにあります：

ホスト名	IPアドレス	役割
server1.example.com	192.0.2.1	ブートストラップ領事サーバー
server2.example.com	192.0.2.2	領事サーバー
server3.example.com	192.0.2.3	領事サーバー
agent1.example.com	192.0.2.50	領事クライアント

このデモでは64ビットのUbuntu14.04サーバーを使用しますが、最新のLinuxサーバーでも同様に機能するはずです。構成が完了したら、サービス、チェック、およびノードを簡単に追加できるシステムを導入する必要があります。

このガイドの手順を完了するには、rootユーザーとしてマシンにログインします。

領事のダウンロードとインストール

領事ガイドの最初の紹介にまだ領事をインストールしていない場合は、今すぐインストールする必要があります。構成している4台のマシンのそれぞれに、システムレベルのアプリケーションとしてconsulをインストールします。

領事アプリケーションを調べる前に、unzipを取得して実行可能ファイルを抽出する必要があります。ローカルシステムのパッケージキャッシュを更新してから、aptを使用してパッケージをインストールします。

apt-get update
apt-get install unzip

これで、領事プログラムの取得に取り掛かることができます。 consulプロジェクトのページには、Windows、OS X、およびLinux用のバイナリパッケージへのダウンロードリンクがあります。

上のページに移動し、サーバーを表すオペレーティングシステムとアーキテクチャを右クリックします。このガイドでは、64ビットサーバーを使用しているため、「linux」の下にある「amd64」リンクを使用します。「リンクの場所をコピー」またはブラウザが提供する同様のオプションを選択します。

ターミナルで、/usr/local/binディレクトリに移動します。ここに、実行可能ファイルが保持されます。 wgetとスペースを入力し、サイトからコピーしたURLを貼り付けます。

cd /usr/local/bin
wget https://dl.bintray.com/mitchellh/consul/0.3.0_linux_amd64.zip

これで、前にインストールしたunzipコマンドを使用してバイナリパッケージを抽出できます。次に、zipファイルを削除できます。

unzip *.zip
rm *.zip

これで、すべてのサーバーでconsulコマンドを使用できるようになります。

必要なディレクトリとシステム構造を作成する

consulコマンドを使用すると、構造化されていない方法で領事を簡単に試すことができます。これにより、いくつかの機能をテストできます。ソフトウェアに慣れるために、前回のガイドでこれを行いました。

ただし、管理しやすい、より信頼性の高いシステムの構築を試みるため、これを機能させるための構造を作成します。各コンピューター（サーバーとクライアント）で次の手順を実行します。

最初に注意する必要があるのは、タスクに固有のユーザーを作成することです。これはユーザー特権分離の標準的なケースであるため、専用ユーザーを使用して領事プロセスを実行します。

次のように入力して、今すぐユーザーを作成します。

adduser consul

すべてのプロンプトをスキップできます（パスワードを設定することをお勧めします。それ以外の場合は文句を言います）必要に応じて。

次に、サービスの開始方法に応じて使用するさまざまな構成を格納する構成階層を作成します。これを簡単にするために、/etc構成構造に親consul.dディレクトリを作成し、bootstrap、server、および[というサブディレクトリを配置します。 X155X]各システムのこの下：

mkdir -p /etc/consul.d/{bootstrap,server,client}

後でこれらのそれぞれに構成を配置できます。各サーバーはおそらくこれらのディレクトリのうち最大2つを使用しますが、各ホストで一貫性を保つための構造を作成します。

また、領事が再起動の間に永続データを保存できる場所を作成する必要があります。この目的のために/var/consulにディレクトリを作成し、それをconsulユーザーに渡して、データを管理できるようにします。

mkdir /var/consul
chown consul:consul /var/consul

この構造が整ったら、構成ファイルの作成を開始できるはずです。

ブートストラップ構成の作成

作成する必要のある最初の構成は、クラスターをブートストラップするためのものです。これは、クラスターを最初に作成するためにのみ必要であるため、あまり一般的なイベントではありません。ただし、クラスターが完全にダウンした場合にすぐに再開できるように、構成ファイルを作成します。

この構成ファイルは、領事サーバーの1つだけに配置することも、すべてのサーバーに配置して、ブートストラップのオプションを増やすこともできます。このデモンストレーションでは、server1にのみ配置します。

構成ファイルは単純なJSONで保存されるため、管理が非常に簡単です。 bootstrapサブディレクトリに最初のファイルを作成します。

nano /etc/consul.d/bootstrap/config.json

このファイルでは、この構成を使用するときに、consulがブートストラップモードのサーバーとして起動するように指定することから始めることができます。

{
    "bootstrap": true,
    "server": true
}

また、クラスターが存在するデータセンターを指定する必要があります。これは、クラスターの物理的な場所を識別するのに役立つ任意の名前にすることができます。 Consulはデータセンターに対応しており、これらの指定は、データセンターごとにさまざまなクラスターを整理するのに役立ちます。

/var/consulで作成したデータディレクトリを渡すこともできます。領事はこれを使用して、クラスターの状態に関する情報を保存します。

{
    "bootstrap": true,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul"
}

次に、領事が使用するウィスパープロトコルに暗号化を実装します。共有秘密システムを使用してこの機能が組み込まれています。シークレットは、16ビットのbase-64エンコード文字列である必要があります。この値に適した値を取得するために、ファイルを一時的に終了します。

ターミナルでは、consulコマンドを使用して、必要な長さとエンコーディングのキーを生成できます。タイプ：

consul keygen

X4SYOinf2pTAcAHRhpj7dA==

生成された値をコピーして、構成ファイルを再度開きます。

nano /etc/consul.d/bootstrap/config.json

コピーした文字列をencryptパラメーターの値として使用します。

{
    "bootstrap": true,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA=="
}

最後に、ログレベルを指定し、ログにsyslogを使用することを示すためにいくつかの追加情報を追加します。

{
    "bootstrap": true,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true
}

終了したら、ファイルを保存して閉じます。

通常のサーバー構成の作成

ブートストラップ構成が完了したので、これを一般的なサーバー構成の基礎として使用できます。クラスターがブートストラップされると、サーバー構成が使用されます。

ブートストラップファイルをserver1からそのマシンのサーバーサブディレクトリにコピーして編集することから始めます。

cp /etc/consul.d/bootstrap/config.json /etc/consul.d/server

ファイルを開いて、必要な変更を加えます。

nano /etc/consul.d/server/config.json

この構成は非ブートストラップ構成用であるため、開始するには、ブートストラップフラグをオフにする必要があります。

サーバー構成のために変更する必要がある他の唯一のことは、このノードが起動時に参加を試みる他のサーバーのIPアドレスを指定することです。これにより自動的に参加できるため、サーバーの起動後に手動でクラスターに参加する必要はありません。

{
    "bootstrap": false,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true,
    "start_join": ["192.0.2.2", "192.0.2.3"]
}

encryptパラメータはシステムのすべての参加者で同じである必要があるため、ファイルをコピーすることでその要件はすでに満たされています。新しい構成を作成するときは、このことに注意してください。

終了したらファイルを保存します。

この構成ファイルの内容を、領事サーバーとして機能する他のマシンにコピーする必要があります。最初のホストで行ったのと同じように、/etc/consul.d/server/config.jsonのファイルにそれらを配置します。

他のホストで変更する必要がある唯一の値は、接続を試みる必要があるIPアドレスです。自身のIPではなく最初のサーバーに接続しようとしていることを確認する必要があります。たとえば、この例の2番目のサーバーには、次のようなファイルがあります。

{
    "bootstrap": false,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true,
    "start_join": ["192.0.2.1", "192.0.2.3"]
}

終了したら、作成したファイルを保存して閉じます。

クライアント構成の作成

これで、サーバーの構成はすべて完了しました。適切な構成でクライアントマシンを起動して実行することに集中できます。

クライアントマシンのclientサブディレクトリの下にある構成ファイルを開きます。

nano /etc/consul.d/client/config.json

新しい構成の基礎として、以前の構成を再度使用します。サーバーファイルの1つの内容をこのファイルにコピーします。

bootstrapパラメーターの言及を削除することから始めます。これはサーバー構成にのみ適用され、serverパラメーターをfalseに変更するためです。

次に、WebUIディレクトリの場所を指定するパラメータを追加します。これに必要なファイルを少しで取得します。それらが存在する場所は/home/consul/distです。

最後に、start_joinパラメーターを調整して、すべてのサーバーを一覧表示します。

{
    "server": false,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "ui_dir": "/home/consul/dist",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true,
    "start_join": ["192.0.2.1", "192.0.2.2", "192.0.2.3"]
}

終了したら、ファイルを保存して閉じます。

WebUIファイルのダウンロード

Web UIを提供するようにクライアントを構成したので、これを可能にする実際のファイルを取得する必要があります。

領事のWebサイトで、領事のWeb UI へのリンクを右クリックし、[リンクの場所をコピー]または同様のオプションを選択します。

クライアントで、suを使用してconsulユーザーになります。 consulユーザーのホームディレクトリにWebディレクトリを設定します。

su consul
cd ~

ここで、wgetと入力し、スペースを入力して、WebUIダウンロード用にコピーしたリンクを貼り付けます。この記事の執筆時点では、次のようになります。

wget https://dl.bintray.com/mitchellh/consul/0.3.0_web_ui.zip

ダウンロードしたファイルを解凍し、zipファイルを削除します。

unzip *.zip
rm *.zip

これにより、ホームディレクトリ内にdistというディレクトリが作成されます。これは、構成ファイルでWebUIパラメーターを指定したディレクトリーです。

続行する前に、領事ユーザーのセッションを終了して、ルートセッションに戻る必要があります。

exit

アップスタートスクリプトを作成する

これで、構成ファイルが配置されました。次に、起動スクリプトの作成に集中して、問題が発生した場合に、起動時に領事インスタンスが自動的に起動して再起動するようにします。

クラスターのブートストラップは頻繁に行う必要はないため（ほとんどの場合、クラスター自体は存続し、単一のノードを再起動してクラスターに再参加する必要がある場合があります）、ブートストラップをアップスタートスクリプトに織り込むことはありません。このプロセスを手動で完了する方法については、後ほど説明します。

upstartスクリプトは、サーバーとクライアントで同様になります。領事サーバーの1つで、/etc/initディレクトリ内に領事構成を保持するファイルを作成します。

nano /etc/init/consul.conf

このファイルの内容を他のサーバーにコピーし、それをクライアント構成の基礎としても使用します。このファイル内での最初の業務は、プロセスの説明を作成することです。私たちのサーバーでは、以下を使用します。

description "Consul server process"

次に、プロセスを開始する条件を指定します。このサービスでは、ローカルファイルシステムがマウントされ、パブリックネットワークインターフェイスが実行されているときにサービスを開始する必要があります。

また、プロセスをいつ停止するかを指定する必要があります。標準のLinuxランレベルを使用すると、通常の動作モードのいずれかでない場合は常にプロセスを停止するように指示できます（サーバーを停止または再起動するときにプロセスを停止します）。

description "Consul server process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

プロセスが予期せず停止した場合は、プロセスを再開するようにinitシステムに指示できます。また、プロセスを実行するユーザーとグループを指定する必要があります。プロセスを分離するために、領事のユーザーとグループを作成したことを忘れないでください。

description "Consul server process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

respawn

setuid consul
setgid consul

最後に、実行する実際のコマンドを提供する必要があります。これは、単にエージェントモードで実行されるconsulコマンドになります。コマンドの引数として、サーバー構成仕様を含むディレクトリを渡します。

description "Consul server process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

respawn

setuid consul
setgid consul

exec consul agent -config-dir /etc/consul.d/server

終了したらファイルを保存します。

このファイルの内容を、各サーバーとクライアントの/etc/init/consul.confというファイルにコピーします。

クライアントでは、ファイルを少し変更する必要があります。これがクライアントマシンであるという事実を参照するように説明を変更する必要があります。また、実際のconsulコマンドに渡される構成ディレクトリを変更する必要があります。

終了ファイルは次のようになります。

description "Consul client process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

respawn

setuid consul
setgid consul

exec consul agent -config-dir /etc/consul.d/client

終了したら、ファイルを保存して閉じます。

クラスターの開始

これで、領事クラスターを迅速に稼働させるためのすべてが整いました。プロセスは比較的簡単です。

ブートストラップ構成ファイル（この場合は server1 ）を含むサーバーで、suを使用して、領事ユーザーに簡単に変更します。次に、consulを呼び出して、ブートストラップディレクトリを引数として渡すことができます。

su consul
consul agent -config-dir /etc/consul.d/bootstrap

サービスが起動し、ターミナルウィンドウを占有する必要があります。ブートストラップモードでは、このサーバーはリーダーとして自己選択し、クラスターを形成するための基盤を作成します。

他の領事サーバーで、rootとして、次のように入力して、upstartスクリプトで作成した領事サービスを開始します。

start consul

これらのサーバーはブートストラップサーバーに接続し、クラスターを完成させます。この時点で、3台のサーバーのクラスターがあり、そのうち2台は正常に動作しており、1台はブートストラップモードです。つまり、他のサーバーに相談することなく、エグゼクティブの決定を下すことができます。

これは私たちが望んでいることではありません。各サーバーを同じ立場に置く必要があります。クラスターが作成されたので、ブートストラップされた領事インスタンスをシャットダウンしてから、通常のサーバーとしてクラスターに再度入ることができます。

これを行うには、ブートストラップされたサーバーのターミナルでCTRL-Cを押します。

CTRL-C

ここで、ルートセッションに戻り、他のサーバーで行ったように領事サービスを開始します。

exit
start consul

これにより、以前にブートストラップされたサーバーが昇格されていない特権でクラスターに参加し、クラスターが最終状態になります。

クラスタが完全に機能するようになったので、クライアントマシンは接続できます。クライアントマシンで、rootと同じ手順を実行します。

start consul

クライアントは、クライアントとしてクラスターに接続します。クラスターのメンバー（サーバーとクライアント）を確認するには、いずれかのマシンのメンバーを領事に依頼します。

consul members

Node     Address             Status  Type    Build  Protocol
server3  192.0.2.3:8301  alive   server  0.3.0  2
server2  192.0.2.2:8301  alive   server  0.3.0  2
server1  192.0.2.1:8301  alive   server  0.3.0  2
agent1   192.0.2.50:8301    alive   client  0.3.0  2

WebUIへの接続

クラスタへのWebインターフェイスをホストするようにクライアントマシンを構成しました。ただし、これはローカルインターフェイスで提供されているため、マシンのパブリックインターフェイスを使用してアクセスすることはできません。

Web UIにアクセスするために、UIファイルを保持するクライアントマシンへのSSHトンネルを作成します。 Consulは、ポート8500でHTTPインターフェイスを提供します。ローカルポート8500をクライアントマシンのポート8500にトンネリングします。ローカルコンピューターで、次のように入力します。

ssh -N -f -L 8500:localhost:8500 root@192.0.2.50

これにより、リモートマシンに接続し、ローカルポートとリモートポートの間にトンネルを作成してから、接続をバックグラウンドに配置します。

ローカルWebブラウザーで、次のように入力して領事Webインターフェースにアクセスできるようになりました。

http://localhost:8500

これにより、デフォルトのWebUIページが表示されます。

Consul web UI landing page

このインターフェイスを使用して、サーバーの状態を確認し、サービスとインフラストラクチャの概要を取得できます。

Web UIの使用が終了したら、SSHトンネルを閉じることができます。 psコマンドとgrepを使用してプロセスのpid番号を検索し、転送したポート番号を検索します。

ps aux | grep 8500

1001      5275  0.0  0.0  43900  1108 ?        Ss   12:03   0:00 ssh -N -f -L 8500:localhost:8500 [email protected]
1001      5309  0.0  0.0  13644   948 pts/7    S+   12:12   0:00 grep --colour=auto 8500

上記の出力（使用したトンネリングコマンドを含む行）で強調表示されている番号は、探しているpid番号です。次に、これをkillコマンドに渡して、トンネルを閉じます。

kill 5275

結論

これで、領事館のメンバーを安定して管理できるようになります。領事クラスターは、ブートストラップしてすばやく簡単に起動できます。既存のサーバーの構成ファイル（consul configおよびupstartスクリプト）をコピーすることにより、追加のノードをすばやく構成できます。

現在、領事館の環境は、サービスを簡単に管理できるように設定されていますが、通信はまだ完全には保護されていません。次のガイドでは、メンバーのRPC通信を暗号化および検証するためにSSL証明書検証を設定する方法に焦点を当てます。

getdocs

13036