ProHoster > Блог > Administrado > Konsiloj kaj lertaĵoj de Kubernetes: kutimaj eraraj paĝoj en NGINX Ingress
Konsiloj kaj lertaĵoj de Kubernetes: kutimaj eraraj paĝoj en NGINX Ingress
En ĉi tiu artikolo, mi volas paroli pri du trajtoj de NGINX Ingress rilataj al montrado de personigitaj eraraj paĝoj, same kiel la limigoj, kiuj ekzistas en ili, kaj manieroj labori ĉirkaŭ ili.
1. Ŝanĝi la defaŭltan backend
Defaŭlte, NGINX Ingress uzas la defaŭltan backend, kiu plenumas la respondan funkcion. Ĉi tio signifas, ke kiam oni petas Eniron specifantan gastiganton kiu ne estas en la Ingress-resursoj, ni ricevas la sekvan paĝon kun respondkodo 404:
Tamen, pli kaj pli ofte niaj klientoj venas kun peto montri sian paĝon kun kompania emblemo kaj aliaj agrablaĵoj anstataŭ la norma 404. Por fari tion, NGINX Ingress havas enkonstruita kapableco redifini default-backend-service. Ni pasas la formatan eniron kiel argumenton al la samnoma opcio namespace/servicename. La haveno de la servo devus esti 80.
Por fari tion, vi devas krei vian propran pod (deplojo) kaj servon kun via aplikaĵo (ekzempla efektivigo en YAML de la deponejo ingress-nginx), kiu estos donita anstataŭ la defaŭlta backend.
Jen malgranda ilustraĵo:
~$ 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>
Do ĉiuj domajnoj kiuj ne estas eksplicite kreitaj per YAML kun kind: Ingress, falu en defaŭltan backend. En la supra listo, ĉi tiu domajno fariĝis sadsdasdas.
2. Pritrakti HTTP-erarojn en la aplikaĵo uzante la defaŭltan backend
Alia situacio estas petoj finiĝantaj per HTTP-eraroj (404, 500, 502...) al aplikaĵo, kiu ne prilaboras tiajn situaciojn (la respondaj belaj paĝoj ne estas generitaj). Ĉi tio ankaŭ povas esti pro la deziro de programistoj servi la samajn erarpaĝojn en pluraj aplikoj.
Por efektivigi ĉi tiun kazon ĉe la servilo ni bezonas:
Sekvu la suprajn instrukciojn de la alineo pri defaŭlta backend;
Aldonu ŝlosilon al la nginx-ingress-agordo ConfigMap custom-http-errors, ekzemple, kun la valoro 404,503 (evidente respondas al la erarkodoj kiuj estas kovritaj de la nova regulo).
La atendata rezulto estis atingita: kiam la klienta aplikaĵo funkcias kaj ricevas eraron kun respondkodo de 404 aŭ 503, la peto estos aŭtomate redirektita al la nova defaŭlta backend...
Tamen, dum disvolvado de aplikaĵo por defaŭlta backend kaj kutimaj http-eraroj, vi devas konsideri gravan funkcion:
!!! 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.
Fakte, kiam peto estas alidirektita, la kaplinioj enhavos utilajn informojn kun la antaŭa respondkodo kaj pliajn informojn (ilia kompleta listo disponeblas tie).
Ĉi tio signifas, ke vi mem devas prizorgu la ĝustan respondkodon. Jen ekzemplo de la dokumentaro kiel ĝi funkcias.
Malsamaj aplikoj havas malsamajn defaŭltajn backends
Por certigi, ke la solvo ne estas tutmonda por la tuta areto, sed validas nur por specifaj aplikoj, vi unue devas kontroli la Ingress-version. Se ĝi kongruas 0.23 aŭ pli alta, uzu la denaskajn Ingress-kotadojn:
En ĉi tiu kazo, eraroj 404 kaj 502 estos redirektitaj al la servo de erarpaĝoj kun ĉiuj necesaj kaplinioj.
В antaŭaj versioj de Ingress ne havis ĉi tiun funkcion (fatala kompromiso ĉe 0.23). Kaj se vi havas 2 tute malsamajn aplikojn kurantajn en via areto kaj vi volas specifi malsaman defaŭltan-backend-servon kaj prilaboradon de malsamaj erarkodoj por ĉiu el ili, por tio vi devos uzi solvojn, el kiuj ni havas du.
Eniro < 0.23: alproksimiĝu al unu
Ĉi tiu opcio estas pli simpla. Kiel aplikaĵo, kiu servas ĝiajn paĝojn, ni havas regulan HTML, kiu ne scias kiel rigardi la kapliniojn kaj resendi la ĝustajn respondkodojn. Tia aplikaĵo estas lanĉita kun Ingress de la url /error-pages, kaj en la katalogo ws estos la resendita HTML.
Opcio por aplikaĵo, kiu povas prilabori titolojn... Kaj ĝenerale ĉi tio estas pli ĝusta maniero, pruntita de custom-http-eraroj. Uzi ĝin permane (kopiante) permesos al vi ne ŝanĝi tutmondajn agordojn.
La paŝoj estas kiel sekvas. Ni kreas sama deplojo kun aplikaĵo, kiu povas aŭskulti la necesajn titolojn kaj respondi ĝuste. Aldonu servilan fragmenton al la aplikaĵo Ingress kun la sekva enhavo:
Kiel vi povas vidi, por ĉiu eraro, kiun ni volas prilabori, ni devas fari nian propran lokon, kie ĉiuj necesaj kaplinioj estos enmetitaj, kiel en la "denaska". kutimo-eraraj-paĝoj. Tiel ni povas krei malsamajn personigitajn erarpaĝojn eĉ por individuaj lokoj kaj serviloj.