序章

このチュートリアルでは、DigitalOceanAPIを使用してサーバー設定を水平方向にスケーリングする方法を示します。 これを行うには、 DOProxy を使用します。これは、比較的単純なRubyスクリプトであり、構成すると、HTTPアプリケーションサーバー層をスケールアップまたはスケールダウンするためのコマンドラインインターフェイスを提供します。

このチュートリアル用に特別に作成されたDOProxyは、DigitalOcean APIを使用して、アプリケーションサーバーのドロップレットを作成および削除し、HAProxyロードバランサーの背後でそれらを自動的に管理するための簡単な方法を提供します。 この基本的なスケーリングモデルにより、ユーザーはHAProxyサーバーを介してアプリケーションにアクセスでき、負荷分散されたバックエンドアプリケーションサーバーに転送されます。

DOProxyは、次の3つの主要な機能を実行します。

  • ドロップレットを作成し、ロードバランサーに追加します
  • ドロップレットを削除し、ロードバランサーから削除します
  • 削除されるまで、作成した液滴のインベントリを維持します

DOProxy create

注:このチュートリアルの主な目的は、APIを介してDigitalOceanサーバーアーキテクチャをプログラムでスケーリングするために必要な最小限の概念を教えることです。 DOProxyを現在の形式で、実稼働環境で実行しないでください。 復元力を念頭に置いて設計されたものではなく、問題を解決するのに十分なエラーチェックを実行します。 そうは言っても、APIを介した水平スケーリングについて知りたい場合は、始めるのに最適な方法です。

前提条件

このチュートリアルでは、先に進む前に読んでおくとよいさまざまなテクノロジーについて説明します。

DOProxyはRubyで記述されているため、Rubyの知識はプラスですが必須ではありません。 DOProxyコードの要点を説明するための擬似コードを提供します。 また、公式のDigitalOceanRubyラッパーDropletKit を使用します。これにより、RubyコードでAPI呼び出しを簡単に行うことができます。

DOProxyの動作の詳細に入る前に、サーバーにインストールして使用します。 今すぐUbuntu14.04ドロップレットにDOProxyをインストールしましょう。

DOProxyをインストールします

まず、NYC3リージョンにUbuntu 14.04ドロップレットを作成します(doproxy.ymlファイル(DOProxyのインストール後)。 このドロップレットは、HAProxyロードバランサーとDOProxyスケーリングスクリプトを実行するため、目的のスケールの可能性に適していると思われるサイズを選択してください。 このチュートリアルはスケーリングの基本的なデモンストレーションであり、実際のトラフィックを受信しないため、おそらく1GBのサイズで十分です。

このドロップレットをDOProxyサーバーと呼びます。

次に、ログインして、DOProxyGitHubリポジトリのInstallationおよびConfiguration doproxyconfigおよびUserdataを含む)セクションに従います。 このサーバーにDOProxyをインストールします。 サンプルのdoproxy.ymlおよびuser-data.ymlファイルを、指示に従ってコピーして使用します。 DOproxy構成ファイルのtokenssh_key_idsの値を必ず置き換えてください。置き換えないと、スクリプトが機能しません。

サーバーにDOProxyとHAProxyがインストールされたので、環境を拡張してみましょう。

DOProxyを実行します

root としてDOProxyサーバーにログインし、まだ行っていない場合は、DOProxyのクローンを作成したディレクトリに移動します。

次に、引数なしでDOProxyを実行します。

ruby doproxy.rb

これにより、次のような使用可能なコマンドが出力されます。

Commands:
doproxy.rb print                   # Print backend droplets in inventory file
doproxy.rb create                  # Create a new backend droplet and reload
doproxy.rb delete <LINE_NUMBER>    # 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を介して新しいドロップレットを作成し、起動するのを待つため)。 後でDOProxyコードを実行するときに、API呼び出しがどのように行われるかについて説明します。

完了すると、次のように、ドロップレットIDを含む成功メッセージが表示されます。

Success: 4202645 created and added to backend.

WebブラウザでDOProxyサーバーのパブリックIPアドレスにアクセスした場合。 新しいドロップレットのホスト名 id 、およびパブリックIPアドレスを一覧表示するページが表示されます。

DOProxyを使用して、さらに2つの液滴、合計3つの液滴を作成します。 必要に応じて、さらに作成してください。

ruby doproxy.rb create
ruby doproxy.rb create

