SaltStackインフラストラクチャ：Nginx Webサーバーのソルトステートの作成

前書き

SaltStack（Salt）は、構造化された反復可能な方法でインフラストラクチャを簡単に管理するために使用できる強力なリモート実行および構成管理システムです。このシリーズでは、Saltデプロイメントから開発、ステージング、および実稼働環境を管理する1つの方法を示します。 Salt状態システムを使用して、繰り返し可能なアクションを記述および適用します。これにより、後で同じ状態で簡単にオンラインに戻すことができるという知識があるため、環境を破壊することができます。

https://www.digitalocean.com/community/tutorials/saltstack-infrastructure-configuring-salt-cloud-to-spin-up-digitalocean-resources [前のガイド]で、Salt masterサーバーの機能をセットアップして拡張しました`+ salt-cloud +`のDigitalOceanプロバイダー。環境ごとに新しいサーバーを起動できるようにするために必要なファイルを作成しました。この記事では、NginxのSalt状態ファイルを作成することにより、構成管理について詳しく説明します。 Nginxは、Web要求を処理するために、3つすべての環境のWebサーバーノードで使用されます。

メインNginx状態ファイルを作成する

Saltは、その状態システムを通じて構成管理を処理します。最も単純なケースでは、これらはSaltのファイルサーバールート（ `+ / srv / salt +`として設定した）内にあるファイルによって制御されます。 Nginxの構成を開始するために、構成するソフトウェアに固有のディレクトリをこの場所に作成します。

sudo mkdir /srv/salt/nginx

状態ファイルの接尾辞は「+ .sls 」です。ディレクトリ内の ` init.sls `ファイルは、その特定のSalt状態または式のメイン設定ファイルとして機能します。親ディレクトリ名を参照して、関連する ` init.sls +`ファイルに含まれる機能を実行します。

それを念頭に置いて、このディレクトリ内で `+ init.sls +`ファイルを作成して開き、開始します：

sudo nano /srv/salt/nginx/init.sls

Nginxパッケージとサービス状態

`+ nginx `識別子を使用して状態を作成することから始めます。これは、Salt状態システム内のこの特定の状態の一意の名前として機能します。状態モジュールに「name」属性を含めないため、インストールするターゲット（ ` pkg.installed `関数の場合）および実行するサービス（ ` serviceの場合）としても機能します.running + `関数）。

パッケージが更新されたとき、メインの構成ファイルが変更されたとき、デフォルトのサーバーブロックファイルが変更されたときなど、特定の条件下でNginxが自動的にリロードするようにします。これらの条件が発生した場合、 `+ watch +`を使用して、Nginxサービスを再起動するようにSaltに指示できます。

/srv/salt/nginx/init.sls

nginx:
 pkg:
   - installed
 service.running:
   - watch:
     - pkg: nginx
     - file: /etc/nginx/nginx.conf
     - file: /etc/nginx/sites-available/default

`+ watch：`キーの下の ` pkg：`および ` file：`キーは、監視するリソースに関連付けられた状態モジュールを表します。 ` pkg `リソースは、この同じ定義の最初の部分で処理されます。次に、 ` file`リソースに一致する状態を作成する必要があります。

Nginx構成ファイルの状態

`+ / etc / nginx / nginx.conf`ファイルから始めることができます。これを管理対象ファイルにしたいと思います。 Saltの用語では、これは単にマスターサーバー上のファイルのコンテンツを定義し、それを必要とする各ミニオンにアップロードすることを意味します。ファイルにかなり一般的な許可と所有権を設定します。ソースは、Saltファイルサーバー内の場所を参照します（現在のファイルもこの構造内にあります）。このパスとファイルを一時的に作成します。

/srv/salt/nginx/init.sls

nginx:
 pkg:
   - installed
 service.running:
   - watch:
     - pkg: nginx
     - file: /etc/nginx/nginx.conf
     - file: /etc/nginx/sites-available/default

