6.1.1
Elasticsearch is a distributed, RESTful search and analytics engine capable of solving a growing number of use cases. As the heart of the Elastic Stack, it centrally stores your data so you can discover the expected and uncover the unexpected. This image uses search-guard instead of shield to handle trusted users.
This solution focuses on running a dockerized version of elasticsearch in the Google Compute Engine. It has the following preinstalled and preconfigured plugins:
- SearchGuard
- Xpack
- Gce Discovery
Configure it for your needs through the gce.env file. Make sure you have an environment variable PROJECT_ID defined with your google project ID and gcloud is insalled and configured.
Make sure you have gcloud installed and configured. Look up the suppored build options in the Makefile
The default target would build the docker image, push it to your gcr.io and create a cluster in your project.
The build process will create the elastic.env which will have all the user passwords and environment variables provided to the cluster.
Log level from witch elasticsearch echoes logs.
ES cluster name.
This setting tells Elasticsearch to not elect a master unless there are enough master-eligible nodes available. Only then will an election take place.
We recommand to set this variable to (number of nodes / 2) + 1
List of hosts for node discovery (discovery.zen.ping.unicast.hosts)
ES cluster name.
Set to true (default) makes it eligible to be elected as the master node, which controls the cluster.
Data nodes hold data and perform data related operations such as CRUD, search, and aggregations.
Ingest nodes are able to apply an ingest pipeline to a document in order to transform and enrich the document before indexing. With a heavy ingest load, it makes sense to use dedicated ingest nodes and to mark the master and data nodes as NODE_INGEST: false
.
http can be completely disabled and not started by setting HTTP_ENABLE to false. Elasticsearch nodes (and Java clients) communicate internally using the transport interface, not HTTP. It might make sense to disable the http layer entirely on nodes which are not meant to serve REST requests directly. For instance, you could disable HTTP on data-only nodes if you also have client nodes which are intended to serve all REST requests. Be aware, however, that you will not be able to send any REST requests (eg to retrieve node stats) directly to nodes which have HTTP disabled.
Enable or disable cross-origin resource sharing, i.e. whether a browser on another origin can execute requests against Elasticsearch. Note that if the client does not send a pre-flight request with an Origin header or it does not check the response headers from the server to validate the Access-Control-Allow-Origin response header, then cross-origin security is compromised.
Which origins to allow. Note that * is a valid value but is considered a security risk as your elasticsearch instance is open to cross origin requests from anywhere.
The node will bind to this hostname or IP address and advertise this host to other nodes in the cluster. Accepts an IP address, hostname, a special value, or an array of any combination of these.
Defines the memory available to the JVM.
password for built-in user elastic.
password for built-in user kibana.
password for built-in user logstash.
password for built-in user beats.
CA certificate passphrase.
Truststore(public keys storage) password.
Keystore(private key storage) password.
- If true then https is bound on 9200
- If false then http is bound on 9200
Configuration file is located in /etc/elasticsearch/elasticsearch.yml if you follow the same volume mapping as in the docker-compose example above.
If you have any problems with or questions about this image, please ask for help through a GitHub issue.