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
内部では、haproxy
パッケージをインストールして実行されていることを確認するために、Nginxで使用したのと同じパターンを使用できます。 パッケージに変更があった場合、または/etc/default/haproxy
ファイルファイルまたは/etc/haproxy/haproxy.cfg
ファイルに変更があった場合は、サービスが確実に再ロードされます。 繰り返しますが、YAMLエラーを回避するために間隔に十分注意してください。
/srv/salt/haproxy/init.sls
haproxy: pkg: - installed service.running: - watch: - pkg: haproxy - file: /etc/haproxy/haproxy.cfg - file: /etc/default/haproxy
haproxy
サービスが監視している両方のファイルを管理する必要があります。 それぞれに状態を作成できます。
/etc/haproxy/haproxy.cfg
ファイルがテンプレートになります。 このファイルは、トラフィックを渡すWebサーバーのリストにデータを入力するために、環境に関する情報を取得する必要があります。 当社のWebサーバーは、作成されるたびに同じIPを持つわけではありません。 この状態が適用されるたびに、リストを動的に作成する必要があります。
/etc/default/haproxy
ファイルは単なる通常のファイルです。 HAProxyが起動時に開始されるようにしたいので、これを管理しています。 ただし、これは動的な情報ではないため、これをテンプレートにする必要はありません。
/srv/salt/haproxy/init.sls
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サービスを開始するように指示されます。
/ srv / salt / haproxy / files / etc / default / 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サーバーをサーバーリストに追加します。
/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja
{%- set env = salt['grains.get']('env') -%} global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy . . .
ファイルの「デフォルト」セクションにスキップします。 mode
を「tcp」に変更し、最初のoption
を「tcplog」に変更する必要があります。
/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja
. . . defaults . . . mode tcp option tcplog . . .
ファイルの下部で、実際の構成を作成する必要があります。 HAProxyが接続を受け入れる方法を説明する「フロントエンド」セクションを作成する必要があります。 このセクションには「www」というラベルを付けます。
これをサーバーのパブリックIPアドレスにバインドします。 これは、network.interface_ip
実行モジュール関数とeth0
引数を使用して取得できます。 Webリクエストはポート80で受信されます。 default_backend
オプションを使用して、渡すデフォルトのバックエンドを指定できます。 バックエンドをnginx_pool
と呼びます。
/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja
. . . frontend www bind {{ salt['network.interface_ip']('eth0') }}:80 default_backend nginx_pool
次に、nginx_pool
バックエンドを追加する必要があります。 従来のラウンドロビンバランシングモデルを使用し、モードを再び「tcp」に設定します。
その後、環境からバックエンドWebサーバーのリストを作成する必要があります。 これは、Jinjaの「for」ループを使用して実行できます。 mine.get
実行モジュール関数を使用して、internal_ip
鉱山関数の値を取得できます。 Webサーバーの役割と環境を一致させます。 ~ env
は、前に設定したenv
変数の値を、その前にある一致文字列に連結します。
このルックアップの結果は、ループの反復ごとにserver
およびaddr
変数に格納されます。 ループ内で、これらのループ変数を使用してサーバーの詳細を追加します。 最終結果は次のようになります。
/srv/salt/haproxy/files/etc/haproxy/haproxy.cfg.jinja
. . . 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をバックエンドデータベースシステムとして起動して実行することに焦点を当てます。 これは、さまざまな環境でアプリケーションデータを保存するために使用されます。