Så bygger du en nybörjarvänlig appstack utan att göra varje tjänst till ett beroende

En nybörjarvänlig appstack är lätt att förstå när varje tjänst har ett enda syfte, äger sina egna data och kan sluta fungera utan att slå ut orelaterade funktioner i hushållet.

Faran beror inte enbart på antalet containrar. Komplexiteten uppstår när varje app är beroende av samma databas, autentiseringslager, omvänd proxy, DNS-tjänst, lagringssökväg, uppdateringsfönster och administratörskonto. Den första stacken bör därför ha en liten gemensam grund, hålla valfria bekvämligheter utanför viktiga tjänstevägar och tydligt dokumentera vilka komponenter som måste fungera igen innan varje app kan användas.

Utgå från hushållets behov i stället för en appkatalog

Lista de återkommande uppgifter som servern måste hantera innan du väljer programvara. En användbar första stack kan erbjuda säkerhetskopiering av enheter, en gemensam filplats och en valfri medietjänst eller instrumentpanel. För varje uppgift bör det finnas en namngiven användare, en dataägare, en godtagbar avbrottstid och en återställningsväg. Appar som inte bidrar till 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ändarnas krav. Denna karta över sambandet mellan användarkrav och komponenter är mer användbar än att behandla varje tillgänglig app som en fristående funktion.

Beskriv den första stacken som tre tjänsteavtal i stället för tre produktnamn. Definiera för varje avtal vilka data som kommer in, vilket resultat som kommer ut och vad hushållet kan göra när tjänsten inte är tillgänglig. Då behöver senare ersättningar inte tvinga fram en omdesign av hela servern.

Håll den delade grunden mindre än applikationslagret

Det är rimligt att dela viss infrastruktur. Flera webbappar kan använda samma värd, lagringspool, övervakningsmetod och lokala namngivningskonvention. Problemet uppstår när varje app kräver en central tjänst vars avbrott samtidigt slår ut all åtkomst, autentisering, namnuppslagning eller lagring.

TechTargets analys av cirkulära beroenden förklarar att tätt kopplade komponenter blir svåra att uppdatera, testa och driftsätta oberoende av varandra. Dess varning för beroendecykler gäller även en hemserver, trots att stacken är mycket mindre.

Använd den minsta gemensamma grund som behövs i dag. En omvänd proxy, ett centralt identitetslager eller en intern DNS-tjänst bör läggas till för att flera stabila appar har nytta av den – inte för att ett diagram ser mer komplett ut med ännu en ruta.

Ge varje tjänst en tydlig dataägare och beständig sökväg

En app bör inte upptäcka sin lagring av en slump. Ange vilken sökväg som innehåller konfigurationen, vilken som innehåller databasen, vilken som innehåller hushållsfiler och vilken som innehåller tillfällig cache. Två tjänster kan läsa samma mediebibliotek, men de bör inte båda äga metadatabasen eller ha bred skrivåtkomst till 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 här fristående modellen för datalivscykeln är grunden för att byta ut en app utan att skapa oklarhet kring dess data.

Använd lättbegripliga värdsökvägar som /srv/appdata/service, /srv/data/service och /srv/cache/service. Dokumentera ägare, skrivbehörigheter, säkerhetskopieringsregel och återställningsmetod för varje sökväg. Delade hushållsdata bör ha en enda auktoritativ plats även när flera appar indexerar eller visar dem.

Featured

ZimaCube 2 personlig moln-NAS för hemmet

ZimaCube2

$799.00 - $2,499.00

Buy Now

Bygg åtkomstvägar som försämras gradvis

En nybörjare börjar ofta med lokala IP-adresser och portar, lägger sedan till lokal DNS, HTTPS, en omvänd proxy och fjärråtkomst. Varje lager gör användningen enklare, men skapar också ytterligare ett ställe där en app kan verka otillgänglig trots att själva applikationen fungerar.

En hemmaserverguide visar förfrågningsvägen genom DNS, routing, en omvänd proxy, applikationen och dess databas- eller lagringsberoende. Den här skiktade modellen för förfrågningsvägen hjälper en nybörjare att skilja åt problem med åtkomst och problem med applikationen.

Ge varje viktig tjänst ett stabilt lokalt namn, men dokumentera även en direktadress för återställning. Fjärråtkomst ska inte krävas för att administrera servern inifrån huset. Routern, DNS-uppslagningen och autentiseringssystemet ska 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, omslagsbilder för media och central autentisering kan förbättra användarupplevelsen utan att vara nödvändiga 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 begränsad funktionalitet i stället för ett fullständigt avbrott.

TechTargets guide om motståndskraft beskriver bulkhead-mönstret som ett sätt att isolera delar av ett system så att ett fel inte sprider sig och orsakar ett totalt avbrott. Den här principen om felisolering kan omsättas i en enkel regel för hemmet: viktiga sökvägar för lagring, säkerhetskopiering och administration måste fortsätta fungera när valfria lager stoppas.

Testa lösningen genom att stoppa en valfri tjänst åt gången. Delade filer ska fortfarande gå att nå när instrumentpanelen slutar fungera. Lokal administration ska fortfarande vara möjlig när fjärråtkomsten 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 ska 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 arbetsbelastningar påverkas.

Backblaze menar att en återställningsplan bara är så bra som det senaste testet och rekommenderar återkommande återställningsövningar med begränsad omfattning. Den här återställningsövningen tjänst för tjänst passar bra för en liten självhostad lösning.

Före en uppdatering exporterar du konfigurationen, skyddar den berörda databasen eller appens tillstånd och antecknar den aktuella versionen. Efteråt testar du appen med ett vanligt användarkonto och kontrollerar de schemalagda jobben. Om en uppdatering kräver samordnade ändringar i flera tjänster dokumenterar du det beroendet uttryckligen i stället för att upptäcka det under ett avbrott.

För en enkel beroendelogg bredvid tjänstförteckningen. Anteckna för varje app vilken värd, lagringssökväg, databas, lokalt namn, autentiseringsmetod och säkerhetskopieringsdestination den faktiskt behöver. Markera valfria integrationer separat. När en komponent byts ut uppdaterar du bara de rader som är beroende av den och kör motsvarande återställningskontroller. Då undviker du att ett praktiskt delat 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 lagringsöversikt, en säkerhetskopieringsväg och ett litet antal tjänster för användarna. Lägg till delad infrastruktur först när två eller fler stabila appar behöver den och återställningsvägen fortfarande är begriplig utan den.

ServeTheHomes projekt för en kompakt server visar hur ett litet dedikerat system kan utformas kring en tydligt definierad kombination av beräkningskapacitet, lagring och nätverk i stället för att växa till en plattform utan tydliga gränser. Denna servermodell med tydligt avgränsad roll är en bättre referens för nybörjare än att installera alla infrastrukturtjänster på en gång.

ZimaSpaces guide om att bygga en första server kring tre sammankopplade tjänster hjälper dig att hålla den inledande omfattningen hanterbar. En ZimaBoard 2 minihemmaserver passar en kompakt, appbaserad stack med genomtänkt lagring och ett begränsat antal tjänster. En ZimaCube 2 AI-NAS är en tydligare bas när lagring på flera enheter, flera hushållsanvändare, längre lagringstid och lagringscentrerad återställning redan är centrala krav.

Stacken är nybörjarvänlig när en tjänst kan läggas till, stoppas, uppdateras eller bytas ut utan att det påverkar något annat än dess egna data och åtkomstväg, i stället för att hela hemmaservern måste ändras.