Jak zbudować przyjazny początkującym zestaw aplikacji, nie uzależniając od siebie każdej usługi

Stos aplikacji przyjazny dla początkujących 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.

Problemem nie jest sama liczba kontenerów. Złożoność pojawia się, gdy każda aplikacja zależy od tej samej bazy danych, warstwy uwierzytelniania, odwrotnego serwera proxy, usługi DNS, ścieżki do pamięci masowej, okna aktualizacji i konta administratora. Dlatego pierwszy stos powinien opierać się na niewielkiej wspólnej infrastrukturze, pozostawiać opcjonalne udogodnienia poza ścieżkami niezbędnych usług oraz dokładnie dokumentować, które komponenty muszą zostać przywrócone, zanim każda aplikacja będzie znów działać.

Zacznij od potrzeb domowników, a nie katalogu aplikacji

Zanim wybierzesz oprogramowanie, wypisz powtarzające się zadania, które serwer ma obsługiwać. Przydatny pierwszy stos może zapewniać kopie zapasowe urządzeń, jedno wspólne miejsce na pliki oraz jedną opcjonalną usługę multimedialną lub panel. Każde zadanie powinno mieć określonego użytkownika, właściciela danych, dopuszczalny czas niedostępności i ścieżkę odzyskiwania. Aplikacje, które nie wspierają żadnego z tych celów, umieść na późniejszej liście.

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

Opisz początkowy stos za pomocą trzech kontraktów usług, a nie nazw trzech produktów. Dla każdego kontraktu określ, jakie dane są przekazywane, jaki wynik jest zwracany i co domownicy mogą zrobić, gdy usługa jest niedostępna. Dzięki temu późniejsza wymiana komponentów nie wymusi przeprojektowania całego serwera.

Wspólna podstawa powinna być mniejsza niż warstwa aplikacji

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

Analiza TechTarget dotycząca zależności cyklicznych wyjaśnia, że ściśle powiązane komponenty trudno aktualizować, testować i wdrażać niezależnie. Ostrzeżenie o cyklu zależności dotyczy także serwera domowego, nawet gdy jego stos jest znacznie mniejszy.

Korzystaj tylko z minimalnej wspólnej podstawy potrzebnej na dziś. Reverse proxy, centralną warstwę zarządzania tożsamością lub wewnętrzną usługę DNS dodawaj wtedy, gdy skorzysta na nich kilka stabilnych aplikacji, a nie dlatego, że schemat wygląda pełniej z kolejnym elementem.

Przypisz każdej usłudze jasnego właściciela danych i trwałą ścieżkę

Aplikacja nie powinna przypadkowo wykrywać swojego zasobu pamięci masowej. Określ, która ścieżka zawiera konfigurację, która bazę danych, która pliki domowników, a która pamięć podręczną przeznaczoną do usunięcia. Dwie usługi mogą odczytywać tę samą bibliotekę multimediów, ale nie powinny jednocześnie zarządzać bazą danych 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 ryzyka, że jej dane staną się niejednoznaczne.

Używaj czytelnych ścieżek na hoście, takich jak /srv/appdata/service, /srv/data/service i /srv/cache/service. Dla każdej określ właściciela, uprawnienia do zapisu, zasady tworzenia kopii zapasowych i sposób przywracania. Współdzielone dane domowników powinny mieć jedną nadrzędną lokalizację, nawet jeśli kilka aplikacji je indeksuje lub wyświetla.

Featured

Osobista chmura i domowy NAS ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Projektuj ścieżki dostępu tak, by działały także w ograniczonym zakresie

Początkujący często zaczynają od lokalnych adresów IP i portów, a potem dodają lokalny DNS, HTTPS, reverse proxy i dostęp zdalny. Każda warstwa poprawia wygodę obsługi, ale tworzy też kolejne miejsce, w którym aplikacja może wydawać się niedostępna, mimo że działa prawidłowo.

Przewodnik po homelabie pokazuje ścieżkę żądania przez DNS, routing, reverse proxy, aplikację oraz jej bazę danych lub zasób pamięci masowej. Ten warstwowy model ścieżki żądania pomaga początkującym oddzielić problemy z dostępem od problemów z aplikacją.

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

Trzymaj opcjonalne usługi ułatwiające obsługę poza podstawowymi ścieżkami

Pulpity nawigacyjne, indeksy wyszukiwania, przekaźniki powiadomień, grafiki multimediów i centralne uwierzytelnianie mogą poprawiać komfort użytkowania, ale nie powinny być niezbędne do zapewnienia dostępności podstawowych danych. Oznacz je jako opcjonalne zależności, aby awaria wygodnej funkcji powodowała ograniczenie funkcjonalności zamiast całkowitej przerwy w działaniu.

