Consul入门（续1）

发表于 | 分类于

本文依循官方入门教程 https://learn.hashicorp.com/consul/getting-started/consul-gs-intro
加油鸭～～～

introduction 介绍

This “Getting Started” section of Learn will help you build mental models to understand how Consul works with guides that you can run locally on your computer. Complete the guides in this section sequentially; some of them rely on the previous ones.

install consul 安装 consul

教程采用的方法是下载源文件压缩包，解压后得到二进制可运行文件，将文件移动到系统路径列表所对应的一个路径中，或者将文件路径添加到系统路径 Path。
不过，我不打算这么安装，想通过docker安装。

1
sudo docker pull consul

run the consul agent 运行consul 客户端

Server and Client agents

In production you would run each Consul agent in either in server or client mode. Each Consul datacenter must have at least one server, which is responsible for maintaining Consul’s state. This includes information about other Consul servers and clients, what services are available for discovery, and which services are allowed to talk to which other services.

Warning: We highly discourage single-server production deployments.

In order to make sure that Consul’s state is preserved even if a server fails, you should always run either three or five servers in production. The odd number of servers (and no more than five of them) strikes a balance between performance and failure tolerance. You can learn more about these requirements in Consul’s architecture documentation.

Non-server agents run in client mode. A client is a lightweight process that registers services, runs health checks, and forwards queries to servers. A client must be running on every node in the Consul datacenter that runs services, since clients are the source of truth about service health.

When you’re ready to got into production you can find more guidance on production deployment of servers and clients in this guide. For now, lets start our local agent in development mode, which is an in memory server mode with some common features enabled (despite security risks) for ease of use, and all persistence options turned off.

Warning: Never run Consul in -dev mode in production.

starting the agent

如果单机安装，运行如下命令

1
$ consul agent -dev

我感觉自己用docker 运行 consul 玩不转，汗。还是老实跟着教程走吧。
Ubuntu 安装consul，同时查得自己的私有ip 为192.168.2.92

1
2
$ sudo apt-get install consul
$ consul agent -dev -bind 192.168.2.92

如果正常运行，log会显示运行的过程，涉及一些网络设置信息、选举leader的过程以及约每分钟一次的同步？

1
2
3
4
5
2019/12/19 10:05:37 [DEBUG] agent: Service 'consul' in sync
2019/12/19 10:06:39 [DEBUG] agent: Service 'consul' in sync
2019/12/19 10:07:50 [DEBUG] agent: Service 'consul' in sync
2019/12/19 10:09:28 [DEBUG] agent: Service 'consul' in sync
2019/12/19 10:10:35 [DEBUG] agent: Service 'consul' in sync

The logs report that the Consul agent has started and is streaming some log data. They also report that the agent is running as a server and has claimed leadership. Additionally, the local agent has been marked as a healthy member of the datacenter.

datacenter members

Check the membership of the Consul datacenter by running the consul members command in a new terminal window. The output lists the agents in the datacenter. We’ll cover ways to join Consul agents together later on, but for now there is only one member (your machine).

1
2
3
$ consul members
Node                    Address            Status  Type    Build  Protocol  DC
clay-HP-ProBook-446-G3  192.168.2.92:8301  alive   server  0.6.4  2         dc1

The output displays your agent, its IP address, its health state, its role in the datacenter, and some version information. You can discover additional metadata by providing the -detailed flag.

The members command runs against the Consul client, which gets its information via gossip protocol. The information that the client has is eventually consistent, but at any point in time its view of the world may not exactly match the state on the servers. For a strongly consistent view of the world, query the HTTP API, which forwards the request to the Consul servers.

1
2
3
4
5
6
7
8
9
10
11
12
$ curl localhost:8500/v1/catalog/nodes
[
    {
        "Node":"clay-HP-ProBook-446-G3",
        "Address":"192.168.2.92",
        "TaggedAddresses":{
            "wan":"192.168.2.92"
        },
        "CreateIndex":3,
        "ModifyIndex":4
    }
]

In addition to the HTTP API, you can use the DNS interface to discover the nodes. The DNS interface will send your query to the Consul servers unless you’ve enabled caching. To perform DNS lookups you have to point to the Consul agent’s DNS server, which runs on port 8600 by default. The format of the DNS entries (such as Judiths-MBP.node.consul) will be covered in more detail later.

1
$ dig @127.0.0.1 -p 8600 Judiths-MBP.node.consul

stopping the agent

1
$ consul leave

If you switch back to the window with Consul’s streaming log output, the logs indicate that the Consul agent left the datacenter.

