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
       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 抽象化を通じてアクセスできるプロパティにデータをフラット化します。

Java
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");
    }

    // ...

}
Kotlin
import org.springframework.context.EnvironmentAware
import org.springframework.core.env.Environment
import org.springframework.stereotype.Component

@Component
class MyBean : EnvironmentAware {

    private var instanceId: String? = null

    override fun setEnvironment(environment: Environment) {
        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... done
-----> Installing Maven... 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. CloudCaptain および Amazon Web Services

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

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

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

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

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

この時点で、CloudCaptain はアプリケーションのイメージを作成してアップロードし、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 ビルドを開始するための CloudCaptain 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 スタンダード環境にデプロイするには、このチュートリアル (英語) に従ってください。

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

service: "default"

runtime: "java17"
env: "flex"

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>2.4.4</version>
    <configuration>
        <project>myproject</project>
    </configuration>
</plugin>

次に、mvn appengine:deploy を使用してデプロイします (最初に認証する必要があります。そうしないと、ビルドは失敗します)。

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

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

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

Environment="JAVA_HOME=/path/to/java/home"

ExecStart=${JAVA_HOME}/bin/java -jar /var/myapp/myapp.jar
ExecStop=/bin/kill -15 $MAINPID
SuccessExitStatus=143

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

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

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

$ systemctl enable myapp.service

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

2.2. 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 にシンボリックリンクして、標準 start、stop、restart、status コマンドをサポートできます。

完全に実行可能な 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>

2.2.1. 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. 起動スクリプトのカスタマイズ

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. 効率的なデプロイ

3.1. 実行可能 JAR の解凍

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

$ jar -xf myapp.jar
$ java org.springframework.boot.loader.launch.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 ファイルが含まれています。

3.2. JVM での事前処理の使用

AOT で生成された初期化コードを使用してアプリケーションを実行すると、起動時間が短縮されます。まず、構築している jar に AOT で生成されたコードが含まれていることを確認する必要があります。

Maven の場合、これは、native プロファイルをアクティブ化するために -Pnative を使用してビルドする必要があることを意味します。

$ mvn -Pnative package

Gradle の場合、ビルドに org.springframework.boot.aot プラグインが含まれていることを確認する必要があります。

JAR が構築されたら、spring.aot.enabled システムプロパティを true に設定して実行します。例：

$ java -Dspring.aot.enabled=true -jar myapplication.jar

........ Starting AOT-processed MyApplication ...

事前処理の使用には欠点があることに注意してください。これは次の制限を意味します。

  • クラスパスは固定され、ビルド時に完全に定義されます

  • アプリケーションで定義された Bean は実行時に変更できません。つまり、次のことを意味します。

    • Spring @Profile アノテーションとプロファイル固有の構成には制限があります。

    • Bean が作成された場合に変更されるプロパティはサポートされていません (たとえば、@ConditionalOnProperty および .enable プロパティ)。

事前処理の詳細については、"Spring の事前処理セクションについて" を参照してください。

3.3. JVM を使用したチェックポイントと復元

チェックポイントでの調整された復元 (英語) (CRaC) は、HotSpot JVM 上でアプリケーションをチェックポイントして復元できるようにする新しい Java API を定義する OpenJDK プロジェクトです。これは、Linux 上でチェックポイント / 復元機能を実装するプロジェクトである CRIU [GitHub] (英語) に基づいています。

原則は次のとおりです。通常とほぼ同じようにアプリケーションを起動しますが、CRaC を備えた Bellsoft Liberica JDK (英語) または CRaC を使用した Azul Zulu JDK (英語) などの CRaC 対応バージョンの JDK を使用します。その後、ある時点で、すべての共通コードパスを実行して JVM をウォームアップするいくつかのワークロードの後、API 呼び出し、jcmd コマンド、HTTP エンドポイント、または別のメカニズムを使用してチェックポイントをトリガーします。

実行中の JVM のメモリ表現 (ウォームネスを含む) はディスクに直列化され、後で、同様のオペレーティングシステムと CPU アーキテクチャを備えた別のマシン上で高速復元できるようになります。復元されたプロセスは、実行時のさらなる JIT 最適化を含む、HotSpot JVM のすべての機能を保持します。

Spring Framework によって提供される基盤に基づいて、Spring Boot はアプリケーションのチェックポイント設定と復元のサポートを提供し、限られた範囲 [GitHub] (英語) でソケット、ファイル、スレッドプールなどのリソースのライフサイクルをすぐに管理します。他の依存関係、およびそのようなリソースを処理するアプリケーションコードについては、追加のライフサイクル管理が期待されます。

サポートされている 2 つのモード (「実行中のアプリケーションのオンデマンドチェックポイント / リストア」と「起動時の自動チェックポイント / リストア」)、チェックポイントとリストアのサポートを有効にする方法、およびいくつかのガイドラインの詳細については、「Spring Framework JVM チェックポイントリストアサポート」を参照してください。ドキュメント。

4. 次のステップ

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

次のセクションでは、GraalVM ネイティブイメージについて説明します。または、先に進んで Spring Boot CLI またはビルドツールプラグインについて読むこともできます。