2012年6月1日金曜日

PaaSでGrailsならCloudBeesがイイ

HerokuとかCloud Foundryとか、いろんなPaaSを試してみましたが、今のところCloudBeesが良い感じだと思いました。

なお、パフォーマンスや安定性を調査したわけではなく、アプリを動かしてみたときの単純な感想です。
Jelasticなど、Javaをメインに想定したPaaSであればGrailsとの相性もいいと思うので、更に調査したいと思っています。

さて、CloudBeesですが、無料範囲だと、1アプリにつき2インスタンス、5アプリまで作れるようです。さらにビルド環境も用意してくれます。
メモリ制限がきついので本格運用するときは有料プランが必要でしょうけど、試しに始めてみるにはいいGrails実行環境なんじゃないでしょうか。

以下いいとこ雑感

Amazon EC2で動作
これはメリットデメリットあると思いますが、とりあえずMongoHQとかMongoLabとかAmazon SESとか、AWS使った豊富なサービスが使えるのが嬉しい。
例えばcloudfoundry.comとかだとそうは行かない
ビルドサーバー付き
DEV@cloudというCloudBeesのサービスでJenkinsサーバーが使えます。
ソースコードをプッシュしたら、CloudBees上のTomcatで公開するまで全自動
HerokuにもBuildpackというシステムがあって、ソースコードをプッシュしたら自動でビルドが走ってデプロイしてくれる…
が、Grailsのように依存性解決なんかでビルドに時間がかかる場合、途中でタイムアウトになってデプロイに失敗するんですよね。2回に1回くらい。
あとやっぱりJavaな人ならJenkinsが慣れてて使いやすいと思いますし
普通にTomcatにデプロイ
Grailsは大体Tomcatで動かしながら開発するのでTomcatが安心
スティッキーセッション、セッションクラスタリングに対応
クラスタリング時のセッションストアはそれなりに価格高いですけど、なんにしてもこの辺はHerokuでは使えません。
再デプロイ時にダウンタイムがない
CloudBeesはアプリケーションアップデート時、新しいクラスタでアプリを起動させてから古いアプリケーションを破棄してくれるのでダウンタイムが発生しません。
URLのGETパラメータが化けない
Cloud Foundryェ…

今のとこの気になる点

独自ドメイン対応
CloudBees上のアプリを独自ドメインで参照する場合、CNAMEでエイリアスとして設定します
普通の人は独自ドメインのルート(example.comとか)にCNAMEレコード作れないと思うので、www.example.com、とかのサブドメインを使わなければなりません。
Herokuだと普通にAレコードで設定できます。
メモリ
無料範囲だと使用できるのが最大256mで、ここからPermGenなんかを割り当てるようです。
Grailsを動かす場合256mのPermanent領域が推奨されるということですが、もちろんそんなに割り当てたら起動できなくなります。
本格的に動かすときは有料プランで

時間があったら、動かしてみた手順でも書いてみます。

2012年1月7日土曜日

Grails2.0のユニットテスト用アノテーションを整理してみる

Grails Version
2.0.0

Grails 2.0から、アノテーションを使ってユニットテストを書くことになってるのですが、
そのアノテーションの使い方が少しややこしかったので整理してみました。あんまり自信ないです。

Grailsのテストで使うアノテーションは以下のとおり。

  • grails.test.mixin.TestMixin
  • grails.test.mixin.Mock
  • grails.test.mixin.TestFor

@TestMixin

使用例
@TestMixin(GrailsUnitTestMixin)

テストクラスに以下のようなミックスインを適用して、テスト用、モック作成用のメソッドやプロパティを追加、設定するのに使用する。

リストを渡せば複数のミックスインを適用できる。

  • grails.test.mixin.support.GrailsUnitTestMixin
  • grails.test.mixin.domain.DomainClassUnitTestMixin
  • grails.test.mixin.services.ServiceUnitTestMixin
  • grails.test.mixin.web.ControllerUnitTestMixin
  • grails.test.mixin.web.FiltersUnitTestMixin
  • grails.test.mixin.web.GroovyPageUnitTestMixin
  • grails.test.mixin.web.UrlMappingsUnitTestMixin
  • grails.test.mixin.webflow/WebFlowUnitTestMixin