When you issue the leave command, Consul notifies other members that the agent left the datacenter. When an agent leaves, its local services running on the same node and their checks are removed from the catalog and Consul doesn’t try to contact that node again.

Forcibly killing the agent process indicates to other agents in the Consul datacenter that the node failed instead of left. When a node fails, its health is marked as critical, but it is not removed from the catalog. Consul will automatically try to reconnect to a failed node, assuming that it may be unavailable because of a network partition, and that it may be coming back.

If an agent is operating as a server, a graceful leave is important to avoid causing a potential availability outage affecting the consensus protocol. See the Adding and Removing Servers guide for details on how to safely add and remove servers.

summary

Now that you have started and stopped a Consul agent in development mode, continue to the next guide where you will learn how Consul knows about the existence and location of services in your datacenter.

Register a Service and Health Check - Service Discovery

In the previous guide you ran a local Consul agent, and checked for other members of the datacenter. In this guide you will start using Consul by registering a service and a health check.

One of the major use cases for Consul is service discovery. Consul provides a DNS interface that downstream services can use to find the IP addresses of their upstream dependencies.

Consul knows where these services are located because each service registers with its local Consul client. Operators can register services manually, configuration management tools can register services when they are deployed, or container orchestration platforms can register services automatically via integrations.

In this guide, you’ll register a service and health check manually by providing Consul with a configuration file, and use Consul discover its location using the DNS interface and HTTP API. Manually registering a service will help you understand the information that your automation tooling will ultimately need to provide Consul in order to take advantage of service discovery.

defining a service

You can register services either by providing a service definition, which is the most common way to register services, or by making a call to the HTTP API. Here we will use a service definition.

First, create a directory for Consul configuration. Consul loads all configuration files in the configuration directory, so a common convention on Unix systems is to name the directory something like /etc/consul.d (the .d suffix implies “this directory contains a set of configuration files”).

1
2
$ cd /etc
$ mkdir ./consul.d

Next, write a service definition configuration file. Pretend there is a service named “web” running on port 80. Use the following command to create a file called web.json in the configuration directory. This file will contain the service definition: name, port, and an optional tag you can use to find the service later on. (In this case copy the whole code block except for the $ to run the command and create the file.)

1
2
3
4
5
6
$ echo '{"service":
  {"name": "web",
   "tags": ["rails"],
   "port": 80
  }
}' > ./consul.d/web.json

Now, restart the agent, using command line flags to specify the configuration directory and enable script checks on the agent.
走到这里，其实下面的命令运行不通，把consul卸载了（用apt-get install 安装的版本太老了），然后从官网下载压缩包，解压，移动到 /usr/local/bin/ 里面。

1
2
$ cd /etc/consul.d/
$ consul agent -dev -enable-script-checks -config-dir=./

You’ll notice in the output that Consul “synced” the web service. This means that the agent loaded the service definition from the configuration file, and has successfully registered it in the service catalog.

Note: We never started a web service in this example. Consul can register services that aren’t running yet. It correlates each running service with its registration based on the service’s port.

In a multi-agent Consul datacenter, each service would register with its local Consul client, and the clients would forward the registration to the Consul servers, which maintain the service catalog.

If you wanted to register multiple services, you could create multiple service definition files in the Consul configuration directory.

quering services

Once the agent adds the service to Consul’s service catalog you can query it using either the DNS interface or HTTP API.

DNS interface

First query the web service using Consul’s DNS interface. The DNS name for a service registered with Consul is NAME.service.consul, where NAME is the name you used to register the service (in this case, web). By default, all DNS names are in the consul namespace, though this is configurable.

The fully-qualified domain name of the web service is web.service.consul. Query the DNS interface (which Consul runs by default on port 8600) for the registered service.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
$ dig @127.0.0.1 -p 8600 web.service.consul

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @127.0.0.1 -p 8600 web.service.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23392
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;web.service.consul.            IN      A

;; ANSWER SECTION:
web.service.consul.     0       IN      A       127.0.0.1

;; ADDITIONAL SECTION:
web.service.consul.     0       IN      TXT     "consul-network-segment="

;; Query time: 1 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Thu Dec 19 12:06:04 CST 2019
;; MSG SIZE  rcvd: 99

As you can see, an A record was returned containing the IP address where the service was registered. A records can only hold IP addresses.

Tip: Since we started consul with a minimal configuration, the A record will return local host (127.0.0.1). Set the Consul agent -advertise argument or the address field in the service definition if you want to advertise an IP address that is meaningful to other nodes in the datacenter.

