SaltCloudマップファイルを使用してアプリケーションサーバーとNginxリバースプロキシをデプロイする方法
序章
アプリを作成したら、それをデプロイする必要があります。 本番環境を作成してVMにアプリをセットアップすることもできますが、人気が出たときにどのようにスケーリングしますか? 新しいバージョンをどのように展開しますか? 負荷分散についてはどうですか? そして、最も重要なことは、構成が正しいことをどのように確認できるでしょうか。 これらすべてを自動化して、時間を大幅に節約できます。
このチュートリアルでは、カスタムSaltグレインを使用してサーバーに役割を割り当てたり、リバースプロキシを動的に構成したりするなど、SaltCloudマップファイルでアプリケーションを定義する方法を示します。
このチュートリアルの最後に、2つの基本的なアプリサーバー、動的に構築された構成を持つNginxリバースプロキシ、およびアプリケーションを数分でスケーリングする機能があります。
前提条件
このチュートリアルに従うには、次のものが必要です。
1 GBCentOS7ドロップレット1つ。 このチュートリアルのすべてのコマンドはrootとして実行されるため、sudoの非rootユーザーを作成する必要はありません。
root ユーザー(つまり、 ドロップレットで作成された新しいキーペア)。 このSSHキーをDigitalOceanコントロールパネルに追加して、マスタードロップレットから他のDigitalOceanドロップレットにログインできるようにします。 手順については、DigitalOceanDropletsでSSHキーを使用する方法チュートリアルを使用できます。
DigitalOceanコントロールパネルでキーに割り当てた名前をメモします。 このチュートリアルでは、salt-master-root-keyという名前を使用しています。 秘密鍵の場所もメモしておく必要があります。 デフォルトでは、
/root/.ssh/id_rsa
です。DigitalOceanAPIv2の使用方法のこのステップの手順に従って作成できるパーソナルアクセストークン。 スコープは必ず読み取りと書き込みに設定してください。
ステップ1—SaltとSaltCloudのインストール
開始するには、サーバーにSaltCloudをインストールして構成する必要があります。 このチュートリアルでは、Saltブートストラップスクリプトを使用します。
まず、SaltブートストラップスクリプトをエッチングしてSaltをインストールします。
wget -O install_salt.sh https://bootstrap.saltstack.com
Saltブートストラップスクリプトを実行します。 -M
フラグを使用して、salt-master
もインストールします。
sh install_salt.sh -M
Salt CloudコードベースはコアSaltプロジェクトにマージされていますが、CentOS用に個別にパッケージ化されています。 幸い、install_salt
スクリプトでリポジトリが構成されたので、yumを使用してsalt-cloud
をインストールできます。
yum install salt-cloud
これで、Salt Cloudのバージョンをチェックして、インストールが成功したことを確認できます。
salt-cloud --version
次のような出力が表示されます。
salt-cloud--version出力
salt-cloud 2015.5.3 (Lithium)
Saltはローリングリリースサイクルであるため、バージョンが上記と若干異なる場合があることに注意してください。
ステップ2—ソルトクラウドの構成
このセクションでは、DigitalOceanに接続するようにSalt Cloudを構成し、ドロップレットのいくつかのプロファイルを定義します。
DigitalOceanプロバイダーファイルの構成
Salt Cloudでは、プロバイダーファイルは、新しいVMが作成される場所を定義する場所です。 プロバイダーは/etc/salt/cloud.providers.d
ディレクトリで定義されています
nano
またはお気に入りのテキストエディタを使用して、DigitalOceanプロバイダーファイルを作成して開きます。
nano /etc/salt/cloud.providers.d/digital_ocean.conf
以下のテキストを挿入し、 red の変数を自分の変数、つまりサーバーIPとアクセストークン、およびカスタマイズした場合はSSHキー名とファイルに置き換えます。
/etc/salt/cloud.providers.d/digital_ocean.conf
### /etc/salt/cloud.providers.d/digital_ocean.conf ### ###################################################### do: provider: digital_ocean minion: master: your_server_ip # DigitalOcean Access Token personal_access_token: your_access_token # This is the name of your SSH key in your Digital Ocean account # as it appears in the control panel. ssh_key_name: salt-master-root-key # This is the path on disk to the private key for your Digital Ocean account ssh_key_file: /root/.ssh/id_rsa
SSHキーファイルのアクセス許可をロックダウンする必要があります。 それ以外の場合、SSHはそれを使用することを拒否します。 デフォルトの場所/root/.ssh/id_rsa
にあると仮定すると、次の方法でこれを行うことができます。
chmod 600 /root/.ssh/id_rsa
デプロイ可能なサーバーのプロファイルの構成
Salt Cloudでは、プロファイルはプロバイダーに関連付けられた個々のVMの説明です(例: 「DigitalOcean上の512MBのUbuntuVM」)。 これらは/etc/salt/cloud.profiles.d
ディレクトリで定義されています。
プロファイルファイルを作成して開きます。
nano /etc/salt/cloud.profiles.d/digital_ocean.conf
以下をファイルに貼り付けます。 変更は必要ありません:
/etc/salt/cloud.profiles.d/digital_ocean.conf
### /etc/salt/cloud.profiles.d/digital_ocean.conf ### ##################################################### ubuntu_512MB_ny3: provider: do image: ubuntu-14-04-x64 size: 512MB location: nyc3 private_networking: True ubuntu_1GB_ny3: provider: do image: ubuntu-14-04-x64 size: 1GB location: nyc3 private_networking: True
ファイルを保存して閉じます。 このファイルは2つのプロファイルを定義します。
- ニューヨーク3リージョンにデプロイされた512MBのメモリを搭載したUbuntu14.04VM。
- NewYork3リージョンにデプロイされた1GBのメモリを搭載したUbuntu14.04VM。
Ubuntu 14.04以外のイメージを使用する場合は、Salt Cloudを使用して、次のコマンドでDigitalOceanで使用可能なすべてのイメージ名を一覧表示できます。
salt-cloud --list-images do
これにより、すべての標準DigitalOcean画像と、スナップショットツールを使用してアカウントに保存したカスタム画像が表示されます。 プロバイダーファイルで使用したイメージ名またはリージョンを、このリストとは別のイメージ名に置き換えることができます。 その場合は、プロファイルファイルのimage設定でこの出力のslugフィールドを使用してください。
クイッククエリを使用して構成をテストします。
salt-cloud -Q
次のようなものが表示されます。
salt-cloud-Q出力の例
[INFO ] salt-cloud starting do: ---------- digital_ocean: ---------- centos-salt: ---------- id: 2806501 image_id: 6372108 public_ips: 192.241.247.229 size_id: 63 state: active
これは、Salt CloudがDigitalOceanアカウントと通信しており、2つの基本プロファイルが構成されていることを意味します。
ステップ3—簡単な地図ファイルを書く
マップファイルは、作成するサーバーのプロファイルと数を一覧表示するYAMLファイルです。 簡単なマップファイルから始めて、次のセクションでそれを基に構築します。
上記のプロファイルを使用して、2つの1GBアプリサーバーの前に1つの512MBリバースプロキシが必要だとします。 /etc/salt/cloud.maps.d/do-app-with-rproxy.map
という名前のマップファイルを作成し、アプリを定義します。
まず、ファイルを作成します。
nano /etc/salt/cloud.maps.d/do-app-with-rproxy.map
次のテキストを挿入します。 変更は必要ありません:
/etc/salt/cloud.maps.d/do-app-with-rproxy.map
### /etc/salt/cloud.maps.d/do-app-with-rproxy.map #### ###################################################### ubuntu_512MB_ny3: - nginx-rproxy ubuntu_1GB_ny3: - appserver-01 - appserver-02
それでおしまい! これは、マップファイルが取得するのと同じくらい簡単です。 先に進み、これらのサーバーを次のように展開します。
salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map
コマンドが終了したら、すばやくpingを実行して成功を確認します。
salt '*' test.ping
次のように表示されます。
[label salt '*' test.ping appserver-01: True appserver-02: True nginx-rproxy: True
マップファイルにVMを正常に作成したら、それらを削除するのも同じくらい簡単です。
salt-cloud -d -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map
ただし、そのコマンドは注意して使用してください。 そのマップファイルで指定されたすべてのVMを削除します。
ステップ4—より現実的な地図ファイルを書く
そのマップファイルは正常に機能しましたが、シェルスクリプトでさえVMのセットを起動する可能性があります。 必要なのは、アプリケーションのフットプリントを定義することです。 マップファイルに戻って、さらにいくつか追加してみましょう。 マップファイルを再度開きます。
nano /etc/salt/cloud.maps.d/do-app-with-rproxy.map
ファイルの以前の内容を削除し、その中に次のものを配置します。 変更は必要ありません:
/etc/salt/cloud.maps.d/do-app-with-rproxy.map
### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ### ##################################################### ubuntu_512MB_ny3: - nginx-rproxy: minion: mine_functions: network.ip_addrs: interface: eth0 grains: roles: rproxy ubuntu_1GB_ny3: - appserver-01: minion: mine_functions: network.ip_addrs: interface: eth0 grains: roles: appserver - appserver-02: minion: mine_functions: network.ip_addrs: interface: eth0 grains: roles: appserver
今、私たちはどこかに到達しています! たくさんのように見えますが、追加したのは2つだけです。 mine_functions
セクションとgrains
セクションの2つの追加機能について見ていきましょう。
これらのVMのSaltMinion構成を変更し、カスタムグレインを追加するようにSaltCloudに指示しました。 具体的には、グレインはリバースプロキシVMにrproxy
の役割を与え、アプリサーバーにappserver
の役割を与えます。 これは、リバースプロキシを動的に構成する必要がある場合に役立ちます。
mine_functions
もSaltMinion構成に追加されます。 ミニオンに、 eth0 で見つかったIPアドレスをソルトマスターに送り返して、ソルトマインに保存するように指示します。 つまり、Salt Masterは、新しく作成されたDropletのIPを、構成しなくても自動的に認識します。 これは次のパートで使用します。
ステップ5—リバースプロキシの定義
現在、私たちの目の前に共通のタスクがあります。それは、リバースプロキシWebサーバーをインストールして構成することです。 このチュートリアルでは、リバースプロキシとしてNginxを使用します。
Nginxソルトステートの記述
手を汚して、いくつかのソルト状態を書く時が来ました。 まず、デフォルトのソルト状態ツリーの場所を作成します。
mkdir /srv/salt
そのディレクトリに移動し、nginx専用のディレクトリをもう1つ作成します。
cd /srv/salt mkdir /srv/salt/nginx
そのディレクトリに移動し、お気に入りのエディタを使用して、rproxy.sls
という名前の新しいファイルを作成します。
cd /srv/salt/nginx nano /srv/salt/nginx/rproxy.sls
そのファイルに以下を配置します。 変更は必要ありません:
/srv/salt/nginx/rproxy.sls
### /srv/salt/nginx/rproxy.sls ### ################################## ### Install Nginx and configure it as a reverse proxy, pulling the IPs of ### the app servers from the Salt Mine. nginx-rproxy: # Install Nginx pkg: - installed - name: nginx # Place a customized Nginx config file file: - managed - source: salt://nginx/files/awesome-app.conf.jin - name: /etc/nginx/conf.d/awesome-app.conf - template: jinja - require: - pkg: nginx-rproxy # Ensure Nginx is always running. # Restart Nginx if the config file changes. service: - running - enable: True - name: nginx - require: - pkg: nginx-rproxy - watch: - file: nginx-rproxy # Restart Nginx for the initial installation. cmd: - run - name: service nginx restart - require: - file: nginx-rproxy
この状態は次のことを行います。
- Nginxをインストールします。
- カスタム構成ファイルを
/etc/nginx/conf.d/awesome-app.conf
に配置します。 - Nginxが実行されていることを確認します。
私たちのSalt状態は、単にNginxをインストールし、構成ファイルをドロップします。 本当に興味深いコンテンツは設定にあります。
Nginxリバースプロキシ構成ファイルの書き込み
設定ファイル用にもう1つのディレクトリを作成しましょう。
mkdir /srv/salt/nginx/files cd /srv/salt/nginx/files
そして、設定ファイルを開きます。
nano /srv/salt/nginx/files/awesome-app.conf.jin
設定ファイルに以下を入れてください。 プライベートネットワークを使用していない場合を除き、変更は必要ありません。 その場合、インラインで注記されているように、1
を0
に変更します。
/srv/salt/nginx/files/awesome-app.conf.jin
### /srv/salt/nginx/files/awesome-app.conf.jin ### ################################################## ### Configuration file for Nginx to act as a ### reverse proxy for an app farm. # Define the app servers that we're in front of. upstream awesome-app { {% for server, addrs in salt['mine.get']('roles:appserver', 'network.ip_addrs', expr_form='grain').items() %} server {{ addrs[0] }}:1337; {% endfor %} } # Forward all port 80 http traffic to our app farm, defined above as 'awesome-app'. server { listen 80; server_name {{ salt['network.ip_addrs']()[1] }}; # <-- change the '1' to '0' if you're not using # DigitalOcean's private networking. access_log /var/log/nginx/awesome-app.access.log; error_log /var/log/nginx/awesome-app.error.log; ## forward request to awesome-app ## location / { proxy_pass http://awesome-app; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }
.jin
拡張子を使用して、ファイルに Jinjatemplatingが含まれていることを確認します。 Jinjaテンプレートを使用すると、テキストファイルに少量のロジックを追加できるため、構成の詳細を動的に生成できます。
この構成ファイルは、すべてのポート80 HTTPトラフィックを取得し、それをアプリファームに転送するようにNginxに指示します。 これには2つの部分があります。アップストリーム(アプリファーム)と、ユーザーとアプリファーム間のプロキシとして機能する構成です。
上流について話しましょう。 通常のテンプレート化されていないアップストリームは、IPのコレクションを指定します。 ただし、ミニオンのIPアドレスは、存在するまでわかりません。また、構成ファイルを手動で編集することもありません。 (そうでなければ、Saltを使用する理由はありません!)
マップファイルのmine_function
行を覚えていますか? ミニオンは、そのような機会のためにそれらを保存するためにソルトマスターにIPを与えています。 そのジンジャラインをもう少し詳しく見てみましょう。
神社抜粋
{% for server, addrs in salt['mine.get']('roles:appserver', 'network.ip_addrs', expr_form='grain').items() %}
これはJinjaのforループであり、任意のSalt関数を実行します。 この場合、mine.getを実行しています。 パラメータは次のとおりです。
roles:appserver
-これは、「appserver」の役割を持つミニオンからのみ詳細を取得することを意味します。network.ip_addrs
-これは私たちが鉱山から取得したいデータです。 これはマップファイルでも指定しました。expr_form='grain'
-これは、穀物に基づいてミニオンをターゲットにしていることをソルトに伝えます。 Saltstackターゲティングドキュメントでのグレインによるマッチングの詳細。
このループに続いて、変数テンプレート:Addrs
にはIPアドレスのリストが含まれます(アドレスが1つしかない場合でも)。 これはリストなので、[0]
で最初の要素を取得する必要があります。
それが上流です。 サーバー名について:
server_name {{ salt['network.ip_addrs']()[0] }};
これは、Salt mine呼び出し(JinjaでSalt関数を呼び出す)と同じトリックです。 簡単です。 network.ip_addrs を呼び出し、返されたリストの最初の要素を取得します。 これにより、ファイルを手動で編集する必要がなくなります。
ステップ6—アプリファームの定義
リバースプロキシは、背後にアプリがない場合はあまり意味がありません。 稼働しているサーバーのIPを報告するだけの小さなNode.jsアプリケーションを作成しましょう(両方のマシンに到達していることを確認できます)。
awesome-app
という名前の新しいディレクトリを作成し、そこに移動します。
mkdir -p /srv/salt/awesome-app cd /srv/salt/awesome-app
app.sls
という名前の新しいアプリ状態ファイルを作成します。
nano /srv/salt/awesome-app/app.sls
以下をファイルに入れます。 変更は必要ありません:
/srv/salt/awesome-app/app.sls
### /srv/salt/awesome-app/app.sls ### ##################################### ### Install Nodejs and start a simple ### web application that reports the server IP. install-app: # Install prerequisites pkg: - installed - names: - node - npm - nodejs-legacy # workaround for Debian systems # Place our Node code file: - managed - source: salt://awesome-app/files/app.js - name: /root/app.js # Install the package called 'forever' cmd: - run - name: npm install forever -g - require: - pkg: install-app run-app: # Use 'forever' to start the server cmd: - run - name: forever start app.js - cwd: /root
この状態ファイルは次のことを行います。
nodejs
、npm
、およびnodejs-legacy
パッケージをインストールします。- シンプルなアプリとなるJavaScriptファイルを追加します。
- NPMを使用してForeverをインストールします。
- アプリを実行します。
次に、(小さな)アプリコードを作成します。
mkdir /srv/salt/awesome-app/files cd /srv/salt/awesome-app/files
ファイルを作成します。
nano /srv/salt/awesome-app/files/app.js
その中に以下を入れてください。 変更は必要ありません:
/srv/salt/awesome-app/files/app.js
/* /srv/salt/awesome-app/files/app.js A simple Node.js web application that reports the server's IP. Shamefully stolen from StackOverflow: http://stackoverflow.com/questions/10750303/how-can-i-get-the-local-ip-address-in-node-js */ var os = require('os'); var http = require('http'); http.createServer(function (req, res) { var interfaces = os.networkInterfaces(); var addresses = []; for (k in interfaces) { for (k2 in interfaces[k]) { var address = interfaces[k][k2]; if (address.family == 'IPv4' && !address.internal) { addresses.push(address.address) } } } res.writeHead(200, {'Content-Type': 'text/plain'}); res.end(JSON.stringify(addresses)); }).listen(1337, '0.0.0.0'); console.log('Server listening on port 1337');
これは、ポート1337でHTTPリクエストを受け入れ、サーバーのIPで応答するという1つのことを行う単純なNode.jsサーバーです。
この時点で、次のようなファイル構造になっているはずです。
ファイル構造
/srv/salt ├── awesome-app │ ├── app.sls │ └── files │ └── app.js └── nginx ├── rproxy.sls └── files └── awesome-app.conf.jin
ステップ7—アプリケーションのデプロイ
残っているのは、アプリケーションをデプロイすることだけです。
SaltCloudを使用してサーバーをデプロイする
以前と同じ展開コマンドを実行します。これにより、これまでに作成したすべての構成が使用されます。
salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map
ソルトクラウドが完了するのを待ちます。 これにはしばらく時間がかかります。 戻ったら、アプリサーバーにpingを実行して、デプロイが成功したことを確認します。
salt -G 'roles:appserver' test.ping
君は見るべきだ:
アプリサーバーのping出力
appserver-02: True appserver-01: True
リバースプロキシにpingを実行します。
salt -G 'roles:rproxy' test.ping
君は見るべきだ:
リバースプロキシping出力
nginx-rproxy: True
VMを入手したら、次にそれらを機能させます。
アプリケーションを構築する
次に、Saltコマンドを発行して、アプリファームとリバースプロキシを自動的に構築します。
アプリファームを構築します。
salt -G 'roles:appserver' state.sls awesome-app.app
かなりの量の出力がありますが、次のように終了する必要があります。
Summary ------------ Succeeded: 6 (changed=6) Failed: 0 ------------ Total states run: 6
リバースプロキシを構築します。
salt -G 'roles:rproxy' state.sls nginx.rproxy
繰り返しになりますが、次のように終わるかなりの量の出力があります。
Summary ------------ Succeeded: 4 (changed=4) Failed: 0 ------------ Total states run: 4
では、ここで何が起こったのでしょうか。
最初のコマンド(アプリサーバーを使用するコマンド)は、前に記述したソルト状態を取得し、2つのアプリサーバーで実行しました。 これにより、同じ構成の2台のマシンが同じバージョンのコードを実行することになりました。
2番目のコマンド(リバースプロキシ)は、Nginx用に作成したSalt状態を実行しました。 Nginxと構成ファイルをインストールし、構成ファイルにアプリファームのIPを動的に入力しました。
これらのSaltの実行が完了したら、テストしてデプロイが成功したことを確認できます。 リバースプロキシのIPを見つけます。
salt -G 'roles:rproxy' network.ip_addrs
ドロップレットでプライベートネットワークを使用している場合は、2つのIPが返される可能性があります。
パブリックIPをブラウザに接続して、Webページにアクセスしてください。 更新を数回押して、構築した2つのアプリサーバー間でNginxが実際にプロキシしていることを確認します。 IPが変化し、実際に複数のアプリサーバーに接続していることを確認する必要があります。
更新しても同じIPを取得する場合は、ブラウザのキャッシュが原因である可能性があります。 代わりにcurl
を使用して、Nginxがアプリサーバー間でプロキシしていることを示すことができます。 このコマンドを数回実行し、出力を確認します。
curl http://ip-of-nginx-rproxy
これをさらに数ステップ進めて、完全に OverStateを介してアプリケーションの展開を自動化できます。 これにより、単一のコマンドをビルドして、たとえば、リバースプロキシのビルドに進む前に、最初にアプリサーバーをビルドするようにソルトに指示し、ビルドプロセスの順序を保証できます。
ステップ8—スケールアップ(オプション)
Saltを使用するポイントは、ビルドプロセスを自動化することです。 Salt Cloudとマップファイルを使用するポイントは、デプロイメントを簡単にスケーリングすることです。 デプロイメントにさらにアプリサーバー(たとえば、さらに2つ)を追加する場合は、マップファイルを次のように更新します。
/etc/salt/cloud.maps.d/do-app-with-rproxy.map
### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ### ##################################################### ubuntu_512MB_ny3: - nginx-rproxy: minion: mine_functions: network.ip_addrs: interface: eth0 grains: roles: rproxy ubuntu_1GB_ny3: - appserver-01: minion: mine_functions: network.ip_addrs: interface: eth0 grains: roles: appserver - appserver-02: minion: mine_functions: network.ip_addrs: interface: eth0 grains: roles: appserver - appserver-03: minion: mine_functions: network.ip_addrs: interface: eth0 grains: roles: appserver - appserver-04: minion: mine_functions: network.ip_addrs: interface: eth0 grains: roles: appserver
その更新を行った後、ステップ6のsalt-cloudコマンドと2つのsaltコマンドを再実行します。
salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map salt -G 'roles:appserver' state.sls awesome-app.app salt -G 'roles:rproxy' state.sls nginx.rproxy
既存のサーバーはSaltの繰り返し実行の影響を受けず、新しいサーバーは仕様に合わせて構築され、Nginx構成が更新されて、新しいアプリサーバーへのトラフィックのルーティングが開始されます。
結論
サーバーのIPを報告するだけのアプリをデプロイすることはあまり役に立ちません。 幸い、このアプローチはNode.jsアプリケーションに限定されていません。 Saltは、アプリがどの言語で書かれているかを気にしません。
このフレームワークを使用して独自のアプリをデプロイする場合は、サーバーにアプリをインストールするタスクを自動化し(スクリプトまたはSalt状態を使用)、awesome-appを置き換える必要があります。独自の自動化の例。
Saltがドロップレットのプロセスを自動化するのと同じように、SaltCloudはクラウドのプロセスを自動化します。 楽しみ!