情熱プログラマー

August 29th, 2010 by naoya | No Comments | Filed in day

Rubykaigi で、すっかり買うのを忘れていた情熱プログラマーを購入した。

この本は、達人プログラマーという本があったが、その本のコンセプトに近い、プログラマーが幸せに生きるためのヒントが合計 53 の項目に書かれてまとめられている本です。

個人的にぐっときた項目を紹介したいと思います。

5. 自分の知性に投資しよう (Invest in Your Intelligence)

自分がこれから学ぶべきテクノロジーをどうやって選択するのか、そのヒントが書かれています。これから主流になりそうなテクノロジーを学ぶことが重要だけれど、そうでなくあえて主流でないテクノロジーを学ぶことで自分自身を高めることができるという発想は個人的にはなかった。もちろんその主流でないテクノロジーの達人になるのではなく、他のプログラミン言語との特徴や違いをつかむことが重要とのこと。

個人的には、まったく関数型言語を使ったことがないので、これから挑戦してみようと思います。

15 一に練習、二に練習 (Practice, Practice, Practice)

本番で練習するという考え方はもう捨てること。自分の技術にちゃんと時間を投資して練習し続けることの大切が書かれています。たくさん練習することで、自分の技術は磨かれる。当たり前と言ってしまうと、確かにそうですが、なかなか実務に忙しいときは練習量が減ってしまうことも多々あるかと思います。なので、練習するという意識はもち続けることが大切なのだと思います。

28. 8時間燃焼 (Eight-Hour burn)

毎日、職場についたら8時間!やって、やって、やるしかない!という気持ちで業務に取りかかって、終了の時刻を自分に厳しく課して生産性を向上あげようというもの。けっこう僕の場合、最初はだらだらしがちになってしまうことが多いので、この8時間燃焼という考え方は実践してみたいと思います。

午前4時間、お昼休憩1時間、午後4時間、そのサイクルでくたくたになるまで集中して取り組む。もちろん、Twitter やメッセなどは全部切って集中する。終わったら、帰宅してくつろいで好きなことをする。

そして、最後の項目。

53 独立する (Go Independent)

個人的に今年の4月からフリーランスとしての独立をしてしまったので、感情深いエッセイとして読んでしまった。僕も、この項目に書かれている内容を決意して独立をしました。何事も分かりやすいのが、一番なので。

この他にも、53の項目以外にも、コラムがあってその中には GitHub の誕生秘話などもあって、かなり面白いのでプログラマー・エンジニアの方は読んでみるのをおすすめします。

Rails でメンテナンス画面を表示する方法

August 17th, 2010 by naoya | No Comments | Filed in day

今日は、Rails でメンテナンス画面を表示する方法を紹介したいと思います。今のところ、次のような方法で行っています。

環境は、次のとおりです。

  • OS: CentOS 5.x x86_64
  • ロードバランサー: LVS + keepalived
  • ウェブサーバ: Apache + Passenger + Rails

サービスをメンテナンス状態にしたいとき、次の方法が考えらます。

  1. ロードバランサー側の iptables を使って、ロードバランサー側でメンテナンス表示画面を返す
  2. ウェブサーバ側で、メンテナンス表示画面を返す

1 だと、メンテナンスへの切り替えが面倒なので、僕は 2 の方法で行っています。

ウェブサーバ側で、次のようなルールを記述しておきます。

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^(.*)$ /$1 [R=503,L]

DocumentRoot 以下に maintenance.html というファイルがあるとき、そのファイルを返すというシンプルなルールです。

メンテナンス表示に切り替えるには、maintenance.html を置くだけなので、プログラムのデプロイにも使っている capistrano の ::deploy::web の disable / enable を、次のように定義します。

namespace :web do
task :disable do
on_rollback {
run “rm #{current_path}/public/maintenance.html”
}

run “cp #{current_path}/templates/maintenance.html #{current_path}/public/”
end

