Complete steps for deploying a front-end and back-end separated nginx configuration

Preface

It's a cliché. Here I will talk about my understanding of front-end and back-end separation. Simple separation is nothing more than stripping out the original mvc view layer and making it an independent Servlet service. The Servlets are connected by http. The view Servlet container here can be any server-side service, such as Tomcat, Apache, Nginx, or IIS. Here we take the commonly used Nginx as an example to give a brief introduction.

Demand Analysis

Let’s start with a demand analysis.

• Single Project
  • A single project means that a front-end service is deployed on a server, making www.xxx.com => index.html a single point.
• Multiple Projects
  • Multi-project means that one server is deployed with multiple front-end services, so that www.xxx.com/a => a.html, www.xxx.com/b => b.html and so on can point to multiple sites.
• Request an agent.
• Cookie domain rewrite.
• Cookie path override.

Tip: It is better to write conf.d/*.conf here so that the configuration can be processed separately.

Public Configuration

server{
 listen 80; # Configure port server_name _; # Configure domain name charset utf-8; # Encoding access_log /xxx/log/nginx_access.log main; # Success log error_log /xxx/log/nginx_error.log error; # Error log index index.html; # Search file order set $root /xxx/nginx/; # Variable setting, set public path # Other location
}

Please manually create corresponding files under /xxx/log/nginx_access.log and /xxx/log/nginx_error.log. An error may occur when nginx reload is executed for the first time.

The $root path of set is an absolute path, and access_log and error_log are also absolute paths.

Single project configuration

Directory Structure

nginx
|----- index.html
|----- user.html

Location configuration

location / {
	root $root;
}

Well, the simplest root path-based configuration is just like this. Here, it is nothing more than configuring a path through location and then pointing to the index.html file in the $root folder.

Multi-project configuration

Directory Structure

nginx
|----- a
    |----- index.html
|----- b
    |----- index.html

Multiple location configurations

location ^~ /a {
  alias $root/a;
}

location ^~ /b {
  alias $root/b;
}

location / {
  root $root;
}

The only difference between the copycat projects is the difference between root and alias. Root refers to the absolute matching path of the file, while alias is a relative match. root can be configured in http, server, and location, while alias can only be configured in location. I also added the regular expression ^~. When matching /a or /b, no matter what the location path is, the actual path of the resource must be the path specified by alias. In this way, I can make /a and /b have matching paths and jump to fixed paths. This is very useful in SPA-style front-end projects, because there is actually only one index.html file as the core file (resource files are another matter). In this way, I can always jump to index.html to ensure that when the browser is refreshed manually, it will not search for resources in other paths of the server based on the root path. Then set the root path of spa and /b must match.

Why is there such a demand? The front end is lightweight, and we use this mechanism to save servers and aggregate the same type of business. Just like you want admin.xxxx.com/a => operations management desk, and admin.xxxx.com/b => erp management desk. We just need to cut out the sub-path under the admin domain name. Simple and lightweight.

Request forwarding

location ^~ /api {
  proxy_pass http://api.xxx.com/;
}

This is very simple. I match the /api request with a regular expression and direct the request to http://api.xxx.com through the proxy_pass attribute. You can

Modify cookie domain

Sometimes for security reasons, we will set certain cookie domain attributes, which is not very friendly to nginx forwarding. Of course there is a solution, and it is very simple.

location {
  proxy_cookie_domain <domain of this domain> <domain you want to modify>;
}

Modify the cookie path

When we forward back to the API interface, sometimes the API domain name cannot get the cookie. In addition to the domain, there is also the possibility of the cookie path. Of course the solution is simple

location {
  proxy_cookie_path <path of this domain> <path to be modified>;
}

Subsequent optimization

This is just the simplest example of nginx configuration. There are also configurations such as turning on gzip, cache settings, plug-ins for merging resource requests, setting 50x, 40x pages, judging mobile and PC jumps, etc. Nginx is still very powerful.

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM.