label
Terraform module designed to generate consistent names and tags for resources. Use `terraform-null-label` to implement a strict naming convention. There are 6 inputs considered "labels" or "ID elements" (because the labels are used to construct the ID): 1. namespace 1. tenant 1. environment 1. stage 1. name 1. attributes This module generates IDs using the following convention by default: `{namespace}-{environment}-{stage}-{name}-{attributes}`. However, it is highly configurable. The delimiter (e.g. `-`) is configurable. Each label item is optional (although you must provide at least one). So if you prefer the term `stage` to `environment` and do not need `tenant`, you can exclude them and the label `id` will look like `{namespace}-{stage}-{name}-{attributes}`. - The `tenant` label was introduced in v0.25.0. To preserve backward compatibility, it is not included by default. - The `attributes` input is actually a list of strings and `{attributes}` expands to the list elements joined by the delimiter. - If `attributes` is excluded but `namespace`, `stage`, and `environment` are included, `id` will look like `{namespace}-{environment}-{stage}-{name}`. Excluding `attributes` is discouraged, though, because attributes are the main way modules modify the ID to ensure uniqueness when provisioning the same resource types. - If you want the label items in a different order, you can specify that, too, with the `label_order` list. - You can set a maximum length for the `id`, and the module will create a (probably) unique name that fits within that length. (The module uses a portion of the MD5 hash of the full `id` to represent the missing part, so there remains a slight chance of name collision.) - You can control the letter case of the generated labels which make up the `id` using `var.label_value_case`. - By default, all of the non-empty labels are also exported as tags, whether they appear in the `id` or not. You can control which labels are exported as tags by setting `labels_as_tags` to the list of labels you want exported, or the empty list `[]` if you want no labels exported as tags at all. Tags passed in via the `tags` variable are always exported, and regardless of settings, empty labels are never exported as tags. You can control the case of the tag names (keys) for the labels using `var.label_key_case`. Unlike the tags generated from the label inputs, tags passed in via the `tags` input are not modified. There is an unfortunate collision over the use of the key `name`. Cloud Posse uses `name` in this module to represent the component, such as `eks` or `rds`. AWS uses a tag with the key `Name` to store the full human-friendly identifier of the thing tagged, which this module outputs as `id`, not `name`. So when converting input labels to tags, the value of the `Name` key is set to the module `id` output, and there is no tag corresponding to the module `name` output. An empty `name` label will not prevent the `Name` tag from being exported. It's recommended to use one `terraform-null-label` module for every unique resource of a given resource type. For example, if you have 10 instances, there should be 10 different labels. However, if you have multiple different kinds of resources (e.g. instances, security groups, file systems, and elastic ips), then they can all share the same label assuming they are logically related. For most purposes, the `id` output is sufficient to create an ID or label for a resource, and if you want a different ID or a different format, you would instantiate another instance of `null-label` and configure it accordingly. However, to accomodate situations where you want all the same inputs to generate multiple descriptors, this module provides the `descriptors` output, which is a map of strings generated according to the format specified by the `descriptor_formats` input. This feature is intentionally simple and minimally configurable and will not be enhanced to add more features that are already in `null-label`. See [examples/complete/descriptors.tf](https://github.com/cloudposse/terraform-null-label/tree/main/examples/complete/descriptors.tf) for examples. All [Cloud Posse Terraform modules](https://github.com/cloudposse?utf8=%E2%9C%93&q=terraform-&type=&language=) use this module to ensure resources can be instantiated multiple times within an account and without conflict. The Cloud Posse convention is to use labels as follows: - `namespace`: A short (3-4 letters) abbreviation of the company name, to ensure globally unique IDs for things like S3 buckets - `tenant`: _(Rarely needed)_ When a company creates a dedicated resource per customer, `tenant` can be used to identify the customer the resource is dedicated to - `environment`: A [short abbreviation](https://github.com/cloudposse/terraform-aws-utils/#introduction) for the AWS region hosting the resource, or `gbl` for resources like IAM roles that have no region - `stage`: The name or role of the account the resource is for, such as `prod` or `dev` - `name`: The name of the component that owns the resources, such as `eks` or `rds` **NOTE:** The `null` originally referred to the primary Terraform [provider](https://www.terraform.io/docs/providers/null/index.html) used in this module. With Terraform 0.12, this module no longer needs any provider, but the name was kept for continuity. - Releases of this module from `0.23.0` onward only work with Terraform 0.13 or newer. - Releases of this module from `0.12.0` through `0.22.1` support `HCL2` and are compatible with Terraform 0.12 or newer. - Releases of this module prior to `0.12.0` are compatible with earlier versions of terraform like Terraform 0.11.