Spring Boot アプリケーションのインストール

java -jar を直接使用して Spring Boot アプリケーションを実行するだけでなく、systemdinit.d、または Windows サービスとして実行することもできます。

systemd サービスとしてのインストール

systemd は System V init システムの後継であり、現在多くの最新の Linux ディストリビューションで使用されています。Spring Boot アプリケーションは、systemd の「サービス」スクリプトを使用して起動できます。

/var/myapp に uber jar としてパッケージ化された Spring Boot アプリケーションがあると仮定して、それを systemd サービスとしてインストールするには、myapp.service という名前のスクリプトを作成し、/etc/systemd/system ディレクトリに配置します。次のスクリプトは例を示しています。

[Unit]
Description=myapp
After=syslog.target network.target

[Service]
User=myapp
Group=myapp

Type=exec
ExecStart=/path/to/java/home/bin/java -jar /var/myapp/myapp.jar
WorkingDirectory=/var/myapp
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target
アプリケーションの DescriptionUserGroupExecStartWorkingDirectory フィールドを変更することを忘れないでください。
ExecStart フィールドは、スクリプトアクションコマンドを宣言しません。これは、run コマンドがデフォルトで使用されることを意味します。

アプリケーションを実行するユーザー、PID ファイル、コンソールログファイルは systemd 自体によって管理されるため、「サービス」スクリプト内の適切なフィールドを使用して構成する必要があります。詳細については、サービスユニット設定のマニュアルページ (英語) を参照してください。

システムの起動時に自動的に起動するようにアプリケーションにフラグを付けるには、次のコマンドを使用します。

$ systemctl enable myapp.service

詳細については、man systemctl を実行してください。

init.d サービスとしてのインストール (システム V)

アプリケーションを init.d サービスとして使用するには、完全に実行可能な jar を生成するようにそのビルドを構成します。

完全に実行可能な jar は、ファイルの先頭に追加のスクリプトを埋め込むことで機能します。現在、一部のツールはこの形式を受け入れないため、常にこの手法を使用できるとは限りません。例: jar -xf は、完全に実行可能にされた jar または war の抽出に確認なしで失敗する場合があります。jar または war を完全に実行可能にするのは、java -jar で実行したり、サーブレットコンテナーにデプロイしたりするのではなく、直接実行する場合のみにすることをお勧めします。
zip64 形式の jar ファイルを完全に実行可能にすることはできません。そうしようとすると、直接または java -jar で実行された場合に jar ファイルが破損していると報告されます。1 つ以上の zip64 形式のネストされた jar を含む標準形式の jar ファイルは、完全に実行可能です。

Maven で「完全に実行可能な」jar を作成するには、次のプラグイン構成を使用します。

<plugin>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-maven-plugin</artifactId>
	<configuration>
		<executable>true</executable>
	</configuration>
</plugin>

次の例は、同等の Gradle 構成を示しています。

tasks.named('bootJar') {
	launchScript()
}

その後、init.d にシンボリックリンクして、標準 startstoprestartstatus コマンドをサポートできます。

完全に実行可能な jar に追加されるデフォルトの起動スクリプトは、ほとんどの Linux ディストリビューションをサポートしており、CentOS および Ubuntu でテストされています。OS X や FreeBSD などの他のプラットフォームでは、カスタムスクリプトを使用する必要があります。デフォルトのスクリプトは次の機能をサポートしています。

  • jar ファイルを所有するユーザーとしてサービスを開始します

  • /var/run/<appname>/<appname>.pid を使用して、アプリケーションの PID を追跡します

  • コンソールログを /var/log/<appname>.log に書き込みます

/var/myapp に Spring Boot アプリケーションがインストールされていると仮定して、Spring Boot アプリケーションを init.d サービスとしてインストールするには、次のようにシンボリックリンクを作成します。

$ sudo ln -s /var/myapp/myapp.jar /etc/init.d/myapp

インストールしたら、通常の方法でサービスを開始および停止できます。例: Debian ベースのシステムでは、次のコマンドで起動できます。

$ service myapp start
アプリケーションの起動に失敗した場合は、/var/log/<appname>.log に書き込まれたログファイルでエラーを確認してください。

標準のオペレーティングシステムツールを使用して、アプリケーションが自動的に起動するようにフラグを立てることもできます。例: Debian では、次のコマンドを使用できます。

$ update-rc.d myapp defaults <priority>

init.d サービスの保護

以下は、init.d サービスとして実行される Spring Boot アプリケーションを保護する方法に関する一連のガイドラインです。これは、アプリケーションとそれを実行する環境を強化するために実行する必要があるすべての網羅的なリストであることを意図していません。

