Add docs on what activates task execution (#8936)

This commit is contained in:
Kim Ngo 2020-10-13 11:47:30 -05:00 committed by GitHub
parent 646e1f369c
commit 30993a7495
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 26 additions and 20 deletions

View File

@ -33,7 +33,7 @@ task {
version = "1.0.0"
providers = ["myprovider"]
services = ["web", "api"]
wait {
buffer_period {
min = "10s"
}
}

View File

@ -124,24 +124,7 @@ variable "services" {
}
```
Keys of the `services` map are unique identifiers of the service across Consul agents and data centers. Keys follow the format `service-id.node.datacenter` (or `service-id.node.namespace.datacenter` for Consul Enterprise).
| Attribute | Description |
| -- | -- |
| `id` | A unique Consul ID for this service. This is unique per Consul agent. |
| `name` | The logical name of the service. Many service instances may share the same logical service name. |
| `address` | IP address of the service host -- if empty, node address should be used. |
| `port` | Port number of the service |
| `meta` | List of user-defined metadata key/value pairs for the service |
| `tags` | List of tags for the service |
| `namespace` | Consul Enterprise namespace of the service instance |
| `status` | Representative status for the service instance based on an aggregate of the list of health checks |
| `node` | Name of the Consul node on which the service is registered |
| `node_id` | ID of the node on which the service is registered. |
| `node_address` | The IP address of the Consul node on which the service is registered. |
| `node_datacenter` | Data center of the Consul node on which the service is registered. |
| `node_tagged_addresses` | List of explicit LAN and WAN IP addresses for the agent |
| `node_meta` | List of user-defined metadata key/value pairs for the node |
Keys of the `services` map are unique identifiers of the service across Consul agents and data centers. Keys follow the format `service-id.node.datacenter` (or `service-id.node.namespace.datacenter` for Consul Enterprise). A complete list of attributes available for the `services` variable is included in the [documentation for Consul-Terraform-Sync tasks](/docs/nia/tasks#task-execution).
Terraform variables when passed as module arguments can be [lossy for object types](https://www.terraform.io/docs/configuration/types.html#conversion-of-complex-types). This allows Consul-Terraform-Sync to declare the full variable with every object attribute in the generated root module, and pass the variable to a child module that contains a subset of these attributes for its variable declaration. Modules compatible with Consul-Terraform-Sync may simplify the services variable within the module by omitting unused attributes. For example, the following services variable has 4 attributes with the rest omitted.

View File

@ -23,8 +23,31 @@ task {
}
```
In the example task above, the "fake-firewall" and "null" providers, listed in the `providers` field, are used. These providers themselves should be configured in their own separate [provider blocks](/docs/nia/installation/configuration#provider). These providers are used in the Terraform module "example/firewll-policy/module", configured in the `source` field, to create, update, and destroy resources. This module may do something like use the providers to create and destroy firewall policy objects based on IP addresses. The IP addresses come from the "web" and "image" service instances configured in the `services` field. This service-level information is retrieved by Consul-Terraform-Sync which watches Consul catalog for changes.
In the example task above, the "fake-firewall" and "null" providers, listed in the `providers` field, are used. These providers themselves should be configured in their own separate [provider blocks](/docs/nia/installation/configuration#provider). These providers are used in the Terraform module "example/firewall-policy/module", configured in the `source` field, to create, update, and destroy resources. This module may do something like use the providers to create and destroy firewall policy objects based on IP addresses. The IP addresses come from the "web" and "image" service instances configured in the `services` field. This service-level information is retrieved by Consul-Terraform-Sync which watches Consul catalog for changes.
See [task configuration](/docs/nia/installation/configuration#task) for more details on how to configure a task.
## Task Execution
A task is executed when any change of information for services the task is configured for is detected from the Consul catalog. Execution could include one or more changes to service values, like IP address, added or removed service instance, or tags. A complete list of values that would cause a task to run are expanded below:
| Attribute | Description |
| -- | -- |
| `id` | A unique Consul ID for this service. This is unique per Consul agent. |
| `name` | The logical name of the service. Many service instances may share the same logical service name. |
| `address` | IP address of the service host -- if empty, node address should be used. |
| `port` | Port number of the service |
| `meta` | List of user-defined metadata key/value pairs for the service |
| `tags` | List of tags for the service |
| `namespace` | Consul Enterprise namespace of the service instance |
| `status` | Representative status for the service instance based on an aggregate of the list of health checks |
| `node` | Name of the Consul node on which the service is registered |
| `node_id` | ID of the node on which the service is registered. |
| `node_address` | The IP address of the Consul node on which the service is registered. |
| `node_datacenter` | Data center of the Consul node on which the service is registered. |
| `node_tagged_addresses` | List of explicit LAN and WAN IP addresses for the agent |
| `node_meta` | List of user-defined metadata key/value pairs for the node |
Consul-Terraform-Sync automatically generates any files needed to execute the network driver for each task. See [network drivers](/docs/nia/network-drivers) for more details on the files generated for the Terraform driver.
A [buffer period](/docs/nia/installation/configuration#buffer_period-1) can be configured for tasks to accumulate changes before executing the task. This helps reduce number of times a task is immediately executed by batching changes for a short duration of time.