diff --git a/website/content/docs/agent/config-entries.mdx b/website/content/docs/agent/config-entries.mdx index e95ea16f2..38025e67a 100644 --- a/website/content/docs/agent/config-entries.mdx +++ b/website/content/docs/agent/config-entries.mdx @@ -51,7 +51,7 @@ See [Kubernetes Custom Resource Definitions](/docs/k8s/crds). Configuration entries outside of Kubernetes should be managed with the Consul [CLI](/commands/config) or [API](/api/config). Additionally, as a convenience for initial cluster bootstrapping, configuration entries can be -specified in all of the Consul servers's +specified in the Consul servers agent's [configuration files](/docs/agent/options#config_entries_bootstrap) ### Managing Configuration Entries with the CLI diff --git a/website/content/docs/agent/index.mdx b/website/content/docs/agent/index.mdx index a19c1e312..1d7c76987 100644 --- a/website/content/docs/agent/index.mdx +++ b/website/content/docs/agent/index.mdx @@ -136,7 +136,7 @@ $ consul agent -data-dir=/tmp/consul - **Server**: This indicates whether the agent is running in server or client mode. Running an agent in server mode requires additional overhead. This is because they participate in the consensus quorum, store cluster state, and handle queries. A server may also be - in ["bootstrap"](/docs/agent/options#_bootstrap_expect) mode, which enables the server to elect itselft as the Raft leader. Multiple servers cannot be in bootstrap mode because it would put the cluster in an inconsistent state. + in ["bootstrap"](/docs/agent/options#_bootstrap_expect) mode, which enables the server to elect itself as the Raft leader. Multiple servers cannot be in bootstrap mode because it would put the cluster in an inconsistent state. - **Client Addr**: This is the address used for client interfaces to the agent. This includes the ports for the HTTP and DNS interfaces. By default, this diff --git a/website/content/docs/agent/telemetry.mdx b/website/content/docs/agent/telemetry.mdx index 076c21105..ceb2fece5 100644 --- a/website/content/docs/agent/telemetry.mdx +++ b/website/content/docs/agent/telemetry.mdx @@ -350,8 +350,8 @@ These metrics are used to monitor the health of the Consul servers. | `consul.raft.boltdb.logSize` | Measures the size of logs being written to the db. | bytes | sample | | `consul.raft.boltdb.numFreePages` | Represents the number of free pages within the raft.db file. | pages | gauge | | `consul.raft.boltdb.numPendingPages` | Represents the number of pending pages within the raft.db that will soon become free. | pages | gauge | -| `consul.raft.boltdb.openReadTxn` | Represents the number of open read transactions against the db | transactions | guage | -| `consul.raft.boltdb.totalReadTxn` | Represents the total number of started read transactions against the db | transactions | guage | +| `consul.raft.boltdb.openReadTxn` | Represents the number of open read transactions against the db | transactions | gauge | +| `consul.raft.boltdb.totalReadTxn` | Represents the total number of started read transactions against the db | transactions | gauge | | `consul.raft.boltdb.storeLogs` | Measures the amount of time spent writing logs to the db. | ms | timer | | `consul.raft.boltdb.txstats.cursorCount` | Counts the number of cursors created since Consul was started. | cursors | counter | | `consul.raft.boltdb.txstats.nodeCount` | Counts the number of node allocations within the db since Consul was started. | allocations | counter | diff --git a/website/content/docs/connect/gateways/index.mdx b/website/content/docs/connect/gateways/index.mdx index b12c100b9..2111bd86c 100644 --- a/website/content/docs/connect/gateways/index.mdx +++ b/website/content/docs/connect/gateways/index.mdx @@ -28,8 +28,8 @@ They operate by sniffing and extracting the server name indication (SNI) header Mesh gateways enable the following scenarios: - **Federate multiple datacenters across a WAN**. Since Consul 1.8.0, mesh gateways can forward gossip and RPC traffic between Consul servers. See [WAN federation via mesh gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways) for additional information. -- **Service-to-service communication across datacenters**. Refer to [Enabling Service-to-service Traffic Accross Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) for additional information. -- **Service-to-service communication across admin partitions**. Since Consul 1.11.0, you can create administrative boundaries for single Consul deployements called "admin partitions". You can use mesh gateways to facilitate cross-partition communication. Refer to [Enabling Service-to-service Traffic Accross Admin Partitions](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) for additional information. +- **Service-to-service communication across datacenters**. Refer to [Enabling Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) for additional information. +- **Service-to-service communication across admin partitions**. Since Consul 1.11.0, you can create administrative boundaries for single Consul deployments called "admin partitions". You can use mesh gateways to facilitate cross-partition communication. Refer to [Enabling Service-to-service Traffic Across Admin Partitions](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) for additional information. -> **Mesh gateway tutorial**: Follow the [mesh gateway tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-gateways) to learn concepts associated with mesh gateways. diff --git a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx index bc529496f..39b10675d 100644 --- a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx +++ b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx @@ -10,7 +10,7 @@ description: >- -> **Consul Enterprise 1.11.0+:** Admin partitions are supported in Consul Enterprise versions 1.11.0 and newer. -Mesh gateways enable you to route service mesh traffic between different Consul [admin partitions](/docs/enteprise/admin-partitions). +Mesh gateways enable you to route service mesh traffic between different Consul [admin partitions](/docs/enterprise/admin-partitions). Partitions can reside in different clouds or runtime environments where general interconnectivity between all services in all partitions isn't feasible. @@ -20,7 +20,7 @@ Mesh gateways operate by sniffing and extracting the server name indication (SNI Ensure that your Consul environment meets the following requirements. -### Consul +### Consul * Consul Enterprise version 1.11.0 or newer. * A local Consul agent is required to manage its configuration. @@ -170,7 +170,7 @@ service: ### Enabling Gateways for a Proxy Upstream -The following service definition will enable gateways in `local` mode for three different partitions. Note that each service exists in the same namepace, but are separated by admin partition. +The following service definition will enable gateways in `local` mode for three different partitions. Note that each service exists in the same namespace, but are separated by admin partition. @@ -241,4 +241,4 @@ service: mesh_gateway: - mode: local ``` - \ No newline at end of file + diff --git a/website/content/docs/connect/intentions.mdx b/website/content/docs/connect/intentions.mdx index 198fa0d28..9f3ea2c42 100644 --- a/website/content/docs/connect/intentions.mdx +++ b/website/content/docs/connect/intentions.mdx @@ -57,7 +57,7 @@ If is set to `deny`, then all connections or requests will be denied by default. You can define a [`service-intentions`](/docs/connect/config-entries/service-intentions) configuration entry to create and manage intentions, as well as manage intentions through the Consul UI. You can also perform some intention-related tasks using the API and CLI commands. Refer to the [API](/api-docs/connect/intentions) and [CLI](/commands/intention) documentation for details. -The following example shows a `service-intentions` configuration entry that specifes two intentions. Refer to the [`service-intentions`](/docs/connect/config-entries/service-intentions) documentation for the full data model and additional examples. +The following example shows a `service-intentions` configuration entry that specifies two intentions. Refer to the [`service-intentions`](/docs/connect/config-entries/service-intentions) documentation for the full data model and additional examples. diff --git a/website/content/docs/connect/proxies/integrate.mdx b/website/content/docs/connect/proxies/integrate.mdx index 7a6e0574d..f57cc2234 100644 --- a/website/content/docs/connect/proxies/integrate.mdx +++ b/website/content/docs/connect/proxies/integrate.mdx @@ -55,7 +55,7 @@ $ curl http://:8500/v1/agent/connect/ca/roots After validating the client certificate from the caller, the proxy can authorize the entire connection (L4) or each request (L7). Depending upon the [protocol] of the proxied service, authorization is performed either on a per-connection (L4) or per-request (L7) basis. Authentication is based on "service identity" (TLS), and is implemented at the transport layer. --> **Note:** Some features, such as (local) rate limiting or max connections, are expected to be proxy-level configurations enforced separately when authorization calls are made. Proxies can enforce the configurations based on information about request rates and other states that should already be availabe. +-> **Note:** Some features, such as (local) rate limiting or max connections, are expected to be proxy-level configurations enforced separately when authorization calls are made. Proxies can enforce the configurations based on information about request rates and other states that should already be available. The proxy can authorize the connection by either calling the [`/v1/agent/connect/authorize`](/api/agent/connect) API endpoint or by querying the [intention match API](/api/connect/intentions#list-matching-intentions) endpoint. diff --git a/website/content/docs/connect/registration/service-registration.mdx b/website/content/docs/connect/registration/service-registration.mdx index 92bcb1a93..32ced2d3a 100644 --- a/website/content/docs/connect/registration/service-registration.mdx +++ b/website/content/docs/connect/registration/service-registration.mdx @@ -97,14 +97,14 @@ Sidecar proxies are co-located with the single service instance they represent a Specify the following parameters in the `proxy` code block to configure a sidecar proxy in its own service registration: * `destination_service_id`: String value that specifies the ID of the service being proxied. Refer to the [proxy parameters reference](#destination-service-id) for details. -* `local_service_port`: Integer value that specifes the port that the proxy should use to connect to the _local_ service instance. Refer to the [proxy parameters reference](#local-service-port) for details. -* `local_service_address`: String value that specifies the IP address or hostname that the proxy should use to connect to the _local_ service. Refer to the [proxy parameters reference](#local-service-address) for details. +* `local_service_port`: Integer value that specifies the port that the proxy should use to connect to the _local_ service instance. Refer to the [proxy parameters reference](#local-service-port) for details. +* `local_service_address`: String value that specifies the IP address or hostname that the proxy should use to connect to the _local_ service. Refer to the [proxy parameters reference](#local-service-address) for details. See (Sidecar Service Registration)[/docs/connect/registration/sidecar-service] for additional information about configuring service mesh proxies as sidecars. ### Complete Configuration Example -The following example includes values for all availble options when registering a proxy instance. +The following example includes values for all available options when registering a proxy instance. @@ -160,7 +160,7 @@ The following table describes all parameters that can be defined in the `proxy` | Parameter | Description | Required | Default | | --- | --- | --- | --- | | `destination_service_id` | String value that specifies the ID of a single service instance represented by the proxy.
This parameter is only applicable for sidecar proxies that run on the same node as the service.
Consul checks for the proxied service on the same agent.
The ID is unique and may differ from its `name` value.
Specifying this parameter helps tools identify which sidecar proxy instances are associated with which application instance, as well as enable fine-grained analysis of the metrics coming from the proxy.| Required when registering proxy as a sidecar | None | -| `local_service_port` | Integer value that specifes the port that a sidecar proxy should use to connect to the _local_ service instance. | Required when registering proxy as a sidecar | Port advertised by the service instance configured in `destination_service_id` | +| `local_service_port` | Integer value that specifies the port that a sidecar proxy should use to connect to the _local_ service instance. | Required when registering proxy as a sidecar | Port advertised by the service instance configured in `destination_service_id` | | `local_service_address` | String value that specifies the IP address or hostname that a sidecar proxy should use to connect to the _local_ service. | Optional | `127.0.0.1` | | `destination_service_name` | String value that specifies the _name_ of the service the instance is proxying. The name is used during service discovery to route to the correct proxy instances for a given service name. | Required | None | | `local_service_socket_path` | String value that specifies the path of a Unix domain socket for connecting to the local application instance.
This parameter value is created by the application and conflicts with `local_service_address` and `local_service_port`.
Supported when using Envoy for the proxy. | Optional | None | @@ -175,23 +175,23 @@ The following table describes all parameters that can be defined in the `proxy` You can configure the service mesh proxy to create listeners for upstream services. The listeners enable the upstream service to accept requests. You can specify the following parameters to configure upstream service listeners. -| Parameter | Description | Required | Defautl | +| Parameter | Description | Required | Default | | --- | --- | --- | --- | |`destination_name` | String value that specifies the name of the service or prepared query to route the service mesh to. The prepared query should be the name or the ID of the prepared query. | Required | None | | `destination_namespace` | String value that specifies the namespace containing the upstream service. | Optional | `default` | | `destination_partition` | String value that specifies the name of the admin partition containing the upstream service. | Optional | `default` | | `local_bind_port` | Integer value that specifies the port to bind a local listener to. The application will make outbound connections to the upstream from the local port. | Required | None | -| `local_bind_address` | String value that specifies the address to bind a local listener to. The application will make outbound connecttions to the upstream service from the local bind address. | Optional | `127.0.0.1` | +| `local_bind_address` | String value that specifies the address to bind a local listener to. The application will make outbound connections to the upstream service from the local bind address. | Optional | `127.0.0.1` | | `local_bind_socket_path` | String value that specifies the path at which to bind a Unix domain socket listener. The application will make outbound connections to the upstream from the local bind socket path.
This parameter conflicts with the `local_bind_port` or `local_bind_address` parameters.
Supported when using Envoy as a proxy. | Optional | None| | `local_bind_socket_mode` | String value that specifies a Unix octal that configures file permissions for the socket. | Optional | None | | `destination_type` | String value that specifies the type of discovery query the proxy should use for finding service mesh instances. The following values are supported:
  • `service`: Queries for upstream `service` types.
  • `prepared_query`: Queries for upstream prepared queries.
    • | Optional | `service` | | `datacenter` | String value that specifies the datacenter to issue the discovery query to. | Optional | Defaults to the local datacenter. | -| `config` | Object value that specifies opaque configuration options that will be provided to the proxy instance for the upstream.
    Valid JSON objects are also suppported.
    The `config` parameter can specify timeouts, retries, and other proxy-specific features for the given upstream.
    See the [built-in proxy configuration reference](/docs/connect/proxies/built-in#proxy-upstream-config-key-reference) for configuration options when using the built-in proxy.
    If using Envoy as a proxy, see [Envoy configuration reference](/docs/connect/proxies/envoy#proxy-upstream-config-options) | Optional | None | +| `config` | Object value that specifies opaque configuration options that will be provided to the proxy instance for the upstream.
    Valid JSON objects are also supported.
    The `config` parameter can specify timeouts, retries, and other proxy-specific features for the given upstream.
    See the [built-in proxy configuration reference](/docs/connect/proxies/built-in#proxy-upstream-config-key-reference) for configuration options when using the built-in proxy.
    If using Envoy as a proxy, see [Envoy configuration reference](/docs/connect/proxies/envoy#proxy-upstream-config-options) | Optional | None | | `mesh_gateway` | Object that defines the mesh gateway configuration for the proxy. Refer to the [Mesh Gateway Configuration Reference](#mesh-gateway-configuration-reference) for configuration details. | Optional | None | ### Upstream Configuration Examples -Upstreams support multiple destination types. The following examples include information about each implmentation. +Upstreams support multiple destination types. The following examples include information about each implementation. -> **Snake case**: The examples in this topic use `snake_case` because the syntax is supported in configuration files and API registrations. See [Service Definition Parameter Case](/docs/agent/services#service-definition-parameter-case) for additional information. diff --git a/website/content/docs/discovery/checks.mdx b/website/content/docs/discovery/checks.mdx index 02ef1c284..defed5d4e 100644 --- a/website/content/docs/discovery/checks.mdx +++ b/website/content/docs/discovery/checks.mdx @@ -613,7 +613,7 @@ The status will not transition states until the configured threshold is reached. - `failures_before_warning` - Number of consecutive unsuccessful results required before check status transitions to warning. Defaults to the same value as that of `failures_before_critical` to maintain the expected behavior of not changing the - status of serivce checks to `warning` before `critical` unless configured to do so. + status of service checks to `warning` before `critical` unless configured to do so. Values higher than `failures_before_critical` are invalid. Added in Consul 1.11.0. - `failures_before_critical` - Number of consecutive unsuccessful results required before check status transitions to critical. Defaults to `0`. Added in Consul 1.7.0. diff --git a/website/content/docs/ecs/index.mdx b/website/content/docs/ecs/index.mdx index 0e8d22db3..68fa655bb 100644 --- a/website/content/docs/ecs/index.mdx +++ b/website/content/docs/ecs/index.mdx @@ -25,6 +25,6 @@ There are several ways to get started with Consul with ECS. * The [Serverless Consul Service Mesh with ECS and HCP](https://learn.hashicorp.com/tutorials/cloud/consul-ecs-hcp?in=consul/cloud-integrations) learn guide shows how to use Terraform to run Consul service mesh applications on ECS with managed Consul servers running in HashiCorp Cloud Platform (HCP). * The [Service Mesh with ECS and Consul on EC2](https://learn.hashicorp.com/tutorials/consul/consul-ecs-ec2?in=consul/cloud-integrations) learn guide shows how to use Terraform to run Consul service mesh applications on ECS with Consul servers running on EC2 instances. * The [Consul with Dev Server on Fargate](https://registry.terraform.io/modules/hashicorp/consul-ecs/aws/latest/examples/dev-server-fargate) example installation deploys a sample application in ECS using the Fargate launch type. -* The [Consul with Dev Server on EC2](https://registry.terraform.io/modules/hashicorp/consul-ecs/aws/latest/examples/dev-server-ec2) example installation deploys a sample applciation in ECS using the EC2 launch type. +* The [Consul with Dev Server on EC2](https://registry.terraform.io/modules/hashicorp/consul-ecs/aws/latest/examples/dev-server-ec2) example installation deploys a sample application in ECS using the EC2 launch type. See the [Requirements](/docs/ecs/get-started/requirements) and the full [Install Guide](/docs/ecs/get-started/install) when you're ready to install Consul on an existing ECS cluster and add existing tasks to the service mesh. diff --git a/website/content/docs/enterprise/admin-partitions.mdx b/website/content/docs/enterprise/admin-partitions.mdx index 3a88138d9..922d905ed 100644 --- a/website/content/docs/enterprise/admin-partitions.mdx +++ b/website/content/docs/enterprise/admin-partitions.mdx @@ -1,7 +1,7 @@ --- layout: docs page_title: Consul Enterprise Admin Partitions -description: Consul Enterprise enables you to create paritions that can be administrated across namespaces. +description: Consul Enterprise enables you to create partitions that can be administrated across namespaces. --- # Consul Enterprise Admin Partitions diff --git a/website/content/docs/k8s/installation/vault/index.mdx b/website/content/docs/k8s/installation/vault/index.mdx index df1bc25dc..b76ee4b5d 100644 --- a/website/content/docs/k8s/installation/vault/index.mdx +++ b/website/content/docs/k8s/installation/vault/index.mdx @@ -41,7 +41,7 @@ Prior to creating Vault auth roles for the Consul servers and clients, ensure th $ vault auth enable kubernetes ``` -After enabling the Kubernetes auth method, in Vault, ensure that you have configured the Kubernetes Auth method properly as described in [Kubernetes Auth Method Configuration](https://www.vaultproject.io/docs/auth/kubernetes#configuration). The command should look simliar to the following with a custom `kubernetes_host` config provided from the information provided via `kubectl cluster-info`. +After enabling the Kubernetes auth method, in Vault, ensure that you have configured the Kubernetes Auth method properly as described in [Kubernetes Auth Method Configuration](https://www.vaultproject.io/docs/auth/kubernetes#configuration). The command should look similar to the following with a custom `kubernetes_host` config provided from the information provided via `kubectl cluster-info`. ```shell-session $ vault write auth/kubernetes/config \ @@ -52,7 +52,7 @@ $ vault write auth/kubernetes/config \ ### Vault KV Secrets Engine - Version 2 -In order to utlize Vault as a secrets backend, we must enable thne [Vault KV secrets engine - Version 2](https://www.vaultproject.io/docs/secrets/kv/kv-v2). +In order to utilize Vault as a secrets backend, we must enable the [Vault KV secrets engine - Version 2](https://www.vaultproject.io/docs/secrets/kv/kv-v2). ```shell-session $ vault secrets enable -path=consul kv-v2 diff --git a/website/content/docs/k8s/installation/vault/server-tls.mdx b/website/content/docs/k8s/installation/vault/server-tls.mdx index f0ad83183..612d9997e 100644 --- a/website/content/docs/k8s/installation/vault/server-tls.mdx +++ b/website/content/docs/k8s/installation/vault/server-tls.mdx @@ -9,7 +9,7 @@ description: >- To use Vault to issue Server TLS certificates the following will be needed: -1. Bootstrap the Vault PKI engine and boostrap it with any configuration required for your infrastructure. +1. Bootstrap the Vault PKI engine and bootstrap it with any configuration required for your infrastructure. 1. Create Vault Policies that will allow the Consul server to access the certificate issuing url. 1. Create Vault Policies that will allow the Consul components, e.g. ingress gateways, controller, to access the CA url. 1. Create Kubernetes auth roles that link these policies to the Kubernetes service accounts of the Consul components. @@ -130,7 +130,7 @@ vault write auth/kubernetes/role/consul-ca \ ``` The above Vault Roles will now be your Helm values for `global.secretsBackend.vault.consulServerRole` and -`global.secretsBAckend.vault.consulCARole` respectively. +`global.secretsBackend.vault.consulCARole` respectively. ## Deploying the Consul Helm chart diff --git a/website/content/docs/k8s/k8s-cli.mdx b/website/content/docs/k8s/k8s-cli.mdx index c4b07305a..af1ce6c82 100644 --- a/website/content/docs/k8s/k8s-cli.mdx +++ b/website/content/docs/k8s/k8s-cli.mdx @@ -88,9 +88,9 @@ The following options are available. | `-config-file` | String value that specifies the path to a file containing custom installation configurations, e.g., Consul Helm chart values file.
    You can use the `-config-file` flag multiple times to specify multiple files. | none | Optional | | `-namespace` | String value that specifies the namespace of the Consul installation. | `consul` | Optional | | `-preset` | String value that installs Consul based on a preset configuration. You can specify the following values:
    `demo`: Installs a single replica server with sidecar injection enabled; useful for testing service mesh functionality.
    `secure`: Installs a single replica server with sidecar injection, ACLs, and TLS enabled; useful for testing service mesh functionality. | Configuration of the Consul Helm chart. | Optional | -| `-set` | String value that enables you to set a customizeable value. This flag is comparable to the `helm install --set` flag.
    You can use the `-set` flag multiple times to set multiple values.
    Consul Helm chart values are supported. | none | Optional | -| `-set-file` | String value that specifies the name of an arbitrary config file. This flag is comparable to the `helm install --set-file`
    flag. The contents of the file will be used to set a customizeable value. You can use the `-set-file` flag multiple times to specify multiple files.
    Consul Helm chart values are supported. | none | Optional | -| `-set-string` | String value that enables you to set a customizeable string value. This flag is comparable to the `helm install --set-string`
    flag. You can use the `-set-string` flag multiple times to specify multiple strings.
    Consul Helm chart values are supported. | none | Optional | +| `-set` | String value that enables you to set a customizable value. This flag is comparable to the `helm install --set` flag.
    You can use the `-set` flag multiple times to set multiple values.
    Consul Helm chart values are supported. | none | Optional | +| `-set-file` | String value that specifies the name of an arbitrary config file. This flag is comparable to the `helm install --set-file`
    flag. The contents of the file will be used to set a customizable value. You can use the `-set-file` flag multiple times to specify multiple files.
    Consul Helm chart values are supported. | none | Optional | +| `-set-string` | String value that enables you to set a customizable string value. This flag is comparable to the `helm install --set-string`
    flag. You can use the `-set-string` flag multiple times to specify multiple strings.
    Consul Helm chart values are supported. | none | Optional | | `-timeout` | Specifies how long to wait for the installation process to complete before timing out. The value is specified with an integer and string value indicating a unit of time.
    The following units are supported:
    `ms` (milliseconds)
    `s` (seconds)
    `m` (minutes)
    In the following example, installation will timeout after one minute:
    `consul-k8s install -timeout 1m` | `10m` | Optional | | `-wait` | Boolean value that determines if Consul should wait for resources in the installation to be ready before exiting the command. | `true` | Optional | | `-verbose`, `-v` | Boolean value that specifies whether to output verbose logs from the install command with the status of resources being installed. | `false` | Optional | @@ -133,7 +133,7 @@ The following options are available. | `-name` | String value for the name of the installation to remove. | none | Optional | | `-namespace` | String value that specifies the namespace of the Consul installation to remove. | `consul` | Optional | | `-timeout` | Specifies how long to wait for the removal process to complete before timing out. The value is specified with an integer and string value indicating a unit of time.
    The following units are supported:
    `ms` (milliseconds)
    `s` (seconds)
    `m` (minutes)
    `h` (hours)
    In the following example, removal will timeout after one minute:
    `consul-k8s uninstall -timeout 1m` | `10m` | Optional | -| `-wipe-data` | Boolan value that deletes PVCs and secrets associated with the Consul installation during installation.
    Data will be removed without a verification prompt if the `-auto-approve` flag is set to `true`. | `false`
    Instructions for removing data will be printed to the console. | Optional | +| `-wipe-data` | Boolean value that deletes PVCs and secrets associated with the Consul installation during installation.
    Data will be removed without a verification prompt if the `-auto-approve` flag is set to `true`. | `false`
    Instructions for removing data will be printed to the console. | Optional | | `--help` | Prints usage information for this option. | none | Optional | See [Global Options](#global-options) for additional commands that you can use when uninstalling Consul from Kubernetes. @@ -210,11 +210,11 @@ The following options are available. | `-config-file` | String value that specifies the path to a file containing custom upgrade configurations, e.g., Consul Helm chart values file.
    You can use the `-config-file` flag multiple times to specify multiple files. | none | Optional | | `-namespace` | String value that specifies the namespace of the Consul installation. | `consul` | Optional | | `-preset` | String value that upgrades Consul based on a preset configuration. | Configuration of the Consul Helm chart. | Optional | -| `-set` | String value that enables you to set a customizeable value. This flag is comparable to the `helm upgrade --set` flag.
    You can use the `-set` flag multiple times to set multiple values.
    Consul Helm chart values are supported. | none | Optional | -| `-set-file` | String value that specifies the name of an arbitrary config file. This flag is comparable to the `helm upgrade --set-file`
    flag. The contents of the file will be used to set a customizeable value. You can use the `-set-file` flag multiple times to specify multiple files.
    Consul Helm chart values are supported. | none | Optional | -| `-set-string` | String value that enables you to set a customizeable string value. This flag is comparable to the `helm upgrade --set-string`
    flag. You can use the `-set-string` flag multiple times to specify multiple strings.
    Consul Helm chart values are supported. | none | Optional | +| `-set` | String value that enables you to set a customizable value. This flag is comparable to the `helm upgrade --set` flag.
    You can use the `-set` flag multiple times to set multiple values.
    Consul Helm chart values are supported. | none | Optional | +| `-set-file` | String value that specifies the name of an arbitrary config file. This flag is comparable to the `helm upgrade --set-file`
    flag. The contents of the file will be used to set a customizable value. You can use the `-set-file` flag multiple times to specify multiple files.
    Consul Helm chart values are supported. | none | Optional | +| `-set-string` | String value that enables you to set a customizable string value. This flag is comparable to the `helm upgrade --set-string`
    flag. You can use the `-set-string` flag multiple times to specify multiple strings.
    Consul Helm chart values are supported. | none | Optional | | `-timeout` | Specifies how long to wait for the upgrade process to complete before timing out. The value is specified with an integer and string value indicating a unit of time.
    The following units are supported:
    `ms` (milliseconds)
    `s` (seconds)
    `m` (minutes)
    In the following example, the upgrade will timeout after one minute:
    `consul-k8s upgrade -timeout 1m` | `10m` | Optional | -| `-wait` | Boolean value that determines if Consul should wait for resources in the upgtrade to be ready before exiting the command. | `true` | Optional | +| `-wait` | Boolean value that determines if Consul should wait for resources in the upgrade to be ready before exiting the command. | `true` | Optional | | `-verbose`, `-v` | Boolean value that specifies whether to output verbose logs from the upgrade command with the status of resources being upgraded. | `false` | Optional | | `--help` | Prints usage information for this option. | none | Optional | diff --git a/website/content/docs/k8s/operations/uninstall.mdx b/website/content/docs/k8s/operations/uninstall.mdx index 19ffbc66a..2d2ebddf4 100644 --- a/website/content/docs/k8s/operations/uninstall.mdx +++ b/website/content/docs/k8s/operations/uninstall.mdx @@ -10,7 +10,7 @@ You can uninstall Consul using Helm commands or the Consul K8s CLI. ## Consul K8s CLI -Issue the `consul-k8s uninstall` command to remove Consul on Kubernetes. You can specify the installation name, namespace, and data retention behavior using the applicable options. By default, the uninstallation preserves the secrets and PVCs that are provisioned by Consul on Kubernetes. +Issue the `consul-k8s uninstall` command to remove Consul on Kubernetes. You can specify the installation name, namespace, and data retention behavior using the applicable options. By default, the uninstall preserves the secrets and PVCs that are provisioned by Consul on Kubernetes. ```shell-session $ consul-k8s uninstall diff --git a/website/content/docs/nia/network-drivers/terraform.mdx b/website/content/docs/nia/network-drivers/terraform.mdx index 9fd6db4cb..041cac572 100644 --- a/website/content/docs/nia/network-drivers/terraform.mdx +++ b/website/content/docs/nia/network-drivers/terraform.mdx @@ -22,7 +22,7 @@ Once all workspaces are set up, Consul-Terraform-Sync monitors the Consul catalo Within the Consul-Terraform-Sync configuration for a task, practitioners can select the desired module to run for the task as well as set the condition to execute the task. Each task executed by the Terraform driver corresponds to an automated root module that calls the selected module in an isolated Terraform environment. Consul-Terraform-Sync will manage concurrent execution of these tasks. -Autogenerated root modules for tasks are mantained in local subdirectories of the Consul-Terraform-Sync working directory. Each subdirectory represents the local workspace for a task. 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) to the desired path or configure the [`task.working_dir`](/docs/nia/configuration#working_dir-1) individually. +Autogenerated root modules for tasks are maintained in local subdirectories of the Consul-Terraform-Sync working directory. Each subdirectory represents the local workspace for a task. 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) to the desired path or configure the [`task.working_dir`](/docs/nia/configuration#working_dir-1) individually. ~> **Note:** Although Terraform state files for task workspaces are independent, this does not guarantee the infrastructure changes from concurrent task executions are independent. Ensure that modules across all tasks are not modifying the same resource objects or have overlapping changes that may result in race conditions during automation. diff --git a/website/content/docs/security/acl/acl-rules.mdx b/website/content/docs/security/acl/acl-rules.mdx index 0d76efce7..1571f754b 100644 --- a/website/content/docs/security/acl/acl-rules.mdx +++ b/website/content/docs/security/acl/acl-rules.mdx @@ -68,7 +68,7 @@ The following syntax describes how to include a resource label in the rule:     -Labels provide operators with more granular control over access to the resouce, but the following resource types do not take a label: +Labels provide operators with more granular control over access to the resource, but the following resource types do not take a label: * `acl` * `keyring` @@ -102,7 +102,7 @@ Use the `policy` keyword and one of the following access levels to set a policy - `write`: Allows the resource to be read and modified. - `deny`: Denies read and write access to the resource. -The special `list` access level provices access to all keys with the specified resource label in the Consul KV. The `list` access level can only be used with the `key_prefix` resource. The [`acl.enable_key_list_policy`](/docs/agent/options#acl_enable_key_list_policy) setting must be set to `true`. +The special `list` access level provides access to all keys with the specified resource label in the Consul KV. The `list` access level can only be used with the `key_prefix` resource. The [`acl.enable_key_list_policy`](/docs/agent/options#acl_enable_key_list_policy) setting must be set to `true`. ### Matching and Prefix Values @@ -295,7 +295,7 @@ $ curl \ }' http://127.0.0.1:8500/v1/acl/policy?token= ``` -The policy configuration is returned when the call is succesfully performaed: +The policy configuration is returned when the call is successfully performed: ```json { diff --git a/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx b/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx index e55fe05c4..78a602b03 100644 --- a/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx +++ b/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx @@ -210,7 +210,7 @@ to the latest 1.8.x or 1.9.x before the next steps. Otherwise, this step can be **6.** Update the value of `global.image` in the values file to the latest 1.8.x or 1.9.x image. -Additionally, ensure that the Kuberenetes secret with the license is specified in the +Additionally, ensure that the Kubernetes secret with the license is specified in the values `server.enterpriseLicense.secretName` and `server.enterpriseLicense.secretKey`. **7.** Upgrade the cluster.