Elasticsearch: Allow Setting to force Production Mode ON

Created on 29 Nov 2016  路  13Comments  路  Source: elastic/elasticsearch

There are some use cases where a reverse proxy is setup for communicating with Elasticsearch. Unfortunately, for those kind of scenarios, if the host is never changed from localhost, then it never gets into production mode.

It would be great for such users to be able to guarantee that production mode is on. It should simply only accept true (on) or undefined (current behavior).

node.production: true

Therefore this should cause an ironic error:

node.production: false
discuss

Most helpful comment

You'll see:

[2016-11-29T12:34:14,207][INFO ][o.e.b.BootstrapCheck     ] [_0x10gR] bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks

in the logs.

All 13 comments

There are some use cases where a reverse proxy is setup for communicating with Elasticsearch.

Are you talking about proxying HTTP and transport?

The comment came from a user in IRC. It sounds like they have a single node, and it's proxying only HTTP as a result.

I'm running that scenario exactly where nginx just acts as a reverse proxy for the node. The network config in elasticsearch.yml is:

network.host: 127.0.0.1
http.port: 9200

And nginx just reverse proxies it:

location ~ ^/es.*$ {
    proxy_pass http://localhost:9200;
    rewrite ^/es(.*) /$1 break;
}

Then just bind transport to non localhost and you'll force the bootstrap checks to run.

You can do this with:

transport.host: <non-loopback address>

and you do not even need to set network.host and http.port.

Will that work for pre-flight checks on local dev machines? e.g. 192.168.0.1?

Yes, binding transport to a non-loopback interface will force the bootstrap checks to run.

You'll see:

[2016-11-29T12:34:14,207][INFO ][o.e.b.BootstrapCheck     ] [_0x10gR] bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks

in the logs.

@pickypg @alfmatos Can I close this then?

I'm good with it since it provides an option for users. I do kind of like forcing it on directly though. :)

I do kind of like forcing it on directly though. :)

If it's not necessary, I'd rather not and just keep things simple. 馃槆

@jasontedor I agree with @pickypg as I like the concept of explicitly configuring the environment if necessary, like e.g. in rails expression the ENV=production or with --production.

Having said that, I got how it works, and can force it when needed.

I have reconsidered this and have opened #23585.

Was this page helpful?
0 / 5 - 0 ratings