Bläddra i källkod

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
Jason Tedor 8 år sedan
förälder
incheckning
279be13a00
1 ändrade filer med 37 tillägg och 33 borttagningar
  1. 37 33
      docs/reference/setup/bootstrap-checks.asciidoc

+ 37 - 33
docs/reference/setup/bootstrap-checks.asciidoc

@@ -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.
-
-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.
-
-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.
-
-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.
+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 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.
+
+[[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.
+
+
+[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