🥇 Kubernetes këshilla & truk: faqe të personalizuara gabimesh në NGINX Ingress

Në këtë artikull do të dëshiroj të flas për dy mundësi të NGINX Ingress, të lidhura me shfaqjen e faqeve të personalizuara me gabime, si dhe për kufizimet ekzistuese dhe mënyrat për t'i shpëtuar ato.

1. Ndryshimi i backend-it nga e para

Nga e para, në NGINX Ingress përdoret backend standard, i cili kryen funksionin e duhur. Kjo do të thotë se kur bëhet një kërkesë në Ingress me një host që nuk është në burimet e Ingress-it, ne marrim një faqe të tillë me kodin e përgjigjes 404:

Megjithatë, gjithnjë e më shumë klientë po vijnë me kërkesën që në vend të standard 404 të shfaqin faqen e tyre me logo të markës dhe komoditete të tjera. Për këtë, NGINX Ingress ka një mundësi të integruar për të tejkaluar shërbimin-default-backend. Opcioni i njëjtë si emri, si argument, merr një regjistrim në formatin namespace/servicename. Porta e shërbimit duhet të jetë 80.

Për këtë është e nevojshme të krijoni pod-in tuaj (implementim) dhe shërbim me aplikacionin tuaj (shembuj të realizimit në YAML nga depoja ingress-nginx), i cili do të kthehet në vend të backend-it të standard.

Këtu është një ilustrim i vogël:

~$ 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>Faqja që po kërkoni nuk mund të gjendet.</span>

Kështu, të gjitha domenet që nuk janë krijuar qartazi përmes YAML me kind: Ingress, bien në backend-in e paracaktuar. Në listimin më sipër, një nga këto domene ishte sadsdasdas.

2. Trajtimi i gabimeve HTTP në aplikacion nga fuqia e backend-it të paracaktuar

Një situatë tjetër — kërkesat për aplikacione që përfundojnë me gabime HTTP (404, 500, 502…) dhe që në të cilat këto situata nuk trajtohen (nuk gjenerohen faqet e bukura të duhura). Kjo mund të shkaktohet gjithashtu nga dëshira e zhvilluesve për të ofruar faqe të njëjta gabimesh në shumë aplikacione.

Për të realizuar këtë rast në anën e serverit, na nevojitet:

Të kryejmë instrukcionin e mësipërm nga pika e backend-it standard;
Në ConfigMapin e konfigurimit nginx-ingress të shtojmë çelësin custom-http-errors, për shembull, me vlerën 404,503 (e qartë, korrespondon me kodet e gabimit, për të cilat zbatohen rregulli i ri).

Rezultati i pritur është arritur: kur aplikacioni klient punon dhe merr një gabim me kodin e përgjigjes 404 ose 503, kërkesa do të kalojë automatikisht në backend-in e ri paracushtuar…

Megjithatë, kur zhvilloni një aplikacion për backend-in e paracaktuar dhe custom-http-errors, duhet të merrni parasysh një veçori të rëndësishme:

!!! E rëndësishme Backend-i i personalizuar pritet të kthejë kodin e saktë të statusit HTTP në vend të 200. NGINX nuk e ndërron përgjigjen nga backend-i standard të personalizuar.

Kjo është se kur redirektoni një kërkesë, do të ketë informacion të dobishëm në tituj me kodin e mëparshëm të përgjigjes dhe informacionin shtesë (lista e plotë e tyre është e disponueshme këtu).

Kjo do të thotë se ju vetë duhet të kujdeseni për kodin e saktë të përgjigjes. Ja një shembull nga dokumentacioni, si funksionon kjo.

Aplikacione të ndryshme - backend-default të ndryshëm

Për të mos pasur një zgjidhje globale për të gjithë klusterin, por që i përket vetëm aplikacioneve specifike, duhet fillimisht të kontrolloni versionin e Ingress. Nëse ai përputhet me 0.23 ose më të lartë, përdorni anotacionet 'native' të Ingress:

Ne mund të tejkalojmë backend-default për çdo Ingress'i me anotacionin;
Ne mund të tejkalojmë custom-http-errors për çdo Ingress'i me anotacionin.

Si rezultat, burimi i Ingress do të duket afërsisht si më poshtë:

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

Në këtë rast, gabimet 404 dhe 502 do të redirektohen në shërbimin error-pages me të gjitha titujt e nevojshëm.

Në në versionet e mëparshme të Ingress, kjo mundësi nuk ka qenë e disponueshme (komit i rëndësishëm në 0.23). Dhe nëse keni dy aplikacione krejtësisht të ndryshme në klusterin tuaj dhe dëshironi t’u jepni secilit prej tyre shërbim të ndryshëm backend-default dhe trajtimin e kodit të ndryshëm të gabimeve - për këtë do të duhet të përdorni workaround-et, për të cilat ne kemi dy.

Ingress < 0.23: qasja e parë

Ky variant është më i thjeshtë. Si aplikacion që ofron faqet e tij, ne kemi një HTML të zakonshëm, i cili nuk di të shikojë titujt dhe të ofrojë kodet e saktë të përgjigjes. Ky aplikacion nxirret me Ingress me url /error-pages, ndërsa në katalogun ws do të jetë HTML që ofrohet.

Ilustrimi në 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

Shërbimi për këtë deploy duhet të jetë me tipin ClusterIP.

Në këtë rast, në aplikacionin ku do të trajtojmë gabimin, në Ingress shtojmë server-snippet ose configuration-snippet me përmbajtjen e mëposhtme:

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

Ingress < 0.23: alternativa e dytshme

Një variant për aplikacionin që di të trajtojë titujt... Dhe gjithashtu, ky është një rrugë më e saktë, e marrë nga custom-http-errors. Përdorimi i tij manual (kopjimi) do të lejojë që të mos ndryshoni konfiguratat globale.

Hapat janë si më poshtë. Krijojmë një deployment të ngjashëm me aplikacionin që di të dëgjojë titujt e nevojshëm dhe të përgjigjet saktë. Shtojmë në Ingress të aplikacionit server-snippet me përmbajtjen e mëposhtme:

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

Siç shihet, për çdo gabim që dëshirojmë të trajtojmë, duhet të krijojmë lokacionin e tij, ku do të vendosen të gjithë titujt e nevojshëm, ashtu si në "origjinale" custom-error-pages. Kështu mund të krijojmë faqe të ndryshme të personalizuara për gabime madje edhe për lokacione dhe servera të veçantë.