task :enable do
run “rm #{current_path}/public/maintenance.html”
end
end

あとは、このタスクを使って、次のコマンド一発でメンテナンスへの切り替えをすることができます。

$ cap deploy:web:disable

メンテナンス状態を解除する場合には、次のコマンド一発です。

$ cap deploy:web:enable

また、メンテナンス表示のとき、画像を返さないといけない場合は、mod_asis を使って、次ようなルールを定義しています。

AddHandler send-as-is asis

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteRule ^(.*)$ /images/transparent.gif.asis [NC,L]

transparent.gif.asis は、1×1 の白い、次のヘッダーがついた gif です。

Status: 200 OK
Content-Type: image/gif
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-store
Cache-Control: no-store

Tags:

(おそらく)サーバをたくさん並べるのは流行らない

August 5th, 2010 by naoya | 3 Comments | Filed in day

これからの時代、(おそらく)サーバをたくさん並べるのは流行らないと思っています。

その理由は、次のとおりです。

  • 最近のサーバには、かなりの大量のメモリが搭載できる
  • CPU の処理速度もマルチコア化がかなり進んでいて上がっている
  • 仮想化技術が当たり前のようになっていてサーバのリソースをまんべんなく使えるようになっている
  • 最初のボトルネックになりがちだったディスクも SSD や Fusion I/O を搭載できる
  • ラックの最大許容電力の問題

具体的な例をあげてみましょう。いつもこのブログでは DELL サーバを例にとっているので、今回は HP のサーバを例にとってみます。

例えば、HP の ProLiant DL360 G7 では、最大次のような仕様になっています。

  • サイズ: 1U
  • CPU: Xeon 5500/5600番台 x 2
  • Memory: 192GB (DDR3、18 スロット)
  • Disk: 2.5 SAS/SATA x 8
  • NIC: 4ポート
  • PCI Express: 2 スロット

このサーバを、次のスペックで見積もってみると、約67万円くらいでした。

  • CPU: Xeon L5520 x 2
  • Memory: 48GB
  • Disk: 120GB 2.5 inch x 2

いっけん高いようにみえますが、比較するべきは、次のようなスペックのマシンを2台購入したときとのコストの比較になると思います。

  • CPU: Xeon L5520 x 1
  • Memory: 24GB
  • Disk: 120GB 2.5inch x 1

もちろん、マシンは機械である以上故障はするので、故障のリスクも考えないといけませんが、できる限りマシンは減らした方がサーバの運営管理コストは下がるので、量と質の問題を考えなければいけません。

さらに、4U の ProLiant GL580 G7 というサーバには、メモリをなんと最大 1TB まで搭載できます。コストは相当なかかると思いますが、コストはイニシャルコストとランニングコストのバランスの問題になってくるはずです。

すこし前までは、メモリが足りない、ディスクが遅い、などの理由で、多数の 1U サーバを並べる傾向が強かったような気がしています。

さらにクラウドでも、同じような傾向があります。クラウド大手の Amazon EC2 をみてみると、High Memory Instance として次の 3 種類が提供されています。

  • High-Memory Extra Large Instance 17.1 GB memory, 6.5 ECU (2 virtual cores with 3.25 EC2 Compute Units each), 420 GB of local instance storage, 64-bit platform
  • High-Memory Double Extra Large Instance 34.2 GB of memory, 13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform
  • High-Memory Quadruple Extra Large Instance 68.4 GB of memory, 26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform

Quadruple Extra Large を選択すると、なんと 68.4GB メモリが搭載されています。

価格は、現時点で次のとおりです。(US – N.California, Linux の場合)

  • Extra Large: $0.57 per hour
  • Double Extra Large: $1.34 per hour
  • Quadruple Extra Large: $2.68 per hour

Extra Large と Quadruple Extra Large の価格差は約 4.7 倍程度で、おおよそ実際のスペックと同じ比率になっています(若干すこし高めの設定ですが)。

