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

投稿日: 2019-11-08 2022-10-20
タグ: Configuration Management, ubuntu

序章

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エラーを回避するために間隔に十分注意してください。

/srv/salt/haproxy/init.sls

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が起動時に開始されるようにしたいので、これを管理しています。ただし、これは動的な情報ではないため、これをテンプレートにする必要はありません。

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

getdocs

13036