ProHoster > блог > Администрација > Совети и трикови на Kubernetes: прилагодени страници за грешки во NGINX Ingress
Совети и трикови на Kubernetes: прилагодени страници за грешки во NGINX Ingress
Во оваа статија, сакам да зборувам за две карактеристики на NGINX Ingress поврзани со прикажување на персонализирани страници за грешки, како и за ограничувањата што постојат во нив и начините за нивно работење.
1. Промена на стандардниот заднина
Стандардно, NGINX Ingress го користи стандардниот заден дел, кој ја извршува соодветната функција. Ова значи дека кога бараме Ingress со одредување на домаќин што не е во ресурсите на Ingress, ја добиваме следната страница со код за одговор 404:
Сепак, сè почесто нашите клиенти доаѓаат со барање да ја покажат својата страница со корпоративно лого и други погодности наместо стандардниот 404. За да го направите ова, NGINX Ingress има вградена способност редефинира default-backend-service. Записот за формат го пренесуваме како аргумент на опцијата со исто име namespace/servicename. Пристаништето на услугата треба да биде 80.
За да го направите ова, треба да креирате сопствена подлога (распоредување) и услуга со вашата апликација (пример имплементација во YAML од складиштето ingress-nginx), кое ќе биде дадено наместо стандардниот заден дел.
Еве мала илустрација:
~$ 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-грешки во апликацијата користејќи го стандардниот заднина
Друга ситуација се барањата што завршуваат со HTTP грешки (404, 500, 502...) до апликација која не обработува такви ситуации (соодветните убави страници не се генерираат). Ова може да се должи и на желбата на програмерите да ги опслужуваат истите страници за грешки во повеќе апликации.
За да го имплементираме овој случај на страната на серверот ни треба:
Следете ги упатствата погоре од параграфот за стандардниот заднина;
Додадете клуч на конфигурацијата 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:
Можеме да прескокнеме default-backend за од секоја На Ingress користејќи прибелешки;
Можеме да прескокнеме custom-http-errors за од секоја На Ingress користејќи прибелешки.
Како резултат на тоа, ресурсот Ingress ќе изгледа вака:
Во овој случај, грешките 404 и 502 ќе бидат пренасочени на услугата за страници со грешки со сите потребни заглавија.
В претходните верзии на Ingress ја немаа оваа функција (судбоносно извршување на 0.23). И ако имате 2 сосема различни апликации што работат во вашиот кластер и сакате да наведете различна стандардна услуга за задната страна и обработка на различни шифри за грешка за секоја од нив, за ова ќе треба да користите решенија, од кои имаме две.
Влез < 0.23: пристап до еден
Оваа опција е поедноставна. Како апликација која ги опслужува своите страници, имаме редовен HTML, кој не знае како да ги погледне заглавјата и да ги врати точните кодови за одговор. Таквата апликација се пушта со Ingress од URL-то /error-pages, и во каталогот ws ќе биде вратениот HTML.
Опција за апликација која може да обработува заглавија... И генерално ова е поправилен начин, позајмен од custom-http-errors. Рачното користење (копирање) ќе ви овозможи да не ги менувате глобалните поставки.
Чекорите се како што следува. Ние создаваме исто распоредување со апликација која може да ги слуша потребните наслови и правилно да одговори. Додајте фрагмент од сервер во апликацијата Ingress со следнава содржина:
Како што можете да видите, за секоја грешка што сакаме да ја обработиме, треба да направиме своја локација, каде што ќе бидат вметнати сите потребни заглавија, како во „мајчинот“. сопствени-страници за грешки. На овој начин можеме да креираме различни персонализирани страници за грешки дури и за поединечни локации и сервери.