Exported Services Configuration Entry

This topic describes the exported-services configuration entry type. The exported-services configuration entry enables Consul to export service instances to other clusters from a single file and connect services across clusters. For additional information, refer to Cluster Peering and Admin Partitions.

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.

You can configure the settings defined in the exported-services configuration entry to apply to all namespaces in a Consul Enterprise admin partition.

Requirements

  • Enterprise Only: A corresponding partition that the configuration entry can export from. For example, the exported-services configuration entry for a partition named frontend requires an existing frontend partition.

Usage

  1. Verify that your datacenter meets the conditions specified in the Requirements.
  2. Specify the exported-services configuration in the agent configuration file (see config_entries) as described in Configuration.
  3. Apply the configuration using one of the following methods:

Configuration

Configure the following parameters to define a exported-services configuration entry:

Exported services configuration syntax

Exported services configuration syntax

  1. Kind = "exported-services"
  2. Name = "default"
  3. Services = [
  4. {
  5. Name = "<name of service to export>"
  6. Consumers = [
  7. {
  8. Peer = "<name of the peered cluster that dials the exported service>"
  9. }
  10. ]
  11. }
  12. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. kind: ExportedServices
  3. metadata:
  4. name: default
  5. spec:
  6. services:
  7. - name: <name of service to export>
  8. consumers:
  9. - peer: <name of the peered cluster that dials the exported service>
  1. "Kind": "exported-services",
  2. "Name": "default",
  3. "Services": [
  4. {
  5. "Name": "<name of service to export>",
  6. "Consumers": [
  7. {
  8. "Peer": "<name of the peered cluster that dials the exported service>"
  9. }
  10. ]
  11. }
  12. ]

Exported services configuration syntax

Exported services configuration syntax

  1. Kind = "exported-services"
  2. Partition = "<partition containing services to export>"
  3. Name = "<partition containing services to export>"
  4. Services = [
  5. {
  6. Name = "<name of service to export>"
  7. Namespace = "<namespace in the partition containing the service to export>"
  8. Consumers = [
  9. {
  10. Peer = "<name of the peered cluster that dials the exported service>"
  11. }
  12. ]
  13. }
  14. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. kind: ExportedServices
  3. metadata:
  4. name: <partition containing services to export>
  5. spec:
  6. services:
  7. - name: <name of service to export>
  8. namespace: <namespace in the partition containing the service to export>
  9. consumers:
  10. - peer: <name of the peered cluster that dials the exported service>
  1. "Kind": "exported-services",
  2. "Partition": "<partition containing services to export>",
  3. "Name": "<partition containing services to export>",
  4. "Services": [
  5. {
  6. "Name": "<name of service to export>",
  7. "Namespace": "<namespace in the partition containing the service to export>"
  8. "Consumers": [
  9. {
  10. "Peer": "<name of the peered cluster that dials the exported service>"
  11. }
  12. ]
  13. }
  14. ]

Exported services configuration syntax

Exported services configuration syntax

  1. Kind = "exported-services"
  2. Partition = "<partition containing services to export>"
  3. Name = "<partition containing services to export>"
  4. Services = [
  5. {
  6. Name = "<name of service to export>"
  7. Namespace = "<namespace in the partition containing the service to export>"
  8. Consumers = [
  9. {
  10. Partition = "<name of the partition that dials the exported service>"
  11. }
  12. ]
  13. }
  14. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. kind: ExportedServices
  3. metadata:
  4. name: <partition containing services to export>
  5. spec:
  6. services:
  7. - name: <name of service to export>
  8. namespace: <namespace in the partition containing the service to export>
  9. consumers:
  10. - partition: <name of the partition that dials the exported service>
  1. "Kind": "exported-services",
  2. "Partition": "<partition containing services to export>",
  3. "Name": "<partition containing services to export>",
  4. "Services": [
  5. {
  6. "Name": "<name of service to export>",
  7. "Namespace": "<namespace in the partition containing the service to export>"
  8. "Consumers": [
  9. {
  10. "Partition": "<name of partition that dials the exported service>"
  11. }
  12. ]
  13. }
  14. ]

Exported services configuration syntax

Exported services configuration syntax

  1. Kind = "exported-services"
  2. Partition = "<partition containing services to export>"
  3. Name = "<partition containing services to export>"
  4. Services = [
  5. {
  6. Name = "<name of service to export>"
  7. Namespace = "<namespace in the partition containing the service to export>"
  8. Consumers = [
  9. {
  10. SamenessGroup = "<name of the sameness group that dials the exported service>"
  11. }
  12. ]
  13. }
  14. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. kind: ExportedServices
  3. metadata:
  4. name: <partition containing services to export>
  5. spec:
  6. services:
  7. - name: <name of service to export>
  8. namespace: <namespace in the partition containing the service to export>
  9. consumers:
  10. - samenessGroup: <name of the sameness group that dials the exported service>
  1. "Kind": "exported-services",
  2. "Partition": "<partition containing services to export>",
  3. "Name": "<partition containing services to export>",
  4. "Services": [
  5. {
  6. "Name": "<name of service to export>",
  7. "Namespace": "<namespace in the partition containing the service to export>"
  8. "Consumers": [
  9. {
  10. "SamenessGroup": "<name of the sameness group that dials the exported service>"
  11. }
  12. ]
  13. }
  14. ]

Configuration Parameters

The following table describes the parameters associated with the exported-services configuration entry.

ParameterDescriptionRequiredDefault
KindString value that enables the configuration entry. The value should always be exported-services (HCL and JSON) or ExportedServices (YAML)RequiredNone
PartitionEnterprise String value that specifies the name of the partition that contains the services you want to export.RequiredNone
NameString value that specifies the name of the partition that contains the services you want to export. Must be default in Consul OSS.RequiredNone
ServicesList of objects that specify which services to export. For details, refer to Services.RequiredNone
MetaObject that defines a map of the max 64 key/value pairs.OptionalNone

Services

The Services parameter contains a list of one or more parameters that specify which services to export, which namespaces the services reside, and the destination cluster for the exported services. Each item in the Services list must contain the following parameters:

  • Name: Specifies the name of the service to export. You can use an asterisk wildcard (*) to include all services in the namespace.
  • Namespace: EnterpriseExported services - 图2Enterprise Specifies the namespace containing the services to export. You can use an asterisk wildcard (*) to include all namespaces in the partition.
  • Consumers: Specifies one or more objects that identify a destination cluster for the exported services.

Consumers

The Consumers parameter contains a list of one or more parameters that specify the destination cluster for an exported service. Each item in the Consumers list must contain exactly one of the following parameters:

  • Peer: Specifies the name of the peered cluster to export the service to. A asterisk wildcard (*) cannot be specified as the Peer. Added in Consul 1.13.0.
  • Partition: EnterpriseExported services - 图3Enterprise Specifies an admin partition in the datacenter to export the service to. A asterisk wildcard (*) cannot be specified as the Partition.
  • SamenessGroup: EnterpriseExported services - 图4Enterprise Specifies as sameness group to export the service to. A asterisk wildcard (*) cannot be specified as the SamennessGroup.

Examples

Exporting services to peered clusters

The following example configures Consul to export the payments and refunds services to the peered web-shop cluster.

  1. Kind = "exported-services"
  2. Name = "default"
  3. Services = [
  4. {
  5. Name = "payments"
  6. Consumers = [
  7. {
  8. Peer = "web-shop"
  9. },
  10. ]
  11. },
  12. {
  13. Name = "refunds"
  14. Consumers = [
  15. {
  16. Peer = "web-shop"
  17. }
  18. ]
  19. }
  20. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. Kind: ExportedServices
  3. metadata:
  4. name: default
  5. spec:
  6. services:
  7. - name: payments
  8. consumers:
  9. - peer: web-shop
  10. - name: refunds
  11. consumers:
  12. - peer: web-shop
  1. "Kind": "exported-services",
  2. "Name": "default",
  3. "Services": [
  4. {
  5. "Name": "payments",
  6. "Consumers": [
  7. {
  8. "Peer": "web-shop"
  9. },
  10. ],
  11. },
  12. {
  13. "Name": "refunds",
  14. "Consumers": [
  15. {
  16. "Peer": "web-shop"
  17. }
  18. ]
  19. }
  20. ]

The following example configures Consul to export the payments and refunds services from the billing namespace of the finance admin partition to the web-shop peer.

  1. Kind = "exported-services"
  2. Partition = "finance"
  3. Name = "finance"
  4. Services = [
  5. {
  6. Name = "payments"
  7. Namespace = "billing"
  8. Consumers = [
  9. {
  10. Peer = "web-shop"
  11. },
  12. ]
  13. },
  14. {
  15. Name = "refunds"
  16. Namespace = "billing"
  17. Consumers = [
  18. {
  19. Peer = "web-shop"
  20. }
  21. ]
  22. }
  23. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. Kind: ExportedServices
  3. metadata:
  4. name: finance
  5. spec:
  6. services:
  7. - name: payments
  8. namespace: billing
  9. consumers:
  10. - peer: web-shop
  11. - name: refunds
  12. namespace: billing
  13. consumers:
  14. - peer: web-shop
  1. "Kind": "exported-services",
  2. "Partition": "finance",
  3. "Name": "finance",
  4. "Services": [
  5. {
  6. "Name": "payments",
  7. "Namespace": "billing"
  8. "Consumers": [
  9. {
  10. "Peer": "web-shop"
  11. },
  12. ],
  13. },
  14. {
  15. "Name": "refunds",
  16. "Namespace": "billing",
  17. "Consumers": [
  18. {
  19. "Peer": "web-shop"
  20. }
  21. ]
  22. }
  23. ]

The following example configures Consul to export the payments and refunds services from the billing namespace of the finance admin partition to the web-shop partition.

  1. Kind = "exported-services"
  2. Partition = "finance"
  3. Name = "finance"
  4. Services = [
  5. {
  6. Name = "payments"
  7. Namespace = "billing"
  8. Consumers = [
  9. {
  10. Partition = "web-shop"
  11. },
  12. ]
  13. },
  14. {
  15. Name = "refunds"
  16. Namespace = "billing"
  17. Consumers = [
  18. {
  19. Partition = "web-shop"
  20. }
  21. ]
  22. }
  23. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. Kind: ExportedServices
  3. metadata:
  4. name: finance
  5. spec:
  6. services:
  7. - name: payments
  8. namespace: billing
  9. consumers:
  10. - partition: web-shop
  11. - name: refunds
  12. namespace: billing
  13. consumers:
  14. - partition: web-shop
  1. "Kind": "exported-services",
  2. "Partition": "finance",
  3. "Name": "finance",
  4. "Services": [
  5. {
  6. "Name": "payments",
  7. "Namespace": "billing"
  8. "Consumers": [
  9. {
  10. "Partition": "web-shop"
  11. },
  12. ],
  13. },
  14. {
  15. "Name": "refunds",
  16. "Namespace": "billing",
  17. "Consumers": [
  18. {
  19. "Partition": "web-shop"
  20. }
  21. ]
  22. }
  23. ]

Exporting a service to a sameness group

The following example configures Consul to export a service named api to a defined group of partitions that belong to a separately defined sameness group named monitoring.

  1. Kind = "exported-services"
  2. Name = "default"
  3. Services = [
  4. {
  5. Name = "api"
  6. Consumers = [
  7. {
  8. SamenessGroup = "monitoring"
  9. }
  10. ]
  11. }
  12. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. Kind: ExportedServices
  3. metadata:
  4. name: default
  5. spec:
  6. services:
  7. - name: api
  8. consumers:
  9. - samenessGroup: monitoring
  1. "Kind": "exported-services",
  2. "Name": "default",
  3. "Services": [
  4. {
  5. "Name": "api",
  6. "Consumers": [
  7. {
  8. "SamenessGroup": "monitoring"
  9. }
  10. ]
  11. }
  12. ]

Exporting all services

The following example configures Consul to export all services in the datacenter to the peered monitoring and platform clusters.

  1. Kind = "exported-services"
  2. Name = "default"
  3. Services = [
  4. {
  5. Name = "*"
  6. Consumers = [
  7. {
  8. Peer = "monitoring"
  9. },
  10. {
  11. Peer = "platform"
  12. }
  13. ]
  14. }
  15. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. Kind: ExportedServices
  3. metadata:
  4. name: default
  5. spec:
  6. services:
  7. - name: *
  8. consumers:
  9. - peer: monitoring
  10. - peer: platform
  1. "Kind": "exported-services",
  2. "Name": "default",
  3. "Services": [
  4. {
  5. "Name": "*",
  6. "Namespace": "*"
  7. "Consumers": [
  8. {
  9. "Peer": "monitoring"
  10. },
  11. {
  12. "Peer": "platform"
  13. }
  14. ]
  15. }
  16. ]

The following example configures Consul to export all services in all namespaces of the finance partition to the peered monitoring and platform clusters.

  1. Kind = "exported-services"
  2. Partition = "finance"
  3. Name = "finance"
  4. Services = [
  5. {
  6. Name = "*"
  7. Namespace = "*"
  8. Consumers = [
  9. {
  10. Peer = "monitoring"
  11. },
  12. {
  13. Peer = "platform"
  14. }
  15. ]
  16. }
  17. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. Kind: ExportedServices
  3. metadata:
  4. name: finance
  5. spec:
  6. services:
  7. - name: *
  8. namespace: *
  9. consumers:
  10. - peer: monitoring
  11. - peer: platform
  1. "Kind": "exported-services",
  2. "Partition": "finance",
  3. "Name": "finance",
  4. "Services": [
  5. {
  6. "Name": "*",
  7. "Namespace": "*"
  8. "Consumers": [
  9. {
  10. "Peer": "monitoring"
  11. },
  12. {
  13. "Peer": "platform"
  14. }
  15. ]
  16. }
  17. ]

The following example configures Consul to export all services in all namespaces of the finance partition to the monitoring and platform partitions.

  1. Kind = "exported-services"
  2. Partition = "finance"
  3. Name = "finance"
  4. Services = [
  5. {
  6. Name = "*"
  7. Namespace = "*"
  8. Consumers = [
  9. {
  10. Partition = "monitoring"
  11. },
  12. {
  13. Partition = "platform"
  14. }
  15. ]
  16. }
  17. ]
  1. apiVersion: consul.hashicorp.com/v1alpha1
  2. Kind: ExportedServices
  3. metadata:
  4. name: finance
  5. spec:
  6. services:
  7. - name: *
  8. namespace: *
  9. consumers:
  10. - partition: monitoring
  11. - partition: platform
  1. "Kind": "exported-services",
  2. "Partition": "finance",
  3. "Name": "finance",
  4. "Services": [
  5. {
  6. "Name": "*",
  7. "Namespace": "*"
  8. "Consumers": [
  9. {
  10. "Partition": "monitoring"
  11. },
  12. {
  13. "Partition": "platform"
  14. }
  15. ]
  16. }
  17. ]

Reading Services

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.

The following example queries the finance peer for the imported payments service:

  1. $ curl 'localhost:8500/v1/health/service/payments?peer=finance'

An ACL token with either of the following permissions is required in the cluster where the query is made:

If the call in the previous example is made from a service named web, then the request requires either:

  • A token with service:write permissions to web.
  • A token with service:read and node:read to all names in the datacenter.

Example ACL rules for reading imported services in Consul OSS

Example ACL rules for reading imported services in Consul OSS

  1. service "web" {
  2. policy = "write"
  3. }
  4. # OR
  5. service_prefix "" {
  6. policy = "read"
  7. }
  8. node_prefix "" {
  9. policy = "read"
  10. }
  1. {
  2. "service": {
  3. "web": {
  4. "policy": "write"
  5. }
  6. }
  7. }
  8. ## OR
  9. {
  10. "service_prefix": {
  11. "": {
  12. "policy": "read"
  13. }
  14. },
  15. "node_prefix": {
  16. "": {
  17. "policy": "read"
  18. }
  19. }
  20. }

The following example queries the finance partition for the imported payments service:

  1. $ curl 'localhost:8500/v1/health/service/payments?partition=finance'

An ACL token with either of the following permissions is required in the cluster where the query is made:

  • service:write permissions for any service in the partition where the query is made.
  • service:read and node:read for all services and nodes, respectively, in any namespace and the exact partition where the query is made.

If the call in the previous example is made from a service named web in a partition named frontend, then the request requires either:

  • A token with service:write permissions to web in the frontend partition.
  • A token with service:read and node:read to all names in the frontend partition, for any namespace.

Example ACL rules for reading imported services from a partition in Consul Enterprise

Example ACL rules for reading imported services from a partition in Consul Enterprise

  1. partition "frontend" {
  2. namespace "dev" { # This could be any namespace
  3. service "web" {
  4. policy = "write"
  5. }
  6. }
  7. }
  8. # OR
  9. partition "frontend" {
  10. namespace "dev" { # This could be any namespace
  11. service_prefix "" {
  12. policy = "read"
  13. }
  14. node_prefix "" {
  15. policy = "read"
  16. }
  17. }
  18. }
  1. {
  2. "partition": {
  3. "frontend": {
  4. "namespace": {
  5. ## The following could be any namespace
  6. "dev": {
  7. "service": {
  8. "web": {
  9. "policy": "write"
  10. }
  11. }
  12. }
  13. }
  14. }
  15. }
  16. }
  17. ## OR
  18. {
  19. "partition": {
  20. "frontend": {
  21. "namespace": {
  22. ## The following could be any namespace
  23. "dev": {
  24. "service_prefix": {
  25. "": {
  26. "policy": "read"
  27. }
  28. },
  29. "node_prefix": {
  30. "": {
  31. "policy": "read"
  32. }
  33. }
  34. }
  35. }
  36. }
  37. }
  38. }

The following example queries the finance peer for the imported payments service:

  1. $ curl 'localhost:8500/v1/health/service/payments?peer=finance'

An ACL token with either of the following permissions is required in the cluster where the query is made:

  • service:write permissions for any service in the partition where the query is made.
  • service:read and node:read for all services and nodes, respectively, in any namespace and the exact partition where the query is made.

If the call in the previous example is made from a service named web in a partition named frontend, then the request requires either:

  • A token with service:write permissions to web in the frontend partition.
  • A token with service:read and node:read to all names in the frontend partition, for any namespace.

Example ACL rules for reading imported services from a peer in Consul Enterprise

Example ACL rules for reading imported services from a peer in Consul Enterprise

  1. partition "frontend" {
  2. namespace "dev" { # This could be any namespace
  3. service "web" {
  4. policy = "write"
  5. }
  6. }
  7. }
  8. # OR
  9. partition "frontend" {
  10. namespace "dev" { # This could be any namespace
  11. service_prefix "" {
  12. policy = "read"
  13. }
  14. node_prefix "" {
  15. policy = "read"
  16. }
  17. }
  18. }
  1. {
  2. "partition": {
  3. "frontend": {
  4. "namespace": {
  5. ## The following could be any namespace
  6. "dev": {
  7. "service": {
  8. "web": {
  9. "policy": "write"
  10. }
  11. }
  12. }
  13. }
  14. }
  15. }
  16. }
  17. ## OR
  18. {
  19. "partition": {
  20. "frontend": {
  21. "namespace": {
  22. ## The following could be any namespace
  23. "dev": {
  24. "service_prefix": {
  25. "": {
  26. "policy": "read"
  27. }
  28. },
  29. "node_prefix": {
  30. "": {
  31. "policy": "read"
  32. }
  33. }
  34. }
  35. }
  36. }
  37. }
  38. }

For additional information, refer to Health HTTP Endpoint.