You can also use the DNS interface to retrieve the entire address/port pair as a SRV record.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$ dig @127.0.0.1 -p 8600 web.service.consul SRV

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @127.0.0.1 -p 8600 web.service.consul SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4596
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;web.service.consul.            IN      SRV

;; ANSWER SECTION:
web.service.consul.     0       IN      SRV     1 1 80 clay-HP-ProBook-446-G3.node.dc1.consul.

;; ADDITIONAL SECTION:
clay-HP-ProBook-446-G3.node.dc1.consul. 0 IN A  127.0.0.1
clay-HP-ProBook-446-G3.node.dc1.consul. 0 IN TXT "consul-network-segment="

;; Query time: 0 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Thu Dec 19 12:10:19 CST 2019
;; MSG SIZE  rcvd: 157

The SRV record says that the web service is running on port 80 and exists on the node Judiths-MBP.lan.node.dc1.consul.. An additional section is returned by the DNS with the A record for that node.

Finally, you can also use the DNS interface to filter services by tags. The format for tag-based service queries is TAG.NAME.service.consul. In the example below, you’ll ask Consul for all web services with the “rails” tag. You’ll get a successful response since you registered the web service with that tag.

Finally, you can also use the DNS interface to filter services by tags. The format for tag-based service queries is TAG.NAME.service.consul. In the example below, you’ll ask Consul for all web services with the “rails” tag. You’ll get a successful response since you registered the web service with that tag.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
$ dig @127.0.0.1 -p 8600 rails.web.service.consul

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @127.0.0.1 -p 8600 rails.web.service.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53829
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rails.web.service.consul.      IN      A

;; ANSWER SECTION:
rails.web.service.consul. 0     IN      A       127.0.0.1

;; ADDITIONAL SECTION:
rails.web.service.consul. 0     IN      TXT     "consul-network-segment="

;; Query time: 0 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Thu Dec 19 12:14:17 CST 2019
;; MSG SIZE  rcvd: 105

HTTP API

In addition to the DNS interface, you can also query for the service using the HTTP API.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
$ curl http://localhost:8500/v1/catalog/service/web
[
    {
        "ID": "9d5737a0-4367-010f-8c8b-a0a60976503c",
        "Node": "clay-HP-ProBook-446-G3",
        "Address": "127.0.0.1",
        "Datacenter": "dc1",
        "TaggedAddresses": {
            "lan": "127.0.0.1",
            "wan": "127.0.0.1"
        },
        "NodeMeta": {
            "consul-network-segment": ""
        },
        "ServiceKind": "",
        "ServiceID": "web",
        "ServiceName": "web",
        "ServiceTags": [
            "rails"
        ],
        "ServiceAddress": "",
        "ServiceWeights": {
            "Passing": 1,
            "Warning": 1
        },
        "ServiceMeta": {},
        "ServicePort": 80,
        "ServiceEnableTagOverride": false,
        "ServiceProxy": {
            "MeshGateway": {},
            "Expose": {}
        },
        "ServiceConnect": {},
        "CreateIndex": 10,
        "ModifyIndex": 10
    }
]

The HTTP API lists all nodes hosting a given service. As you will see later when we discuss health checks you’ll typically want to filter your query for only healthy service instances, which DNS does automatically under the hood. Filter your HTTP API query to look for only healthy instances.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
$ curl 'http://localhost:8500/v1/health/service/web?passing'
[
    {
        "Node": {
            "ID": "9d5737a0-4367-010f-8c8b-a0a60976503c",
            "Node": "clay-HP-ProBook-446-G3",
            "Address": "127.0.0.1",
            "Datacenter": "dc1",
            "TaggedAddresses": {
                "lan": "127.0.0.1",
                "wan": "127.0.0.1"
            },
            "Meta": {
                "consul-network-segment": ""
            },
            "CreateIndex": 9,
            "ModifyIndex": 10
        },
        "Service": {
            "ID": "web",
            "Service": "web",
            "Tags": [
                "rails"
            ],
            "Address": "",
            "Meta": null,
            "Port": 80,
            "Weights": {
                "Passing": 1,
                "Warning": 1
            },
            "EnableTagOverride": false,
            "Proxy": {
                "MeshGateway": {},
                "Expose": {}
            },
            "Connect": {},
            "CreateIndex": 10,
            "ModifyIndex": 10
        },
        "Checks": [
            {
                "Node": "clay-HP-ProBook-446-G3",
                "CheckID": "serfHealth",
                "Name": "Serf Health Status",
                "Status": "passing",
                "Notes": "",
                "Output": "Agent alive and reachable",
                "ServiceID": "",
                "ServiceName": "",
                "ServiceTags": [],
                "Type": "",
                "Definition": {},
                "CreateIndex": 9,
                "ModifyIndex": 9
            }
        ]
    }
]

