前書き
このチュートリアルでは、DigitalOcean APIを使用して、DOProxyを使用してサーバーセットアップを水平方向にスケーリングする方法を示します。DOProxyは、構成後、HTTPアプリケーションサーバー層をスケールアップまたはスケールダウンするコマンドラインインターフェイスを提供するRubyスクリプトです。
DOProxyは、DigitalOcean APIを使用してHAProxyロードバランサーへのメンバーシップを管理することにより、アプリケーションサーバードロップレットを作成および削除する簡単な方法を提供するために、このチュートリアル専用に作成されました。 この基本的なスケーリングモデルにより、ユーザーはHAProxyサーバーを介してアプリケーションにアクセスし、負荷分散方式でバックエンドアプリケーションサーバーに転送できます。
DOProxyは3つの主要な機能を実行します。
-
ドロップレットを作成し、ロードバランサーに追加します
-
ドロップレットを削除し、ロードバランサーから削除します
-
削除されるまで、作成したドロップレットのインベントリを維持します
[.note]#Note:このチュートリアルの主な目的は、APIを介してDigitalOceanサーバーアーキテクチャをプログラムでスケーリングするために必要な最小限の概念を教えることです。 DOProxyは復元力を考慮して設計されておらず、非常に基本的なエラーチェックしか実行しないため、実稼働環境でDOProxyを実行しないでください。 そうは言っても、このスクリプトに精通することは、DigitalOcean APIを介した水平スケーリングについて学習するための優れた方法です。
#
前提条件
このチュートリアルでは、先に進む前に読んでおくとよい次のテクノロジーを使用します。
DOProxyはRubyで記述されているため、Rubyの知識は有益です。 Rubyに精通するために、How To Code in Rubyに関するシリーズを読むことができます。 Rubyに慣れていない場合は、DOProxyコードの要点を説明するための疑似コードを提供します。 APIの呼び出しを簡素化するために、公式のDigitalOcean RubyラッパーであるDropletKitを使用しています。
DOProxyの動作の詳細に入る前に、サーバーにインストールして使用します。
ここで、Ubuntu 16.04 DropletにDOProxyをインストールしましょう。
DOProxyをインストールする
まず、NYC3リージョンでUbuntu 16.04ドロップレットを作成します。DOProxyがデフォルトで使用するリージョンです。 別のリージョンを使用する場合は、DOProxyをインストールした後、doproxy.yml
ファイルでregion
変数を構成する必要があります。 このDropletは、HAProxyロードバランサーとDOProxyスケーリングスクリプトを実行するため、希望するスケールの可能性に適したサイズを選択します。 このチュートリアルは、実際のトラフィックを想定しないスケーリングの基本的なデモンストレーションであるため、おそらく512MBのサイズで十分です。
このドキュメントの長さについては、このドロップレットをDOProxy serverと呼びます。
次に、サーバーにログインし、DOProxy GitHub repository READMEのInstallationおよびConfiguration(doproxy configおよびUserdataを含む)セクションに従って、このサーバーにDOProxyをインストールします。 DOproxy構成ファイルのYOUR_DO_API_TOKEN
とYOUR_SSH_KEY_FINGERPRINT
の値を必ず置き換えてください。そうしないと、スクリプトが機能しません。
サーバーにDOProxyとHAProxyがインストールされたので、環境を拡張してみましょう。
DOProxyを実行する
DOProxyサーバーにrootとしてログインし、DOProxyのクローンを作成したディレクトリに移動します。
引数なしでDOProxyを実行します。
ruby doproxy.rb
これにより、使用可能なコマンドが出力されます。
OutputCommands:
doproxy.rb print # Print backend Droplets in inventory file
doproxy.rb create # Create a new backend Droplet and reload
doproxy.rb delete # Delete a Droplet and reload
doproxy.rb reload # Generate HAProxy config and reload HAProxy
doproxy.rb generate # Generate HAProxy config based on inventory
この時点で、DOProxyはまだドロップレットを作成していません。 HTTPサービスをオンラインで取得してスケールアップするためにいくつか作成してみましょう。
スケールアップ(作成)
create
コマンドを実行して、DOProxyによって管理される最初のドロップレットを作成します。
ruby doproxy.rb create
これは、プロンプトに戻るまでに時間がかかります(スクリプトがAPIを介して新しいドロップレットを作成し、起動するのを待つため)。 疑似コードを実行するときにAPI呼び出しがどのように行われるかについて説明します。
スクリプトが完了すると、ドロップレットIDを含む成功メッセージが表示されます。
OutputSuccess: 4202645 created and added to backend.
ユーザーデータスクリプトがまだ実行されておらず、HAProxyがトラフィックの受け渡しを開始していない可能性があるため、プロンプトが戻ってから数分待ってから次の手順に進むことをお勧めします。
続行する準備ができたら、WebブラウザーでDOProxyサーバーのパブリックIPアドレスにアクセスします。 新しいドロップレットのhostname、id、およびpublic IP addressを一覧表示するページが表示されます。
DOProxyを使用して、さらに2つのドロップレット(合計3つ)を作成します。 必要に応じてさらに作成してください。
ruby doproxy.rb create
ruby doproxy.rb create
次に、WebブラウザーでDOProxyサーバーのパブリックIPアドレスに再度アクセスします。 ページを更新すると、作成したドロップレットを循環している間にページの情報が変更されることに気付くでしょう。 これは、DOProxyで作成されたときに各ドロップレットをその構成に追加したHAProxyによってすべて負荷分散されているためです。
DigitalOceanコントロールパネルを見ると、これらの新しいドロップレットが(他のドロップレットと共に)そこにリストされていることがわかります。
DOProxyの在庫を見て作成されたドロップレットを詳しく見てみましょう。
在庫の印刷
DOProxyは、インベントリの一部であるすべてのドロップレットを出力するprint
コマンドを提供します。
ruby doproxy.rb print
次のような出力が表示されるはずです。
Output0) auto-nginx-0 (pvt ip: 192.0.2.175, status: active, id: 4202645)
1) auto-nginx-1 (pvt ip: 192.0.2.176, status: active, id: 4205587)
2) auto-nginx-2 (pvt ip: 192.0.2.172, status: active, id: 4205675)
出力例では、ホスト名、ステータス、ドロップレットIDなど、作成した3つのドロップレットに関する情報が表示されます。 ホスト名とIDは、HAProxyロードバランサーにアクセスしたときに(DOProxyのパブリックIPアドレス経由で)Webブラウザーで表示したものと一致する必要があります。
お気づきかもしれませんが、DOProxyは、作成したドロップレットに関する情報のみを出力しました。 これは、作成するドロップレットのインベントリを保持するためです。
今すぐinventory
ファイルの内容を確認してください。
cat inventory
各ドロップレットのIDが1行に1つずつ表示されます。 ドロップレットが作成されるたびに、そのIDはこのインベントリファイルに保存されます。
ご想像のとおり、DOProxyのprint
コマンドは、インベントリファイル内のドロップレットIDを反復処理し、API呼び出しを実行して各ドロップレットIDに関する情報を取得します。
サーバーインベントリを単一のファイルに保存するのは最善の解決策ではないことに注意してください(簡単に破損または削除される可能性があります)が、動作するシンプルな実装を示しています。 etcdなどの分散キー値ストアがより良いソリューションです。 また、インベントリにドロップレットIDだけを保存することもできます(したがって、特定のドロップレット情報を確認するたびにAPI呼び出しを行う必要はありません)。
縮小(削除)
DOProxyには、インベントリ内のドロップレットを削除できるdelete
コマンドもあります。 delete
コマンドでは、削除するドロップレットの行番号を指定する必要があります(print
コマンドで表示されます)。
このコマンドを実行する前に、おそらくインベントリを印刷する必要があります。
ruby doproxy.rb print
したがって、たとえば、3番目のドロップレットを削除する場合は、行番号として2
を指定します。
ruby doprorxy.rb delete 2
しばらくすると、確認メッセージが表示されます:
OutputSuccess: 4205675 deleted and removed from backend.
delete
コマンドは、APIを介してドロップレットを削除し、HAProxy構成から削除して、インベントリから削除します。 DOProxy印刷コマンドを使用するか、DigitalOceanコントロールパネルをチェックして、ドロップレットが削除されたことを確認してください。 また、ロードバランサーの一部ではなくなったことにも気付くでしょう。
HAProxy設定
まだ説明していないDOProxyの最後の部分は、HAProxyの構成方法です。
create
またはdelete
DOProxyコマンドを実行すると、インベントリ内の各ドロップレットの情報が取得され、その情報の一部がHAProxy構成ファイルの変更に使用されます。 特に、ドロップレットIDとプライベートIPアドレスは、各ドロップレットをバックエンドサーバーとして追加するために使用されます。
生成されたhaproxy.cfg
ファイルの最後の数行を次のように見てください。
tail haproxy.cfg
このようなものが見えるはずです。
haproxy.cfgのテール
frontend www-http
bind 203.0.113.43:80
reqadd X-Forwarded-Proto:\ http
default_backend www-backend
backend www-backend
server www-4202645 192.0.2.175:80 check # id:4202645, hostname:auto-nginx-0
server www-4205587 192.0.2.176:80 check # id:4205587, hostname:auto-nginx-1
frontend
セクションには、DOProxyサーバーのパブリックIPアドレスが含まれている必要があり、backend
セクションには、作成された各ドロップレットを参照する行が含まれている必要があります。
[.note]#Note:この時点で、DOProxyで作成された残りのドロップレットを削除することをお勧めします(すべてのサーバーがなくなるまでruby doproxy.rb delete 0
)。
#
DOProxyのスケーリングの実際の動作を確認したので、コードを詳しく見てみましょう。
DOProxyコード
このセクションでは、DOProxyを機能させる関連ファイルとコード行を見ていきます。 DOProxyの実装方法を確認すると、APIを使用して独自のサーバーインフラストラクチャを管理および自動化する方法についてのアイデアが得られるはずです。
リポジトリをサーバーに複製したので、そこにあるファイルを確認するか、DOProxyリポジトリ(https://github.com/scanevari/doproxy)にあるファイルを確認できます。
重要なファイル:
-
doproxy.rb
:DOProxyRubyスクリプト。 DOProxyの背後にあるコマンドラインインターフェイスとロジックを提供します -
doproxy.yml
:DOProxy構成ファイル。 APIトークンが含まれ、ドロップレット作成オプションを指定します -
haproxy.cfg.erb
:HAProxy構成テンプレート。 適切なバックエンドサーバー情報でロードバランサー構成を生成するために使用 -
inventory
:液滴インベントリファイル。 作成されたドロップレットのIDを保存します -
user-data.yml
:ユーザーデータファイル。 新しいDropletの作成時に実行されるcloud-configファイル
最初に構成ファイルに飛び込みましょう。
doproxy.yml
これらはdoproxy.yml
の重要な行です。
doproxy.yml
token: YOUR_DO_API_TOKEN
ssh_key_ids:
- YOUR_SSH_KEY_FINGERPRINT
...
droplet_options:
hostname_prefix: auto-nginx
region: nyc3
size: 1gb
image: ubuntu-16-04-x64
token
プロパティは、read and writeAPIトークンを保持する必要があるプロパティです。
他の行は、DOProxyが新しいドロップレットを作成するときに使用されるオプションを指定します。 たとえば、指定されたSSHキーを(IDまたは指紋によって)インストールし、ホスト名に「auto-nginx」をプレフィックスとして付けます。
有効なドロップレットオプションの詳細については、DigitalOcean API documentationを参照してください。
user-data.yml
これは、新しいDropletが作成されるたびにcloud-initによって実行されるファイルです。 これは、クラウド構成ファイルまたはスクリプトを提供して、新しい各ドロップレットにアプリケーションソフトウェアをインストールできることを意味します。
サンプルのユーザーデータファイルには、UbuntuサーバーにNginxをインストールし、デフォルトの構成ファイルをDropletのホスト名、ID、パブリックIPアドレスに置き換える簡単なbashスクリプトが含まれています。
user-data.yml
#!/bin/bash
apt-get -y update
apt-get -y install nginx
export DROPLET_ID=$(curl http://169.254.169.254/metadata/v1/id)
export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, ID: $DROPLET_ID, IP Address: $PUBLIC_IPV4 > /var/www/html/index.html
これらのcurl
コマンドは、DigitalOceanメタデータサービスを使用して、ドロップレットに関する情報(ホスト名、ID、およびIPアドレス)を取得しています。
本番環境の実装では、このファイルには、たとえばアプリケーションをインストールして構成するためのコマンドが含まれます。 また、これを使用して、SSHキーを自動的にインストールし、構成管理ツールまたは監視ツールに接続するなどの方法で、インフラストラクチャ全体へのドロップレットの統合を自動化することもできます。
ユーザーデータ、クラウド構成、メタデータの詳細については、次のリンクをご覧ください。
haproxy.cfg.erb
HAProxy構成テンプレートには、ほとんどのロードバランサー構成が含まれており、Rubyコードはバックエンドドロップレット情報に置き換えられます。
バックエンド構成を生成するRubyセクションを見てみましょう。
haproxy.cfg.erb
backend www-backend
<% @Droplets.each_with_index do |droplet, index| %>
server www-<%= droplet.id %> <%= droplet.private_ip %>:80 check # id:<%= droplet.id %>, hostname:<%= droplet.name -%>
<% end %>
このコードは、インベントリ内の各ドロップレットを反復処理し、それらの各ドロップレットに(プライベートIPアドレスに基づいて)新しいHAProxyバックエンドエントリを追加します。
たとえば、各ドロップレットに対して次のような行が生成されます。
haproxy.cfg
server www-4202645 192.0.2.175:80 check # id:4202645, hostname:auto-nginx-0
ドロップレットが作成または削除されるたびに、DOProxyは変更を含む新しいHAProxy構成ファイルを生成します。
doproxy.rb
このRubyスクリプトは、主に、ドロップレットの作成と削除、インベントリ管理、HAProxy構成の生成を実行するメソッドを含むDOProxyクラスで構成されています。
Rubyを理解している場合は、GitHubのファイルhttps://github.com/scanevari/doproxy/blob/master/doproxy.rbを確認してください。
Rubyを理解していない場合は、各方法を説明する簡単なpseudocode
を次に示します。 これを実際のRubyコードと比較すると、何が起こっているのかを理解するのに役立つ場合があります。
def initialize
有効な引数を指定してDOProxyが実行されるたびに実行されます。
-
doproxy.yml
構成ファイルを読み取り、APIトークンとドロップレットオプションを取得します。
def get\_inventory
インベントリファイル内の各ドロップレットの情報を取得します。 他のメソッドを実行する前に実行する必要があります。
-
インベントリファイルの読み取り(ドロップレットIDを含む)
-
各ドロップレットIDについて、APIを使用してドロップレット情報を取得します
def print\_inventory
このメソッドは、インベントリファイル内の各ドロップレットIDのドロップレット情報を出力します。 doproxy.rb print
コマンドで呼び出されます。
-
インベントリ内の各ドロップレットについて、ホスト名、プライベートIPアドレス、ステータス、およびIDを印刷します
def create\_server
このメソッドをdoproxy.rb create
コマンドで呼び出すと、新しいドロップレットが作成され、インベントリファイルに追加されます。 次に、reload_haproxy
を呼び出して、HAProxy構成ファイルを再生成し、ロードバランサーをリロードします。
-
ユーザーデータファイルを読む
-
APIを使用して、提供されたユーザーデータとオプションに基づいてドロップレットを作成します
-
ドロップレットのステータスが「アクティブ」になるのを待つ— APIを使用して、ステータスが変わるまで15秒ごとにドロップレット情報を取得します
-
ステータスが「アクティブ」の場合、インベントリファイルにドロップレットIDを追加します
-
reload_haproxy
を呼び出して、HAProxy構成ファイルを再生成し、ロードバランサーをリロードします
def delete\_server(line\_number)
doproxy.rb delete
コマンドを使用すると、このメソッドは指定されたドロップレットを削除し、そのIDをインベントリファイルから削除します。 次に、reload_haproxy
を呼び出して、HAProxy構成ファイルを再生成し、ロードバランサーをリロードします。
-
インベントリファイルから指定された行を削除します(ドロップレットIDを削除します)
-
APIを使用して、IDでDropletを削除します
-
reload_haproxy
を呼び出して、HAProxy構成ファイルを再生成し、ロードバランサーをリロードします
def generate\_haproxy\_cfg
これは、インベントリ内のドロップレットに基づいて新しいHAProxy構成ファイルを作成するサポート方法です。
-
HAProxy構成テンプレートを開きます(
haproxy.cfg.erb
) -
インベントリ内の各ドロップレットについて、対応するバックエンドサーバーエントリを追加します
-
結果の
haproxy.cfg
ファイルをディスクに書き込みます
def reload\_haproxy
これは、HAProxy構成ファイルを適切な場所にコピーしてHAProxyをリロードする別のサポート方法です。 これはgenerate_haproxy_cfg
に依存します。
-
HAProxy構成ファイル
haproxy.cfg
を、HAProxyがリロード時に検索する場所にコピーします -
HAProxyをリロードする
これがDOProxyを機能させる重要なコードのすべてです。 最後に説明するのは、DOProxyで使用したAPIラッパーであるDropletKitです。
DropletKit Gem
DOProxyは、DigitalOcean APIへの呼び出しを容易にする公式のDigitalOceanAPI v2 RubyラッパーであるDropletKit gemを使用します。 DropletKitを使用すると、次のようなことを行うRubyプログラムを簡単に作成できます。
-
新しいドロップレットを作成する
-
既存のドロップレットを削除する
-
ステータス、IPアドレス、ドロップレットID、地域など、既存のドロップレットに関する情報を取得します
このチュートリアルでは、これらの特定のAPIエンドポイントに焦点を当てましたが、DigitalOceanサーバーインフラストラクチャのプログラムによる管理を容易にするのに役立つ他の多くのエンドポイントがあることに留意してください。
結論
DigitalOcean API、cloud-config、およびメタデータを活用して簡単なスクリプトでサーバー環境を拡張する方法を確認したので、これらすべての概念を適用して独自のサーバー設定を拡張できます。 DOProxyは実稼働環境での使用を目的としていませんが、独自のスケーリングソリューションを実装するための優れたアイデアを提供するはずです。
ここでDOProxyを使用して説明したスケーリング設定は情報提供ですが、monitoring systemと組み合わせて使用することで大幅に改善される可能性があることに注意してください。 これにより、サーバーリソースの使用率などの特定の条件に応じて、アプリケーションサーバー層を自動的にスケールアップおよびスケールダウンできます。