以下にいくつかの使用例を挙げる。

GrailsUnitTestsMixin

以下のような機能をテストクラスに追加する、全てのミックスインの基盤となるミックスイン

  • grailsApplicationやmessageSourceなどのGrailsのコンテキストプロパティを追加
  • mockForConstraintsTests、mockForなどの基本的なモック作成メソッドを追加
import grails.test.mixin.TestMixin
import grails.test.mixin.support.GrailsUnitTestMixin
import org.junit.Test

@TestMixin(GrailsUnitTestMixin)
class GenericTests {
    
    @Test
    void genericTest() {
        mockForConstraintsTests(Book)
        def book = new Book(title: "")
        assert !book.validate()
        assert book.errors["title"] == "blank"
    }
}

DomainClassUnitTestMixin

さっきの「GrailsUnitTestsMixin」を適用し、さらにドメインクラスのテスト用にmockDomainメソッドを追加する。

import grails.test.mixin.TestMixin
import grails.test.mixin.domain.DomainClassUnitTestMixin
import org.junit.Test

@TestMixin(DomainClassUnitTestMixin)
class GenericTests {
    
    @Test
    void genericTest() {
        mockDomain(Book)
        def book = new Book(title: "")
        assert !book.save()
        assert book.errors.getFieldError("title").code == "blank"
    }
}

ServiceUnitTestMixin

さっきの「GrailsUnitTestsMixin」を適用し、さらにサービスのテスト用にmockServiceメソッドを追加する。

import grails.test.mixin.TestMixin
import grails.test.mixin.services.ServiceUnitTestMixin
import org.junit.Test

@TestMixin(ServiceUnitTestMixin)
class GenericTests {
    @Test
    void genericTest() {
        mockService(HelloService)
        assert applicationContext.helloService.hello() == "Hello, World"
    }
}

ControllerUnitTestMixin

「GrailsUnitTestsMixin」を適用し、さらにコントローラーのテスト用にmockControllerメソッドやサーブレットコンテキストのモックなどを追加する。

import grails.test.mixin.TestMixin
import grails.test.mixin.web.ControllerUnitTestMixin
import grails.test.mixin.services.ServiceUnitTestMixin
import org.junit.Test

@TestMixin([ControllerUnitTestMixin, ServiceUnitTestMixin])
class GenericTests {
    @Test
    void genericTest() {
        mockService(HelloService)
        
        def controller = mockController(BookController)
        controller.show()

        assert response.text == "Hello, World"
    }
}

などなど。

@Mock

使用例
@Mock(BookController)
  • 指定クラスに応じて、適当にミックスインを適用する
  • 更に指定クラスのモックを作成してコンテキストに登録する

例えば……

  • ドメインクラスの場合: DomainClassUnitTestMixinを適用し、更に指定クラスに対してmockDomainを適用する
  • サービスクラスの場合: ServiceUnitTestMixinを適用し、更に指定クラスに対してmockServiceを適用する
  • コントローラークラスの場合: ControllerUnitTestMixinを適用し、更に指定クラスに対してmockControllerを適用する
  • などなど
import org.junit.Test
import grails.test.mixin.Mock
import org.codehaus.groovy.grails.web.servlet.GrailsApplicationAttributes

@Mock([BookController, HelloService])
class GenericTests {
    
    @Test
    void genericTest() {
        def controller = webRequest.currentRequest.getAttribute(GrailsApplicationAttributes.CONTROLLER)
        controller.show()
        assert response.text == "Hello, World"
    }
    
}

@TestFor

使用例
@TestFor(BookController)
  • 指定クラスに対して@Mock相当の機能を適用してモックを作成
  • 指定クラスのモックに、アーティファクト名のプロパティでアクセスできるようにする
  • testで始まるメソッドに、@Testアノテーションを付加

このアノテーションには、複数のクラスを引数に渡すことができない。

import grails.test.mixin.Mock
import grails.test.mixin.TestFor

@TestFor(BookController)
@Mock(HelloService)
class GenericTests {

    void testGenericTest() {
        controller.show()
        assert response.text == "Hello, World"
    }
    
}

ちなみに

Grailsのコマンド、test-appを使ってテストを実行すると、いくつかの処理を自動で行ってくれるようです。

例えば、ドメインクラスがBookで、テストクラスがBookTestsという名前だった場合、BookTestsに@TestFor(Book)が何も書かなくても適用されるように見えます。

この辺の動作はまだよく分かりません。

おわりに

もっぱら使用するのは@TestForと@Mockであって、@TestMixinで直接テストメソッドをミックスインすることはあまりないと思いますが、大体こんな役割になってそう、ということです。

動作確認はしましたが、ソースはあまり追っていないので間違ってるところもあるかもしれません。

気がついたことなどありましたら、教えてもらえると幸いです。

2011年12月16日金曜日

ConfluenceのHTML→PDF変換ライブラリを利用する

JIRA Advent Calendar 2011、15日目です。

ってすみません、ConfluenceネタですがまあJIRA使ってる人は連携して使ったりしますよねとか、そんな感じで。
GradleのユーザーガイドPDFに変換するときにお世話になったので、紹介してみます。

Confluenceは、バンドルされているプラグインでページをPDFに変換して出力できるのですが、この機能に使われているライブラリを使って、XHTMLをPDFに変換しようという話です。

ConfluenceのXHTML→PDF処理にはFlying SaucerというJavaのライブラリが使われています。
Flying Saucerを使うと、XMLやXHTMLファイルを、PDFやSWT、Swingのスクリーンに出力させることができます。デザインはCSSで指定できます。

ただ、このFlying Saucer、PDFに変換したときに、文字列が空白位置でしか改行されません。
英文Onlyならいいのですが、日本語で長文をだらだら書いていると画面外にあふれて見えなくなってしまうわけですね。
ConflueceのPDFエクスポートでの禁則 - azuki note

この問題を、Atlassianさんがパッチを当てて修正しているので、しかもMavenリポジトリ上に上げてくれているので、今回はそれを使います。

@Grape+Groovyスクリプトでもいいですが、いろいろ面倒なのでGradleスクリプトで。

フルのサンプルはGithubに上げたのでそちらを見てもらうとして、ポイントだけ書いておきます。

変換元のHTMLとCSSのサンプル

AtlassianさんのMavenリポジトリからFlying Saucerを取得

AtlassianさんのMavenリポジトリから、パッチの当たったFlying Saucerライブラリを取得します。
GradleとかMavenとかIvyとか、そのあたりの設定に依存関係を追加するのがいいですね。

ライセンスが気になるところですが、LGPLのままみたいなので大丈夫でしょう、多分…

Mavenリポジトリ
https://maven.atlassian.com/repository/public
アーティファクト
org.xhtmlrenderer:xhtmlrenderer:8.3-atlassian

Flying SaucerはPDF生成にiTextを使うのでそちらも

Mavenリポジトリ
セントラルリポジトリ
アーティファクト
com.lowagie:itext:2.0.8
// Gradleの例
buildscript {
    repositories {
        mavenCentral()
        mavenRepo url: "https://maven.atlassian.com/repository/public"
    }
    dependencies {
        classpath "org.xhtmlrenderer:xhtmlrenderer:8.3-atlassian"
        classpath "com.lowagie:itext:2.0.8"
    }
}

PDFへの変換処理

PDFへの変換処理は、次のような感じで書きます。

import org.xhtmlrenderer.pdf.ITextRenderer

def renderer = new ITextRenderer()
renderer.setDocument(new File("sample.html"))
renderer.layout()
new File("sample.pdf").withOutputStream {
    renderer.createPDF(it)
}

このコードを実行すれば、sample.htmlがsample.pdfに変換されます。

