Spring Boot の柔軟なパッケージオプションは、アプリケーションのデプロイに関して多くの選択肢を提供します。Spring Boot アプリケーションは、さまざまなクラウドプラットフォーム、仮想 / 実マシンにデプロイしたり、Unix システムで完全に実行可能にすることができます。

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

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

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

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

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

このセクションでは、「入門」セクションで開発したアプリケーションをクラウドで稼働させるために必要なことを説明します。

1.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/ で見つけることができます。

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

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

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

import org.springframework.context.EnvironmentAware;
import org.springframework.core.env.Environment;
import org.springframework.stereotype.Component;

@Component
public 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 の構成などのタスクにより適しています。

1.2. Kubernetes

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

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

1.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 がコンテナーに送信され、正常なシャットダウンが開始され、残りの進行中のリクエストを完了できます。

Kubernetes が SIGTERM シグナルを pod に送信すると、終了猶予期間（デフォルトは 30 秒）と呼ばれる指定された時間待機します。猶予期間後もコンテナーが実行されている場合は、SIGKILL シグナルが送信され、強制的に削除されます。pod のシャットダウンに 30 秒以上かかる場合は、spring.lifecycle.timeout-per-shutdown-phase を増やしたことが原因である可能性があります。必ず、Pod YAML で terminationGracePeriodSeconds オプションを設定して、終了猶予期間を増やしてください。

1.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 main

その結果、次のようになります。

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]      main -> main

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

1.4. OpenShift

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

1.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 を使用したアプローチについて説明します。

1.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

1.5.2. 要約

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

1.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 統合のドキュメント (英語) を参照してください。

1.7. Azure

この入門ガイドは、Spring Boot アプリケーションを Azure Spring Cloud (英語) または Azure アプリサービス のいずれかにデプロイする方法を説明します。

1.8. 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 でデプロイします（最初に認証する必要がある場合、ビルドは失敗します）。

2. 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 を含むディレクトリは、アプリケーションの作業ディレクトリとして使用されます。

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

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

2.2. Unix/Linux サービス

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

2.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

2.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 を実行してください。

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

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

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

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

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

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

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

2.3. Microsoft Windows サービス

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

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

3. 次のステップ

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

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