次に、WebブラウザでDOProxyサーバーのパブリックIPアドレスに再度アクセスします。 ページを更新すると、ページの情報が変更され、作成したドロップレットが循環します。 これは、それらがすべてHAProxyによって負荷分散されているためです。各ドロップレットは、作成時にロードバランサー構成に追加されます。

DigitalOceanコントロールパネルを見ると、これらの新しい液滴が(残りの液滴とともに)そこにリストされていることに気付くでしょう。

Droplets in Control Panel

DOProxyのインベントリを見て作成された液滴を詳しく見てみましょう。

DOProxyは、 print コマンドを提供します。このコマンドは、インベントリの一部であるすべてのドロップレットを印刷します。

ruby doproxy.rb print

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

0) auto-nginx-0  (pvt ip: 10.132.224.168, status: active, id: 4202645)
1) auto-nginx-1  (pvt ip: 10.132.228.224, status: active, id: 4205587)
2) auto-nginx-2  (pvt ip: 10.132.252.42, status: active, id: 4205675)

出力例では、ホスト名、ステータス、ドロップレットIDなど、作成した3つのドロップレットに関する情報が表示されます。 ホスト名とIDは、(DOProxyのパブリックIPアドレスを介して)HAProxyロードバランサーにアクセスしたときに表示されたものと一致する必要があります。

お気づきかもしれませんが、DOProxyは作成した液滴に関する情報のみを出力しました。 これは、作成する液滴のインベントリを維持するためです。

inventoryファイルの内容を今すぐチェックしてください。

cat inventory

各液滴のIDが1行に1つずつ表示されます。 ドロップレットが作成されるたびに、そのIDがこのインベントリファイルに保存されます。

ご想像のとおり、DOProxyのprintコマンドは、インベントリファイル内のドロップレットIDを繰り返し処理し、API呼び出しを実行して各IDに関するドロップレット情報を取得します。

サーバーインベントリを単一のファイルに保存することは最善の解決策ではなく、簡単に破損または削除される可能性があることに注意してください。ただし、これは機能する単純な実装を示しています。 etcdなどの分散型KeyValueストアがより優れたソリューションになります。 また、インベントリにドロップレットIDだけでなく、それ以上のものを保存することもできます(したがって、特定のドロップレット情報を確認するたびにAPI呼び出しを行う必要はありません)。

スケールダウン(削除)

DOProxyには、インベントリ内のドロップレットを削除できる削除コマンドもあります。 削除コマンドでは、削除するドロップレットの行番号を指定する必要があります(printコマンドで表示されます)。

このコマンドを実行する前に、インベントリを印刷することをお勧めします。

ruby doproxy.rb print

したがって、たとえば、3番目の液滴を削除する場合は、行番号として2を指定します。

ruby doprorxy.rb delete 2

しばらくすると、確認メッセージが表示されます。

Success: 4205675 deleted and removed from backend.

deleteコマンドは、APIを介してドロップレットを削除し、HAProxy構成から削除して、インベントリから削除します。 DOProxy印刷コマンドを使用するか、DigitalOceanコントロールパネルをチェックして、液滴が削除されたことを確認してください。 また、ロードバランサーの一部ではなくなったことにも気付くでしょう。

HAProxyの設定

まだ説明していないDOProxyの最後の部分は、HAProxyの構成方法です。

createまたはdeleteDOProxyコマンドを実行すると、インベントリ内の各ドロップレットの情報が取得され、その情報の一部がHAProxy構成ファイルの作成に使用されます。 特に、ドロップレットIDとプライベートIPアドレスは、各ドロップレットをバックエンドサーバーとして追加するために使用されます。

生成されたhaproxy.cfgファイルの最後の数行を次のように見てください。

tail haproxy.cfg

次のように表示されます。

	frontend www-http
	   bind 104.236.236.43:80
	   reqadd X-Forwarded-Proto:\ http
	   default_backend www-backend

	backend www-backend

	   server www-4202645 10.132.224.168:80 check # id:4202645, hostname:auto-nginx-0
	   server www-4205587 10.132.228.224:80 check # id:4205587, hostname:auto-nginx-1

frontendセクションには、DOProxyサーバーのパブリックIPアドレスが含まれている必要があり、backendセクションには、作成された各ドロップレットを参照する行が含まれている必要があります。

注:この時点で、DOProxyで作成された残りのドロップレットを削除することをお勧めします(すべてのサーバーがなくなるまでruby doproxy.rb delete 0)。

