情報畑でつかまえてロゴ
本サイトは NTTテクノロスが旬の IT をキーワードに
IT 部門が今知っておきたい最新テクノロジーに関する情報をお届けするサイトです

中野靖治のGroovy活用術 第6回

Grailsのプロファイル機能で社内向けにアプリケーションのひな形を共有する

今回は、2016/01/28にリリースされたGrails 3.1で追加された「独自プロファイル」機能を使って、社内向けにアプリケーションのひな形を共有する方法について紹介します。

Grailsのプロファイル機能で社内向けにアプリケーションのひな形を共有する

はじめに

こんにちは。NTTソフトウェアの中野です。振り返ってみると、ここまで5回連続「Grails〜」というタイトルでやってきていましたが、空気を読まずに引き続きGrailsネタでお送りします。今回は、2016/01/28にリリースされたGrails 3.1で追加された「独自プロファイル」機能を使って、社内向けにアプリケーションのひな形を共有する方法について紹介します。

プロファイルとは?

Grailsにおける「プロファイル」とは、「アプリケーション構築のためのひな形・設定・コマンド等を含めた一式」のことを指します。Mavenで言う「アーキタイプ(archetype)」のようなイメージですが、開発用のコマンドも含まれているなど、一回りリッチな感じです。

プロファイル機能自体は、Grails 3.0から導入されました。Grailsアプリケーションを新規作成するときに明示的にプロファイルを指定することで、従来の画一的なWebアプリとは異なる構成のアプリケーションも開発できるようになりました。

$ grails create-app --profile=web myapp

Grails 2.xの時と同じように--profileを省略すると、デフォルトであるwebプロファイルが指定されたことになります。

$ grails create-app myapp

なお、Springにおける「プロファイル」という用語は、開発・テスト・運用環境などに対してそれぞれのコンフィギュレーションを個別にカスタマイズするための機能を指します。SpringベースであるGrailsで、同じ「プロファイル」という用語を「アプリケーション構築のためのひな形・設定・コマンド等を含めた一式」を表すために使ってしまうのは、混乱を助長するという意味で個人的にはもやもやしたものを感じますが、すでにこれはこれで定着しつつあるのであきらめて受け入れましょう。ちなみに、Springの「プロファイル」的な機能は、Grailsでは「環境(environment)」と呼んでいます。

標準プロファイルの品揃え

Grails 3.0のリリース当初は以下のような品揃えでした。

$ grails list-profiles
| Available Profiles
--------------------
* base - The base profile extended by other profiles
* plugin - Profile for plugins designed to work across all profiles
* web - Profile for Web applications
* web-micro - Profile for creating Micro Service applications run as Groovy scripts
* web-plugin - Profile for Plugins designed for Web applications

baseプロファイルは他のプロファイルのベースとなる特殊なプロファイルです。

Grails 3.1では以下のプロファイルが標準で提供されています。

$ grails list-profiles
| Available Profiles
--------------------
* angular - A profile for creating applications using AngularJS
* rest-api - Profile for Web API applications
* base - The base profile extended by other profiles
* plugin - Profile for plugins designed to work across all profiles
* web - Profile for Web applications
* web-plugin - Profile for Plugins designed for Web applications

見世物としての意味が強かったweb-microプロファイルが削除されて、代わりにRESTなWeb APIサーバ向けのrest-apiプロファイルと、フロントエンドにAngularJSを利用するangularプロファイルが追加されています。なお、angularプロファイルが対応しているAngularJSのバージョンは1.x系です。そろそろ2.0がリリースされようかとしている段階なので、タイミング的には若干微妙ですね。

3.1で何が変わったのか?

独自のプロファイルを作成して、JARファイルにしてMavenリポジトリに公開して共有できるようになりました。これによって、ついに、プラグイン化するまでもない or プラグイン化できなかったような細かいノウハウを形式化して共有できるようになった訳です。

シンプルな独自プロファイルを作成する

プロファイルプロジェクトの生成

create-profileコマンドで独自プロファイルが作成できます。

$ grails create-profile myweb
| Application created at /xxxx/myweb
$ cd myweb
$ tree
.
├── build.gradle
├── commands
├── gradle.properties
├── profile.yml
├── skeleton
│   └── grails-app
│       ├── conf
│       │   └── application.yml
│       ├── controllers
│       ├── domain
│       ├── init
│       └── services
└── templates
9 directories, 4 files


派生元プロファイルの変更

初期状態ではbaseプロファイルからの派生プロファイルになっています。今回はwebプロファイルを独自にカスタマイズしたいという想定で、build.gradleを以下のように変更しましょう。

//...
dependencies {
//runtime "org.grails.profiles:base:${project.grailsVersion}"
runtime "org.grails.profiles:web:${project.grailsVersion}"
}


ロギング設定

さて、独自プロファイルの第一歩として、ロギングの設定を仕込んでみます。ほとんどの場合、アプリケーションを新規作成するたびに毎回手を入れる必要があるので、プロファイルであらかじめよしなにしておけば、かなり楽になりそうです。

作成したばかりのプロファイルにはlogback.groovyが存在していないので、skelton/grails-app/conf/logback.groovyとして以下の内容でファイルを新規作成します。