Updating Services

Next you’ll update the web service by registering a health check for it. Remember that because you never started a service on port 80 where you registered web, the health check you register will fail.

You can update service definitions without any downtime by changing the service definition file and sending a SIGHUP to the agent or running consul reload. Alternatively, you can use the HTTP API to add, remove, and modify services dynamically. In this example, you will update the registration file.
web.json: 

1
2
3
4
5
6
7
8
9
10
11
{
    "service": {
        "name": "web",
        "tags": ["rails"],
        "port": 80, 
        "check": {
            "args": ["curl", "localhost"],
            "interval": "10s"
        }
    }   
}

The ‘check’ stanza of this service definition adds a script-based health check that tries to connect to the web service every 10 seconds via curl. Script based health checks run as the same user that started the Consul process.

If the command exits with an exit code >= 2, then the check will fail and Consul will consider the service unhealthy. An exit code of 1 will be considered as warning state.

Now reload Consul’s configuration to make it aware of the new health check.

1
2
$ consul reload
Configuration reload triggered

Notice the following lines in Consul’s logs, which indicate that the web check is critical.

Consul’s DNS server only returns healthy results. Query DNS for the web service again. It shouldn’t return any IP addresses since web’s health check is failing.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ dig @127.0.0.1 -p 8600 web.service.consul

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @127.0.0.1 -p 8600 web.service.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30685
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;web.service.consul.            IN      A

;; AUTHORITY SECTION:
consul.                 0       IN      SOA     ns.consul. hostmaster.consul. 1576736917 3600 600 86400 0

;; Query time: 0 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Thu Dec 19 14:28:37 CST 2019
;; MSG SIZE  rcvd: 97

Notice that there is no answer section in the response, because Consul has marked the web service as unhealthy.

Summary

In this guide you registered a service with Consul and learned how to query it using the HTTP API and DNS interface. You also added a script based health check for the service. You can find a complete list of service registration fields in the API documentation, or learn more about health checks in the check definition documentation.

Continue to the next guide to learn how to enable Consul’s service mesh control plane called Consul Connect, which allows you to secure and observe network traffic between your services, and allow or deny inter-service communication.

Connect Services - Service Mesh

In addition to providing IP addresses directly to services with the DNS interface or HTTP API, Consul can connect services to each other via sidecar proxies that you deploy locally with each service instance. This type of deployment (local proxies that control network traffic between service instances) is a service mesh. Because sidecar proxies connect your registered services, Consul’s service mesh feature is called Consul Connect.

Connect lets you secure and observe communication between your services without modifying their code. Instead Connect configures sidecar proxies to establish mutual TLS between your services and either allow or deny communication between them based on their registered names. Because sidecar proxies control all service-to-service traffic, they can gather metrics about it and export them to a third party aggregator like Prometheus.

You can also natively integrate applications with Consul Connect for optimal performance and security.

Security Warning: This guide demonstrates Connect features with a dev-mode agent for simplicity, which is not a production-recommended secure way to deploy Connect. Please read the Connect production guide to learn about securely deploying Connect.

Registering services that use Connect is similar to registering services normally. In this guide you will:

  • Start a service.
  • Register it normally, but with an additional connect stanza.
  • Register a second proxy to communicate with the service.
  • Start sidecar proxies.
  • Practice blocking the connection to the service by creating an intention.

start a connect-unaware service

Begin by starting a service that is unaware of Connect. You will use socat to start a basic echo service, which will act as the “upstream” service in this guide. In production, this service would be a database, backend, or any service which another service relies on.

Socat is a decades-old Unix utility that lacks a concept of encryption or the TLS protocol. You will use it to demonstrate that Connect takes care of these concerns for you. If socat isn’t installed on your machine, it should be available via a package manager.

Start the socat service and specify that it will listen for TCP connections on port 8181.

1
$ socat -v tcp-l:8181,fork exec:"/bin/cat"

You can verify it is working by using nc (netcat) to connect directly to the echo service on the correct port. Once connected, type some text and press enter. The text you typed should be echoed back:

1
2
3
4
5
$ nc 127.0.0.1 8181
hello
hello
testing 123
testing 123

