Java開発者のためのcloud-foundry講座【Part 4 SPRING PROFILES編】

USING CLOUD FOUNDRY SERVICES WITH SPRING: PART 4 – SPRING PROFILES(意訳)

(Posted on November 10th, 2011 by Scott Andrews in 3.1Cloud ComputingCloud Foundry.)

Spring 3.1に重要な新機能が追加されました。新しい環境用APIでアプリケーションへのプロパティ設定を容易にしたり、条件に応じてフラグが付いている設定を有効にします。 このシリーズの一番最初のブログにCloud Foundryはデータベース接続に関する設定を手動ではなく、自動で設定し接続できることが書かれていましたが、このプロセスをもう少しハンドリングしなければならない状況、例えば、アプリケションが複数のデータベースサービスを利用しなければならない場合などは<cloud>ネームスペースの方法を使います。この方法はDataSourceの定義をXMLに一行追加するだけで利用できます 。<cloud>ネームスペースは非常にパワフルな方法ですが、アプリケーションがCloud Foundry上で動かすときしか利用できません。ある意味、この 方法はコンフィグレーションがCloud Foundryに依存したものになってしまいます。 Cloud Foundry以外で展開するときは、このコンフィグレーションは無効とすべきです。 このため、Cloud Foundryへのアプリケーションの展開を考えると<cloud>ネームスペースの場合、ローカル環境での単体テストを行うことはできません。単体テストなしに、いきなり統合テストのためアプリケーションをCloud Foundry上に展開することは受け入れ難いことです。この問題をSpring Profileは解決することができます。

Spring Profileとは、コンフィグレーションにフラグを付け、ある条件に合致したときのみこのフラブ部分に記述されたコンフィグレーションが有効になります。 ほとんどのアプリケーションプラットフォームでは、開発、テスト及び本番用のコンフィグレーションがそれぞれ存在し、環境に応じて使い分けされますが、このプロファイル(Spring Profile)を使うことによりコンフィグレーションに柔軟性を持たせることができます 。設定されたプロファイルのすべての条件に合致しなかった場合、”default”のプロファイルとなり、そこに記述されたコンフィグレーションが有効になります。このプロファイルは環境の違いによってコンフィグレーションをスワップし、または、アプリケーションのオプション機能の設定を行うことができます。使い方は開発者の思いのままに利用することができます。

ISOLATING CLOUD FOUNDRY SPECIFIC CONFIGURATION

SpringアプリケーションがCloud Foundry上に展開するときは自動的に”cloud”のプロファイルが有効になります。展開する場所に依存せずにCloud Foundryに固有なコンフィグレーションを予め定義することができるので便利です。<cloud>ネームスペース固有のコンフィグレーションは”cloud”のプロファイルのブロック以内に定義することでCloud Foundryでなくてもアプリケーションを動作させることができます。

<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
    <constructor-arg ref="mongoDbFactory" />
</bean>
<beans profile="default">
    <mongo:db-factory id="mongoDbFactory" dbname="pwdtest" host="127.0.0.1" port="27017" username="test_user" password="efgh" />
</beans>
<beans profile="cloud">
    <cloud:mongo-db-factory id="mongoDbFactory" />
</beans>

上記のサンプルコンフィグレーションは、Spring MongoTemplateのコンフィグレーションをConnection Factoryとして二者択一の環境で使えるように設定したものです。cloud foundry上で動作するときはConnection Factoryは自動的に設定され、cloud foundry上でない場合はローカル上にMongoDBインスタンスが存在し、接続のためのコンフィグレーションは手動で設定します。

ENABLING AN APPLICATION FEATURE ON CLOUD FOUNDRY

ここで共通した一つの課題、「cloud foundry上のアプリケーションからのメール送信」について考えてみましょう。残念ながら、SPAMメールの防止、その他の悪用を防ぐ理由のためCloud Foundry上のアプリケーションからのSMTPはブロックされます。しかしながら、HTTP Webサービス経由でSendGridのようなサービスプロバイダーを利用することでCloud Foundry上のアプリケーションからメールを送信ことはできます。通常、使っているデータセンター上ではSMTP Serverを使い、Cloud Foundry上ではHTTP Webサービス経由でSendGridサービスを利用することを考えると、以下のようなにプロファイルでSendGridサービスと接続するためのBeanを定義できます。

<beans profile="cloud">
 <bean name="mailSender" class="example.SendGridMailSender">
 <property name="apiUser" value="youremail@domain.com" />
 <property name="apiKey" value="secureSecret" />
 </bean>
