🥇Kubernetes ٽوٽڪا ۽ ترڪيبون: NGINX Ingress ۾ ذاتي غلطي جا صفحا

هن آرٽيڪل ۾، مان NGINX Ingress جي ٻن خاصيتن بابت ڳالهائڻ چاهيان ٿو جيڪي ذاتي ٿيل غلطي صفحن کي ظاهر ڪرڻ سان لاڳاپيل آهن، انهي سان گڏ انهن ۾ موجود حدون ۽ انهن جي چوڌاري ڪم ڪرڻ جا طريقا.

1. ڊفالٽ پس منظر کي تبديل ڪرڻ

ڊفالٽ طور، NGINX Ingress ڊفالٽ پس منظر استعمال ڪري ٿو، جيڪو لاڳاپيل فنڪشن انجام ڏئي ٿو. ان جو مطلب اهو ٿيو ته جڏهن هڪ Ingress جي درخواست ڪئي وڃي هڪ ميزبان جي وضاحت ڪندي جيڪا Ingress وسيلن ۾ نه آهي، اسان کي هيٺ ڏنل صفحو 404 جوابي ڪوڊ سان ملي ٿو:

جڏهن ته، گهڻو ڪري اسان جا گراهڪ هڪ گذارش سان ايندا آهن ته انهن جو صفحو هڪ ڪارپوريٽ لوگو ۽ ٻين سهولتن سان ڏيکاريو معياري 404 بدران. هن کي ڪرڻ لاء، NGINX Ingress آهي تعمير ٿيل صلاحيت ٻيهر وضاحت ڪرڻ default-backend-service. اسان ساڳي نالي جي اختيار کي دليل طور فارميٽ داخل ڪريون ٿا namespace/servicename. خدمت جو پورٽ 80 هجڻ گهرجي.

هن کي ڪرڻ لاءِ، توهان کي پنهنجو پوڊ ٺاهڻو پوندو (تعيناتي) ۽ خدمت توهان جي ايپليڪيشن سان (مثال طور YAML ۾ عمل درآمد ingress-nginx repository کان)، جيڪو ڊفالٽ پس منظر جي بدران ڏنو ويندو.

هتي هڪ ننڍڙو مثال آهي:

