docs: Fix spelling errors across website
This commit is contained in:
parent
901a5cdd8c
commit
4d2bc76d62
|
@ -616,7 +616,7 @@ This endpoint evaluates the intentions for a specific source and destination
|
|||
and returns whether the connection would be authorized or not given the current
|
||||
Consul configuration and set of intentions.
|
||||
|
||||
-> **Note:** This endpoint will always evaulate intentions with `Permissions`
|
||||
-> **Note:** This endpoint will always evaluate intentions with `Permissions`
|
||||
defined as _deny_ intentions during. This endpoint is only suited for
|
||||
networking layer 4 (e.g. TCP) integration.
|
||||
|
||||
|
|
|
@ -117,7 +117,7 @@ service "consul-snapshot" {
|
|||
</Tabs>
|
||||
|
||||
Additional `session` rules should be created, or `session_prefix` used, if the
|
||||
snapshot agent is deployed across more than one hosts.
|
||||
snapshot agent is deployed across more than one host.
|
||||
|
||||
## Usage
|
||||
|
||||
|
@ -281,7 +281,7 @@ Note that despite the AWS references, any S3-compatible endpoint can be specifie
|
|||
|
||||
- `-aws-s3-server-side-encryption` - Enables saving snapshots to S3 using server side encryption with [Amazon S3-Managed Encryption Keys](http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html)
|
||||
|
||||
- `-aws-s3-static-snapshot-name` - If this is given, all snapshots are saved with the same file name. The agent will not rotate or versionize snapshots, and will save them with the same name each time.
|
||||
- `-aws-s3-static-snapshot-name` - If this is given, all snapshots are saved with the same file name. The agent will not rotate or version snapshots, and will save them with the same name each time.
|
||||
Use this if you want to rely on [S3's versioning capabilities](http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html) instead of the agent handling it for you.
|
||||
|
||||
- `-aws-s3-enable-kms` - Enables using [Amazon KMS](https://aws.amazon.com/kms/) for encrypting snapshots.
|
||||
|
|
|
@ -265,7 +265,7 @@ The options below are all specified on the command-line.
|
|||
- `-log-file` ((#\_log_file)) - writes all the Consul agent log messages
|
||||
to a file. This value is used as a prefix for the log file name. The current timestamp
|
||||
is appended to the file name. If the value ends in a path separator, `consul-`
|
||||
will be appened to the value. If the file name is missing an extension, `.log`
|
||||
will be appended to the value. If the file name is missing an extension, `.log`
|
||||
is appended. For example, setting `log-file` to `/var/log/` would result in a log
|
||||
file path of `/var/log/consul-{timestamp}.log`. `log-file` can be combined with
|
||||
[`-log-rotate-bytes`](#_log_rotate_bytes) and [-log-rotate-duration](#_log_rotate_duration)
|
||||
|
@ -459,7 +459,7 @@ The options below are all specified on the command-line.
|
|||
segment.
|
||||
|
||||
- `-serf-lan-allowed-cidrs` ((#\_serf_lan_allowed_cidrs)) - The Serf LAN allowed CIDRs allow to accept incoming
|
||||
connections for Serf only from several networks (mutiple values are supported).
|
||||
connections for Serf only from several networks (multiple values are supported).
|
||||
Those networks are specified with CIDR notation (eg: 192.168.1.0/24).
|
||||
This is available in Consul 1.8 and later.
|
||||
|
||||
|
@ -468,7 +468,7 @@ The options below are all specified on the command-line.
|
|||
and later.
|
||||
|
||||
- `-serf-wan-allowed-cidrs` ((#\_serf_wan_allowed_cidrs)) - The Serf WAN allowed CIDRs allow to accept incoming
|
||||
connections for Serf only from several networks (mutiple values are supported).
|
||||
connections for Serf only from several networks (multiple values are supported).
|
||||
Those networks are specified with CIDR notation (eg: 192.168.1.0/24).
|
||||
This is available in Consul 1.8 and later.
|
||||
|
||||
|
@ -819,7 +819,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
|
|||
- `advertise_reconnect_timeout` This is a per-agent setting of the [`reconnect_timeout`](#reconnect_timeout) parameter.
|
||||
This agent will advertise to all other nodes in the cluster that after this timeout, the node may be completely
|
||||
removed from the cluster. This may only be set on client agents and if unset then other nodes will use the main
|
||||
`reconnect_timeout` setting when determing when this node may be removed from the cluster.
|
||||
`reconnect_timeout` setting when determining when this node may be removed from the cluster.
|
||||
|
||||
- `serf_lan` ((#serf_lan_bind)) Equivalent to the [`-serf-lan-bind` command-line flag](#_serf_lan_bind).
|
||||
|
||||
|
@ -958,7 +958,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
|
|||
client agent's TLS certificate. The `localhost` DNS SAN is always requested.
|
||||
|
||||
- `ip_sans` (Defaults to `[]`) This is a list of extra IP SANs to request in the
|
||||
client agent's TLS certficate. The `::1` and `127.0.0.1` IP SANs are always requested.
|
||||
client agent's TLS certificate. The `::1` and `127.0.0.1` IP SANs are always requested.
|
||||
|
||||
- `authorization` This object controls how a Consul server will authorize `auto_config`
|
||||
requests and in particular how to verify the JWT intro token.
|
||||
|
@ -1094,7 +1094,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
|
|||
- `bind_addr` Equivalent to the [`-bind` command-line flag](#_bind).
|
||||
|
||||
This parameter can be set to a go-sockaddr template that resolves to a single
|
||||
address. Special characters such as blackslashes `\` or double quotes `"`
|
||||
address. Special characters such as backslashes `\` or double quotes `"`
|
||||
within a double quoted string value must be escaped with a backslash `\`.
|
||||
Some example templates:
|
||||
|
||||
|
@ -1603,7 +1603,7 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr
|
|||
|
||||
- `leave_on_terminate` If enabled, when the agent receives a TERM signal, it will send a `Leave` message to the rest of the cluster and gracefully leave. The default behavior for this feature varies based on whether or not the agent is running as a client or a server (prior to Consul 0.7 the default value was unconditionally set to `false`). On agents in client-mode, this defaults to `true` and for agents in server-mode, this defaults to `false`.
|
||||
|
||||
- `license_path` <EnterpriseAlert inline /> This specifies the path to a file that contains the Consul Enterprise license. Alternatively the license may also be specified in either the `CONSUL_LICENSE` or `CONSUL_LICENSE_PATH` environment variables. See the [licensing documentation](/docs/enterprise/license/overview) for more information about Consul Enterprise license management. Added in versions 1.10.0, 1.9.7 and 1.8.13. Prior to version 1.10.0 the value may be set for all agents to faciliate forwards compatibility with 1.10 but will only actually be used by client agents.
|
||||
- `license_path` <EnterpriseAlert inline /> This specifies the path to a file that contains the Consul Enterprise license. Alternatively the license may also be specified in either the `CONSUL_LICENSE` or `CONSUL_LICENSE_PATH` environment variables. See the [licensing documentation](/docs/enterprise/license/overview) for more information about Consul Enterprise license management. Added in versions 1.10.0, 1.9.7 and 1.8.13. Prior to version 1.10.0 the value may be set for all agents to facilitate forwards compatibility with 1.10 but will only actually be used by client agents.
|
||||
|
||||
- `limits` Available in Consul 0.9.3 and later, this is a nested
|
||||
object that configures limits that are enforced by the agent. Prior to Consul 1.5.2,
|
||||
|
@ -1903,10 +1903,10 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr
|
|||
|
||||
- `circonus_submission_url` ((#telemetry-circonus_submission_url))
|
||||
The `check.config.submission_url` field, of a Check API object, from a previously
|
||||
created HTTPTRAP check.
|
||||
created HTTPTrap check.
|
||||
|
||||
- `circonus_check_id` ((#telemetry-circonus_check_id))
|
||||
The Check ID (not **check bundle**) from a previously created HTTPTRAP check.
|
||||
The Check ID (not **check bundle**) from a previously created HTTPTrap check.
|
||||
The numeric portion of the `check._cid` field in the Check API object.
|
||||
|
||||
- `circonus_check_force_metric_activation` ((#telemetry-circonus_check_force_metric_activation)) Force activation of metrics which already exist and are not currently active.
|
||||
|
@ -1936,7 +1936,7 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr
|
|||
portion of `broker._cid` field in a Broker API object. If metric management is
|
||||
enabled and neither a Submission URL nor Check ID is provided, an attempt will
|
||||
be made to search for an existing check using Instance ID and Search Tag. If
|
||||
one is not found, a new HTTPTRAP check will be created. By default, this is not
|
||||
one is not found, a new HTTPTrap check will be created. By default, this is not
|
||||
used and a random Enterprise Broker is selected, or the default Circonus Public
|
||||
Broker.
|
||||
|
||||
|
|
|
@ -98,7 +98,7 @@ These are some metrics emitted that can help you understand the health of your c
|
|||
|
||||
**What to look for:** Alert if `healthy` is 0. Some other indicators of an unhealthy cluster would be:
|
||||
- `consul.raft.commitTime` - This can help reflect the speed of state store
|
||||
changes being performmed by the agent. If this number is rising, the server may
|
||||
changes being performed by the agent. If this number is rising, the server may
|
||||
be experiencing an issue due to degraded resources on the host.
|
||||
- [Leadership change metrics](#leadership-changes) - Check for deviation from
|
||||
the recommended values. This can indicate failed leadership elections or
|
||||
|
@ -320,7 +320,7 @@ This is a full list of metrics emitted by Consul.
|
|||
| `consul.dns.domain_query.` | Measures the time spent handling a domain query for the given node. | ms | timer |
|
||||
| `consul.http...` | DEPRECATED IN 1.9: Tracks how long it takes to service the given HTTP request for the given verb and path. Paths do not include details like service or key names, for these an underscore will be present as a placeholder (eg. `consul.http.GET.v1.kv._`) | ms | timer |
|
||||
| `consul.system.licenseExpiration` | <EnterpriseAlert inline /> This measures the number of hours remaining on the agents license. | hours | gauge |
|
||||
| `consul.version` | Measures the count of running agents. | agents | guage |
|
||||
| `consul.version` | Measures the count of running agents. | agents | gauge |
|
||||
|
||||
## Server Health
|
||||
|
||||
|
@ -373,7 +373,7 @@ These metrics are used to monitor the health of the Consul servers.
|
|||
| `consul.raft.state.candidate` | Increments whenever a Consul server starts an election. If this increments without a leadership change occurring it could indicate that a single server is overloaded or is experiencing network connectivity issues. | election attempts / interval | counter |
|
||||
| `consul.raft.state.leader` | Increments whenever a Consul server becomes a leader. If there are frequent leadership changes this may be indication that the servers are overloaded and aren't meeting the soft real-time requirements for Raft, or that there are networking problems between the servers. | leadership transitions / interval | counter |
|
||||
| `consul.raft.state.follower` | Counts the number of times an agent has entered the follower mode. This happens when a new agent joins the cluster or after the end of a leader election. | follower state entered / interval | counter |
|
||||
| `consul.raft.transistion.heartbeat_timeout` | The number of times an agent has transitioned to the Candidate state, after receive no heartbeat messages from the last known leader. | timeouts / interval | counter |
|
||||
| `consul.raft.transition.heartbeat_timeout` | The number of times an agent has transitioned to the Candidate state, after receive no heartbeat messages from the last known leader. | timeouts / interval | counter |
|
||||
| `consul.raft.verify_leader` | Counts the number of times an agent checks whether it is still the leader or not | checks / interval | Counter |
|
||||
| `consul.rpc.accept_conn` | Increments when a server accepts an RPC connection. | connections | counter |
|
||||
| `consul.catalog.register` | Measures the time it takes to complete a catalog register operation. | ms | timer |
|
||||
|
|
|
@ -184,7 +184,7 @@ the following specific limitations:
|
|||
`domain` configured for its DNS interface. This might be relaxed in the
|
||||
future.
|
||||
- Tag filters for services are not currently supported (i.e.
|
||||
`tag1.web.service.consul`) however the same behaviour can be achieved using a
|
||||
`tag1.web.service.consul`) however the same behavior can be achieved using a
|
||||
prepared query.
|
||||
- External DNS names, raw IP addresses and so on will cause an error and should
|
||||
be fetched using a separate `HTTPClient`.
|
||||
|
|
|
@ -345,7 +345,7 @@ will continue to be supported.
|
|||
Must be one of `STRICT_DNS` or `LOGICAL_DNS`. Details for each type are available in
|
||||
the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/v1.17.2/intro/arch_overview/upstream/service_discovery).
|
||||
This option applies to terminating gateways that route to services
|
||||
addressed by a hostname, such as a managed databased. It also applies to mesh gateways,
|
||||
addressed by a hostname, such as a managed database. It also applies to mesh gateways,
|
||||
such as when gateways in other Consul datacenters are behind a load balancer that is addressed by a hostname.
|
||||
|
||||
## Advanced Configuration
|
||||
|
|
|
@ -88,7 +88,7 @@ restarting them if they crash. The lifecycle of the proxy process is decoupled
|
|||
from the agent so if the agent crashes or is restarted for an upgrade, the
|
||||
managed proxy instances will _not_ be stopped.
|
||||
|
||||
Note that this behaviour while desirable in production might leave proxy
|
||||
Note that this behavior while desirable in production might leave proxy
|
||||
processes running indefinitely if you manually stop the agent and clear its
|
||||
data dir during testing.
|
||||
|
||||
|
@ -164,7 +164,7 @@ use namespacing techniques provided by your operating system.
|
|||
|
||||
-> **Deprecation Note:** versions 1.2.0 to 1.3.0 required specifying `upstreams`
|
||||
as part of the opaque `config` that is passed to the proxy. However, since
|
||||
1.3.0, the `upstreams` configuration is now specified directily under the
|
||||
1.3.0, the `upstreams` configuration is now specified directly under the
|
||||
`proxy` key. Old service definitions using the nested config will continue to
|
||||
work and have the values copied into the new location. This allows the upstreams
|
||||
to be registered centrally rather than being part of the local-only config
|
||||
|
|
|
@ -54,7 +54,7 @@ connectInject:
|
|||
|
||||
It can also be enabled on a per namespace basis by setting the label `consul.hashicorp.com/transparent-proxy=true` on the
|
||||
Kubernetes namespace. This will override the Helm value `connectInject.transparentProxy.defaultEnabled` and define the
|
||||
default behaviour of Pods in the namespace. For example:
|
||||
default behavior of Pods in the namespace. For example:
|
||||
```bash
|
||||
kubectl label namespaces my-app "consul.hashicorp.com/transparent-proxy=true"
|
||||
```
|
||||
|
|
|
@ -64,7 +64,7 @@ There are several different kinds of checks:
|
|||
Certificate verification can be turned off by setting the `tls_skip_verify`
|
||||
field to `true` in the check definition. When using TLS, the SNI will be set
|
||||
automatically from the URL if it uses a hostname (as opposed to an IP address);
|
||||
the value can be overriden by setting `tls_server_name`.
|
||||
the value can be overridden by setting `tls_server_name`.
|
||||
|
||||
- `TCP + Interval` - These checks make a TCP connection attempt to the specified
|
||||
IP/hostname and port, waiting `interval` amount of time between attempts
|
||||
|
|
|
@ -42,7 +42,7 @@ These Consul tools are created and managed by the amazing members of the Consul
|
|||
- [Dropwizard Consul Bundle](https://github.com/smoketurner/dropwizard-consul) - Service discovery and configuration integration with the [Dropwizard](http://www.dropwizard.io/) framework
|
||||
- [Embedded Consul](https://github.com/pszymczyk/embedded-consul) - Library for JVM based applications, provides easy way to run Consul in integration tests
|
||||
- [fabio](https://github.com/eBay/fabio) - Fast, zero-conf, consul-aware load-balancing HTTP/HTTPS router
|
||||
- [files-to-consul-kv](https://github.com/bitsofinfo/files-to-consul-kv) - Ultra simple, configuration free CLI tool for syncing a directory structure of key-value files to Consul KV using the transactions API. Docker image available. Integrates easily into any CICD workflow.
|
||||
- [files-to-consul-kv](https://github.com/bitsofinfo/files-to-consul-kv) - Ultra simple, configuration free CLI tool for syncing a directory structure of key-value files to Consul KV using the transactions API. Docker image available. Integrates easily into any CI/CD workflow.
|
||||
- [file2consul](https://github.com/joeatbayes/file2consul) - Update Consul values from git or files. Config loader with support for multiple environments. Provides variable expansion, interpolation, inheritance with overrides and ability to update multiple consul servers. Reduces cost of maintaining larger configuration sets between environments by reducing restatement and manual editing of similar or predictably changing config properties. MIT license, Written in GO.
|
||||
- [Flightpath](https://docs.flightpath.xyz/) - An xDS server that can configure Envoy to act as an Edge proxy for Consul Connect enabled services
|
||||
- [git2consul](https://github.com/ryanbreen/git2consul) - Mirror the contents of a Git repository into Consul KVs
|
||||
|
|
|
@ -52,7 +52,7 @@ The license changes do not impact customers with the baked-in licensed binaries.
|
|||
## Q: What is the product behavior change introduced by the licensing changes?
|
||||
|
||||
Starting with Consul Enterprise 1.10.0, a valid license is required on-disk (auto-loading) or as an environment variable for Consul Enterprise to successfully boot-up.
|
||||
The in-storage license feature will not be supported starting with Consul Enteprise 1.10.0+ent. All Consul Enterprise clusters using 1.10.0+ent must ensure that there is a valid license on-disk (auto-loaded) or as an environment variable.
|
||||
The in-storage license feature will not be supported starting with Consul Enterprise 1.10.0+ent. All Consul Enterprise clusters using 1.10.0+ent must ensure that there is a valid license on-disk (auto-loaded) or as an environment variable.
|
||||
|
||||
## Q: What is the impact on evaluation licenses due to this change?
|
||||
|
||||
|
@ -62,7 +62,7 @@ Failure to provide a valid license key will result in the Consul server agent no
|
|||
|
||||
## Q: Is there a grace period when licenses expire?
|
||||
|
||||
A license includes an `expiration_date` and a `termination_date`. An enteprise binary will cease to function once the `termination_date` has passed.
|
||||
A license includes an `expiration_date` and a `termination_date`. An enterprise binary will cease to function once the `termination_date` has passed.
|
||||
Licenses will now have a 24 hrs grace period. The grace period is the time between license expiry until the time it terminates.
|
||||
As Consul Enterprise approaches the expiration date, warnings will be issued in the system logs.
|
||||
|
||||
|
@ -123,7 +123,7 @@ Please see the [upgrade requirements](faq#q-what-are-the-upgrade-requirements).
|
|||
1. Run [`consul license get -signed`](/commands/license#get) to extract the license from their running cluster. Store the license in a secure location on disk.
|
||||
1. Set up the necessary configuration so that when Consul Enterprise reboots it will have access to the required license. This could be via the client agent configuration file or an environment variable.
|
||||
1. Visit the [Enterprise License Tutorial](https://learn.hashicorp.com/tutorials/nomad/hashicorp-enterprise-license?in=consul/enterprise) for detailed steps on how to install the license key.
|
||||
1. Follow the Consul upgrade [docummentation](/docs/upgrading).
|
||||
1. Follow the Consul upgrade [documentation](/docs/upgrading).
|
||||
|
||||
### Kubernetes
|
||||
|
||||
|
@ -143,7 +143,7 @@ Please see the [upgrade requirements](faq#q-what-are-the-upgrade-requirements).
|
|||
1. Store the license in a secure location on disk.
|
||||
1. Set up the necessary configuration so that when Consul Enterprise reboots it will have the required license. This could be via the client agent configuration file or an environment variable.
|
||||
Visit the [Enterprise License Tutorial](https://learn.hashicorp.com/tutorials/nomad/hashicorp-enterprise-license?in=consul/enterprise) for detailed steps on how to install the license key.
|
||||
1. Follow the Consul upgrade [docummentation](/docs/upgrading).
|
||||
1. Follow the Consul upgrade [documentation](/docs/upgrading).
|
||||
|
||||
### Kubernetes
|
||||
|
||||
|
|
|
@ -265,7 +265,7 @@ multiple cloud providers via APIs.
|
|||
|
||||
## Mutual Transport Layer Security (mTLS)
|
||||
Mutual Transport Layer Security, also known as mTLS, is an authentication
|
||||
mechanishm that ensures network traffic security in both directions between
|
||||
mechanism that ensures network traffic security in both directions between
|
||||
a client and server.
|
||||
|
||||
## Network Middleware Automation
|
||||
|
@ -287,7 +287,7 @@ packet inspection, and application based routing.
|
|||
|
||||
## Network Visualization
|
||||
Network Visualization is the process of visually displaying networks and
|
||||
connected entitites in a "boxes and lines" kind of a diagram.
|
||||
connected entities in a "boxes and lines" kind of a diagram.
|
||||
|
||||
In the context of microservices architecture, visualization can provide a clear
|
||||
picture of how services are connected to each other, the service-to-service
|
||||
|
@ -364,7 +364,7 @@ how to send requests to these service instances.
|
|||
## Microservice Segmentation
|
||||
Microservice segmentation, sometimes visual, of microservices is the
|
||||
segmentation in a microservices application architecture that enables
|
||||
adminsitrators to view their functions and interactions.
|
||||
administrators to view their functions and interactions.
|
||||
|
||||
## Service-to-service communication
|
||||
Service-to-service communication, sometimes referred to as
|
||||
|
|
|
@ -20,7 +20,7 @@ which is the combination of all Kubernetes probes registered with the pod.
|
|||
1. If the pod is utilizing [Transparent Proxy](/docs/connect/transparent-proxy) mode, the mutating webhook will mutate all `http` based Startup, Liveness, and Readiness probes in the pod to redirect through the Envoy proxy.
|
||||
This is done with [`ExposePaths` configuration](/docs/connect/registration/service-registration#expose-paths-configuration-reference) for each probe so that kubelet can access the endpoint through the Envoy proxy.
|
||||
|
||||
~> The mutation behaviour can be disabled by either setting the `consul.hashicorp.com/transparent-proxy-overwrite-probes` pod annotation to `false` or the `connectInject.defaultOverwriteProbes` Helm value to `false`.
|
||||
~> The mutation behavior can be disabled by either setting the `consul.hashicorp.com/transparent-proxy-overwrite-probes` pod annotation to `false` or the `connectInject.defaultOverwriteProbes` Helm value to `false`.
|
||||
|
||||
When readiness probes are set for a pod, the status of the pod will be reflected within Consul and will cause Consul to redirect service
|
||||
mesh traffic to the pod based on the pod's health. If the pod has failing health checks, Consul will no longer use
|
||||
|
|
|
@ -128,7 +128,7 @@ task {
|
|||
- `providers` - (list[string]) Providers is the list of provider names the task is dependent on. This is used to map [Terraform provider configuration](#terraform-provider) to the task.
|
||||
- `services` - (list[string]) Required depending on [`condition`](#condition) configuration. Services is the list of logical service names or service IDs the task executes on. Consul-Terraform-Sync monitors the Consul Catalog for changes to these services and triggers the task to run. Any service value not explicitly defined by a `service` block with a matching ID is assumed to be a logical service name in the default namespace. Alternative to configuring `services`, a `condition` can be configured so that the task does not trigger on changes to services (default behavior) but instead trigger on a different condition. See [Task Condition](#task-condition) configuration for more details.
|
||||
- `source` - (string: required) Source is the location the driver uses to fetch task dependencies. The source format is dependent on the driver. For the [Terraform driver](#terraform-driver), the source is the module path (local or remote). Read more on [Terraform module source here](https://www.terraform.io/docs/modules/sources.html).
|
||||
- `variable_files` - (list[string]) A list of paths to files containing variables for the task. For the [Terraform driver](#terraform-driver), these are used as Terraform [variable defintion (`.tfvars`) files](https://www.terraform.io/docs/configuration/variables.html#variable-definitions-tfvars-files) and consists of only variable name assignments. The variable assignments must match the corresponding variable declarations available by the Terraform module for the task. Consul-Terraform-Sync will generate the intermediate variable declarations to pass as arguments from the auto-generated root module to the task's module. Variables are loaded in the same order as they appear in the order of the files. Duplicate variables are overwritten with the later value. _Note: unless specified by the module, configure arguments for Terraform providers using [`terraform_provider` blocks](#terraform-provider)._
|
||||
- `variable_files` - (list[string]) A list of paths to files containing variables for the task. For the [Terraform driver](#terraform-driver), these are used as Terraform [variable definition (`.tfvars`) files](https://www.terraform.io/docs/configuration/variables.html#variable-definitions-tfvars-files) and consists of only variable name assignments. The variable assignments must match the corresponding variable declarations available by the Terraform module for the task. Consul-Terraform-Sync will generate the intermediate variable declarations to pass as arguments from the auto-generated root module to the task's module. Variables are loaded in the same order as they appear in the order of the files. Duplicate variables are overwritten with the later value. _Note: unless specified by the module, configure arguments for Terraform providers using [`terraform_provider` blocks](#terraform-provider)._
|
||||
```hcl
|
||||
address_group = "consul-services"
|
||||
tags = [
|
||||
|
@ -234,7 +234,7 @@ driver "terraform" {
|
|||
- `path` - (string) The file path to install Terraform or discover an existing Terraform binary. If omitted, Terraform will be installed in the same directory as the Consul-Terraform-Sync daemon. To resolve an incompatible Terraform version or to change versions will require removing the existing binary or change to a different path.
|
||||
- `persist_log` - (bool) Enable trace logging for each Terraform client to disk per task. This is equivalent to setting `TF_LOG_PATH=<work_dir>/terraform.log`. Trace log level results in verbose logging and may be useful for debugging and development purposes. We do not recommend enabling this for production. There is no log rotation and may quickly result in large files.
|
||||
- `required_providers` - (obj: required) Declare each Terraform provider used across all tasks. This is similar to the [Terraform `terraform.required_providers`](https://www.terraform.io/docs/configuration/provider-requirements.html#requiring-providers) field to specify the source and version for each provider. Consul-Terraform-Sync will process these requirements when preparing each task that uses the provider.
|
||||
- `version` - (string) The Terraform version to install and run in automation for task execution. If omittied, the driver will install the latest official release of Terraform. To change versions, remove the existing binary or change the path to install the desired version. Verify that the desired Terraform version is compatible across all Terraform modules used for Consul-Terraform-Sync automation.
|
||||
- `version` - (string) The Terraform version to install and run in automation for task execution. If omitted, the driver will install the latest official release of Terraform. To change versions, remove the existing binary or change the path to install the desired version. Verify that the desired Terraform version is compatible across all Terraform modules used for Consul-Terraform-Sync automation.
|
||||
- `working_dir` - (string: "sync-tasks") The base working directory to manage Terraform configurations all tasks. The full path of each working directory will have the task identifier appended to the end of the path, e.g. `./sync-tasks/task-name`.
|
||||
|
||||
## Terraform Provider
|
||||
|
@ -357,7 +357,7 @@ terraform_provider "example" {
|
|||
- `transport` - [(transport block)](#transport) Transport configures the low-level network connection details.
|
||||
- `unwrap_token` - (bool) Unwraps the provided Vault token as a wrapped token.
|
||||
|
||||
-> Note: Vault credentials are not accessible by tasks and the associated Terraform configurations, including automated Terraform modules. If the task requires Vault, you will need to seprately configure the Vault provider and explicitly include it in the `task.providers` list.
|
||||
-> Note: Vault credentials are not accessible by tasks and the associated Terraform configurations, including automated Terraform modules. If the task requires Vault, you will need to separately configure the Vault provider and explicitly include it in the `task.providers` list.
|
||||
|
||||
### Multiple Provider Configurations
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ Within the Consul-Terraform-Sync configuration for a task, practitioners can sel
|
|||
|
||||
The root module is simple in structure and proxies Consul information, configuration, and other variables to the Terraform module for the task. The content of the files that make up the root module are sourced from Consul-Terraform-Sync configuration, information for task's module to use as the automation playbook, and information from Consul such as service information.
|
||||
|
||||
Autogenerated root modules for tasks are stored in local subdirectories of the Terraform working directory. By default, the working directory `sync-tasks` is created in the current directory. To configure where Terraform configuration files are stored, set [`working_dir`](/docs/nia/configuration#working_dir) for the Terraform driver to the desired path.
|
||||
Auto-generated root modules for tasks are stored in local subdirectories of the Terraform working directory. By default, the working directory `sync-tasks` is created in the current directory. To configure where Terraform configuration files are stored, set [`working_dir`](/docs/nia/configuration#working_dir) for the Terraform driver to the desired path.
|
||||
|
||||
A working directory with one task named "my-task" would have the folder structure below.
|
||||
|
||||
|
|
|
@ -80,7 +80,7 @@ environment and adapt these configurations accordingly.
|
|||
to true to require clients to provide a valid TLS certificate when the Consul HTTPS API is enabled. TLS for the API
|
||||
may be not be necessary if it is exclusively served over a loopback interface such as `localhost`.
|
||||
|
||||
- [`verifing_incoming_rpc`](/docs/agent/options#verify_incoming_rpc) - By default this is false, and should almost
|
||||
- [`verify_incoming_rpc`](/docs/agent/options#verify_incoming_rpc) - By default this is false, and should almost
|
||||
always be set to true to require clients to provide a valid TLS certificate for Consul agent RPCs.
|
||||
|
||||
- [`verify_outgoing`](/docs/agent/options#verify_outgoing) - By default this is false, and should be set to true to
|
||||
|
@ -239,7 +239,7 @@ environment and adapt these configurations accordingly.
|
|||
|
||||
```hcl
|
||||
http_config {
|
||||
reponse_headers {
|
||||
response_headers {
|
||||
"X-Frame-Options" = "DENY"
|
||||
}
|
||||
}
|
||||
|
@ -374,7 +374,7 @@ The following are not part of the threat model for client agents:
|
|||
to your cluster in certain situations, especially in multi-team deployments. They may accidentally or intentionally
|
||||
abuse access to Consul components which can help be protected against using Namespace, and Sentinel policies.
|
||||
|
||||
- **Application** - A malicious internal application, suchs as a compromised third-party dependency with access to a
|
||||
- **Application** - A malicious internal application, such as a compromised third-party dependency with access to a
|
||||
Consul agent, along with the TLS certificate or ACL token used by the local agent, could effectively do anything the
|
||||
token permits. Consider enabling HTTPS for the local Consul agent API, enforcing full mutual TLS verification,
|
||||
segmenting services using namespaces, as well as configuring OS users, groups, and file permissions to build a defense-in-depth approach.
|
||||
|
|
|
@ -22,5 +22,5 @@ controls for a cluster. You can read more about the various personas, recommenda
|
|||
|
||||
[Network Infrastructure Automation](/docs/nia) (NIA) enables dynamic updates to network infrastructure devices triggered
|
||||
by service changes. Both the core Consul product's configuration and the configuration for the `consul-terraform-sync`
|
||||
daemon used by NIA can affect the security of your deploymnet. You can read more about the various personas,
|
||||
daemon used by NIA can affect the security of your deployment. You can read more about the various personas,
|
||||
recommendations, requirements, and threats [here](/docs/security/security-models/nia).
|
||||
|
|
|
@ -123,7 +123,7 @@ The full list of changes is available here:
|
|||
- https://www.consul.io/docs/upgrading/upgrade-specific#deprecated-options-have-been-removed
|
||||
|
||||
You can make sure your config changes are valid by copying your existing configuration files,
|
||||
making the changes, and then verifing them by using `consul validate $CONFIG_FILE1_PATH $CONFIG_FILE2_PATH ...`.
|
||||
making the changes, and then verifying them by using `consul validate $CONFIG_FILE1_PATH $CONFIG_FILE2_PATH ...`.
|
||||
|
||||
Once your config is passing the validation check, replace your old config files with the new ones
|
||||
and slowly roll your cluster again one server at a time – leaving the leader agent for last in each
|
||||
|
|
|
@ -220,7 +220,7 @@ These are the changes you will need to make:
|
|||
```
|
||||
|
||||
You can make sure your config changes are valid by copying your existing configuration files,
|
||||
making the changes, and then verifing them by using `consul validate $CONFIG_FILE1_PATH $CONFIG_FILE2_PATH ...`.
|
||||
making the changes, and then verifying them by using `consul validate $CONFIG_FILE1_PATH $CONFIG_FILE2_PATH ...`.
|
||||
|
||||
Once your config is passing the validation check, replace your old config files with the new ones
|
||||
and slowly roll your cluster again one server at a time – leaving the leader agent for last in each
|
||||
|
|
Loading…
Reference in New Issue