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، ڈیفالٹ بیک اینڈ میں گریں۔ مندرجہ بالا فہرست میں، یہ ڈومین بن گیا sadsdasdas.

2. پہلے سے طے شدہ بیک اینڈ کا استعمال کرتے ہوئے ایپلیکیشن میں ایچ ٹی ٹی پی کی غلطیوں کو ہینڈل کرنا

دوسری صورت حال HTTP کی غلطیوں (404, 500, 502...) سے ختم ہونے والی درخواستوں کی ہے جو ایسی صورت حال پر کارروائی نہیں کرتی ہے (متعلقہ خوبصورت صفحات تیار نہیں ہوتے ہیں)۔ یہ ڈویلپرز کی خواہش کی وجہ سے بھی ہو سکتا ہے کہ ایک سے زیادہ ایپلی کیشنز میں ایک ہی ایرر پیجز پیش کریں۔

اس کیس کو سرور سائڈ پر لاگو کرنے کے لیے ہمیں ضرورت ہے:

1. پہلے سے طے شدہ پسدید کے بارے میں پیراگراف سے اوپر دی گئی ہدایات پر عمل کریں۔
2. nginx-ingress کنفیگریشن 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.

حقیقت یہ ہے کہ جب کسی درخواست کو ری ڈائریکٹ کیا جاتا ہے تو ہیڈرز میں سابقہ ​​جوابی کوڈ اور اضافی معلومات کے ساتھ مفید معلومات ہوتی ہیں (ان کی مکمل فہرست دستیاب ہے یہاں).

اس کا مطلب یہ ہے کہ آپ کو خود کرنا چاہئے۔ صحیح جوابی کوڈ کا خیال رکھیں. یہاں ایک مثال ہے دستاویزات سے یہ کیسے کام کرتا ہے۔

مختلف ایپلی کیشنز کے مختلف ڈیفالٹ بیک اینڈ ہوتے ہیں۔

اس بات کو یقینی بنانے کے لیے کہ حل پورے کلسٹر کے لیے عالمی نہیں ہے، بلکہ صرف مخصوص ایپلی کیشنز پر لاگو ہوتا ہے، آپ کو پہلے Ingress ورژن کو چیک کرنے کی ضرورت ہے۔ اگر یہ میل کھاتا ہے۔ 0.23 یا اس سے زیادہ، مقامی Ingress تشریحات استعمال کریں:

1. ہم اوور رائڈ کر سکتے ہیں۔ default-backend لیے ہر ایک داخل ہونے کا تشریحات کا استعمال کرتے ہوئے;
2. ہم اوور رائڈ کر سکتے ہیں۔ 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

اس تعیناتی کے لیے سروس ClusterIP قسم کی ہونی چاہیے۔

ایک ہی وقت میں، درخواست میں جہاں ہم غلطی پر کارروائی کریں گے، Ingress میں ہم درج ذیل مواد کے ساتھ سرور-ٹکڑا یا کنفیگریشن-ٹکڑا شامل کرتے ہیں:

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-غلطیوں سے لیا گیا ہے۔ اسے دستی طور پر استعمال کرنا (کاپی کرنا) آپ کو عالمی ترتیبات کو تبدیل کرنے کی اجازت نہیں دے گا۔

اقدامات درج ذیل ہیں۔ ہم تخلیق کرتے ہیں۔ ایک ہی تعیناتی ایک ایسی ایپلی کیشن کے ساتھ جو ضروری سرخیوں کو سن سکے اور صحیح جواب دے سکے۔ درج ذیل مواد کے ساتھ Ingress ایپلی کیشن میں سرور کا ٹکڑا شامل کریں:

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;
      }

جیسا کہ آپ دیکھ سکتے ہیں، ہر ایک غلطی کے لیے جس پر ہم کارروائی کرنا چاہتے ہیں، ہمیں اپنا مقام بنانا ہوگا، جہاں تمام ضروری ہیڈرز ڈالے جائیں گے، جیسا کہ "مقامی" میں ہے۔ اپنی مرضی کے مطابق غلطی والے صفحات. اس طرح ہم انفرادی مقامات اور سرورز کے لیے بھی مختلف ذاتی نوعیت کے ایرر پیجز بنا سکتے ہیں۔

PS

K8s ٹپس اینڈ ٹرکس سیریز سے دیگر:

• «ایک کلسٹر میں چلنے والے وسائل کو ہیلم 2 مینجمنٹ میں منتقل کرنا؛ "
• «ویب ایپلیکیشن پر نوڈ ایلوکیشن اور لوڈ کے بارے میں؛ "
• «ڈیو سائٹس تک رسائی؛ "
• «بڑے ڈیٹا بیس کے لیے بوٹسٹریپ کو تیز کرنا'.

ہمارے بلاگ پر بھی پڑھیں:

• «Istio کے ساتھ مائیکرو سروسز پر واپس جائیں۔ حصہ 1؛ "
• «Kubernetes میں نیٹ ورکنگ کے لیے گائیڈ۔ حصہ 3'.

ماخذ: www.habr.com