Flask にはエラーハンドラという機構がある。 これは Web アプリケーションの中でハンドルされなかった例外を HTTP のレスポンスに変換するというものだ。 つまり、どれだけ呼び出しの深い場所にいてもエラーが起こったときには例外さえ上げればクライアントに適切なレスポンスが返るという便利な仕組み。 同様の機構は、他の Web アプリケーションフレームワークでも JAX-RS (Java) の例外マッパーや Pyramid (Python) の例外ビューとして見られる。 今回はその便利なエラーハンドラについて書いてみる。 まずは何はともあれ Flask をインストールする。 $ pip install flask 最初のサンプルコードは 404 エラーをレスポンスに変換するというものだ。 エラーハンドラが登録されていない場合はデフォルトのエラーメッセージが HTML で返ることになるが、
OpenStack の操作というと Horizon (OpenStack Dashboard) を使うやり方が紹介されることが多い気がする。 ただ、個人的には GUI よりも CUI を使った方が手順として残しやすいので、コマンドラインツールを使うやり方を覚えておきたいところ。 なので、今回は CUI 経由の操作方法について試してみる。 OpenStack 自体のセットアップ方法については、以前 RDO や DevStack を使うやり方について書いた。 コマンドラインツールは RDO や DevStack を使って OpenStack をインストールすると自動的にインストールされる。 OpenStack プロジェクトが使っているリポジトリにある python-*client って名前付いてるのがそれ。 https://github.com/openstack もし手動で入れる場合には P
以前 Packer で CentOS 6.5 の Vagrant Base Box を作る方法について書いた。 今回はそれに引き続き Vagrantbox.es になかなか登録されないなーと思っていた Ubuntu 14.04 LTS で作ってみる。 ハイパーバイザは VirtualBox と VMware Fusion に対応してる。 Packer のインストールは Mac なら Homebrew から。 $ brew tap homebrew/binary $ brew install packer Packer のテンプレートは GitHub に置いたので、まずはクローンする。 $ git clone https://github.com/momijiame/packer-vanilla-box.git Ubuntu 用のディレクトリに移動したら Packer でビルドする。 Vir
今回は Fabric を使ってみて便利だなと思った使い方についてメモっておく。 何はともあれ Fabric をインストールしておく。 前提として、ホストの情報は ~/.ssh/config に記載されていることにする。 $ sudo pip install fabric 実行時にタスクへ引数を渡す タスクとなる関数に引数を付けることで、実行時に引数を渡すことができる。 以下は、汎用なコマンド実行用のタスク invoke を定義して、実行するコマンドを引数で受け取るようにしている。 # -*- coding: utf-8 -*- from fabric.state import env from fabric.decorators import task from fabric.operations import sudo, run env.use_ssh_config = True @ta
コンテナ型仮想化は LXC を直で使おうとして一旦諦めたクチなんだけど、最近 Docker が登場してだいぶ便利になったらしいので試しに使ってみる。 コンテナ型仮想化というのは、ゲスト OS をホスト OS のカーネル内で分離する技術をいう、と思う。 ハイパーバイザ型仮想化に比べると一般に仮想化に必要なオーバーヘッドが少ないのがメリットとされている。 ただし、ホスト OS とゲスト OS がカーネルを共有するため、幾ら内部的に分離されているとはいえカーネルモジュールを使ったりするような一部の機能とは相性がよろしくない。 まず Docker は EPEL からインストールする。 $ sudo yum -y install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm $ sudo yum -
RabbitMQ には Firehose 機能というものがあって、有効にするとルーティングされるメッセージが全てそこに転送される。 スイッチのミラーポートみたいなイメージかな。 これを使うと AMQP のデバッグが捗る。 Rabbitracer は、その Firehose 機能で転送されてくる全てのメッセージを JSON 形式でダンプする。 以前同様のスクリプトを書いたので、それをリファクタした上で GitHub で公開してみた。 https://github.com/momijiame/rabbitracer 使い方は GitHub の README に書いた。 パッケージは PyPI にも登録したので PIP でインストールできる。 $ pip install rabbitracer そんなかんじで。
Vagrant で作成した既存の仮想マシンを元にした Base Box ファイルの作り方は以前この記事で扱った。 今回はまっさらな状態から手動で Base Box ファイルを作る方法について書いてみる。 おそらく本格的にやるなら VeeWee や Packer といったツールで自動化するんだろうけど、何事も一足飛びは失敗の元なので最初はマニュアルでやってみる。 Vagrant ホストには Mac OS X Mavericks (10.9.1) を使った。 VirtualBox のバージョンは 4.3.6 で、Vagrant のバージョンは 1.4.3 で動作確認している。 作成する Base Box ファイルは CentOS 6.5 (minimal) にする。 まず、一般的な Base Box ファイルの要件は以下に書かれている。 http://docs.vagrantup.com/v2
StringIO はファイルオブジェクトの API を備えた文字列のバッファ。 つまりオンメモリのファイルオブジェクトとして扱うことができる。 このオンメモリっていうのが割りと重要で、この特性を生かすと色々と便利に使えそう。 例えば、ファイルオブジェクトを受け取るような API の動作確認がしたいとする。 通常であれば実際にファイルをシステム上に作ってやるか、面倒だけどモックオブジェクトを作ることになるだろう。 StringIO を使えば、そんな手間が不要になる。 試しに REPL 上で StringIO を使って ConfigParser の動作を確認してみよう。 以下のコードでは ConfigParser が設定を読み出す元を StringIO オブジェクトにしている。 テスト用のファイルをシステム上に用意したり、自分でモックオブジェクトを用意するのに比べていかに簡単か分かると思う。
Ansible は Python で実装された IT インフラの自動化ツールだ。 乱暴に言えば Chef や Puppet の親戚みたいなもの。 特筆すべき点としては、対象に SSH さえ届けば使えるという手軽さがある。 上記は同じく Python で実装された自動化ツールの Fabric にも言えることだが、それとの違いは冪等性への考慮が手厚いことが挙げられる。 今回は、その Ansible を Vagrant と上手いこと連携させるまでの軌跡を紹介したい。 動作確認は以下の環境で行った。 Mac OS X Mavericks (10.9.2)Vagrant 1.4.3Ansible 1.4.5 まずは Vagrant を実行するマシンに Ansible をインストールする。 $ pip install ansible 次に Ansible で管理する VM を Vagrant で作る。
サーバ環境をテストするソフトウェアとしては Ruby の serverspec が有名だけど、Python にも Fabric をベースにして作られた envassert がある。 通常はテストに使われる envassert だけど、ふと Fabric のデプロイ用タスクに使っても便利なのでは?と思った。 envassert のインストールは PyPI から PIP で。 必要に応じて root ユーザで実行したり sudo する。 ついでに Fabric と Cuisine も入れておく。 $ pip install fabric envassert cuisine 以下はデプロイ用のタスクに evnassert を使うコンセプト的なコード片。 envassert はプラットフォームやパッケージの有無などを検出できる。 だから、例えばデプロイ先に求められる環境をチェックをしたり、パッケー
Linux では iptables を使って NAT ができる。 Ubuntu 13.04 で試してみた。 下準備 動作確認のために複数ホスト用意するのは面倒なので、環境には Linux Network Namespace を使う。 Linux Network Namespace についてはこちらの記事を参照のこと。 環境づくりに使ったコマンドは以下の通り。 $ sudo ip netns add client $ sudo ip netns add gateway $ sudo ip netns add server $ sudo ip netns exec gateway sysctl net.ipv4.ip_forward=1 $ sudo ip link add svr-veth type veth peer name svrgw-veth $ sudo ip link add c
Python のデバッガといえば言語そのものに付属している pdb がまず挙げられるけど、pdb は実行中の行以外を確認できなくて正直かなり使いづらさを感じる。 それ以外の Python のデバッガとしては、以前にこのブログでも winpdb を紹介しているし、それ以外だと Eclipse PyDev プラグインの GUI デバッガをよく使っている。 とはいえ、これら二つは動作に X Window System が必要だったり、プラットフォームとして Eclipse や wxPython をインストールしなきゃいけないのが結構手間になる。 今回紹介する PudB は動作に特別なプラットフォームが不要でなおかつ pdb より便利な CUI のデバッガだ。 インストールはいつも通り PyPI から PIP で。 必要に応じて sudo などする。 $ pip install pudb 使い方は
OpenFlow コントローラの冗長化について考える。 まず、冗長化と言って一番に思いつくのは VRRP などでアクティブスタンバイにする方法かな。 でも、これだとアクティブなホストは一台に限られるからスケールアップしかできなくなる。 やっぱり OpenFlow のレベルでコントローラをクラスタリングしてスケールアウトするのが、一番筋が良さそうだと感じた。 OpenFlow 1.3 ではスイッチが複数のコントローラに接続できて、各コントローラはロールを持つ。 デフォルトのロールは OFPCR_ROLE_EQUAL で、このロールのコントローラはスイッチにフルアクセス権を持つ。 それ以外に MASTER/SLAVE 構成を取るためのロールも定義されている。 今回はデフォルトのロールでスイッチをクラスタリングしてみる。 今回使う環境は以下の通り。 コントローラ 2 台 (cntl1, cntl
JSON の内容を sed や awk のようにフィルタ・加工するためのプログラムに jq がある。 JSON 形式で提供されている WebAPI の出力や、ログの内容を扱うのにとても便利。 その強力さの一端を紹介したい。 インストールは Mac OS X であれば Homebrew から。公式サイトからバイナリをダウンロードすることもできる。 $ brew install jq サンプル用の JSON を用意しておく。 $ cat << EOS > jsonfile {"name": "Foo", "sex": "Male", "age": 15, "emails": []} {"name": "Bar", "sex": "Male", "age": 20, "emails": ["hoge@example.jp"]} {"name": "Baz", "sex": "Female", "
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く