A service catalog contains all available nodes and their services running in a cluster. The Consul agent registers the service definition details, availability, and health metrics using the catalog. 

Service configuration definitions are enabled by setting the -config-file option for the Consul agent as either an HCL or JSON extension. Definitions can be updated through the agent, and dynamic service registrations are made through REST API calls.

The following example configuration is a service definition that highlights high-level fields:

{
  "service": {
    "id": "redisuniquevalue",
    "name": "redis",
    "tags": ["primary"],
    "address": "",
    "meta": {
      "meta": "for my service"
    },
    "port": 8000,
    "enable_tag_override": false,
    "checks": [
      {
        "args": ["/usr/local/bin/check_redis.py"],
        "interval": "10s"
      }
     ],
     "kind": "connect-proxy",
...

The service definition configs must include a name and the following properties:

• id: If a name is not provided, the id is set as the name. It is a recommended best practice to define a unique ID for all the services within a node. This way, if any names conflict with other services, the unique ID is exclusive to that service.
• tags: These are values that are used to define node details, including primary or secondary, node versions, service labels, and many other attributes.
• address: This is the consul agent IP address that generates the service definition. This property is optional and doesn't need to be specified.
• meta: This is an ASCII semantic that can contain a maximum of 64 keys or value characters with no special characters. If security or performance is enabled, keys can be 128 chars, and values can be up to 512 chars.
• port: Along with the IP address, this can facilitate service discovery.
• enable_tag_override: This is an optional property that can be used to enable or disable other Consul agents outside the service to update the service catalog and definition tags. If the property is false, override is disabled.
• checks: This is the health check property that's used to identify any failed or left nodes. The use of this property is highly recommended and should be enabled with the health check scripts.
• kind: This property is optional, and its value will be a connect proxy. If the service instance is a non-proxy, then this field is removed altogether.
• connect: This property enables connected capabilities for the service.
• native: This is either true or false and states whether connection parameters are native.
• sidecar_service: This property is the sidecar proxy service definition and registration service. This property should not be defined if native is true.
• weights: This is an optional property that is specific to a service weight for DNS responses. If no values are defined, the default value for passing is 1, and the warning is 1 if a service definition is critical or if there are warning checks.

HashiCorp also allows us to integrate Consul with Kubernetes. We will discuss this in the next section.