CSSでPDFに埋め込むフォントを指定する

日本語を使うには日本語フォントをPDFに埋め込むか参照させる必要があります。変換元のHTMLに次のようなCSSを適用しましょう。

@font-face{
    font-family: "IPAexGothic";
    src: url(ipaexg.ttf);
    -fs-pdf-font-embed: embed;
    -fs-pdf-font-encoding: Identity-H;
}

body {
    font-family: "IPAexGothic";
}

なんか、使えるフォントと使えないフォントがあるみたいです。

fsなんたらはFlying Saucerのベンダー拡張ですね。詳しくはFlying Saucerのユーザーガイドを見てみてください。

長い文章を折り返すための設定

Atlassianさんのパッチが当たったFlying Saucerを使うと、次のようにCSSでword-wrapを指定することで長い文章が折り返されるようになります。

p {
    word-wrap: break-word;  
}

おわりに

いやぁ、便利ですね。ちょっとしたPDF作るだけなら、それ用のHTMLファイル作って変換するのが簡単かもしれません。

さて、かなり脱線気味でしたが、こんなところで。
引き続きJIRA Advent Calendar 2011をお楽しみください。

2011年12月6日火曜日

GrailsのプラグインリポジトリとしてGithubを使う

G* Advent Calendar、6日目いってみます。
今日を境に、公開Grailsプラグインの数が爆発的に増える……といいなーという感じで

Grails version
2.0.0.RC1

Grailsプラグインのリポジトリには、Maven形式のリポジトリが使用できます。

つまり、MavenのリモートリポジトリをGithub上に構築する以下の手法を使えば、GraisプラグインのリポジトリをGithub上に持てるわけですね。
Github を Maven 公開リポジトリにする
GitHub を Maven 公開リポジトリにする (Gradle 編)

何ができるの?

例えば、私はGrailsのAWSプラグインにパッチを当てたものをGithub上に公開しています。1

このプラグインは、次のようにしてどこからでも使用できます。

// grails-app/conf/BuildConfig.groovy
// ...
grails.project.dependency.resolution = {
    // ...
    repositories {
        grailsPlugins()
        grailsHome()
        grailsCentral()

        // ...
        // Github上のマイプラグインリポジトリを指定
        mavenRepo "http://literalice.github.com/maven-repo/releases"
    }
}

# 上で指定したプラグインリポジトリからプラグインをインストール
cd grails-project
grails install-plugin aws 1.2.12.1.p1

とまあ、このように、改造したり開発したりした非公式オリジナルプラグインを簡単に公開して使えるようにしちゃおうというのが目的です。

GrailsのプラグインはzipファイルのURLを指定してインストールできるので他にいくらでも方法はあるわけですが、不特定多数に公開して良いなら今のところこれが一番手軽なんじゃないかなぁと。

この記事は、私がAWSプラグインを改造して公開したときの手順を思い出しながら書いていますが、オリジナルのプラグインを公開するときも同じような感じです。

以下がその手順です。

プラグインのソースコードを入手する

  • Github上にあるプラグインのソースコードをフォークして、手元にクローン
  • grails create-plugin コマンドでプラグインプロジェクトを作成する
  • などなど

プラグインのバージョン番号を更新する

既存のプラグインを改造する場合は、バージョン番号がオリジナルのものと被らないように変更しておいた方が良いでしょう。1.0.0.p1、といった風に適当なサフィックスを付けておきます。

    // XXGrailsPlugin.groovy - プラグインディスクリプタ
    // ..
    def version  = "1.0.0.p1"
    // ..

GrailsのReleaseプラグインをインストールする

プラグインのビルド、リポジトリへの公開は、このReleaseプラグインを使います。

Grails2系のcreate-pluginでプラグインプロジェクトを作成した場合は既にプロジェクトにインストールされているかと思いますが、そうでなければ自分でインストールする必要があります。

