SaltStackインフラストラクチャ:HAProxyロードバランサーのソルト状態の作成

提供:Dev Guides
移動先:案内検索

序章

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をバックエンドデータベースシステムとして起動して実行することに焦点を当てます。 これは、さまざまな環境でアプリケーションデータを保存するために使用されます。