AWSの利用料金をzabbixに登録する

若干の今更感がありますが、とある出来事をきっかけに AWS CloudWatch APIを用いて、
zabbixに利用料金を登録するようにしたのでメモ。

とある出来事

AWS上に構築しているとあるシステムがあるのですが、運用がある程度落ち着いてきているため、
利用料金は月末にざっくり確認するくらいしかやってませんでした。

ある日、何気なく利用料金を確認してみると、なぜか普段よりも $200 くらい高い…。
これはと思いもろもろ確認してみると…

∑(ﾟДﾟ)ｶﾞｰﾝ

検証用に立てた RDS インスタンスが上げっぱなしだった…しかも2台。。

今まで結構お金を気にして運用していたため、$200 とはいえガックリ…。

そこで、そういえばこんな↓記事を以前見たことを思い出し、

　 【AWS発表】 AWSクラウドの利用料金を監視・通知できるように from Amazon Web Services ブログ

このあたり↓のブログを参考にさせて頂き、zabbix に利用料金を登録してみました。

　 AWS SDK for Rubyを使ってAWSの課金額を取得する from cohakim's blog

　 CloudWatch API + ZabbixでAWS課金情報をグラフ化 from Tech-Sketch

　 Zabbix Senderで複数の値を一括登録 from ike-daiの日記

課金状況を CloudWatch から取得できるようにする

まず初めに、課金情報を CloudWatch から取得可能にするには、一つ事務的なステップを踏む必要があります。

AWS Account Activity にアクセスします。

既に自分は設定してしまっているので画像が異なるのですが、
この↓赤枠のあたりをクリックして遷移していくと、15分程度経つとCloudWatchから
確認出来るようになります。

スクリプト作成

AWS SDK for Ruby を使いました。
Zabbix に登録する部分は自分で書く自信が無かったので、zabbix_senderコマンドを使っています。
その形式に合わせるために、文字列をガチャガチャしていますが…。

ちなみに start time を４時間前にしているのは、これは１時間とかだと取得に
失敗するパターンがあり、ある程度安定して取れたのが４時間だった、というのが理由です。

これを実行すると、下記のような形で AWS Billing の値をまるっと取ってきます。

hoge-server AmazonEC2 1369563780 497.7
 hoge-server AmazonRoute53 1369563780 0.54
 hoge-server AmazonRDS 1369563780 132.89
 hoge-server AWSDataTransfer 1369563780 4.43
 hoge-server AmazonSNS 1369563780 0.0
 hoge-server AmazonS3 1369563780 1.45
 hoge-server USD 1369563780 637.0

ただし、これだけでは、zabbix にデータは登録されません。 先に zabbix 側でアイテムを作っておく必要があります。

Zabbixアイテム（トラッパー）作成

これは、それぞれ下記のように普通に登録します。

cronに登録

これで、データを蓄積する準備は出来たので、とりあえずcronに登録して定期実行します。

# send aws-billing-data to zabbix
0 * * * * cd /etc/zabbix/externalscripts; /usr/local/bin/ruby /etc/zabbix/externalscripts/get_aws_billing.rb

↑変な書き方をしているのですが、普通に登録しただけではどうも動かなくて、
この書き方であれば動いたので、そのままにしています。

グラフで確認

データが取れたら可視化、ということで下記のようにサービス毎に積み上げグラフにしてみました。

これだけだと全体金額が若干分かりづらいので、そちらは折れ線で。

おーやはりグラフになるといいですね。
グラフ自体は直近二週間ならCloudwatchでも見れますが、もっと蓄積したい場合はこの方法は良さそうです。

ただ、このきっかけとなったインスタンスの上げっぱなしを防止するにはこれだけだと
ちょっとイマイチ…毎日確認する必要があります。

日々のだいたいの増加量を算出して、それ以上の増加量を検知したらアラート、
とかすれば良さそうですが、それはまた別で…

おしまい。

HerokuアプリをカスタムドメインでSSL運用する手順

仕事でHerokuアプリを動かす必要があったのですが、その際にカスタムドメインを付けるのと、
SSLで動かすのに結構手間取ったのでメモ。

前提

• SSL証明書を取得済みであること
• herokuアカウントにクレジットカードの登録が済んでいること

SSLアドオン追加

$ heroku addons:add ssl:endpoint --app YOUR_APP_NAME

もし下記のエラーが出た場合は、クレジットカード情報が未登録の可能性あり。

Adding ssl:endpoint on YOUR_APP_NAME... failed
 !    Please verify your account to install this add-on
 !    For more information, see http://devcenter.heroku.com/categories/billing
 !    Verify now at https://heroku.com/verify