DOProxyのスケーリングの動作を確認したので、コードを詳しく見てみましょう。

DOProxyコード

このセクションでは、DOProxyを機能させるための関連ファイルとコード行について説明します。 DOProxyがどのように実装されたかを見ると、APIを使用して独自のサーバーインフラストラクチャを管理および自動化する方法についてのアイデアが得られるはずです。

リポジトリをサーバーに複製したので、そこでファイルを確認するか、DOProxyリポジトリ(https://github.com/thisismitch/doproxy)でファイルを確認できます。

重要なファイル:

  • doproxy.rb :DOProxyRubyスクリプト。 DOProxyの背後にあるコマンドラインインターフェイスと頭脳を提供します
  • doproxy.yml :DOProxy構成ファイル。 APIトークンが含まれ、ドロップレット作成オプションを指定します
  • haproxy.cfg.erb :HAProxy構成テンプレート。 適切なバックエンドサーバー情報を使用してロードバランサー構成を生成するために使用されます
  • Inventory :ドロップレットインベントリファイル。 作成された液滴のIDを格納します
  • user-data.yml :ユーザーデータファイル。 作成時に新しいドロップレットで実行されるcloud-configファイル

まず、構成ファイルについて詳しく見ていきましょう。

doproxy.yml

DOProxy構成ファイルdoproxy.ymlの重要な行は次のとおりです。

token: 878a490235d53e34b44369b8e78
ssh_key_ids:           # DigitalOcean ID for your SSH Key
  - 163420
...
droplet_options:
  hostname_prefix: auto-nginx
  region: nyc3
  size: 1gb
  image: ubuntu-14-04-x64

tokenは、読み取りおよび書き込みAPIトークンを構成できる場所です。

他の行は、DOProxyが新しいドロップレットを作成するときに使用されるオプションを指定します。 たとえば、指定されたSSHキー(IDまたはフィンガープリントによる)をインストールし、ホスト名の前に「auto-nginx」を付けます。

有効なドロップレットオプションの詳細については、DigitalOceanAPIドキュメントをご覧ください。

user-data.yml

userdataファイルuser-data.ymlは、新しいドロップレットが作成されるたびに、cloud-initによって実行されるファイルです。 これは、cloud-configファイルまたはスクリプトを提供して、新しい各ドロップレットにアプリケーションソフトウェアをインストールできることを意味します。

サンプルのuserdataファイルには、UbuntuサーバーにNginxをインストールし、デフォルトの構成ファイルをドロップレットのホスト名、ID、およびパブリックIPアドレスに置き換える単純なbashスクリプトが含まれています。

#!/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 > /usr/share/nginx/html/index.html

ドロップレット情報(ホスト名、ID、およびIPアドレス)は、DigitalOceanメタデータサービスを介して取得されます。これは、これらのcurlコマンドが実行していることです。

明らかに、アプリケーションのインストールや構成など、これよりも便利なことをしたいと思うでしょう。 これを使用して、SSHキーを自動的にインストールしたり、構成管理または監視ツールに接続したりすることで、インフラストラクチャ全体へのドロップレットの統合を自動化できます。

userdata、cloud-config、およびメタデータの詳細については、次のリンクを確認してください。

haproxy.cfg.erb

HAProxy構成テンプレートhaproxy.cfg.erbには、ほとんどのロードバランサー構成が含まれており、一部のRubyコードはバックエンドのドロップレット情報に置き換えられます。

バックエンド構成を生成するRubyセクションを見てみましょう。

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 %>

このコードは、インベントリ内の各ドロップレットを反復処理し、各ドロップレットに新しいHAProxyバックエンドを追加します(プライベートIPアドレスに基づく)。

たとえば、次のような行が各液滴に対して生成されます。

server www-4202645 10.132.224.168:80 check # id:4202645, hostname:auto-nginx-0

ドロップレットが作成または削除されるたびに、DOProxyは新しいHAProxy構成ファイル(前に見たhaproxy.cfgファイル)を生成します。

doproxy.rb

DOProxyRubyスクリプトdoproxy.rbは、主に、液滴の作成と削除、在庫管理、およびHAProxy構成の生成を実行するメソッドを含むDOProxyクラスで構成されています。

Rubyを理解している場合は、GitHubのファイルhttps://github.com/thisismitch/doproxy/blob/master/doproxy.rbを確認してください。

Rubyを理解していない場合は、各メソッドを説明する簡略化された擬似コードを次に示します。 何が起こっているのかを理解するのに役立つように、これを実際のRubyコードに対して参照すると役立つ場合があります。

def initialize

引数が指定されていない限り、DOProxyが実行されるたびに実行されます。

  1. doproxy.yml構成ファイルを読み取ります(APIトークンとドロップレットオプションを取得します)。 2化。

def get_inventory

インベントリファイル内の各液滴の情報を取得します。 次のいずれかのメソッドを実行する前に実行する必要があります。

  1. インベントリファイル(ドロップレットIDを含む)を読み取ります
  2. 液滴IDごとに、APIを使用して液滴情報を取得します

def print_inventory

「doproxy.rbprint」コマンドを使用すると、液滴情報が画面に印刷されます。 get_inventoryに依存しています。

  1. インベントリ内の各ドロップレットについて、ホスト名、プライベートIPアドレス、ステータス、およびID(get_inventoryによって取得された)を出力します)