Register the Service and Proxy with Consul

Next, register the service with Consul by writing a new service definition, like you did in the last guide. This time you will include a Connect stanza in the registration that will register a sidecar proxy to handle traffic for this backend service instance.

Add a file called socat.json to the consul.d directory with the following command (copy the whole code block except the $).

1
2
3
4
5
6
7
$ echo '{
  "service": {
    "name": "socat",
    "port": 8181,
    "connect": { "sidecar_service": {} }
  }
}' > ./consul.d/socat.json

Now run consul reload or send a SIGHUP signal to Consul so it will read the new configuration.

Take a look at the “connect” stanza in the registration you just added. This empty configuration notifies Consul to register a sidecar proxy for this process on a dynamically allocated port. It also creates reasonable defaults that Consul will use to configure the proxy once you start it via the CLI. Consul does not automatically start the proxy process for you. This is because Consul Connect allows you to chose the proxy you’d like to use.

Consul comes with a L4 proxy for testing purposes, and first-class support for Envoy, which you should use for production deployments and layer 7 traffic management. You’ll use the L4 proxy in this guide, because, unlike Envoy, it comes with Consul and doesn’t require any extra installation.

Start the proxy process in another terminal window using the consul connect proxy command, and specify which service instance and proxy registration it corresponds to.

1
2
3
4
5
6
7
8
9
10
11
12
$ consul connect proxy -sidecar-for socat
==> Consul Connect proxy starting...
    Configuration mode: Agent API
        Sidecar for ID: socat
              Proxy ID: socat-sidecar-proxy

==> Log data will now stream in as it occurs:

    2019/12/19 15:03:23 [INFO] Proxy loaded config and ready to serve
    2019/12/19 15:03:23 [INFO] TLS Identity: spiffe://bb324d47-b9d5-5f51-788e-1d8fb0fa6133.consul/ns/default/dc/dc1/svc/socat
    2019/12/19 15:03:23 [INFO] TLS Roots   : [Consul CA 7]
    2019/12/19 15:03:23 [INFO] public listener starting on 0.0.0.0:21000

Register a Dependent Service and Proxy

Next, register a downstream service called “web”. Like the socat service definition, the configuration file for web will include a connect stanza that specifies a sidecar, but unlike the socat definition, the configuration here isn’t empty. Instead it specifies web’s upstream dependency on socat, and the port that the proxy will listen on.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ echo '{"service": {
    "name": "web",
    "port": 8080,
    "connect": {
      "sidecar_service": {
        "proxy": {
          "upstreams": [{
             "destination_name": "socat",
             "local_bind_port": 9191
          }]
        }
      }
    }
  }
}' > ./consul.d/web.json

Use consul reload or SIGHUP to reload Consul with the new web service definition. This registers a sidecar proxy for the service “web” that will listen on port 9191 to establish mTLS connections to “socat”.

If we were running a real web service it would talk to its proxy on a loopback address. The proxy would encrypt its traffic and send it over the network to the sidecar proxy for the socat service. Socat’s proxy would decrypt the traffic and send it locally to socat on a loopback address at port 8181. Because there is no web service running, you will pretend to be the web service by talking to its proxy on the port that we specified (9191).

Before you start the proxy process, verify that you aren’t able to connect to the socat service on port 9191. The below command should exit immediately, because there is nothing listening on port 9191 (socat is listening on 8181).

Now start the web proxy using the configuration from the sidecar registration.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ consul connect proxy -sidecar-for web
==> Consul Connect proxy starting...
    Configuration mode: Agent API
        Sidecar for ID: web
              Proxy ID: web-sidecar-proxy

==> Log data will now stream in as it occurs:

    2019/12/19 15:14:10 [INFO] 127.0.0.1:9191->service:default/socat starting on 127.0.0.1:9191
    2019/12/19 15:14:10 [INFO] Proxy loaded config and ready to serve
    2019/12/19 15:14:10 [INFO] TLS Identity: spiffe://bb324d47-b9d5-5f51-788e-1d8fb0fa6133.consul/ns/default/dc/dc1/svc/web
    2019/12/19 15:14:10 [INFO] TLS Roots   : [Consul CA 7]
    2019/12/19 15:14:10 [INFO] public listener starting on 0.0.0.0:21001
    2019/12/19 15:14:16 [ERR] failed to dial: dial tcp 127.0.0.1:8080: connect: connection refused
    2019/12/19 15:14:26 [ERR] failed to dial: dial tcp 127.0.0.1:8080: connect: connection refused
    2019/12/19 15:14:36 [ERR] failed to dial: dial tcp 127.0.0.1:8080: connect: connection refused
    2019/12/19 15:14:46 [ERR] failed to dial: dial tcp 127.0.0.1:8080: connect: connection refused
    2019/12/19 15:14:56 [ERR] failed to dial: dial tcp 127.0.0.1:8080: connect: connection refused