</beans>

CLOUD PROPERTIES

Cloud Propertiesはアプリケーションに直接関係を持つプロパティで、Spring プロパティ・プレイスホルダーに対応することで利用することができます。これらのプロパティはアプリケーションの基本的な情報に関するもので、プロパティ名、クラウドプロバイダ名、アプリケーションにすべてのサービスをバイディングするためのコネクション情報などがあります。

<beans profile="cloud">
    <bean id="c3p0DataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
        <property name="driverClass" value="com.mysql.jdbc.Driver" />
        <property name="jdbcUrl" value="jdbc:mysql://${cloud.services.mysql.connection.host}:${cloud.services.mysql.connection.port}/${cloud.services.mysql.connection.name}" />
        <property name="user" value="${cloud.services.mysql.connection.username}" />
        <property name="password" value="${cloud.services.mysql.connection.password}" />
    </bean>
</beans>

上記の例は、一般的なサービスプロパティで”cloud.services.{service-name}.connection.{property}”のフォームで利用します。このコネクション・プロパティの仕様はサービスタイプによって異なります。利便性のため、アプリケーションにバイディングする一つのサービスタイプの場合、エイリアスはサービス名の代わりにサービスタイプ名をベースとして作成されます。MySQLサービスの場合、”cloud.services.mysql.connection.{property}”のフォームを使います。

AVAILABLE  TODAY,AUTOMAGICALLY

Cloud Profile及びPropertiesと共に、SpringアプリケーションとしてCloud Foundry上で動作するときに有効になります。この場合、Spring 3.1以降が必須となります。我々のゴールは、必要最小限の作業でCloud Foundry上にアプリケーションが動作するための無理ないパスを作ることです。最も重要なことは、開発環境ごとに手動で設定することなく、Springアプリケーションとして最大限のポータビリティ性を確保することです。


本ブログの記事は、Using Cloud Foundry Services with Spring: Part 4 – Spring Profilesの意訳であり、完全な翻訳ではございません。所々、翻訳を省略しているところや、原本にはない文を追加しているところもございます。また、翻訳の正確性が欠ける可能性もございますので、原文にも目を通すことを推奨いたします。ご了承ください。

広告

Java開発者のためのcloud-foundry講座【Part 3 THE NAMESPACE編】

USING CLOUD FOUNDRY SERVICES WITH SPRING: PART 3 – THE <cloud>NAMESPACE(意訳)

(Posted on November 9th, 2011 by Thomas Risberg in 3.1Cloud ComputingCloud FoundryData Access,JavaOpen SourceSpringSpring Data)

前回の投稿したブログUSING CLOUD FOUNDRY SERVICES WITH SPRING: PART 2 – AUTO-RECONFIGURATIONで、Springアプリケーションをデプロイするとき、使われているデータサービスを検出し、自動的にアプリケーションがクラウドサービスが利用できるように再設定いたします。デモとかサンプルアプリケーションなどに利用するには、この上ない素晴らしい機能ですが、本番のアプリケーションなのでは、多分、いくつか自分たち制御したくなるところが増えてくるでしょう。最も、同じタイプのサービス複数利用する場合は自分たちで制御してやらなければなりません。Ramnivas が書いた前回のブログのなかで、いくつかヒントになることが書かれている訳ですが、そこにはCloudRedisConnectionFactoryBean、CloudMongoDbFactoryBeanなどのようなCloud Factory Service Beanを使う場合は、auto-reconfiguration機能を使用しない選択を行うことができます。その選択の方法として一番簡単なものは、利用しようとするサービス定義に<cloud> ネームスペースを用いることです。本ブログではこのネームスペースについてもう少し詳しく説明いたします。

<cloud>ネームスペースが含まれているアプリケーション

アプリケーションのビルド時に、org.cloudfoundry:cloudfoundry-runtimeをディペンデンシー(dependency)として含める必要があります。ビルドにMavenを使っているなら 次のようにpom.xmlのディペンデンシー(dependency)に追加します。

<dependencies>
    <dependency>
        <groupId>org.cloudfoundry</groupId>
        <artifactId>cloudfoundry-runtime</artifactId>
        <version>0.8.1</version>
    </dependency>

    <!-- additional dependency declarations -->
</dependencies>

また、次のようにpom.xmlにSpring Framework Milestone Repositoryを持たせる必要がありますが、単純にこのrepository宣言に追加するだけです。

<repositories>
    <repository>
        <id>org.springframework.maven.milestone</id>
        <name>Spring Framework Maven Milestone Repository</name>
        <url>http://maven.springframework.org/milestone</url>
    </repository>

    <!-- additional repository declarations -->
</repositories>

今、この状態でアプリケーションコンテキストファイルに ネームスペースを記述できるようになりました。実際に、下記の例のようにアプリケーションコンテキストファイルに記述してみます。まず、5行目にネームスペースの宣言を行い、次に8行目にスキーマのロケーションが記述します。10行目で最初の ネームスペース・エレメントを使った定義がされています。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:context="http://www.springframework.org/schema/context"
  xmlns:cloud="http://schema.cloudfoundry.org/spring"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd
    http://schema.cloudfoundry.org/spring http://schema.cloudfoundry.org/spring/cloudfoundry-spring-0.8.xsd">

    <cloud:mongo-db-factory id="mongoDbFactory">

    <bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
        <constructor-arg ref="mongoDbFactory"/>
    </bean>

    <!-- more beans for your app -->

</beans>

このブログでは、すべての有効なネームスペースエレメント及びそれらのオプション設定について説明いたします。

有効なネームスペースエレメント

<cloud:data-source>

<cloud:data-source>エレメントはSpringアプリケーションでJDBC DataSourceの設定をするときに利用できます。次に基本的な属性を説明します。

  • id – デフォルトのサービス名
  • service-name – 複数のデータベースサービスをアプリケーションに接続させるときに必要になります。

JdbcTemplateを注入したDataSourceのシンプルな設定例を下記に示します。このようにdatasource beanをidの属性として指定します。

<cloud:data-source id="dataSource" />

<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
  <property name="dataSource" ref="dataSource" />
</bean>

サブ・エレメントでコネクション及びプールの設定を行うことができます。<cloud:data-source> ネームスペースエレメントは、最も一般的な設定項目をオプションとして<cloud:connection> 及び<cloud:pool> のサブ・エレメントで定義できます。以下の表にサポートされるオプションを説明します。

<cloud:connection> options

Namespace attribute Description Type
properties コネクションに関する項目で、新しいコネクションが確立するときに、JDBCドライバへ送られる。 string

<cloud:pool> options

Namespace attribute Description Type Default
pool-size プールの最大のコネクション数もしくは最小と最大をダッシュで分離する表現がされる範囲 int デフォルトの設定でアパッチコモンズプールを用い、最小0接続と最大8接続が設定されます。
max-wait-time プールの最大接続待ち時間(ミリ秒)、−1のexceptionエラー発生する前に、接続応答が返ってくるまでの最大待ち時間 int デフォルトでアパッチコモンズプールを使い、無制限(-1)の設定がされている。

付加的なオプションが追加されたDataSourceの設定例を以下に示します。

<cloud:data-source id="mydatasource">
    <cloud:connection properties="charset=utf-8;" />
    <cloud:pool pool-size="5-10" max-wait-time="2000" />
</cloud:data-source>

 <cloud:mongo-db-factory>

この <cloud:mongo-db-factory>エレメントは、SpringアプリケーションがMongoDB Connection Factoryに関する設定を行うときに利用されます。次に基本的な属性を説明します。

  • id – デフォルトのサービス名
  • service-name – 複数のMongoDBサービスをアプリケーションに接続させるときに必要になります。
  • write-concern – このWriteConcernはすべてのDBコネクションが作成されたときに使われます(NONE, NORMAL, SAFE, FSYNC_SAFE)。DBコネクションに何もWriteConcernが設定されていない場合は、デフォルトNORMALが設定されます。

write-concernの属性値は、有効な値をcom.mongodb.WriteConcernクラスに持ちます。

Value Description
NONE exceptionの発生及びネットワークの異常も関与しない。
NORMAL ネットワークに関するexceptionは関与するが、サーバのエラーに関する問題は関与しない
SAFE ネットワークに関するexceptionは関与し、サーバのオペレーション待ちに関する問題のみ関与しない
FSYNC_SAFE ネットワークに関するexceptionは関与し、サーバのエラーに関する問題及びデータをディスクにフラッシュする書込みオペレーション待ちに関する問題も関与する

MongoTemplateを注入したMongoDbFactoryのシンプルな設定例を下記に示します。このようにMongoDbFactory beanをidの属性として指定します。

<cloud:mongo-db-factory id="mongoDbFactory" />

<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
    <constructor-arg ref="mongoDbFactory"/>
</bean>

