19 デプロイ - Reference Documentation
Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith
Version: 2.4.0.M1
Translated by: T.Yamamoto, Japanese Grails Doc Translating Team. Special thanks to NTT Software.
【注意】このドキュメントの内容はスナップショットバージョンを元に*意訳*されているため、一部現行バージョンでは未対応の機能もあります。
19 デプロイ
Grails applications can be deployed in a number of ways, each of which has its pros and cons.
Grailsアプリケーションはいくつかの方法でデプロイが可能です。
なお、それぞれのデプロイ方法には利点、欠点があります。"grails run-app"
You should be very familiar with this approach by now, since it is the most common method of running an application during the development phase. An embedded Tomcat server is launched that loads the web application from the development sources, thus allowing it to pick up an changes to application files.
開発中の間は上記コマンドによってアプリケーションを起動させる事が一般的な手法となります。
コマンド実行により、Grailsに同梱されているTomcatサーバが起動され、ソースコードが読み込まれます。ファイル変更時も再起動を実施せず、内容が反映されます。This approach is not recommended at all for production deployment because the performance is poor. Checking for and loading changes places a sizable overhead on the server. Having said that,
なお、本コマンドでのデプロイはパフォーマンスが悪いため、本番環境での導入は推奨しておりません。Grailsアーテファクト(GSPやコントローラ)のソースファイルの変更を監視していて、変更されたらリコンパイル・リロードが行われる為です。grails prod run-app removes the per-request overhead and lets you fine tune how frequently the regular check takes place.grails prod run-appコマンドを利用することで上記処理を実施しないようにする事ができ、更新検出のオーバーヘッドをなくす事が出来ます。Setting the system property "disable.auto.recompile" to
また、起動オプションでtrue disables this regular check completely, while the property "recompile.frequency" controls the frequency. This latter property should be set to the number of seconds you want between each check. The default is currently 3.disable.auto.recompile=trueを指定する事で再コンパイルを無効にする事ができます。
また、recompile.frequencyという起動オプションで構文のチェック頻度を指定できます。チェック頻度は数字(秒)で指定します。なお、本値のデフォルト値は3秒です。"grails run-war"
This is very similar to the previous option, but Tomcat runs against the packaged WAR file rather than the development sources. Hot-reloading is disabled, so you get good performance without the hassle of having to deploy the WAR file elsewhere.
先ほどのコマンドと似ていますが、grails run-appではTomcatサーバがソースコードを読み込んで動作するのに対して、grails run-warではWARファイルを利用して動作します。
このコマンドによる起動では自動再読み込みが実施されず、WARファイルの面倒なデプロイをする必要もなく、高いパフォーマンスでの実行が可能です。h3. WAR file
WARファイル
When it comes down to it, current java infrastructures almost mandate that web applications are deployed as WAR files, so this is by far the most common approach to Grails application deployment in production. Creating a WAR file is as simple as executing the war command:
現在のJavaによって動作するWebアプリケーションの大半はWARファイルによってデプロイされており、Grailsにおいても最も一般的な方法となります。
WARファイルの作成はシンプルな war コマンドの実行で可能です。grails war
There are also many ways in which you can customise the WAR file that is created. For example, you can specify a path (either absolute or relative) to the command that instructs it where to place the file and what name to give it:
WARファイル作成時にいくつかの条件指定が可能です。
例えば、ファイル名称及びファイル出力先を相対パスもしくは絶対パスで指定する事が可能です。grails war /opt/java/tomcat-5.5.24/foobar.war
Alternatively, you can add a line to
また、grails-app/conf/BuildConfig.groovy that changes the default location and filename:grails-app/conf/BuildConfig.groovyに以下の行を追加する事でデフォルトのファイル名称及びファイル出力先を指定する事が出来ます。grails.project.war.file = "foobar-prod.war"Any command line argument that you provide overrides this setting.
設定はコマンドライン引数によって上書きを行う事が出来ます。It is also possible to control what libraries are included in the WAR file, for example to avoid conflicts with libraries in a shared directory. The default behavior is to include in the WAR file all libraries required by Grails, plus any libraries contained in plugin "lib" directories, plus any libraries contained in the application's "lib" directory. As an alternative to the default behavior you can explicitly specify the complete list of libraries to include in the WAR file by setting the property
WARファイルにどのライブラリを含めるかを指定する事ができ、ライブラリの競合を避ける事などができます。 デフォルトの状態では、Grailsに必要な全てのライブラリ、プラグインの "lib" ディレクトリに含まれるライブラリ、アプリケーションの "lib" ディレクトリに含まれるライブラリがWARファイルに含まれます。 デフォルトの動作を変更する場合は、BuildConfigでgrails.war.dependencies in BuildConfig.groovy to either lists of Ant include patterns or closures containing AntBuilder syntax. Closures are invoked from within an Ant "copy" step, so only elements like "fileset" can be included, whereas each item in a pattern list is included. Any closure or pattern assigned to the latter property will be included in addition to grails.war.dependencies.grails.war.dependenciesプロパティにAntでインクルードするパターンのリストを設定するか、またはAntBuilder構文で記述したクロージャを設定することで、明示的にWARファイルに含めるライブラリを指定することができます。クロージャはAntの"copy"の処理の中から実行され、インクルードするパターンのリストを指定する"fileset"のみを含むことができます。なお、複数のクロージャ、パターンが指定された場合には末尾に指定されたものが有効化の対象となります。Be careful with these properties: if any of the libraries Grails depends on are missing, the application will almost certainly fail. Here is an example that includes a small subset of the standard Grails dependencies:
grails.war.dependenciesを指定する場合、Grailsの動作に必要なライブラリ群がない場合にはアプリケーションの起動に失敗するので注意して下さい。
以下にGrailsに最低限必要なライブラリ群を含める場合の記述例について示します。def deps = [
"hibernate3.jar",
"groovy-all-*.jar",
"standard-${servletVersion}.jar",
"jstl-${servletVersion}.jar",
"oscache-*.jar",
"commons-logging-*.jar",
"sitemesh-*.jar",
"spring-*.jar",
"log4j-*.jar",
"ognl-*.jar",
"commons-*.jar",
"xstream-1.2.1.jar",
"xpp3_min-1.1.3.4.O.jar" ]grails.war.dependencies = {
fileset(dir: "libs") {
for (pattern in deps) {
include(name: pattern)
}
}
}This example only exists to demonstrate the syntax for the properties. If you attempt to use it as is in your own application, the application will probably not work. You can find a list of dependencies required by Grails in the "dependencies.txt" file in the root directory of the unpacked distribution. You can also find a list of the default dependencies included in WAR generation in the "War.groovy" script - see the
上記記述例はデモ用となっており、あなたが作成したアプリケーションに適用すると起動ができなくなると思われます。
Grailsの動作に必要なライブラリ群については、Grails本体のルートディレクトリ配下に存在する "dependecies.txt" で確認できます。
DEFAULT_DEPS and DEFAULT_J5_DEPS variables.Grails2.2.0ではdependencies.txtが無くなっています。
JIRAに記載の通り、War.groovyには「DEFAULT_DEPS」及び「DEFAULT_J5_DEPS」の値が存在しません。本家英語ドキュメントの更新が行われていないため、上記内容に該当する箇所は未翻訳としております。
The remaining two configuration options available to you are
grails.war.copyToWebApp and grails.war.resources. The first of these lets you customise what files are included in the WAR file from the "web-app" directory. The second lets you do any extra processing you want before the WAR file is finally created.grails.war.copyToWebApp、grails.war.resourcesのプロパティに関する説明が残っています。grails.war.copyToWebAppではWARファイル作成時に "web-app" ディレクトリ配下のどのファイルを含めるかを指定する事が出来ます。grails.war.resourcesではWARファイル作成前に実施したい追加処理を記述する事が出来ます。// This closure is passed the command line arguments used to start the
// war process.grails.war.copyToWebApp = { args ->
fileset(dir:"web-app") {
include(name: "js/**")
include(name: "css/**")
include(name: "WEB-INF/**")
}
}// This closure is passed the location of the staging directory that
// is zipped up to make the WAR file, and the command line arguments.
// Here we override the standard web.xml with our own.
grails.war.resources = { stagingDir, args ->
copy(file: "grails-app/conf/custom-web.xml",
tofile: "${stagingDir}/WEB-INF/web.xml")
}// このクロージャにはWARファイル作成時のコマンドライン引数が渡されます。
grails.war.copyToWebApp = { args ->
fileset(dir:"web-app") {
include(name: "js/**")
include(name: "css/**")
include(name: "WEB-INF/**")
}
}// このクロージャにはWARファイルがZIP圧縮されるステージング環境のパスとコマンドライン引数が渡されます。
// 本例では標準のweb.xmlをあなたの作成したファイルで上書きします。
grails.war.resources = { stagingDir, args ->
copy(file: "grails-app/conf/custom-web.xml",
tofile: "${stagingDir}/WEB-INF/web.xml")
}h2. Application servers
アプリケーションサーバ
Ideally you should be able to simply drop a WAR file created by Grails into any application server and it should work straight away. However, things are rarely ever this simple. The Grails website contains an up-to-date list of application servers that Grails has been tested with, along with any additional steps required to get a Grails WAR file working.
通常では作成したWARファイルは各アプリケーションサーバに配置するというシンプルな操作のみで動作可能となります。
なお、各アプリケーションサーバの最新確認状況及び、WARファイルを動作させるための詳細な手順についてはGrails website を参照下さい。