Clarify development vs. production mode

The definition of development vs. production mode has evolved slightly
over time (with the introduction of single-node) discovery. This commit
clarifies the documentation to better account for this adjustment.

Relates #26460
This commit is contained in:
Jason Tedor 2017-09-02 09:47:39 -04:00 committed by GitHub
parent f8fc0f3ebe
commit 279be13a00

View File

@ -23,39 +23,43 @@ documented individually.
[float] [float]
=== Development vs. production mode === Development vs. production mode
By default, Elasticsearch binds to `localhost` for <<modules-http,HTTP>> By default, Elasticsearch binds to `localhost` for <<modules-http,HTTP>> and
and <<modules-transport,transport (internal)>> communication. This is <<modules-transport,transport (internal)>> communication. This is fine for
fine for downloading and playing with Elasticsearch, and everyday downloading and playing with Elasticsearch, and everyday development but it's
development but it's useless for production systems. To form a cluster, useless for production systems. To join a cluster, an Elasticsearch node must be
Elasticsearch instances must be reachable via transport communication so reachable via transport communication. To join a cluster over an external
they must bind transport to an external interface. Thus, we consider an network interface, a node must bind transport to an external interface and not
Elasticsearch instance to be in development mode if it does not bind be using <<single-node-discovery,single-node discovery>>. Thus, we consider an
transport to an external interface (the default), and is otherwise in Elasticsearch node to be in development mode if it can not form a cluster with
production mode if it does bind transport to an external interface. another machine over an external network interface, and is otherwise in
production mode if it can join a cluster over an external interface.
Note that HTTP can be configured independently of transport via Note that HTTP and transport can be configured independently via
<<modules-http,`http.host`>> and <<modules-transport,`transport.host`>>; <<modules-http,`http.host`>> and <<modules-transport,`transport.host`>>; this
this can be useful for configuring a single instance to be reachable via can be useful for configuring a single node to be reachable via HTTP for testing
HTTP for testing purposes without triggering production mode. purposes without triggering production mode.
We recognize that some users need to bind transport to an external [[single-node-discovery]]
interface for testing their usage of the transport client. For this [float]
situation, we provide the discovery type `single-node` (configure it by === Single-node discovery
setting `discovery.type` to `single-node`); in this situation, a node We recognize that some users need to bind transport to an external interface for
will elect itself master and will not form a cluster with any other testing their usage of the transport client. For this situation, we provide the
node. discovery type `single-node` (configure it by setting `discovery.type` to
`single-node`); in this situation, a node will elect itself master and will not
join a cluster with any other node.
If you are running a single node in production, it is possible to evade
the bootstrap checks (either by not binding transport to an external [float]
interface, or by binding transport to an external interface and setting === Forcing the bootstrap checks
the discovery type to `single-node`). For this situation, you can force If you are running a single node in production, it is possible to evade the
execution of the bootstrap checks by setting the system property bootstrap checks (either by not binding transport to an external interface, or
`es.enforce.bootstrap.checks` to `true` (set this in <<jvm-options>>, or by binding transport to an external interface and setting the discovery type to
by adding `-Des.enforce.bootstrap.checks=true` to the environment `single-node`). For this situation, you can force execution of the bootstrap
variable `ES_JAVA_OPTS`). We strongly encourage you to do this if you checks by setting the system property `es.enforce.bootstrap.checks` to `true`
are in this specific situation. This system property can be used to (set this in <<jvm-options>>, or by adding `-Des.enforce.bootstrap.checks=true`
force execution of the bootstrap checks independent of the node to the environment variable `ES_JAVA_OPTS`). We strongly encourage you to do
configuration. this if you are in this specific situation. This system property can be used to
force execution of the bootstrap checks independent of the node configuration.
=== Heap size check === Heap size check