また、 `+ / etc / nginx / sites-available / default +`ファイルの内容も制御したいと思います。これは、コンテンツの提供方法を制御するサーバーブロックを定義します。状態ブロックは、最後のものとかなり似ています。主な違いは、このファイルがJinjaテンプレートになることです。

Jinjaテンプレートにより、Saltは、ファイルのコンテンツの一部を、それが配置される各ミニオンに固有の詳細でカスタマイズできます。これは、各ホストから情報を取得し、各Webサーバーに対して適切なカスタマイズされたバージョンのファイルを構築できることを意味します。このファイルは、Jinjaと `+ template `オプションを使用することを示します。また、ファイルがテンプレートであることを一目でわかるように、ソースファイルで接尾辞「 .jinja +」を使用します。

/srv/salt/nginx/init.sls

. . .

/etc/nginx/nginx.conf:
 file.managed:
   - source: salt://nginx/files/etc/nginx/nginx.conf
   - user: root
   - group: root
   - mode: 640

ミニオンホストの `+ sites-available `ディレクトリに配置される予定のデフォルトのサーバーブロックファイルがあります。ただし、ファイルを有効にするには、 ` sites-enabled `ディレクトリにファイルをリンクする必要があります。 ` file.symlink `関数でそれを行うことができます。元のファイルの場所を ` target`として指定するだけです。また、この状態が前の状態が正常に完了した後にのみ実行されるように、そのファイルを「必要」にする必要があります。

/srv/salt/nginx/init.sls

. . .

/etc/nginx/sites-available/default:
 file.managed:
   - source: salt://nginx/files/etc/nginx/sites-available/default.jinja
   - template: jinja
   - user: root
   - group: root
   - mode: 640

デフォルトのサイトコンテンツの状態

Nginxのインストール状態と構成状態が記述されています。ここで、サイトの実際のコンテンツになる `+ index.html`ファイルの状態を作成するだけです。

この状態は、以前のテンプレート状態とまったく同じ形式を使用します。唯一の違いは、このファイルの識別子、ソース、およびアクセス許可モードです。

/srv/salt/nginx/init.sls

. . .

/etc/nginx/sites-enabled/default:
 file.symlink:
   - target: /etc/nginx/sites-available/default
   - require:
     - file: /etc/nginx/sites-available/default

終了したら、このファイルを保存して閉じます。現時点では、実際のNginxの状態情報については完了です。

Nginxをインストールして元のファイルをソルトマスターに転送する

メインのNginx Salt状態ファイルが作成されました。ただし、作成した状態の一部は、まだ存在しないSaltマスターのファイルサーバー上の参照ファイルです。

ファイルはUbuntuのNginxパッケージによってインストールされるデフォルトのファイルとほぼ同じであるため、開始する最も簡単な方法はそのパッケージのファイルを使用することです。私たちの環境のいずれかのWebサーバーは、必要なファイルを取得できるようにNginxをインストールするのに最適な場所を提供します。

いずれの環境もスピンアップしていない場合は、展開する環境マップファイルのいずれかを選択します。このシリーズでは「ステージ」環境を使用します。これは、必要なすべてのサーバータイプを備えた最小の環境だからです。

sudo salt-cloud -P -m /etc/salt/cloud.maps.d/stage-environment.map

サーバーが稼働したら、いずれかのWebサーバーを選択してNginxをインストールします。この時点では、 `+ pkg +`実行モジュールを使用するだけです。これは、状態がまだ完全に機能していないためです。

sudo salt stage-www1 pkg.install nginx

Saltマスター設定をセットアップするとき、 `+ file_recv +`オプションを有効にしました。これにより、特定のファイルをマスターにプッシュするように手先に要求できます。これを使用して、管理するファイルのデフォルトバージョンを取得できます。

sudo salt stage-www1 cp.push /etc/nginx/nginx.conf
sudo salt stage-www1 cp.push /etc/nginx/sites-available/default
sudo salt stage-www1 cp.push /usr/share/nginx/html/index.html

これで、これらのファイルがマスターで使用可能になります。これらのファイルへのパスは、 `+ / var / cache / salt / master / minion // files in`ディレクトリ内に作成されます。この場合、ミニオンIDは「+ stage-www1 +」になります。次のように入力して、この場所の下のディレクトリ（ミニオンのファイルパスを表す）をSalt状態のディレクトリにコピーできます。

