Create or update index template API
editCreate or update index template API
editCreates or updates an index template. Index templates define settings, mappings, and aliases that can be applied automatically to new indices.
response = client.indices.put_index_template( name: 'template_1', body: { index_patterns: [ 'te*' ], priority: 1, template: { settings: { number_of_shards: 2 } } } ) puts response
PUT /_index_template/template_1 { "index_patterns" : ["te*"], "priority" : 1, "template": { "settings" : { "number_of_shards" : 2 } } }
Request
editPUT /_index_template/<index-template>
Prerequisites
edit-
If the Elasticsearch security features are enabled, you must have the
manage_index_templates
ormanage
cluster privilege to use this API.
Description
editElasticsearch applies templates to new indices based on an wildcard pattern that matches the index name.
Index templates are applied during data stream or index creation. For data streams, these settings and mappings are applied when the stream’s backing indices are created.
Settings and mappings specified in a create index request override any settings or mappings specified in an index template.
Changes to index templates do not affect existing indices, including the existing backing indices of a data stream.
Comments in index templates
editYou can use C-style /* */ block comments in index templates. You can include comments anywhere in the request body, except before the opening curly bracket.
Path parameters
edit-
<index-template>
- (Required, string) Name of the index template to create.
Query parameters
edit-
create
-
(Optional, Boolean)
If
true
, this request cannot replace or update existing index templates. Defaults tofalse
. -
master_timeout
-
(Optional, time units)
Period to wait for a connection to the master node. If no response is received
before the timeout expires, the request fails and returns an error. Defaults to
30s
.
Request body
edit-
composed_of
- (Optional, array of strings) An ordered list of component template names. Component templates are merged in the order specified, meaning that the last component template specified has the highest precedence. See Composing multiple component templates for an example.
-
data_stream
-
(Optional, object) If this object is included, the template is used to create data streams and their backing indices. Supports an empty object.
Data streams require a matching index template with a
data_stream
object. See create an index template.Properties of
data_stream
-
allow_custom_routing
-
(Optional, Boolean) If
true
, the data stream supports custom routing. Defaults tofalse
. -
hidden
-
(Optional, Boolean) If
true
, the data stream is hidden. Defaults tofalse
. -
index_mode
-
(Optional, string) Type of data stream to create. Valid values are
null
(regular data stream) andtime_series
(time series data stream).If
time_series
, each backing index has anindex.mode
index setting oftime_series
.
-
-
index_patterns
-
(Required, array of strings) Array of wildcard (
*
) expressions used to match the names of data streams and indices during creation.Elasticsearch includes several built-in index templates. To avoid naming collisions with these templates, see Avoid index pattern collisions.
-
_meta
- (Optional, object) Optional user metadata about the index template. May have any contents. This map is not automatically generated by Elasticsearch.
-
priority
- (Optional, integer) Priority to determine index template precedence when a new data stream or index is created. The index template with the highest priority is chosen. If no priority is specified the template is treated as though it is of priority 0 (lowest priority). This number is not automatically generated by Elasticsearch.
-
template
-
(Optional, object) Template to be applied. It may optionally include an
aliases
,mappings
, orsettings
configuration.Properties of
template
-
aliases
-
(Optional, object of objects) Aliases to add.
If the index template includes a
data_stream
object, these are data stream aliases. Otherwise, these are index aliases. Data stream aliases ignore theindex_routing
,routing
, andsearch_routing
options.Properties of
aliases
objects-
<alias>
-
(Required, object) The key is the alias name. Index alias names support date math.
The object body contains options for the alias. Supports an empty object.
Properties of
<alias>
-
filter
- (Optional, Query DSL object) Query used to limit documents the alias can access.
-
index_routing
-
(Optional, string) Value used to route indexing operations to a specific shard.
If specified, this overwrites the
routing
value for indexing operations. -
is_hidden
-
(Optional, Boolean) If
true
, the alias is hidden. Defaults tofalse
. All indices for the alias must have the sameis_hidden
value. -
is_write_index
-
(Optional, Boolean) If
true
, the index is the write index for the alias. Defaults tofalse
. -
routing
- (Optional, string) Value used to route indexing and search operations to a specific shard.
-
search_routing
-
(Optional, string) Value used to route search operations to a specific shard. If
specified, this overwrites the
routing
value for search operations.
-
-
-
mappings
-
(Optional, mapping object) Mapping for fields in the index. If specified, this mapping can include:
- Field names
- Field data types
- Mapping parameters
See Mapping.
-
settings
- (Optional, index setting object) Configuration options for the index. See Index Settings.
-
-
version
- (Optional, integer) Version number used to manage index templates externally. This number is not automatically generated by Elasticsearch.
-
deprecated
- (Optional, boolean) Marks this index template as deprecated. When creating or updating a non-deprecated index template that uses deprecated components, Elasticsearch will emit a deprecation warning.
Examples
editIndex template with index aliases
editYou can include index aliases in an index template.
Multiple matching templates
editIf multiple index templates match the name of a new index or data stream, the template with the highest priority is used. For example:
PUT /_index_template/template_1 { "index_patterns" : ["t*"], "priority" : 0, "template": { "settings" : { "number_of_shards" : 1, "number_of_replicas": 0 }, "mappings" : { "_source" : { "enabled" : false } } } } PUT /_index_template/template_2 { "index_patterns" : ["te*"], "priority" : 1, "template": { "settings" : { "number_of_shards" : 2 }, "mappings" : { "_source" : { "enabled" : true } } } }
For indices that start with te*
, _source
will enabled, and the index will have two primary
shards and one replica, because only template_2
will be applied.
Multiple templates with overlapping index patterns at the same priority are not allowed, and an error will be thrown when attempting to create a template matching an existing index template at identical priorities.
Template versioning
editYou can use the version
parameter to add a version number to an index template.
External systems can use these version numbers to simplify template management.
The version
parameter is optional and not automatically generated or used by Elasticsearch.
To unset a version
, replace the template without specifying one.
response = client.indices.put_index_template( name: 'template_1', body: { index_patterns: [ 'foo', 'bar' ], priority: 0, template: { settings: { number_of_shards: 1 } }, version: 123 } ) puts response
PUT /_index_template/template_1 { "index_patterns" : ["foo", "bar"], "priority" : 0, "template": { "settings" : { "number_of_shards" : 1 } }, "version": 123 }
To check the version
, you can use the get index template API.
Template metadata
editYou can use the _meta
parameter to add arbitrary metadata to an index template.
This user-defined object is stored in the cluster state,
so keeping it short is preferable.
The _meta
parameter is optional and not automatically generated or used by Elasticsearch.
To unset _meta
, replace the template without specifying one.
response = client.indices.put_index_template( name: 'template_1', body: { index_patterns: [ 'foo', 'bar' ], template: { settings: { number_of_shards: 3 } }, _meta: { description: 'set number of shards to three', serialization: { class: 'MyIndexTemplate', id: 17 } } } ) puts response
PUT /_index_template/template_1 { "index_patterns": ["foo", "bar"], "template": { "settings" : { "number_of_shards" : 3 } }, "_meta": { "description": "set number of shards to three", "serialization": { "class": "MyIndexTemplate", "id": 17 } } }
To check the _meta
, you can use the get index template API.
Data stream definition
editTo use an index template for data streams, the template must include a
data_stream
object. See create an index template.
response = client.indices.put_index_template( name: 'template_1', body: { index_patterns: [ 'logs-*' ], data_stream: {} } ) puts response
PUT /_index_template/template_1 { "index_patterns": ["logs-*"], "data_stream": { } }
Composing aliases, mappings, and settings
editWhen multiple component templates are specified in the composed_of
field for an index template,
they are merged in the order specified, meaning that later component templates override earlier
component templates. Any mappings, settings, or aliases from the parent index template are merged
in next. Finally, any configuration on the index request itself is merged.
In this example, the order of the two component templates changes the number of shards for an index:
PUT /_component_template/template_with_2_shards { "template": { "settings": { "index.number_of_shards": 2 } } } PUT /_component_template/template_with_3_shards { "template": { "settings": { "index.number_of_shards": 3 } } } PUT /_index_template/template_1 { "index_patterns": ["t*"], "composed_of": ["template_with_2_shards", "template_with_3_shards"] }
In this case, an index matching t*
will have three primary shards. If the order of composed
templates were reversed, the index would have two primary shards.
Mapping definitions are merged recursively, which means that later mapping components can introduce new field mappings and update the mapping configuration. If a field mapping is already contained in an earlier component, its definition will be completely overwritten by the later one.
This recursive merging strategy applies not only to field mappings, but also root options like
dynamic_templates
and meta
. If an earlier component contains a dynamic_templates
block,
then by default new dynamic_templates
entries are appended onto the end. If an entry already
exists with the same key, then it is overwritten by the new definition.