SaltStackインフラストラクチャ:HAProxyロードバランサーのソルト状態の作成
序章
SaltStack(Salt)は、構造化された反復可能な方法でインフラストラクチャを簡単に管理するために使用できる強力なリモート実行および構成管理システムです。 このシリーズでは、Saltデプロイメントから開発、ステージング、および実稼働環境を管理する1つの方法を示します。 ソルト状態システムを使用して、繰り返し可能なアクションを記述して適用します。 これにより、環境を破壊することができます。後で同じ状態で簡単にオンラインに戻すことができるため、安全です。
以前のガイドでは、Nginxをインストールして構成したWebサーバーのSalt状態を作成しました。 このガイドでは、ステージング環境と本番環境でWebサーバーの前に配置されるロードバランサーの状態を構成します。 トラフィックを正しく渡すには、ロードバランサーをWebサーバーアドレスで構成する必要があります。
始めましょう。
メインのHAProxy状態ファイルを作成する
ロードバランサーはHAProxyを使用して、環境内で使用可能なすべてのWebサーバー間でアプリケーションのトラフィックを分散します。 Nginx状態ファイルと同様に、この状態のディレクトリを /srv/salt
ディレクトリ:
- sudo mkdir /srv/salt/haproxy
名前を使用します init.sls
このディレクトリ内のメイン状態ファイルの場合、ディレクトリ名で状態を参照できます。
- sudo nano /srv/salt/haproxy/init.sls
内部では、Nginxで使用したのと同じパターンを使用して、 haproxy
パッケージを作成し、実行されていることを確認します。 パッケージに変更があった場合、またはパッケージに変更があった場合は、サービスが再ロードされることを確認します /etc/default/haproxy
ファイルファイルまたは /etc/haproxy/haproxy.cfg
ファイル。 繰り返しますが、YAMLエラーを回避するために間隔に十分注意してください。
haproxy:
pkg:
- installed
service.running:
- watch:
- pkg: haproxy
- file: /etc/haproxy/haproxy.cfg
- file: /etc/default/haproxy
両方のファイルを管理する必要があります haproxy
サービスが見ています。 それぞれに状態を作成できます。
The /etc/haproxy/haproxy.cfg
ファイルはテンプレートになります。 このファイルは、トラフィックを渡すWebサーバーのリストにデータを入力するために、環境に関する情報を取得する必要があります。 当社のWebサーバーは、作成されるたびに同じIPを持つわけではありません。 この状態が適用されるたびに、リストを動的に作成する必要があります。
The /etc/default/haproxy
fileは単なる通常のファイルです。 HAProxyが起動時に開始されるようにしたいので、これを管理しています。 ただし、これは動的な情報ではないため、これをテンプレートにする必要はありません。
haproxy:
pkg:
- installed
service.running:
- watch:
- pkg: haproxy
- file: /etc/haproxy/haproxy.cfg
- file: /etc/default/haproxy
/etc/haproxy/haproxy.cfg:
file.managed:
- source: salt://haproxy/files/etc/haproxy/haproxy.cfg.jinja
- template: jinja
- user: root
- group: root
- mode: 644
/etc/default/haproxy:
file.managed:
- source: salt://haproxy/files/etc/default/haproxy
- user: root
- group: root
- mode: 644
実際には、状態ファイル自体に必要なのはこれだけです。 完了したら、ファイルを保存して閉じます。
HAProxyをインストールし、パッケージファイルをSaltマスターに転送します
必要な基本的なHAProxyファイルを取得するために、Nginxで使用したのと同じ手法を使用します。 パッケージをミニオンにインストールしてから、サーバーにファイルをマスターにプッシュバックするように指示します。
を使ってみましょう stage-lb
とにかくそれがこのパッケージの最終的なターゲットになるので、サーバー。 ステージングマシンをまだ稼働させていない場合は、次のように入力します。
- sudo salt-cloud -P -m /etc/salt/cloud.maps.d/stage-environment.map
サーバーが利用可能になったら、 haproxy
のパッケージ stage-lb
次のように入力してサーバーを作成します。
- sudo salt stage-lb pkg.install haproxy
インストールが完了すると、必要な2つのファイルをマスターサーバーにプッシュするようにミニオンに指示できます。
- sudo salt stage-lb cp.push /etc/default/haproxy
- sudo salt stage-lb cp.push /etc/haproxy/haproxy.cfg
ミニオンファイルシステムの関連部分は、 /var/cache/salt/master/minions/minion_id/files
ディレクトリ。 この場合、ミニオンIDは stage-lb
. minionファイル構造全体をHAProxy状態ディレクトリにコピーします。
- sudo cp -r /var/cache/salt/master/minions/stage-lb/files /srv/salt/haproxy
次のように入力すると、ファイル構造を確認できます。
- find /srv/salt/haproxy -printf "%P\n"
Outputfiles
files/etc
files/etc/default
files/etc/default/haproxy
files/etc/haproxy
files/etc/haproxy/haproxy.cfg
init.sls
ミニオンからのファイルを取得したので、負荷分散サーバーを破棄できます。
- sudo salt-cloud -d stage-lb
その後、バックグラウンドでサーバーを再作成して、後で最終的なテストと確認を行うためのクリーンな状態にすることができます。 関連するクラウドファイルにアクセスできるため、このコマンドでSaltマスターサーバーをターゲットにします。
- sudo salt --async sm cloud.profile stage-lb stage-lb
サーバーの再構築中に、次に進み、管理しているHAProxyファイルに必要な変更を加えることができます。
/ etc / default/haproxyファイルを設定します
から始めることができます /etc/default/haproxy
ファイル。 SaltマスターのHAProxy状態ディレクトリで、デフォルトファイルを格納するディレクトリに移動します。
- cd /srv/salt/haproxy/files/etc/default
ファイルをにコピーします haproxy.orig
ファイルを最初にパッケージ化されたとおりに保存できるようにするには、次のようにします。
- sudo cp haproxy haproxy.orig
次に、ファイルを開いて編集します。
- sudo nano haproxy
変化する ENABLED
「1」に。 これにより、UbuntuのinitシステムであるUpstartに、サーバーの起動時にHAProxyサービスを開始するように指示されます。
# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=1
# Add extra flags here.
#EXTRAOPTS="-de -m 16"
これが私たちが行う必要がある唯一の変更です。 ファイルを保存して閉じます。
/etc/haproxy/haproxy.cfgテンプレートファイルを設定します
次に、メインのHAProxy構成ファイルで作業します。 Saltマスターサーバーの適切なディレクトリに移動します。
- cd /srv/salt/haproxy/files/etc/haproxy
繰り返しになりますが、構成をコピーして元の状態を保存しましょう。
- sudo cp haproxy.cfg haproxy.cfg.orig
次に、これがJinjaテンプレートファイルであることを反映するようにファイルの名前を変更します。
- sudo mv haproxy.cfg haproxy.cfg.jinja
テキストエディタでテンプレートファイルを開きます。
- sudo nano haproxy.cfg.jinja
ファイルの先頭で、Jinja変数を設定することから始めることができます。 ロードバランサーが動作している環境を取得する必要があります network.interface_ip
実行関数。 後でこれを使用して、同じ環境のWebサーバーをサーバーリストに追加します。
{%- set env = salt['grains.get']('env') -%}
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
. . .
ファイルの「デフォルト」セクションにスキップします。 変更する必要があります mode
「tcp」と最初の option
「tcplog」へ:
. . .
defaults
. . .
mode tcp
option tcplog
. . .
ファイルの下部で、実際の構成を作成する必要があります。 HAProxyが接続を受け入れる方法を説明する「フロントエンド」セクションを作成する必要があります。 このセクションには「www」というラベルを付けます。
これをサーバーのパブリックIPアドレスにバインドします。 これを使用して取得できます network.interface_ip
実行モジュール機能 eth0
口論。 Webリクエストはポート80で受信されます。 で渡すデフォルトのバックエンドを指定できます default_backend
オプション。 バックエンドと呼びます nginx_pool
:
. . .
frontend www
bind {{ salt['network.interface_ip']('eth0') }}:80
default_backend nginx_pool
次に、を追加する必要があります nginx_pool
バックエンド。 従来のラウンドロビンバランシングモデルを使用し、モードを再び「tcp」に設定します。
その後、環境からバックエンドWebサーバーのリストを作成する必要があります。 これは、Jinjaの「for」ループを使用して実行できます。 使用できます mine.get
の値を取得する実行モジュール関数 internal_ip
鉱山機能。 Webサーバーの役割と環境を一致させます。 The ~ env
の値を分類します env
前に設定した変数を、その前にある一致文字列に設定します。
このルックアップの結果は、に保存されます server
と addr
ループの各反復の変数。 ループ内で、これらのループ変数を使用してサーバーの詳細を追加します。 最終結果は次のようになります。
. . .
frontend www
bind {{ salt['network.interface_ip']('eth0') }}:80
default_backend nginx_pool
backend nginx_pool
balance roundrobin
mode tcp
{% for server, addr in salt['mine.get']('G@role:webserver and G@env:' ~ env, 'internal_ip', expr_form='compound').items() -%}
server {{ server }} {{ addr }}:80 check
{% endfor -%}
終了したら、ファイルを保存して閉じます。
HAProxy状態ファイルのテスト
負荷分散の状態はかなり基本的ですが、完全です。 これで、テストに進むことができます。
まず、使ってみましょう state.show_sls
ファイルの順序を表示するには:
- sudo salt stage-lb state.show_sls haproxy
出力のさまざまな「順序」値のシーケンスから、パッケージがインストールされ、サービスが開始され、2つのファイルが適用されることがわかります。 これは私たちが期待したことです。 ファイルを変更すると、構成した「監視」設定により、サービスのリロードがトリガーされます。
次に、状態アプリケーションのドライランを実行できます。 これにより、実行時に状態が失敗する原因となるいくつかの(すべてではない)エラーがキャッチされます。
- sudo salt stage-lb state.apply haproxy test=True
すべての州が合格したことを確認してください。 下部または出力の失敗数に関係なく、上にスクロールして、各状態の「コメント」行を確認します。 テストが成功としてマークされていても、これには潜在的な問題に関する追加情報が含まれる場合があります。
テストコマンド中に表面化した問題を修正した後、ロードバランサーサーバーに状態を適用できます。 状態を適用する前に、バックエンドNginxWebサーバーが実行および構成されていることを確認してください。
- sudo salt-cloud -P -m /etc/salt/cloud.maps.d/stage-environment.map
- sudo salt -G 'role:webserver' state.apply nginx
Webサーバーが実行されているときに、 haproxy
州:
- sudo salt -G 'role:lbserver' state.apply haproxy
これで、ロードバランサーのパブリックIPアドレスを介して2つのバックエンドWebサーバーのいずれかにアクセスできるようになります。 次のコマンドを使用して、ロードバランサーのパブリックIPアドレスを表示できます。
- sudo salt -G 'role:lbserver' network.interface_ip eth0
ブラウザを使用すると、次のようになります。
ロードバランサーがバックエンドサーバー間でトラフィックを通過させるのを確認するのは簡単です。 curl
:
- curl load_balancer_public_IP
Output<!DOCTYPE html>
<html>
<head>
<title>Welcome from stage-www2</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>Hello! This is being served from:</p>
<h2>stage-www2</h2>
</body>
</html>
コマンドをもう一度数回入力すると、2つのサーバー間でスワップする必要があります。
- curl load_balancer_public_IP
Output<!DOCTYPE html>
<html>
<head>
<title>Welcome from stage-www1</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>Hello! This is being served from:</p>
<h2>stage-www1</h2>
</body>
</html>
ご覧のとおり、リクエストを処理するサーバーが変更されました。これは、ロードバランサーが正しく機能していることを意味します。
結論
この時点で、ロードバランサーマシンに適用できるHAProxy状態が機能しています。 これを使用して、アプリケーションの着信トラフィックをすべてのバックエンドNginxサーバー間で分割できます。 ロードバランサーを簡単に破棄して、利用可能なWebサーバーに基づいて再構築できます。
次のガイドでは、MySQLをバックエンドデータベースシステムとして起動して実行することに焦点を当てます。 これは、さまざまな環境でアプリケーションデータを保存するために使用されます。