Note in the first log line that the proxy setup a local listener on port 9191 that will proxy to the socat service just as we configured in the sidecar registration. Subsequent log lines list the identity URL of the certificate loaded from the agent, identifying it as the “web” service, and the set of trusted root CAs that the proxy knows about.

Try connecting to socat again on port 9191. This time it should work and echo back your text.

Close the connection by typing Crl+c.

The communication between the web and socat proxies is encrypted and authorized over a mutual TLS connection, while communication between each service and its sidecar proxy is unencrypted. In production, services should only accept only loopback connections. Any traffic in and out of the machine should travel through the proxies and therefore would always be encrypted.

Security note: The Connect security model requires trusting loopback connections when you use proxies. To further secure loopback connections you can use tools like network namespacing.

control communication with intentions

Intentions define which services are allowed communicate with which other services. The connections above succeeded because in development mode, the ACL system (and therefor the default intention policy) is “allow all” by default.

Create an intention to deny access from web to socat that specifies policy, and the source and destination services.

1
2
$ consul intention create -deny web socat
Created: web => socat (deny)

Now, try to connect again. The connection will fail.

1
$ nc 127.0.0.1 9191

Delete the intention.

1
2
$ consul intention delete web socat
Intention deleted.

Try the connection again, and it will succeed.

1
2
3
$ nc 127.0.0.1 9191
hello
hello

Intentions allow you to segment your network much like traditional firewalls, but they rely on the services’ logical names (for example “web” or “socat”) rather than the IP addresses of each individual service instance. Learn more about intentions in the documentation.

Note: Changing intentions does not affect existing connections with the current version of Consul. You must establish a new connection to see the effects of a changed intention.

Summary

This guide has demonstrated some basic Connect functions but there is much more. Take a look at the resource list in our getting started with Connect documentation for more guides on setting up Connect with Envoy proxy, with Docker, and on Kubernetes, and how to enable layer 7 observability, routing, and gateways.

In this guide you configured a service on a single agent and used Connect for automatic connection authorization and encryption. Next explore how to use Consul’s key value (KV) store for service configuration.

Add to Consul KV - Service Configuration

In addition to providing service discovery, integrated health checking, and securing network traffic, Consul includes a key value store, which you can use to dynamically configure applications, coordinate services, manage leader election, or serve as a data backend for Vault, along with a myriad of other uses.

In this guide you will explore the Consul key value store (Consul KV) using the command line. The guide assumes that the Consul agent from the previous guide is still running. If not you can start a new one by running consul agent -dev. Consul KV is enabled automatically on Consul agents; you don’t need to enable it in Consul’s configuration.

There are two ways to interact with the Consul KV store: the HTTP API and the CLI. In this guide we will use the CLI. See the HTTP API documentation to learn how applications and services can interact with Consul KV.

Add Data

First, insert or “put” some values into the KV store with the consul kv put command. The first entry after the command is the key, and the second entry is the value.

1
2
3
4
5
6
7
8
$ consul kv put redis/config/minconns 1
Success! Data written to: redis/config/minconns

$ consul kv put redis/config/maxconns 25
Success! Data written to: redis/config/maxconns

$ consul kv put -flags=42 redis/config/users/admin abcd1234
Success! Data written to: redis/config/users/admin

Notice that with the last key you entered (“redis/config/users/admin”), you set a flag value of 42. Keys support setting a 64-bit integer flag value that isn’t used internally by Consul, but can be used by clients to add metadata to any KV pair.

query data

Now, query for the value of one of the keys you just entered.

1
2
$ consul kv get redis/config/minconns
1

Consul retains some additional metadata about the key-value pair. Retrieve the some metadata (including the “flag” you set) using the -detailed command line flag.

1
2
3
4
5
6
7
8
$ consul kv get -detailed redis/config/users/admin
CreateIndex      907
Flags            42
Key              redis/config/users/admin
LockIndex        0
ModifyIndex      907
Session          -
Value            abcd1234

List all the keys in the store using the recurse options. Results are returned in lexicographical order.

1
2
3
4
$ consul kv get -recurse 
redis/config/maxconns:25
redis/config/minconns:1
redis/config/users/admin:abcd1234