sudo cp -r /var/cache/salt/master/minions/stage-www1/files /srv/salt/nginx

状態ディレクトリの内容を見ると、「ファイル」と呼ばれる新しいディレクトリが表示されます。このディレクトリの下には、ミニオンのファイルシステム内の関連ディレクトリとコピーした3つのファイルがあります。

find /srv/salt/nginx -printf "%P\n"

Outputfiles
files/usr
files/usr/share
files/usr/share/nginx
files/usr/share/nginx/html
files/usr/share/nginx/html/index.html
files/etc
files/etc/nginx
files/etc/nginx/sites-available
files/etc/nginx/sites-available/default
files/etc/nginx/nginx.conf
init.sls

ここで、すべての管理対象ファイルが維持されます。これは、Nginx状態ファイルで設定した「ソース」の場所と一致します。

これで、Nginxがインストールされたミニオンからプルする必要のあるすべてのファイルがあるので、ミニオンを破棄して再構築できます。これにより、後で状態ファイルをクリーンなサーバーでテストできるようになります。 Nginxミニオンを破壊します。

sudo salt-cloud -d stage-www1

イベントが処理されるのを待った後、ミニオンを再構築できます。

通常、これにはマップファイルを使用しますが、単一のサーバーのみを再構築するため、実際には + stage-web +`プロファイルを直接使用することをお勧めします。次に、 `+ salt-cloud +`の代わりに `+ cloud.profile + Salt実行関数を使用できます。これにより、 `-async +`フラグを追加できます。基本的に、これにより、作業を継続しながらバックグラウンドで ` stage-www1 +`サーバーを再構築できます。これは必要なクラウドプロファイルを持つサーバーであるため、このコマンドでソルトマスターをターゲットにする必要があります。

sudo salt --async  cloud.profile stage-web stage-www1

`+ stage-www1 +`ノードがバックグラウンドで再構築されている間、続行できます。

/etc/nginx/nginx.confファイルを構成する

まず、メインのNginx設定ファイルを見てみましょう。これは、ミニオンの「+ / etc / nginx / nginx.conf 」に配置されます。 Nginx状態ディレクトリなしで、「 files in」ディレクトリの下にこのパスを見つけることができます。

cd /srv/salt/nginx/files/etc/nginx

現時点では実際にこのファイルを変更するつもりはありませんが、すぐに元のファイルをバックアップして元に戻すことができます。

sudo cp nginx.conf nginx.conf.orig

これにより、今後行うカスタマイズの参考になります。次のように入力すると、行った変更をすばやく確認できます。

diff nginx.conf nginx.conf.orig

将来、さまざまな環境でNginxの構成をカスタマイズする必要がある場合（たとえば、 `+ worker_processes +`を後で実稼働サーバーのCPUの数と一致させたい場合）、移行する可能性がありますテンプレートファイルを使用します。現時点ではこれは必要ないので、非テンプレートファイルとして、変更はハードコードされます。

ただし、前述したように、現時点では変更は必要ありません。次へ移りましょう。

/ etc / nginx / sites-available / defaultテンプレートを構成します

次に、デフォルトのサーバーブロックテンプレートを見てみましょう。このディレクトリでオリジナルを見つけることができます：

cd /srv/salt/nginx/files/etc/nginx/sites-available

繰り返しますが、後で必要になる場合に備えて、元のファイルをバックアップの場所にコピーする必要があります。

sudo cp default default.orig

次に、ファイルの名前を変更して、拡張子が「+ .jinja +」になるようにします。これにより、このファイルはテンプレートであり、それ自体では使用可能なファイルではないことが視覚的にわかります。

sudo mv default default.jinja

これで、テンプレートファイルを開いて変更を加えることができます。

sudo nano default.jinja

ファイルの一番上で、Jinjaのテンプレート機能の利用を開始する必要があります。デフォルトのサーバーブロックは、Webサーバーがロードバランサーの背後にあるかどうかに応じて、異なるファイルをレンダリングする必要があります。

