honeymoose/OpenSearch
1
0
Fork 0
mirror of https://github.com/honeymoose/OpenSearch.git synced 2025-02-22 12:56:53 +00:00
Code Issues Packages Projects Releases Wiki Activity

Clarify development vs. production mode

Browse Source 
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
1 changed files with 34 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
docs/reference/setup/bootstrap-checks.asciidoc
View File

@ -23,39 +23,43 @@ documented individually.
[float]
=== Development vs. production mode
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. 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
Elasticsearch 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.
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. To join a cluster, an Elasticsearch node must be
reachable via transport communication. To join a cluster over an external
network interface, a node must bind transport to an external interface and not
be using <<single-node-discovery,single-node discovery>>. Thus, we consider an
Elasticsearch node to be in development mode if it can not form a cluster with
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
<<modules-http,`http.host`>> and <<modules-transport,`transport.host`>>;
this can be useful for configuring a single instance to be reachable via
HTTP for testing purposes without triggering production mode.
Note that HTTP and transport can be configured independently via
<<modules-http,`http.host`>> and <<modules-transport,`transport.host`>>; this
can be useful for configuring a single node to be reachable via HTTP for testing
purposes without triggering production mode.
We recognize that some users need to bind transport to an external
interface for testing their usage of the transport client. For this
situation, we provide the 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 form a cluster with any other
node.
[[single-node-discovery]]
[float]
=== Single-node discovery
We recognize that some users need to bind transport to an external interface for
testing their usage of the transport client. For this situation, we provide the
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
interface, or by binding transport to an external interface and setting
the discovery type to `single-node`). For this situation, you can force
execution of the bootstrap checks by setting the system property
`es.enforce.bootstrap.checks` to `true` (set this in <<jvm-options>>, or
by adding `-Des.enforce.bootstrap.checks=true` to the environment
variable `ES_JAVA_OPTS`). We strongly encourage you to do 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.
[float]
=== Forcing the bootstrap checks
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 interface, or
by binding transport to an external interface and setting the discovery type to
`single-node`). For this situation, you can force execution of the bootstrap
checks by setting the system property `es.enforce.bootstrap.checks` to `true`
(set this in <<jvm-options>>, or by adding `-Des.enforce.bootstrap.checks=true`
to the environment variable `ES_JAVA_OPTS`). We strongly encourage you to do
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