Poradnik TechTarget o odporności opisuje wzorzec izolacji jako oddzielenie części systemu, tak aby jedna awaria nie doprowadziła do całkowitej awarii. Ta zasada izolowania awarii przekłada się na prostą regułę dotyczącą domowego serwera: podstawowe ścieżki dostępu do pamięci masowej, kopii zapasowych i administracji muszą pozostać dostępne po zatrzymaniu opcjonalnych warstw.

Testuj środowisko, zatrzymując po jednej opcjonalnej usłudze naraz. Dostęp do współdzielonych plików powinien być możliwy, nawet gdy pulpit nawigacyjny przestanie działać. Lokalna administracja powinna pozostać możliwa po utracie zdalnego dostępu. Kopia zapasowa nie powinna zależeć od indeksu multimediów, a przywracanie nie powinno wymagać usługi powiadomień informującej o stanie kopii zapasowej.

Aktualizuj i twórz kopie zapasowe usług jako niezależnych jednostek odzyskiwania

Jedno okno serwisowe nie powinno wymagać jednoczesnej aktualizacji wszystkich aplikacji. Rozdziel definicje usług, dane trwałe i informacje o wersjach na tyle, by można było zabezpieczyć, zmienić, sprawdzić i przywrócić jedną aplikację bez modyfikowania niezwiązanych z nią obciążeń.

Backblaze przekonuje, że plan odzyskiwania jest tak dobry, jak jego ostatni test, i zaleca powtarzalne ćwiczenia odzyskiwania o ograniczonym zakresie. Taki test odzyskiwania poszczególnych usług sprawdzi się w niewielkim, samodzielnie hostowanym środowisku.

Przed aktualizacją wyeksportuj konfigurację, zabezpiecz odpowiednią bazę danych lub stan aplikacji i zanotuj bieżącą wersję. Następnie sprawdź działanie aplikacji na zwykłym koncie użytkownika i upewnij się, że zaplanowane zadania są wykonywane. Jeśli aktualizacja wymaga skoordynowanych zmian w kilku usługach, jawnie udokumentuj tę zależność, zamiast odkrywać ją podczas awarii.

Prowadź krótką ewidencję zależności obok wykazu usług. Dla każdej aplikacji zapisuj hosta, ścieżkę do pamięci masowej, bazę danych, nazwę lokalną, metodę uwierzytelniania i miejsce docelowe kopii zapasowych, których faktycznie potrzebuje. Opcjonalne integracje oznaczaj osobno. Gdy jeden komponent zostanie zastąpiony, zaktualizuj tylko te pozycje, które od niego zależą, i przeprowadź odpowiednie testy odzyskiwania danych. Dzięki temu wygodne wspólne narzędzie nie stanie się nieudokumentowanym fundamentem każdej kolejnej usługi.

Zacznij od podstawowego zestawu, który można rozbudowywać bez tworzenia łańcucha zależności

Trwały pierwszy zestaw zwykle obejmuje jedną warstwę systemową, jedną mapę pamięci masowej, jedną ścieżkę tworzenia kopii zapasowych i niewielką liczbę usług widocznych 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 ServeTheHome pokazuje, jak zaprojektować niewielki, dedykowany system z myślą o określonym zestawie zasobów obliczeniowych, pamięci masowej i sieciowych, zamiast rozbudowywać go w nieograniczoną platformę. Ten model serwera o jasno określonej roli jest lepszym punktem odniesienia dla początkujących niż jednoczesna instalacja wszystkich usług infrastrukturalnych.

Poradnik ZimaSpace dotyczący zbudowania pierwszego serwera wokół trzech połączonych usług pomaga ograniczyć początkowy zakres. Miniaturowy serwer domowy ZimaBoard 2 sprawdzi się w kompaktowym zestawie zorientowanym na aplikacje, z przemyślanym rozwiązaniem pamięci masowej i ograniczoną liczbą usług. ZimaCube 2 AI NAS będzie lepszą podstawą, gdy kluczowe wymagania obejmują już pamięć masową z wieloma dyskami, kilku domowników jako użytkowników, dłuższy okres przechowywania danych i odzyskiwanie danych z priorytetem dla pamięci masowej.

Ten stos jest przyjazny dla początkujących, gdy dodawanie, zatrzymywanie, aktualizowanie lub zastępowanie jednej usługi zmienia tylko jej własne dane i ścieżkę dostępu, zamiast wymuszać przenoszenie wraz z nią całego serwera domowego.