ロードバランサーを介して接続を受信する場合、Webサーバーがプライベートインターフェイスへのトラフィックを制限するようにします。ただし、開発環境にはロードバランサーがないため、パブリックインターフェースを介してサービスを提供する必要があります。この区別はJinjaで作成できます。

アドレスが必要なインターフェイスを含む「+ interface 」という変数を作成します。ミニオンの環境が「dev」に設定されているかどうかをテストします。この場合、 ` eth0 `インターフェースを使用します。それ以外の場合は、サーバーのプライベートインターフェイスである「 eth1 」に設定します。次に、 ` grains.get `実行モジュール関数を使用して、選択したインターフェースに関連付けられたアドレスを取得し、それを ` addr +`変数の値として使用します。これをファイルの一番上に追加します。

/srv/salt/nginx/files/etc/nginx/sites-available/default.jinja

{%- set interface = 'eth0' if salt['grains.get']('env') == 'dev' else 'eth1' -%}
{%- set addr = salt['network.interface_ip'](interface) -%}
# You may add here your
# server {
#       ...
# }

. . .

次に、ファイルのさらに下の `+ server `ブロックを編集できます。 ` listen `と ` server_name `ディレクティブの上部に設定した ` addr +`変数を使用できます。このブロックの機能を制限するために、IPv6とデフォルトのサーバー部分を削除しました。

/srv/salt/nginx/files/etc/nginx/sites-available/default.jinja

{%- set interface = 'eth0' if salt['grains.get']('env') == 'dev' else 'eth1' -%}
{%- set addr = salt['network.interface_ip'](interface) -%}

. . .

server {
   listen :80;

   root /usr/share/nginx/html;
   index index.html index.htm;

   server_name ;

   location / {
       try_files $uri $uri/ =404;
   }
}

完了したら、ファイルを保存して閉じます。

これで、 `+ index.html`ファイルに移動できます。ファイルを含むソルトマスターのディレクトリに移動します。

cd /srv/salt/nginx/files/usr/share/nginx/html

内部では、前回使用したのと同じ手順で開始する必要があります。監査およびバックアップのために、元のファイルのコピーを保存する必要があります。次に、ファイルの名前を変更して、これがテンプレートであることを示す必要があります。

sudo cp index.html index.html.orig
sudo mv index.html index.html.jinja

必要な変更を加えることができるように、テンプレートファイルを開きます。

sudo nano index.html.jinja

上部で、Jinjaを使用して別の変数を設定します。ミニオンのホスト名を取得するには、 `+ grains.get `実行モジュール関数を使用します。これを ` host +`変数に保存します：

{% set host = salt['grains.get']('host') -%}
<!DOCTYPE html>
<html>

. . .

その後、ファイル全体でこの値を使用して、どのWebサーバーがリクエストを処理しているかを簡単に判断できるようにします。最初に `+ <title> +`の値を変更します：

{% set host = salt['grains.get']('host') -%}
<!DOCTYPE html>
<html>
<head>
<title>Welcome </title>
. . .

本文をこれに変更しましょう：

. . .

<body>
<h1>Welcome to nginx!</h1>




</body>
</html>

完了したら、ファイルを保存して閉じます。

Nginx状態ファイルのテスト

これで、Nginxの構成が完了しました。状態の適切な動作を確認するために、状態の特定の側面をテストできます。

まず、 `+ state.show_sls `実行モジュール関数を使用して、SaltがNginx状態ファイルをどのように解釈するかを表示できます。 ` stage-www1 +`サーバーをターゲットとして使用できます。ただし、この時点ではサーバー上では何も実行されません。

sudo salt stage-www1 state.show_sls nginx

次のような出力が返されます。

Outputstage-www1:
   ----------
   /etc/nginx/nginx.conf:
       ----------
       __env__:
           base
       __sls__:
           nginx
       file:
           |_
             ----------
             source:
                 salt://nginx/files/etc/nginx/nginx.conf
           |_
             ----------
             user:
                 root
           |_
             ----------
             group:
                 root
           |_
             ----------
             mode:
                 640
           - managed
           |_
             ----------
             order:
                 10002

