§本番環境設定
本番環境では、さまざまな種類の設定を行うことができます。主な3つの種類は次のとおりです。
これらの種類ごとに、設定方法が異なります。
§一般設定
Playには、多数の設定可能な設定があります。データベース接続URL、アプリケーションシークレット、HTTPポート、SSL設定などを設定できます。
Playの設定のほとんどは、HOCON形式を使用するさまざまな.confファイルで定義されています。使用する主な設定ファイルは、application.confファイルです。このファイルは、プロジェクト内のconf/application.confにあります。 application.confファイルは、実行時にクラスパスからロードされます（または、ロードされる場所をオーバーライドできます）。プロジェクトごとに1つのapplication.confのみ使用できます。
他の.confファイルもロードされます。ライブラリは、reference.confファイルにデフォルト設定を定義します。これらのファイルは、ライブラリのJARに格納されます（JARごとに1つのreference.conf）。実行時にまとめて集約されます。 reference.confファイルはデフォルトを提供します。 application.confファイルで定義されている設定によってオーバーライドされます。
Playの設定は、システムプロパティと環境変数を使用して定義することもできます。これは、環境間で設定が変更される場合に便利です。 application.confを共通設定に使用できますが、異なる環境でアプリケーションを実行する場合は、システムプロパティと環境変数を使用して設定を変更します。
システムプロパティはapplication.confの設定をオーバーライドし、application.confはさまざまなreference.confファイルのデフォルト設定をオーバーライドします。
実行時設定は、いくつかの方法でオーバーライドできます。これは、環境間で設定が異なる場合に便利です。環境ごとに設定を動的に変更できます。実行時設定の選択肢は次のとおりです。
- 代替の
application.confファイルを使用する。 - システムプロパティを使用して個々の設定をオーバーライドする。
- 環境変数を使用して設定値を挿入する。
§代替設定ファイルの指定
デフォルトでは、application.confファイルがクラスパスからロードされます。必要に応じて、代替設定ファイルを指定できます。
§-Dconfig.resourceの使用
これは、アプリケーションクラスパスで代替設定ファイルを検索します（通常、これらの代替設定ファイルはパッケージ化する前にアプリケーションのconf/ディレクトリに提供します）。 Playはconf/を調べるので、conf/を追加する必要はありません。
$ /path/to/bin/<project-name> -Dconfig.resource=prod.conf
§-Dconfig.fileの使用
アプリケーションアーティファクトにパッケージ化されていない別のローカル設定ファイルを指定することもできます。
$ /path/to/bin/<project-name> -Dconfig.file=/opt/conf/prod.conf
includeディレクティブを使用して、新しいprod.confファイルで元の構成ファイルを参照できることに注意してください。例:include "application.conf" key.to.override=blah
§システムプロパティによる設定のオーバーライド
別の完全な設定ファイルを指定したくないが、特定のキーの束をオーバーライドしたい場合があります。 Javaシステムプロパティとして指定することで、それを行うことができます。
$ /path/to/bin/<project-name> -Dplay.http.secret.key=ad31779d4ee49d5ad5162bf1429c32e2e9933f3b -Ddb.default.password=toto
§システムプロパティを使用したHTTPサーバーのアドレスとポートの指定
システムプロパティを使用して、HTTPポートとアドレスの両方を簡単に指定できます。デフォルトでは、アドレス0.0.0.0（すべてのアドレス）のポート9000でリッスンします。
$ /path/to/bin/<project-name> -Dhttp.port=1234 -Dhttp.address=127.0.0.1
§環境変数を使用したHTTPサーバーのアドレスとポートの指定
LinuxでBashを使用する場合など、環境変数を使用してHTTPポートとアドレスの両方を簡単に指定できます。
export PLAY_HTTP_PORT=1234
export PLAY_HTTPS_PORT=1235
export PLAY_HTTP_ADDRESS=127.0.0.1
これらの変数は最後に取得されます。つまり、application.confまたはシステムプロパティで既に定義されているポートまたはアドレスは、これらの環境変数をオーバーライドします。
§RUNNING_PIDのパスを変更する
開始されたアプリケーションのプロセスIDを含むファイルへのパスを変更することは可能です。通常、このファイルはPlayプロジェクトのルートディレクトリに配置されますが、再起動時に自動的にクリアされる場所に配置することをお勧めします。例：/var/run
$ /path/to/bin/<project-name> -Dpidfile.path=/var/run/play.pid
ディレクトリが存在し、Playアプリケーションを実行するユーザーに書き込み権限があることを確認してください。
このファイルを使用して、たとえば、killコマンドを使用してアプリケーションを停止できます。
$ kill $(cat /var/run/play.pid)
Playが独自のPIDを作成しないようにするには、application.confファイルでパスを/dev/nullに設定します。
pidfile.path = "/dev/null"
§環境変数の使用
application.confファイルから環境変数を参照することもできます。
my.key = defaultvalue
my.key = ${?MY_KEY_ENV}
ここで、オーバーライドフィールドmy.key = ${?MY_KEY_ENV}は、MY_KEY_ENVの値がない場合は単に消えますが、たとえば環境変数MY_KEY_ENVを設定すると、それが使用されます。
§サーバー設定オプション
PlayのデフォルトのHTTPサーバー実装はPekko HTTPです。これにより、パーサーバッファのサイズ、キープアライブを使用するかどうかなど、サーバーを調整および設定するための多数の方法が提供されます。
デフォルトを含むサーバー設定オプションの完全なリストは、こちらをご覧ください。
# Copyright (C) from 2022 The Play Framework Contributors <https://github.com/playframework>, 2011-2021 Lightbend Inc. <https://www.lightbend.com>
# Configuration for Play's PekkoHttpServer
play {
server {
# The server provider class name
provider = "play.core.server.PekkoHttpServerProvider"
pekko {
# How long to wait when binding to the listening socket
bindTimeout = 5 seconds
# How long a request takes until it times out. Set to null or "infinite" to disable the timeout.
requestTimeout = infinite
# Enables/disables automatic handling of HEAD requests.
# If this setting is enabled the server dispatches HEAD requests as GET
# requests to the application and automatically strips off all message
# bodies from outgoing responses.
# Note that, even when this setting is off the server will never send
# out message bodies on responses to HEAD requests.
# For Play to work correctly with WebSockets, you should avoid setting this config to "on",
# see https://github.com/playframework/playframework/pull/7060
transparent-head-requests = off
# If this setting is empty the server only accepts requests that carry a
# non-empty `Host` header. Otherwise it responds with `400 Bad Request`.
# Set to a non-empty value to be used in lieu of a missing or empty `Host`
# header to make the server accept such requests.
# Note that the server will never accept HTTP/1.1 request without a `Host`
# header, i.e. this setting only affects HTTP/1.1 requests with an empty
# `Host` header as well as HTTP/1.0 requests.
# Examples: `www.spray.io` or `example.com:8080`
default-host-header = ""
# The default value of the `Server` header to produce if no
# explicit `Server`-header was included in a response.
# If this value is null and no header was included in
# the request, no `Server` header will be rendered at all.
server-header = null
server-header = ${?play.server.server-header}
# Configures the processing mode when encountering illegal characters in
# header value of response.
#
# Supported mode:
# `error` : default mode, throw an ParsingException and terminate the processing
# `warn` : ignore the illegal characters in response header value and log a warning message
# `ignore` : just ignore the illegal characters in response header value
illegal-response-header-value-processing-mode = warn
# Enables/disables inclusion of an Tls-Session-Info header in parsed
# messages over Tls transports (i.e., HttpRequest on server side and
# HttpResponse on client side).
#
# See Pekko HTTP `pekko.http.server.parsing.tls-session-info-header` for
# more information about how this works.
tls-session-info-header = on
# The maximum number of requests that are accepted (and dispatched to
# the application) on one single connection before the first request
# has to be completed.
# Incoming requests that would cause the pipelining limit to be exceeded
# are not read from the connections socket so as to build up "back-pressure"
# to the client via TCP flow control.
# A setting of 1 disables HTTP pipelining, since only one request per
# connection can be "open" (i.e. being processed by the application) at any time.
# This value must be > 0 and <= 1024.
# ATTENTION:
# Only enable HTTP pipelining if you _really_ know what you are doing. Nowadays, HTTP pipelining
# is mostly used for benchmarks anyway. Basically all web browser and most common clients (like curl)
# removed support for HTTP pipelining, since most client and server implementations were error prone.
# Also the implemention used by Play can cause unexpected behaviour, e.g. see
# https://github.com/playframework/playframework/issues/12351
pipelining-limit = 1
}
}
}HTTPサーバーとしてNettyを使用することもできます。Nettyにも独自の設定が用意されています。デフォルトを含むNettyサーバー設定の完全なリストは、以下をご覧ください。
# Copyright (C) from 2022 The Play Framework Contributors <https://github.com/playframework>, 2011-2021 Lightbend Inc. <https://www.lightbend.com>
play.server {
# The server provider class name
provider = "play.core.server.NettyServerProvider"
netty {
# The default value of the `Server` header to produce if no explicit `Server`-header was included in a response.
# If this value is the null and no header was included in the request, no `Server` header will be rendered at all.
server-header = null
server-header = ${?play.server.server-header}
# The number of event loop threads. 0 means let Netty decide, which by default will select 2 times the number of
# available processors.
eventLoopThreads = 0
# When Netty shuts down, it ensures that no tasks (requests) are submitted for 'the quiet period' before it finally shuts down.
# If a task is submitted during the quiet period, it is guaranteed to be accepted and the quiet period will start over.
#
# For more details see:
# https://netty.dokyumento.jp/4.1/api/io/netty/util/concurrent/EventExecutorGroup.html#shutdownGracefully-long-long-java.util.concurrent.TimeUnit-
#
# Play keeps using Netty's default of 2 seconds:
# https://github.com/netty/netty/blob/netty-4.1.92.Final/common/src/main/java/io/netty/util/concurrent/AbstractEventExecutor.java#L40
shutdownQuietPeriod = 2 seconds
# The maximum length of the initial line. This effectively restricts the maximum length of a URL that the server will
# accept, the initial line consists of the method (3-7 characters), the URL, and the HTTP version (8 characters),
# including typical whitespace, the maximum URL length will be this number - 18.
maxInitialLineLength = 4096
# The maximum length of body bytes that Netty will read into memory at a time.
# This is used in many ways. Note that this setting has no relation to HTTP chunked transfer encoding - Netty will
# read "chunks", that is, byte buffers worth of content at a time and pass it to Play, regardless of whether the body
# is using HTTP chunked transfer encoding. A single HTTP chunk could span multiple Netty chunks if it exceeds this.
# A body that is not HTTP chunked will span multiple Netty chunks if it exceeds this or if no content length is
# specified. This only controls the maximum length of the Netty chunk byte buffers.
maxChunkSize = 8192
# Whether the Netty wire should be logged
log.wire = false
# The transport to use, either jdk or native.
# Native socket transport has higher performance and produces less garbage but are only available on linux
transport = "jdk"
# Netty options. Possible keys here are defined by:
#
# https://netty.dokyumento.jp/4.1/api/io/netty/channel/ChannelOption.html
# For native socket transport:
# https://netty.dokyumento.jp/4.1/api/io/netty/channel/unix/UnixChannelOption.html
# https://netty.dokyumento.jp/4.1/api/io/netty/channel/epoll/EpollChannelOption.html
#
# Options that pertain to the listening server socket are defined at the top level, options for the sockets associated
# with received client connections are prefixed with child.*
option {
# Set the size of the backlog of TCP connections. The default and exact meaning of this parameter is JDK specific.
# SO_BACKLOG = 100
child {
# Set whether connections should use TCP keep alive
# SO_KEEPALIVE = false
# Set whether the TCP no delay flag is set
# TCP_NODELAY = false
# Example how to set native socket transport options
# (Full qualified class name + "#" + option)
# "io.netty.channel.unix.UnixChannelOption#SO_REUSEPORT" = true
# "io.netty.channel.ChannelOption#TCP_FASTOPEN" = 1
}
}
}
}**注**: Nettyサーバーバックエンドは2.6.xではデフォルトではないため、明示的に有効にする必要があります。
上記の設定はPekko HTTPおよびNettyサーバーバックエンドに固有のものですが、他のより一般的な設定も利用できます。
# Copyright (C) from 2022 The Play Framework Contributors <https://github.com/playframework>, 2011-2021 Lightbend Inc. <https://www.lightbend.com>
play {
server {
# The root directory for the Play server instance. This value can
# be set by providing a path as the first argument to the Play server
# launcher script. See `ServerConfig.loadConfiguration`.
dir = ${?user.dir}
# HTTP configuration
http {
# The HTTP port of the server. Use a value of "disabled" if the server
# shouldn't bind an HTTP port.
port = 9000
port = ${?PLAY_HTTP_PORT}
port = ${?http.port}
# The interface address to bind to.
address = "0.0.0.0"
address = ${?PLAY_HTTP_ADDRESS}
address = ${?http.address}
# The idle timeout for an open connection after which it will be closed
# Set to null or "infinite" to disable the timeout, but notice that this
# is not encouraged since timeout are important mechanisms to protect your
# servers from malicious attacks or programming mistakes.
idleTimeout = 75 seconds
}
# HTTPS configuration
https {
# The HTTPS port of the server.
port = ${?PLAY_HTTPS_PORT}
port = ${?https.port}
# The interface address to bind to
address = "0.0.0.0"
address = ${?PLAY_HTTPS_ADDRESS}
address = ${?https.address}
# The idle timeout for an open connection after which it will be closed
# Set to null or "infinite" to disable the timeout, but notice that this
# is not encouraged since timeout are important mechanisms to protect your
# servers from malicious attacks or programming mistakes.
idleTimeout = ${play.server.http.idleTimeout}
# The SSL engine provider
engineProvider = "play.core.server.ssl.DefaultSSLEngineProvider"
engineProvider = ${?play.http.sslengineprovider}
# HTTPS keystore configuration, used by the default SSL engine provider
keyStore {
# The path to the keystore
path = ${?https.keyStore}
# The type of the keystore
type = "JKS"
type = ${?https.keyStoreType}
# The password for the keystore
password = ""
password = ${?https.keyStorePassword}
# The algorithm to use. If not set, uses the platform default algorithm.
algorithm = ${?https.keyStoreAlgorithm}
}
# HTTPS truststore configuration
trustStore {
# If true, does not do CA verification on client side certificates
noCaVerification = false
}
# Whether JSSE want client auth mode should be used. This means, the server
# will request a client certificate, but won't fail if one isn't provided.
wantClientAuth = false
# Whether JSSE need client auth mode should be used. This means, the server
# will request a client certificate, and will fail and terminate the session
# if one isn't provided.
needClientAuth = false
}
# The path to the process id file created by the server when it runs.
# If set to "/dev/null" then no pid file will be created.
pidfile.path = ${play.server.dir}/RUNNING_PID
pidfile.path = ${?pidfile.path}
websocket {
# Maximum allowable frame payload length. Setting this value to your application's
# requirement may reduce denial of service attacks using long data frames.
frame.maxLength = 64k
frame.maxLength = ${?websocket.frame.maxLength}
# Periodic keep alive may be implemented using by sending Ping frames
# upon which the other side is expected to reply with a Pong frame,
# or by sending a Pong frame, which serves as unidirectional heartbeat.
# Valid values:
# ping - default, for bi-directional ping/pong keep-alive heartbeating
# pong - for uni-directional pong keep-alive heartbeating
periodic-keep-alive-mode = ping
# Interval for sending periodic keep-alives
# If a client does not send a frame within this idle time, the server will sent the the keep-alive frame.
# The frame sent will be the one configured in play.server.websocket.periodic-keep-alive-mode
# `infinite` by default, or a duration that is the max idle interval after which an keep-alive frame should be sent
# The value `infinite` means that *no* keep-alive heartbeat will be sent, as: "the allowed idle time is infinite"
periodic-keep-alive-max-idle = infinite
}
debug {
# If set to true this will attach an attribute to each request containing debug information. If the application
# fails to load (e.g. due to a compile issue in dev mode), then this configuration value is ignored and the debug
# information is always attached.
#
# Note: This configuration option is not part of Play's public API and is subject to change without the usual
# deprecation cycle.
addDebugInfoToRequests = false
}
# The maximum length of the HTTP headers. The most common effect of this is a restriction in cookie length, including
# number of cookies and size of cookie values.
max-header-size = 8k
# If a request contains a Content-Length header it will be checked against this maximum value.
# If the value of a given Content-Length header exceeds this configured value, the request will not be processed
# further but instead the error handler will be called with Http status code 413 "Entity too large".
# If set to infinite or if no Content-Length header exists then no check will take place at all
# and the request will continue to be processed.
# Play uses the concept of a `BodyParser` to enforce this limit, so we set it to infinite.
max-content-length = infinite
# Timeout after which all requests and connections shall be forcefully terminated
# when shutting down the server. When this timeout gets applied, already the server is not bound to ports
# and therefore not accepting new connections anymore. It will default to Coordinated Shutdown service-requests-done
# phase timeout. Because of that default, Play will trigger the timeout 100 milliseconds earlier than actually configured
# via this config to make sure it fires before the service-requests-done phase ends.
# Value must be a duration, for example:
# play.server.terminationTimeout = 5 seconds
# This should be less than or equal to the value for `pekko.coordinated-shutdown.phases.service-requests-done.timeout`
# to prevent early server terminations by the underlying Pekko Coordinated Shutdown system.
terminationTimeout = null
# The delay to wait before the server will shut down requests and connections via "graceful" termination. When
# this delay gets applied, already the server is not bound to ports and therefore not accepting new connections anymore.
# This config might help you do work around a bug which causes the pekko-http backend to not take response entity streams into account
# during graceful termination, giving those responses time to finish: https://github.com/akka/akka-http/issues/3209
# By default, no delay is applied.
# Value must be a duration, for example:
# play.server.waitBeforeTermination = 2 seconds
# Be aware that `waitBeforeTermination` and `terminationTimeout` both happen within the Coordinated Shutdown `service-requests-done` phase.
# Therefore, the total value of the two configs should not be longer than the total timeout of the `service-requests-done` phase.
waitBeforeTermination = 0
# If body parsing should happen before executing actions defined via action composition (default) or if it should
# be deferred to a later point in time.
# Depending on the used Play plugin (PlayScala or PlayJava), setting this config to true will behave slightly differently.
# Please see the docs for more details:
# PlayScala
# https://playframework.com/documentation/latest/ScalaActionsComposition#Action-composition-in-interaction-with-body-parsing
# PlayJava
# https://playframework.com/documentation/latest/JavaActionsComposition#Action-composition-in-interaction-with-body-parsing
deferBodyParsing = false
}
editor = ${?PLAY_EDITOR}
}§ロギング設定
ロギングは、logback設定ファイルを作成することで設定できます。これは、次の方法でアプリケーションで使用できます。
§カスタムlogback設定ファイルをアプリケーションにバンドルする
logback.xmlという名前の代替logback設定ファイルを作成し、それを<app>/confにコピーします。
システムプロパティを介して別のlogback設定ファイルを指定することもできます。設定ファイルが指定されていない場合、Playは本番モードでPlayに付属のデフォルトのlogback.xmlを使用することに注意してください。これは、application.confファイルのログレベル設定がオーバーライドされることを意味します。良い習慣として、常にlogback.xmlを指定してください。
§-Dlogger.resourceの使用
クラスパスからロードする別のlogback設定ファイルを指定します。
$ /path/to/bin/<project-name> -Dlogger.resource=prod-logger.xml
§-Dlogger.fileの使用
ファイルシステムからロードする別のlogback設定ファイルを指定します。
$ /path/to/bin/<project-name> -Dlogger.file=/opt/prod/prod-logger.xml
§-Dlogger.urlの使用
URLからロードする別のlogback設定ファイルを指定します。
$ /path/to/bin/<project-name> -Dlogger.url=http://conf.mycompany.com/logger.xml
**注**: 使用されているファイルを確認するには、システムプロパティをデバッグに設定します：
-Dlogback.debug=true。
§JVM設定
アプリケーション起動スクリプトにJVM引数を指定できます。それ以外の場合、デフォルトのJVM設定が使用されます。
$ /path/to/bin/<project-name> -J-Xms128M -J-Xmx512m -J-server
**次:** フロントエンドHTTPサーバーのセットアップ
このドキュメントに誤りを見つけましたか？このページのソースコードはこちらにあります。ドキュメントガイドラインを読んだ後、プルリクエストを送信してください。質問やアドバイスはありますか？コミュニティフォーラムにアクセスして、コミュニティとの会話を開始してください。