~$ curl -i -XGET http://sadsdasdas.kube-cloud.my/
HTTP/1.1 404 Not Found
Date: Mon, 11 Mar 2019 05:38:15 GMT
Content-Type: */*
Transfer-Encoding: chunked
Connection: keep-alive

<span>The page you're looking for could not be found.</span>

تنهن ڪري سڀئي ڊومين جيڪي واضح طور تي YAML ذريعي نه ٺاهيا ويا آهن kind: Ingress, default-backend ۾. مٿي ڏنل لسٽ ۾، هي ڊومين بڻجي ويو sadsdasdas.

2. ڊفالٽ پس منظر استعمال ڪندي ايپليڪيشن ۾ HTTP غلطيون سنڀالڻ

ٻي صورتحال HTTP غلطين (404, 500, 502...) ۾ ختم ٿيڻ واري درخواستن جي درخواست آهي جيڪا اهڙين حالتن تي عمل نه ڪندي آهي (ساڳئي خوبصورت صفحا ٺاهيل نه آهن). اهو پڻ ٿي سگهي ٿو ڊولپرز جي خواهش جي ڪري ڪيترن ئي ايپليڪيشنن ۾ ساڳئي غلطي صفحن جي خدمت ڪرڻ لاء.

هن ڪيس کي سرور جي پاسي تي لاڳو ڪرڻ لاء اسان کي ضرورت آهي:

پيراگراف کان مٿي ڏنل هدايتن تي عمل ڪريو ڊفالٽ پس منظر بابت؛
nginx-ingress configuration ConfigMap ڏانهن هڪ ڪنجي شامل ڪريو custom-http-errorsمثال طور، قدر سان 404,503 (ظاهر آهي ته غلطي ڪوڊ سان ملن ٿا جيڪي نئين قاعدي سان ڍڪيل آهن).

متوقع نتيجو حاصل ڪيو ويو آهي: جڏهن ڪلائنٽ ايپليڪيشن هلائي رهي آهي ۽ 404 يا 503 جي جوابي ڪوڊ سان هڪ غلطي وصول ڪري ٿي، درخواست خودڪار طريقي سان نئين ڊفالٽ پس منظر ڏانهن منتقل ڪيو ويندو ...

تنهن هوندي، جڏهن ڊفالٽ پس منظر ۽ ڪسٽم-http-نقصن لاءِ ايپليڪيشن ٺاهي رهيا آهيو، توهان کي هڪ اهم خصوصيت جو خيال رکڻو پوندو:

!!! Important The custom backend is expected to return the correct HTTP status code instead of 200. NGINX does not change the response from the custom default backend.

حقيقت اها آهي ته جڏهن هڪ درخواست کي ريڊائريڪٽ ڪيو ويندو آهي، هيڊر اڳئين جوابي ڪوڊ ۽ اضافي معلومات سان گڏ مفيد معلومات تي مشتمل هوندي (انهن جي مڪمل فهرست موجود آهي. هتي).

هن جو مطلب آهي ته توهان پاڻ کي گهرجي صحيح جوابي ڪوڊ جو خيال رکجو. هتي هڪ مثال آهي دستاويزن مان اهو ڪيئن ڪم ڪري ٿو.

مختلف ايپليڪيشنن ۾ مختلف ڊفالٽ پس منظر آهن

انهي ڳالهه کي يقيني بڻائڻ لاءِ ته حل پوري ڪلستر لاءِ عالمي نه آهي، پر صرف مخصوص ايپليڪيشنن تي لاڳو ٿئي ٿو، توهان کي پهريان انگريس ورزن کي چيڪ ڪرڻ جي ضرورت آهي. جيڪڏهن اهو ملندو 0.23 يا وڌيڪ, اصلي Ingress تشريح استعمال ڪريو:

اسان مٿي ڪري سگهون ٿا default-backend لاء هر هڪ جو داخل ٿيڻ تشريح استعمال ڪندي;
اسان مٿي ڪري سگهون ٿا custom-http-errors لاء هر هڪ جو داخل ٿيڻ تشريح استعمال ڪندي.

نتيجي طور، Ingress وسيلو ڪجهه هن طرح نظر ايندو:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: {{ .Chart.Name }}-app2
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/custom-http-errors: "404,502"
    nginx.ingress.kubernetes.io/default-backend: error-pages
spec:
  tls:
  - hosts:
    - app2.example.com
    secretName: wildcard-tls
  rules:
  - host: app2.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: {{ .Chart.Name }}-app2
          servicePort: 80

انهي صورت ۾، غلطيون 404 ۽ 502 سڀني ضروري سرن سان غلطي-صفحي جي خدمت ڏانهن موڪليا ويندا.

В Ingress جي پوئين ورزن ۾ اها خصوصيت نه هئي (0.23 تي قسمت جو ڪم). ۽ جيڪڏهن توهان وٽ 2 مڪمل طور تي مختلف ايپليڪيشنون آهن جيڪي توهان جي ڪلستر ۾ هلن ٿيون ۽ توهان انهن مان هر هڪ لاءِ مختلف ڊفالٽ-بيڪ اينڊ-سروس ۽ پروسيسنگ جي مختلف ايرر ڪوڊ جي وضاحت ڪرڻ چاهيو ٿا، ان لاءِ توهان کي ڪم ڪارناما استعمال ڪرڻا پوندا، جن مان اسان وٽ ٻه آهن.

داخل ٿيڻ <0.23: هڪ نقطو

هي اختيار وڌيڪ آسان آهي. هڪ ايپليڪيشن جي طور تي جيڪو ان جي صفحن کي خدمت ڪري ٿو، اسان وٽ باقاعده HTML آهي، جنهن کي خبر ناهي ته هيڊر ڪيئن ڏسڻ ۽ درست جوابي ڪوڊ واپس ڪرڻ. اهڙي ايپليڪيشن کي url مان Ingress سان گڏ ڪيو ويو آهي /error-pages، ۽ فهرست ۾ ws واپسي وارو HTML هوندو.

YAML ۾ مثال:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: {{ .Chart.Name }}-app2
  annotations:
    kubernetes.io/ingress.class: "nginx"
    ingress.kubernetes.io/server-snippet: |
      proxy_intercept_errors on;
      error_page 500 501 502 503 504 @error_pages;
      location @error_pages {
        rewrite ^ /error-pages/other/index.html break;
        proxy_pass http://error-pages.prod.svc.cluster.local;
      }
spec:
  tls:
  - hosts:
    - app2.example.com
    secretName: wildcard-tls
  rules:
  - host: app2.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: {{ .Chart.Name }}-app2
          servicePort: 80

ھن ڊيپلائيمينٽ لاءِ خدمت لازمي آھي ڪلستر آءِ پي قسم جي.

ساڳئي وقت، ايپليڪيشن ۾ جتي اسان غلطي تي عمل ڪنداسين، Ingress ۾ اسان سرور-snippet يا ترتيب-snippet شامل ڪندا آهيون هيٺين مواد سان:

nginx.ingress.kubernetes.io    /server-snippet: |
      proxy_intercept_errors on;
      error_page 500 501 502 503 504 @error_pages;
      location @error_pages {
        rewrite ^ /error-pages/ws/index.html break;
        proxy_pass http://error-pages.prod.svc.cluster.local;
      }

داخل ٿيڻ <0.23: ٻيو طريقو

ايپليڪيشن لاءِ هڪ آپشن جيڪو هيڊرز کي پروسيس ڪري سگهي ٿو... ۽ عام طور تي هي هڪ وڌيڪ صحيح طريقو آهي، ڪسٽم-http- غلطين مان قرض ورتو ويو آهي. ان کي دستي طور استعمال ڪندي (ڪاپي ڪرڻ) توهان کي اجازت ڏيندو ته توهان عالمي سيٽنگون تبديل نه ڪندا.

مرحلا هن ريت آهن. اسان ٺاهيندا آهيون ساڳي تعیناتي هڪ ايپليڪيشن سان جيڪو ضروري عنوانن کي ٻڌي ۽ صحيح جواب ڏئي سگهي ٿو. ھيٺ ڏنل مواد سان گڏ داخل ٿيڻ واري ايپليڪيشن ۾ سرور-اسنيپٽ شامل ڪريو:

nginx.ingress.kubernetes.io    /server-snippet: |
      proxy_intercept_errors off;
      error_page 404 = @custom_404;
      error_page 503 = @custom_503;
      location @custom_404 {
        internal;
        proxy_intercept_errors off;
        proxy_set_header       X-Code             404;
        proxy_set_header       X-Format           $http_accept;
        proxy_set_header       X-Original-URI     $request_uri;
        proxy_set_header       X-Namespace        $namespace;
        proxy_set_header       X-Ingress-Name     $ingress_name;
        proxy_set_header       X-Service-Name     $service_name;
        proxy_set_header       X-Service-Port     $service_port;
        proxy_set_header       Host               $best_http_host;
        rewrite ^ /error-pages/ws/index.html break;
        proxy_pass http://error-pages.prod.svc.cluster.local;
      }
      location @custom_503 {
        internal;
        proxy_intercept_errors off;
        proxy_set_header       X-Code             503;
        proxy_set_header       X-Format           $http_accept;
        proxy_set_header       X-Original-URI     $request_uri;
        proxy_set_header       X-Namespace        $namespace;
        proxy_set_header       X-Ingress-Name     $ingress_name;
        proxy_set_header       X-Service-Name     $service_name;
        proxy_set_header       X-Service-Port     $service_port;
        proxy_set_header       Host               $best_http_host;
        rewrite ^ /error-pages/ws/index.html break;
        proxy_pass http://error-pages.prod.svc.cluster.local;
      }

جئين توهان ڏسي سگهو ٿا، هر هڪ غلطي لاء جيڪو اسان پروسيس ڪرڻ چاهيون ٿا، اسان کي پنهنجي جڳهه ٺاهڻ جي ضرورت آهي، جتي سڀئي ضروري هيڊر داخل ڪيا ويندا، جيئن "مقامي" ۾. حسب ضرورت-غلطي-صفحا. هن طريقي سان اسان ٺاهي سگهون ٿا مختلف ذاتي ٿيل غلطي صفحا جيتوڻيڪ انفرادي جڳهن ۽ سرورن لاءِ.

پي ايس

ٻيا K8s ٽوٽڪا ۽ چالون سيريز مان:

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

ڪبرنيٽس ٽوٽڪا ۽ ترڪيبون: NGINX Ingress ۾ ڪسٽم ايرر صفحا