この価格なら、例えば Extra Large を 5 台並べるか、Quadruple Extra Large を 1 台にするか、どちらがいいのか考える必要があるでしょう。

もちろん、サーバが少ないときのデメリットも、サーバが1台ダウンしたときの影響が大きいが考えられます。

すこし前まではサーバの多く並べる傾向が強かったと思います。

ただ、これからの時代はどちらかというと、サーバをたくさん並べるよりも、処理能力の高いサーバを少なく並べる傾向が強くなってくると思います。

つまり、僕はできる限り多くの同時リクエストを1台のサーバでさばく、そんな時代になってくると思うので、その流れにあった技術を身につけるのが重要になるのではないかと思います。

Tags:

Linux から IPMI の IP アドレスを変更する方法

July 26th, 2010 by naoya | No Comments | Filed in day

通常の IA サーバは、IPMI の IP アドレスは BIOS 上から変更できるようになっています。最初に BIOS から IPMI の IP アドレスを変更して、Linux(CentOS) をセットアップして本番投入直前になって諸事情によって IPMI の IP アドレスとサブネットマスクを変更することになりました。

このとき OS を再起動して、BIOS から変更すれば IPMI の IP アドレスを変更することが可能ですが、データセンターの現地にいって一台ずつ再起動するのが面倒です。

Linux 上からだと、IPMI のサービスを起動することによって、IPMI の IP アドレスを変更することができます。仮想化をしている場合には、物理サーバ上から変更することができます。

まず、IPMI のサービス、imptool をインストールします。

$ sudo yum install OpenIPMI ipmitool

次に IPMI のサービスを起動します。

$ sudo service ipmi start

Starting ipmi drivers:                                     [  OK  ]

IPMI サービスを起動すると、ipmi のデバイスが見えます。

$ dmesg | grep ipmi

ipmi message handler version 39.1
ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca2, slave address 0×0, irq 0
ipmi: Found new BMC (man_id: 0x00XXXX,  prod_id: 0xXXXX, dev_id: 0xXX)
ipmi device interface

この状態で、ipmitool を使って IP アドレスとサブネットマスクを変更します。

$ sudo ipmitool lan set 1 ipaddr X.X.X.X

$ sudo ipmitool lan set 1 netmask 255.255.0.0

この変更にはすこし時間がかかることもあるので、プロンプトが返ってくるまで待ちます。

変更したら、正しく変更されているか確認します。

$   ipmitool -I lanplus -H X.X.X.X -U <ユーザ名> -P <パスワード> lan print

IPMI の IP アドレスなどの変更ツールは、IA サーバのメーカー製のツールがあってそのツールからも変更できますが、ipmitool を使うことによって同じ方法で変更できるので便利です。

Tags:

Puppet キャンプ in ヨーロッパ

July 6th, 2010 by naoya | No Comments | Filed in day

すこし前のことになりますが、ベルギーにて 3 月 27 〜 28 日まで Puppet キャンプが開催されました。

Puppet Labs に、そのときの動画をスライドがすべて公開されています。

動画はあとでチェックすることにして、スライドだけチェックしてみました。講演のタイトルは、次のとおりです。

  • Portable infrastructure with Puppet – Luke Kanies (Slides|Video)
  • Embedded Puppet – Alban Peignier (Slides|Video)
  • Deploying datacenters with Puppet – A user’s perspective – Rafael Brito (Slides|Video)
  • Puppet modules and module standards – Alessandro Franceschi (Slides|Video)
  • Auditing change management policies with Puppet and Splunk – Jeff McCune (Slides|Video)
  • Puppet in complex, real-time environments – Rick van der Zwet (Video)

