如何理解nginx rewrite和nginx-ingress rewrite

這篇文章將為大家詳細講解有關如何理解nginx rewrite和nginx-ingress rewrite，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

在nginx的配置里面有個 proxy_pass  指令

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

像這樣的配置，proxy_pass 后面加了uri  /remote， 會將正常請求uri中與location匹配的部分用/remote替換掉，我有個類似的場景是：訪問 aa.xxx.net/gateway/a/b 代理到后端的是類似于訪問 svc-gateway:8080/a/b ，要怎么配置？截掉其中的gateway。首先想到的是用ingress里面的rewrite注解來解決問題。

nginx的rewrite

參考官方文檔 鏈接
ngx_http_rewrite_module模塊使用PCRE正則表達式更改請求URI，返回重定向或者有條件地選擇配置。
break, if, return, rewrite, and set指令按照下面的順序執行:

1. server塊按照順序執行

2. 執行匹配到的location塊內的該模塊指令

3. 循環重定向最多10次

break 指令

停止處理當前的ngx_http_rewrite_module指令集。如果在location內的if指令內包含break，則在location內的其他指令繼續執行。

rewrite指令

Syntax: rewrite regex replacement [flag];
Default:    —
Context:    server, location, if

如果指定的正則匹配請求的uri，uri將被replacement替換。rewrite按照在配置文件里面出現的順序執行。如下示例：

location / {
    rewrite ^/a /b;
    #return 200 okokok;
    rewrite ^/b /c last;
    rewrite ^/d /b;
}
location = /b {
    return 401;
}

location = /c {
    return 402;
}

像上面這種配置，訪問localhost:port/d 會返回401
rewrite 不指定flag，則會繼續往下執行
可以用flags選項終止處理后面的指令。如果replacement以http://、https:// 或$scheme開頭，則請求不會往后執行，redirect將直接返回給客戶端

flag選項

    1、last 停止處理當前 ngx_http_rewrite_module 指令集，且用替換過的uri重新匹配新的location
    2、break 選項和break指令的效果一樣，不再匹配新的location
    3、redirect，replacement不以 'http://' 等開頭的時候，返回臨時重定向302
    4、permanent，返回永久重定向301

完整的重定向url按照請求的scheme和server_name_in_redirect和port_in_redirect 指令格式生成的

nginx-ingress里面的rewrite注解

官方鏈接
示例：

...
    nginx.ingress.kubernetes.io/rewrite-target: /$1
...
spec:
  rules:
  - host: aa.xxx.net
    http:
      paths:
      - backend:
          serviceName: svc-gateway
          servicePort: 8080
        path: /gateway/(.*)
      - backend:
          serviceName: svc-ui
          servicePort: 80
        path: /(.*)
  tls:
  - hosts:
    - aa.xxx.net
    secretName: xxx.net

在版本0.22.0或更高版本中，需要傳遞到重寫路徑的請求URI中的任何子字符串都必須在捕獲組中顯式定義。第一個組用$1 表示，可以作為rewrite-target的參數。
使用了rewrite-target注解后，所有path被強制使用忽略大小寫的正則，類似于nginx配置里面的：

location ~* "^/foo/.*" {
  ...
}

spec.rules.host 字段不像nginx一樣支持范匹配和正則，必須寫完整的域名
為了實現更精確的路徑匹配，ingress-nginx在將路徑作為location塊寫入nginx模板之前，首先按長度對路徑降序排序，長度里面包含正則字符。和nginx一樣，正則模式下先匹配到的location會直接執行，不往下繼續匹配。

擴展閱讀：ingress-path-matching
Understanding Nginx Server and Location Block Selection Algorithms

第二種方式：

...
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/server-snippet: |
      if ($uri ~* "/gateway/.*") {
          rewrite ^/gateway/(.*) /$1 break;
      }
    nginx.ingress.kubernetes.io/use-regex: "true"
...
spec:
  rules:
  - host: aa.xxx.net
    http:
      paths:
      - backend:
          serviceName: svc-gateway
          servicePort: 8080
        path: /gateway(/|$)(.*)
      - backend:
          serviceName: svc-gateway
          servicePort: 8080
        path: /(admin|bg|auth|monitor)
      - backend:
          serviceName: svc-ui
          servicePort: 80
        path: /
  tls:
  - hosts:
    - aa.xxx.net
    secretName: xxx.net

nginx.ingress.kubernetes.io/server-snippet  注解用于在server塊自定義配置，可以寫nginx的配置實現更多需求。每個server塊只能用一次。用此方式實現了類似proxy_pass的需求

關于如何理解nginx rewrite和nginx-ingress rewrite就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。