Jak zbudować przyjazny początkującym stos aplikacji bez uzależniania każdej usługi od innych

Łatwy dla początkujących stos aplikacji pozostaje zrozumiały, gdy każda usługa ma jeden cel, zarządza własnymi danymi i może ulec awarii bez wyłączania niezwiązanych z nią funkcji domowych.

Zagrożeniem nie jest sama liczba kontenerów. Złożoność pojawia się wtedy, gdy każda aplikacja zależy od tej samej bazy danych, warstwy uwierzytelniania, odwrotnego serwera proxy, usługi DNS, ścieżki pamięci masowej, okna aktualizacji i konta administratora. Dlatego początkowy stos powinien korzystać z niewielkiej współdzielonej warstwy bazowej, utrzymywać opcjonalne udogodnienia poza ścieżkami usług kluczowych oraz dokładnie dokumentować, które komponenty muszą ponownie działać, zanim każda aplikacja stanie się użyteczna.

Zacznij od rezultatów dla gospodarstwa domowego, a nie od katalogu aplikacji

Zanim wybierzesz oprogramowanie, wypisz powtarzające się zadania, które serwer musi obsługiwać. Przydatny początkowy stos może zapewniać kopie zapasowe urządzeń, jedną wspólną lokalizację plików oraz jedną opcjonalną usługę multimedialną lub pulpit nawigacyjny. Każde zadanie powinno mieć określonego użytkownika, właściciela danych, akceptowalny czas niedostępności i ścieżkę odzyskiwania. Aplikacje, które nie wspierają żadnego z tych rezultatów, powinny trafić na późniejszą listę.

TechTarget definiuje architekturę aplikacji jako strukturalną mapę pokazującą, jak aplikacje współdziałają z oprogramowaniem pośredniczącym, bazami danych i innymi aplikacjami, aby spełniać wymagania użytkowników. Ta mapa łącząca wymagania użytkownika z komponentami jest bardziej użyteczna niż traktowanie każdej dostępnej aplikacji jako niezależnej funkcji.

Opisz początkowy stos jako trzy kontrakty usługowe, a nie trzy nazwy produktów. Dla każdego kontraktu określ, jakie dane do niego trafiają, jaki wynik zwraca oraz co domownicy mogą zrobić, gdy usługa jest niedostępna. Dzięki temu późniejsze zamienniki nie będą wymagały przeprojektowania całego serwera.

Współdzielona warstwa bazowa powinna być mniejsza niż warstwa aplikacji

Pewna współdzielona infrastruktura jest rozsądnym rozwiązaniem. Kilka aplikacji internetowych może korzystać z tego samego hosta, puli pamięci masowej, sposobu monitorowania i lokalnej konwencji nazewnictwa. Problem zaczyna się wtedy, gdy każda aplikacja wymaga centralnej usługi, której awaria jednocześnie odbiera dostęp, uwierzytelnianie, rozpoznawanie nazw lub pamięć masową.

Analiza TechTarget dotycząca zależności cyklicznych wyjaśnia, że silnie powiązane komponenty stają się trudne do niezależnego aktualizowania, testowania i wdrażania. Jej ostrzeżenie przed cyklem zależności dotyczy również serwera domowego, nawet gdy stos jest znacznie mniejszy.

Używaj minimalnej wspólnej podstawy potrzebnej obecnie. Odwrotne proxy, centralną warstwę tożsamości lub wewnętrzną usługę DNS dodawaj dlatego, że kilka stabilnych aplikacji na nich skorzysta — nie dlatego, że diagram wygląda pełniej z kolejnym elementem.

Nadaj każdej usłudze jasno określonego właściciela danych i trwałą ścieżkę

Aplikacja nie powinna przypadkowo wykrywać swojego magazynu. Określ, która ścieżka zawiera konfigurację, która bazę danych, która pliki domowe, a która nietrwałą pamięć podręczną. Dwie usługi mogą odczytywać tę samą bibliotekę multimediów, ale nie powinny jednocześnie zarządzać bazą metadanych ani mieć szerokich uprawnień do zapisu w całej puli.

Better Stack wyjaśnia, że trwałe dane kontenera wymagają cyklu życia niezależnego od kontenera, który z nich korzysta. Ten niezależny model cyklu życia danych stanowi podstawę do zastąpienia jednej aplikacji bez wprowadzania niejasności dotyczących jej danych.

Używaj czytelnych ścieżek hosta, takich jak /srv/appdata/service, /srv/data/service oraz /srv/cache/service. Zapisz dla każdego właściciela, uprawnienia do zapisu, zasadę tworzenia kopii zapasowych i metodę przywracania. Współdzielone dane domowe powinny mieć jedną nadrzędną lokalizację, nawet jeśli kilka aplikacji je indeksuje lub wyświetla.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Buduj ścieżki dostępu, które zachowują funkcjonalność w przypadku awarii

Początkujący często zaczyna od bezpośrednich lokalnych adresów IP i portów, a następnie dodaje lokalny DNS, HTTPS, odwrotne proxy i zdalny dostęp. Każda warstwa poprawia wygodę użytkowania, ale każda tworzy też kolejne miejsce, w którym aplikacja może wyglądać na niedostępną, mimo że sama działa prawidłowo.

Przewodnik po homelabie przedstawia ścieżkę żądania prowadzącą przez DNS, routing, odwrotne proxy, aplikację oraz zależność w postaci bazy danych lub magazynu. Ten warstwowy model ścieżki żądania pomaga początkującemu oddzielić problemy z dostępem od problemów z aplikacją.