まずは、Puppet の中心人物である Luke さんの発表。この発表では、おもに Puppet の現在の状況と、これからの展望について発表がありました。以下、メモです。

  • Puppet は、安定している(現在のリリースバージョンは、0.25.5)
  • Puppet は、さまざまな面で日々高速に進化している
  • Puppet は、さまざまな分野で使われている(Google、DELL、Disney、J.P.Morgan など)
  • Puppet キャンプ 2009 では、次のことを約束した
  • バージョン 1.0 のリリース … 1.0 / 2.0 はスキップして、現在 2.6 で開発中で、いくつか大きな機能を盛り込んでいる、Pure Ruby DSL(*1)、クラスパラメータ(*2)、REST への移行がすべて完了する、puppet のプログラム一つに移行する(例えば、puppetmastered -> puppet master となる)、レポートにさらに詳細な情報が含まれるようになる、新しい関連を示すシンタックスが追加される(*3)、ハッシュ(*4)
  • Web GUI アプリケーション … Puppet Dashboard としてリリースした
  • モジュール … モジュールを共有できる場所として Puppet Forge をリリースした

(*1) Pure Ruby DSL

Puppet 2.6 では、Ruby で DSL として、次のような感じで記述することができる。ついにこの機能が登場しそうです。Ruby で記述できれば、特殊な Puppet DSL を学習することができなくて済みますね(大きな概念は変わらないと思いますが)。おそらく、これはユーザの声をきいた結果だと個人的に思います。

hostclass “foo” do

package :foo, :ensure => :present

service :foo, :ensure => :running

end

node “hoge.example.com” do

acquire “ssh”

end

(*2) クラスにパラメータを与えることができる

class foo($hoge = “bar”) {

}

class { foo: hoge => “bar” }

(*3) 次のようなシンタックスが追加される、個人的にはちょっと複雑な文法なので使いこなせなさそうです

notify { b: } -> notify { a: } -> notify { c: }

Notify[b] ~> Notify[a] ~-> Notify[c]

(*4) ハッシュ、Ruby のハッシュっぽく記述することができる、これは重宝しそうです

class foo {

$data = {}

$data[one] = 1

$data[one] = 2

file { “/tmp/hoge”: content => template(“foo/tmp/hoge”), }

Puppet Forge については、改めて別の機会に紹介したいと思います。

次の話は、Puppet を組み込む方法について。これは省略します。

その次の話は、Puppet を使って複数のデータセンターを構築する方法の話。OS は、RHEL でしたが、その中で kickstart の pre セクションで、MAC アドレスを登録する次のスクリプトは、なるほどと思いました。

%pre
SERVER=`grep ‘url address’ /tmp/anaconda.log | awk ‘{print $6}’`
cd /tmp && wget -q http://${SERVER}/pub/dmidecode
chmod +x /tmp/dmidecode
SN=`dmidecode | grep “Serial Number” | head -1 | awk ‘{print $3}’`
MAC=`ifconfig | grep HWaddr | awk ‘{print $5}’`
wget -q http://${SERVER}/cgi-bin/register.pl?mac=$MAC\&sn=$SN
reboot

上のスクリプトでは、MAC アドレスと dmidecode をしたマシンのシリアル番号を register.pl へ送っています。

僕は、いままでマシンの BIOS などで MAC アドレスを確認していましたが、この方法を応用すれば自動化できる可能性が出てきました、さっそく挑戦してみたいと思います!

その次の話では、Puppet モジュールの標準的な書き方について、いくつか参考になる話があったのでまとめておきます。

include するときのポイント。次のように使い分けると分かりやすい。

  • include postfix – Postfix サービスをインストールして実行する
  • include postfix::disable – Postfix をインストールするがサービスは実行しない
  • include samba::server – Samba サーバをインストールする
  • include samba::client – Samba クライアントをインストールする

import と include の違いは、Puppet の中で重要なので押さえておきたいところです。次のような違いがあります。