install-pluginコマンドでインストールせず、必ずBuildConfig.groovy上でプラグインを追加してexport設定を追加します。そうでないと、このマイプラグインをインストールしたときに、インストール先のプロジェクトもreleaseプラグインに推移的に依存するようになってしまいますので。

ちなみにAWSプラグインはinstall-pluginでreleaseプラグインをインストールしていたようなので、改造版ではこちらも修正しています。

// grails-app/conf/BuildConfig.groovy
// ...
grails.project.dependency.resolution = {
    // ...
    plugins {
        // ...
        build(':release:1.0.0.RC3') {
            export = false // このプラグインはインストール先のプロジェクトには不要
        }
    }
}

プラグインをがしかし実装

プラグインをオレオレに改造します。がしかし好きな機能を実装します。

Github上にMavenリポジトリを構築する

好きな機能は実装できましたか? ではプラグインを公開しましょう。

Github を Maven 公開リポジトリにする
を参考に、MavenリポジトリをGithub上に構築します。

おおざっぱに言えば、

  1. ローカルにフォルダを作ります(「D:\mvn」など)。
  2. そのフォルダをgitのリポジトリとして初期化します。
  3. そのリポジトリに「gh-pages」という名前のブランチを作ります。
  4. 作った「gh-pages」ブランチをgithubにプッシュします
  5. おわり

後は、このフォルダにMavenリポジトリ構造でファイルを追加してプッシュすれば、Github上にそのファイルを公開できるわけですね

ここでは、「D:\mvn」にgitのリポジトリを作ったものとします。

ローカルフォルダにGrailsプラグインをリリースする

先ほどgitリポジトリとして初期化したフォルダ「D:\mvn」にプラグインをリリースします。

Grailsのreleaseプラグインは、SubversionリポジトリやリモートのWebDAV Mavenリポジトリにプラグインをリリースできますが、ローカルにはき出すことも可能なようです。

リリース先の指定方法はreleaseプラグインのマニュアルに載っています。

プロジェクトのBuildConfig.groovyか、ユーザーのホームディレクトリにsettings.groovyというファイルを置いて設定することができます。

バージョン管理に入れるであろうBuildConfig.groovyに、ローカルのファイルパスを書き込むというのはダサい気がするので、私はsettings.groovyを使いました。以下のように設定します。

// ~/.grails/settings.groovy
grails.release.scm.enabled = false // プラグインのソースコードはリリースしない

grails.project.repos.default = "localRelease" // リリース先未指定時のリリース先
grails.project.repos.localRelease.url = "file:///D:/mvn" // リリース先"localRelease"のURL

設定が終わったら、プラグインのプロジェクトディレクトリに移動して、リリースコマンドを実行します。2

cd my-grails-plugin
grails publish-plugin

コマンドが正常に終了すれば、「D:\mvn」にプラグインのzipファイル、pomファイルなどが生成されているはずです。3

MavenリポジトリをGithubにプッシュ

「D:\mvn」に生成された全てのファイルをコミットし、github上にプッシュします。

これで、作成したプラグインをどこからでも使用できるようになりました。

公開したプラグインを使う

公開したプラグインは、前述のように「BuildConfig.groovy」にGithub上のプラグインリポジトリを追加すれば使用できます。

リポジトリのURLは、Githubユーザー名が「literalice」、プッシュしたMavenリポジトリのフォルダ名が「mvn」であれば、「http://literalice.github.com/mvn」となります。

// grails-app/conf/BuildConfig.groovy
// ...
grails.project.dependency.resolution = {
    // ...
    repositories {
        // ...
        // Github上のマイプラグインリポジトリを指定
        mavenRepo "http://literalice.github.com/mvn"
    }
}

# 上で指定したプラグインリポジトリからプラグインをインストール
cd grails-project
grails install-plugin myplugin 1.0.0.p1

Twitterとかで通知

使って欲しい人に向けて、プラグインのリリース情報を通知します。プラグインリポジトリのURLとプラグイン名、プラグインバージョンを教えてあげれば大丈夫なはず。

まとめ

これでもう、プラグインのバグ修正も機能追加も待つ必要ないですね。直して公開です。

