前書き
アプリを作成したら、今すぐデプロイする必要があります。 実稼働環境を作成してアプリをVMにセットアップすることもできますが、人気が出たときにどのようにスケーリングしますか？ 新しいバージョンをどのように展開しますか？ 負荷分散はどうですか？ そして、最も重要なのは、構成が正しいことをどのように確認できるかということです。 これをすべて自動化して、時間を大幅に節約できます。
このチュートリアルでは、Salt Cloudマップファイルでアプリケーションを定義する方法を示します。これには、カスタムSaltグレインを使用してサーバーにロールを割り当て、リバースプロキシを動的に構成することが含まれます。
このチュートリアルの最後には、2つの基本的なアプリサーバー、動的に構築された構成を持つNginxリバースプロキシ、および数分でアプリケーションをスケーリングする機能があります。
前提条件
このチュートリアルを実行するには、次のものが必要です。
-
1 GB CentOS 7ドロップレット1つ。 このチュートリアルのすべてのコマンドはrootとして実行されるため、sudoの非rootユーザーを作成する必要はありません。
-
* root *ユーザーのDroplet上のSSHキー（つまり、 ドロップレットで作成された新しいキーペア）。 このSSHキーをDigitalOceanコントロールパネルに追加して、それを使用してマスタードロップレットから他のDigitalOceanドロップレットにログインできるようにします。 手順については、https：//www.digitalocean.com/community/tutorials/how-to-use-ssh-keys-with-digitalocean-droplets [DigitalOcean DropletsでSSHキーを使用する方法]チュートリアルを使用できます。 + DigitalOceanコントロールパネルでキーに割り当てた名前を書き留めます。 このチュートリアルでは、名前を使用しています。 秘密鍵の場所も書き留めてください。デフォルトでは、 `+ / root / .ssh / id_rsa +`です。
-
https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2#how-to-generateのこの手順の指示に従って作成できる個人用アクセストークン-a-personal-access-token [DigitalOcean APIv2の使用方法]。 読み取りと書き込みのスコープを設定してください。
手順1-SaltおよびSalt Cloudのインストール
開始するには、サーバーにSalt Cloudをインストールして構成する必要があります。 このチュートリアルでは、Saltブートストラップスクリプトを使用します。
最初に、Saltブートストラップスクリプトをエッチングして、Saltをインストールします。
wget -O install_salt.sh https://bootstrap.saltstack.comSaltブートストラップスクリプトを実行します。 `+ -M `フラグを使用して、 ` salt-master +`もインストールします。
sh install_salt.sh -MSalt 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-Salt Cloudの構成
このセクションでは、DigitalOceanに接続するようにSalt Cloudを構成し、ドロップレットのプロファイルを定義します。
DigitalOceanプロバイダーファイルの構成
Salt Cloudでは、_provider files_は、新しいVMを作成する場所を定義する場所です。 プロバイダーは `+ / etc / salt / cloud.providers.d +`ディレクトリで定義されます
`+ nano +`またはお好みのテキストエディターを使用して、DigitalOceanプロバイダーファイルを作成して開きます。
nano /etc/salt/cloud.providers.d/digital_ocean.conf以下のテキストを挿入し、変数を自分のものに置き換えます。つまり、サーバーIPとアクセストークン、およびカスタマイズした場合はSSHキー名とファイルです。
/etc/salt/cloud.providers.d/digital_ocean.conf
### /etc/salt/cloud.providers.d/digital_ocean.conf ###
######################################################
do:
provider: digital_ocean
minion:
master:
# DigitalOcean Access Token
personal_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:
# This is the path on disk to the private key for your Digital Ocean account
ssh_key_file:SSHキーファイルの権限をロックダウンする必要があります。 そうしないと、SSHはその使用を拒否します。 yoursがデフォルトの場所 `+ / root / .ssh / id_rsa +`にあると仮定すると、次のようにできます：
chmod 600 /root/.ssh/id_rsaデプロイ可能なサーバーのプロファイルの構成
Salt Cloudでは、_profiles_は、プロバイダーに関連付けられている個々のVMの説明です（例： 「DigitalOcean上の512 MB Ubuntu VM」）。 これらは `+ / 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つのプロファイルを定義します。
-
512 MBのメモリを搭載したUbuntu 14.04 VM。ニューヨーク3リージョンに展開されています。
-
ニューヨーク3リージョンに展開された、1 GBのメモリを備えたUbuntu 14.04 VM。
Ubuntu 14.04以外のイメージを使用する場合は、Salt Cloudを使用して、次のコマンドでDigitalOceanで使用可能なすべてのイメージ名をリストできます。
salt-cloud --list-images doこれにより、すべての標準DigitalOceanイメージと、スナップショットツールでアカウントに保存したカスタムイメージが表示されます。 プロバイダーファイルで使用したイメージ名またはリージョンを、このリストとは異なるイメージ名に置き換えることができます。 その場合は、プロファイルファイルの設定でこの出力のフィールドを必ず使用してください。
クイッククエリで構成をテストします。
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ファイルです。 単純なマップファイルから始めて、次のセクションでその上に構築します。
上記のプロファイルを使用して、1つの512 MBリバースプロキシを前面に配置した2つの1 GBアプリサーバーが必要だとします。 `+ / 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つだけです。 2つの追加項目、「+ mine_functions 」セクションと「 grains +」セクションを見ていきましょう。
これらのVMのSalt Minion構成を変更し、カスタムのhttp://docs.saltstack.com/en/latest/topics/targeting/grains.html[grains]を追加するように、Salt Cloudに指示しました。 具体的には、グレインはリバースプロキシVMに「+ rproxy 」ロールを付与し、アプリサーバーに「 appserver +」ロールを付与します。 これは、リバースプロキシを動的に構成する必要がある場合に便利です。
`+ mine_functions +`もSalt Minionの設定に追加されます。 Minionに、* eth0 *で見つかったIPアドレスをhttp://docs.saltstack.com/en/latest/topics/mine/[Salt mine]に保存されるSalt Masterに送信するよう指示します。 これは、Salt Masterが新しく作成したDropletのIPを自動的に認識するため、設定する必要はありません。 これは次のパートで使用します。
ステップ5-リバースプロキシの定義
目の前に共通のタスクがあります。リバースプロキシWebサーバーをインストールして構成します。 このチュートリアルでは、Nginxをリバースプロキシとして使用します。
Nginx Saltステートの記述
手を汚し、いくつかのソルトの状態を書きます。 最初に、デフォルトのソルト状態ツリーの場所を作成します。
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']()[] }}; #
# 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;
}
}ファイルにhttp://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html[Jinja templating]が含まれていることを伝えるために、 `+ .jin +`拡張機能を使用します。 Jinjaテンプレートを使用すると、テキストファイルに少量のロジックを追加して、構成の詳細を動的に生成できます。
この構成ファイルは、すべてのポート80 HTTPトラフィックを取得してアプリファームに転送するようにNginxに指示します。 2つの部分があります：アップストリーム（アプリファーム）と、ユーザーとアプリファーム間のプロキシとして機能する構成です。
アップストリームについて話しましょう。 通常の、テンプレート化されていないアップストリームは、IPのコレクションを指定します。 ただし、ミニオンのIPアドレスが存在するまでは、そのIPアドレスがどうなるかはわかりません。また、設定ファイルを手動で編集することもありません。 （そうでなければ、Saltを使用する理由はありません！）
マップファイルの `+ mine_function +`行を覚えていますか？ ミニオンはソルトマスターにIPを提供して、そのような機会にそれらを保存します。 そのJinjaラインをもう少し詳しく見てみましょう。
ジンジャ抜粋
{% for server, addrs in salt['mine.get']('roles:appserver', 'network.ip_addrs', expr_form='grain').items() %}これは、Jinjaのforループであり、任意のSalt関数を実行します。 この場合、http：//docs.saltstack.com/en/latest/ref/modules/all/salt.modules.mine.html#salt.modules.mine.get [+ mine.get +]を実行しています。 パラメーターは以下のとおりです。
-
+ roles：appserver +-これは、「appserver」ロールを持つミニオンからのみ詳細を取得することを意味します。 -
+ network.ip_addrs +-これは、鉱山から取り出したいデータです。 マップファイルでもこれを指定しました。 -
+ expr_form = 'grain' +-これは、Saltに、グレインに基づいてミニオンをターゲットにしていることを伝えます。 穀物によるマッチングの詳細については、http：//docs.saltstack.com/en/latest/topics/targeting/grains.html [Saltstackターゲティングドキュメント]をご覧ください。
このループに続いて、変数 `+ {{addrs}} `にはIPアドレスのリストが含まれます（アドレスが1つだけであっても）。 リストであるため、最初の要素を ` [0] +`で取得する必要があります。
それが上流です。 サーバー名について：
server_name {{ salt['network.ip_addrs']()[0] }};これは、Salt mine呼び出し（JinjaでSalt関数を呼び出す）と同じトリックです。 単純です。 http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.network.html#salt.modules.network.ip_addrs [+ 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を使用してhttps://www.npmjs.org/package/forever [
+ 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');これは、1つのことを行う単純なNode.jsサーバーです。ポート1337でHTTP要求を受け入れ、サーバーのIPで応答します。
この時点で、次のようなファイル構造が必要です。
ファイル構造
/srv/salt
├── awesome-app
│ ├── app.sls
│ └── files
│ └── app.js
└── nginx
├── rproxy.sls
└── files
└── awesome-app.conf.jinステップ7-アプリケーションのデプロイ
あとは、アプリケーションを展開するだけです。
Salt Cloudを使用してサーバーを展開する
以前と同じ展開コマンドを実行します。これにより、これまでに行ったすべての構成が使用されます。
salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.mapSalt Cloudが完了するまで待ちます。これにはしばらく時間がかかります。 戻ったら、アプリサーバーにpingを実行して、展開が成功したことを確認します。
salt -G 'roles:appserver' test.ping君は見るべきだ：
アプリサーバーのping出力
appserver-02:
True
appserver-01:
Trueリバースプロキシのping：
salt -G 'roles:rproxy' test.ping君は見るべきだ：
リバースプロキシping出力
nginx-rproxy:
TrueVMを作成したら、それらを機能させる時間です。
アプリケーションを構築する
次に、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では、ここで何が起きたのでしょうか？
最初のコマンド（アプリサーバーを使用するコマンド）は、以前に記述したSalt状態を取得し、2つのアプリサーバーで実行しました。 これにより、同一バージョンのコードを実行する同一構成の2台のマシンが作成されました。
2番目のコマンド（リバースプロキシ）は、Nginx用に記述したSalt状態を実行しました。 Nginxと構成ファイルをインストールし、構成ファイルにアプリファームのIPを動的に入力しました。
これらのSaltが完了したら、テストして展開の成功を確認できます。 リバースプロキシのIPを見つけます。
salt -G 'roles:rproxy' network.ip_addrsDropletでプライベートネットワークを使用している場合、2つのIPを取得できます。
パブリックIPをブラウザーに接続して、Webページにアクセスしてください！ 更新を数回押して、構築した2つのアプリサーバー間でNginxが実際にプロキシしていることを確認します。 IPが変化し、実際に複数のアプリサーバーに接続していることを確認します。
更新しても同じIPを取得する場合は、ブラウザのキャッシュが原因である可能性があります。 代わりに `+ curl +`を使用して、Nginxがアプリサーバー間でプロキシしていることを示すことができます。 このコマンドを数回実行して、出力を観察します。
curl http://これをさらに数ステップ進め、http：//docs.saltstack.com/en/latest/topics/tutorials/states_pt5.html#states-overstate [OverState]を介してアプリケーションのデプロイを_完全に自動化できます。 これにより、1つのコマンドを作成してSaltに、たとえばアプリサーバーを最初にビルドしてからリバースプロキシのビルドに進み、ビルドプロセスの順序を保証するように指示できます。
ステップ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のコマンドと2つのコマンドを再実行します。
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既存のサーバーは、繰り返し実行されるソルトの影響を受けず、新しいサーバーは仕様に合わせて構築され、Nginxの構成は更新されて、新しいアプリサーバーへのトラフィックのルーティングが開始されます。
結論
サーバーのIPを報告するだけのアプリを展開することはあまり役に立ちません。 幸いなことに、このアプローチはNode.jsアプリケーションに限定されません。 Saltは、アプリの言語を気にしません。
このフレームワークを使用して独自のアプリをデプロイする場合、サーバーにアプリをインストールするタスクを自動化するだけで（スクリプトまたはソルトステートを使用）、サンプルを独自の自動化に置き換えることができます。
SaltがDropletのプロセスを自動化するように、Salt Cloudはクラウドのプロセスを自動化します。 楽しい！