  • import autofs – $modulepath/autofs/manifests/init.pp を読み込む
  • include autofs::server – $modulepath/autofs/manifests/server.pp を読み込む

puppetdoc コマンドを使うと、コメントが含まれているマニフェストからドキュメントを生成することができる。例えば、次のようなマニフェストを書く。

# Class: apache
#
# このモジュールは Apache を管理します
#
# Parameters:
#
# Actions:
#
# Requires:
#
# Sample Usage:
#
# [注意: コメントとクラス定義の間には空行を入れないこと]
class apache {
	...
}

最後の二つの講演は、特に参考になる情報はありませんでしたが、Puppet キャンプ楽しそうです!

RE: 独自/ミラー yum リポジトリを作ろう

June 15th, 2010 by naoya | No Comments | Filed in day

アシアルさんのブログに「独自/ミラー yum リポジトリを作ろう」というエントリが公開されました。

とても分かりやすく「独自/ミラー yum リポジトリ」を作る方法がまとまっている素晴らしいエントリです。

アシアルさんのブログでは、rsync や createrepo などを手動で使っていますが、これを cobbler というツールを使うともっと簡単に「独自/ミラー yum リポジトリ」を作成することができます。

まず、CentOS 5.x のミラーを作成する方法を紹介します。

EPEL を設定してから、cobbler をインストールします。

$ sudo yum install cobbler

CentOS ミラーサイト一覧から、自分がいる国にいる近いサイトの rsync 可能なミラーサイトを選びます。ミラーサイトを選んだら、次のコマンドでミラーします。

$ sudo cobbler import –path=rsync://your_centos_mirror_site/centos –name=centos –arch=x86_64

rsync し終わったら、httpd を起動してから、/etc/yum.repos.d に次のような yum リポジトリを追加します。

cobbler をインストールすると、自動的に必要な yum リポジトリの公開設定が /etc/httpd/conf.d/cobbler.conf にされています。

[centos]
name=centos
baseurl=http://localhost/cobbler/repo_mirror/centos
enabled=1
gpgcheck=0
priority=1

ミラーを更新したい場合は、次のような cron を root ユーザの cron で設定します。

/usr/bin/cobbler reposync –tries=3 –no-fail > /dev/null 2>&1

独自の yum リポジトリを作成した場合は、RPM が入っているディレクトリ (例えば /home/naoya/rpms) を用意して、次のコマンドを実行するだけです。

$ sudo cobbler repo add –name=”local” –mirror=”/home/naoya/rpms”

独自の yum リポジトリを更新する場合も、上の cobbler reposync コマンド一発で同期させることができます。

独自の yum リポジトリの設定は、次のようなになります。

[local]
name=local
baseurl=http://localhost/cobbler/repo_mirror/local
enabled=1
gpgcheck=0
priority=1

いかがでしょうか?

cobbler を使うと、とても簡単に yum リポジトリを構築することができます。

ぜひ、試してみてください!

Tags:

kumofs の RPM を作ってみた

June 11th, 2010 by naoya | No Comments | Filed in day

そろそろ本格的に kumofs を使ってみようかなと思いたって、CentOS 5.5 x86_64 向けの RPM を作ってみました。

まず、kumofs には、次のものが必要です(以下の情報は公式ドキュメントを参照しました)。

Linux と g++ と libcrypto と zlib は、CentOS 5.5 x86_64 の標準パッケージに含まれているので標準パッケージをインストールすれば問題ありません。

Ruby は、以前紹介した方法で作成したバージョン 1.8.7 系を RPM でインストールします。

TokyoCabinet は、自分で作成した SPEC ファイルから RPM を作成しました。

MessagePack for C++ も、自分で作成した SPEC ファイルから RPM を作成しました。

MessagePack for Ruby は、RPM を作成してもいいですが gem コマンド一発でインストールすることができるので RPM は作成しませんでした。次のコマンドでインストールします。

$ sudo gem install msgpack

肝心の kumofs ですが、kumofs は分散環境下で使われていることを前提しているので、kumo-manager、kumo-server、kumo-gateway、は別々のサーバであることが普通の環境だと思います。

そこで、kumofs というコアのプログラムが含まれている RPM、manager、server、gateway、をそれぞれ別々の RPM として作成してみました。あわせて、manager、server、gateway、それぞれの redhat 系の起動スクリプト、設定ファイル、logrotate スクリプト、daemontools 用のサンプルスクリプト、を作成して RPM に同梱しました。これからのスクリプトは、まとめて github に置きました。また、作成した RPM も github に置きました(バージョンが少し古いので注意してください)。

sysinit のスクリプトを使うと、kumofs の実行ユーザが root にになります。通常ユーザで実行したい場合は、daemontools などを使うといいと思います。daemontools 用のサンプルスクリプトは、github においてある kumofs-XXX-run.sample と kumofs-XXX-log-run.sample です。daemontools を使う場合は、logrotate のスクリプトを削除するのを忘れないでください。

kumo-gateway のプログラムにも libtokyocabinet がリンクされているのはちょっと気になるところですが、特に弊害はないので気にしないことにします。

ここで作成した RPM で、それぞれのインストール方法を説明します。

まず、manager から、manager にはコアの RPM もインストールします。manager の設定は、/etc/sysconfig/kumo-manager を編集します。daemontools 用のスクリプトも同じ設定ファイルを読み込んでいます。

$ sudo yum install kumofs kumofs-manager

次に server。設定ファイルは、/etc/sysconfig/kumo-server です。

$ sudo yum install kumofs-server

そして、gateway。設定ファイルは、/etc/sysconfig/kumo-gateway です。

$ sudo yum install kumofs-gateway

server と gateway には、kumoctl などの管理系のコマンドはインストールされないので注意してください。server と gateway にはそれぞれに必要な最低限のプログラムをインストールしています。kumofs の管理系のコマンドを使う場合は、manager のサーバ上から使います。

また、kumofs とは関係ありませんが、個人的には rpmforge を本番環境のサーバでは使わない方がいいと思います。過去に、rpmforge を使っていてパッケージまわりでトラブったことがあります。自分で RPM を作成する手間を削減できるので EPEL の方はちゃんとしているので使うのをおすすめします。

今回作成した kumofs の RPM も、EPEL に入れることができるのか提案してみる予定です。

今回の RPM を作るにあたって、次のページを参考にしました。貴重な情報ありがとうございました!

(おまけ)

OSX を使っている人向けに MacPorts でも kumofs をインストールすることができます。

$ sudo port selfupdate

$ sudo port install kumofs

$ sudo port info kumofs
kumofs @0.4.7 (net)
Variants:             universal

Description:          kumofs is a scalable and highly available distributed
key-value store. You can use a memcached client library to
set, get, CAS or delete values from/into kumofs. Backend
storage is Tokyo Cabinet and it will give you great
performance.
Homepage:            http://kumofs.sourceforge.net/

Library Dependencies: msgpack, rb-msgpack, tokyocabinet, openssl, zlib
Platforms:              darwin
License:                  unknown
Maintainers:          < my email address >

Tags:

MacBook Pro で、外付けディスプレイのみを使う方法

June 8th, 2010 by naoya | No Comments | Filed in day

昨年、自宅や出先など大きなディスプレイがあるときは MacBook Pro で外付けディスプレイのみをこの方法で使っていました。

しかし、新しい世代の MacBook Pro になってから、OSX のバージョンアップの影響からなのか、昨年紹介した方法が使えなくなってしまいました。

ずっと不便だなと思っていたのですが、今日偶然こんな映像「Set Up External Monitor/TV to Macbook Pro – Video」を見つけました。この映像によると、次の手順で外付けディスプレイのみを使うことができるようです。