わざわざGrailsの公式リポジトリにプラグインを公開する必要もないですね。プラグイン名とリポジトリのURLを一緒に教えてあげれば大丈夫です。

気が向きましたら、本家にpull requestとか、プラグインを公式リポジトリに公開とかするとよりナイスですね。

Githubの最大容量は300MBらしいですが、普通のプラグインはそんなに容量大きくならないので大丈夫じゃないでしょうか、多分。

G* Advent Calendar、7日目は@masanobuimaiさんです。



注1: AWSプラグインは、GrailsからAmazon Web Serviceを簡単に使えるようにするものですが、SESでメールを送信するときに文字セットを指定できなかったためパッチを当てて使っています。

注2: 本来であれば、

cd my-grails-plugin
grails publish-plugin --repository=localRelease
とすることで、リリース先を明示的に指定できるはずなのですが、私の環境ですと上手く動かなかったので、デフォルトのリリース先をsettings.groovyで設定して、リリース先を指定せずにリリースできるようにしています。

注3: 「WARNING: unknown protocol 'file' for repository」というワーニングが出るのが気になりますが…とりあえず、問題なくリリースできるようです。

2011年11月28日月曜日

Load the JQuery Library via CDN with Grails Resources Plugin

Grails version
2.0.0.RC1
Resources Plugin version
1.1.1

You can use the jquery library on existing CDN networks with Grails Resources Plugin in this way.

// grails-app/conf/XXResources.groovy
modules = {
    // Defines JQuery's CDN network
    overrides {
        def jqueryVersion = org.codehaus.groovy.grails.plugins.jquery.JQueryConfig.SHIPPED_VERSION
        'jquery' {
            resource id:'js',
                     linkOverride:"http://ajax.googleapis.com/ajax/libs/jquery/${jqueryVersion}/jquery.min.js"
        }
    }
}

Note: The resources plugin load a resource via 'linkOverride' url only when it is not in debugging mode.
see also: Grails Resources Plugin: Debbugging

2011年11月25日金曜日

Cloud Foundry上のMongoDBに既存データを流し込む

Cloud Foundryは、VMWare社が開発しているPaaS環境です。現在、クラウド上でβ試験中の環境が無料で試用できます。

GrailsなどのWebフレームワーク、MongoDB、MySQL、Redis等々、様々なサービスを起動して使用できるようです。

基本的な使い方はこちらを見ていただくとして、
http://d.hatena.ne.jp/y-kawaz/20110425/1303708958
http://support.cloudfoundry.com/entries/20054091-vmware-cloud-foundry-getting-started-japanese

Cloud Foundryでは「vmc」というCLIが提供されていて、これでアプリのデプロイやらを行うわけですが、
これに最近追加された「tunnel」というサブコマンドで、このPaaS上のMongoDBに既存データを流し込めるらしいので試してみました。

今回は、mongodumpで既存データをバックアップし、mongorestoreでCloudFoundry上のMongoDBにデータを流し込みます。
これらのツールの使い方は、こちらの記事がわかりやすいです。
http://d.hatena.ne.jp/rougeref/20110325

流し込むデータファイルは、前もってmongodumpでダンプしておいたものとします。

vmc tunnelって?

vmc tunnelを使うと、あたかもローカルのポート10000番で動作しているMongoDBに接続しているかのように、CloudFoundry上のMongoDBに接続できます。
ローカル環境から、


mongo localhost:10000 --username xxx --password xxx

という感じでCloudFoundry上のmonogodに接続して操作できるようになるわけですね。

詳しくは、以下でわかりやすく図解してくださっています。
http://blog.udcp.net/2011/11/22/vmc-tunnel/

今回の作業も、すべて上記の記事を見ながら行いました。

vmcのインストール

Cloud Foundry上のアプリケーションやMongoDBなどのサービスの操作は、vmcというRubyGemのツールで行います。

こちらを参考に、次のように必要なgemを入れます。


gem install vmc --pre
gem install caldecott

