Clarify production mode for bootstrap checks
This commit clarifies that production mode for the bootstrap checks is only tripped if transport is bound to an external interface. Relates #21220
This commit is contained in:
parent
c10a6ddec1
commit
1d8d8ea55f
|
@ -23,14 +23,20 @@ documented individually.
|
|||
[float]
|
||||
=== Development vs. production mode
|
||||
|
||||
By default, Elasticsearch binds and publishes to `localhost`. This is
|
||||
By default, Elasticsearch binds to `localhost` for <<modules-http,HTTP>>
|
||||
and <<modules-transport,transport (internal)>> communication. This is
|
||||
fine for downloading and playing with Elasticsearch, and everyday
|
||||
development but it's useless for production systems. For a production
|
||||
installation to be reachable, it must either bind or publish to an
|
||||
external interface. Thus, we consider Elasticsearch to be in development
|
||||
mode if it does not bind nor publish to an external interface (the
|
||||
default), and is otherwise in production mode if it does bind or publish
|
||||
to an external interface.
|
||||
development but it's useless for production systems. To form a cluster,
|
||||
Elasticsearch instances must be reachable via transport communication so
|
||||
they must bind transport to an external interface. Thus, we consider an
|
||||
Elaticsearch instance to be in development mode if it does not bind
|
||||
transport to an external interface (the default), and is otherwise in
|
||||
production mode if it does bind transport to an external interface. Note
|
||||
that HTTP can be configured independently of transport via
|
||||
<<modules-http,`http.host>> and
|
||||
<<modules-transport,`transport.tcp.host`>>; this can be useful for
|
||||
configuring a single instance to be reachable via HTTP for testing
|
||||
purposes without triggering production mode.
|
||||
|
||||
=== Heap size check
|
||||
|
||||
|
|
Loading…
Reference in New Issue