Spring Boot アプリケーションのデプロイ

Spring Boot の柔軟なパッケージオプションは、アプリケーションのデプロイに関して非常に多くの選択肢を提供します。Spring Boot アプリケーションは、さまざまなクラウドプラットフォーム、コンテナーイメージ（Docker など）、仮想 / 実マシンにデプロイできます。

このセクションでは、より一般的なデプロイシナリオのいくつかについて説明します。

1. コンテナーへのデプロイ

コンテナーからアプリケーションを実行している場合、実行可能な jar を使用できますが、それを展開させて別の方法で実行することもしばしば利点です。特定の PaaS 実装では、アーカイブを実行する前に解凍することもできます。例: Cloud Foundry はこのように動作します。解凍されたアーカイブを実行する最も簡単な方法は、次のように適切なランチャーを起動することです。

$ jar -xf myapp.jar
$ java org.springframework.boot.loader.JarLauncher

これは、実際には、起動時に（jar のサイズに応じて）未展開のアーカイブから実行するよりもわずかに高速です。実行時に違いを期待しないでください。

jar ファイルを解凍したら、JarLauncher の代わりに「自然な」main メソッドでアプリを実行することにより、起動時間をさらに速くすることができます。例：

$ jar -xf myapp.jar
$ java -cp BOOT-INF/classes:BOOT-INF/lib/* com.example.MyApplication

アプリケーションのメインメソッド上で JarLauncher を使用すると、予測可能なクラスパス順序の利点が追加されます。jar には、クラスパスを構築するときに JarLauncher によって使用される classpath.idx ファイルが含まれています。

依存関係とアプリケーションクラスおよびリソース（通常は頻繁に変更される）に個別のレイヤーを作成することにより、より効率的なコンテナーイメージを作成することもできます。

2. クラウドへのデプロイ

Spring Boot の実行可能 jar は、ほとんどの一般的なクラウド PaaS（Platform-as-a-Service）プロバイダー向けに用意されています。これらのプロバイダーは、「独自のコンテナーを持ち込む」ことを要求する傾向があります。アプリケーションプロセス（特に Java アプリケーションではない）を管理するため、実行中のプロセスのクラウドの概念にアプリケーションを適合させる中間層が必要です。

2 つの人気のあるクラウドプロバイダーである Heroku と Cloud Foundry は、"buildpack" アプローチを採用しています。buildpack は、デプロイされたコードを、アプリケーションの起動に必要なものにラップします。これは、JDK と、java、組み込み Web サーバー、本格的なアプリケーションサーバーへの呼び出しである可能性があります。buildpack はプラグイン可能ですが、理想的には、可能な限り少ないカスタマイズで問題を解決できるはずです。これにより、制御できない機能のフットプリントが削減されます。開発環境と本番環境の間の相違を最小限に抑えます。

理想的には、Spring Boot 実行可能ファイル jar のようなアプリケーションには、実行に必要なものがすべてパッケージ化されています。

このセクションでは、「入門」セクションで開発したシンプルなアプリケーションをクラウドで起動して実行するために必要なものを見ていきます。

2.1. Cloud Foundry

Cloud Foundry は、他の buildpack が指定されていない場合に機能するデフォルトの buildpacks を提供します。Cloud Foundry Java buildpack [GitHub] (英語) は、Spring Boot を含む Spring アプリケーションを優れた方法でサポートします。スタンドアロンの実行可能 jar アプリケーションと、従来の .war パッケージアプリケーションをデプロイできます。

mvn clean package などを使用してアプリケーションを構築し、cf コマンドラインツールをインストールしたら、cf push コマンド (英語) を使用して、コンパイル済みの .jar へのパスを置き換えてアプリケーションをデプロイします。アプリケーションをプッシュする前に、cf コマンドラインクライアントでログインしてください (英語) 。次の行は、cf push コマンドを使用してアプリケーションをデプロイすることを示しています。

$ cf push acloudyspringtime -p target/demo-0.0.1-SNAPSHOT.jar

前の例では、cf をアプリケーションの名前として指定した値の代わりに acloudyspringtime を使用しています。

その他のオプションについては、cf push ドキュメント (英語) を参照してください。同じディレクトリに Cloud Foundry manifest.yml (英語) ファイルが存在する場合、それが考慮されます。

この時点で、cf はアプリケーションのアップロードを開始し、次の例のような出力を生成します。

Uploading acloudyspringtime... OK
Preparing to start acloudyspringtime... OK
-----> Downloaded app package (8.9M)
-----> Java Buildpack Version: v3.12 (offline) | https://github.com/cloudfoundry/java-buildpack.git#6f25b7e
-----> Downloading Open Jdk JRE 1.8.0_121 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_121.tar.gz (found in cache)
       Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.6s)
-----> Downloading Open JDK Like Memory Calculator 2.0.2_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-2.0.2_RELEASE.tar.gz (found in cache)
       Memory Settings: -Xss349K -Xmx681574K -XX:MaxMetaspaceSize=104857K -Xms681574K -XX:MetaspaceSize=104857K
-----> Downloading Container Certificate Trust Store 1.0.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-certificate-trust-store/container-certificate-trust-store-1.0.0_RELEASE.jar (found in cache)
       Adding certificates to .java-buildpack/container_certificate_trust_store/truststore.jks (0.6s)
-----> Downloading Spring Auto Reconfiguration 1.10.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.10.0_RELEASE.jar (found in cache)
Checking status of app 'acloudyspringtime'...
  0 of 1 instances running (1 starting)
  ...
  0 of 1 instances running (1 starting)
  ...
  0 of 1 instances running (1 starting)
  ...
  1 of 1 instances running (1 running)

App started

おめでとう！これでアプリケーションが公開されました！

アプリケーションが稼働したら、次の例に示すように、cf apps コマンドを使用して、デプロイされたアプリケーションのステータスを確認できます。

$ cf apps
Getting applications in ...
OK

name                 requested state   instances   memory   disk   urls
...
acloudyspringtime    started           1/1         512M     1G     acloudyspringtime.cfapps.io
...

Cloud Foundry がアプリケーションがデプロイされたことを確認すると、指定された URI でアプリケーションを見つけることができるはずです。上記の例では、https://acloudyspringtime.cfapps.io/ で見つけることができます。

2.1.1. サービスへのバインド

デフォルトでは、実行中のアプリケーションに関するメタデータとサービス接続情報は、環境変数（$VCAP_SERVICES など）としてアプリケーションに公開されます。このアーキテクチャの決定は、Cloud Foundry のポリグロット（任意の言語とプラットフォームを buildpack としてサポートできます）の性質によるものです。プロセススコープの環境変数は言語に依存しません。

環境変数は常に最も簡単な API を提供するとは限らないため、Spring Boot は自動的に抽出し、次の例に示すように、Spring の Environment 抽象化を通じてアクセスできるプロパティにデータをフラット化します。

@Component
class MyBean implements EnvironmentAware {

    private String instanceId;

    @Override
    public void setEnvironment(Environment environment) {
        this.instanceId = environment.getProperty("vcap.application.instance_id");
    }

    // ...

}

すべての Cloud Foundry プロパティには、接頭辞 vcap が付きます。vcap プロパティを使用して、アプリケーション情報（アプリケーションのパブリック URL など）およびサービス情報（データベース資格情報など）にアクセスできます。詳細については、‘ CloudFoundryVcapEnvironmentPostProcessor ’ (Javadoc) Javadoc を参照してください。

Java CFEnv [GitHub] (英語) プロジェクトは、DataSource の構成などのタスクにより適しています。

2.2. Kubernetes

Spring Boot は、"*_SERVICE_HOST" および "*_SERVICE_PORT" 変数の環境をチェックすることにより、Kubernetes デプロイ環境を自動検出します。この検出は、spring.main.cloud-platform 構成プロパティでオーバーライドできます。

Spring Boot は、アプリケーションの状態を管理し、アクチュエーターを使用した HTTP Kubernetes プローブでエクスポートできます。

2.2.1. Kubernetes コンテナーライフサイクル

Kubernetes がアプリケーションインスタンスを削除すると、シャットダウンプロセスには複数のサブシステムが同時に関与します。シャットダウンフック、サービスの登録解除、ロードバランサーからのインスタンスの削除…このシャットダウン処理は並行して（分散システムの性質により）行われるため、シャットダウン処理を開始した pod にトラフィックをルーティングできるウィンドウです。

preStop ハンドラーでスリープ実行を構成すると、すでにシャットダウンを開始している pod にリクエストがルーティングされるのを防ぐことができます。このスリープは、新しいリクエストが pod にルーティングされなくなるのに十分な長さである必要があり、その期間はデプロイからデプロイまで異なります。preStop ハンドラーは、次のように pod の構成ファイルの PodSpec を介して構成できます。

spec:
  containers:
  - name: example-container
    image: example-image
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "sleep 10"]

事前停止フックが完了すると、SIGTERM がコンテナーに送信され、正常なシャットダウンが開始され、残りの進行中のリクエストを完了できます。

2.3. Heroku

Heroku は、もう 1 つの一般的な PaaS プラットフォームです。Heroku ビルドをカスタマイズするには、アプリケーションをデプロイするために必要な呪文を提供する Procfile を提供します。Heroku は、使用する Java アプリケーションに port を割り当て、外部 URI へのルーティングが機能することを確認します。

正しいポートでリッスンするようにアプリケーションを構成する必要があります。次の例は、スターター REST アプリケーションの Procfile を示しています。

web: java -Dserver.port=$PORT -jar target/demo-0.0.1-SNAPSHOT.jar

Spring Boot は、-D 引数を Spring Environment インスタンスからアクセス可能なプロパティとして使用できるようにします。server.port 構成プロパティは、組み込み Tomcat、Jetty、Undertow インスタンスに供給され、起動時にポートを使用します。$PORT 環境変数は、Heroku PaaS によって割り当てられます。

これが必要なものすべてです。Heroku デプロイの最も一般的なデプロイワークフローは、次の例に示すように、本番環境にコードを git push することです。

$ git push heroku master

Initializing repository, done.
Counting objects: 95, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (78/78), done.
Writing objects: 100% (95/95), 8.66 MiB | 606.00 KiB/s, done.
Total 95 (delta 31), reused 0 (delta 0)

-----> Java app detected
-----> Installing OpenJDK 1.8... done
-----> Installing Maven 3.3.1... done
-----> Installing settings.xml... done
-----> Executing: mvn -B -DskipTests=true clean install

       [INFO] Scanning for projects...
       Downloading: https://repo.spring.io/...
       Downloaded: https://repo.spring.io/... (818 B at 1.8 KB/sec)
        ....
       Downloaded: https://s3pository.heroku.com/jvm/... (152 KB at 595.3 KB/sec)
       [INFO] Installing /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/target/...
       [INFO] Installing /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/pom.xml ...
       [INFO] ------------------------------------------------------------------------
       [INFO] BUILD SUCCESS
       [INFO] ------------------------------------------------------------------------
       [INFO] Total time: 59.358s
       [INFO] Finished at: Fri Mar 07 07:28:25 UTC 2014
       [INFO] Final Memory: 20M/493M
       [INFO] ------------------------------------------------------------------------

-----> Discovering process types
       Procfile declares types -> web

-----> Compressing... done, 70.4MB
-----> Launching... done, v6
       https://agile-sierra-1405.herokuapp.com/ deployed to Heroku

To [email protected] (英語)  :agile-sierra-1405.git
 * [new branch]      master -> master

これで、アプリケーションが Heroku で稼働しているはずです。詳細については、Spring Boot アプリケーションを Heroku にデプロイする (英語) を参照してください。

2.4. OpenShift

OpenShift (英語) には、Spring Boot アプリケーションをデプロイする方法を説明する多くのリソースがあります。

2.5. Amazon Web Services (AWS)

Amazon Web Services は、SpringBoot ベースのアプリケーションを、従来の Web アプリケーション（war）として、または Web サーバーが組み込まれた実行可能 jar ファイルとしてインストールするための複数の方法を提供します。オプションは次のとおりです。

AWS Elastic Beanstalk
AWS Code Deploy
AWS OPS Works
AWS Cloud Formation
AWS Container Registry

それぞれに異なる機能と価格設定モデルがあります。このドキュメントでは、最も単純なオプションである AWS Elastic Beanstalk のみを説明します。

2.5.1. AWS Elastic Beanstalk

公式 Elastic Beanstalk Java ガイド [Amazon] に従って、Java アプリケーションをデプロイするには 2 つの主なオプションがあります。「Tomcat プラットフォーム」または「Java SE プラットフォーム」のいずれかを使用できます。

Tomcat プラットフォームの使用

このオプションは、war ファイルを生成する Spring Boot プロジェクトに適用されます。特別な設定は必要ありません。公式ガイドに従うだけです。

Java SE プラットフォームの使用

このオプションは、jar ファイルを生成し、埋め込み Web コンテナーを実行する Spring Boot プロジェクトに適用されます。Elastic Beanstalk 環境は、ポート 80 で nginx インスタンスを実行し、ポート 5000 で実行されている実際のアプリケーションをプロキシします。設定するには、application.properties ファイルに次の行を追加します。

server.port=5000

ソースの代わりにバイナリをアップロードする

デフォルトでは、Elastic Beanstalk はソースをアップロードし、AWS でコンパイルします。ただし、代わりにバイナリをアップロードすることをお勧めします。これを行うには、.elasticbeanstalk/config.yml ファイルに次のような行を追加します。

deploy:
    artifact: target/demo-0.0.1-SNAPSHOT.jar

環境型を設定してコストを削減

デフォルトでは、ElasticBeanstalk 環境は負荷分散されています。ロードバランサーにはかなりのコストがかかります。このコストを回避するには、Amazon のドキュメントで説明されているように、環境型を「シングルインスタンス」に設定します。CLI と次のコマンドを使用して、単一インスタンス環境を作成することもできます。

eb create -s

2.5.2. 要約

これは AWS にアクセスする最も簡単な方法の 1 つですが、Elastic Beanstalk を任意の CI/CD ツールに統合する方法、CLI の代わりに Elastic Beanstalk Maven プラグインを使用する方法など、さらに説明することがあります。これらのトピックをより詳細にカバーするブログ投稿 (英語) があります。

2.6. Boxfuse と Amazon Web Services

Boxfuse (英語) は、Spring Boot 実行可能ファイル jar または war を、VirtualBox または AWS に変更せずにデプロイできる最小の VM イメージに変換することで機能します。Boxfuse には Spring Boot の緊密な統合が付属しており、Spring Boot 構成ファイルの情報を使用して、ポートとヘルスチェック URL を自動的に構成します。Boxfuse は、生成するイメージとプロビジョニングするすべてのリソース（インスタンス、セキュリティグループ、エラスティックロードバランサーなど）の両方について、この情報を活用します。

Boxfuse アカウント (英語) を作成し、AWS アカウントに接続し、Boxfuse クライアントの最新バージョンをインストールし、Maven または Gradle（たとえば、mvn clean package を使用して）によってアプリケーションがビルドされたことを確認したら、Spring Boot をデプロイできます。次のようなコマンドを使用して AWS に適用します。

$ boxfuse run myapp-1.0.jar -env=prod

その他のオプションについては、boxfuse run ドキュメント (英語) を参照してください。現在のディレクトリに boxfuse.conf (英語) ファイルが存在する場合、それが考慮されます。

デフォルトでは、Boxfuse は起動時に boxfuse という名前の Spring プロファイルをアクティブにします。実行可能な jar または war に application-boxfuse.properties (英語) ファイルが含まれている場合、Boxfuse はその構成をそのプロパティに基づいています。

この時点で、boxfuse はアプリケーションのイメージを作成してアップロードし、AWS で必要なリソースを構成および開始します。その結果、出力は次の例のようになります。

Fusing Image for myapp-1.0.jar ...
Image fused in 00:06.838s (53937 K) -> axelfontaine/myapp:1.0
Creating axelfontaine/myapp ...
Pushing axelfontaine/myapp:1.0 ...
Verifying axelfontaine/myapp:1.0 ...
Creating Elastic IP ...
Mapping myapp-axelfontaine.boxfuse.io to 52.28.233.167 ...
Waiting for AWS to create an AMI for axelfontaine/myapp:1.0 in eu-central-1 (this may take up to 50 seconds) ...
AMI created in 00:23.557s -> ami-d23f38cf
Creating security group boxfuse-sg_axelfontaine/myapp:1.0 ...
Launching t2.micro instance of axelfontaine/myapp:1.0 (ami-d23f38cf) in eu-central-1 ...
Instance launched in 00:30.306s -> i-92ef9f53
Waiting for AWS to boot Instance i-92ef9f53 and Payload to start at https://52.28.235.61/ ...
Payload started in 00:29.266s -> https://52.28.235.61/
Remapping Elastic IP 52.28.233.167 to i-92ef9f53 ...
Waiting 15s for AWS to complete Elastic IP Zero Downtime transition ...
Deployment completed successfully. axelfontaine/myapp:1.0 is up and running at https://myapp-axelfontaine.boxfuse.io/

これで、アプリケーションが AWS で稼働しているはずです。

EC2 への Spring Boot アプリのデプロイ (英語) に関するブログ投稿と、アプリを実行するための Maven ビルドを開始するための Boxfuse Spring Boot 統合のドキュメント (英語) を参照してください。

2.7. Google クラウド

Google クラウドには、Spring Boot アプリケーションを起動するために使用できるいくつかのオプションがあります。おそらく App Engine を使用するのが最も簡単ですが、Container Engine を使用するコンテナー内で、または Compute Engine を使用する仮想マシン上で Spring Boot を実行する方法を見つけることもできます。

App Engine で実行するには、最初に UI でプロジェクトを作成します。これにより、一意の識別子が設定され、HTTP ルートも設定されます。Java アプリをプロジェクトに追加し、空のままにしてから、Google クラウド SDK を使用して、コマンドラインまたは CI ビルドから Spring Boot アプリをそのスロットにプッシュします。

App Engine スタンダードでは、WAR パッケージを使用する必要があります。App Engine Standard アプリケーションを Google Cloud にデプロイするには、次の手順 [GitHub] (英語) に従います。

または、App Engine Flex では、app.yaml ファイルを作成して、アプリに必要なリソースを記述する必要があります。通常、このファイルは src/main/appengine に配置し、次のファイルのようになります。

service: default

runtime: java
env: flex

runtime_config:
  jdk: openjdk8

handlers:
- url: /.*
  script: this field is required, but ignored

manual_scaling:
  instances: 1

health_check:
  enable_health_check: False

env_variables:
  ENCRYPT_KEY: your_encryption_key_here

次の例に示すように、プロジェクト ID をビルド構成に追加することで、アプリを（たとえば、Maven プラグインを使用して）デプロイできます。

<plugin>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>appengine-maven-plugin</artifactId>
    <version>1.3.0</version>
    <configuration>
        <project>myproject</project>
    </configuration>
</plugin>

次に、mvn appengine:deploy でデプロイします（最初に認証する必要がある場合、ビルドは失敗します）。

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

java -jar を使用して Spring Boot アプリケーションを実行することに加えて、Unix システム用の完全に実行可能なアプリケーションを作成することもできます。完全に実行可能な jar は、他の実行可能なバイナリと同様に実行することも、init.d または systemd に登録することもできます。これにより、一般的な本番環境で Spring Boot アプリケーションを非常に簡単にインストールおよび管理できます。

完全に実行可能な 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 構成を示しています。

bootJar {
    launchScript()
}

その後、./my-application.jar （my-application はアーティファクトの名前）と入力して、アプリケーションを実行できます。jar を含むディレクトリは、アプリケーションの作業ディレクトリとして使用されます。

3.1. サポートされているオペレーティングシステム

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

3.2. Unix/Linux サービス

Spring Boot アプリケーションは、init.d または systemd を使用して Unix/Linux サービスとして簡単に開始できます。

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

完全に実行可能な jar を生成するように Spring Boot の Maven または Gradle プラグインを構成し、カスタム embeddedLaunchScript を使用しない場合、アプリケーションを init.d サービスとして使用できます。これを行うには、jar を init.d にシンボリックリンクして、標準の start、stop、restart、status コマンドをサポートします。

このスクリプトは次の機能をサポートしています。

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

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

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

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

[Unit]
Description=myapp
After=syslog.target

[Service]
User=myapp
ExecStart=/var/myapp/myapp.jar
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

アプリケーションの Description、User、ExecStart フィールドを変更することを忘れないでください。

ExecStart フィールドは、スクリプトアクションコマンドを宣言しません。これは、run コマンドがデフォルトで使用されることを意味します。

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

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

$ systemctl enable myapp.service

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

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

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

書き込まれたときの開始スクリプトのカスタマイズ

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

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

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

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

名前	説明	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

mode

スクリプトモード。

auto

initInfoProvides

"INIT INFO" の Provides セクション

${task.baseName}

${project.artifactId}

initInfoRequiredStart

Required-Start section of “INIT INFO”.

$remote_fs $syslog $network

initInfoRequiredStop

Required-Stop section of “INIT INFO”.

$remote_fs $syslog $network

initInfoDefaultStart

Default-Start section of “INIT INFO”.

2 3 4 5

initInfoDefaultStop

Default-Stop section of “INIT INFO”.

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

confFolder

CONF_FOLDER のデフォルト値

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

stopWaitTime

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

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

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`）。

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

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 サービスを保護するためのガイドラインを参照してください。

3.3. Microsoft Windows サービス

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

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

4. 次のステップ

PaaS が提供できる機能の種類の詳細については、Cloud Foundry (英語) 、Heroku (英語) 、OpenShift (英語) 、Boxfuse (英語) の Web サイトを参照してください。これらは、最も人気のある 4 つの Java PaaS プロバイダーにすぎません。Spring Boot はクラウドベースのデプロイに非常に適しているため、他のプロバイダーも自由に検討できます。

次のセクションでは Spring Boot CLI について説明します。また、ビルドツールプラグインについて読むこともできます。