def create_server

「doproxy.rbcreate」コマンドを使用すると、新しいドロップレットを作成してインベントリファイルに追加し、reload_haproxyを呼び出してHAProxy構成を生成し、ロードバランサーをリロードします。

  1. userdataファイルを読み取る
  2. APIを使用して、提供されたユーザーデータとオプションに基づいてドロップレットを作成します
  3. ドロップレットのステータスが「アクティブ」になるのを待ちます。ステータスが変わるまで、APIを使用して15秒ごとにドロップレット情報を取得します。
  4. ステータスが「アクティブ」の場合、ドロップレットIDをインベントリファイルに追加します
  5. reload_haproxyを呼び出して、HAProxy構成を生成し、ロードバランサーをリロードします

def delete_server(line_number)

「doproxy.rbdelete」コマンドを使用すると、指定したドロップレットを削除し、インベントリファイルからそのIDを削除してから、reload_haproxyを呼び出してHAProxy構成を生成し、ロードバランサーをリロードします。

  1. インベントリファイルから指定された行を削除します(ドロップレットIDを削除します)
  2. APIを使用して、IDでドロップレットを削除します
  3. reload_haproxyを呼び出して、HAProxy構成を生成し、ロードバランサーをリロードします

def generate_haproxy_cfg

これは、インベントリ内のドロップレットに基づいて新しいHAProxy構成ファイルを作成するサポート方法です。

  1. HAProxy構成テンプレートhaproxy.cfg.erbを開きます
  2. インベントリ内のドロップレットごとに、対応するバックエンドサーバーを追加します
  3. 結果のhaproxy.cfgファイルをディスクに書き込みます

def reload_haproxy

これは、HAProxy構成ファイルを適切な場所にコピーし、HAProxyを再ロードするサポート方法です。 これはgenerate_haproxy_cfgに依存しています。

  1. HAProxy設定ファイルhaproxy.cfgを、リロード時にHAProxyが読み取る場所にコピーします
  2. HAProxyをリロードする

これが、DOProxyを機能させる重要なコードのすべてです。 最後に説明するのは、DOProxyで使用したAPIラッパーであるDropletKitです。

DropletKitジェム

DOProxyは、公式のDigitalOcean APIv2RubyラッパーであるDropletKitgem を使用して、DigitalOceanAPI呼び出しを行います。 DropletKitを使用すると、次のようなことを行うRubyプログラムを簡単に作成できます。

  • 新しい液滴を作成する
  • 既存の液滴を削除する
  • ステータス、IPアドレス、液滴ID、地域など、既存の液滴に関する情報を取得します

このチュートリアルでは、これらの特定のAPIエンドポイントに焦点を当てましたが、DigitalOceanサーバーインフラストラクチャのプログラムによる管理を容易にするのに役立つエンドポイントは他にもたくさんあることに注意してください。

結論

DigitalOcean API、cloud-config、およびメタデータを活用することで、単純なスクリプトがサーバー環境の拡張にどのように役立つかを確認したので、これらの概念を適用して独自のサーバー設定を拡張できることを願っています。 DOProxyは本番環境に対応していませんが、独自のスケーリングソリューションを実装するためのアイデアを提供するはずです。

ここで説明するDOProxyを使用したスケーリング設定は優れていますが、監視システムと組み合わせて使用することで大幅に改善できる可能性があることを忘れないでください。 これにより、サーバーリソースの使用率などの特定の条件に応じて、アプリケーションサーバーの階層を自動的に拡大および縮小できます。

質問やコメントがありますか? 以下に投稿してください。