Location>code7788 >text

Consul Learning Summary

Popularity：327 ℃/2024-12-15 00:38:47

What is Consul?

Consul is a service networking solution that enables teams to manage secure network connectivity between services and across local and multi-cloud environments and runtimes.Consul provides service discovery, service mesh, traffic management, and automatic updates to network infrastructure devices. These capabilities can be used individually or together in a single Consul deployment.

Architecture Introduction

Consul provides a control plane that allows for the registration, querying, and protection of services deployed on the network. The control plane is part of the network infrastructure that maintains a central registry to track services and their respective IP addresses. It is a distributed system running on a cluster of nodes (such as physical servers, cloud instances, virtual machines, or containers).

Consul interacts with the data plane through proxies. The data plane is part of the network infrastructure that handles data requests

The core workflow of Consul consists of the following phases:

  • enrollment: The team added services to the Consul directory -- a central registry that allows services to discover each other automatically without requiring manual action to modify application code, deploy additional load balancers, or hard-code IP addresses. It is the runtime source of truth for all services and their addresses. Teams can use the CLI or API to manuallydefinerespond in singingenrollmentservice, which can also be accessed through theService synchronizationProcess automation in Kubernetes. Services also include health checks so that Consul can monitor unhealthy services.
  • consult (a document etc): Consul's identity-based DNS supports finding healthy services in the Consul catalog. Services registered with Consul provide health information, access points, and other data that helps control the flow of data in the network. Services can only access other services through their local proxies based on customized identity-based policies.
  • surety: After services are located upstream, Consul ensures that communication between services and services is authenticated, authorized, and encrypted. the Consul Service Grid protects the microservices architecture using mTLS and can allow or restrict access based on the service identity regardless of differences in computing environments and runtimes.

basic term

data center

The Consul control plane contains one or more data centers. A data center is the smallest unit of the Consul infrastructure that can perform basic Consul operations. Data centers contain at least one Consul server agent, and actual deployments contain three to five server agents and several Consul client agents. Multiple data centers can be created and nodes from different data centers are allowed to interact with each other. See alsoBootstrap a data centerGet information on how to create a data center.

clustering

A collection of Consul agents that are mutually aware of each other is called a cluster. The termdata centerrespond in singingclusteringare often used interchangeably. However, in some cases clustering refers only to Consul server agents, and in some cases clustering may refer to a collection of client agents.

act on behalf of sb. in a responsible position

Consul can be started by running the Consul binary.act on behalf of sb. in a responsible position, they are daemons that implement Consul's control plane functionality. Agents can be started as servers or clients. All nodes should allow agents. See also.Consul AgentGet more information.

server agent

Personally, I understand that the server agent, i.e. the node running the Consul agent in server mode, corresponds to the figure aboveConsul Server. the Consul server agent stores all status information including service and node IP addresses, health checks, and configurations. It is recommended that three to five servers be deployed in a cluster. The more servers deployed, the greater the resilience and availability in the event of a failure. However, more servers slow down theconsensusThis is a key server function that enables Consul to process information efficiently and effectively.

Consensus Protocol

Consul clusters work together through a system calledconsensusThe process of selecting a server as theleader。leaderHandles all queries and transactions and prevents conflicting updates in clusters containing multiple servers.

Not currently acting as a clusterleaderThe Consul Server is calledfollowers。followersForward client agent requests to the clusterleader 。leader Replicate requests to all other servers in the cluster. Request replication ensures that when theleaderWhen unavailable, other servers in the cluster can elect a new server without losing any dataleader。

The Consul server uses the Raft algorithm on port8300build onconsensus。

Client Agent

Personally, I understand that client agents, i.e., nodes that run Consul agents in client mode, correspond to the above figure inConsul Client. the Consul client reports node and service health status to the Consul cluster. In a typical deployment, a client agent must be running on each compute node in the data center. The client interacts with the server using remote procedure calls (RPCs). By default, the clients communicate with the server through the port8300on the server sends an RPC request.

