Så bygger du en nybörjarvänlig appstack utan att göra varje tjänst till ett beroende
En nybörjarvänlig appstack förblir lätt att förstå när varje tjänst har ett syfte, äger sina data och kan sluta fungera utan att inaktivera orelaterade funktioner i hushållet.
Faran ligger inte enbart i antalet containrar. Komplexitet uppstår när varje app är beroende av samma databas, autentiseringslager, omvända proxy, DNS-tjänst, lagringssökväg, uppdateringsfönster och administratörskonto. Den första stacken bör därför använda en liten delad grund, hålla valfria bekvämligheter utanför de centrala tjänstevägarna och dokumentera exakt vilka komponenter som måste vara tillbaka innan varje app kan användas.
Börja med hushållets behov i stället för en appkatalog
Lista de återkommande uppgifter som servern måste stödja innan du väljer programvara. En användbar första stack kan erbjuda säkerhetskopiering av enheter, en gemensam plats för filer och en valfri medie- eller instrumentpanelstjänst. Varje uppgift bör ha en namngiven användare, en dataägare, ett acceptabelt avbrott och en återställningsväg. Appar som inte stöder något av dessa resultat hör hemma på en senare lista.
TechTarget definierar applikationsarkitektur som en strukturell karta över hur applikationer samverkar med middleware, databaser och andra applikationer för att uppfylla användarkrav. Den karta från användarkrav till komponenter är mer användbar än att betrakta varje tillgänglig app som en oberoende funktion.
Skriv den ursprungliga stacken som tre tjänstekontrakt i stället för tre produktnamn. Definiera för varje kontrakt vilka data som kommer in, vilket resultat som lämnas ut och vad hushållet kan göra när tjänsten inte är tillgänglig. Då kan senare ersättningar genomföras utan att hela servern måste byggas om.
Håll den delade grunden mindre än applikationslagret
Viss delad infrastruktur är rimlig. Flera webbappar kan använda samma värd, lagringspool, övervakningsmetod och lokala namnkonvention. Problemet uppstår när varje app kräver en central tjänst vars fel samtidigt tar bort all åtkomst, autentisering, namnupplösning eller lagring.
TechTargets analys av cirkulära beroenden förklarar att tätt kopplade komponenter blir svåra att uppdatera, testa och distribuera oberoende av varandra. Dess varning för beroendecykler gäller även för en hemmaserver, trots att stacken är mycket mindre.
| Delad komponent | Rimlig första användning | Beroendegräns |
|---|---|---|
| Värdoperativsystem | Kör flera betrodda tjänster | Håll applikationstillstånd utanför systemlagret |
| Lagringspool | Tillhandahåller stabila datamängder | Separera applikationstillstånd, användardata och säkerhetskopieringsmål |
| Reverse proxy | Tillhandahåller minnesvärda lokala namn | Behåll en direkt lokal återställningsväg |
| Enkel inloggning | Lägg till efter att stacken är stabil | Gör den aldrig till den enda vägen till administration |
Använd den minsta gemensamma grund som behövs i dag. En reverse proxy, ett centralt identitetslager eller en intern DNS-tjänst bör läggas till eftersom flera stabila appar har nytta av den – inte för att ett diagram ser mer komplett ut med ytterligare en ruta.
Ge varje tjänst en tydlig dataägare och en beständig sökväg
En app bör inte upptäcka sin lagring av en slump. Definiera vilken sökväg som innehåller konfiguration, vilken som innehåller databasen, vilken som innehåller hushållsfiler och vilken som innehåller cache som kan raderas. Två tjänster kan läsa samma mediebibliotek, men de bör inte båda äga metadatadatabasen eller skriva brett över hela lagringspoolen.
Better Stack förklarar att beständiga containerdata behöver en livscykel som är fristående från containern som använder dem. Den oberoende livscykelmodellen för data är grunden för att ersätta en app utan att göra dess data tvetydiga.
Använd lättlästa värdsökvägar som /srv/appdata/service, /srv/data/service, och /srv/cache/service. Ange ägare, skrivbehörigheter, säkerhetskopieringsregel och återställningsmetod för varje. Delade hushållsdata bör ha en auktoritativ plats även när flera appar indexerar eller visar dem.
Bygg åtkomstvägar som försämras på ett kontrollerat sätt
En nybörjare börjar ofta med lokala IP-adresser och portar, och lägger sedan till lokal DNS, HTTPS, en reverse proxy och fjärråtkomst. Varje lager förbättrar användarvänligheten, men skapar också ytterligare ett ställe där en app kan verka otillgänglig trots att själva applikationen fungerar som den ska.
En homelab-guide beskriver begärans väg genom DNS, routing, en reverse proxy, applikationen och dess databas- eller lagringsberoende. Den skiktade modellen för begärans väg hjälper nybörjare att skilja åtkomstproblem från applikationsproblem.
Ge varje viktig tjänst ett stabilt lokalt namn, men behåll en dokumenterad direktadress för återställning. Fjärråtkomst ska inte krävas för att administrera servern inifrån huset. Routern, DNS-uppslagstjänsten och autentiseringssystemet bör inte alla vara beroende av samma experimentella tjänstekedja.
Håll valfria bekvämlighetstjänster utanför viktiga sökvägar
Instrumentpaneler, sökindex, aviseringsreläer, medieomslag och central autentisering kan förbättra upplevelsen utan att krävas för att underliggande data ska förbli tillgängliga. Markera dessa som valfria beroenden så att ett fel i ett bekvämlighetslager leder till minskad funktionalitet i stället för ett fullständigt avbrott.
TechTargets resiliensguide beskriver skottmönstret som att delar av ett system isoleras så att ett fel inte sprider sig till ett totalt haveri. Den principen om felisolering kan omsättas till en enkel hemregel: viktiga lagrings-, säkerhetskopierings- och administrationsvägar måste förbli användbara när valfria lager stoppas.
Testa stacken genom att stoppa en valfri tjänst i taget. Delade filer ska fortfarande vara åtkomliga när instrumentpanelen slutar fungera. Lokal administration ska fortfarande vara möjlig när fjärråtkomst slutar fungera. En säkerhetskopia ska inte vara beroende av medieindexet, och en återställning ska inte kräva aviseringstjänsten som rapporterar säkerhetskopieringsstatus.
Uppdatera och säkerhetskopiera tjänster som oberoende återställningsenheter
Ett underhållsfönster bör inte kräva att alla appar uppdateras samtidigt. Håll tjänstedefinitioner, beständigt tillstånd och versionsinformation tillräckligt åtskilda så att en app kan skyddas, ändras, valideras och återställas utan att orelaterade arbetslaster ändras.
Backblaze hävdar att en återställningsplan bara är så stark som dess senaste test och rekommenderar upprepningsbara återställningsövningar med begränsad omfattning. Den återställningsövningen tjänst för tjänst passar för en liten självhostad stack.
Före en uppdatering exporterar du konfigurationen, skyddar den relevanta databasen eller appens tillstånd och antecknar den aktuella versionen. Efteråt validerar du appen från ett vanligt användarkonto och bekräftar dess schemalagda jobb. Om en uppdatering kräver samordnade ändringar i flera tjänster ska du dokumentera beroendet tydligt i stället för att upptäcka det under ett driftavbrott.
Ha en liten beroendeförteckning bredvid tjänsteinventeringen. Anteckna för varje app vilken värd, lagringssökväg, databas, lokalt namn, autentiseringsmetod och säkerhetskopieringsdestination den faktiskt kräver. Markera valfria integrationer separat. När en komponent ersätts uppdaterar du bara de rader som är beroende av den och kör de återställningskontrollerna. På så sätt förhindrar du att ett praktiskt gemensamt verktyg blir en odokumenterad grund för varje senare tillagd tjänst.
Använd en startstack som kan växa utan att bli en kedja
En hållbar första stack består vanligtvis av ett systemlager, en lagringskarta, en säkerhetskopieringsväg och ett litet antal användartjänster. Lägg till gemensam infrastruktur först när två eller fler stabila appar behöver den och återställningsvägen fortfarande är begriplig utan den.
ServeTheHomes projekt med en kompakt server visar hur ett litet dedikerat system kan utformas kring en definierad kombination av beräkningskapacitet, lagring och nätverk i stället för att byggas ut till en obegränsad plattform. Den rollavgränsade servermodellen är en bättre referens för nybörjare än att installera alla infrastrukturtjänster på en gång.
Guiden från ZimaSpace om att bygga en första server kring tre sammankopplade tjänster hjälper dig att hålla den första omfattningen avgränsad. En ZimaBoard 2 Mini-hemmaserver passar en kompakt appfokuserad stack med genomtänkt lagring och ett begränsat antal tjänster. En ZimaCube 2 AI-NAS blir en tydligare bas när lagring med flera enheter, flera användare i hushållet, längre lagringstid och återställning med fokus på lagringen redan är centrala krav.
Stacken är nybörjarvänlig när det räcker att lägga till, stoppa, uppdatera eller ersätta en tjänst för att bara dess egna data och åtkomstväg ska påverkas, i stället för att hela hemmaservern måste flyttas med.
Rekommenderade produkter
NAS- och serverinstallation
Mer att läsa
Hur mycket lagringskapacitet bör du köpa för fem års foton?
Ett femårigt fotoarbetsblad som ersätter generiska uppskattningar med uppmätt hushållstillväxt, användbart lagringsutrymme, återställningskopior och en tidig tröskel för utbyggnad.
Hur många enhetsfack behöver en NAS för familjebackup?
Ett ramverksystem för antal diskfack som skiljer mellan enkelheten hos två fack, tillväxt med fyra fack och behovet av fler fack för långtidslagring, samtidigt...
Räcker 16 GB RAM för en hemmaserver som kör tio containrar?
Ett minnestest på 16 GB som dimensionerar efter applikationer i stället för antal containrar och fastställer när övervakning, begränsningar, schemaläggning eller en uppgradering krävs.
