ProHoster > Blog > administracja > Porady i wskazówki Kubernetes: niestandardowe strony błędów w NGINX Ingress
Porady i wskazówki Kubernetes: niestandardowe strony błędów w NGINX Ingress
W tym artykule chcę omówić dwie funkcje NGINX Ingress związane z wyświetlaniem spersonalizowanych stron błędów, a także istniejące w nich ograniczenia i sposoby obejścia ich.
1. Zmiana domyślnego backendu
Domyślnie NGINX Ingress korzysta z domyślnego backendu, który wykonuje odpowiednią funkcję. Oznacza to, że w przypadku żądania Ingressu ze wskazaniem hosta, którego nie ma w zasobach Ingress, otrzymamy następującą stronę z kodem odpowiedzi 404:
Jednak coraz częściej nasi klienci zwracają się z prośbą o wyświetlenie swojej strony z logo firmy i innymi udogodnieniami zamiast standardowego 404. Aby to zrobić, NGINX Ingress ma wbudowana funkcja przedefiniować default-backend-service. Wpis formatu przekazujemy jako argument opcji o tej samej nazwie namespace/servicename. Port usługi powinien mieć numer 80.
Aby to zrobić, musisz utworzyć własny pod (wdrożenie) i usługę ze swoją aplikacją (przykładowa implementacja w YAML z repozytorium ingress-nginx), który zostanie podany zamiast domyślnego backendu.
Oto mała ilustracja:
~$ 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>
Zatem wszystkie domeny, które nie są jawnie utworzone za pomocą YAML z kind: Ingress, wpadnij do domyślnego backendu. Na powyższym wykazie ta domena stała się sadsdasdas.
2. Obsługa błędów HTTP w aplikacji przy wykorzystaniu domyślnego backendu
Inną sytuacją są żądania zakończone błędami HTTP (404, 500, 502...) kierowane do aplikacji, która nie przetwarza takich sytuacji (nie są generowane odpowiednie piękne strony). Może to również wynikać z chęci programistów do obsługi tych samych stron błędów w wielu aplikacjach.
Aby zaimplementować ten przypadek po stronie serwera, potrzebujemy:
Postępuj zgodnie z instrukcjami powyżej z akapitu dotyczącego domyślnego backendu;
Dodaj klucz do konfiguracji nginx-ingres ConfigMap custom-http-errorsna przykład z wartością 404,503 (oczywiście odpowiada kodom błędów objętych nową zasadą).
Oczekiwany rezultat został osiągnięty: gdy aplikacja kliencka jest uruchomiona i otrzyma błąd z kodem odpowiedzi 404 lub 503, żądanie zostanie automatycznie przekierowane do nowego domyślnego backendu...
Jednak tworząc aplikację dla domyślnego backendu i niestandardowych błędów http, należy wziąć pod uwagę ważną cechę:
!!! 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.
Faktem jest, że w przypadku przekierowania żądania w nagłówkach będą znajdować się przydatne informacje z poprzednim kodem odpowiedzi oraz informacje dodatkowe (ich pełna lista jest dostępna tutaj).
Oznacza to, że sam musisz zadbaj o poprawny kod odpowiedzi. Oto przykład. z dokumentacji jak to działa.
Różne aplikacje mają różne domyślne backendy
Aby mieć pewność, że rozwiązanie nie jest globalne dla całego klastra, a dotyczy tylko konkretnych aplikacji, należy najpierw sprawdzić wersję Ingress. Jeśli pasuje 0.23 lub więcejużyj natywnych adnotacji Ingress:
W takim przypadku błędy 404 i 502 zostaną przekierowane do usługi error-pages ze wszystkimi niezbędnymi nagłówkami.
В poprzednie wersje Ingress nie miały tej funkcji (fatalne popełnienie na poziomie 0.23). A jeśli w klastrze działają 2 zupełnie różne aplikacje i chcesz określić inną domyślną usługę backendu i przetwarzanie różnych kodów błędów dla każdej z nich, w tym celu będziesz musiał skorzystać z obejść, z których mamy dwa.
Ingres < 0.23: podejście do pierwszego
Ta opcja jest prostsza. Jako aplikacja obsługująca swoje strony mamy zwykły HTML, który nie wie jak patrzeć na nagłówki i zwracać poprawne kody odpowiedzi. Taka aplikacja jest wdrażana za pomocą Ingress z adresu URL /error-pagesi w katalogu ws będzie zwróconym kodem HTML.
Opcja dla aplikacji, która może przetwarzać nagłówki... I ogólnie jest to bardziej poprawny sposób, zapożyczony z niestandardowych błędów http. Użycie go ręcznie (kopiowanie) pozwoli Ci nie zmieniać ustawień globalnych.
Kroki są następujące. Tworzymy to samo wdrożenie z aplikacją, która potrafi odsłuchać niezbędne nagłówki i poprawnie odpowiedzieć. Dodaj fragment kodu serwera do aplikacji Ingress z następującą treścią:
Jak widać, dla każdego błędu, który chcemy przetworzyć, musimy stworzyć własną lokalizację, w której zostaną wstawione wszystkie niezbędne nagłówki, tak jak w „natywnym”. niestandardowe strony błędów. W ten sposób możemy tworzyć różne spersonalizowane strony błędów nawet dla poszczególnych lokalizacji i serwerów.