Preface: Due to my curiosity about Nginx, I decided to set my personal learning theme as the introduction to Nginx. Learning content is about learning geek time, “Nginx Core Knowledge 100 lectures” produced by Teacher Tao Hui. Then cooperate with their business scene in a few actual combat, some experience to share with you here. In the article, many screenshots are directly cut from the PPT part of the teacher in the course for sorting (infringement is deleted, I will draw another picture). Note that this is teaching a completely ignorant person how to get started. If you already know, you can just close the exit, don’t waste time
Get started with Nginx
Custom builds build Nginx
Generally speaking, if there are no special needs. Nginx builds can be installed and started directly by relying on yum install Nginx or brew install Nginx. But when you need to add modules, add features that are not compiled into Nginx by default, hot updates, and so on, you’ll need to learn to build custom builds again. In addition, custom builds are not as difficult as you might think, and are easy to learn later, so my advice is to learn this simple custom build method.
Get the compilation source file
Open the Nginx website and go to the Download TAB to Download the binary file. Download directly, or use the wget file path to download. Generally for the sake of safety, you can directly choose the Mainline version
Start compiling and installing
Decompress the downloaded package tar -xzvf nginx-1.15.12.tar.gz. When you’re done, you’ll see a directory of files like this.
Generally speaking, we don’t need to care about the contents of this list, but those who are interested can learn a little bit about it and use it as we move forward.
Nginx 1.15.12 / ├ ─ ─ auto | ├ ─ ─ cc used to compile | ├ ─ ─ lib | ├ ─ ─ the judgment of the OS operating system | ├ ─ ─... The rest of the content is to support the config file to determine whether nginx supports features, modules, etc. Can use `. / configure -- help ` view support parameter ├ ─ ─ contrib offers two. Pl and vim script tools | ├ ─ ─ vim can perform ` cp -r contrib/vim / * ~ / vim / ` in support of vim nginx syntax ├ ─ ─ HTML provides two standard HTML | ├ ─ ─ 50 x) HTML 500 error when the display file | ├ ─ ─ index. The HTML welcome screen ├ ─ ─ man Linux file for nginx help ├ ─ ─ the SRC nginx source code ├ ─ ─ Objs configure compiler generated when the intermediate file | ├ ─ ─ ngx_modules. C (make) determines the compile time, will be compiled into nginx module. What module can be used to view the nginx were compiled into | ├ ─ ─ nginx | ├ ─ ─ the SRC ` voice ` C compiler generated when all documents | ├ ─ ─ so if using the dynamic module fileCopy the code
We usually rely on the instructions provided by the configure file to compile, which is very simple. Run./configure –help to see what parameters are executed and customize the build mode. For example, I can’t install nginx to the default directory /etc/nginx/… At this point, I need to customize the directory where the compilation and installation will take place
The ngx_modules.c file is a quick way to see the features that nginx supports. If no more errors are reported, you are ready to execute make and make install. If an error occurs, it is generally easy to find the corresponding solution from the major search engines.
After compiling, our operation is more in the compilation of the installation of the same Nginx. You can also see that the directory structure of the file is similar to that of yum install. The directory structure should be slightly different if you use yum install directly.
I don’t have access to most of the folders, but here are a few key ones:
sbin
: holds Nginx command line commands. Can be executed inside the file soft link or directly through. / sbin/nginx + instructions
performlogs
: Stores log files as the name impliesconf
: Nginx configuration folder, which tells Nginx how to work through the configuration (our main working directory)
Generally after the execution here,./sbin/nginx -s can start nginx began to play happily.
Nginx configuration syntax
I don’t know if MY understanding is incorrect, the implementation of Nginx is actually using the method instructions provided by each module to guide the work of Nginx, so it is essential to learn the basic configuration syntax. The syntax diagram is directly posted here. You can see the actual syntax file and the comments for each arrow to get an idea of what a configuration file consists of, without going into details.
1998176F-2824-48C7-8913-F644B924D6DF.png
Nginx instructions
The instructions section is also very simple and is usually used to stop, restart, and so on.
- Format:
nginx -s reolad
- Help:
-? Or - h
- Using the specified configuration file:
-c
- Specify a configuration directive:
-g
Overrides configuration items in the configuration file - Specify a run directory:
-p
Also overrides the run directory in the configuration file - Send a signal:
-s
- Stop service immediately:
stop
; - Gracefully stop service:
quit
; - Overloading configuration files:
reload
; Change the value in the configuration file to take effect (without stopping service) - Restart log files:
reopen
;
- Stop service immediately:
- Test the configuration file for syntax errors:
- t or -t
- Print nGINx version information, compile information, etc.
V or -- v
Nginx documentation basic reading and searching methods
The idea running through the whole paper is that the early learning process of Nginx is to learn its configuration. So the first thing is to understand what functionality Nginx provides and how to use it properly and legally.
My general thinking goes something like this: First, open your favorite search engine.
image-20190508202107944-7318067.png
In general, if your request is common, you will find it in the top tutorial articles.
Of course, at the same time, I will find the module introduction in the Nginx official document to read more scientific instructions according to my own needs. The introduction of each module will include the following three aspects:
- Example Configuration Example
- Description of all Directives
- The Variables provided by the Embedded Variables module
Among them, we focus on how to read the instruction document
image-20190508202738735.png
Each section is labeled with the directive name and supported parameters and default values. The rest of the content describes what this directive does. When we are in doubt about the use or efficacy of this instruction, we can find a perfect reading here (after all, other tutorials may omit a lot of details after being digested).
Ps: the official website sometimes can also find some of the more common configuration tutorial (such as how to configure websocket and so on, very worth reading)
Nginx Knows how to debug logs
When I was learning Nginx, I was often troubled by the fact that THERE was no way to interrupt points and add console. Log like JS. Until I found a way to enable debug logging, My mom didn’t have to worry that I didn’t know where I was wrong with the configuration.
A Debugging log is an example of how to enable Debugging
The enable method is back to the custom build we mentioned above, adding a line at compile time and enabling debug mode
./configure --with-debug
Copy the code
Then, once the build installation has been performed, configure where you want the error log to be printed.
error_log /path/to/log debug
Copy the code
It will take effect after you restart nginx. Of course, there is actually a more detailed explanation in the official website, it is recommended to read the corresponding article for further understanding.
Important points to know
After mastering the above basic knowledge, you have basically had the basic ability to configure Nginx. Based on the following path, 50% of the requirements can be easily solved (my personal feeling).
However, there are a number of pitfalls in Nginx configuration, or a few very important things that can make you miserable during configuration if you don’t understand them. Below, a knowledge point, of course, if you directly buy the course to listen to Teacher Tao Hui, it must be a lot of in-depth. Here, I just from their own point of view to measure the importance of knowledge points. Let’s go!!!!!
Instruction merge and inheritance
Merge of instructions
Nginx instruction can be divided into: value instruction and action instruction
- Value directive: Stores the values of configuration items, which can be merged. Such as:
root
,gizp
- Action class instruction: specifies behavior. Cannot be combined. Such as:
rewrite
,proxy_pass
Inheritance of instructions
- If the child configuration does not exist, the parent configuration block is used
- If the child configuration exists, the parent configuration block is overwritten
Server matching order
When multiple server configuration blocks are configured and the matching logic is complex, it is highly likely that a request will hit multiple server blocks at the same time. You need to determine which server block to enter for execution by referring to the priority order.
- An exact match
- * In the previous generic domain name
- * Later generic domain name
- Matches regular expression domain names in the order in the file
- default server
- The first one
- Listen to specify default
Location directive [Location [= | | | ~ ~ * ^ ~] uri {…} or Location @ name {…}]
Location directive to master the content of the Server is basically the same, but also the problem of matching order. One small detail worth noting though is that Location only matches the URI, ignoring the parameters.
image-20190509105518688-7370518.png
The evil If command
When an if block appears in succession, the last true if block affects all subsequent processing. It is often misleading not to use continuous if, especially if the continuous is true.
The cause of a mistake
- If directives are executed in the rewrite phase
- The configuration in the if {} block replaces the configuration of the current request when the if condition is true.
- If {} also inherits the parent configuration upward
- When the rewrite interface executes sequentially, the configuration of the current request is replaced every time if is true
- Configuration in if {} affects subsequent phases of the rewrite interface.
location /only-one-if {
set $true1; / / not to take effectif ($true) { add_headder X-First 1; } // The valid moduleif ($true) {
add_header X-Second 2;
}
return 204;
}
Copy the code
Therefore, the if block should ensure that the request can be handled correctly, and it does not depend on the instructions outside the if {} block. Of course, you can also use break to block instruction execution in subsequent rewrite phases.
The Rewrite module: The difference between Return and Rewrite
The return instructions
The Nginx command stops processing and directly returns redirection to the client. The return directive is concise and efficient. In contrast, the use of return takes precedence over the use of rewrite.
Rewrite instructions
Rewrite rules change urls in part or all of a user’s requests for two main purposes:
- Instruction similar to return, by returning directly
http://
. - Control the Nginx processing flow
In the rewrite directive, there is a falg flag bit, but there are two important ones:
-
Last: Stops processing the current ngX_HTTP_rewrite_module directive set and starts searching for a new location that matches the changed URI (through the server again). Ngx_http_rewrite_module override module directives are no longer processed for the current server or location context.
-
Break: Stop processing the current ngX_http_rewrite_module directive set
Last and break:
- After last rewrites the URL, the matching process is repeated from the server, while break terminates the rewritten match
- Both break and last prevent subsequent rewrite directives from being executed again
variable
The Nginx variables have a lot of uses, but there are two very simple things you need to know when using them.
- Lazy evaluation of variables. This is a familiar concept, that variables are only used at the moment of execution, “the method that resolves the variable”. This is equivalent to a way to improve performance.
- The value of a variable can change from time to time, and its value is an effect of using the value at that moment — the lazy evaluation of the variable. That is, the name of the variable is defined at Nginx startup, but if you use the variable at the stage before you can get the value, you will obviously only get a null value. Or if the variable is changed in a subsequent phase, it will not respond to the previous execution step.
A deeper understanding of variable changes requires a deeper understanding of Nginx’s operating mechanism and execution steps.
practice
Single-domain name reverse proxy supports multiple sets of application services
Requirement scenario: Only a single domain name is provided, and the domain name needs to be reversed to specific application services based on the path prefix.
Difficult points:
- Routing the reverse proxy is very simple. The difficulty is that the application service is not aware that it is being reversely proxy and will use A URI path like this when fetching resource content or making API requests:
www.myapp.com/public/xxxxx
orwww.myapp.com/api/xxxx/.
For such a common request, it may be used on every set of services, and we are not easy to retrieve its source request location (do not want to change the application layer code).
Implementation ideas:
- For the newly entered service, the location will be matched. In the corresponding location directive block, we set the corresponding service cookie value — identifying the request’s target source application. The value of the cookie can be set in the location. If the cookie is not redefined, then the reverse proxy service in the cookie is used.
- As a single page application if used
history
Mode, single-page path hops may override paths (not via Nginx). Therefore, Nginx has no time to rewrite its request URL. When refreshing the page, in order to facilitate developers to view the current system, it needs to be used at all timesrewrite
Directive to rewrite the contents of the URL.
nginx.png
Just look at the code
http {
# Avoid timeout related operations
fastcgi_connect_timeout 3600;
fastcgi_send_timeout 3600;
fastcgi_read_timeout 3600;
proxy_connect_timeout 3600;
proxy_send_timeout 3600;
proxy_read_timeout 3600;
upstream see_test {
server 127.0.0.1:9501;
}
upstream see_poc_fjnx {
server 127.0.0.1:9502;
}
server {
listen 8890 default_server;
server_name www.myapp.com;
if ($http_cookie ~* "prefix_url=see_poc_fjnx") {
set $group see_poc_fjnx;
}
if ($http_cookie ~* "prefix_url=see_test") {
set $group see_test;
}
location /public {
proxy_pass http://$group;
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
}
location /api {
proxy_pass http://$group;
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
}
location /poc/fjnx/ {
proxy_set_header HOST $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://see_poc_fjnx/;
proxy_redirect / http://http://www.myapp.com/poc/fjnx/;
userid on;
userid_name prefix_url=see_poc_fjnx;
userid_mark =;
userid_service 1;
}
location / {
if ($group = see_poc_fjnx) {
rewrite^ / +) (. http://www.myapp.com/poc/fjnx/The $1 last;
}
proxy_set_header HOST $host;
proxy_set_header X-Real_IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://see_test/;
proxy_redirect / http://www.myapp.com/;
userid on;
userid_name prefix_url=see_test;
userid_mark =;
userid_service 1; }}}Copy the code
Follow-up: In fact, the logic of the whole article is fragmented and scattered, which is not applicable to students who have a certain understanding of Nginx. At the same time, if you have some practical experience and want to learn more about Nginx, geek Time course is recommended.
Reference documentation
- HTTPS configuration setup