前書き
SaltStack(Salt)は、構造化された反復可能な方法でインフラストラクチャを簡単に管理するために使用できる強力なリモート実行および構成管理システムです。 このシリーズでは、Saltデプロイメントから開発、ステージング、および実稼働環境を管理する1つの方法を示します。 Salt状態システムを使用して、繰り返し可能なアクションを記述および適用します。 これにより、後で同じ状態で簡単にオンラインに戻すことができるという知識があるため、環境を破壊することができます。
https://www.digitalocean.com/community/tutorials/saltstack-infrastructure-creating-salt-states-for-nginx-web-servers [以前のガイド]では、インストールおよび設定済みのNginx。 このガイドでは、ステージング環境と運用環境で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
これは、実際に状態ファイル自体に必要なすべてです。 完了したら、ファイルを保存して閉じます。
HAProxyをインストールし、パッケージファイルをSalt Masterに転送します
必要な基本的なHAProxyファイルを取得するために、Nginxで使用したのと同じ手法を使用します。 パッケージをミニオンにインストールし、サーバーにファイルをマスターにプッシュするように指示します。
とにかくこのパッケージの最終ターゲットになるため、 `+ stage-lb +`サーバーを使用しましょう。 ステージングマシンをまだ実行していない場合は、次のように入力します。
sudo salt-cloud -P -m /etc/salt/cloud.maps.d/stage-environment.map
サーバーが利用可能になったら、次のように入力して、 `+ stage-lb `サーバーに ` haproxy +`パッケージをインストールできます。
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 // files `ディレクトリに再作成されます。 この場合、ミニオンIDは「 stage-lb +」です。 ミニオンファイル構造全体を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 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」に変更します。 これにより、サーバーの起動時にHAProxyサービスを開始するようにUbuntuの初期化システムUpstartに指示します。
/ srv / salt / haproxy / files / etc / default / haproxy
# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=
# 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
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
option
. . .
ファイルの下部で、実際の構成を作成する必要があります。 HAProxyが接続を受け入れる方法を説明する「フロントエンド」セクションを作成する必要があります。 このセクションに「www」というラベルを付けます。
これをサーバーのパブリックIPアドレスにバインドします。 `+ eth0 `引数を指定した ` network.interface_ip `実行モジュール関数を使用してこれを取得できます。 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
完了したら、ファイルを保存して閉じます。
HAProxy状態ファイルのテスト
負荷分散状態はかなり基本的ですが、完全です。 これでテストに進むことができます。
最初に、 `+ state.show_sls +`を使用してファイルの順序を表示します。
sudo salt stage-lb state.show_sls haproxy
出力のさまざまな「順序」値のシーケンスから、パッケージがインストールされ、サービスが開始され、2つのファイルが適用されることがわかります。 これは私たちが期待したことです。 設定した「監視」設定により、ファイルの変更はサービスのリロードをトリガーします。
次に、状態アプリケーションのドライランを実行できます。 これにより、実行時に状態が失敗するいくつかの(すべてではない)エラーがキャッチされます。
sudo salt stage-lb state.apply haproxy test=True
すべての州が合格したことを確認してください。 下部または出力の失敗カウントに関係なく、上にスクロールして、各状態の「コメント」行を確認します。 テストに成功とマークされていても、潜在的な問題に関する追加情報が含まれることがあります。
テストコマンド中に発生した問題を修正した後、ロードバランサーサーバーに状態を適用できます。 状態を適用する前に、バックエンドのNginx Webサーバーが実行および構成されていることを確認してください。
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
ブラウザを使用すると、次のようになります。
image:https://assets.digitalocean.com/articles/saltstack_haproxy/example_page.png [ロードバランサーページ]
ロードバランサーが `+ curl +`を使用してバックエンドサーバー間でトラフィックを渡すのを見るのは簡単です:
curl
Output<!DOCTYPE html>
<html>
<head>
<title>Welcome from </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></h2>
</body>
</html>
もう一度コマンドを入力すると、2つのサーバー間でスワップするはずです。
curl
Output<!DOCTYPE html>
<html>
<head>
<title>Welcome from </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></h2>
</body>
</html>
ご覧のように、リクエストを処理するサーバーが変更されました。これは、ロードバランサーが正しく機能していることを意味します。
結論
この時点で、ロードバランサーマシンに適用できるHAProxy状態が機能しています。 これを使用して、アプリケーションの受信トラフィックをすべてのバックエンドNginxサーバーに分割できます。 ロードバランサーを簡単に破棄し、利用可能なWebサーバーに基づいてロードバランサーを再構築できます。
https://www.digitalocean.com/community/tutorials/saltstack-infrastructure-creating-salt-states-for-mysql-database-servers [次のガイド]では、MySQLをバックエンドとして実行することに焦点を当てます。データベースシステム。 これは、さまざまな環境でアプリケーションデータを保存するために使用されます。