というのに遅ればせながら自分もtryしてみたので、駆け足でメモ。
コンセプト:Androidのソースツリーをmirrorモードでsync + そこから任意のバージョンのソースツリーをさらにsyncして、そのソースツリーをmilkodeに突っ込む。
当然、数十GB単位のディスクスペースが必要で、環境準備だけで数時間かかる(mirrorモードのsyncやmilkodeへの登録が時間かかる)。
さらに、週末やお仕事中の「ちょっとした空き時間で調べごと」をしたいだけなので、それ以外の時間はインスタンスを落としておきたい。となるとEBS(Elastic Block Storage)で永続化して必要なときだけインスタンスを上げておく使い方になる。
ということで、今回はCommunity AMIsから"099720109477/ebs/ubuntu-images/ubuntu-lucid-10.04-amd64-server-20110930"を使ってrootを8GBのubuntu 10.04 64ビット版で立ち上げ。マイクロではメモリが足りなさすぎるので、スタンダード オンデマンドインスタンスのラージモデルで立ち上げ。
躓いたところ:
Security Groupはとりあえずdefaultにして、HTTP, SSH, HTTPSを0.0.0.0から許可。
インスタンスが立ち上がったら、
sudo aptitude update sudo aptitude safe-upgrade sudo reboot
した上で、さらに次のURLを参考にパッケージ環境を調整する。
一方でAWSコンソール上からEBSで100GBのVolumeを用意して、実行中のインスタンスにattach。今回は/dev/sdfにattachした。
→ext4で初期化:
# mkfs.ext4 /dev/sdf mke2fs 1.41.11 (14-Mar-2010) /dev/sdf is entire device, not just one partition! Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 6553600 inodes, 26214400 blocks 1310720 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 800 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 24 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.
その後独自の作業用ディレクトリ "/work" にマウント。
# mkdir /work # mount /dev/sdf /work
"/etc/fstab"にも追加しておきました。
/dev/sdf /work auto defaults 0 0
"/work"のユーザとかパーミッションは、後でubuntuユーザでmkdirとか出来るように適当に調整しておく。
忘れずにsshdの設定を直しておく。
/etc/ssh/sshd_confi:
Protocol 2 ... PermitRootLogin no ... PermitEmptyPasswords no ... PasswordAuthentication no
設定したら
# service ssh restart
今回はtmuxを使うが、screenでも可。ポイントは、非常に時間がかかり場合によっては一度HTTP 401が返されたりして躓くため、tmuxやscreenでrepo syncを放置できる状態が必要。
tmuxはapt-getですんなりインストール可能。
参考:
何回もrepo syncしてると、負荷を下げるためかHTTP 401がrepo syncによるfetchingで返されるようになる。
その場合は以下のページの"Using authentication"を参考に、~/.netrcファイルを適切に設定し、repo syncを再挑戦する。
さらに今回はmirrorモードとしてrepo syncした。
$ mkdir -p /work/android/src-mirror $ cd /work/android/src-mirror $ repo init -u ... -mirror $ repo sync
mirrorのsyncが完了すれば(もしかしたら途中から401が発生して.netrcを調整したり、Networkエラーで途中でこけてまたsyncしなおしたりとあったかもしれないが)、そこから特定のbranchをrepo syncする。
$ mkdir -p /work/android/src-android-2.3.6_r1 $ cd /work/android/src-android-2.3.6_r1 $ repo init -u /work/android/src-mirror/platform/manifest.git -b android-2.3.6_r1 $ repo sync
参考:下記のURLを参考に、一部実際は変更してます。rvmのバージョンも多少変わってると思いますし・・・。
まずrvmを導入する。すいません、ruby使ってないので、1.8のバージョンがどうとか1.9がどうとか、gemの置き場所だの依存関係がどうだのとかよく分からないので手を抜きました。
rvmのインストールが完了すると、.bashrcとか.profileとかに追記が入るので、ログインしなおすなり"."で取り込むなりしておく。
続いて
$ sudo apt-get install build-essential
しておく・・・けど、多分repo sync環境の調整時に殆ど入ってるかも。milkode入れる段になって
$ sudo apt-get install libxml2 libxslt
したくらい?
あとは
$ rvm install 1.8.7 $ rvm use 1.8.7 $ gem install milkode
で終わり。
以降、ログインしなおしたら
$ rvm use 1.8.7
がおまじないとなる。
続いてmilkodeのデータベースを作る。
$ mkdir -p /work/milkdbs/src-android $ cd /work/milkdbs/src-android $ milk init $ milk add /work/android/src-android-2.3.6_r1 $ milk add /work/android/src-android-x.y.z_rN (お好みの他のバージョンツリー)
検索例:
$ milk setdb /work/milkdbs/src-android $ milk grep -a "cacerts" ...
あるいは"milk web"でWebインターフェイスを立ち上げてもOK。その場合は"-p"オプションで適宜ポートを指定した上で、AWSコンソールから"Security Groups"でそのポート番号のInboundを許可しておく設定が必要。
参考:
今回は全てAsia Pacific/Tokyoリージョンに作成した。
まずEBSから:
$0.12 設定されたストレージについて、$/GB/月 => 100GB + AMI 8GB = 108GB * $0.12 = $12.96
続いてインスタンスの使用量。
$0.40 /時 (ラージ) => 月の日曜日、半日(12hour)ほど弄る+その他の平日に業務で利用する可能性 => 12hour * 5dayとして、60hour /month => 60 * 0.40 = $24.00
合計して、
$12.96 (ESB) + $24.00 (インスタンス) = $36.96 /month
日本円だと今日のレートではおよそ
2,867円
実際のところ、スペックを度外視すれば3,000円前後のこの価格帯であれば他にもクラウドサービスあるいはVPSの候補は存在する。
今回のAWSの構成だと明らかにカゴヤ・クラウドに負ける。しかし、最終的に、2.3.6_r1と4.0.3_r1のソースツリーをmirrorから展開+milkodeに追加して33GBほど消費したので、EBSボリュームについては50GBに抑え、さらにrepo syncやソースのビルド時のみラージモデルを使用し、検索するだけであればマイクロインスタンスあるいはスモールモデルを使うように出来れば(あくまでも出来れば、の話)、
ESB: 58GB => $6.96 マイクロインスタンス: 60hour * $0.027 => $1.62 合計:$8.58 => 約665.7円
となり圧勝となる。
とはいえ、あくまでも検索だけの用途でマイクロインスタンスが利用できた場合の計算となる。メモリの使用量の都合で、検索だけでもラージモデルが必要となり、100GBをフルに使うとなるといよいよカゴヤ・クラウドが選択肢に上がる。
それ以外は全般的に実験用途としては価格・サービス内容共にオーバースペックとなっているため選択肢に入れることができない状況。
・・・まぁ、今回は単純にAmazon EC2弄ってみたかっただけなので。(^_^;)
さすがに32bitOSホスト上のVMwareからは限界を感じましたもので。64bitにしようかな。メモリ自体は4GB積んでるのに、使いきれてない・・・。