Nginx - we leave for technical work

More recently, an interesting problem has arisen: to implement the closure of access to a website from the outside, for the time of technical work. It seemed to me that this is a fairly common task, the solution of which will interest many.
One of the possible solutions is below.

Given

• Server: Ubuntu 10.04 LTS
• Nginx as front-end

Task

Close access to the website from all external IP-addresses, with the exception of our own (or any other, if desired). It is highly desirable that the following conditions be met:

• The time for "closing" should be minimal (less than a second in idede)
• Each time you can change the Nginx config when working -
• It is also impossible to reboot Nginx during work (neither restart nor reload)

Such harsh conditions are dictated primarily by considerations of ease of use and elegance of the solution. Of course are not mandatory.
')

Decision

1. Actually “Closing”

It was decided to use a trigger file as a switch (for example, /etc/nginx/maintenance.file ). When it appears, Nginx will have to return error code 503 and display the corresponding page. For this, we save somewhere existing config:

cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/default.save

And then we make the following changes (in bold):
server {
listen 80;
server_name example.com;
...
location / {
i f (-f /etc/nginx/maintenance.file) {
return 503;
}
#
...
...
}
...
...
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /etc/nginx/error; #
}
}

Now, if the web server detects the /etc/nginx/maintenance.file file, it will immediately /etc/nginx/maintenance.file 503rd and display the error page. Thus, the "close / open" can be done by creating / deleting a trigger file, respectively.
In this case, the 503rd will be shown to everyone indiscriminately, which contradicts the original conditions. How to get around this - next.

2. To what to show

In order to be able to visually monitor the contents of the website during various manipulations, it is highly desirable that the “Technical work in progress” page is not shown to us. For this, we use the ngx_http_geo_module module. As written in the documentation: "... it creates variables, the values ​​of which depend on the client's IP address." Exactly what you need.

We want the 503rd to appear only if: at the same time both the IP is external and the trigger file exists. The simplest solution that comes to mind is a double condition or two nested IFs. Unfortunately, neither the first nor the second Nginx understands. Therefore it is necessary to do "feint ears." Modifying the config a little more.
geo $maintenance
{
default yes; # -
# IP, 503
127.0.0.1/32 no;
123.45.67.0/24 no;
...
}
server {
listen 80;
server_name example.com;
...
location / {
if (-f /etc/nginx/maintenance.file) {
set $tmp clo;
}
if ($maintenance = yes) {
set $action "${tmp}se";
}
if ($action = close) {
return 503;
}
#
...
...
}
...
...
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /etc/nginx/error; #
}
}

In the location / section there are three conditions that replace the double condition: external IP plus the presence of a trigger file. You should explain a little how it works. The easiest way to do this is by example.
Let a client with an arbitrary external IP request a page. In addition: the file /etc/nginx/maintenance.file already exists.

1. Since the trigger file was created: $tmp = "clo"
2. Aypishnik not from the list of exceptions: $maintenance = "yes"
3. Since $maintenance = "yes" , then: $action = $tmp + "se" = "close"
4. $action = "close" , then there is a return 503

All “alien” see page 503, but for our network one of the conditions is not met and the $ action variable is not full ( $action = "lo" ). As a result, nothing will change for us and we will get to the site.

In order for the modified config to take effect, we restart the web server.

sudo /etc/init.d/nginx restart


The ngx_http_geo_module module has many additional "buns". For example, it is possible to load the list with addresses and values ​​from a separate file. This will allow you to quickly change the exclusion list without changing the Nginx config. For details, I ask in the documentation .

At this setting is over.
Using:

• Close access: touch /etc/nginx/maintenance.file
• Share: rm /etc/nginx/maintenance.file

I really hope that the method outlined above will be useful to someone and will save time.