import grails.util.Environment
// // Appenders //
def FILE_LOG_PATTERN = '%d{yyyy-MM-dd HH:mm:ss.SSS}\t%thread\t%level\t%logger:%line\t%m%n' def CONSOLE_LOG_PATTERN = /%d{HH:mm:ss.SSS} [%thread] %highlight(%level) %cyan(\(%logger{39}:%line\)) %m%n/
def logDir = 'logs'
appender('STDOUT', ConsoleAppender) { withJansi = true encoder(PatternLayoutEncoder) { pattern = CONSOLE_LOG_PATTERN } }
appender("FILE", RollingFileAppender) { encoder(PatternLayoutEncoder) { pattern = FILE_LOG_PATTERN } rollingPolicy(TimeBasedRollingPolicy) { fileNamePattern = "${logDir}/application.%d{yyyy-MM-dd}.log" } }
appender("FULL_STACKTRACE", RollingFileAppender) { encoder(PatternLayoutEncoder) { pattern = FILE_LOG_PATTERN } rollingPolicy(TimeBasedRollingPolicy) { fileNamePattern = "${logDir}/stacktrace.%d{yyyy-MM-dd}.log" } }

// // Helpers //
def error = { logger it, ERROR, ['STDOUT', 'FILE'], false } def warn = { logger it, WARN, ['STDOUT', 'FILE'], false } def info = { logger it, INFO, ['STDOUT', 'FILE'], false } def debug = { logger it, DEBUG, ['STDOUT', 'FILE'], false } def trace = { logger it, TRACE, ['STDOUT', 'FILE'], false }

// // Configurations //
root INFO, ['STDOUT', 'FILE']
logger "StackTrace", ERROR, ['FULL_STACKTRACE'], false
Environment.executeForCurrentEnvironment { development { debug '@grails.codegen.defaultPackage@' debug 'grails.app.controllers.@grails.codegen.defaultPackage@' trace 'org.hibernate.type.descriptor.sql.BasicBinder' trace 'org.hibernate.type.EnumType' debug 'org.hibernate.SQL' debug 'groovy.sql.Sql' } test { debug '@grails.codegen.defaultPackage@' debug 'grails.app.controllers.@grails.codegen.defaultPackage@' trace 'org.hibernate.type.descriptor.sql.BasicBinder' trace 'org.hibernate.type.EnumType' debug 'org.hibernate.SQL' debug 'groovy.sql.Sql' } }

独自プロファイルを利用してみる

利用する前に、プロファイルをビルドしたJARファイルを、アクセス可能なMavenリポジトリに公開します。とりあえず個人的に試すだけであればローカルMavenリポジトリ(.m2/repository)で十分です。

以下のコマンドを実行して、ビルドしたJARファイルをローカルMavenリポジトリにインストールしましょう(実行にはGradleがインストールされている必要があります)。

$ gradle install

それでは使ってみましょう。

$ grails create-app --profile=myweb myapp

独自プロファイルに追加したlogback.groovyが展開されているかどうか確認してみると...

$ cat myapp/grails-app/conf/logback.groovy | head
import grails.util.Environment
// // Appenders //
def FILE_LOG_PATTERN = '%d{yyyy-MM-dd HH:mm:ss.SSS}\t%thread\t%level\t%logger:%line\t%m%n' def CONSOLE_LOG_PATTERN = /%d{HH:mm:ss.SSS} [%thread] %highlight(%level) %cyan(\(%logger{39}:%line\)) %m%n/
def logDir = 'logs'

期待通り反映されていますね。

プロファイルを社内で共有する

前述したとおり、生成したJARファイルを社内のMavenリポジトリで共有すればOKです。既存のMavenリポジトリへの公開方法は以下のURLを参照してください。

Mavenリポジトリの構築方法などはここでは触れません。

(おまけ)再利用におけるプロファイルとプラグインの使い分け

Grails 2.xまでは、再利用可能なものはプラグイン化しよう、という方針でした。独自プロファイルの作成が可能となった今、再利用方法として独自プロファイルにするのか、従来通り独自プラグインにするのか、どのように使い分ければ良いでしょうか?

ひとつのポイントとしては、独立した一つの機能としてカプセル化できるかどうか、があります。Yesであれば、より再利用性の高いプラグイン化を検討しましょう。

プロファイルが便利なのは、書き換えを前提としつつ、各種ひな形や設定を含んだゆるいアプリケーション全体像を共有するような場面です。

  • 既存のファイルや設定の変更
  • いつも使うプラグインセットの追加
  • 機能的にわかりやすくひとくくりにはできない何らかのカスタマイズ

余談ですが、プロファイル自体の開発で地味につらい点としては、統合開発環境(IDE)のサポートがまだ追いついていないところです。Grails開発において大変便利で人気のあるIntelliJ IDEAというIDEを使っても、プロファイルのプロジェクト構成は認識されないため、プロファイルプロジェクト上で込み入った開発をする場合にIDEの恩恵にあずかることができません。

おわりに

今後の展開として、以下のようなカスタマイズを施せば、ゼロからアプリケーションを構築するスピードがより一層向上しますね。

  • よく使う必須プラグインをインストールする
  • HTMLやCSSなどのビューテンプレートをカスタマイズする
  • i18nメッセージをカスタマイズする
  • データソースをよく使うRDBMSに差し替える
  • 更に認証・認可対応プロファイルを派生させる(spring-security-coreプラグインを利用)

参考URL

連載シリーズ
中野靖治のGroovy活用術
著者プロフィール
中野 靖治

ソフトウェア生産技術センター Grails推進室(GGAO)

中野 靖治