Python botoにAWSのアクセスキーIDとシークレットキーを予め設定しておく小ネタ メモ

最近知ったbotoの小ネタ。
botoを使っていると、毎回AWSのアクセスキーIDとシークレットキーをベタに書いていたのですが、/etc/boto.cfgに書いておけば以下の書き方が出来るというお話

import boto.ec2
region = 'ap-northeast-1'
conn = boto.ec2.connect_to_region(region)

設定ファイルはこんな感じに成ります。

/etc/boto.cfg
[Credentials]
aws_access_key_id=アクセスキーID
aws_secret_access_key=シークレットキー
# 複数切り替える場合は、予め書いておいてコメントアウトしておくと便利
# aws_access_key_id=アクセスキーID2
# aws_access_key_id=シークレットキー2

バッチサーバー等で複数のスクリプト実行してる場合便利ですね。

Python Fabricでデプロイしてみた

最近デプロイツールを探していたのだけど、やはりPythonで書きたいなと思い、勉強がてらFabricを使ってデプロイスクリプトを書いてみました。
設定とコードをなるべく切り分けたかったので、このあいだ知ったConfigParser使って設定を外部化させてみました。
Fabricのrolesを使いたかったので、Keyに対して、カンマ区切りで複数のValueを持たせられるようにしてみました。とりあえず動く程度なのでも
う少し綺麗にまとめるかも、っというかもっとスマートな方法があるはず・・・。

Pythonで設定ファイルを読み込みたい場合の方法 ConfigParser

Pythonでコードを書いていると設定する項目が増えてきていろいろと大変・・・。
別のファイルにまとめられないかなと思ったら、ConfigParserなる便利なモジュールがあったので使ってみました。
テストで使用した設定ファイルの内容は以下のものとなります。
FileName:config_file

[options]
spam: egg
hoge: huga
[example]
host=192.168.1.10
port=22
user=iiwake

[]で括られているのが各セクションとなり、それ以下がオプションとなります。
オプションは、左がKeyで右がValueとなっており、「:(コロン)」「=(イコール)」が使用出来るようです。
では実際に読み込んでみます。
read()にて、用意した設定ファイルを指定し読み込みます。

>>> import ConfigParser
>>> conf = ConfigParser.SafeConfigParser()
>>> conf.read('config_file')

get(‘セクション名’, ‘オプション名’)で値を取り出せます。

>>> conf.get('options', 'spam')
'egg'

sections()で各セクション名が返されます。また、options(‘セクション名’)でセクション内の各オプションを返します。

>>> for section in conf.sections():
...     for option in conf.options(section):
...         print '[section: %s] option: %s' % (section, conf.get(section, option))
...
[section: options] option: egg
[section: options] option: huga
[section: example] option: 192.168.1.10
[section: example] option: 22
[section: example] option: iiwake

items(‘セクション名’)はオプション名を指定せず(key, value)のペアで取り出せます。

>>> for section in conf.sections():
...     print 'section: %s, option: %s' % (section, conf.items(section))
...
section: options, option: [('spam', 'egg'), ('hoge', 'huga')]
section: example, option: [('host', '192.168.1.10'), ('port', '22'), ('user', 'iiwake')]

has_option()を使えば、オプションの有無がわかります。

>>> for section in conf.sections():
...     if conf.has_option(section, 'spam'):
...         print conf.get(section, 'spam')
...
egg

意外と簡単に設定の外部化ができました。
ただ、値を複数持つオプション等が出来ないようなので(そこまで調べてませんが)そう言った事をする場合、自前で解析しなくてはならないかも。
 

PythonでFacebookのキャッシュなどをクリアしてみる

Facebookのキャッシュ(OGPなど)ですが、せっかくエントリーを公開しても、なかなか消えない上にいいねの数が反映されない現象がたまにあります。
そこで、安直ですがRSSフィードを参照し、直近に公開されたエントリーのFacebookキャッシュをクリアをするスクリプトを作成してみました。
一応FacebookDebuggerでの結果が欲しかったので、BeautifulSoupでページ内の結果(StatusCode)をひっこぬいてデバッグログに書いてます。

これをcronなどで1日1回くらい回せば、直近に公開したエントリーのキャッシュはクリアされるかと思います。

サーバ上でコマンドラインからWebサイトのスクリーンショットを撮ってみた wkhtmltoimage

