Table of contents
1. What is service registration and discovery
3. Docker-consul implementation process
4. Docker-consul cluster configuration
1. Download the consul service
(1) Layer 4 proxy configuration
(2) Layer-7 proxy configuration
5. View consul cluster information
1. What is service registration and discovery
Service registration and discovery are indispensable and important components in the microservice architecture. At first, the services were single-node, which did not guarantee high availability and did not consider the pressure bearing of the service. The calls between services were simply accessed through the interface. Until a distributed architecture with multiple nodes appeared later, the initial solution was to load balance the front end of the service, so that the front end must know the network locations of all backend services and configure them in the configuration file. there will be a few questions
- If you need to call the backend service AN, you need to configure the network locations of N services, which is very troublesome to configure.
- Any change in the network location of the backend service requires changing the configuration of each caller.
Since there are these problems, service registration and discovery are to solve these problems. The back-end service AN can register its current network location to the service discovery module, and the service discovery will be recorded in the form of KV. K is generally the service name, and V is IP:PORT. The service discovery module conducts health checks regularly, and polls to see if these back-end services can be accessed. When the front-end calls the back-end service AN, it runs to the service discovery module to ask their network locations, and then calls their services. In this way, the above problems can be solved. The front end does not need to record the network locations of these back-end services at all, and the front-end and back-end are completely decoupled!
Two, Docker-consul cluster
1.Docker-consul
consul is a service management software developed by google open source using go language. Supports multi-data centers, distributed high availability, service discovery and configuration sharing. The Raft algorithm is used to ensure high availability of services. Built-in service registration and discovery framework, distributed consistency protocol implementation, health check, Key/Value storage, multi-data center solution, no longer need to rely on other tools (such as ZooKeeper, etc.).
Service deployment is simple, with only one executable binary package. Each node needs to run agent, which has two modes of operation: server and client. The official recommendation of each data center is that 3 or 5 server nodes are required to ensure data security and ensure that the election of the server-leader can be performed correctly.
In client mode, all services registered to the current node will be forwarded to the server node, and the information itself will not be persisted.
In the server mode, the function is similar to the client mode, the only difference is that it will persist all the information to the local, so that the information can be retained in case of failure. The server-leader is the boss of all server nodes. It is different from other server nodes in that it needs to be responsible for synchronizing registered information to other server nodes, and is also responsible for the health monitoring of each node.
Some key features provided by consul
Service registration and discovery: Consul makes service registration and service discovery easy through DNS or HTTP interfaces, and some external services, such as those provided by saas, can also be registered in the same way.
Health check: Health check enables consul to quickly alert the operation in the cluster. Integration with service discovery prevents service forwarding to failed services.
Key/Value Storage: A system for storing dynamic configurations. Provides a simple HTTP interface that can be operated anywhere.
Multi-datacenter: Support any number of regions without complicated configuration.
Installing consul is used for service registration, that is, some information of the container itself is registered in consul, and other programs can obtain registered service information through consul, which is service registration and discovery.
2. recorder
Gliderlabs/Registrator can check the running status of the container to automatically register, and can also log out the service of the docker container to the service configuration center. Consul, Etcd and SkyDNS2 are currently supported.
3.Consul-template
Consul-Template is an application that automatically replaces configuration files based on Consul. Consul-Template is a daemon process used to query Consul cluster information in real time, update any number of specified templates on the file system, and generate configuration files. After the update is complete, you can optionally run a shell command to perform the update and then reload the service configuration.
Consul-Template can query the service directory, Key, Key-values, etc. in Consul. This powerful abstraction and query language templates make Consul-Template particularly suitable for dynamically creating configuration files. For example: create Apache/Nginx Proxy Balancers, Haproxy Backends, etc.
3. Docker-consul implementation process
Take the configuration of nginx load balancing as an example
1. First configure consul-agent, there are two modes server and client:
- consul_client collects automatically discovered information, forwards all information that needs to be registered to the server node, and does not persist the information.
- consul_server persists all information to the local, synchronizes information to other server nodes through server-leader, and monitors the health of each node.
2. Then discover the network location of the application through the registrator, and send it to the automatic discovery module of the consul agent for registration;
3. consul-template automatically replaces the configuration file of the service based on the registered information of consul (template needs to be written).
4. Docker-consul cluster configuration
consul
1. Download the consul service
#解压软件后移动到/usr/local/bin/下
mv consul /usr/local/bin/
#创建数据目录，启动服务
mkdir /var/lib/consul_data
consul agent \
-server \
-bootstrap \
-ui \
-data-dir=/var/lib/consul_data \
-bind=192.168.116.70 \
-client=0.0.0.0 \
-node=consul-server01 &> /var/log/consul.log &
Common Startup Options
| options | effect |
|---|---|
| -server | Start as server. The default is client. |
| -bootstrap | It is used to control whether a server is in bootstrap mode. There can only be one server in bootstrap mode in a data center. When a server is in bootstrap mode, it can be elected as the server-leader by itself. |
| -bootstrap-expect=2 | The minimum number of servers required by the cluster, when it is lower than this number, the cluster will fail. |
| -ui | Specify to enable the UI interface, so that you can access the web UI interface that comes with consul through an address such as http://localhost:8500/ui. |
| -data-dir | Specifies the data storage directory. |
| -bind | Specify the communication address used within the cluster. All nodes in the cluster must be reachable to this address. The default is 0.0.0.0. |
| -client | Specify which client address consul is bound to. This address provides services such as HTTP, DNS, and RPC. The default is 127.0.0.1. |
| -node | The name of the node in the cluster must be unique in a cluster, and the default is the host name of the node. |
| -datacenter | Specify the data center name, the default is dc1. |
After starting consul, it will listen to 5 ports
8300 by default: port
8301 for replication and leader farwarding : port
8302 for lan cossip : port 8500 for wan gossip
: port 8600 for the web ui interface
: port for viewing node information using the dns protocol
2. The web server starts multiple nginx containers and uses the registrator to automatically discover them
Start multiple nginx containers
Install auto-discovery using registrator
docker run -d \
--name=registrator \
--net=host \
-v /var/run/docker.sock:/tmp/docker.sock \
--restart=always \
gliderlabs/registrator:latest \
--ip=192.168.116.60 \
consul://192.168.116.70:8500
Common options
| options | effect |
|---|---|
| --net=host | Set the running docker container to host network mode. |
| -v /var/run/docker.sock:/tmp/docker.sock | Mount the Unix domain socket that the host's Docker daemon (Docker daemon) listens to by default into the container. |
| --restart=always | Set to always restart the container when the container exits. |
| --ip=host ip | The network has just been specified as the host mode, so we specify the ip as the host's ip. |
| consul://consul server ip: port | If it is not deployed on the consul server, the IP and port of the consul server must be specified. |
Front-end inspection has been found
3. Use nginx as a reverse proxy, and use Consul-template configuration to automatically modify the configuration file
First download and start the nginx service
#配置nginx官方源，下载并开启
vim /etc/yum.repos.d/nginx.repo
[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1
yum install nginx -y
systemctl enable --now nginxDownload consul-template
(1) Layer 4 proxy configuration
The nginx installed by yum has two configuration files, /etc/nginx/nginx.conf contains the configuration of the global configuration, events block and http block, and /etc/nginx/conf.d/default.conf contains the configuration of the server block.
Because the four-layer proxy is done in the global configuration, it is referenced in the nginx global configuration
Then write the template template file to generate and automatically modify the nginx configuration file referenced in the previous step
#模板文件以ctmpl结尾！
vim nginx.ctmpl
stream {
upstream nginx_backend {
#获取consul的nginx服务范围
{
{range service "nginx"}}
server {
{.Address}}:{
{.Port}};
{
{end}}
}
server {
listen 9090;
proxy_pass nginx_backend;
}
}
Use the template file to enable the template (start in the foreground, add & in the background)
consul-template --consul-addr 192.168.116.70:8500 \
--template "/opt/consul/nginx.ctmpl:/etc/nginx/template/stream.conf:/usr/sbin/nginx -s reload" \
--log-level=info
Open another terminal to log in to view, the configuration file is automatically modified successfully
Add a page, visit the test to see if it is polled
The polling is correct and the access test is successful
(2) Layer-7 proxy configuration
Write template files
vim nginx2.ctmpl
upstream nginx_backend {
#获取consul的nginx服务范围
{
{range service "nginx"}}
server {
{.Address}}:{
{.Port}};
{
{end}}
}
server {
listen 9090;
location / {
root /usr/share/nginx/html;
index index.html;
proxy_pass http://nginx_backend;
proxy_set_header HOST $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Client-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Note: You also need to annotate the location / {} configuration in /etc/nginx/conf.d/default.conf, otherwise it will conflict with the newly generated location / {} configuration.
Start the service and access the test
Note: The configuration of the seven-layer proxy is in the http module, so the configuration file generated here should be under /etc/nginx/conf.d/
4. Add docker-consul node
Download the consul service first like the node
Then enable the consul node and join the first cluster
consul agent \
-server \
-ui \
-data-dir=/var/lib/consul-data \
-bind=192.168.116.60 \
-client=0.0.0.0 \
-node=consul-server02 \
-enable-script-checks=true \
-datacenter=dc1 \
-join 192.168.116.70 &> /var/log/consul.log &| Supplementary options | effect |
| -enable-script-checks=true | Set check service to available |
| -join | Join an existing cluster |
5. View consul cluster information
consul members
consul operator raft list-peers
