Kubernetes wenke en truuks: persoonlike foutbladsye in NGINX Ingress
In hierdie artikel wil ek praat oor twee kenmerke van NGINX Ingress wat verband hou met die vertoon van gepersonaliseerde foutbladsye, sowel as hul beperkings en maniere om dit te omseil.
1. Verander die verstek agterkant
By verstek gebruik NGINX Ingress die verstek agterkant, wat die ooreenstemmende funksie verrig. Dit beteken dat wanneer ons 'n Ingress versoek met 'n gasheer wat nie in die Ingress-bronne is nie, ons hierdie bladsy kry met 'n 404-antwoordkode:
Ons kliënte kom egter meer en meer gereeld met 'n versoek om hul bladsy met 'n maatskappylogo en ander geriewe te wys in plaas van die standaard 404. Hiervoor het NGINX Ingress ingeboude vermoë herdefinieer default-backend-service. Ons gee die formaatrekord as 'n argument aan die opsie met dieselfde naam namespace/servicename. Die dienspoort moet 80 wees.
Om dit te doen, moet jy jou eie pod (ontplooiing) en 'n diens met jou toepassing skep (voorbeeld implementering in YAML vanaf die ingress-nginx-bewaarplek), wat gegee sal word in plaas van die verstek agterkant.
Hier is 'n klein illustrasie:
~$ 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>
So alle domeine wat nie eksplisiet geskep is via YAML met kind: Ingress, val in die verstek-agterkant. In die lys hierbo het hierdie domein geword sadsdasdas.
2. Hantering van HTTP-foute in die toepassing deur die verstek-backend
Nog 'n situasie is versoeke wat eindig met HTTP-foute (404, 500, 502 ...) na 'n toepassing wat nie sulke situasies hanteer nie (ooreenstemmende pragtige bladsye word nie gegenereer nie). Dit kan ook veroorsaak word deur die begeerte van ontwikkelaars om dieselfde foutbladsye in verskeie toepassings terug te gee.
Om hierdie geval aan die bedienerkant te implementeer, benodig ons:
Volg die instruksies hierbo uit die paragraaf oor die verstek agterkant;
Voeg die sleutel by die konfigurasie ConfigMap nginx-ingress custom-http-errors, byvoorbeeld, met die waarde 404,503 (kom natuurlik ooreen met die foutkodes wat deur die nuwe reël gedek word).
Die verwagte resultaat word behaal: wanneer die kliënttoepassing loop en 'n fout met 'n 404- of 503-antwoordkode ontvang, sal die versoek outomaties herlei word na die nuwe verstek-agtergrond ...
Wanneer 'n toepassing vir die verstek-agtergrond en persoonlike http-foute ontwikkel word, moet 'n belangrike kenmerk egter in ag geneem word:
!!! 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.
Die feit is dat wanneer die versoek herlei word, die opskrifte nuttige inligting sal bevat met die vorige antwoordkode en bykomende inligting (hul volledige lys is beskikbaar hier).
Dit beteken dat jy moet sorg vir die korrekte antwoordkode. Hier is 'n voorbeeld. uit die dokumentasie hoe dit werk.
Verskillende toepassings - verskillende standaard backend
Sodat die oplossing nie wêreldwyd vir die hele groepering is nie, maar slegs op spesifieke toepassings van toepassing is, moet u eers die weergawe van Ingress nagaan. As dit ooreenstem 0.23 of hoër, gebruik die oorspronklike Ingress-aantekeninge:
Ons kan herdefinieer default-backend vir elkeen Intrede met annotasie;
Ons kan herdefinieer custom-http-errors vir elkeen Intrede met annotasie.
As gevolg hiervan sal die Ingress-hulpbron iets soos volg lyk:
In hierdie geval sal 404- en 502-foute na die foutbladsye-diens herlei word met al die nodige opskrifte.
В vorige weergawes van Ingress het nie hierdie kenmerk gehad nie. (noodlottige pleeg in 0.23). En as jy 2 heeltemal verskillende toepassings in jou groepering het en jy wil verskillende verstek-backend-dienste spesifiseer en verskillende foutkodes vir elkeen van hulle hanteer, sal jy oplossings hiervoor moet gebruik, waarvan ons twee het.
Ingang < 0.23: nader een
Hierdie opsie is eenvoudiger. As 'n toepassing wat sy bladsye weergee, het ons gewone HTML, wat nie weet hoe om na kopskrifte te kyk en korrekte antwoordkodes terug te gee nie. So 'n toepassing ontplooi met Ingress met url /error-pages, en in die gids ws sal HTML gegee word.
Die diens vir hierdie ontplooiing moet van die tipe ClusterIP wees.
Terselfdertyd, in die toepassing waar ons die fout sal hanteer, voeg ons in Ingress bediener-brokkie of konfigurasie-brokkie by met die volgende inhoud:
'n Variant vir 'n toepassing wat opskrifte kan verwerk ... En in die algemeen is dit 'n meer korrekte manier, geleen van persoonlike-http-foute. Deur dit met die hand te gebruik (kopieer) sal jy nie die globale instellings verander nie.
Die stappe is soos volg. Ons skep dieselfde ontplooiing met 'n toepassing wat na die regte kopskrifte kan luister en korrek kan reageer. Ons voeg bediener-brokkie-toepassings by die Ingress met die volgende inhoud:
Soos u kan sien, moet ons vir elke fout wat ons wil verwerk, ons eie ligging maak, waar al die nodige opskrifte vervang sal word, soos in "native" pasgemaakte foutbladsye. Op hierdie manier kan ons verskillende gepersonaliseerde foutbladsye skep, selfs vir individuele liggings en bedieners.