SSL証明書登録

$ heroku certs:add 証明書.crt [中間証明書.crt] 秘密鍵.key --app YOUR_APP_NAME
Resolving trust chain... done
Adding SSL Endpoint to YOUR_APP_NAME... done
YOUR_APP_NAME now served by hoge.herokussl.com
Certificate details:
Common Name(s): *.hoge.com
以下続く

↑ の hoge.herokussl.com がSSL接続用のURLとなります。

登録済み証明書確認コマンド

$ heroku certs:info --app YOUR_APP_NAME

ドメイン登録

証明書登録時に確認した hoge.herokussl.com をCNAMEで登録する。
Route53 を用いる場合は下記のような感じ。

これで晴れてherokuアプリをカスタムドメインでSSL運用出来るようになりました。

ちなみに、単純にカスタムドメインを付けるだけなら、下記だけでOK。

$ heroku domains:add www.hoge.com

herokuのこともうちょっと学んでおかないとなぁ。
しかしSSLアドオンだけで $20 はちょっと…ま、色々便利だししょうがないか。

おしまい。

bundlerの環境変数でハマった話

capistranoでrailsアプリをbundle packageを使ってデプロイしようとしてハマった話。
ちょっとまとめるのが億劫だったので、つらつらと。

困った

あるプロジェクトで、capistranoのcopyストラテジーを使って
デプロイしているのですが、その際に、外部へgemを取りに行かないように、
bundle package を使っています。

で、その bundle package をする部分は自前で定義していて、
下記のように単純にやっていました。

system("cd #{destination} && bundle package --all")

しかしこれだと予期したように動かなかった。

想定としては、

/tmp/hogehoge/vendor/cache

の下に、gem達が入るはずなのに、なぜか

capコマンド実行ディレクトリ/vendor/cache

に入ってしまった。

原因

ググると、こんな記事が見つかりました。
どうやらbundlerが定義している環境変数が原因だったよう。
確認してみる。

$ bundle exec env | grep -i bundle
 :
 :
BUNDLE_BIN_PATH=/hoge/.rbenv/versions/2.0.0-p0/lib/ruby/gems/2.0.0/gems/bundler-1.3.1/bin/bundle
BUNDLE_GEMFILE=/hoge/hoge/Gemfile
RUBYOPT=-I/hoge/.rbenv/versions/2.0.0-p0/lib/ruby/gems/2.0.0/gems/bundler-1.3.1/lib -rbundler/setup

確かに環境変数がセットされていました。

具体的には、BUNDLE_BIN_PATH と RUBYOPT の bundler/setup がいけなかったようです。

対応

参照した記事と同様に、bundle package を実行する際に、
bundler関連の環境変数をリセットする処理を入れると。想定通りに動きました。

def bundle_package
  execute "bundle packaging" do
    with_clean_env do
      system("cd #{destination} && bundle package --all")
    end
  end
end

def with_clean_env
  bundled_env = ENV.to_hash
  %w(BUNDLE_GEMFILE RUBYOPT BUNDLE_BIN_PATH).each{ |var| ENV.delete(var) }
  yield
ensure
  ENV.replace(bundled_env.to_hash)
end

結局のところ

色々頑張ってみたけど、実は bundler には、

with_clean_env

なるメソッドが実装されていて、さらにその状態でコマンドを実行する

with_clean_system

まで用意されていました。
なので、自前で書かずとも、

def bundle_package
  execute "bundle packaging" do
    Bundler.clean_system("cd #{destination} && bundle package --all")
  end
end

とかやればOKでした。

それはそうと、とりあえずcopyストラテジーで bundle package が使いたいだけなんだけど？

という方は、自分のリポジトリではないですが、

https://github.com/rainux/capistrano-strategy-copy-with-bundle-package

とかを参照したら良い感じになるのではないでしょうか。

勉強になりました。

おしまい。

RVMからrbenvへの移行手順メモ

ruby 2.0 を試す必要があったので、これを機にようやっとRVMからrbenvに乗り換えたので、そのメモ。

RVM と rbenv の違い

rbenvのReadmeに記載されている。

1. shellに読み込む必要がない。
2. cd等のshellのコマンドを上書かない。
3. 設定ファイルがない。
4. rubyのインストールはしない。（ruby-buildを使えば自動化してくれる）
5. gemsetの管理はしない。（bundler使えばOK）
6. ライブラリの変更を要求しない。
7. プロジェクトを切り替えた時に警告を出さない。