root を使用して init.d サービスを開始する場合のように、root として実行すると、デフォルトの実行可能スクリプトは RUN_AS_USER 環境変数で指定されたユーザーとしてアプリケーションを実行します。環境変数が設定されていない場合、jar ファイルを所有するユーザーが代わりに使用されます。Spring Boot アプリケーションを root として実行することは絶対にしないでください。そのため、RUN_AS_USER が root になることはなく、アプリケーションの jar ファイルが root によって所有されることはありません。代わりに、次の例に示すように、特定のユーザーを作成してアプリケーションを実行し、RUN_AS_USER 環境変数を設定するか、chown を使用してそれを jar ファイルの所有者にします。

$ chown bootapp:bootapp your-app.jar

この場合、デフォルトの実行可能スクリプトは、bootapp ユーザーとしてアプリケーションを実行します。

アプリケーションのユーザーアカウントが侵害される可能性を減らすには、ログインシェルの使用を防止することを検討する必要があります。例: アカウントのシェルを /usr/sbin/nologin に設定できます。

また、アプリケーションの jar ファイルの変更を防ぐための措置を講じる必要があります。まず、次の例に示すように、所有者のみが書き込みおよび読み取りまたは実行できるように、アクセス許可を構成します。

$ chmod 500 your-app.jar

次に、アプリケーションまたはそれを実行しているアカウントが侵害された場合の被害を制限するための措置も講じる必要があります。攻撃者がアクセスした場合、jar ファイルを書き込み可能にし、その内容を変更する可能性があります。これを防ぐ 1 つの方法は、次の例に示すように、chattr を使用して不変にすることです。

$ sudo chattr +i your-app.jar

これにより、root を含むすべてのユーザーが jar を変更できなくなります。

root を使用してアプリケーションのサービスを制御し、.conf ファイルを使用して起動をカスタマイズする場合、.conf ファイルは root ユーザーによって読み取られ、評価されます。それに応じて保護する必要があります。次の例に示すように、所有者のみがファイルを読み取れるように chmod を使用し、ルートを所有者にするには chown を使用します。

$ chmod 400 your-app.conf
$ sudo chown root:root your-app.conf

起動スクリプトのカスタマイズ

Maven または Gradle プラグインによって作成されたデフォルトの組み込み起動スクリプトは、さまざまな方法でカスタマイズできます。ほとんどの人にとって、デフォルトのスクリプトといくつかのカスタマイズを使用するだけで通常は十分です。必要なものをカスタマイズできない場合は、embeddedLaunchScript オプションを使用して完全に独自のファイルを作成してください。

作成時の開始スクリプトのカスタマイズ

多くの場合、jar ファイルに書き込まれる開始スクリプトの要素をカスタマイズすることは理にかなっています。例: init.d スクリプトは「説明」を提供できます。説明は事前に知っているため(変更する必要はありません)、jar の生成時に説明を提供することもできます。

記述された要素をカスタマイズするには、Spring Boot Maven プラグインの embeddedLaunchScriptProperties オプションまたは Spring Boot Gradle プラグインの launchScriptproperties プロパティを使用します。

デフォルトのスクリプトでは、次のプロパティの置換がサポートされています。

名前 説明 Gradle デフォルト Maven デフォルト

mode

スクリプトモード。

auto

auto

initInfoProvides

"INIT INFO" の Provides セクション

${task.baseName}

${project.artifactId}

initInfoRequiredStart

Required-Start section of “INIT INFO”.

$remote_fs $syslog $network

$remote_fs $syslog $network

initInfoRequiredStop

Required-Stop section of “INIT INFO”.

$remote_fs $syslog $network

$remote_fs $syslog $network

initInfoDefaultStart

Default-Start section of “INIT INFO”.

2 3 4 5

2 3 4 5

initInfoDefaultStop

Default-Stop section of “INIT INFO”.

0 1 6

0 1 6

initInfoShortDescription

Short-Description section of “INIT INFO”.

Single-line version of ${project.description} (falling back to ${task.baseName})

${project.name}

initInfoDescription

Description section of “INIT INFO”.

${project.description} (falling back to ${task.baseName})

${project.description} (falling back to ${project.name})

initInfoChkconfig

chkconfig section of “INIT INFO”

2345 99 01

2345 99 01

confFolder

CONF_FOLDER のデフォルト値

jar を含むフォルダー

jar を含むフォルダー

inlinedConfScript