Nadaj każdej ważnej usłudze stabilną nazwę lokalną, ale zachowaj udokumentowany bezpośredni adres na potrzeby odzyskiwania. Zdalny dostęp nie powinien być wymagany do administrowania serwerem z wnętrza domu. Router, resolver DNS i system uwierzytelniania nie powinny być jednocześnie zależne od tego samego eksperymentalnego łańcucha usług.

Trzymaj opcjonalne usługi zwiększające wygodę poza podstawowymi ścieżkami

Pulpity nawigacyjne, indeksy wyszukiwania, przekaźniki powiadomień, grafiki multimediów i centralne uwierzytelnianie mogą poprawiać komfort korzystania z systemu, ale nie powinny być wymagane do zachowania dostępności podstawowych danych. Oznacz je jako opcjonalne zależności, aby awaria warstwy wygody powodowała ograniczenie funkcjonalności, a nie całkowitą niedostępność systemu.

Przewodnik TechTargeta dotyczący odporności opisuje wzorzec grodzi jako izolowanie części systemu, aby pojedyncza awaria nie przerodziła się w całkowitą awarię. Ta zasada izolowania awarii przekłada się na prostą zasadę domową: podstawowe ścieżki dostępu do pamięci masowej, kopii zapasowych i administracji muszą pozostać użyteczne, gdy opcjonalne warstwy przestaną działać.

Testuj stos, zatrzymując po kolei jedną opcjonalną usługę. Współdzielone pliki powinny pozostać dostępne, gdy pulpit nawigacyjny przestanie działać. Administracja lokalna powinna być nadal możliwa, gdy zdalny dostęp przestanie działać. Kopia zapasowa nie powinna zależeć od indeksu multimediów, a przywracanie nie powinno wymagać usługi powiadomień raportującej stan kopii zapasowej.

Aktualizuj usługi i twórz ich kopie zapasowe jako niezależne jednostki odzyskiwania

Jedno okno konserwacyjne nie powinno wymagać jednoczesnej aktualizacji każdej aplikacji. Definicje usług, stan trwały i informacje o wersjach powinny być na tyle od siebie oddzielone, aby można było zabezpieczyć, zmienić, sprawdzić i wycofać jedną aplikację bez modyfikowania niezwiązanych z nią obciążeń.

Backblaze twierdzi, że plan odzyskiwania jest tak dobry, jak jego ostatni test, i zaleca powtarzalne ćwiczenia odzyskiwania o ograniczonym zakresie. Takie ćwiczenie odzyskiwania usługa po usłudze jest odpowiednie dla niewielkiego stosu utrzymywanego samodzielnie.

Przed aktualizacją wyeksportuj konfigurację, zabezpiecz odpowiednią bazę danych lub stan aplikacji i zapisz bieżącą wersję. Następnie sprawdź aplikację ze zwykłego konta użytkownika i potwierdź działanie zaplanowanych zadań. Jeśli aktualizacja wymaga skoordynowanych zmian w kilku usługach, wyraźnie udokumentuj tę zależność, zamiast odkrywać ją dopiero podczas awarii.

Obok inwentarza usług prowadź niewielki rejestr zależności. Dla każdej aplikacji zapisz hosta, ścieżkę pamięci masowej, bazę danych, nazwę lokalną, metodę uwierzytelniania i miejsce docelowe kopii zapasowej, których rzeczywiście wymaga. Integracje opcjonalne oznaczaj osobno. Gdy jeden komponent zostanie zastąpiony, aktualizuj tylko wiersze zależne od niego i wykonuj odpowiednie testy odzyskiwania. Zapobiega to sytuacji, w której wygodne współdzielone narzędzie staje się nieudokumentowaną podstawą każdej usługi dodanej później.

Używaj zestawu startowego, który może rosnąć bez przekształcania się w łańcuch zależności

Trwały pierwszy stos zwykle obejmuje jedną warstwę systemową, jedną mapę pamięci masowej, jedną ścieżkę tworzenia kopii zapasowych i niewielką liczbę usług przeznaczonych dla użytkowników. Wspólną infrastrukturę dodawaj dopiero wtedy, gdy potrzebują jej co najmniej dwie stabilne aplikacje, a ścieżka odzyskiwania danych pozostaje zrozumiała także bez niej.

Projekt kompaktowego serwera firmy ServeTheHome pokazuje, jak niewielki, dedykowany system można zaprojektować wokół określonego połączenia mocy obliczeniowej, pamięci masowej i sieci, zamiast rozbudowywać go do nieograniczonej platformy. Ten model serwera o jasno określonej roli jest lepszym punktem odniesienia dla początkujących niż jednoczesna instalacja każdej usługi infrastrukturalnej.

Przewodnik ZimaSpace dotyczący budowy pierwszego serwera wokół trzech połączonych usług pomaga ograniczyć początkowy zakres. ZimaBoard 2 Mini Home Server pasuje do kompaktowego stosu zorientowanego na aplikacje, z przemyślaną przestrzenią dyskową i ograniczoną liczbą usług. ZimaCube 2 AI NAS staje się wyraźnie lepszą bazą, gdy pamięć masowa złożona z wielu dysków, kilku użytkowników domowych, dłuższy okres przechowywania danych oraz odzyskiwanie skoncentrowane na pamięci masowej są już kluczowymi wymaganiami.

Stos jest przyjazny dla początkujących, gdy dodanie, zatrzymanie, aktualizacja lub zastąpienie jednej usługi zmienia tylko jej własne dane i ścieżkę dostępu, zamiast zmuszać cały domowy serwer do przeprowadzki razem z nią.