There is no limit to the number of client agents or services that can be used with Consul, but production deployments should distribute services across multiple Consul data centers. The use of multiple data center deployments can increase infrastructure resiliency and limit control plane issues. It is recommended that up to 5,000 client agents be deployed per data center. Some large organizations have deployed tens of thousands of client agents and hundreds of thousands of service instances in multi-data center deployments. See alsoCross-Data Center Requestsfor more information.

It is also possible to run Consul using an alternate service grid configuration that deploys the Envoy agent but not the client agent. see theSimplified Service Grid using Consul Data PlaneLearn more.

LAN gossip pool

Client and server agents join the LAN gossip pool so they can distribute and execute nodeshealth checkup. Agents in the pool disseminate health check information throughout the cluster. Agents use theUDPThrough the port8301on it for gossip communication. If theUDPNot available, then TCP is used. see theGossip protocolGet more information.

The following simplified diagram shows the interaction between the server and the client.

LAN gossip pool

RRC

Cross-Data Center Requests

Each Consul data center maintains its own service catalog and its operational status. By default, information is not replicated between data centers. WAN federation and cluster peering are two multi-data center deployment models that enable service connectivity across data centers.

WAN federation

WAN federation is a method of connecting multiple Consul data centers. It requires specifying aprimary data center(primary datacenter), which contains authoritative information about all datacenters, including service grid configurations and access control lists (ACL) Resources.

In this model, when a client agent requests a resource in a remote secondary data center, the local Consul server forwards the RPC request to a remote Consul server that has access to the resource. The remote server sends the result to the local server. If the remote data center is unavailable, its resources are also unavailable. By default, the WAN-federated servers are accessed through the TCP port8300Send cross-data center requests.

Control-plane and data-plane traffic can be configured to pass through the mesh gateway, simplifying network requirements.

To enable services to communicate across data centers when the ACL system is enabled, see theACL replication for multiple data centersTutorial.

WAN gossip pool

Servers can also join the WAN gossip pool, which is optimized for the greater latency associated with the Internet. The pool enables servers to exchange information, such as addresses and health status, and gracefully handle connection loss in the event of a failure.

In the following figure, the servers in each data center are connected to each other by passing the port in theTCP/UDP 8302The port sends data to join the WAN gossip pool. see theGossip protocolGet more information.

WAN gossip pool

PRC

Cluster peering

Peer-to-peer connections can be created between two or more independent clusters so that services deployed to different data centers or management partitions can communicate.administrative partitionis a feature in Consul Enterprise that enables the definition of isolated network zones that use the same Consul servers. In a clustered peer-to-peer model, a token can be created in one of the data centers or partitions and another data core or partition can be configured to display the token to establish a connection.

read (instructions)What is cluster peering?Get more information.

reference link

/consul/docs/intro

/consul/docs/architecture

Service Discovery (Service discovery)

What is service discovery?

Service discovery helps to discover, track and monitor the operation of services in the network. Service discovery is performed inService Catalog(service catalog) in which all services are registered and records are maintained. This service catalog acts as a single source of facts, allowing services to query and communicate with each other.

give an example

Question: When a service exists on multiple host nodes, how does the client get the corresponding ip and port.

As follows, in the traditional case, the static configuration method is used to store service configuration information, and then the corresponding service is accessed based on this configuration information.

As shown above, assuming a client request for a certain interface, you need to call services 1-N. The client must know the network location (ip + port) of all the services, and the previous practice will store the server information in the configuration file, or in the database. This brings up a couple of questions:

  • Need to configure the network location of N services, increasing the complexity of configuration
  • Any change in the network location of the service requires a change in each caller's configuration
  • Difficult to do loads with clustering (except for reverse proxy approach)

To summarize in a nutshell: more services and a pain to configure.

To solve this troublesome problem, service discovery was introduced, and see below.