<cloud:mongo-options>のサブ・エレメントの属性として使われるアドバンスな設定を以下の表に示します。

<cloud:mongo-options>

Namespace attribute Description Type Default
connections-per-host 一つのMongoインスタンスに対する最大許容コネクション数。これらのコネクションはプールとして接続を保たれ、コネクションがすべて消費されるとコネクションを要求するオペレーションはブロックされる int Mongoドライバでデフォルト10の値
max-wait-time 一つのスレッドにおけるプールの最大接続待ち時間(ミリ秒) int Mongoドライバでデフォルト120000の値

付加的なオプションが追加されたMongoDbFactoryの設定例を以下に示します。

<cloud:mongo-db-factory id="mongoDbFactory" write-concern="FSYNC_SAFE">
    <cloud:mongo-options connections-per-host="10" max-wait-time="2000" />
</cloud:mongo-db-factory>

<cloud:redis-connection-factory>

この <cloud:redis-connection-factory>エレメントは、SpringアプリケーションがRedis Connection Factoryに関する設定を行うときに利用されます。次に基本的な属性を説明します。

  • id – デフォルトのサービス名
  • service-name – 複数のRedisサービスをアプリケーションに接続させるときに必要になります。

RedisTemplateを注入したRedisConnectionFactoryのシンプルな設定例を下記に示します。このようにRedisConnectionFactory beanをidの属性として指定します。

<cloud:redis-connection-factory id="redisConnectionFactory" />

<bean id="redisTemplate" class="org.springframework.data.redis.core.StringRedisTemplate">
    <property name="connection-factory" ref="redisConnectionFactory"/>
</bean>

<cloud:pool>のサブ・エレメントの属性として使われるアドバンスな設定を以下の表に示します。

<cloud:pool> options

Namespace attribute Description Type Default
pool-size プールの最大のコネクション数もしくは最小と最大をダッシュで分離する表現がされる範囲 int デフォルトの設定でアパッチコモンズプールを用い、最小0接続と最大8接続が設定されます。
max-wait-time プールの最大接続待ち時間(ミリ秒)、−1のexceptionエラー発生する前に、接続応答が返ってくるまでの最大待ち時間 int デフォルトでアパッチコモンズプールを使い、無制限(-1)の設定がされている。

付加的なオプションが追加されたRedisConnectionFactoryの設定例を以下に示します。

<<cloud:redis-connection-factory id="myRedisConnectionFactory">
    <cloud:pool pool-size="5-10" max-wait-time="2000" />
</cloud:redis-connection-factory>

<cloud:rabbit-connection-factory>

この <cloud:redis-connection-factory>エレメントは、SpringアプリケーションがRabbit Connection Factoryに関する設定を行うときに利用されます。次に基本的な属性を説明します。

  • id – デフォルトのサービス名
  • service-name – 複数のRabbitサービスをアプリケーションに接続させるときに必要になります。

RabbitTemplateを注入したRabbitConnectionFactoryのシンプルな設定例を下記に示します。このようにRabbitConnectionFactory beanをidの属性として指定し、<rabbit> のネームスペースに<Cloud>一つを追加した形となります。

<cloud:rabbit-connection-factory id="rabbitConnectionFactory" />

<rabbit:template id="rabbitTemplate"
    connection-factory="rabbitConnectionFactory" />

<cloud:rabbit-options>のサブ・エレメントの属性として使われるアドバンスな設定を以下の表に示します。

<cloud:rabbit-options>

Namespace attribute Description Type Default
channel-cache-size 一つのチャネルで利用されるキャッシュサイズ int デフォルト1の値

付加的なオプションが追加されたRabbitConnectionFactoryの設定例を以下に示します。

<cloud:rabbit-connection-factory id="myRedisConnectionFactory">
    <cloud:rabbit-options channel-cache-size="10" />
</cloud:rabbit-connection-factory>

<cloud:service-scan>

<cloud:service-scan>は、アプリケーションにバイディングされているすべてのサービスをスキャンし、各々のサービスに対し、妥当なBeanタイプを作成します。このエレメントは、Springコアの<context:component-scan>をクラウド用に拡張したものと考えることができます。<cloud:service-scan>は特にアプリケーションの初期の開発フェーズに使うと便利だと思います。新規にサービスをバイディングさせたいときに、<cloud>エレメントをあらたに継ぎ足すことなく、手っ取り早くサービスへアクセスするためのbeanを作成することができます。

@Autowired DataSource dataSource;
@Autowired ConnectionFactory rabbitConnectionFactory;
@Autowired RedisConnectionFactory redisConnectionFactory;
@Autowired MongoDbFactory mongoDbFactory;

一度、<context:component-scan>エレメントをアプリケーションコンテキストに含めるだけで、後は、下記の例のように、Javaコードに各々バイディングしたいサービスに@Autowiredのアノテーションを単純に付加するだけです。 ただ、上記のやり方だと一つのサービスのみに対してそれぞれのタイプでアプリケーションにバイディングする定義になりますが、それ以外、下記のように@Qualifierのアノテーションを使いサービス名を別途、指定することができます。(ここで記述したサービス名で自動的にbeanを作成します。)

@Autowired @Qualifier("inventory-db") DataSource inventoryDataSource;
@Autowired @Qualifier("pricing-db") DataSource pricingDataSource;

ここの例だと、inventoryDataSource BeanとしてInventory-dbサービスにバイディングされ、PriceingDataSource BeanとしてPricing-dbサービスにバイディングします。

<cloud:properties>

有効となる属性を説明します。
  • id – デフォルトのプロパティbean名

この<cloud:properties>エレメントは、Springがサポートしているプレイスホルダープロパティを使ってサービスの基本情報が設定できます。このプロパティフォームについては次回のブログで詳しく説明します。

結論

クラウド・ネームスペースは、クラウドサービスに接続するための簡単な仕組みとしてサポートしています。開発者はローカルなtc/tomcat server、ローカルなクラウド、そしてcloudfoundry.comと同じようにデプロイしたい欲求にかられます。Spring 3.1 profileは、このような欲求に対してテイラーメイドな方法でサポートします。この方法ついてはScott Andrews が次回のブログで説明します。


本ブログの記事は、USING CLOUD FOUNDRY SERVICES WITH SPRING: PART 3 – THE <CLOUD> NAMESPACEの意訳であり、完全な翻訳ではございません。所々、翻訳を省略しているところや、原本にはない文を追加しているところもございます。また、翻訳の正確性が欠ける可能性もございますので、原文にも目を通すことを推奨いたします。ご了承ください。

Java開発者のためのcloud-foundry講座【Part 2 AUTO-RECONFIGURATION編】

USING CLOUD FOUNDRY SERVICES WITH SPRING: PART 2 – AUTO-RECONFIGURATION(意訳)

(Posted on November 4th, 2011 by Ramnivas Laddad in Cloud ComputingCloud FoundrySpringSpring Data)

Cloud Foundry launch eventのビデオをご覧になればわかると思いますが、Spring Web FlowのサンプルからSpring TravelをダウンロードしてきたWebアプリケーションをEclipseベースの開発ツールSTSに展開し、Cloud FoundryプラグインからMySQLサービスをアプリケーションにバイディングし、ドラック&ドロップでCloud Foundryサーバへデプロイする。これでCloud Foudry上へのアプリケーションの配布が終了。ダウンロードしたSpring Travelアプリケーションには、何一つ、一行たりとも変更を行っていません。では、ローカルのデータベースを使用するためにコンフィグレーションされたアプリケーションの設定はCloud Foudry上へ配布するときにはどうなったのだろうか? 実はこのタイミングでauto-reconfiguration機能が関与します。Cloud Foundryは、1ドルでも1セントでも初期の投資コストを低く抑えるために常に努力し続けていますが、実際のところ投資言うものは、開発者がどれだけ時間を費やしたかに依存します。そのような意味で、このauto-reconfigurationは、Cloud Foundryで開発をはじめるにあたり、開発者の費やす時間を短縮し、初期の投資コストを削減するための機能と言えます。 このブログでは、SpringアプリケーションをCloud Foundryへ展開する際に、auto-reconfigurationがどのように機能しているかを説明したいと思います。

DI機能を活かした AUTO-RECONFIGURATION

アプリケーションがビジネスロジックから構成され、データベースあるいはメッセージングなどのサービスと連携されている場合、典型的なSpringアプリケーションとしてDI(Dependcy Injection)フレームワークの恩恵を受けることができます。典型的なSpringアプリケーションがリレーショナルデータベースを使用する場合、次のようなデータソースのbean定義がされます。直接、auto-reconfigurationの仕組みには関係はないのですが、データベースのアクセスに必要な認証情報、ユーザ名、パスワードを別ファイルとして外出しすることができます。

<bean class="org.apache.commons.dbcp.BasicDataSource" id="dataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
    <property name="url" value="jdbc:mysql://localhost:3306/inventory-db"/>
    <property name="username" value="myuser"/>
    <property name="password" value="mypass"/>
</bean>

下記のbean定義は、他のbeanへの依存注入(JPA entity managerへの依存注入の例)を記述しています。

<bean class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" id="entityManagerFactory">
    <property name="persistenceUnitName" value="persistenceUnit"/>
    <property name="dataSource" ref="dataSource"/>
</bean>

上記の見方は簡単です。データベースのURLはlocalhost上に存在し、ユーザ名に”myuser”、パスワードに”mypass”が設定されます。アプリケーションをCloudFoundry上に展開し、MySQLもしくはPostgresサービスをバインドするとJDBCのURLが”jdbc:mysql://localhost:3306/inventory-db”、ユーザ名が”myuser”、パスワードが”mypass”に設定が適用できなくなります。このまま状態ではアプリケーションのスタートアップが失敗してしまいます。ここでauto-reconfiguration機能が関与いたします。auto-reconfigurationはDI機能を活かした仕組みで、Spring アプリケーション・コンテキストファイルを参照し、サービスと通信するbeanを検索し、CloudFoundry上でアプリケーションにバイディングするサービスをベースとした新たなBeanに置き換えることをいたします。この結果、アプリケーション開発者はローカルで展開したコンフィグレーションのまま、CloudFoundry上にアプリケーションを展開できます。
以下の表は、auto-reconfiguration機能が置換え対象となるBeanタイプ(マッチングタイプのBean)を示します。

Service Type Replaced bean type
Mysql, Postgres javax.sql.DataSource
Redis org.springframework.data.redis.connection.RedisConnectionFactory
MongoDB org.springframework.data.document.mongodb.MongoDbFactory
RabbitMQ org.springframework.amqp.rabbit.connection.ConnectionFactory

auto-reconfiguration機能を支援するための内部的な仕組みとしてBeanFactoryPostProcessorを利用いたします。このBeanFactoryPostProcessorはBeanを作成する前に、アプリケーションコンテキストファイルを調査し、アプリケーションにバイディングするサービスをベースしたBeanとそれとマッチしたタイプの既存Beanをスワップいたします。また、リレーショナルデータベースの場合、使用されている方言的な違いも調整するためにJPA entity manager factory もしくはHibernate session factoryに再構成いたします。

Cloud Foundryへのアプリケーションのデプロイメント過程において、アプリケーションがステージングされているときに、CloudFoundryは、以下の二つの変更を実施いたします。

  1. デプロイするアプリケーションにBeanFactoryPostProcessorと付加的なリソースを含んだjarファイルを追加します。ここで注目すべきは、このjarファイルにauto-reconfigurationで使われるcloudfoundry-runtimeの特定バージョンも含まれていることです。共有機能によって、変更が必要な特定のjavaクラスは別のパッケージに置換えられます。このことから違うcloudfoundry-runtimeのバージョンを使用しているアプリケーションをデプロイしたとしてもコンフリクトを起こすことはありません。
  2. 次にSpring アプリケーション・コンテキストに BeanFactoryPostProcessorを追加したかたちにするため、web.xmlに書換えを行います。

制限事項

Auto-reconfiguration機能は、以下の条件でのみ有効となります。

  1. 与えられたサービスタイプから一つのサービスだけのとき有効になります。例えば、アプリケーションが一つのリレーショナルデータベースサービス(MySQLもしくはPostgres)だけをバイディングするとき。
  2. マッチングタイプのbeanから一つのbeanだけのとき有効になります。例えば、Spring アプリケーション・コンテキストが一つのデータソースbeanだけを使っているとき。

AUTO-RECONFIGURATION機能を使わない選択

これからAuto-reconfiguration機能使わない選択をすべき状況をいくつかご説明します。例えば、アプリケーションがCloudFoundryのサービスにないインメモリデータベースを使っている場合など、Cloud Foundryは、いくつかAuto-reconfiguration機能使わない選択の方法を提供します。

  1. Spring frameworkを使ったSpringアプリケーションでない”JavaWeb”のアプリケーションをCloudFoundry上にデプロイするとき、このときはAuto-reconfiguration機能は有効でなくなり、アプリケーションの変更も行われません(アプリケーションにJarファイルも付加されず、web.xmlの書換えもありません)。ここでprofile機能と関わるところがあるのですが、改めて後のブログで説明いたします。
  2. サービスを定義するbeanに<cloud> のエレメントが使われている場合。現状では、<cloud:data-source>、<cloud:mongo-db-factory>、<cloud:rabbit-connection-factory>、<cloud:redis-connection-factory>及び<cloud:service-scan>があります。これらのネームスペースエレメントをベースとしたBeanがアプリケーションに含まれていた場合、Auto-reconfiguration機能は適用外となります。アプリケーションにAuto-reconfiguration機能の振舞を持たせたいか、あるいは、サービス生成の単純な制御を完全に持たせたいかによって、Cloud Foundryはこの機能を適用しない選択を行うことができます。

結論

Cloud FoundryのAuto-reconfiguration機能は、はじめのころのアプリケーション開発には素晴らしい機能ですが、同時に複数のサービスを利用するなどアプリケーションが成熟すると、アプリケーション側で、きめ細かくサービスのオブジェクト接続を制御してやる必要があります。ここで<cloud>ネームスペースの話がでましたが、次のブログでThomas Risbergが紹介いたします。


本ブログの記事は、USING CLOUD FOUNDRY SERVICES WITH SPRING: PART 2 – AUTO-RECONFIGURATIONの意訳であり、完全な翻訳ではございません。所々、翻訳を省略しているところや、原本にはない文を追加しているところもございます。また、翻訳の正確性が欠ける可能性もございますので、原文にも目を通すことを推奨いたします。ご了承ください。

Java開発者のためのCloud Foundry講座【Part 1 基本編】

USING CLOUD FOUNDRY SERVICES WITH SPRING: PART 1 – THE BASICS(意訳)

(Posted on October 13th, 2011 by Ramnivas Laddad in Cloud ComputingCloud FoundrySpring.)

開発者は、CloudFoundryが提供するPostgres,MongoDB及びRabittMQなどのアプリケーションサービスを使ったアプリケーションをCloudFoundry上で効率的に構築することができます。ローカルの開発環境で行う煩わしいミドルウェアのインストール、設定作業を気にせずに、開発者はアプリケーションサービスを選択し、利用することができます。例えば、クルーシャルなトランザクションアクセスを必要としているアプリケーションの場合は、Postgresを選択し、ドキュメント形式のデータを扱う場合には、MongoDBのサービスを選択でき、開発を勧めることができます。今回、ご紹介する4回のブログ連載で、SpringアプリケーションがCloud Foundryで提供しているPostgres,MongoDB及びRabittMQなどアプリケーションサービスをどのように利用することができるのかご説明いたします。今回のPart1(Ramnivas Laddad著)で、CloudFoundryがアプリケーションサービスの環境情報をどのようにアプリケーションに提供しているのかご紹介します。次回のPart2Ramnivas Laddad著)では、典型的なSpringアプリケーションが、auto-reconfiguration機能を使ってパラメータの再設定なしにアプリケーションサービスをどのように利用することができるかを説明し、Part3Thomas Risberg著)では、クラウドサービスを明示的に制御するためのクラウド・ネームスペースの使い方。Part4Scott Andrews著)では、Spring 3.1の新機能であるプロファイルとクラウド・ネームスペースを組み合わせて使うことで、パラメータ変更することなしにローカルで開発したアプリケーションをPaaSクラウドへ展開する方法をご紹介いたします。

PostgresあるいはMongoDBなどのCloud Foundryサービスをアプリケーションがバインディングする場合、バインディングに必要な情報、例えば、バインディングされるCloud Foundryサービスのホストネーム、ポート番号、クリデンシャルなど情報は、JSON形式にエンコーディングされた環境変数として存在します。下記のコードは、Cloud Foundryサービスの環境変数を表示するシンプルなWebアプリケーションです。このアプリケーションは、Spring MVCテンプレートプロジェクトを使い、HomeControllerソースコードにエンドポイントとしてコードを追加いたしました。(このアプリケーションはgithubに公開されています。)

@RequestMapping("/env")
public void env(HttpServletResponse response) throws IOException {
    response.setContentType("text/plain");
    PrintWriter out = response.getWriter();
    out.println("System Environment:");
    for (Map.Entry<String, String> envvar : System.getenv().entrySet()) {
        out.println(envvar.getKey() + ": " + envvar.getValue());
    }
}

では、実際にこのアプリケーションをCloudFoundry上にデプロイしてみましょう。CloudFoundryプラグインが有効になっているSTSでも使えるのですが、今回はvmcツールを使うことにします。アプリケーション名を”env-hello”としてベースとなるデフォルトのURLをそのまま使うことにします(hello-env.clouddounry.com)。アプリケーション名をこの記事の通り使いたい場合は、Micro Cloud Foundryへアプリケーションをデプロイしてください。