Linuxサーバ上で、コマンドラインからWebサイト(Webページ)のスクリーンショットというか、キャプチャーみたいなものが取れないものかと思い探してみたら、
wkhtmltoimageなるコマンドがあったので試してみました。
試したのはAWS EC2のUbuntu Server 12.10(64bit)上
このツールは元々wkhtmltopdfというツールから派生して作成されたようで、APTでインストールする事が可能でした。

$ aptitude install wkhtmltopdf

 
さて、本題のwkhtmltoimageですが、まず下記サイトからDLするのですが、最新Verだとうまく実行できなかったので、古いVerを利用しました。
https://code.google.com/p/wkhtmltopdf/
古いVerのデータが上記サイトから何故か辿れなかったので、とりあえず直接DLします。

$ wget http://wkhtmltopdf.googlecode.com/files/wkhtmltoimage-0.10.0_rc2-static-amd64.tar.bz2

検証したサーバはUbuntu 64bit版なのでこのファイルをDLしましたが、32bit版であれば恐らく下記の物です。
http://wkhtmltopdf.googlecode.com/files/wkhtmltoimage-0.10.0_rc2-static-i386.tar.bz2
次に、落としたデータを解凍

$ tar lxvf wkhtmltoimage-0.11.0_rc1-static-amd64.tar.bz2

すると「wkhtmltoimage-amd64」というバイナリデータが解凍されるので、これを/usr/local/bin等に「wkhtmltoimage」として移動させます。

$ mv wkhtmltoimage-amd64 /usr/local/bin/wkhtmltoimage

 
これでインストール完了、実際にコマンドラインでスクリーンショットを撮ってみましょう。

$ wkhtmltoimage http://www.google.co.jp screenshot.jpg

実際のスクリーンショットはこんな感じに成ります。
screenshot
このツールには色々オプションがあります。

$ wkhtmltoimage -H

にて確認できるので、色々試すのも良いかと。
ちなみに、私の環境だとwkhtmltopdfの方は何故かxvfbが無いと動きませんでした。なので、下記の様にAPTでインストールして、xvfb-runで仮想フレームバッファから実行しています。

$ aptitude install xvfb
$ xvfb-run wkhtmltopdf http://www.google.co.jp screenshot.pdf

 

Nginx ロードバランサー設定でやってしまったミス

せっかくブログ立てたのに、最近更新してないのでメモ的に使っていきます。
Nginxをロードバランサーとして使う際に、upstreamブロックを以下の様にしたところ

upstream backend {
server 10.XX.XX.1 weight=2;
server 10.XX.XX.2;
}

10.XX.XX.2のサーバを誤って落としてしまい、気付かずにブラウザから接続したらNginxからの応答が全く返ってこない始末・・・。
調べてみたらweight以外にも設定があるようで、以下追記

upstream backend {
server 10.XX.XX.1 weight=2;
server 10.XX.XX.2 max_fail=3 fail_timeout=30s;
}

max_failは試行回数、fail_timeoutは再接続(?)までの時間時間みたい。
一応10.XX.XX.2をもう一度落として確認したところ、10.XX.XX.1へ接続するようになったっぽい。

Nginxのempty_gifでhealthcheckをする

Nginxのempty_gifが地味に便利だったのでメモ
EC2などでELBなどを利用していると、Ping Targetにヘルスチェックファイルが必要になります。
インスタンスを立ち上げる際に、いちいち空のファイルを毎回デプロイするのも面倒なのですが、
Nginxのempty_gifを利用すると以下の設定だけでヘルスチェックできる感じです。

location = /healthcheck.html {
access_log off;
empty_gif;
}

empty_gifはメモリ上の1×1の空GIFファイルを取り出してくれるらしいので、実ファイル設置するよりかは多少早いかも。
あと、ELBからのヘルスチェックが頻繁に行われるので、ログに残したく無かったので、access_log off;にしてます。
あとはELB HealthCheckのPing Pathを/healthcheck.htmlなどにすればオッケーでした。

PythonでDaemon化をする メモ

pythonかphpで、スクリプトをデーモン化できないかなぁと思ったら、pythonで案外簡単に出来そうだったのでメモ
モジュールのインストール

pip install python-daemon

実際のコード

# -*- coding: utf-8 -*-
from daemon import DaemonContext
from lockfile.pidlockfile import PIDLockFile
dc = DaemonContext(
pidfile=PIDLockFile(‘/tmp/daemon.pid’),
stderr=open(‘err_console.txt’, ‘w+’)
)
def run():
while True:
# 何やらの処理
with dc:
run()

以上
ね、簡単でしょ。