Index Templates

edit

Index templates allow you to define templates that will automatically be applied when new indices are created. The templates include both settings and mappings and a simple pattern template that controls whether the template should be applied to the new index.

Templates are only applied at index creation time. Changing a template will have no impact on existing indices. When using the create index API, the settings/mappings defined as part of the create index call will take precedence over any matching settings/mappings defined in the template.

For example:

PUT _template/template_1
{
  "index_patterns": ["te*", "bar*"],
  "settings": {
    "number_of_shards": 1
  },
  "mappings": {
    "_source": {
      "enabled": false
    },
    "properties": {
      "host_name": {
        "type": "keyword"
      },
      "created_at": {
        "type": "date",
        "format": "EEE MMM dd HH:mm:ss Z yyyy"
      }
    }
  }
}

Index templates provide C-style /* */ block comments. Comments are allowed everywhere in the JSON document except before the initial opening curly bracket.

Defines a template named template_1, with a template pattern of te* or bar*. The settings and mappings will be applied to any index name that matches the te* or bar* pattern.

It is also possible to include aliases in an index template as follows:

PUT _template/template_1
{
    "index_patterns" : ["te*"],
    "settings" : {
        "number_of_shards" : 1
    },
    "aliases" : {
        "alias1" : {},
        "alias2" : {
            "filter" : {
                "term" : {"user" : "kimchy" }
            },
            "routing" : "kimchy"
        },
        "{index}-alias" : {} 
    }
}

the {index} placeholder in the alias name will be replaced with the actual index name that the template gets applied to, during index creation.

Deleting a Template

edit

Index templates are identified by a name (in the above case template_1) and can be deleted as well:

DELETE /_template/template_1

Getting templates

edit

Index templates are identified by a name (in the above case template_1) and can be retrieved using the following:

GET /_template/template_1

You can also match several templates by using wildcards like:

GET /_template/temp*
GET /_template/template_1,template_2

To get list of all index templates you can run:

GET /_template

Template exists

edit

Used to check if the template exists or not. For example:

HEAD _template/template_1

The HTTP status code indicates if the template with the given name exists or not. Status code 200 means it exists and 404 means it does not.

Before 7.0.0, the mappings definition used to include a type name. Although mappings no longer contain a type name by default, you can still use the old format by setting the parameter include_type_name. For more details, please see Removal of mapping types.

Multiple Templates Matching

edit

Multiple index templates can potentially match an index, in this case, both the settings and mappings are merged into the final configuration of the index. The order of the merging can be controlled using the order parameter, with lower order being applied first, and higher orders overriding them. For example:

PUT /_template/template_1
{
    "index_patterns" : ["*"],
    "order" : 0,
    "settings" : {
        "number_of_shards" : 1
    },
    "mappings" : {
        "_source" : { "enabled" : false }
    }
}

PUT /_template/template_2
{
    "index_patterns" : ["te*"],
    "order" : 1,
    "settings" : {
        "number_of_shards" : 1
    },
    "mappings" : {
        "_source" : { "enabled" : true }
    }
}

The above will disable storing the _source, but for indices that start with te*, _source will still be enabled. Note, for mappings, the merging is "deep", meaning that specific object/property based mappings can easily be added/overridden on higher order templates, with lower order templates providing the basis.

Multiple matching templates with the same order value will result in a non-deterministic merging order.

Template Versioning

edit

Templates can optionally add a version number, which can be any integer value, in order to simplify template management by external systems. The version field is completely optional and it is meant solely for external management of templates. To unset a version, simply replace the template without specifying one.

PUT /_template/template_1
{
    "index_patterns" : ["*"],
    "order" : 0,
    "settings" : {
        "number_of_shards" : 1
    },
    "version": 123
}

To check the version, you can filter responses using filter_path to limit the response to just the version:

GET /_template/template_1?filter_path=*.version

This should give a small response that makes it both easy and inexpensive to parse:

{
  "template_1" : {
    "version" : 123
  }
}