Dynamic upstreams of Nginx

Dynamic upstreams of Nginx

I recently made a configuration in my work. I have a user-oriented Nginx service that forwards access to the server running on AWS Elastic Load Balancer (as you know. A service on ELB. This does not seem to be a difficult task. You just need to find the ELB host name and point Nginx to it. That's not enough, right?

location / {    proxy_pass http://service-1234567890.us-east-1.elb.amazonaws.com;}

There is no problem in the test. Set the Firewall/security group configuration correctly so that it can work well. After a few hours, you may find that the service is no longer working, although it has not changed. Direct access to ELB endpoints can work, but access to Nginx always times out.

ELB enlightenment

To find out why the service suddenly stops, you need to first understand how ELB works:

When you create an Elastic Load balancing (Elastic Load Balancer), you will get a DNS return record, and AWS will tell you all the access services in use. A dns record is a round robin DNS record that points to two or more IP addresses-depending on how many available regions you have. DNS records are set to time to live, which means there is almost no record cache.

Short TTL allows AWS to quickly change the Running Load of machines without interrupting services. This is why they specifically tell you not to find the host name and the IP address that sends traffic to it. In this case, your service may be undefined at a certain time in the future, the IP address may stop working for Server Load balancer.

Return to Nginx

The problem is that for Nginx, when it reads a configuration, it will immediately request the host name from DNS and then use the result until the configuration is re-loaded next time. Before this period of time, ELB may change the IP address so that your Nginx can forward requests to addresses that are not serving you.

Nginx Plus

The solution to this problem is to pay for Nginx Plus, which adds the resolve tag to indicate the servers on the upstream group. That is to say, the DNS is proud of Nginx's TTL record, and occasionally reprocesses the record in order, and obtains the update list used by the server.

$1.500 per server per year for this function, it looks like a lot of money. Of course, this is what you want to get other features from Nginx Plus. If you don't need them, it will be an expensive upgrade.

Free options

A more affordable option is to write such a Configuration:

resolver  172.16 . 0.23 ; set $upstream_endpoint http: //service-1234567890.us-east-1.elb.amazonaws.com; location / {     proxy_pass $upstream_endpoint; }

It will take effect and Nginx will follow the TTL record of the DNS record. In case a request comes in, it will be re-interpreted and the cached record will expire. Why?

The answer can be found at the end of the proxy_pass command document. It declares:

The server name, port, and transmitted URI can also be specified using variables:
proxy_pass http://$host$uri;
Even like this:
proxy_pass $request;
In this case, the server name will be searched in the server groups described. If the server name cannot be found, it will be determined by resolver.

When we provide a variable for proxy_pass, we basically use it to change the behavior, but we do need to specify a DNS resolver in the configuration. The DNS resolver used in this example should be able to run on all servers in the default VPC or EC2 on AWS (applicable ). You can also view/etc/resolv. conf at any time to find out which AWS provides and uses which DNS servers for your servers.

About the forward URI's Caveat (warning)

If the Location you set in Nginx is not just/, You need to note that when a variable is given as a parameter, proxy_pass slightly changes the behavior.

First, let's explain how proxy_pass works in normal operations:

Normal Behavior

Suppose we have an Nginx configuration that includes the following:

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

When we send a/foo/bar/baz request to this site, Nginx will forward the request to http: // 127.0.0.1: 8000/foo/bar/baz.

location /foo/ {    # Note the trailing slash       ↓    proxy_pass http://127.0.0.1:8080/;}

Nginx removes some specified Uris from the Location record, and then transmits the remaining parts to the upstream server. Therefore, the request/foo/bar/baz will be forwarded to http: // 127.0.0.1: 8080/bar/baz.

Change Behavior

When we use a variable as the proxy_pass parameter, the above behavior with a tail slash will change. For example, we have such a configuration.

resolver 172.16.0.23; set  $upstream_endpoint http: //service-1234567890 .us-east-1.elb.amazonaws.com/; location  /foo/  {     proxy_pass $upstream_endpoint; }

When we send the/foo/bar/baz request to that configuration, the forwarding request will not go to/and is not the expected/bar/baz.

To solve this problem, remove the tail slash from the endpoint of upstream and manually rewrite it like this:

resolver 172.16.0.23; set  $upstream_endpoint http: //service-1234567890 .us-east-1.elb.amazonaws.com; location  /foo/  {     rewrite ^ /foo/ (.*) /$1  break ;     proxy_pass $upstream_endpoint; }

Then, when you send the/foo/bar/baz request, upstream will receive the/bar/baz request we want.

Conclusion

You need to know that this is not only applicable to setting elb as the upstream server, but also to configuring all the DNS configurations for modifying the upstream server in nginx.

I hope this will be useful to you. If you have any suggestions or just want to contact me, use twitter to contact Tenzer.

For more Nginx tutorials, see the following:

Deployment of Nginx + MySQL + PHP in CentOS 6.2

Build a WEB server using Nginx

Build a Web server based on Linux6.3 + Nginx1.2 + PHP5 + MySQL5.5

Performance Tuning for Nginx in CentOS 6.3

Configure Nginx to load the ngx_pagespeed module in CentOS 6.3

Install and configure Nginx + Pcre + php-fpm in CentOS 6.4

Nginx installation and configuration instructions

Nginx log filtering using ngx_log_if does not record specific logs

Nginx details: click here
Nginx: click here

Nginx with dynamic upstreams

This article permanently updates the link address: