2009年12月アーカイブ

これからはクラウドだぜ!ということで、この気持が冷めないうちになにかをはじめようと、Google App Engine(GAE)のアカウントを取得した。言語はRuby(JRuby)を選択し、自分がふだん使っているFreeBSDマシンに開発環境を構築した。例によっていくつかトラブルがあったので、メモを残しておく。

インストール対象のOSはFreeBSD 7.2-RELEASE-p5。まずは、JavaのSDKとしてFreeBSD FoundationのJava配布サイトからdiablo-jdk-freebsd7.i386.1.6.0.07.02.tbzを取得してpkg_addコマンドでインストールする。そのままだと日本語が文字化けするので、これを解消するために以下のコマンドを実行する。

% cd /usr/local/diablo-jdk1.6.0/jre/lib/fonts/
%sudo ln -s /usr/local/lib/X11/fonts/TrueType fallback
%

JDKがらみでもうひとつ。このままGAE/JRuby開発環境を作って最後にアプリをGAEにデプロイしようとすると、(エラーメッセージを控えてない、ごめん)GAEのサーバとのSSLのコネクションができずにデプロイに失敗する。これを回避するための方法は、例えばDebianのca-certificates-javaパッケージなどを取得して、そのなかに含まれているcacertsファイルをdiablo-jdkのファイルと入れ換える。

% pwd
/tmp
% wget http://ftp2.jp.debian.org/debian/pool/main/c/ca-certificates-java/ca-certificates-java_20091021_all.deb
% ar x ca-certificates-java_20091021_all.deb
% tar xvf data.tar.gz
% cd /usr/local/diablo-jdk1.6.0/jre/lib/security/
% sudo cp /tmp/usr/share/ca-certificates-java/cacerts ./
%

次にrubyとgem。rubyは最新の1.9.1-p376で、gemも最新の1.3.5をインストールした。これ自体はノープロブレム。そのあと、gemを用いてgoogle-appengineパッケージをインストールするのだが、このときいっしょにインストールされるrubyzip-0.9.1が使用しているftoolsがruby-1.9.1ではdeprecatedだとのことで、処理が途中で失敗してしまう。いろいろ調べて、以下のパッチの要領でftoolsのところをfileutilsで書き換えることにより解決した。

% pwd
/usr/local/lib/ruby/gems/1.9.1/gems/rubyzip-0.9.1/lib/zip
% diff -u zip.rb.orig zip.rb
--- zip.rb.orig 2009-12-13 22:15:39.000000000 +0900
+++ zip.rb      2009-12-14 20:38:25.000000000 +0900
@@ -1,7 +1,7 @@
 require 'delegate'
 require 'singleton'
 require 'tempfile'
-require 'ftools'
+require 'fileutils'
 require 'stringio'
 require 'zlib'
 require 'zip/stdrubyext'
@@ -662,8 +662,8 @@
         # ignore setuid/setgid bits by default.  honor if @restore_ownership
         unix_perms_mask = 01777
         unix_perms_mask = 07777 if (@restore_ownership)
-        File::chmod(@unix_perms & unix_perms_mask, destPath) if (@restore_permissions && @unix_perms)
-        File::chown(@unix_uid, @unix_gid, destPath) if (@restore_ownership && @unix_uid && @unix_gid && Process::egid == 0)
+        FileUtils::chmod(@unix_perms & unix_perms_mask, destPath) if (@restore_permissions && @unix_perms)
+        FileUtils::chown(@unix_uid, @unix_gid, destPath) if (@restore_ownership && @unix_uid && @unix_gid && Process::egid == 0)
         # File::utimes()
         end
     end
@@ -1566,7 +1566,7 @@
       tmpFilename = tmpfile.path
       tmpfile.close
       if yield tmpFilename
-        File.move(tmpFilename, name)
+        File.rename(tmpFilename, name)
       end
     end
ino%

あとは手順どおりで、Sinatraを用いてRubyで書いたWebアプリケーションをGAEにデプロイできた。さてさて、これから先の最大の問題は、おれがRubyをほとんど知らんということだ。まあ、この先はじっくり勉強しながら進めることにしましょ。

先日に書いたRHELのインストールの話の続き。ググってみつけた、NICのチェックサムオフロードを無効にすればSSH通信(というかTCP通信)ができるようになるのではないかというやつを試してみたんだけど、結果から言うとこれはダメだった。VMwareでブリッジ接続したゲストOSとTCP通信ができないという情報はいくつか見つけることができたけど、どれも解決には至っておらず、これはもう無理かなと諦め、ひとまずstoneでホストOSのポート22をRHELにポートフォワーディングすることでお茶を濁しておくことにした。この現象、ゲストOSのイメージを別マシンに移したらそっちでは普通に動作したなんて話もあったので、やはりNICを含んだハードウェアに依存しているように思う。しかしこういケースがあるようだと、客先への提案として「VMwareで仮想化しましょう」とか気楽に言えないよね。ちょっと困ったな。