ちなみに、64ビット版のWindows7上だとネイティブライブラリのコンパイル時にエラーになってインストールできませんでした。

エラーメッセージ見る限り、64ビット版のWindowsには対応していないように感じましたが、特に深く追求する気もないのでVMWare上のCentOSで実行することにします。

ネイティブライブラリ依存は将来的に取り除かれる予定らしいので、それに期待しておきましょう。
http://blog.cloudfoundry.com/post/12928974099/now-you-can-tunnel-into-any-cloud-foundry-data-service

Rubyが入っていないときは、最近はRVMでインストールするのがナウいらしいので、この辺を参考にしていれましょう。
https://rvm.beginrescueend.com/
http://d.hatena.ne.jp/mirakui/20100502/1272849327

MongoDBのインストール

前述の通り、CloudFoundry上のmongodには、ローカルから

mongo localhost:10000 --username xxx --password xxx
って感じで接続します。つまり、ローカル上にmongoクライアントをインストールする必要があるはず。

mongoのインストール方法はこちら。公式がyumリポジトリを提供してくれており、インストールは異様に簡単です。
http://www.mongodb.org/display/DOCS/CentOS+and+Fedora+Packages

現在CloudFoundry上で稼働しているMongoDBはバージョン1.8.1なので、合わせた方が良いかもしれません。
私は既に2.0.1を入れてしまっていたのでソレを使いました。今回の作業では特に問題は起きてません。

vmc tunnelの実行

http://blog.udcp.net/2011/11/22/vmc-tunnel/に書かれているとおりにvmc tunnelを実行します。

% vmc tunnel
1: mongodb-ea00999
2: redis-8dcyyyy
Which service to tunnel to?: 1
Password: ***********
Getting tunnel connection info: OK

Service connection info:
  username : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  password : yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
  name     : db

Starting tunnel to mongodb-ea00999 on port 10000.
1: none
2: mongo
Which client would you like to start?: 1
Open another shell to run command-line clients or
use a UI tool to connect using the displayed information.
Press Ctrl-C to exit...

最後に「2」を選べば、さっきインストールしたローカルのmongoシェルが勝手に起動して、CloudFoundry上のmongodにつなぎに行ってくれます

今回はmongoのインタラクティブシェルには用はないので、「1」を選んで待機させておきます。

これで、ローカルのポート10000番を通して、CloudFoundry上のMongoDBに接続できるようになりました。

mongorestoreの実行

ターミナルをもう一つ立ち上げて、mongorestoreを実行します。

接続情報は、vmc tunnel実行時に表示されるので、待機中のターミナルをみれば載っているでしょう。

Service connection info:
  username : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  password : yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
  name     : db

CloudFoundry上のMongoDBへの接続情報を確認したら、mongorestoreを実行してデータを流し込みます。

流し込むデータファイルは、前もってmongodumpでダンプしておきます。

mongorestore -h localhost:10000 -d db(上で確認した「name」) -c book(ダンプしたコレクション名) \
  -u (上で確認したユーザー名) -p (上で確認したパスワード) --drop \
  dump/db/book.bson(mongodumpで取得したダンプファイル)

これで、MongoDB上へデータが流し込まれているはず。

mongoシェルなどでデータを確認したら、待機させておいたvmc tunnelを終了させて完了です。

既存のデータでCloud Foundryを試してみたい、運用してみたい、といった場合もこれで何とかなりそうですね。

2011年7月14日木曜日

JQueryUI Theme in Grails Resources Plugin

Grails version : 1.3.7
Resources Plugin version : 1.0

Resources PluginとJQuery UI Pluginと使っているときに、JQuery UIのカスタムThemeを指定する方法が分からなかったのですが、
以下のようにすることで今のところ正常に動いています。

conf/XXResources.groovy (Resources configuration file)
modules = {
  overrides {
    'jquery-theme' {
      // location of a jquery theme css
      resource id:'theme', url:'/jquery-ui/themes/cupertino/jquery-ui-1.8.11.custom.css'
    }
  }
}