  1. MacBook Pro の LCD を閉じる
  2. スリープ状態になるまで待つ
  3. 適当な外付けキーボードを接続する
  4. MacBook Pro と外部ディスプレイを接続する
  5. 外付けキーボードから、スペースキーを押して復帰させる

この方法をとると、MacBook Pro LCD の解像度ではなく、外付けディスプレイの解像度として切り替えることができるようです。

なるほどと思って、僕もさっそく試してみると上の方法で確かにできました!

ただ、毎回外付けキーボードを接続するのは面倒くさいです。無線 LAN 経由で、スリープ状態から起こすことができるか調べてみるとなんとできるではありませんか!(参考:無線LAN経由で眠っているMacBookを起こす方法 – ザリガニが見ていた…。

ということで、次の方法で MacBook Pro を外付けディスプレイのみで使うことに成功しました。これで、大きいディスプレイがある環境では、マルチディスプレイにするより作業効率が上がります。

  1. MacBook Pro を、同一ネットワーク上からインターネットに接続する
  2. 別のホストコンピュータから、WakeOnLan などのソフトウェアを起動して MacBook Pro を認識させておく
  3. MacBook Pro の LCD を閉じて、スリープ状態にする
  4. 外付けディスプレイに接続する
  5. 手順 2 の WakeOnLan などのソフトウェアから、対象の MacBook Pro を起こす
  6. 対象の MacBook Pro が起きると、外付けディスプレイのみに出力先が切り替わる

あとは、teleport や Synergy なりで、ホストコンピュータから MacBook Pro を操作することができます。

これで、個人的には自宅や出先での作業効率がいくぶんか上がるはずです。

# 2010/06/10: 追記

@htaira さんから、すばらしいアドバイスをいただきました。なんと、次の方法でもできました!

  1. MacBook Pro LCD を閉じる
  2. 外部ディスプレイを接続する
  3. MacBook Pro がスリープ状態になったら、素早く LCD を開いて、すぐに閉じる

これなら、簡単ですね!

Tags:

RVM を使ってみた

May 17th, 2010 by naoya | No Comments | Filed in day

Ruby のバージョンには、いくか種類があります。現在、Ruby バージョン 1.8 系、バージョン 1.9 系、をはじめ REE、JRuby、などいくもあります。これからの複数のバージョンを切り替えて使いたい場合には、RVM(Ruby Version Manager)を使うと便利です。

RVM を使うと、簡単に Ruby のバージョンを使い分けることができます。

インストールは、いたってシンプルで gem からインストールします。

$ sudo gem install rvm

rvm をインストールしたら、rvm-install コマンドでホームディレクトリにインストールします。

$ rvm-install

すると、$HOME/.rvm というディレクトリが作れらます。

次に、.zshrc などに、次の設定を追加して反映させます。反映されると、rvm というコマンドが使えるようになります。

if [[ -s /Users/n0ts/.rvm/scripts/rvm ]] ; then source /Users/n0ts/.rvm/scripts/rvm ; fi

あとは、ここに使いたい Ruby をインストールするだけです。RVM で対応している Ruby 一覧を見るには、次のコマンドを実行します。

$ rvm list known

(ruby-)1.8.6(-p399)
(ruby-)1.8.6-head
(ruby-)1.8.7(-p249)
(ruby-)1.8.7-head
(ruby-)1.9.1(-p243)
(ruby-)1.9.1(-p376)
(ruby-)1.9.1-head
(ruby-)1.9.2-preview1

REE や JRuby や IronRuby などにも対応しています。

さっそく複数の Ruby をインストールしてみましょう。

最初に、Ruby バージョン 1.8.7 をインストールします。

$ rvm install 1.8.7

Ruby をコンパイルしてインストールするので、対象時間がかかります。

次に、Ruby バージョン 1.9.1 をインストールします。

$ rvm install 1.9.1

そして、肝心の Ruby を切り替える方法ですが、バージョン 1.8.7 に切り替えたいときは、次のコマンドを実行します。

$ rvm use 1.8.7
Using ruby 1.8.7 p249

$ ruby –version
ruby 1.8.7 (2010-01-10 patchlevel 249) [i686-darwin10.3.0]

$ which ruby
/Users/naoya/.rvm/rubies/ruby-1.8.7-p249/bin/ruby

仕組みは単純で PATH 環境変数を書き換えているだけです。

次にバージョンを 1.9.1 に切り替えてみます。

$ rvm use 1.9.1
Using ruby 1.9.1 p378

$ ruby –version
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.3.0]

$ which ruby
/Users/n0ts/.rvm/rubies/ruby-1.9.1-p378/bin/ruby

ちゃんと切り替わっていますね。

また、RVM でインストールした Ruby に対して一括実行することもできます。

$ rvm ruby -v
ruby-1.9.1-p378: ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.3.0]
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.3.0]