. . .

主に、いくつかの興味深い追加とともに、 `+ / srv / salt / nginx / init.sls `ファイルからの情報をレンダリングします。 Saltがコマンドの読み方を知らなかった解釈エラーがないことを確認してください。各ピースの「順序」もチェックするのに適したアイテムです。これにより、ファイル内の個々の状態がいつ実行されるかが決まります。最初の状態の注文番号は「10000」になります。そこからすべての追加の状態がカウントアップされます。 ` env `は、グレインを使用して設定した ` env +`とは異なることに注意してください。このガイドでは、Saltの環境の概念を使用していません。

次に、状態ファイルを適用するドライランを実行できます。これは、 `+ test = True `オプションを指定した ` state.apply +`関数で実行できます。コマンドは次のようになります。

sudo salt stage-www1 state.apply nginx test=True

これにより、 `+ test = True +`オプションが削除された場合に行われる変更が表示されます。変更が意味をなし、Saltがすべてのファイルを正しく解釈できることを確認してください。「コメント」フィールドは、ソルトが状態を失敗としてマークしなかった場合でも問題を明らかにできるため、特に重要です。

予行演習で問題が明らかにならなかった場合は、次のように入力して、使用可能なすべてのWebサーバーに状態を適用することができます。

sudo salt -G 'role:webserver' state.apply nginx

Nginx状態をステージングWebサーバーまたは運用Webサーバーに適用した場合、それらの内部IPアドレスを取得する必要があります。ページは、パブリックインターフェースでは使用できません。

sudo salt-call mine.get 'role:webserver' internal_ip expr_form=grain

Outputlocal:
   ----------
   stage-www1:

   stage-www2:

一方、開発用ウェブサーバーをスピンアップしてNginx状態を適用した場合、次の理由から外部アドレスを取得する必要があります。

sudo salt-call mine.get 'role:webserver' external_ip expr_form=grain

`+ curl +`を使用してサーバーをテストできます：

curl

変更した `+ index.html`ページが表示されるはずです。

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>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

ご覧のとおり、ジンジャがレンダリングされたときに、ミニオンのホスト名がファイルに配置されました。 Nginxの状態が完成しました。

結論

これで、完全に機能するNginx状態になります。これにより、Saltで制御されたマシンを、仕様を備えたWebサーバーにすばやく簡単に変換できます。これを大規模なインフラストラクチャ管理戦略の一部として使用して、環境内にWebサーバーを簡単に構築します。

https://www.digitalocean.com/community/tutorials/saltstack-infrastructure-creating-salt-states-for-haproxy-load-balancers [次のガイド]では、ロードバランサーの状態を構築します。ウェブサーバーの前にトラフィックを誘導します。このガイドで使用したものと同じテクニックを使用して、ロードバランサーを柔軟にします。

TOC

SaltStackインフラストラクチャ：Nginx Webサーバーのソルトステートの作成

前書き

メインNginx状態ファイルを作成する

Nginxパッケージとサービス状態

Nginx構成ファイルの状態

デフォルトのサイトコンテンツの状態

Nginxをインストールして元のファイルをソルトマスターに転送する

/etc/nginx/nginx.confファイルを構成する

/ etc / nginx / sites-available / defaultテンプレートを構成します

Nginx状態ファイルのテスト

結論

Related

TOC

SaltStackインフラストラクチャ：Nginx Webサーバーのソルトステートの作成

前書き

メインNginx状態ファイルを作成する

Nginxパッケージとサービス状態

Nginx構成ファイルの状態

デフォルトのサイトコンテンツの状態

Nginxをインストールして元のファイルをソルトマスターに転送する

/etc/nginx/nginx.confファイルを構成する

/ etc / nginx / sites-available / defaultテンプレートを構成します

/usr/share/nginx/html/index.htmlテンプレートを構成します

Nginx状態ファイルのテスト

結論

Related