Delete Data

Delete a key from the Consul KV store, issue a “delete” call.

1
2
$ consul kv delete redis/config/minconns
Success! Deleted key: redis/config/minconns

Consul lets you interact with keys in a folder-like way. Although all the keys in the KV store are actually stored flat, Consul allows you to manipulate keys that share a certain prefix as a group, as if they were in folders or subfolders.

Delete all the keys with the redis prefix using the recurse option.

1
2
$ consul kv delete -recurse redis
Success! Deleted keys with prefix: redis

Modify Existing Data

update the value of an existing key, put a new value at an extant “path”.

1
2
3
4
5
6
7
8
$ consul kv put foo bar
Success! Data written to: foo
$ consul kv get foo
bar
$ consul kv put foo zip
Success! Data written to: foo
$ consul kv get foo
zip

Summary

In this guide you added, viewed, modified, and deleted entries in Consul’s key value store.

Consul can perform atomic key updates using a Check-And-Set (CAS) operation, and includes other sophisticated options for writing keys and values. You can explore these options on the help page for the consul kv put command.

1
$ consul kv put -h

These are only a few examples of what the API supports. For the complete documentation, please see the HTTP API documentation and CLI documentation.

Now that Consul contains some interesting data including service registrations, keys, values, and intentions, continue to the next guide to explore all this data in the Consul web UI.

Explore the Consul UI

Consul’s web UI allows you to view and interact with Consul via a graphical user interface, which can lower the barrier of entry for new users, and ease troubleshooting.

If you were running Consul in production you would need to enable the UI in Consul’s configuration file or using the -ui command line flag, but because your agent is running in development mode, the UI is automatically enabled.

If you have already stopped the agent you were using in the previous guides, you can visit a live demo-instance of the Consul Web UI to explore the steps in this guide.
If you are still running the agent that you used for the previous guides, you will be able to follow the activities in this guide more closely. Open a browser window and navigate to the UI, which is available at the /ui path on the same port as the HTTP API (port 8500).

http://localhost:8500/ui

A page will load that has a pink menu bar across the top. Welcome to the Consul Web UI.

The landing page for the UI is the services page, which gives you a list of all registered services including their health, tags, type, and source. You can click on a specific service to learn more about its instance count, the health of individual instances, and which agent each instance is registered with.

You can filter the services visible on the page based on their name, tag, status, or other search terms.

Try it: filter for sidecar services by typing sidecar in the search bar and pressing the enter key.

You can learn about individual services by clicking on them.

Try it: click on the web-sidecar-proxy service to explore what information is available. Now select the one listed instance of the web-sidecar-proxy service to see what information is available on an instance-to-instance basis.

view Nodes

Next click on the “Nodes” option in the pink top navigation bar to go to the nodes page. There you’ll find an overview of the entire datacenter including the health status of each node. You can select individual nodes to learn about their health checks, registered services, round trip time, and lock sessions.

You can also filter the nodes by heath status, or search for them in the search bar.

Try it: Select the nodes page from the top menu bar and click on your local machine.

Manage the Key-Value Store

In the top navigation, click “Key/Value” to view the page for Consul KV. If you are using the same agent that from previous guides, you should see one key, foo.

The keys page has a folder-like structure. Objects appear nested according to their key prefix. For example, you could have a folder for each application, business function, or a nested combination of the two.

Try it: From the main page, click the blue “Create” button to add a new key-value pair. Call the key redis/user with a value Alice. Now create another pair with the key redis/password and the value 123. On the main page, notice that there is only one new entry, called “redis”, with a folder icon next to it.

When you are clicked into a folder, Consul will automatically nest new keys under that folder, without you needing to type the prefix.

Manage Access Control Lists

Consul uses Access Control Lists (ACLs) to secure the UI, API, CLI, service communications, and agent communications. You need to configure ACLs in your Consul datacenter to secure it for production, however, on your development agent they aren’t enabled, so the there isn’t much to see on your “ACL” page at the moment.

You can secure the UI itself with ACLs, by limiting read, write, and update permissions for the various pages in the UI. You do this by creating a token with the appropriate permissions, and adding it to the UI under the ACL page. To remove access, simply select “Stop using” from your tokens action menu in the token list.

Security Warning: The browser can store tokens that you add to the UI.

Intentions

Click on the “Intentions” menu item to navigate to the intentions page in the UI. There aren’t any intentions there yet, but if you are still running the same agent that you used for the previous guides, you can create an intention to block communication between your web and socat services.

