Only Gold and Platinum subscriptions have access to uploading custom plugins. All subscription levels, including Standard, can upload scripts and dictionaries.
There are several cases where you might need your own files to be made available to your Elasticsearch cluster’s nodes:
- Your own custom plugins, or third-party plugins that are not amongst the officially available plugins.
- Custom dictionaries, such as synonyms, stop words, compound words, etc.
- Non-dynamic scripts, to safely use scripting.
To facilitate this, we make it possible to upload a zip file that contains the files you want to make available. Uploaded files are stored using Amazon’s highly available S3 service. This is necessary so we do not have to rely on the availability of third-party services such as the official plugin repository when provisioning nodes.
Files you upload are expected to be a zip file. Also, you need to choose whether your uploaded file should be treated as a plugin or as a bundle.
A plugin is a zip file that is installable as a plugin using Elasticsearch’s plugin tool. When configuring the node of your cluster, that is exactly what we do. We invoke the install-tool with the URL of the uploaded zip file. This makes it easy for you to test that your uploaded zip file works locally: just see if you can run bin/plugin --url file:///path/to/plugin --install plugin-name yourself.
Elasticsearch’s plugin tool assumes that the uploaded zip file contains binaries. If it finds any source code, it will fail with an error message, causing provisioning to fail. Make sure you upload binaries, and not source code.
A bundle’s entire content is made available to the node. This is useful to make custom dictionaries, scripts, etc. available.
Bundles are not installed as plugins. If you need to upload both a custom plugin and custom dictionaries, you will need to upload the plugin and dictionary separately.
Selected plugins/bundles are downloaded and provided when a node starts. Changing a plugin does not change it for nodes already running it. See Updating Plugins and Bundles.
With great power comes great responsibility: Your plugins can extend your cluster with new functionality, but also make it break. Be careful. We obviously cannot guarantee that your custom code works.
Uploaded files cannot be bigger than 20 MB, i.e. 20971520 bytes.
It is important that plugins and dictionaries that you reference in mappings and configurations are available at all times. If you try to upgrade Elasticsearch and for example de-select a dictionary that is referenced in your mapping, the new nodes will be unable to recover the cluster state and function. This is true even if the dictionary is referenced by an empty index you do not actually use.
We expect the scripts will be under /scripts and dictionaries under /dictionaries in the root of your zipped bundles.
Here is an example of two bundles which contain a script and a dictionary of synonyms.
$ tree .
.
└── scripts
└── test.groovyThe script test.groovy can be referred in queries as "script": "test".
$ tree .
.
└── dictionaries
└── synonyms.txtThe dictionary synonyms.txt can be used as synonyms.txt in the synonyms_path of the synonym-filter.
While you can update the zip file for any plugin or bundle, this will not update the files on nodes that are already using the plugin or bundle. These are downloaded and made available when a node is started.
For example, to upgrade a plugin or provide a new dictionary, we recommend creating a new plugin/bundle, make your new files available there, and select it when you re-configure your cluster. With this approach, you do not change something you know works, so you can easily roll back if your new files do not work as you expect.