Backport of docs: Rename Consul OSS to Consul CE into release/1.16.x (#19016)
* backport of commit b96bdd91eb2ec91277a18d9b1725cd9b1a20f17e * backport of commit 6c87ff2c364d60abff87040bdf98176c07fc300d * backport of commit 56d3f8a55d5136b51daf5ccd16b273b314ee0868 --------- Co-authored-by: Blake Covarrubias <blake@covarrubi.as> Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com> Co-authored-by: Tu Nguyen <im2nguyen@gmail.com>
This commit is contained in:
parent
19761336c2
commit
f004db21bc
|
@ -396,7 +396,7 @@ $ curl \
|
|||
`leader`, `voter`, `non-voter`, or `staging`.
|
||||
- `Meta` is the node metadata of this server. Values within this map are used for determining a server's
|
||||
redundancy zone and upgrade version.
|
||||
- `NodeType` is the desired type autopilot thinks this server should have. In Consul OSS the only possible
|
||||
- `NodeType` is the desired type autopilot thinks this server should have. In Consul CE, the only possible
|
||||
value is `voter` as all present servers should having voting rights. In Consul Enterprise the possible values also
|
||||
include `read-replica`, `zone-voter`, `zone-standby` and `zone-extra-voter`. `zone-voter` indicates that autopilot
|
||||
wants this server to be the voter for a particular redundancy zone. When a zone has no voter all nodes will be typed
|
||||
|
|
|
@ -49,7 +49,7 @@ $ curl \
|
|||
|
||||
<Tabs>
|
||||
|
||||
<Tab heading="OSS">
|
||||
<Tab heading="CE">
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
@ -14,7 +14,7 @@ Command: `consul snapshot agent`
|
|||
~> The [`agent`](/consul/commands/snapshot/agent) subcommand described here is
|
||||
available only in [Consul Enterprise](https://www.hashicorp.com/products/consul/)
|
||||
version 0.7.1 and later. All other [snapshot subcommands](/consul/commands/snapshot)
|
||||
are available in the open source version of Consul.
|
||||
are available in the community edition of Consul.
|
||||
|
||||
The `snapshot agent` subcommand starts a process that takes snapshots of the
|
||||
state of the Consul servers and saves them locally, or pushes them to an
|
||||
|
|
|
@ -651,7 +651,7 @@ Any metric in this section can be turned off with the [`prefix_filter`](/consul/
|
|||
These metrics give insight into the health of the cluster as a whole.
|
||||
Query for the `consul.memberlist.*` and `consul.serf.*` metrics can be appended
|
||||
with certain labels to further distinguish data between different gossip pools.
|
||||
The supported label for OSS is `network`, while `segment`, `partition`, `area`
|
||||
The supported label for CE is `network`, while `segment`, `partition`, `area`
|
||||
are allowed for <EnterpriseAlert inline />.
|
||||
|
||||
| Metric | Description | Unit | Type |
|
||||
|
|
|
@ -47,11 +47,11 @@ While their likelihood remains low to very low, be aware of the following risks
|
|||
- If WAL corrupts data on a Consul server agent, the server data cannot be recovered. Restart the server with an empty data directory and reload its state from the leader to resolve the issue.
|
||||
- WAL may corrupt data or contain a defect that causes the server to panic and crash. WAL may not restart if the defect recurs when WAL reads from the logs on startup. Restart the server with an empty data directory and reload its state from the leader to resolve the issue.
|
||||
- If WAL corrupts data, clients may read corrupted data from the Consul server, such as invalid IP addresses or unmatched tokens. This outcome is unlikely even if a recurring defect causes WAL to corrupt data because replication uses objects cached in memory instead of reads from disk. Restart the server with an empty data directory and reload its state from the leader to resolve the issue.
|
||||
- If you enable a Consul OSS server to use WAL or enable WAL on a voting server with Consul Enterprise, WAL may corrupt the server's state, become the leader, and replicate the corrupted state to all other servers. In this case, restoring from backup is required to recover a completely uncorrupted state. Test WAL on a non-voting server in Enterprise to prevent this outcome. You can add a new non-voting server to the cluster to test with if there are no existing ones.
|
||||
- If you enable a Consul CE server to use WAL or enable WAL on a voting server with Consul Enterprise, WAL may corrupt the server's state, become the leader, and replicate the corrupted state to all other servers. In this case, restoring from backup is required to recover a completely uncorrupted state. Test WAL on a non-voting server in Enterprise to prevent this outcome. You can add a new non-voting server to the cluster to test with if there are no existing ones.
|
||||
|
||||
## Enable log verification
|
||||
|
||||
You must enable log verification on all voting servers in Enterprise and all servers in OSS because the leader writes verification checkpoints.
|
||||
You must enable log verification on all voting servers in Enterprise and all servers in CE because the leader writes verification checkpoints.
|
||||
|
||||
1. On each voting server, add the following to the server's configuration file:
|
||||
|
||||
|
@ -75,7 +75,7 @@ When complete, the server's logs should contain verifier reports that appear lik
|
|||
|
||||
## Select target server to enable WAL
|
||||
|
||||
If you are using Consul OSS or Consul Enterprise without non-voting servers, select a follower server to enable WAL. As noted in [Risks](#risks), Consul Enterprise users with non-voting servers should first select a non-voting server, or consider adding another server as a non-voter to test on.
|
||||
If you are using Consul CE, or Consul Enterprise without non-voting servers, select a follower server to enable WAL. As noted in [Risks](#risks), Consul Enterprise users with non-voting servers should first select a non-voting server, or consider adding another server as a non-voter to test on.
|
||||
|
||||
Retrieve the current state of the servers by running the following command:
|
||||
|
||||
|
|
|
@ -30,7 +30,7 @@ The following table describes the TCP port requirements for each component of th
|
|||
|
||||
## Consul server deployments
|
||||
|
||||
- Consul Editions supported: OSS and Enterprise
|
||||
- Consul Editions supported: CE and Enterprise
|
||||
- Supported Consul Server deployment types:
|
||||
- Self-Managed
|
||||
- HCP Consul
|
||||
|
|
|
@ -11,7 +11,7 @@ This topic describes the `exported-services` configuration entry type. The `expo
|
|||
|
||||
## Introduction
|
||||
|
||||
To configure Consul to export services contained in a Consul Enterprise admin partition or Consul OSS datacenter to one or more additional clusters, create a new configuration entry and declare `exported-services` in the `kind` field. This configuration entry enables you to route traffic between services in different clusters.
|
||||
To configure Consul to export services contained in a Consul Enterprise admin partition or Consul CE datacenter to one or more additional clusters, create a new configuration entry and declare `exported-services` in the `kind` field. This configuration entry enables you to route traffic between services in different clusters.
|
||||
|
||||
You can configure the settings defined in the `exported-services` configuration entry to apply to all namespaces in a Consul Enterprise admin partition.
|
||||
|
||||
|
@ -31,7 +31,7 @@ You can configure the settings defined in the `exported-services` configuration
|
|||
Configure the following parameters to define a `exported-services` configuration entry:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
<CodeTabs heading="Exported services configuration syntax" tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
|
||||
```hcl
|
||||
|
@ -256,7 +256,7 @@ The following table describes the parameters associated with the `exported-servi
|
|||
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
|
||||
| `Kind` | String value that enables the configuration entry. The value should always be `exported-services` (HCL and JSON) or `ExportedServices` (YAML) | Required | None |
|
||||
| `Partition` | <EnterpriseAlert inline /> String value that specifies the name of the partition that contains the services you want to export. | Required | None |
|
||||
| `Name` | String value that specifies the name of the partition that contains the services you want to export. Must be `default` in Consul OSS. | Required | None |
|
||||
| `Name` | String value that specifies the name of the partition that contains the services you want to export. Must be `default` in Consul CE. | Required | None |
|
||||
| `Services` | List of objects that specify which services to export. For details, refer to [`Services`](#services). | Required | None |
|
||||
| `Meta` | Object that defines a map of the max 64 key/value pairs. | Optional | None |
|
||||
|
||||
|
@ -288,7 +288,7 @@ A asterisk wildcard (`*`) cannot be specified as the `SamenessGroup`.
|
|||
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
The following example configures Consul to export the `payments` and `refunds` services to the peered `web-shop` cluster.
|
||||
|
||||
|
@ -580,7 +580,7 @@ spec:
|
|||
### Exporting all services
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
The following example configures Consul to export all services in the datacenter to the peered `monitoring` and `platform` clusters.
|
||||
|
||||
|
@ -780,7 +780,7 @@ spec:
|
|||
When an exported service has been imported to another cluster, you can use the `health` REST API endpoint to query the service on the consumer cluster.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
The following example queries the `finance` peer for the imported `payments` service:
|
||||
|
||||
|
@ -795,7 +795,7 @@ If the call in the previous example is made from a service named `web`, then the
|
|||
- A token with `service:write` permissions to `web`.
|
||||
- A token with `service:read` and `node:read` to all names in the datacenter.
|
||||
|
||||
<CodeTabs heading="Example ACL rules for reading imported services in Consul OSS">
|
||||
<CodeTabs heading="Example ACL rules for reading imported services in Consul CE">
|
||||
|
||||
```hcl
|
||||
service "web" {
|
||||
|
|
|
@ -1529,7 +1529,7 @@ Refer to the following examples for common ingress gateway configuration pattern
|
|||
|
||||
The following example sets up a TCP listener on an ingress gateway named `us-east-ingress` that proxies traffic to the `db` service. For Consul Enterprise, the `db` service can only listen for traffic in the `default` namespace inside the `team-frontend` admin partition:
|
||||
|
||||
#### Consul OSS
|
||||
#### Consul CE
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
|
||||
|
@ -1656,7 +1656,7 @@ The Consul Enterprise version implements the following additional configurations
|
|||
- The ingress gateway is set up in the `default` [namespace](/consul/docs/enterprise/namespaces) and proxies traffic to all services in the `frontend` namespace.
|
||||
- The `api` and `web` services are proxied to team-specific [admin partitions](/consul/docs/enterprise/admin-partitions):
|
||||
|
||||
#### Consul OSS
|
||||
#### Consul CE
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ Settings in this config entry apply across all namespaces and federated datacent
|
|||
Enforce that service mesh mTLS traffic uses TLS v1.2 or newer.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
|
||||
|
@ -108,7 +108,7 @@ Note that the Kubernetes example does not include a `partition` field. Configura
|
|||
Only allow transparent proxies to dial addresses in the mesh.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
|
||||
|
@ -189,7 +189,7 @@ Note that the Kubernetes example does not include a `partition` field. Configura
|
|||
Set the `PeerThroughMeshGateways` parameter to `true` to route peering control plane traffic through mesh gateways.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
|
||||
|
@ -315,7 +315,7 @@ Note that the Kubernetes example does not include a `partition` field. Configura
|
|||
name: 'namespace',
|
||||
enterprise: true,
|
||||
description:
|
||||
'Must be set to `default`. If running Consul Open Source, the namespace is ignored (see [Kubernetes Namespaces in Consul OSS](/consul/docs/k8s/crds#consul-oss)). If running Consul Enterprise see [Kubernetes Namespaces in Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for additional information.',
|
||||
'Must be set to `default`. If running Consul Community Edition, the namespace is ignored (see [Kubernetes Namespaces in Consul CE](/consul/docs/k8s/crds#consul-ce)). If running Consul Enterprise see [Kubernetes Namespaces in Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for additional information.',
|
||||
},
|
||||
],
|
||||
hcl: false,
|
||||
|
|
|
@ -899,7 +899,7 @@ Specifies the name of the service you are setting the defaults for.
|
|||
|
||||
### `metadata.namespace` <Enterprise/>
|
||||
|
||||
Specifies the Consul namespace that the configuration entry applies to. Refer to [Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for information about how Consul namespaces map to Kubernetes Namespaces. Open source Consul distributions (Consul OSS) ignore the `metadata.namespace` configuration.
|
||||
Specifies the Consul namespace that the configuration entry applies to. Refer to [Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for information about how Consul namespaces map to Kubernetes Namespaces. Consul Community Edition (Consul CE) ignores the `metadata.namespace` configuration.
|
||||
|
||||
- Default: `default`
|
||||
- Data type: String
|
||||
|
@ -1336,7 +1336,7 @@ You can also set the global default protocol for all proxies in the [`proxy-defa
|
|||
### Upstream configuration
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
The following example sets default connection limits and mesh gateway mode across all upstreams of the `dashboard` service.
|
||||
It also overrides the mesh gateway mode used when dialing its `counting` upstream service.
|
||||
|
@ -1612,13 +1612,13 @@ Proxy services must be in transparent proxy mode to configure destinations. Refe
|
|||
{
|
||||
name: 'namespace',
|
||||
description:
|
||||
'If running Consul Open Source, the namespace is ignored (see [Kubernetes Namespaces in Consul OSS](/consul/docs/k8s/crds#consul-oss)). If running Consul Enterprise see [Kubernetes Namespaces in Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for more details.',
|
||||
'If running Consul Community Edition, the namespace is ignored (see [Kubernetes Namespaces in Consul CE](/consul/docs/k8s/crds#consul-ce)). If running Consul Enterprise see [Kubernetes Namespaces in Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for more details.',
|
||||
},
|
||||
{
|
||||
name: 'partition',
|
||||
enterprise: true,
|
||||
description:
|
||||
'Specifies the admin partition in which the configuration will apply. The current partition is used if unspecified. Refer to the [Admin Partitions documentation](/consul/docs/enterprise/admin-partitions) for details. The partitions parameter is not supported in Consul OSS.',
|
||||
'Specifies the admin partition in which the configuration will apply. The current partition is used if unspecified. Refer to the [Admin Partitions documentation](/consul/docs/enterprise/admin-partitions) for details. The partitions parameter is not supported in Consul CE.',
|
||||
},
|
||||
],
|
||||
hcl: false,
|
||||
|
|
|
@ -687,7 +687,7 @@ Map that contains an arbitrary name for the configuration entry and the namespac
|
|||
|
||||
Specifies an arbitrary name for the configuration entry. Note that in other configuration entries, the `metadata.name` field specifies the name of the service that the settings apply to. For service intentions, the service that accepts the configurations is the _destination_ and is specified in the [`spec.destination.name`](#spec-destination-name) field. Refer to the following topics for additional information:
|
||||
|
||||
- [ServiceIntentions Special Case (OSS)](/consul/docs/k8s/crds#serviceintentions-special-case)
|
||||
- [ServiceIntentions Special Case (CE)](/consul/docs/k8s/crds#serviceintentions-special-case)
|
||||
- [ServiceIntentions Special Case (Enterprise)](/consul/docs/k8s/crds#serviceintentions-special-case-enterprise)
|
||||
|
||||
#### Values
|
||||
|
@ -697,7 +697,7 @@ Specifies an arbitrary name for the configuration entry. Note that in other conf
|
|||
|
||||
### `metadata.namespace` <EnterpriseAlert inline />
|
||||
|
||||
Specifies the [namespace](/consul/docs/enterprise/namespaces) that the configuration entry applies to. Refer to [Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for information about how Consul namespaces map to Kubernetes Namespaces. Open source Consul distributions (Consul OSS) ignore the `metadata.namespace` configuration.
|
||||
Specifies the [namespace](/consul/docs/enterprise/namespaces) that the configuration entry applies to. Refer to [Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for information about how Consul namespaces map to Kubernetes Namespaces. Consul Community Edition (Consul CE) ignores the `metadata.namespace` configuration.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
|
@ -46,7 +46,7 @@ traffic from the mesh to those services will be evenly load-balanced between the
|
|||
### Access an external service
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
Link gateway named "us-west-gateway" with the billing service.
|
||||
|
||||
|
@ -144,7 +144,7 @@ spec:
|
|||
### Access an external service over TLS
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
Link gateway named "us-west-gateway" with the billing service, and specify a CA
|
||||
file to be used for one-way TLS authentication.
|
||||
|
@ -259,7 +259,7 @@ spec:
|
|||
### Access an external service over mutual TLS
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
Link gateway named "us-west-gateway" with the billing service, and specify a CA
|
||||
file, key file, and cert file to be used for mutual TLS authentication.
|
||||
|
@ -385,7 +385,7 @@ spec:
|
|||
### Override connection parameters for a specific service
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
Link gateway named "us-west-gateway" with all services in the datacenter, and configure default certificates for mutual TLS.
|
||||
|
||||
|
@ -611,7 +611,7 @@ spec:
|
|||
{
|
||||
name: 'namespace',
|
||||
description:
|
||||
'If running Consul Open Source, the namespace is ignored (see [Kubernetes Namespaces in Consul OSS](/consul/docs/k8s/crds#consul-oss)). If running Consul Enterprise see [Kubernetes Namespaces in Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for more details.',
|
||||
'If running Consul Community Edition, the namespace is ignored (see [Kubernetes Namespaces in Consul CE](/consul/docs/k8s/crds#consul-ce)). If running Consul Enterprise see [Kubernetes Namespaces in Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for more details.',
|
||||
},
|
||||
],
|
||||
hcl: false,
|
||||
|
|
|
@ -22,7 +22,7 @@ Consul Dataplane requires servers running Consul version `v1.14+`. To find a spe
|
|||
The following options are required when starting `consul-dataplane` with the CLI:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
- `-addresses`
|
||||
- `-service-node-name`
|
||||
|
@ -139,7 +139,7 @@ A static ACL token is passed to Consul Dataplane.
|
|||
Consul Dataplane logs in to one of Consul's supported [auth methods](/consul/docs/security/acl/auth-methods).
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
```shell-session
|
||||
$ consul-dataplane -credential-type "login"
|
||||
|
|
|
@ -55,13 +55,13 @@ For Consul Enterprise clusters, mesh gateways must be registered in the "default
|
|||
### ACL configuration
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
In addition to the [ACL Configuration](/consul/docs/connect/cluster-peering/tech-specs#acl-specifications) necessary for service-to-service traffic, mesh gateways that route peering control plane traffic must be granted `peering:read` access to all peerings.
|
||||
|
||||
This access allows the mesh gateway to list all peerings in a Consul cluster and generate unique routing per peered datacenter.
|
||||
|
||||
<CodeTabs heading="Example ACL rules for Mesh Gateway Peering Control Plane Traffic in Consul OSS">
|
||||
<CodeTabs heading="Example ACL rules for Mesh Gateway Peering Control Plane Traffic in Consul CE">
|
||||
|
||||
```hcl
|
||||
peering = "read"
|
||||
|
|
|
@ -78,7 +78,7 @@ The following table shows match precedence in descending order:
|
|||
Consul prints the precedence value to the service intentions configuration entry after it processes the matching criteria. The value is read-only. Refer to
|
||||
[`Precedence`](/consul/docs/connect/config-entries/service-intentions#precedence) for additional information.
|
||||
|
||||
Namespaces are an Enterprise feature. In Consul OSS, the only allowable value for either namespace field is `"default"`. Other rows in the table are not applicable.
|
||||
Namespaces are an Enterprise feature. In Consul CE, the only allowable value for either namespace field is `"default"`. Other rows in the table are not applicable.
|
||||
|
||||
The [intention match API](/consul/api-docs/connect/intentions#list-matching-intentions)
|
||||
should be periodically called to retrieve all relevant intentions for the
|
||||
|
|
|
@ -14,7 +14,7 @@ By specifying a JSON Web Key Set (JWKS) in the configuration entry and referenci
|
|||
|
||||
The process to configure your network to enforce service intentions based on JSON web tokens consists of the following steps:
|
||||
|
||||
1. **Create a JWT provider configuration entry**. This configuration entry defines rules and behaviors for verifying tokens. These configurations apply to admin partitions in Consul Enterprise, which is functionally equivalent to a datacenter in Consul OSS. Then, write the `jwt-provider` configuration entry to Consul. The ACL policy requirement to read and modify this configuration entry is `mesh:write`.
|
||||
1. **Create a JWT provider configuration entry**. This configuration entry defines rules and behaviors for verifying tokens. These configurations apply to admin partitions in Consul Enterprise, which is functionally equivalent to a datacenter in Consul CE. Then, write the `jwt-provider` configuration entry to Consul. The ACL policy requirement to read and modify this configuration entry is `mesh:write`.
|
||||
|
||||
1. **Create or update a service intentions configuration entry to reference the JWT provider**. This configuration invokes the name of the `jwt-provider` configuration entry you created, which causes the Envoy proxy to verify the token and the permissions it authorizes before the incoming request is accepted. Then, write the `service-intentions` configuration entry that references the JWT to Consul. The ACL policy requirement to read and modify this configuration entry is `mesh:write`.
|
||||
|
||||
|
|
|
@ -117,7 +117,7 @@ valid non-wildcard intentions to match.
|
|||
The numbers in the table above are not stable. Their ordering will remain
|
||||
fixed but the actual number values may change in the future.
|
||||
|
||||
-> **Consul Enterprise** - Namespaces are an Enterprise feature. In Consul OSS any of the rows in
|
||||
-> **Consul Enterprise** - Namespaces are an Enterprise feature. In Consul CE, any of the rows in
|
||||
the table with a `*` for either the source namespace or destination namespace are not applicable.
|
||||
|
||||
## Intention Management Permissions
|
||||
|
|
|
@ -225,7 +225,7 @@ With ACLs enabled, the proxy endpoint requires a valid token with read access
|
|||
to all nodes and services (across all namespaces in Enterprise):
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Consul OSS">
|
||||
<Tab heading="Consul CE">
|
||||
|
||||
<CodeTabs heading="Example policy granting read-only access to all services and nodes">
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ Refer to [Gateways overview](/consul/docs/connect/gateways) for additional infor
|
|||
|
||||
## Supported proxies
|
||||
|
||||
Consul has first-class support for Envoy proxies, which is a highly configurable open source edge service. Consul configures Envoy by optionally exposing a gRPC service on the local agent that serves Envoy's xDS configuration API. Refer to the following documentation for additional information:
|
||||
Consul has first-class support for Envoy proxies, which is a highly configurable open source edge service proxy. Consul configures Envoy by optionally exposing a gRPC service on the local agent that serves Envoy's xDS configuration API. Refer to the following documentation for additional information:
|
||||
|
||||
- [Envoy proxy reference](/consul/docs/connect/proxies/envoy)
|
||||
- [Envoy API documentation](https://www.envoyproxy.io/docs/envoy/v1.17.2/api-docs/xds_protocol)
|
||||
|
|
|
@ -34,14 +34,14 @@ Consul on ECS with ACLs enabled, the license will be automatically pulled down f
|
|||
Currently there is no capability for specifying the license when ACLs are disabled so if you wish to
|
||||
run Consul Enterprise clients then you must enable ACLs.
|
||||
|
||||
## Running Open Source Consul Clients
|
||||
## Running Consul Community Edition clients
|
||||
|
||||
You can operate Consul Enterprise servers with Consul OSS (open source) clients as long as the features you are using do not require Consul Enterprise client support. Admin partitions and namespaces, for example, require Consul Enterprise clients and are not supported with Consul OSS.
|
||||
You can operate Consul Enterprise servers with Consul CE (community edition) clients as long as the features you are using do not require Consul Enterprise client support. Admin partitions and namespaces, for example, require Consul Enterprise clients and are not supported with Consul CE.
|
||||
|
||||
## Feature Support
|
||||
|
||||
Consul on ECS supports the following Consul Enterprise features.
|
||||
If you are only using features that run on Consul servers, then you can use an OSS client in your service mesh tasks on ECS.
|
||||
If you are only using features that run on Consul servers, then you can use a CE client in your service mesh tasks on ECS.
|
||||
If client support is required for any of the features, then you must use a Consul Enterprise client in your `mesh-tasks`.
|
||||
|
||||
| Feature | Supported | Description |
|
||||
|
@ -54,8 +54,8 @@ If client support is required for any of the features, then you must use a Consu
|
|||
| Advanced Federation/Network Areas | Yes (servers) | This feature runs on Consul servers. |
|
||||
| Sentinel | Yes (servers) | This feature runs on Consul servers. |
|
||||
| Network Segments | No | Currently there is no capability to configure the network segment Consul clients on ECS run in. |
|
||||
| Namespaces | Yes | This feature requires Consul Enterprise servers. OSS clients can register into the `default` namespace. Registration into a non-default namespace requires a Consul Enterprise client. |
|
||||
| Admin Partitions | Yes | This feature requires Consul Enterprise servers. OSS clients can register into the `default` admin partition. Registration into a non-default partition requires a Consul Enterprise client. |
|
||||
| Namespaces | Yes | This feature requires Consul Enterprise servers. CE clients can register into the `default` namespace. Registration into a non-default namespace requires a Consul Enterprise client. |
|
||||
| Admin Partitions | Yes | This feature requires Consul Enterprise servers. CE clients can register into the `default` admin partition. Registration into a non-default partition requires a Consul Enterprise client. |
|
||||
| Audit Logging | Yes | This feature requires Consul Enterprise clients. |
|
||||
|
||||
### Admin Partitions and Namespaces
|
||||
|
|
|
@ -23,7 +23,7 @@ Admin partitions exist a level above namespaces in the identity hierarchy. They
|
|||
|
||||
As of Consul v1.11, every _datacenter_ contains a single administrative partition named `default` when created. With Consul Enterprise, operators have the option of creating multiple partitions within a single datacenter.
|
||||
|
||||
-> **Preexisting nodes**: Admin partitions were introduced in Consul 1.11. Nodes existed in global scope prior to 1.11. After upgrading to Consul 1.11 or later, all nodes will be scoped to an admin partition, which will be the `default` partition when initially upgrading an existing deployment or for OSS versions.
|
||||
-> **Preexisting nodes**: Admin partitions were introduced in Consul 1.11. Nodes existed in global scope prior to 1.11. After upgrading to Consul 1.11 or later, all nodes will be scoped to an admin partition, which will be the `default` partition when initially upgrading an existing deployment or for CE versions.
|
||||
|
||||
There are tutorials available to help you get started with admin partitions.
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
layout: docs
|
||||
page_title: Consul Enterprise
|
||||
description: >-
|
||||
Consul Enterprise is a paid offering that extends Consul’s open source functions to support large and complex deployments. Learn about scaling infrastructure, simplifying operations, and making networks more resilient with Enterprise. Evaluate Enterprise features with the feature availability and compatibility matrix.
|
||||
Consul Enterprise is a paid offering that extends Consul Community Edition to support large and complex deployments. Learn about scaling infrastructure, simplifying operations, and making networks more resilient with Enterprise. Evaluate Enterprise features with the feature availability and compatibility matrix.
|
||||
---
|
||||
|
||||
# Consul Enterprise
|
||||
|
|
|
@ -50,7 +50,7 @@ Network segments are a subset of other Consul networking models. Understanding t
|
|||
|
||||
### Clusters
|
||||
|
||||
You can segment networks within a Consul _cluster_. A cluster is one or more Consul servers that form a Raft quorum and one or more Consul clients that are members of the same [datacenter](/consul/docs/agent/config/cli-flags#_datacenter). The cluster is sometimes called the _local cluster_. Consul clients discover and make RPC requests to Consul servers in their local cluster through the gossip mechanism. Consul OSS uses LAN gossip for intra-cluster communication between agents.
|
||||
You can segment networks within a Consul _cluster_. A cluster is one or more Consul servers that form a Raft quorum and one or more Consul clients that are members of the same [datacenter](/consul/docs/agent/config/cli-flags#_datacenter). The cluster is sometimes called the _local cluster_. Consul clients discover and make RPC requests to Consul servers in their local cluster through the gossip mechanism. Consul CE uses LAN gossip for intra-cluster communication between agents.
|
||||
|
||||
### LAN gossip pool
|
||||
|
||||
|
|
|
@ -53,7 +53,7 @@ These Consul tools are created and managed by the amazing members of the Consul
|
|||
- [Gonsul](https://github.com/miniclip/gonsul) - A Git to Consul standalone tool made in Go. Updates Consul KV from a repo with multiple strategies.
|
||||
- [gradle-consul-plugin](https://github.com/amirkibbar/red-apple) - A Consul Gradle plugin
|
||||
- [hashi-ui](https://github.com/jippi/hashi-ui) - A modern user interface for the Consul and Nomad
|
||||
- [HashiBox](https://github.com/nunchistudio/hashibox) - Vagrant environment to simulate highly-available cloud with Consul, Nomad, Vault, and optional support for Waypoint. OSS & Enterprise supported.
|
||||
- [HashiBox](https://github.com/nunchistudio/hashibox) - Vagrant environment to simulate highly-available cloud with Consul, Nomad, Vault, and optional support for Waypoint. This supports both Consul CE and Enterprise.
|
||||
- [Jenkins Consul Plugin](https://plugins.jenkins.io/consul) - Jenkins plugin for service discovery and K/V store
|
||||
- [marathon-consul](https://github.com/allegro/marathon-consul) - Service registry bridge for Marathon
|
||||
- [marathon-consul](https://github.com/CiscoCloud/marathon-consul) - Bridge from Marathon apps to the Consul K/V store
|
||||
|
|
|
@ -9,7 +9,7 @@ description: >-
|
|||
|
||||
The HashiCorp Consul Integration Program enables prospective partners to build integrations with HashiCorp Consul that are reviewed and verified by HashiCorp. You can integrate with any of the following Consul versions:
|
||||
|
||||
- **Self-Managed**. Open source, always free
|
||||
- **Self-Managed**. Community Edition, always free
|
||||
- **HashiCorp Cloud Platform (HCP)**. A hosted version of Consul managed in the cloud
|
||||
- **Consul Enterprise**. Self-managed, with additional features for custom deployments
|
||||
|
||||
|
@ -17,7 +17,7 @@ The program is intended to be largely self-service with links to resources, code
|
|||
|
||||
## Categories of Consul Integrations
|
||||
|
||||
By leveraging Consul's RESTful HTTP API system, prospective partners are able to build extensible integrations at the data plane, platform, and the infrastructure layer to extend Consul's functionalities. These integrations can be performed both with the open source version of Consul, Consul Enterprise, and HCP Consul.
|
||||
By leveraging Consul's RESTful HTTP API system, prospective partners are able to build extensible integrations at the data plane, platform, and the infrastructure layer to extend Consul's functionalities. These integrations can be performed both with the community edition of Consul, Consul Enterprise, and HCP Consul.
|
||||
|
||||
**The Consul ecosystem of integrations:**
|
||||
|
||||
|
|
|
@ -75,7 +75,7 @@ Rolling out changes can be risky, especially in complex network environments. Up
|
|||
|
||||
## Consul Enterprise
|
||||
|
||||
HashiCorp offers core Consul functionality for free in the open source version, which is ideal for smaller businesses and teams that want to pilot Consul within their organizations. As your business grows, you can upgrade to Consul Enterprise, which offers additional capabilities designed to address organizational complexities of collaboration, operations, scale, and governance.
|
||||
HashiCorp offers core Consul functionality for free in the community edition, which is ideal for smaller businesses and teams that want to pilot Consul within their organizations. As your business grows, you can upgrade to Consul Enterprise, which offers additional capabilities designed to address organizational complexities of collaboration, operations, scale, and governance.
|
||||
|
||||
### HCP Consul
|
||||
|
||||
|
|
|
@ -159,9 +159,9 @@ the `ServiceSplitter`.
|
|||
|
||||
## Kubernetes Namespaces
|
||||
|
||||
### Consul OSS
|
||||
### Consul CE ((#consul_oss))
|
||||
|
||||
Consul Open Source (Consul OSS) ignores Kubernetes namespaces and registers all services into the same
|
||||
Consul Community Edition (Consul CE) ignores Kubernetes namespaces and registers all services into the same
|
||||
global Consul registry based on their names. For example, service `web` in Kubernetes namespace
|
||||
`web-ns` and service `admin` in Kubernetes namespace `admin-ns` are registered into
|
||||
Consul as `web` and `admin` with the Kubernetes source namespace ignored.
|
||||
|
|
|
@ -129,7 +129,7 @@ The registrator also requires the following IAM permissions to access the parame
|
|||
| `consul_ca_cert_path` | Specifies the path to the CA certificate stored in the AWS Parameter Store. When Lambda registrator makes an HTTPS request to Consul's API and the Consul API is signed by a custom CA, Lambda registrator uses this CA certificate to verify the authenticity of the Consul API. At startup, Lambda registrator pulls the CA certificate at this path from Parameter Store, writes the certificate to the filesystem and stores the path of that file in `CONSUL_CACERT`. Also refer to [Optional: Store the CA Certificate in Parameter Store](#optional-store-the-ca-certificate-in-parameter-store).|
|
||||
| `consul_http_token_path` | Specifies the path to the ACL token stored in AWS Parameter Store that Lambda registrator presents to access resources. This parameter is only required when ACLs are enabled for the Consul server. It is used to fetch an ACL token from Parameter Store and is stored in the `CONSUL_HTTP_TOKEN` environment variable. Also refer tp [Optional: Store the ACL Token in Parameter Store](#optional-store-the-acl-token-in-parameter-store).|
|
||||
| `node_name` | The Consul node name that Lambdas are registered to. Defaults to `lambdas`. |
|
||||
| `enterprise` | <EnterpriseAlert inline /> Determines if the Consul server at `consul_http_addr` is running open source Consul or Consul Enterprise. |
|
||||
| `enterprise` | <EnterpriseAlert inline /> Determines if the Consul server at `consul_http_addr` is running Consul Community Edition or Consul Enterprise. |
|
||||
| `partitions` | <EnterpriseAlert inline /> The partitions that Lambda registrator manages. |
|
||||
|
||||
## Deploy the Lambda registrator
|
||||
|
|
|
@ -13,7 +13,7 @@ This topic describes Consul-Terraform-Sync (CTS) cross-compatibility with Consul
|
|||
|
||||
Below are CTS versions with supported Consul versions. The latest CTS binary supports the three most recent Consul minor versions, along with their latest patch versions.
|
||||
|
||||
| CTS Version | Consul OSS & Enterprise Version | HCP Consul Version |
|
||||
| CTS Version | Consul Community Edition & Enterprise Version | HCP Consul Version |
|
||||
| :--------------------- | :------------------------------ | :----------------- |
|
||||
| CTS Enterprise 0.6+ | 1.8+ | 1.9+ |
|
||||
| CTS Enterprise 0.3-0.5 | 1.8+ | N/A |
|
||||
|
|
|
@ -11,10 +11,10 @@ Consul-Terraform-Sync (CTS) Enterprise is available with [Consul Enterprise](htt
|
|||
|
||||
Enterprise features of CTS address organization complexities of collaboration, operations, scale, and governance. CTS Enterprise supports an official integration with [Terraform Cloud](https://cloud.hashicorp.com/products/terraform) and [Terraform Enterprise](/terraform/enterprise), the self-hosted distribution, to extend insight into dynamic updates of your network infrastructure.
|
||||
|
||||
| Features | Open Source | Enterprise |
|
||||
| Features | Community Edition | Enterprise |
|
||||
|----------|-------------|------------|
|
||||
| Consul Namespace | Default namespace only | Filter task triggers by any namespace |
|
||||
| Automation Driver | Terraform OSS | Terraform OSS, Terraform Cloud, or Terraform Enterprise |
|
||||
| Automation Driver | Terraform Community Edition | Terraform Community Edition, Terraform Cloud, or Terraform Enterprise |
|
||||
| Terraform Workspaces | Local | Local workspaces with the Terraform driver or [remote workspaces](/terraform/cloud-docs/workspaces) with the Terraform Cloud driver |
|
||||
| Terraform Backend Options | [azurerm](/terraform/language/settings/backends/azurerm), [consul](/terraform/language/settings/backends/consul), [cos](/terraform/language/settings/backends/cos), [gcs](/terraform/language/settings/backends/gcs), [kubernetes](/terraform/language/settings/backends/kubernetes), [local](/terraform/language/settings/backends/local), [manta](/terraform/language/v1.2.x/settings/backends/manta), [pg](/terraform/language/settings/backends/pg), and [s3](/terraform/language/settings/backends/s3) with the Terraform driver | The supported backends for CTS with the Terraform driver or Terraform Cloud with the Terraform Cloud driver |
|
||||
| Terraform Version | One Terraform version for all tasks | Optional Terraform version per task when using the Terraform Cloud driver |
|
||||
|
|
|
@ -32,7 +32,7 @@ Consul ESM only supports `default` admin partitions.
|
|||
|
||||
@include 'create-token-requirements.mdx'
|
||||
|
||||
## Consul ESM token in Consul OSS
|
||||
## Consul ESM token in Consul CE
|
||||
|
||||
To create a token for Consul ESM, you must define a policy, register the policy with Consul, and link the policy to a token.
|
||||
|
||||
|
|
|
@ -29,7 +29,7 @@ The DNS token must be linked to policies that grant the following permissions:
|
|||
|
||||
@include 'create-token-requirements.mdx'
|
||||
|
||||
## DNS token in Consul OSS
|
||||
## DNS token in Consul CE
|
||||
|
||||
To create a token for DNS, you must define a policy, register the policy with Consul, and link the policy to a token.
|
||||
|
||||
|
|
|
@ -37,7 +37,7 @@ The mesh gateway must present a token linked to a policy that grants the followi
|
|||
|
||||
@include 'create-token-requirements.mdx'
|
||||
|
||||
## Consul OSS
|
||||
## Consul CE
|
||||
|
||||
To create a token for the mesh gateway, you must define a policy, register the policy with Consul, and link the policy to a token.
|
||||
|
||||
|
|
|
@ -27,7 +27,7 @@ For a Consul server agent with ACL replication enabled in a secondary datacenter
|
|||
|
||||
@include 'create-token-requirements.mdx'
|
||||
|
||||
## Replication token in Consul OSS
|
||||
## Replication token in Consul CE
|
||||
|
||||
To create a token for ACL replication, you must define a policy, register the policy with Consul, and link the policy to a token.
|
||||
|
||||
|
|
|
@ -33,7 +33,7 @@ The service token must be linked to policies that grant the following permission
|
|||
|
||||
@include 'create-token-requirements.mdx'
|
||||
|
||||
## Service identity in Consul OSS
|
||||
## Service identity in Consul CE
|
||||
|
||||
Refer to [Service identities](/consul/docs/security/acl#service-identities) for information about creating service identities that you can link to tokens.
|
||||
|
||||
|
@ -123,7 +123,7 @@ $ curl --request PUT http://127.0.0.1:8500/v1/acl/token \
|
|||
|
||||
</Tabs>
|
||||
|
||||
## Custom policy in Consul OSS
|
||||
## Custom policy in Consul CE
|
||||
|
||||
When you are unable to link tokens to a service identity, you can define policies, register them with Consul, and link the policies to tokens that enable services to register into the Consul catalog.
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ Core ACL functionality is available in all versions of Consul.
|
|||
|
||||
### Requirements for the `agent` command
|
||||
|
||||
The [`agent`](/consul/commands/snapshot/agent) subcommand requires [Consul Enterprise](https://www.hashicorp.com/products/consul/). All other [`snapshot` subcommands](/consul/commands/snapshot) are available in the open source version of Consul.
|
||||
The [`agent`](/consul/commands/snapshot/agent) subcommand requires [Consul Enterprise](https://www.hashicorp.com/products/consul/). All other [`snapshot` subcommands](/consul/commands/snapshot) are available in Consul Community Edition.
|
||||
|
||||
### Snapshot agent ACL requirements
|
||||
|
||||
|
|
|
@ -29,7 +29,7 @@ The terminating gateway token must be linked to policies that grant the appropri
|
|||
|
||||
@include 'create-token-requirements.mdx'
|
||||
|
||||
## Consul OSS
|
||||
## Consul CE
|
||||
|
||||
To create a token for the terminating gateway, you must define a policy, register the policy with Consul, and link the policy to a token.
|
||||
|
||||
|
|
|
@ -19,7 +19,7 @@ Core ACL functionality is available in all versions of Consul.
|
|||
|
||||
@include 'create-token-requirements.mdx'
|
||||
|
||||
## View catalog in Consul OSS
|
||||
## View catalog in Consul CE
|
||||
|
||||
This section describes how to create a token that grants read-only access to the catalog. This token allows users to view the catalog without the ability to make changes. To create the ACL token, define a policy, create the policy, and then link the policy to a token.
|
||||
|
||||
|
@ -276,7 +276,7 @@ $ curl --request PUT http://127.0.0.1:8500/v1/acl/token \
|
|||
|
||||
</Tabs>
|
||||
|
||||
## View all resources in Consul OSS
|
||||
## View all resources in Consul CE
|
||||
|
||||
This section describes how to create a token with read-only access to all resources in the Consul UI. This token allows users to view any resources without the ability to make changes. To create the ACL token, define a policy, create the policy, and then link the policy to a token.
|
||||
|
||||
|
|
|
@ -34,7 +34,7 @@ The agent token must be linked to policies that grant the following permissions:
|
|||
|
||||
@include 'create-token-requirements.mdx'
|
||||
|
||||
## Node identity in Consul OSS
|
||||
## Node identity in Consul CE
|
||||
|
||||
Refer to [Node identities](/consul/docs/security/acl#node-identities) for information about node identities that you can link to tokens.
|
||||
|
||||
|
@ -125,7 +125,7 @@ $ curl --request PUT http://127.0.0.1:8500/v1/acl/token \
|
|||
|
||||
</Tabs>
|
||||
|
||||
## Custom policy in Consul OSS
|
||||
## Custom policy in Consul CE
|
||||
|
||||
When you are unable to link tokens to a node identity, you can define policies, register them with Consul, and link the policies to tokens that enable nodes to register into the Consul catalog.
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ The ingress gateway token must be linked to policies that grant the following pe
|
|||
|
||||
@include 'create-token-requirements.mdx'
|
||||
|
||||
## Consul OSS
|
||||
## Consul CE
|
||||
|
||||
To create a token for the ingress gateway, you must define a policy, register the policy with Consul, and link the policy to a token.
|
||||
|
||||
|
|
|
@ -182,7 +182,7 @@ environment and adapt these configurations accordingly.
|
|||
deployed within Consul.
|
||||
|
||||
- **🏷 Namespace** <EnterpriseAlert inline /> - a named, logical scoping of Consul Enterprise resources, typically to
|
||||
enable multi-tenant environments. Consul OSS clusters always operate within the "default" namespace.
|
||||
enable multi-tenant environments. Consul CE clusters always operate within the "default" namespace.
|
||||
|
||||
- **Gossip Encryption** - A shared, base64-encoded 32-byte symmetric key is required to [encrypt Serf gossip
|
||||
communication](/consul/tutorials/security/gossip-encryption-secure?utm_source=consul.io&utm_medium=docs) within a cluster using
|
||||
|
|
|
@ -127,7 +127,7 @@ Create a file for the configuration entry and specify the required fields. If yo
|
|||
|
||||
If you use Consul Enterprise, you can also specify the `Namespace` and `Partition` fields to apply the configuration to services in a specific namespace or partition. For Kubernetes environments, the configuration entry is always created in the same partition as the Kubernetes cluster.
|
||||
|
||||
### Consul OSS example
|
||||
### Consul CE example
|
||||
The following example instructs services named `counting` to send up to `512` concurrent requests to a mesh gateway:
|
||||
|
||||
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
|
||||
|
|
|
@ -22,7 +22,7 @@ First, download the binary for the new version you want.
|
|||
<Tabs>
|
||||
<Tab heading="Binary">
|
||||
|
||||
All current and past versions of the OSS and Enterprise releases are
|
||||
All current and past versions of the CE and Enterprise releases are
|
||||
available here:
|
||||
|
||||
- https://releases.hashicorp.com/consul
|
||||
|
@ -32,7 +32,7 @@ available here:
|
|||
|
||||
Docker containers are available at these locations:
|
||||
|
||||
- **OSS:** https://hub.docker.com/_/consul
|
||||
- **CE:** https://hub.docker.com/_/consul
|
||||
- **Enterprise:** https://hub.docker.com/r/hashicorp/consul-enterprise
|
||||
|
||||
</Tab>
|
||||
|
@ -171,8 +171,8 @@ Most of these problems can be solved by following the steps outlined in our
|
|||
If you are still having trouble after trying the recovery steps outlined there,
|
||||
then the following options for further assistance are available:
|
||||
|
||||
- OSS users without paid support plans can request help in our [Community Forum](https://discuss.hashicorp.com/c/consul/29)
|
||||
- Enterprise and OSS users with paid support plans can contact [HashiCorp Support](https://support.hashicorp.com/)
|
||||
- CE users without paid support plans can request help in our [Community Forum](https://discuss.hashicorp.com/c/consul/29)
|
||||
- Enterprise and CE users with paid support plans can contact [HashiCorp Support](https://support.hashicorp.com/)
|
||||
|
||||
When contacting Hashicorp Support, please include the following information in your ticket:
|
||||
|
||||
|
|
|
@ -19,7 +19,7 @@ will require intermediate version upgrades to a forward-compatible release of v1
|
|||
as well as other licensing related configuration changes. If you have multiple Consul datacenters,
|
||||
upgrade them in the normal order and take the following instructions into account for each upgrade.
|
||||
|
||||
For the open source version of Consul please follow the
|
||||
For Consul Community Edition, please follow the
|
||||
[General Upgrade Process](/consul/docs/upgrading/instructions/general-process).
|
||||
|
||||
~> You can only upgrade to Consul Enterprise 1.10 from a version of Consul Enterprise
|
||||
|
|
|
@ -752,11 +752,11 @@ fields which are those documented in the example payloads in the API documentati
|
|||
|
||||
### DNS PTR Record Output
|
||||
|
||||
Consul will now return the canonical service name in response to PTR queries. For OSS users the
|
||||
Consul will now return the canonical service name in response to PTR queries. For CE users, the
|
||||
change is that the datacenter will be present where it was not before. For Consul Enterprise
|
||||
users, both the datacenter and the services namespace will be present. For example, where a
|
||||
PTR record would previously have contained `web.service.consul`, it will now be `web.service.dc1.consul`
|
||||
in OSS or `web.service.ns1.dc1.consul` for Enterprise.
|
||||
in CE, or `web.service.ns1.dc1.consul` for Enterprise.
|
||||
|
||||
### Telemetry: semantics of `consul.rpc.query` changed, see `consul.rpc.queries_blocking`
|
||||
|
||||
|
@ -891,7 +891,7 @@ datacenters monitor this periodically (every few minutes) and will
|
|||
automatically upgrade service mesh to use a federated Certificate Authority when
|
||||
they do.
|
||||
|
||||
In general, migrating a Consul cluster from OSS to Enterprise will update the
|
||||
In general, migrating a Consul cluster from CE to Enterprise will update the
|
||||
CA to be federated automatically and without impact on service mesh traffic. When
|
||||
upgrading Consul Enterprise 1.3.x to Consul Enterprise 1.4.0 upgrades the CA
|
||||
upgrade is seamless, however depending on the size of the cluster, _new_
|
||||
|
|
Loading…
Reference in New Issue