Use Nginx, Consul, Consul Template to build load balancing and service discovery services in Windows environment

The purpose of building load balancing and service discovery services

With the continuous improvement of website business, the performance of a single server becomes more and more difficult to meet the business needs of customers. Therefore, in many cases, it is necessary to use multiple server instances and load balancers to meet business needs.

Nginx

What is Nginx

Nginx is a high-performance web server that can be used alone or in combination with other web servers as a load balancer.

Nginx installation

We can download the latest Windows version zip package from the Nginx official website ( http://nginx.org/) .
After the compressed package is decompressed, the directory structure is as follows:

Nginx configuration

events {
    worker_connections 1024;
}


http {
    upstream backend
    {
        server 127.0.0.1:91 weight=1;
        server 127.0.0.1:92 weight=1;
    }
    server 
    {
        location / {
            proxy_pass http://backend;
        }
    }
}

The upstream part defines load balancing for HTTP requests. When a user sends a request to http://backend, Nginx forwards the request to one of the specified server IP lists. The weight field in the configuration sets the weight of the specified server IP. The higher the weight, the higher the possibility of forwarding.

common problem

Nginx will occupy port 80 by default, which conflicts with IIS, so you need to modify the default port of Nginx in nginx.conf

events {
    worker_connections 1024;
}


http {
    upstream backend
    {
        server 127.0.0.1:92 weight=1;
        server 127.0.0.1:93 weight=1;
    }
    server 
    {
        listen 81;
        server_name localhost;

        location / {
            proxy_pass http://backend;
        }
    }
}

example

The current website has 2 instances deployed in IIS, siteA IP 127.0.0.1:92, siteB IP 127.0.0.1:93.

Both siteA and siteB have only one index.html page.
code show as below:

siteA

<!DOCTYPE html>
<html>
<head>
   <title>Nginx Sample</title>
</head>

<body>
    <h1>This is site A</h1>
</body>
</html>

siteB

<!DOCTYPE html>
<html>
<head>
   <title>Nginx Sample</title>
</head>

<body>
    <h1>This is site B</h1>
</body>
</html>

Nginx server uses port 81. The effect we hope to achieve is that when a user visits http://127.0.0.1:81, Nginx randomly forwards the request to http://127.0.0.1:92 or http://127.0.0.1:93

The effect of the index.html page of siteA website is as follows

The effect of the index.html page of the siteB website is as follows

Implementation steps

a. First we modify the Nginx configuration file

events {
    worker_connections 1024;
}


http {
    upstream 127.0.0.1
    {
        server 127.0.0.1:91 weight=1;
        server 127.0.0.1:92 weight=1;
    }
    server 
    {
        listen 81;
        server_name localhost;

        location / {
            proxy_pass http://127.0.0.1;
        }
    }
}

b. Start NginX at the command line

c. Open the browser, enter http://127.0.0.1:81, press F5 repeatedly to refresh, and the website content switches between siteA and siteB, which means that load balancing has been successfully enabled.

Consul

What is Consul

Consul is a high-performance service registration/service health check component

Consul installation

We can download the corresponding version of the 32-bit or 64-bit program from the official website ( https://www.consul.io/downloads.html ). After downloading, it is an executable file consul.exe

How to start Consul

Use the command consul agent -dev, and consul will be started in development mode ( development mode will not enable persistence, and all configurations will be lost after the program is closed )

Consul service background

After the Consul service is started, we can visit http://localhost:8500 to access the management background of Consul. The interface is as follows.

In this management background, you can view all services and all host nodes registered by Consul.

registration service

After the Consul service is started, we can call some corresponding Api to register the service (relevant Api list https://www.consul.io/api/index.html )

continue with our example

Now we try to register the previous siteA, siteB with Consul.

a. First, let's download a Curl program ( https://curl.haxx.se/ ) to call Api (you can use POSTMAN instead)

b. Create two json files siteA.json, siteB.json. Its content is as follows

siteA.json

{
    "ID":"webA",
    "Name":"web",
    "Tags":[],
    "Address":"127.0.0.1",
    "Port":92,
    "EnableTagOverride":false
}

siteB.json

{
    "ID":"webB",
    "Name":"web",
    "Tags":[],
    "Address":"127.0.0.1",
    "Port":93,
    "EnableTagOverride":false
}

Here Name is the service name, and ID is an instance ID of the service.

c. Use curl to call the registration service Api to register siteA and siteB with Consul
curl --request PUT --data @siteA.json http://localhost:8500/v1/agent/service/register
curl --request PUT --data @siteB.json http://localhost:8500/v1/agent/service/register

d. Go back to the Consul management page, we will find that a service named web will appear in the service list, and this service has 2 instances

If you see the above results, it means that the two Web service instances are registered successfully.

Add service health check

After registering a service with Consul, the first benefit you get is that you can use Consul to perform health checks on each service instance.

Go ahead and modify our instance

a. Close the previously opened Consul service, open a new command line window, and use consul agent -dev to restart a new Consul service

b. In the siteA and siteB website directories, add a healthcheck.html file with the following contents

<html>
<head>
   <title>Nginx Sample</title>
</head>
<body>
    <h1>This is health check page</h1>
</body>
</html>

c. Modify the previous siteA.json and siteB.json
siteA.json

{
    "ID":"webA",
    "Name":"web",
    "Tags":[],
    "Address":"127.0.0.1",
    "Port":92,
    "Checks":[{
        "http":"http://127.0.0.1:92/healthcheck.html",
        "interval":"5s"
    }],
    "EnableTagOverride":false
}

siteB.json

{
    "ID":"webB",
   "Name":"web",
    "Tags":[],
    "Address":"127.0.0.1",
    "Port":93,
    "Checks":[{
        "http":"http://127.0.0.1:93/healthcheck.html",
        "interval":"5s"
    }],
    "EnableTagOverride":false
}

d. Reuse curl to call the registration service Api, and register siteA and siteB with Consul

e. Open the siteA directory and rename healthcheck.html to healthcheck1.html (this operation is equivalent to simulating the crash of the server where siteA is located, and the healthcheck.html file cannot be requested by consul)

f. Go back to the Consul management interface, let's take a look at the result, it will show that the webA check failed

g. Rename healthcheck1.html to healthcheck.html, wait for 5 seconds, return to the consul interface, and webA has returned to the status of passing the test.

Consul Template

What is Consul Template

Consul Template is an extension component of Consul, which can read the service configuration in Consul and generate different configuration files according to the specified template.

So here we can use Consul and Consul Template in combination to dynamically generate Nginx configuration files and automatically restart Nginx.

Install Consul Template

We can download consul-template.exe from the official website ( https://releases.hashicorp.com/consul-template)

Start Consul Template

consul-template -consul-addr 127.0.0.1:8500 -template "./2.tpl:./conf/nginx.conf:nginx -s reload"

The -consul-addrparameter here is the address of the specified consul service, the -templatetemplate used by the specified consul template, the address of the new file generated, and the command executed after the new file is generated.

continue our case

Now we add a new siteC, the ip is 127.0.0.1:94, and there are only two files index.html and healthcheck.html in siteC

a. Create 2.tpl, the content of the file is as follows, the template syntax of consul-template is used here (the corresponding syntax can be viewed at https://github.com/hashicorp/consul-template)

events {
    worker_connections 1024;
}


http {
   upstream 127.0.0.1{
        {{ range service "web" }}
    server {{ .Address }}:{{ .Port }} weight=1;{{ end }} 
    }
    server {
        listen       81;
        server_name  localhost;


        location / {
           proxy_pass http://127.0.0.1;
        }

    }
}

b. consul-template -consul-addr 127.0.0.1:8500 -template "2.tpl:conf/nginx.conf:nginx -s reload"Start consul-template with the command

c. Create siteC.json, use curl to register siteC in consul, the content of siteC.json is as follows

{
    "ID":"webC",
    "Name":"web",
    "Tags":[],
    "Address":"127.0.0.1",
    "Port":94,
    "Checks":[{
        "http":"http://127.0.0.1:94/healthcheck.html",
        "interval":"5s"
    }],
    "EnableTagOverride":false
}

d. Open the browser, enter http://localhost:81, press F5 repeatedly to refresh, you will find that siteC has been added to the Nginx load balancing configuration. d

e. Then we do a test, we rename siteA's healthcheck.html to healthcheck1.html

f. Go back to the page just now and continue to refresh by pressing F5. We will find that only the contents of siteB and siteC are displayed now. This is because siteA has been identified as an unhealthy service by consul, so consul-template regenerates the Nginx configuration file and sets the Erased from the configuration file in siteA and restarted Nginx.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324484407&siteId=291194637