Try it: Click on the blue “Create” button. On the creation page set the source service to “web” and the destination to “socat”. Make a deny intention. Open a terminal window and try to connect to to the socat service with the command nc 127.0.0.1 9191. It should exit immediately. Now on the main intentions page, click on the “…” menu item at the right of the new intention. Delete it and try to connect again. This time it should succeed.

Adjust UI Settings

Click on “Settings” at the far-right of the menu bar. Here you can edit the UI’s settings.

If you have set up a metrics dashboard to monitor your services, you can add a link on the settings page that will auto-populate placeholders for there service name and datacenter, and link out to each service’s metrics from its UI page.

You can also choose whether or not you would like to set up a blocking query to update the UI in real time, rather than upon refresh. This is off by default because it can have performance implications.

UI Task Table

As you may have noticed, some pages of the web UI are read-only, while others are interactive. Below is a table with the CRUD actions available for each page.

Page Action
Services Read
Nodes Read
Key/Value Create, Read, Update, Delete
Intentions Create, Read, Update, Delete
ACLs Create, Read, Update, Delete

Next Steps

Now that you are comfortable navigating the UI, try using the Consul CLI to accomplish the same tasks we listed here.

So far you have explored the core functionality of Consul, including service discovery, securing services with a mesh, and using the key value store. Continue to the next guide to learn how to set up a Consul datacenter by joining multiple Consul agents together.

Note: The next guide relies on VirtualBox, and Vagrant to run multiple Consul agents on your computer at once. If you haven’t downloaded them yet, now would be a good time to do so.

Create a Local Consul Datacenter

这一小节，不跟官方教程了，采用docker来。官方需要虚拟机，好重。
以下教程来自于： https://www.jianshu.com/p/df3ef9a4f456

  • 1 docker 拉取consul 镜像

    1
    docker pull consul

  • 2 启动server
    启动前，先建立/data/consul文件，保存consul数据

    1
    mkdir -p /data/consul

  • 3 使用docker run 启动server

    1
    docker run -d -p 8500:8500 -v /data/consul:/consul/data -e CONSUL_BIND_INTERFACE='eth0' --name=consul1 consul agent -server -bootstrap -ui -client='0.0.0.0'

agent: 表示启动 agent 进程
server: 表示 consul 为 server 模式
client: 表示 consul 为 client 模式
bootstrap: 表示这个节点是 Server-Leader
ui: 启动 Web UI, 默认端口 8500
node: 指定节点名称, 集群中节点名称唯一
client: 绑定客户端接口地址, 0.0.0.0 表示所有地址都可以访问

1
docker inspect --format '{{ .NetworkSettings.IPAddress }}' consul1

查看第一个容器的ip地址

1
2
$ sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' consul1
172.17.0.2

  • 4 往集群中插入其他节点

    1
    2
    3
    sudo docker run -d --name=consul2 -e CONSUL_BIND_INTERFACE=eth0 consul agent --server=true --client=0.0.0.0 --join 172.17.0.2
    sudo docker run -d --name=consul3 -e CONSUL_BIND_INTERFACE=eth0 consul agent --server=true --client=0.0.0.0 --join 172.17.0.2
    sudo docker run -d --name=consul4 -e CONSUL_BIND_INTERFACE=eth0 consul agent --server=false --client=0.0.0.0 --join 172.17.0.2

  • 5 查看集群下面的节点

    1
    sudo docker exec -it consul1 consul members

  • 6 创建dc2，并将dc1和dc2关联起来

    1
    sudo docker run -d --name=consul5 -e CONSUL_BIND_INTERFACE='eth0' consul agent -server -bootstrap-expect 3 -datacenter=dc2

  • 7 往dc2添加节点

    1
    2
    3
    sudo docker run -d --name=consul6 -e CONSUL_BIND_INTERFACE=eth0 consul agent --datacenter=dc2 --server=true --client=0.0.0.0 --join 172.17.0.6;
    sudo docker run -d --name=consul7 -e CONSUL_BIND_INTERFACE=eth0 consul agent --datacenter=dc2 --server=true --client=0.0.0.0 --join 172.17.0.6;
    sudo docker run -d --name=consul8 -e CONSUL_BIND_INTERFACE=eth0 consul agent --datacenter=dc2 --server=false --client=0.0.0.0 --join 172.17.0.6;

  • 8 关联dc1和dc2

    1
    sudo docker exec -it consul6 consul join -wan 172.17.0.2

  • 9 http://127.0.0.1:8500/ui/dc2/services