It is different from the previous processing. A service discovery module is added to the figure. Services 1-N register their current own network locations to the service discovery module, while the service discovery module records these registrations in the form of K-V. (K generally designed as a service name.V Generally designed toip:port. In addition, the service discovery module polls regularly to see if these services can be accessed (this is a health check).

When the client invokes services 1-N, it directly requests the service discovery module to query the network location of the corresponding services, and then invokes the corresponding services. It is not difficult to find that the client does not need to record the network location information of these services at this time, realizing the complete decoupling of the client and the server.

Benefits of Service Discovery

Service discovery brings benefits to all organizations, from simplified scalability to increased application resilience. Some of the benefits of service discovery include:

  • Dynamic IP address and port discovery
  • -Simplifies horizontal service scaling
  • Abstract discovery logic from the application
  • Ensure reliable service communication through health checks
  • Load balancing requests across health service instances
  • Faster time to deployment through high-speed discovery
  • Automatic service enrollment and deregistration

Service discovery is any work?

Service discovery uses the identity of the service instead of traditional access information (IP address and port). This allows services to be dynamically mapped and any changes in the service catalog to be tracked. The service consumer (user or other service) then uses DNS to dynamically retrieve access information for other services from the service catalog. The life cycle of a service might be as follows:

The service consumer communicates with the "Web" service through a unique Consul DNS entry provided by the service catalog.

A new instance of the "Web" service registers itself with the service catalog using its IP address and port. When new instances of the service register with the service catalog, they join the load balancing pool to handle requests from service consumers.

The service catalog is dynamically updated as new instances of services are added and old or unhealthy instances of services are removed. Deleted services will no longer be added to the load balancing pool that handles service consumer requests.

What is service discovery in microservices?

In microservices applications, the set of active service instances changes frequently in large dynamic environments. These service instances rely on service catalogs to retrieve the latest access information from the corresponding services. Reliable service catalogs are particularly important for service discovery in microservices to ensure healthy, scalable, and highly responsive application operations.

Two main models for service discovery

There are two main service discovery models:client (computing)Discovery (client-side discovery) andserver-sideDiscovery (server-side discovery)。

In systems that use client discovery, the service consumer is responsible for determining access information for available service instances and load balancing requests between them.

  1. Service Consumer Search Service Catalog
  2. Service catalog retrieval and return of all access information
  3. Service consumers choose healthy downstream services and direct requests to them

In systems that use server-side discovery, a service consumer uses an intermediary to query a service catalog and issue requests to it.

the service consumer uses an intermediary to query the service catalog and make requests to them.

  1. Service Consumer Query Intermediate Service (Consul)
  2. The intermediate service queries the service catalog and routes the request to an available service instance.

For modern applications, this discovery approach is beneficial because developers can make their applications faster and lighter by decoupling and centralizing service discovery logic

Service Discovery vs Load Balancing

Service discovery and load balancing are similar in terms of distributing requests to back-end services, but differ in many important ways.

Traditional load balancers are not designed for fast registration and deregistration of services, nor are they designed for high availability. In contrast, service discovery systems use multiple nodes to maintain service registry state and use a peer-to-peer state management system to improve the resiliency of any type of infrastructure.

For modern cloud-based applications, service discovery is the preferred method of directing traffic to the right service provider because it scales and remains elastic and independent of infrastructure.

Reference Links

/consul/docs/concepts/service-discovery

Enabling Agents

consul agent <options>

Common Options:

  • -datacenter=<value> Agent-Owned Data Centers

  • -auto-reload-config Monitor configuration file changes and automatically reload the file when it is modified

  • -bind=<value> Sets the bind address for cluster communication. It is the IP address that should be accessible to all other nodes in the cluster. The default value is0.0.0.0, meaning that Consul will bind to all addresses on the local computer and advertise the first available private IPv4 address to the rest of the cluster. This parameter is critical to ensure the stability and reliability of communication within the cluster.

  • -advertise: Notification of presentation address, used to change the address we present to other nodes in the cluster, normally the -bind address is the presentation address, but in some cases there may be a routable address that is not bindable, which activates a different address for provisioning. If this address is not routable, other nodes will treat the node as faulty. This is where the advertise parameter comes in handy, which allows a different address to be configured to advertise to the cluster to ensure that the node is properly discovered by other members of the cluster.

  • -bootstrap: Set the server to boot mode. Only one server in a data center can be inbootstrapmode, when a server is inbootstrapmode, you can elect yourself to theleader。

  • -bootstrap-expect=<value> Set servers to the desired bootstrap mode - the desired number of servers, when supplied, consul waits until the specified number of sever to bootstrap the entire cluster, this option cannot be used with the-bootstrapsimultaneous use

  • -check_output_max_size=<value> Set the maximum output size to be checked on this agent

  • -client=<value> Sets the binding address to be used for client access. This includes RPC, DNS, HTTP, HTTPS, and gRPC (if configured), with a default value of127.0.0.1

  • -config-dir=<value> The path to the directory where the configuration files will be read. This will read, in alphabetical order, every file ending in '.json' in that directory as configuration, which can be specified multiple times.

  • -config-file=<value> Configuration file path, which can be specified multiple times.

  • -config-format=<string> Configuration file format, independent of extension, must be 'hcl' or 'json'.

  • -data-dir=<value> The path to the data directory where the agent state is stored.

  • -default-query-time=<value> The amount of time a blocking query waits before Consul forces a response back. This value can be changed by thewaitQuery parameter override.
    Parameters.

  • -dev Start the agent in development mode.

  • -disable-host-node-id Set this totruewill prevent Consul from generating node IDs using host information and will cause Consul to generate random node IDs.

  • -dns-port=<value> The DNS port to use.

  • -domain=<value> Domain used for the DNS interface.

  • -enable-local-script-checks Enable the health check script in the configuration file.

  • -enable-script-checks Enable health check scripts.

  • -encrypt=<value> Provides gossip (gossip) encryption keys.

  • -grpc-port=<value> Setting the gRPC API port to listen on

  • -grpc-tls-port=<value> Set the gRPC-TLS API port to listen on.

  • -http-port=<value> Set the HTTP API port to listen on, default 8500, also used for Web UI.

  • -https-port=<value> Set the HTTPS API port to listen on.

  • -log-file=<value> Path to the log file

  • -log-json Outputs logs in JSON format.

  • -log-level=<value> Agent log level.

  • -log-rotate-bytes=<value> Maximum number of bytes that should be written to the log file

  • -log-rotate-duration=<value> Set how long before log rotation needs to be performed

  • -log-rotate-max-files=<value> Maximum number of log files to keep

  • -max-query-time=<value> The maximum amount of time a blocking query can wait before Consul forces a response back.Consul applies jitter to the wait time. This jitter (jitter) time will be limited toMaxQueryTime。

  • -node=<value> The name of this node. It must be unique in the cluster.

  • -node-id=<value> A spatially and temporally unique ID for this node. defaults to a randomly generated and stored ID in the data catalog.

  • -node-meta=<key:value> Any metadata key/value pairs for this node in the formatkey:value. It can be specified more than once.

  • -pid-file=<value> Path to the file where the agent process ID is stored.

  • -primary-gateway=<value> The address in the primary data center where the Grid Gateway is to be used. Used to bootstrap the WAN federation at startup when retry is enabled. Can be specified multiple times.

  • -protocol=<value> Sets the protocol version. The default islatest。

  • -raft-protocol=<value> Sets the Raft protocol version. The default islatest。

  • -read-replica (Enterprise Edition only) This flag is used to keep the server from participating in Raft arbitration, allowing it to receive only the data replication stream. This can be used to increase read scalability when a large number of reads to the server are required.

  • -recursor=<value> The address of the upstream DNS server. This can be specified multiple times.

  • -rejoin Ignore the previous departure and try to rejoin the cluster.

  • -retry-interval=<value> Wait time between join retries

  • -retry-join=<value> When retry is enabled, the proxy address to be added at startup can contain the port number (default)8301), shaped like192.168.1.105:8301. It can be specified multiple times. As follows, if this parameter is configured in the configuration file, written as a list, multiple configurations are supported.

    {
  "retry_join": ["192.168.1.105:8301", "192.168.1.106"]
}

    Regardless of which way it is configured, when the Consul agent starts, it will keep trying to connect to these addresses until it joins the cluster successfully or until it reaches the configured maximum number of retries.

  • -retry-max=<value> Maximum number of retries for retry join. Defaults to 0 for unlimited retries.

  • -serf-lan-allowed-cidrs value Serf LAN-allowed networks (such as the192.168.1.0/24). Multiple assignments are possible

  • -serf-lan-bind value The Serf LAN to listen to address that needs to be bound. The default is to use the-bindaddress

  • -serf-lan-port value The port on which the Serf LAN is to listen.

  • -serf-wan-allowed-cidrs value Serf WAN-permitted networks (such as the192.168.1.0/24). Multiple assignments are possible

  • -serf-wan-bind value The Serf WAN to listen to address that needs to be bound. The default is to use the-bindaddress

  • -serf-wan-port value The port on which the Serf WAN will listen.

  • -server Start the agent in server mode.-server=false Indicates that the agent is started in client mode

  • -server-port=<value> Setting up the server ports to listen on

  • -syslog Enable logging to system log (syslog)

  • -ui Enable the built-in static web UI server.

  • -ui-content-path=<value> Sets the external UI path to a string. Default:/ui/

  • -ui-dir=<value> The path to the directory containing the web UI resources.

Some of the parameters can also be stored in the configuration file, via the-config-fileThe parameter configuration is read from the configuration file, refer to the link for configuration details:/consul/docs/agent#common-configuration-settings

More options can be viewed with the following command

# ./consul agent --help

Server node 1 (192.168.88.133）：

# mkdir -p /data/consul
# consul agent -server -bootstrap -datacenter=testDC -ui=true -data-dir=/data/consul -node=server1 -bind=192.168.88.133 -client=0.0.0.0 -serf-lan-port=8303 -serf-wan-port=8305 -dns-port=8601 -http-port=8603 -syslog -log-level=INFO

Server node 1 (192.168.88.134）：

# mkdir -p /data/consul
# consul agent -server=true -datacenter=testDC -data-dir=/data/consul --node=server2 -bind=192.168.88.134 -client=0.0.0.0 -retry-join=192.168.88.133 -serf-lan-port=8303 -serf-wan-port=8305 -dns-port=8601 -http-port=8603 -syslog -log-level=INFO

Description: Join the cluster after startup192.168.88.134:8301

Browser access validation

Note: It is my personal understanding that the Web UI accesses the access address (the illustrated192.168.88.133) is the startup parameter-retry-joinConfigured available address (through which the cluster can be successfully joined), port8603is the startup parameter-http-portconfigured port.

Reference Links:

/consul/install

/consul/docs/agent

Viewing Cluster Status

# consul operator raft list-peers
Error getting peers: Failed to retrieve raft configuration: Get "http://127.0.0.1:8500/v1/operator/raft/configuration": dial tcp 127.0.0.1:8500: connect: connection refused
# consul operator raft list-peers -http-addr=192.168.88.133:8603
Node     ID                                    Address              State     Voter  RaftProtocol  Commit Index  Trails Leader By
server1  114b7fb3-0027-e179-19ff-3554d4f754f9  192.168.88.133:8300  follower  true   3             607           0 commits
server2  9e2a3388-bd5c-1a36-6a6c-479a8cd46012  192.168.88.134:8300  leader    true   3             607           -

View Member Status

# consul members
Error retrieving members: Get "http://127.0.0.1:8500/v1/agent/members?segment=_all": dial tcp 127.0.0.1:8500: connect: connection refused
# consul members -http-addr=192.168.88.133:8603
Node     Address              Status  Type    Build   Protocol  DC      Partition  Segment
server1  192.168.88.133:8303  alive   server  1.19.2  2         testdc  default    <all>
server2  192.168.88.134:8303  alive   server  1.19.2  2         testdc  default    <all>

Registration Services

methodologies Request Path content format
PUT /agent/service/register application/json

Query parameters

  • replace-existing-checks - If a health check is missing from a request, the health check for the corresponding service will be removed from the proxy (Official text:Missing health checks from the request will be deleted from the agent). Use this parameter to idempotently register the service and its checks without having to manually deregister the checks.
  • ns (string: "") - Specifies the namespace to which the registered service belongs. It is also possible toSpecifying namespaces through other methods. This parameter is only supported in the Enterprise Edition.

JSON Request Body Service

For JSON key naming, the/agent/service/registerEndpoints support both camel and underscore naming methods. Underline naming is a convention where keys containing two or more words have underscores between them. Underline naming ensures compatibility with the agent configuration file format

  • Name (string: <required>) - Specifies the logical name of the service. Many service instances may share the same logical service name. It is recommended that a valid DNS tag be used for the service definition name.
  • ID (string: "") - Specifies a unique ID for the service.The ID for each service agent must remain unique. If not provided, the default isName Parameter values.
  • Tags (array<string>: nil) - Specifies the list of tags assigned to the service.TagsFacilitates filtering services based on tag when querying services and exposing them in the Consul API.
  • Address (string: "") - Specifies the address of the service. If not provided, the proxy's address will be used as the address of the service during DNS lookups.
  • TaggedAddresses (map<string|object>: nil) - Specify a mapping of explicit LAN and WAN addresses for the service instance. Both addresses and ports can be specified in the mapping values.
  • Meta (map<string|string>: nil) - Specify any KV metadata linked to the service instance
  • Namespace (string: "") - Specifies the namespace to which the registered service belongs. This parameter takes precedence over thensQuery parameter. This parameter is only supported in the Enterprise Edition.
  • Port (int: 0) - Specify the service port
  • Kind (string: "") - The service type, by default, is"", indicates a typical Consule service. It can be configured to the following values:
    • "connect-proxy" be applicableservice mesh Proxy, denoting another service.
    • "mesh-gateway" be applicablemesh gatewayan actual example
    • "terminating-gateway" be applicableterminating gatewayan actual example
    • "ingress-gateway" be applicableingress gatewayan actual example
  • Proxy (Proxy: nil) - As of 1.2.3, specify the configuration of the Service Grid Agent instance. This is available only in theKindValid when defined as a proxy or gateway. See alsoService Grid Proxy Configuration ReferenceGet all the details
  • Connect (Connect: nil) - designationService Grid Configuration. The Connections subsystem provides Consul's Service Grid functionality. See the Connect Structure section to see the supported fields.
  • Check (Check: nil) - Specifies a certain kind of check. See alsoChecking DocumentsGet more information about acceptable fields. If no name or id is provided for the check, it is automatically generated. To provide a custom id and/or name, set theCheckIDand/orNameFields.
  • Checks (array<Check>: nil) - Specifies a list of checks. If no name or id is provided for the check, it is automatically generated. To provide a custom id and/or name, set theCheckIDand/orNameFields. The automatically generatedNamerespond in singingCheckIDDepends on where the check is in the array, so even if the behavior is deterministic, it's recommended that all checks either be set by leaving the field blank/ omitting to let the consulCheckID, either provide a unique value.
  • EnableTagOverride (bool: false) - Specifies that the anti-entropy feature is disabled for tags for this service. IfEnableTagOverrideset totrueIf the external agent can be used in thecatalogsin this agent updates this service and modifies the label. Subsequent local synchronization operations by this agent will ignore the updated label. For example, if an external agent modifies the label and port of this service and theEnableTagOverrideset totrue, then after the next synchronization cycle, the service's port will revert to its original value, but the label will remain at the updated value. As a counterexample, if an external agent modifies the label and port of this service and theEnableTagOverrideset tofalse, then after the next synchronization cycle, the ports and tags of the service will revert to their original values and all modifications will be lost.
  • Weights (Weights: nil) - Specifies the weight of the service. See alsoService Configuration ReferenceGet more information. The default value is{"Passing": 1, "Warning": 1}. Weights apply only to locally registered services. If multiple nodes are registered for the same service, each node independently implements theEnableTagOverrideand other service configuration items. Updating the label of a service registered on one node does not necessarily update the same label on a service of the same name registered in another node. If you do not specify theEnableTagOverride, then the default value isfalse. See also.anti-entropy synchronizationGet more information.
  • Partition (string: "") - The partition to use. If not provided, the partition is inferred from the requested ACL token, or defaults to thedefaultPartitioning. This parameter is only supported in Enterprise Edition.

Connect Structure

with regards toConnect field with the following parameters:

  • Native (bool: false) - Specify whether this serviceprotozoabe in favor ofConsul Service GridProtocol. If the protocol for thetrue, then Service Grid Proxy, DNS lookups, etc. will be able to discover this service.

  • SidecarService (ServiceDefinition: nil) -Specifies an optional nested service definition to be registered. See alsoDeploying sidecar servicesGet more information.

Example of a registered service request body

{
  "ID": "redis1",
  "Name": "redis",
  "Tags": ["primary", "v1"],
  "Address": "127.0.0.1",
  "Port": 8000,
  "Meta": {
    "redis_version": "4.0"
  },
  "EnableTagOverride": false,
  "Check": {
    "DeregisterCriticalServiceAfter": "90m",
    "Args": ["/usr/local/bin/check_redis.py"],
    "Interval": "10s",
    "Timeout": "5s"
  },
  "Weights": {
    "Passing": 10,
    "Warning": 1
  }
}

Example of a registered service request

$ curl --request PUT \
    --data @ \
    http://127.0.0.1:8500/v1/agent/service/register?replace-existing-checks=true

Or something like this

$ curl -X PUT -d '                                      
{                                                    
    "id": "redis-node-exporter",                                   
    "name": "redis-node-exporter",   
    "Tags": ["primary"],
    "address": "192.168.88.131",                      
    "port": 9100,                       
    "EnableTagOverride": false
}' http://192.168.88.133:8603/v1/agent/service/register

Description:127.0.0.1:8500、192.168.88.133:8603Same as Consul Web UI access address

Registration effect:

After registration, you can see the registered services in Services

Reference Links:/consul/api-docs/agent/service#register-service

Write-off services

methodologies Request Path content format
PUT /agent/service/deregister/:service_id application/json

Attention:

1. If the service to be canceled does not exist, no action is taken.

2. The agent will be responsible for deregistering the service in the catalog. If there is a relevant check, it will also deregister.

path parameter

  • service_id (string: <required>) - Specify the ID of the service to be logged off

Query parameters

  • ns (string: "") - Specifies the namespace to which the service to be deregistered belongs. You can alsoSpecifying namespaces through other methods. This parameter is only supported in the Enterprise Edition
  • partition (string: "") The partition to use. If not provided, the partition is inferred from the requested ACL token, or defaults to thedefaultPartitioning. This parameter is only supported in Enterprise Edition.
$ curl --request PUT http://127.0.0.1:8500/v1/agent/service/deregister/my-service-id

Example:

$ curl --request PUT http://192.168.88.133:8603/v1/agent/service/deregister/redis-node-exporter

Reference Links:/consul/api-docs/agent/service#deregister-service

<Previous Next>