デフォルトの起動スクリプトでインライン化されるファイルスクリプトへの参照。これを使用して、外部構成ファイルがロードされる前に JAVA_OPTS などの環境変数を設定できます

logFolder

LOG_FOLDER のデフォルト値。init.d サービスにのみ有効

logFilename

LOG_FILENAME のデフォルト値。init.d サービスにのみ有効

pidFolder

PID_FOLDER のデフォルト値。init.d サービスにのみ有効

pidFilename

PID_FOLDER の PID ファイルの名前のデフォルト値。init.d サービスにのみ有効

useStartStopDaemon

start-stop-daemon コマンドが使用可能な場合、それを使用してプロセスを制御する必要があるかどうか

true

true

stopWaitTime

STOP_WAIT_TIME のデフォルト値(秒)。init.d サービスにのみ有効

60

60

実行時のスクリプトのカスタマイズ

jar の作成にカスタマイズする必要があるスクリプトの項目については、環境変数または構成ファイルを使用できます。

デフォルトのスクリプトでは、次の環境プロパティがサポートされています。

変数 説明

MODE

操作の「モード」。デフォルトは jar の構築方法によって異なりますが、通常は auto です(init.d というディレクトリ内のシンボリックリンクであるかどうかを確認することにより、init スクリプトかどうかを推測しようとします)。stop|start|status|restart コマンドが機能するように明示的に service に設定するか、フォアグラウンドでスクリプトを実行する場合は run に設定できます。

RUN_AS_USER

アプリケーションの実行に使用されるユーザー。設定されていない場合、jar ファイルを所有するユーザーが使用されます。

USE_START_STOP_DAEMON

start-stop-daemon コマンドが使用可能な場合、それを使用してプロセスを制御する必要があるかどうか。デフォルトは true です。

PID_FOLDER

pid フォルダーのルート名(デフォルトでは /var/run)。

LOG_FOLDER

ログファイルを保存するフォルダーの名前(デフォルトでは /var/log)。

CONF_FOLDER

.conf ファイルの読み取り元のフォルダーの名前(デフォルトでは jar-file と同じフォルダー)。

LOG_FILENAME

LOG_FOLDER (デフォルトでは <appname>.log)内のログファイルの名前。

APP_NAME

アプリの名前。jar がシンボリックリンクから実行される場合、スクリプトはアプリ名を推測します。シンボリックリンクではない場合、またはアプリ名を明示的に設定する場合、これは便利です。

RUN_ARGS

プログラム(Spring Boot アプリ)に渡す引数。

JAVA_HOME

java 実行可能ファイルの場所は、デフォルトで PATH を使用して検出されますが、$JAVA_HOME/bin/java に実行可能ファイルがある場合は明示的に設定できます。

JAVA_OPTS

JVM の起動時に JVM に渡されるオプション。

JARFILE

スクリプトが実際に埋め込まれていない jar を起動するために使用されている場合の jar ファイルの明示的な場所。

DEBUG

空でない場合は、シェルプロセスに -x フラグを設定して、スクリプト内のロジックを確認できるようにします。

STOP_WAIT_TIME

シャットダウンを強制する前にアプリケーションを停止するときに待機する時間(秒)(デフォルトでは 60)。

PID_FOLDERLOG_FOLDERLOG_FILENAME 変数は、init.d サービスに対してのみ有効です。systemd の場合、同等のカスタマイズは「サービス」スクリプトを使用して行われます。詳細については、サービスユニットの構成のマニュアルページ (英語) 参照 (英語) してください。
Conf ファイルの使用

JARFILE および APP_NAME を除き、前のセクションにリストされた設定は、.conf ファイルを使用して構成できます。ファイルは jar ファイルの隣にあり、同じ名前であるが、.jar ではなく .conf で接尾辞が付けられていると予想されます。例: /var/myapp/myapp.jar という名前の jar は、次の例に示すように、/var/myapp/myapp.conf という名前の構成ファイルを使用します。

myapp.conf
JAVA_OPTS=-Xmx1024M
LOG_FOLDER=/custom/log/folder
jar ファイルの横に構成ファイルを置くのが気に入らない場合は、CONF_FOLDER 環境変数を設定して、構成ファイルの場所をカスタマイズできます。

このファイルを適切に保護する方法については、init.d サービスを保護するためのガイドラインを参照してください。

Microsoft Windows サービス

winsw [GitHub] (英語) を使用して、Spring Boot アプリケーションを Windows サービスとして開始できます。

別途メンテナンスされているサンプル [GitHub] (英語) )では、Spring Boot アプリケーション用の Windows サービスを作成する方法を順を追って説明しています。