Index Templates

Index templates allow you to define templates that will automatically be applied to new indices created. The templates include both settings and mappings, and a simple pattern template that controls if the template will be applied to the index created. For example:

curl -XPUT localhost:9200/_template/template_1 -d '
{
    "template" : "te*",
    "settings" : {
        "number_of_shards" : 1
    },
    "mappings" : {
        "type1" : {
            "_source" : { "enabled" : false }
        }
    }
}
'

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

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

curl -XPUT localhost:9200/_template/template_1 -d '
{
    "template" : "te*",
    "settings" : {
        "number_of_shards" : 1
    },
    "aliases" : {
        "alias1" : {},
        "alias2" : {
            "filter" : {
                "term" : {"user" : "kimchy" }
            },
            "routing" : "kimchy"
        },
        "{index}-alias" : {} 
    }
}
'

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

curl -XDELETE localhost:9200/_template/template_1

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

curl -XGET localhost:9200/_template/template_1

You can also match several templates by using wildcards like:

curl -XGET localhost:9200/_template/temp*
curl -XGET localhost:9200/_template/template_1,template_2

To get list of all index templates you can run:

curl -XGET localhost:9200/_template/

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

curl -XHEAD -i localhost:9200/_template/template_1

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

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:

curl -XPUT localhost:9200/_template/template_1 -d '
{
    "template" : "*",
    "order" : 0,
    "settings" : {
        "number_of_shards" : 1
    },
    "mappings" : {
        "type1" : {
            "_source" : { "enabled" : false }
        }
    }
}
'

curl -XPUT localhost:9200/_template/template_2 -d '
{
    "template" : "te*",
    "order" : 1,
    "settings" : {
        "number_of_shards" : 1
    },
    "mappings" : {
        "type1" : {
            "_source" : { "enabled" : true }
        }
    }
}
'

The above will disable storing the _source on all type1 types, but for indices of 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.

Index templates can also be placed within the config location (path.conf) under the templates directory (note, make sure to place them on all master eligible nodes). For example, a file called template_1.json can be placed under config/templates and it will be added if it matches an index. Here is a sample of the mentioned file:

{
    "template_1" : {
        "template" : "*",
        "settings" : {
            "index.number_of_shards" : 2
        },
        "mappings" : {
            "_default_" : {
                "_source" : {
                    "enabled" : false
                }
            },
            "type1" : {
                "_all" : {
                    "enabled" : false
                }
            }
        }
    }
}

Please note that templates added this way will not appear in the /_template/* API request.