$ rvm gem install rails

まとめて Rails をインストールすることができます。

Passenger も同様にインストールできますが、Passenger の Apache / Nginx モジュールを作成するときには、次のようにします。

$ rvm install
$ rvm 1.8.7 –passenger
$ rvm 1.8.7
$ gem install passenger
Building native extensions. This could take a while…

$ rvmsudo passenger-install-nginx-module

Phusion Passenger is a trademark of Hongli Lai & Ninh Bui.

あとは、PassengerRoot を、/Users/naoya/.rvm/gems/ruby-1.8.7-p249/gems/passenger-2.2.11/ に設定します。Ruby バージョン 1.9.0 のときも同様の方法でインストールすることができます。

RVM を使うと、手軽に Ruby を切り替えることができるので、便利です。

Tags:

Ruby バージョン 1.8.7 の RPM を作る

May 15th, 2010 by naoya | 1 Comment | Filed in day

CentOS 5.4 x86_64 の Ruby は、ご存じのとおりバージョン 1.8.5。枯れすぎています、さすがに最近ではバージョン 1.8.5 だと動かないプログラムが増えてきたので、RPM を作ってみました。ちなみに RHEL6 beta の Ruby のバージョンは 1.8.6 なので、CentOS 6 になっても役に立ちそうです。

