Kubernetes tippek és trükkök: egyéni hibaoldalak az NGINX Ingressben
Ebben a cikkben az NGINX Ingress két olyan funkciójáról szeretnék beszélni, amelyek a személyre szabott hibaoldalak megjelenítésével kapcsolatosak, valamint a bennük rejlő korlátokról és azok megkerülésének módjairól.
1. Az alapértelmezett háttérrendszer módosítása
Alapértelmezés szerint az NGINX Ingress az alapértelmezett háttérprogramot használja, amely végrehajtja a megfelelő funkciót. Ez azt jelenti, hogy amikor olyan bemenetet kérünk, amely olyan gazdagépet ad meg, amely nem szerepel az Ingress erőforrásokban, a következő oldalt kapjuk 404-es válaszkóddal:
Ügyfeleink azonban egyre gyakrabban érkeznek azzal a kéréssel, hogy a szokásos 404 helyett céges logóval és egyéb szolgáltatásokkal mutassák meg oldalukat. Ehhez az NGINX Ingress rendelkezik beépített képesség újradefiniál default-backend-service. A formátum bejegyzést argumentumként adjuk át az azonos nevű opciónak namespace/servicename. A szolgáltatás portjának 80-asnak kell lennie.
Ehhez létre kell hoznia saját pod (telepítést) és szolgáltatást az alkalmazással (példa megvalósítás YAML-ben az ingress-nginx tárolóból), amely az alapértelmezett háttérprogram helyett lesz megadva.
Íme egy kis illusztráció:
~$ 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>
Tehát minden olyan tartomány, amelyet nem kifejezetten a YAML-en keresztül hoztak létre kind: Ingress, az alapértelmezett háttérprogramba esik. A fenti listában ez a domain lett sadsdasdas.
2. HTTP-hibák kezelése az alkalmazásban az alapértelmezett háttérprogram használatával
Egy másik helyzet a HTTP hibákra (404, 500, 502...) végződő kérések egy olyan alkalmazáshoz, amely nem dolgozza fel az ilyen helyzeteket (a megfelelő szép oldalak nem jönnek létre). Ennek oka lehet az is, hogy a fejlesztők szeretnék ugyanazokat a hibaoldalakat több alkalmazásban is megjeleníteni.
Ennek az esetnek a szerveroldali megvalósításához szükségünk van:
Kövesse a fenti utasításokat az alapértelmezett háttérprogramról;
Adjon hozzá egy kulcsot a ConfigMap nginx-ingress konfigurációjához custom-http-errors, például az értékkel 404,503 (nyilvánvalóan megfelel az új szabály által lefedett hibakódoknak).
A várt eredmény megtörtént: amikor az ügyfélalkalmazás fut, és 404-es vagy 503-as válaszkódú hibaüzenetet kap, a kérést automatikusan átirányítja az új alapértelmezett háttérrendszerre...
Az alapértelmezett háttér- és egyéni http-hibákra vonatkozó alkalmazás fejlesztésekor azonban figyelembe kell vennie egy fontos funkciót:
!!! 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.
A helyzet az, hogy egy kérés átirányításakor a fejlécek hasznos információkat tartalmaznak az előző válaszkóddal és további információkkal (a teljes listája elérhető itt).
Ez azt jelenti, hogy magának kell ügyeljen a helyes válaszkódra. Íme egy példa a dokumentációból, hogyan működik.
A különböző alkalmazásoknak eltérő alapértelmezett háttérprogramjuk van
Annak érdekében, hogy a megoldás ne globális legyen a teljes fürtre, hanem csak bizonyos alkalmazásokra vonatkozzon, először ellenőriznie kell az Ingress verziót. Ha egyezik 0.23 vagy újabb, használja a natív Ingress megjegyzéseket:
Ebben az esetben a 404-es és 502-es hiba az összes szükséges fejléccel együtt át lesz irányítva a hibaoldalak szolgáltatásra.
В az Ingress korábbi verziói nem rendelkeztek ezzel a funkcióval (végzetes elkövetés 0.23-nál). Ha pedig 2 teljesen különböző alkalmazás fut a fürtben, és mindegyikhez más alapértelmezett-háttérszolgáltatást és más hibakódok feldolgozását szeretnénk megadni, akkor ehhez megkerülő megoldásokat kell alkalmazni, amelyek közül kettőnk van.
Belépés < 0.23: közelíts egyet
Ez a lehetőség egyszerűbb. Az oldalait kiszolgáló alkalmazásként normál HTML-kóddal rendelkezünk, amely nem tudja, hogyan kell megnézni a fejléceket és visszaadni a helyes válaszkódokat. Egy ilyen alkalmazás az Ingress segítségével kerül kihelyezésre az URL-ből /error-pages, és a katalógusban ws lesz a visszaadott HTML.
Az ehhez a telepítéshez tartozó szolgáltatásnak ClusterIP típusúnak kell lennie.
Ugyanakkor abban az alkalmazásban, ahol a hibát feldolgozzuk, az Ingressben hozzáadunk egy szerver-kódrészletet vagy konfigurációs kódrészletet a következő tartalommal:
Opció egy olyan alkalmazáshoz, amely képes feldolgozni a fejléceket... És általában ez egy korrektebb módszer, az egyedi http-hibákból kölcsönözve. Kézi használata (másolás) lehetővé teszi, hogy ne módosítsa a globális beállításokat.
A lépések a következők. Mi alkotunk ugyanaz a bevetés olyan alkalmazással, amely képes meghallgatni a szükséges főcímeket és helyesen válaszolni. Adjon hozzá egy szerver-kódrészletet az Ingress alkalmazáshoz a következő tartalommal:
Amint látja, minden feldolgozni kívánt hibához saját helyet kell létrehoznunk, ahová az összes szükséges fejléc be lesz illesztve, mint a „natív” fejlécben. egyéni hibaoldalak. Így akár egyedi helyszínekre, szerverekre is különböző személyre szabott hibaoldalakat tudunk készíteni.