$ vmc push hello-env -n
Creating Application: OK
Uploading Application:
Checking for available resources: OK
Processing resources: OK
Packing application: OK
Uploading (8K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK

ここで、 ”http://hello-env.cloudfoundry.com/env”にブラウザのURLをナビゲートすると、1ページ全体にすべての環境変数を参照することができます。

VCAP_SERVICES: {}

何もサービスがバイディングされていない状態では、上記のように変数が空のマップが表示(JSON形式)されます。それでは実際にPostgresサービスを作成し、アプリケーション名を”env-postgresql”としてこのアプリケーションにバイディングしてみましょう。ここでvmcツールを使い下記のようにvmc create-serviceコマンドでサービスを作成いたします。

$ vmc create-service postgresql env-postgresql hello-env
Creating Service: OK
Binding Service: OK
Stopping Application: OK
Staging Application: OK
Starting Application: OK

もう一度、”http://hello-env.cloudfoundry.com/env”にブラウザのURLをナビゲートします。すると下記のようにVCAP_SERVICESの環境変数がJSON形式で表示されます。

{
    "postgresql-9.0": [{
        "name": "env-postgresql",
        "label": "postgresql-9.0",
        "plan": "free",
        "credentials": {
            "name": "de24667f9344b4eeaad6b5a2326d52faa",
            "host": "172.30.48.122",
            "hostname": "172.30.48.122",
            "port": 5432,
            "user": "u50ce600bba434bacbc99e034bb415644",
            "username": "u50ce600bba434bacbc99e034bb415644",
            "password": "pf4dca5bd449d4732841f0c4ae3f299d0"
        }
    }]
}

ここでは、アプリケーションが接続するに必要なすべての情報、ホスト名、ポート番号、作成されるJDBC URL名、更に接続に必要なユーザ名とパスワードが表示されます。(注意:将来バージョンではホスト名は省略される予定)
今度は、その他、MongoDBのサービスをバインディングしてみましょう。以下のようにvmcツールのコマンドを実行します。

$ vmc create-service mongodb env-mongodb hello-env

同様にブラウザを使って環境変数を参照します。

{
    "mongodb-1.8": [{
        "name": "env-mongodb",
        "label": "mongodb-1.8",
        "plan": "free",
        "tags": ["mongodb", "mongodb-1.8", "nosql"],
        "credentials": {
            "hostname": "172.30.48.68",
            "host": "172.30.48.68",
            "port": 25026,
            "username": "b8b312a0-9b43-4104-90f8-52f2ac8bc7c6",
            "password": "6a62732d-f820-4690-9bab-d1c85af13323",
            "name": "416e990a-6f81-46f9-abaa-1233a11ca5d6",
            "db": "db"
        }
    }],
    "postgresql-9.0": [{
        "name": "env-postgresql",
        "label": "postgresql-9.0",
        "plan": "free",
        "credentials": {
            "name": "de24667f9344b4eeaad6b5a2326d52faa",
            "host": "172.30.48.122",
            "hostname": "172.30.48.122",
            "port": 5432,
            "user": "u50ce600bba434bacbc99e034bb415644",
            "username": "u50ce600bba434bacbc99e034bb415644",
            "password": "pf4dca5bd449d4732841f0c4ae3f299d0"
        }
    }]
}

ここでも、MongoDBへ接続するに必要なすべての情報を参照することができます。このようにCloudFoundryでは、アプリケーションがアプリケーションサービスを利用するために必要な情報を取得することができます。この環境変数にアクセスするためには、環境変数をJSON形式でパーシングし、その結果を格納するアクセスオブジェクト(RDBならDataSourceなどのオブジェクト)作成するだけで、何かここで特別むずかしいことをやらせている訳ではありません。従って、CloudFoundryは、シンプルな設定でアプリケーションサービスに接続することができる仕組みを提供しています。

次回は、典型的なSpringアプリケーションが、auto-reconfiguration機能を使ってパラメータの再設定なしにアプリケーションサービスをどのように利用することができるかを説明いたします。


本ブログの記事は、USING CLOUD FOUNDRY SERVICES WITH SPRING: PART 1 – THE BASICSの意訳であり、完全な翻訳ではございません。所々、翻訳を省略しているところや、原本にはない文を追加しているところもございます。読み辛さを感じるところが多いと思いますが、ご了承ください。