まず、Fedora になる Ruby 1.8.6 の RPM をダウンロードします。

$ wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/development/source/SRPMS/ruby-1.8.6.399-1.fc14.src.rpm

SRPM をインストールします、なぜか MD5 があわないので無視します。

$ rpm -i –nomd5 ruby-1.8.6.399-1.fc14.src.rpm

ruby.spec ファイルを書き換えます、現時点での Ruby バージョン 1.8.7 のパッチレベルは 249 なので、ダウンロードします。

$ cd rpmbuild/SOURCES

$ wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p249.tar.bz2

次に ruby.spec ファイルを、修正します。基本的に適応できないパッチをあてないのと、x86_64 の場合は lib ディレクトリのパスが変わるので変更します。lib ディレクトリのパスは、i386 でも問題がないように %{_lib} を利用しました。

ruby.spec ファイルの差分は、次のような感じです。

あとは、rpmbuild するだけですが、依存しているパッケージがけっこう多いので拙作の auto-rpmbuild.sh を使うと便利です。

$ auto-rpmbuild.sh -ba ~/rpmbuild/SPECS/ruby.spec

最後に、既存の Ruby を上書きしてアップグレード完了です。

$ sudo rpm -Uvh rpmbuild/RPMS/x86_64/ruby-*

$ ruby –version

ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]

上書きしたあと、なぜか ruby-libs の古いバージョンが残っているので念のため削除しておきました。

$ sudo rpm -e ruby-libs-1.8.5-5.el5_4.8

作成した Ruby の RPM は、github へアップロードしておきました(ついでに Rubygems バージョン 1.3.7 の RPM を作ってアップロードしておきました)。

今回の RPM の作り方は、次のページを参考にしました。

# CentOS は、パッケージが枯れすぎていてパッケージを作るのがとてもとても面倒だけれど、安定して動いてくれているので重宝しています。

Tags: