Example of using docker compose to build a consul cluster environment

Basic concepts of consul

Server mode and client mode
Server mode and client mode are types of consul nodes; client does not refer to the user client.

• The server mode provides data persistence function.
• The client mode does not provide persistence, and in fact it does not work, it just forwards the user client's request to the server mode node. Therefore, you can imagine the client mode node as LB (load balance), which is only responsible for request forwarding.
• Usually, the number of server mode nodes needs to be configured to be multiple, for example, 3 or 5. There is no limit on the number of nodes in client mode.
  

Command line parameters for starting server mode

• -server: indicates the currently used server mode; if not specified, it indicates the client mode.
• -node: specifies the name of the current node in the cluster.
• -config-dir: specifies the configuration file path to define the service; all files ending with .json under the path are accessed; the default value is: /consul/config.
• -data-dir: The directory where consul stores data; the default value is: /consul/data.
• -datacenter: data center name. The default value is dc1.
• -ui: Use consul's built-in web UI interface.
• -join: joins an existing cluster.
• -enable-script-checks: Checks whether the service is active, similar to enabling heartbeat.
• -bind: Bind to the server's IP address.
• -client: The client can access the IP address. The default value is: "127.0.0.1", which means that only loopback connections are allowed.
• -bootstrap-expect: The expected number of server nodes in a data center. When Consul starts, it will wait until this number of servers is reached before booting the entire cluster. The value of this parameter must be consistent on all server nodes in the same data center.
  

Here is another parameter - bootstrap, which is used to control whether a server runs in bootstrap mode: when a server is in bootstrap mode, it can elect itself as a leader; note that only one server can be in bootstrap mode in a data center. Therefore, this parameter can generally only be used in a development environment with only one server. In a cluster production environment with multiple servers, this parameter cannot be used. Otherwise, if multiple servers mark themselves as leaders, data inconsistency will occur. In addition, this flag cannot be specified at the same time as -bootstrap-expect.

Use docker-compose to build the following consul cluster environment

• The cluster contains three servers: node1, node2, node3
• The cluster contains one client: node4; and provides web UI access services on the client. .

Edit the docker-compose.yml file

version: '2'
networks:
  byfn:
 
services:
  consul1:
    image: consul
    container_name: node1
    command: agent -server -bootstrap-expect=3 -node=node1 -bind=0.0.0.0 -client=0.0.0.0 -datacenter=dc1
    networks:
      - byfn
 
  consul2:
    image: consul
    container_name: node2
    command: agent -server -retry-join=node1 -node=node2 -bind=0.0.0.0 -client=0.0.0.0 -datacenter=dc1
    depends_on:
        -consul1
    networks:
      - byfn
 
  consul3:
    image: consul
    container_name: node3
    command: agent -server -retry-join=node1 -node=node3 -bind=0.0.0.0 -client=0.0.0.0 -datacenter=dc1
    depends_on:
        -consul1
    networks:
      - byfn
 
  consul4:
    image: consul
    container_name: node4
    command: agent -retry-join=node1 -node=ndoe4 -bind=0.0.0.0 -client=0.0.0.0 -datacenter=dc1 -ui 
    ports:
      - 8500:8500
    depends_on:
        -consul2
        -consul3
    networks:
      - byfn

Start the service

$ docker-compose up
$ docker exec -t node1 consul members
Node Address Status Type Build Protocol DC Segment
node1 172.21.0.2:8301 alive server 1.4.0 2 dc1 <all>
node2 172.21.0.4:8301 alive server 1.4.0 2 dc1 <all>
node3 172.21.0.3:8301 alive server 1.4.0 2 dc1 <all>
ndoe4 172.21.0.5:8301 alive client 1.4.0 2 dc1 <default>

Visit http://127.0.0.1:8500

Registration Configuration Center Example

spring:
  application:
    name: cloud-payment-service
  ####consul registration center address cloud:
    consul:
      enabled: true
      host: 127.0.0.1
      port: 8500
      discovery:
        hostname: 127.0.0.1
        prefer-ip-address: true
        service-name: ${spring.application.name}
        #healthCheckInterval: 15s
        instance-id: ${spring.application.name}-8002
        enabled: true

KV access example

$ docker exec -t node4 consul kv put foo "Hello foo"
$ docker exec -t node4 consul kv put foo/foo1 "Hello foo1"
$ docker exec -t node4 consul kv put foo/foo2 "Hello foo2"
$ docker exec -t node4 consul kv put foo/foo21 "Hello foo21"
$ docker exec -t node4 consul kv get foo
Hello foo
$ docker exec -t node4 consul kv get -detailed foo/foo1
CreateIndex 124
Flags 0
Key foo/foo1
LockIndex 0
ModifyIndex 124
Session -
Value Hello foo1
$ docker exec -t node4 consul kv get -keys -separator="" foo
foo
foo/foo1
foo/foo2
foo/foo2/foo21
$ docker exec -t node4 consul kv get not-a-real-key
Error! No key exists at: not-a-real-key

The above is the details of using docker compose to build a consul cluster environment. For more information about the docker compose cluster environment, please pay attention to other related articles on 123WORDPRESS.COM!