と、この話はここで終わるかと思われたんだけど、まだ続きがあった。その後、この現象はVMwareだけで発生する現象なのか他の仮想化ソフトでもおきるのか確認してみようと思い立ち、Virtual Boxをインストールしてみた。VMwareを動かしている計算機にVirtual Boxも入れちゃってもだいじょうぶか不安もあったんだけど、まあ、ダメならアンインストールすればいいやと、とりあえずやってみた。そうしたら、案の定不安は的中し、インストールプロセスは最後の最後でハングしやがった。インストーラの強制終了もWindowsのシャットダウンもできず、電源をバシッと切って再起動した。NICにはVirtual Boxのブリッジ接続用ドライバがインストールされているものの、ソフトウェア自体は「プログラムの追加と削除」からアンインストールすることもできず、Virtual Boxのインストールはやはり正常に完了していない状態だった。ちなみに、この状態ではVMware上のRHELとのSSH接続は相変わらずできない状態だった。んで、しばらくこの状態で動かしていたんだけど、Virtual Boxのブリッジ接続用ドライバが残ったままだったことを思い出して、これを削除して再起動した。そのあとなんとなしにRHELへのSSH接続を試してみたところ、なんとびっくり、すんなり繋がるではありませんか! SSHといっしょに確認していてやはりダメだったFTPも普通に繋がる。もうなにがなんだかさっぱりわかりません...。ホントなら、環境をまた戻していってどこが原因だったのか確認したいんだけど、なにせ業務用の開発環境でまともに動いていることが大事だし、なにかの間違いで二度と接続できなくなっちゃったら困るので、しばらくはこのままでいくことにした。幸いにもうちの会社にはおれのと同一構成の計算機が他にもあるので、機会があればそちらで再現テストをしてみるつもりだ。

ちょっと前の話になるが、11月後半に秋葉原で開催されていたInernet Week 2009の「仮想化DAY」セッションを聞いてきた。おもしろい話はいろいろあったんだけど、もう時間もたっちゃったし、いちばん印象に残った話をひとつだけ書いておく。

Google App Engine(GAE)に関する話の中で、今年の衆院選のときにGoogleが立ち上げた「未来を選ぼう 衆院選2009」というサイト、これがGAEで構築されていたらしい。Googleのトップページからもリンクされていたのでアクセスした人も多いと思うんだが、このサイトの運用コストがピークでも月あたり1万円いかないくらいとのこと。また、GAEはアクセス数の増加に対してもシステムが自動的にスケールアウトするので、負荷が問題になることもなかったようだ。この手の、短期間にアクセスが集中して後はどんどんアクセスが低下していくようなサイトの場合に、GAEのようなクラウドサービスを選択することが、コスト的にも性能的にも最適解となり得る、というかほかの選択肢を選びようがない、もはやそういう時代なんだということを実感させられる話だった。

セッション全体としては、おれはキーバリューストアやMapReduceの実装や使い方について、より具体的な話が聞ければうれしかったんだけど、最近のInternet Weekは開発よりの話よりもインフラの話が中心になっているのでこれはしかたないかな。今回はマーケティング的な視点でとても勉強になったな。逆にダメだったのは、登壇者がちょっとしたジョークや内輪ネタをもらしたときに、身内の人間が会場に響き渡る馬鹿笑いをしていたこと。無関係の人間には迷惑なだけで、登壇者の評価も下げる愚かな行為だと思う。内輪受けもいいけど、心の中でにやりと笑う程度に、スマートに済ませてほしいよね。まあそれはそれ、全体としては楽しい時間を過ごすことができたし、来年もおもしろいセッションを見つけてぜひ参加したい。

FreeBSDネタと違って、こちらは仕事での話。会社で使ってるWindows XPにVMware Server 1.0.10(バージョン2系列はあのWeb管理画面がなんか嫌い)を入れて、仮想OSとしてRed Hat Enterprise Linux 5をインストールした。仕事でRHELに触ることはよくあるけど、自分でインストールするのは初めてなんだよね。細かい手順は飛ばすとして、トラブったところだけメモを残しておく。

その1、仮想HDDを認識しない。VMwareの標準設定で仮想HDDを作成すると、SCSIアダプタとしてBus Logicが使用されるのだが、RHEL5では認識してくれず、「インストール対象のHDDがみつからない」というエラーになってしまう。解決策は、VMwareで仮想OSを構築するときに標準設定ではなくカスタム設定(だったかな?)を選択した上で、仮想HDDのSCSIアダプタとしてLSI Logicを選択すればよい。

その2、外部ホストから仮想OSであるRHELに対してSSH接続ができない。今回、RHELはブリッジ接続でネットワークにつないでいて、RHELから外部ホストに対しては正しく通信ができるんだけど、外部ホストからRHELに対してSSH接続することができない。ちなみに、ホストOSからRHELに対しては問題なくSSH接続ができる。また、外部ホストからの接続もRHELに到達はしているみたいで、/var/log/secureには"Did not receive identification string from UNKNOWN"というsshdのログが記録されている。これらの現象から、どうやら原因はRHELの設定ではなく、VMwareのブリッジ機能、またはWindows XPのネットワークドライバのあたりにあるのではないかと推測している。この問題、現在まだ解決できていないのだが、ついさきほどみつけた情報で、同様の現象がNICのチェックサムオフロードをオフにすることで解決したという記事があったので、これで解決すれば原因の箇所は予想通りということになる。こんど出社したときにこれを試してみるつもりだ。

11月末、ついにFreeBSD 8.0-RELEASEが出たので、さっそくNB100にインストールしてみた。んが、7.2で問題なく使用できていたEMOBILE D02HWがなんかおかしい。7.2では、umassは最初に認識された後にデタッチされて後は普通にu3gモデムとして使用できるのだが、8.0ではumassのエラーが延々と出力され続ける。モデムとして正常に機能するのかどうかは試してみなかった(これは失敗、確認しておけばよかった)ので不明だが、なんか嫌なので7.2に戻しちゃったよ。あと、7.2では無線LAN(ATHEROS AR5007EG)が使えなくて、これが8.0では使えるようになっていることも期待してたんだけど、これも変わり無し。う~ん、8.0が出たらいろいろ本気出そうと思ってただけに、ちょっと残念だなあ。

最近のコメント