GateOneで複数のSSH接続をブラウザで統合管理

WindowsだとputtyとかPoderosaとかTeraTermとかSSHクライアントソフトを利用してリモートのサーバにSSH接続することが多いです。
接続先のサーバがたくさんある場合には各ツールに接続先サーバのプロファイル情報を登録し、接続することになります。

これらのプロファイル情報はクライアントマシン内に保管されるので、別の端末から接続したいといった場合には別途接続設定を行う必要があるなど、管理に手間がかかります。

そこで、Web上でSSH接続情報を管理をし、複数サーバに対してSSH接続できるものがないかと探していたところ、GateOneというツールを見つけました。
GateOneはAGPLv3で公開されているOSSです。

http://liftoffsoftware.com/Products/GateOne
https://github.com/liftoff/GateOne/

GateOneを稼働させることで、複数のリモートサーバへのSSH接続を統合して管理できます。
接続先情報についてはGateOne内で管理することができるため、GateOneに繋げることさえできればリモートサーバへのSSH接続が実現できます。
Webブラウザで全て完結するのでクライアントソフトの導入なども必要ありません。

他のツールと比べてGateOneの面白いところは、鍵の管理ができたり、プラグインとして機能追加できたりするところです。
AWS上のEC2インスタンスSSH接続する際には標準で鍵認証の方式が採られていますが、GateOneでは鍵認証を使ってSSH接続も可能です。

導入方法

GateOneの公式サイトにてdebrpmのパッケージがそれぞれ公開されています。
このパッケージをインストールすれば簡単に導入できます。

以下、Ubuntu上にGateOneをインストールした例です。

必要なパッケージのダウンロード

gateoneとpython-tornadeの2つのパッケージが必要です。

$ wget https://github.com/downloads/liftoff/GateOne/gateone_1.1-1_all.deb 
$ wget https://github.com/downloads/liftoff/GateOne/python-tornado_2.4-1_all.deb 
パッケージインストール
$ sudo dpkg -i python-tornado_2.4-1_all.deb
$ sudo dpkg -i gateone_1.1-1_all.deb
設定確認

GateOneの設定は/opt/gateone/server.confで行います。
稼働するポートの設定等はここで行います。

gateoneサーバ起動
$ sudo /etc/init.d/gateone start

利用方法

gateoneサーバを起動するとデフォルトで443ポートで待受をするようになっています。
https://hostnameにアクセスします。
ここで接続先を入力して接続してみます。

ssh接続できました。

色付けもされます。
コピー&ペーストも有効です。
日本後も表示されます。
ただし、日本語入力はできません。

さらに別のサーバへのSSH接続も試してみます。
画面右端にある「+(New Terminal)」をクリックすると新規接続画面が開きます。
ここで別サーバへのSSH接続情報を入力すると接続可能です。

先に接続したサーバのターミナルに戻るには画面右端のメニューから「Grid View」をクリックしてターミナル一覧を表示し、操作したいターミナルを選択します。


Bookmark機能

毎回接続先情報を入力するのは面倒です。
よく接続するホストの情報はBookmarkとして保存しておくことができます。
Bookmarkには接続先ホスト名、SSHポート番号、名前、タグが設定できます。
接続先サーバの種類毎にタグで分類もできます。
台数が多くなると有効に活用できそうです。



ここで登録したBookmarkの情報は、Gate Oneが稼働しているサーバの
/opt/gateone/users/ANONYMOUS/bookmarks.jsonに記録されています。

過去の行動履歴

GateOneのターミナル上で行った作業は履歴が残っています。
ターミナルの下部のバーで過去何を行ったかをさかのぼって確認することができます。
また、LogViewerというツールもあり、過去のターミナルセッション毎の履歴情報を確認することができます。
この履歴情報は印刷用の形式で表示できたり、htmlファイルとして保存できたりと作業証跡の保存用途としても活用できそうです。

鍵の管理

鍵認証のSSH接続にも対応しています。
SSH PluginとしてSSH Identity Managerが標準で搭載されています。
ここでは、鍵の新規作成や鍵のアップロードができるようになっています。
登録した秘密鍵をもとに認証を行いSSH接続するといったこともできます。
AWSのEC2インスタンスのような鍵認証のサーバにもログインすることができます。
この鍵情報についてはGateOneサーバの/opt/gateone/users/ANONYMOUS/ssh以下に格納されるようになっています。
秘密鍵の管理には十分注意した上で利用しなければいけません。

ショートカットキー

GateOneはショートカットキーにも対応しています。

  • Shift+矢印: ターミナル切り替え
  • Ctl+Alt+N: 新規ターミナル作成
  • Ctl+Alt+W: ターミナル削除
  • Ctl+Alt+G: Grid View表示
プラグイン

その他プラグインとして、サーバのtopコマンド実行状況を常に画面に表示するようなプラグインがあったりします。

このようにただ単にSSH接続ターミナルを集約できるだけでなく、運用作業をするにあたって便利な機能があるので面白いツールじゃないでしょうか。
プラグインについては、簡単に作れるようになっているみたいなので機会があれば試してみようと思います。

ユーザ管理

ここまでANONYMOSユーザで作業を行いましたが、GateOneにはユーザ管理をする機能もあるようです。
server.confにはauth="none"となっている設定項目があり、pam、googleapiといった値が設定できるようです。
ただ、ここの使い方はいまいちよくわからなかったので今後調べてみようと思います。

まとめ

この手のWebブラウザSSH接続できるようにするツールはAjaxtermやShell in a Boxなどなどたくさんありますが、
GateOneはとても機能が豊富なツールだと思います。
Plugin開発もしやすそうなので、今後に期待です。
使ってみて感じたこととしては、簡単な運用作業とかであれば使えそうです。
ただ、ターミナルの切り替えがもたつくのでたくさんのターミナルを開いて作業するには少し不快感を感じるかもしれません。

音声読み上げができるSpeak.jsを使ってみた

JavaScriptだけで音声の読み上げができるということで試してみました。
ソースコードはこちら
https://github.com/mattytemple/speak-js

Speak.js使い方

使い方は非常に簡単です。
speakClient.jsとspeakWorker.js、speakGenerator.jsを配置し、
HTMLの中でspeakClient.jsを読み込むだけで事前準備はOK。

speak()というJavaScriptの関数があるので、これを使って読み上げを実現します。

speak()の引数としては、読み上げる対象のテキスト情報を第1引数に、
オプションを第2引数に指定します。

オプションとしては以下のような値が設定可能です。

  • speed 読み上げ速度
  • pitch 読み上げ音声の音程
  • amplitude 読み上げ音声の音量
  • wordgap 単語と単語間の読み上げの間指定

書き方はこのような形です。

speak("Nice to meet you. I am ike-dai.", {speed:150,wordgap: 10});

この時、HTML内に「<div id="audio">」のdivタグを記載する必要があります。
Speak.jsが文字列を音声ファイルに変換した後、このdivタブ内にHTML5の<audio>タグを埋め込み音声再生を実行します。

感想

発音はぎこちない感じです。
単語単位ではある程度形になりますが、長文になるとかなりぎこちないです。
しかし、速度や発音間隔など柔軟に変更できるところは良さげです。

サンプルアプリをGoogleドライブ上にデプロイ

Googleドライブに先日追加されたWebホスティング機能を使ってspeak.jsを利用したWebページを公開してみました。
Googleドライブ上に1つディレクトリを作成し、その中にspeak.jsを利用するhtmlファイル(index.html)とspeakClient.js,speakWorker.js,speakGenerator.jsをアップロードします。
このディレクトリを一般公開設定し、誰でも見れるようにします。

一般公開することで、htmlのファイルの編集ページで「プレビュー」ボタンを押すことができるようになります。

このプレビューを押すと、ホスティングされているWebページを見ることができます。
公開URLはプレビューボタンを押した先のページのURLです。
AmazonS3のようなアクセス制限とかの機能はないですが、簡単に無料で公開できます。

テキストエリアに入力した内容を読み上げてくれます。

https://googledrive.com/host/0B2KNKkBsnhZFX0xRaFR6S2w5RG8/index.html

興味があればお試し下さい。

SLAをメールでレポート(ZabbixのITサービスの活用)

システム運用していて、SLA管理のためにサービスレベルを定期的にレポートしたい場合もあるかと思います。
ZabbixにはITサービス機能があり、サービスの稼働率を算出することができます。

例えば次のような形で設定できます。

  • サービスAとサービスBの監視をZabbixで監視
  • サービスAはWebサーバ3台、DBサーバ2台で構成
  • サービスBはWebサーバ2台、DBサーバ2台、認証サーバ2台で構成
  • サービスAが稼働継続するには少なくともWebサーバ、DBサーバが1台以上稼働している必要がある
  • サービスBが稼働継続するには少なくともWebサーバ、DBサーバ、認証サーバが1台以上稼働している必要がある

このような環境があった場合にそれぞれのサーバの稼働率からサービス自体の稼働率を算出することができます。

ZabbixのITサービスの機能を使うことで次のようにできます。
設定は「設定」→「ITサービス」から実行します。

ルートの子としてサービスA、サービスBを登録します。
この時、ステータス計算アルゴリズムとして「子に一つでも障害があった場合に検知」を選択。

サービスAの子としてWeb、DBを、サービスBの子としてWeb、DB、認証を登録します。
この時、ステータス計算アルゴリズムとして「すべての子に障害があった場合に検知」を選択。

最後にWeb、DB、認証の各子として実際のサーバの台数分登録します。
この時、サービスレベルを算出する元となる死活監視のトリガー条件を各子に設定します。

設定ができると、「監視データ」→「ITサービス」の欄で稼働状況が確認できます。

SLAの算出期間は

  • 今日
  • 今週
  • 今月
  • 今年
  • 最新24時間
  • 最新7日
  • 最新30日
  • 最新365日

から選択できます。


このようにブラウザの画面を見ることでSLAを確認することができますが、
エクスポートの機能などは今のところ搭載されてはいません。

Zabbix APIを使ってITサービス情報を取得

毎回画面を見ないでもITサービス情報をレポート通知をする仕組みを考えてみます。

ITサービスの情報は、Zabbix APIを使うことで取得することができます。
そこで、Zabbix APIを利用してSLAの情報を取得してみます。

ITサービスの情報取得には次の2つのメソッドを利用します。

service.get
service.getSla

ITサービス基本情報の取得

ITサービスの基本情報はservice.getメソッドを利用して取得します。
パラメータとしては次のようなものが設定できます。

  • parentids
  • childids
  • countOutput
  • selectParent
  • selectDependencies
  • selectParentDependencies
  • selectTimes
  • selectAlarms
  • selectTrigger
  • sortfield
  • sortorder
  • output

例えば、serviceの詳細情報を親のIDも含めて取得したい場合はパラメータを次のようにします。
"params":{"selectParent":"refer","output":"extend"}

次のような値が取得できます。

{"jsonrpc":"2.0","result":[
    {
         "serviceid":"1",
          "name":"Service A",
          "status":"0",
          "algorithm":"1",
          "triggerid":"0",
          "showsla":"1",
          "goodsla":"99.9000",
          "sortorder":"0",
          "parent":[]
    },
    {
          "serviceid":"2",
          "name":"Web",
          "status":"0",
          "algorithm":"2",
          "triggerid":"0",
          "showsla":"1",
          "goodsla":"99.9000",
          "sortorder":"0",
          "parent":{
                               "serviceid":"1"
                           }
    },
・・・略
SLA情報の取得

次に、SLAの情報を取得します。
SLAの取得にはservice.getSlaメソッドを利用します。
パラメータは次のような形で設定。
"params":{"serviceids":[1,2],"intervals":{"from":"1356966000","to":"1359558000"}}

これは、サービスID1,2のSLAを2013/01/01 00:00〜2013/01/31 00:00の期間で算出する例です。

取得できる値は次のような形式です。

{"jsonrpc":"2.0","result":{
      "1":{
               "status":"0",
               "problems":,
               "sla":[{
                           "from":"1356966000",
                           "to":"1359558000",
                           "sla":98.406404320988,
                           "okTime":2550694,
                           "problemTime":41306,
                           "downtimeTime":0
                          }]
              },
      "2":{
               "status":"0",
               "problems":,
               "sla":[{
                           "from":"1356966000",
                           "to":"1359558000",
                           "sla":98.406404320988,
                           "okTime":2550694,
                           "problemTime":41306,
                           "downtimeTime":0
                         }]
               }
},"id":1}

SLA出力スクリプト

このservice.*のAPIを利用してSLAを外部に出力するためのスクリプトを作成します。

it_service_report.rb

#!/bin/env ruby

require 'rubygems'
require 'zbxapi'

ZABBIX_API_URL = 'http://Zabbixサーバホスト名/zabbix/api_jsonrpc.php'
ZABBIX_LOGINID = 'Zabbixサーバへのログインユーザ名'
ZABBIX_PASSWORD = 'Zabbixサーバへのログインパスワード'
TO = Time.now
case ARGV[0]
when "1day" then
    FROM = TO - 86400
when "1week" then
    FROM = TO - 604800
when "1month" then
    FROM = TO - 2592000
when "1year" then
    FROM = TO - 31536000
else
    puts "Argument Error!:Please input output term(ex. 1day,1week,1month,1year)"
    exit(0)
end

zbxapi = ZabbixAPI.new(ZABBIX_API_URL)
zbxapi.login(ZABBIX_LOGINID,ZABBIX_PASSWORD)

## Get IT Service list
$services = zbxapi.raw_api("service.get", {:selectParent => "refer",:output => "extend"})

serviceids = []
$services.each do |service|
    serviceids << service['serviceid']
end

## Get SLA info
slas = zbxapi.raw_api("service.getSla", {:output => "name",:serviceids => serviceids, :intervals => {:from => FROM, :to => TO}})

$services.each do |service|
    slas.each do |sla|
        if sla.first == service['serviceid']
            service['sla'] = sla[1]['sla'][0]['sla']
        end
    end
end

## Pickup Parent Service
parents = $services.find_all do |service|
    service['parent'].empty?
end

## Search Child
def check_child(parents,level)
    parents.each do |parent|
        $output_data << {:level => level, :service => parent}
        childs = $services.find_all do |service|
            !service['parent'].empty? && service['parent']['serviceid'] == parent['serviceid']
        end
        if childs
            check_child(childs,level+1)
        end
    end
end

$output_data = []
level = 0

check_child(parents,level)

## Print Out
puts "[Calculation Term]From:#{Time.at(FROM.to_i)} - To:#{Time.at(TO.to_i)}"
$output_data.each do |line|
    puts "     "*line[:level] + "[ #{line[:service]['name']} ] SLA => #{line[:service]['sla']}"
end

実行すると次のようにSLA情報が出力されます。

$ ruby it_service_report.rb 1month
[Calculation Term]From:Sat Jan 05 11:14:02 +0000 2013 - To:Mon Feb 04 11:14:02 +0000 2013
[ Service A ] SLA => 100
     [ Web ] SLA => 100
          [ Web Server 1 ] SLA => 100
          [ Web Server 2 ] SLA => 100
          [ Web Server 3 ] SLA => 100
     [ DB ] SLA => 100
          [ DB Server 1 ] SLA => 100
          [ DB Server 2 ] SLA => 100
[ Service B ] SLA => 100
     [ Web Server ] SLA => 100

あとは、この出力結果をメールで飛ばせるよう仕組みを作ればOKです。

ITサービスのAPIを利用することのメリットとしては、SLAを算出する期間を自由に設定できる点です。
Zabbixの管理画面からでは固定された期間でのSLAしか取得できませんが、APIを利用することでFromとToの時刻が指定できるので、使い所があるかもしれません。

Zabbix APIを使ってWeb監視設定を登録してみる

Zabbix公式APIマニュアルには、Zabbix APIの使い方として、Web監視設定情報を取得したり、追加登録する方法が載っていません。
しかし、ソースコードを見ると、CWebCheck.phpというのが存在していて、どうやらAPIで叩けるようです。
ということで、Zabbix APIを使ってWeb監視設定の取得と追加登録を実施してみます。

公式に提供されている機能ではないので、以下解説する内容は参考程度に留めて下さい。
以下、Zabbix2.0.3で動作確認済みです。
別のバージョンでは動かないかもしれません。

webcheck.getによるWeb監視設定情報取得

Web監視関連のAPIはwebcheck.xxxという形のメソッドで実行できます。
監視設定を取得する場合にはwebcheck.getです。

取得する際のパラメータ情報は次の通りです。

パラメータには次の値を設定します。

{"output":"extend"}

これにより、Web監視のシナリオの情報が詳細に取得できます。

実際にcurlコマンドを使って実行した結果はこちら。

curl -X POST -H "Content-Type:application/json-rpc" -d '{"auth":"認証トークン","method":"webcheck.get","id":1,"params":{"output":"extend"},"jsonrpc":"2.0"}' http://Zabbixサーバホスト名/zabbix/api_jsonrpc.php

取得できるJSONデータ

{"jsonrpc":"2.0",
"result":
    [{"httptestid":"1",
     "name":"webtest",
     "applicationid":"454",
     "nextcheck":"1358985877",
     "delay":"60",
     "status":"0",
     "macros":"",
     "agent":"Mozilla\/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident\/6.0)",
     "authentication":"0",
     "http_user":"",
     "http_password":""}],
"id":1}

シナリオの基本設定だけでなく、各ステップの情報も取得したい場合はパラメータを次のように設定します。

{"output":"extend","selectSteps":"extend"}

curlでの実行例

curl -X POST -H "Content-Type:application/json-rpc" -d '{"auth":"認証トークン","method":"webcheck.get","id":1,"params":{"output":"extend","selectSteps":"extend"},"jsonrpc":"2.0"}' http://Zabbixサーバホスト名/zabbix/api_jsonrpc.php

取得できるJSONデータ

{"jsonrpc":"2.0","result":
[{"steps":
	{"1":{"httptestid":"1",
		"name":"index",
		"no":"1",
		"url":"http:\/\/xx.xx.xx.xx\/redmine",
		"timeout":"15",
		"posts":"",
		"required":"hoge",
		"status_codes":"200",
		"webstepid":"1"
	}},
	"httptestid":"1",
	"name":"webtest",
	"applicationid":"454",
	"nextcheck":"1358988040",
	"delay":"60",
	"status":"0",
	"macros":"",
	"agent":"Mozilla\/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident\/6.0)",
	"authentication":"0",
	"http_user":"",
	"http_password":""
}],
"id":1}

ホストの情報も一緒に取得したい場合は"selectHosts":"refer"を更にパラメータに追加して下さい。
すると、シナリオが登録されているホストの情報が"hosts":[{"hostid":"10084"}]といった形で追加されます。

webcheck.createによるWeb監視設定情報登録

では、次にWeb監視設定を登録してみます。
登録にはwebcheck.createを利用します。
webcheck.createを利用することでシナリオ情報、ステップ情報全て登録できます。

パラメータには、シナリオの基本情報と、1つ以上のステップ情報を設定します。
※下記に記載した内容以外にも認証情報やPOST内容など必要に応じて追加して下さい

{"name":"test_case1",  ←シナリオ名
 "delay":60,  ←監視間隔
 "status":0,  ←監視の有効(0)/無効(1)設定
 "authentication":"0",  ←認証設定の有り(1)/無し(0)設定
 "applicationid":454,  ←アプリケーションIDの設定
 "hostid":10084,  ←アイテム登録する対象ホスト指定(ZabbixServerからWeb監視するのであればZabbix ServerのホストIDを指定)
 "steps":[{   ←ステップ情報設定(配列形式で複数のステップを一括登録可能)
     "name":"login",  ←ステップ名
     "no":1,  ←ステップ番号(1以上の数字を指定する必要あり)
     "url":"http://localhost/zabbix",  ←監視URL
     "timeout":10,  ←タイムアウト設定
     "required":"zabbix",  ←要求文字列指定
     "status_codes":200}]  ←ステータスコード
}

この時、注意点としては、applicationidとhostidが正しい組み合わせになっていない場合、シナリオが正しく指定したホストに対して登録されません。実在する組み合わせで設定して下さい。

また、登録時にはシナリオ名で重複チェックがされるため、同一名のシナリオは登録できません。
さらに、同一シナリオ内でステップの名前の重複も許可されていません。

webcheck.updateによるWeb監視設定の変更

既に存在するシナリオにステップを追加したい場合や、既存の設定を変更する場合にはwebcheck.updateを利用します。
パラメータの指定方法はwebcheck.createとほぼ同じです。
一点注意が必要なのは、変更するシナリオのID(httptestid)をパラメータに追加する必要があります。

{"httptestid":2    ←変更したいシナリオのID。create時に自動で割り振られる
 "name":"test_case1",
 "delay":60,
 "status":0,
 "authentication":"0",
 "applicationid":454,
 "hostid":10084,
 "steps":[{
     "name":"login",
     "no":1,
     "url":"http://localhost/zabbix",
     "timeout":10,
     "required":"zabbix",
     "status_codes":200}],
      "steps":[{   ←追加するステップ情報設定
     "name":"dashboard",
     "no":2,  ←ステップが連番になるように設定
     "url":"http://localhost/zabbix/dashboard",
     "timeout":10,
     "required":"zabbix",
     "status_codes":200}]
}

AWS障害状況をZabbixで監視

AWSで発生している障害状況をモニタリングするには、AWS Health Dashboardというサイトがあります。
ここでは、各リージョンの各サービス毎に障害が発生していないかの情報を発信しています。
サービスが利用不可になっている状態のお知らせだけでなく、パフォーマンス劣化が発生している状況なども発信しています。
AWS上でサービス運用している方にとって、ここで公開される情報は結構重要です。
いち早く何が起こっているのかに気付くためにもこのサイトの情報は常にチェックしておきたいところです。

しかし、このサイトの最新情報を知るには、ブラウザでこのサイトを確認するか、RSSで配信される情報をチェックするしかありません。
何かあればプッシュ型で通知して欲しいところではないでしょうか。

そこで、このサイトの情報をZabbixで集約し、障害が発生した場合にアラートを上げれるようにしてみます。

実現方式

Zabbixの外部チェック機能を利用します。
外部チェックスクリプトを作成し、スクリプト内でAWS Health DashboardRSSフィードを取得してきます。
取得した結果をzabbix_senderを用いてZabbixに連携します。
Zabbixに登録された新たな情報があればアラート通知を行うことで実現します。

外部チェックスクリプト

RSSフィードを取得する外部チェックスクリプトはこの通り。
※かなり簡易なスクリプトなので、参考程度に使ってください。

aws_health_check.rb

#!/bin/env ruby

require 'rubygems'
require 'feed_tools'

HOST = ARGV[0]
ITEM_KEY = ARGV[1]
INTERVAL = ARGV[2].to_i 
RSS_URL = 'http://status.aws.amazon.com/rss/ec2-ap-northeast-1.rss'
ZABBIX_SENDER = 'zabbix_senderパス'
ZABBIX_SERVER = 'Zabbixサーバホスト名'
ZABBIX_LOGINID = 'Zabbixサーバへのログインユーザ名'
ZABBIX_PASSWORD = 'Zabbixサーバへのログインパスワード'

def send_to_zabbix(zabbix_sender,zabbix_server,host,item_key,value,unixtime)
    cmd = "echo -n -e #{host} #{item_key} #{unixtime} \"#{value}\" | #{zabbix_sender} -z #{zabbix_server} -T -i - >/dev/null"
    if system(cmd)
        return 0
    else
        return 1
    end
end

FeedTools::Feed.open(RSS_URL).items.reverse.each do |item|
    now = Time.now
    last_check = now -INTERVAL   
    if item.published > last_check
        result = send_to_zabbix(ZABBIX_SENDER,ZABBIX_SERVER,HOST,ITEM_KEY,item.title,item.published.to_i)
        if result == 1
            print 'error'
            exit 0
        end
    end
end

print 'ok'

RSS_URLで東京リージョンのEC2サービスのRSSフィードURLを指定しています。それ以外のサービスのものを見たければ変更してください。

設定

今回はrubyスクリプトを書いたので、Zabbix Serverにrubyのインストールが必要です。
加えて、RSSフィード結果をパースするために、feed_toolsというgemパッケージを用いているため、インストールします。

$ sudo gem install feedtools

Zabbixの外部チェックスクリプトの配置場所(externalscriptディレクトリ)に上記のaws_health_check.rbを置きます。

Zabbixに次のホストテンプレートをインポートします。

zbx_exports_templates.xml

インポートしたテンプレートを割り当てたホストを1つ作成します。
これで、Informational messageが発生したときは「情報」として検知、Performance issuesが発生したときは「警告」として検知、Service disruption が発生したときは「重度の障害」として検知するようトリガーが設定できます。

その他

Nagiosではcheck_aws_status.rbというチェック用プラグインを作成されている方があるようです。
https://gist.github.com/1604786

AWSで新たにリリースされたPython製コマンドラインツールを使ってみる

これまでJava版のコマンドラインツールがありましたが、先日新たにPython版のAWSコマンドラインツールがリリースされたようです。
Introducing the AWS Command Line Interface (Developer Preview)

まだDeveloper Previewらしいですが。
試しに使ってみます。
Ubuntu12.04の環境で試しています。

導入方法

1. Pythonのインストール(Python2.6以上のバージョンが必要らしい)

$ sudo apt-get install python

2. パッケージ管理ツール(easy_install)の導入
Pythonのパッケージ管理ツールでコマンドラインツールのインストールが可能であるため、まずはパッケージ管理ツールを導入します。

$ wget http://peak.telecommunity.com/dist/ez_setup.py
$ sudo python ez_setup.py
pipを利用する場合は更に以下を実施
$ sudo easy_install pip

3. コマンドラインツールインストール
パッケージ管理ツールを利用してawscliをインストール。

$ sudo easy_install awscli
pipを利用する場合は以下でインストール
$ sudo pip install awscli

4. プロフィール設定ファイル作成
コマンドラインインタフェースを利用する際には、予め準備した設定ファイルから接続先のリージョン情報やAPIアクセスキー情報等を読み込んで実行します。
そこで、以下の設定ファイルを準備します。名前は適当に設定して下さい。

$ vi ~/myconfigfile.txt
[default]
aws_access_key_id = アクセスキー
aws_secret_access_key = シークレットキー
region = us-east-1

[account1-us]
aws_access_key_id = アクセスキー
aws_secret_access_key = シークレットキー
region = us-east-1

[account2-ap]
aws_access_key_id = アクセスキー
aws_secret_access_key = シークレットキー
region = ap-northeast-1

複数のアカウント情報を書いておくことが可能です。

5. 設定ファイルの場所指定
環境変数(AWS_CONFIG_FILE)で設定ファイルがある場所を指定します。

$ export AWS_CONFIG_FILE=~/myconfigfile.txt

実行方法

設定ファイルの[default]情報をもとにEC2インスタンスのリストを取得する方法は次の通り。

$ aws ec2 describe-instances

awsコマンドの引数は、1つ目の引数にターゲットとするAWSサービス名を、2つ目の引数に実行するAPIメソッドを指定します。
さらにオプションとして、次の項目が設定可能です。

オプション 説明
--region ap-northeast-1/us-east-1など リージョン指定。設定ファイルに書いたregion設定よりもオプション指定したregionの方が優先される
--output json/text 出力形式を指定可能。デフォルトはjson形式
--profile default/account1-usなど 設定ファイルに記載したプロフィールの内どの情報をもとに接続するかを指定。デフォルトはdefault
--debug なし デバッグ出力

cloudwatchの監視結果を取得

このpythonコマンドラインを使ってcloudwatchの監視データを取得するには次のように実行します。

$ aws cloudwatch list-metrics --endpoint-url http://monitoring.us-east-1.amazonaws.com  ←取得できるMetricsを確認
$ aws cloudwatch get-metric-statistics --metric-name CPUUtilization --statistics Average --dimensions '{"name": "InstanceId","value": "i-5xxxxx"}' --namespace AWS/EC2 --period 3000 --start-time "2012-12-21T12:00:00TZD" --end-time "2012-12-26T12:00:00TZD" --endpoint-url http://monitoring.us-east-1.amazonaws.com    ←CPU使用率を取得
  
    
      
        2012-12-24T19:20:00Z
        Percent
        2.4784
      
      
        2012-12-21T03:50:00Z
        Percent
        2.4364
      
      
        2012-12-25T16:10:00Z
        Percent
        2.4594
      
      
        2012-12-21T13:50:00Z
        Percent
        2.4578
      
      
        2012-12-21T03:00:00Z
        Percent
        2.9257999999999997
      
      
        2012-12-23T23:20:00Z
        Percent
        2.4592
      
      
        2012-12-24T06:00:00Z
        Percent
        2.5024
      
     ・・・省略

注意点

endpoint-urlを正しく指定しないと何故かcloudwatchのみエラーが発生しました。
http://cloudwatch.us-east-1.amazonaws.comに対してアクセスしに行って、500エラーで失敗しているようです。
cloudwatchのAPIのURLはhttp://monitoring.us-east-1.amazonaws.comなのでこのURLをendpoint-urlオプションで指定することで取得できました。
根本的な原因は追えてません・・・

vSphere 5.1のAPIにhttpでもアクセスできるようにする方法

vSphere APIは、「https://hostname/sdk」というhttpsでのアクセスが許可されています。
しかし、開発段階などhttpsである必要がない場合などもあります。
そこで、httpでもAPIアクセスができるよう設定してみます。
vSphere5.1よりも過去のバージョンでのやり方は公式のDeveloper's Setup Guideにも方法が書かれていますが、
ESXiサーバの/etc/vmware/hostd/proxy.xmlの中身を書き換えて、
service mgmt-vmware restart
と再起動すればよかったらしいです。
しかし、同様の手順でESXi 5.1でもできるのかと思ったら、ファイルが存在しませんでした。
5.1からファイルの構成が変更になっているようで、次のようにすることで対応が可能となりました。

参考URL:Proxy.xml which we use to modify to enable HTTP... |VMware Communities

次の2つのファイルがWebアクセスに関する設定になっています。

config.xmlの中身はこのような感じです。

5.0.0.0

/var/log/vmware/

/etc/vmware/

/var/log/vmware/

rhttpproxy

false

false

524288

8

verbose

true

Rhttpproxy

local4

/var/run/vmware/rhttpproxyLogHeader.txt

/etc/vmware/rhttpproxy/endpoints.conf

80

443

/etc/vmware/ssl/rui.key

/etc/vmware/ssl/rui.crt
/lib/

2 44 2 18

8 600 256 rhttpproxy
false false true /lib/ 120000

false

false

62914560

524288

1000

128

vSphere Web Serviceの稼働ポートを変更したい場合には、80443を変更すればいいようです。

endpoints.confの中身はこのような感じです。

/                        local            8309                   		   redirect       allow
/sdk                     local            8307                             redirect       allow
/client/clients.xml      local            8309                             allow          allow
/ui                      local            8308                             redirect       allow
/vpxa                    local            8089                             reject         allow
/mob                     namedpipe        /var/run/vmware/proxy-mob        redirect       allow
/wsman                   local            8889                             redirect       allow
/sdkTunnel               namedpipetunnel  /var/run/vmware/proxy-sdk-tunnel allow          reject
/ha-nfc                  local            12001                            allow          allow
/nfc                     local            12000                            allow          allow

各行の左端列がURLを示しており、左から4番目の列が処理をどうするかについて記載されているようです。
/sdkの行を見ていくと、4番目の列がredirectになっており、httpアクセス時にhttpsにリダイレクトされる設定になっています。
ここをallowにすることでhttpでのアクセスもhttpsにリダイレクトされることなく実施可能になりました。

設定を変更後、rhttpproxyを再起動します。

# /etc/init.d/rhttpproxy restart

テスト環境や開発環境など、httpsにする必要がない場面などはhttpでアクセスできるようにしておくといいかもしれません。