スクリプト書いたりcapistrano使ったりする時とかRVMで悲しい思いをしたことが
あったので、シンプルなのは助かりそう。

手順

RVM削除

• rvm seppuku
  切腹て…

• .zshrc とかから rvm 関連の記述を手で削除

rbenv導入

• rbenv を github から clone

$ git clone git://github.com/sstephenson/rbenv.git ~/.rbenv

• .zshrc に rbenv 関連の記述を追記。

$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.zshrc
$ echo 'eval "$(rbenv init -)"' >> ~/.zshrc

• terminal を再起動

• ruby-build を github から .rbenv/plugin ディレクトリに clone

$ git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

rubyのインストール

• 対象のrubyをインストール

$ rbenv install 2.0.0-p0

• shimを更新
  ※このshimってのが、対象バージョンの実行ファイルを探して実行してくれるらしい。
  詳しくは ~/.rbenv/shims/ の下のファイルを見るか、rbenvのReadmeを参照願いますm(__)m

$ rbenv rehash

以上〜、おしまい。

AWS SES の送信テスト用スクリプト

久々にSESの設定をしたので、ちゃんと出来たかメール送信テストをしてみようと思った時に、以前作ったスクリプトが出て来ました。

…それだけですm(__)m

おしまい。

CDPの実装ガイド買いました。自己学習はもちろん、誰かにAWSの操作方法から説明する時にもいいかもです。

ELB配下のインスタンス全てにcapistranoでデプロイする

最近はもっぱらAWSでのサーバ運用ばかりしています。

で、AWS EC2を使ってる際にどうしようかなぁと思うことの一つに、IPが固定されない、
ということがあると思います。

EIPなりVPCなり使えばIPの固定自体は出来ますが、いちいち固定IP付けるの面倒だし…という時とか。

今回はアプリケーションをデプロイする時にそれを感じました。

capistranoを用いたデプロイ時にデプロイ先のサーバのアドレスを指定しますが、
ELBにぶら下がるインスタンスに固定IP付けてないんだよなぁ、というケースです。

そこで aws-sdk for ruby を使って、ELB配下のインスタンスを取得するように設定してみました。

今回はVPC内のインスタンスを対象にしてたので、通常のEC2インスタンスであれば、 instance.private_ip_address を instance.dns_name にすればいいと思います。

実行結果は以下です。

$ bundle exec cap test_web
    triggering start callbacks for `test_web'
  * 2013-02-27 08:46:42 08:46:42 == Currently executing `test_web'
  * executing "echo 'Hi!'"
    servers: ["10.0.102.11", "10.0.101.11"]
    [10.0.102.11] executing command
 ** [out :: 10.0.102.11] Hi!
    [10.0.101.11] executing command
 ** [out :: 10.0.101.11] Hi!
    command finished in 4000ms


$ bundle exec cap test_app
    triggering start callbacks for `test_app'
  * 2013-02-27 08:46:56 08:46:56 == Currently executing `test_app'
  * executing "echo 'Hi!'"
    servers: ["10.0.102.11", "10.0.101.11"]
    [10.0.101.11] executing command
 ** [out :: 10.0.101.11] Hi!
    [10.0.102.11] executing command
 ** [out :: 10.0.102.11] Hi!
    command finished in 945ms


$ bundle exec cap test_db
    triggering start callbacks for `test_db'
  * 2013-02-27 08:47:04 08:47:04 == Currently executing `test_db'
  * executing "echo 'Hi!'"
    servers: ["10.0.102.11"]
    [10.0.102.11] executing command
 ** [out :: 10.0.102.11] Hi!
    command finished in 1019ms

おぉ、出来た。ちゃんとdb roleの時は１つのインスタンス宛になってます。

もっと色々活用するためにruby勉強せねば…。

おしまい。

まだ途中までしか読んでないですが、この本結構分かりやすいです。オライリーならPDFもありますし。

bundle install で "Invalid .gemspec format" と出た時の対処メモ

あるrailsアプリをデプロイしようとして、

bundle install をしたら、

特定の gem が下記のような警告を出した。

WARNING: Invalid .gemspec format in '/usr/lib/ruby/gems/1.9.1/specifications/factory_girl_rails-1.6.0.gemspec'
WARNING: #＜argumenterror: ["#＜syck::defaultkey:0x00000008c8fb60="" illformed="" requirement=""＞ 3.0.7"]>

これはなんぞ？と思って gemspec ファイルとかを見てみたけど、ruby のことを
あまり理解してないのでよく分からず右往左往…。

識者に聞きつつ色々と試みたところ、結局gem のバージョンが古いのが原因だった。