Twintig jaar zelf hosten: waarom u/jc-21 een klein homelab onderhoudt

Eva Wong

IceWhale author

Eva Wong is de technisch schrijver en vaste knutselaar bij ZimaSpace. Als levenslange geek met een passie voor homelabs en open-sourcesoftwareis ze gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva vindt dat self-hosting leuk moet zijn en niet intimiderend. Met haar tutorials helpt ze de community om hardware-installaties te doorgronden, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Official Nginx Proxy Manager proxy-host list screenshot

Omslagafbeelding: Raspberry Pi — officiële productfoto van de Raspberry Pi 5.

Een goed homelab heeft een vast ritme. De diensten voor het huishouden werken, de eigenaar weet waar de belangrijke gegevens staan en een experiment kan wachten tot de mensen die het netwerk gebruiken klaar zijn met hun dag. Dat is het soort vooruitgang waarover we wilden horen toen we de community uitnodigden om verhalen te delen over hun Self-Hosting Day.

In de bijdrage van u/jc-21 leiden zo’n twintig jaar experimenteren terug naar een bewust kleinschalige installatie op basis van Linux. De reageerder beschrijft een FriendlyWrt-router, een Raspberry Pi 5 voor dagelijkse diensten, waaronder AdGuard en Nginx Proxy Manager, en een NAS voor zwaardere workloads of workloads die minder geschikt zijn voor ARM, zoals Plex. Kleine computers en netwerkapparatuur zijn aangesloten op een UPS. De auteur noemt zichzelf ook de maker van Nginx Proxy Manager en verbindt zo een persoonlijke behoefte aan eenvoudigere toegang met een opensourceproject.

“Mijn lab is klein, praktisch en saai op de best mogelijke manier”
u/jc-21

De architectuurupgrade zorgt voor een duidelijkere verdeling van verantwoordelijkheden

Vanuit het perspectief van ZimaSpace is het idee dat je kunt toepassen de scheiding van verantwoordelijkheden. Een kern van dagelijkse diensten heeft een andere onderhoudsroutine nodig dan een machine die wordt gebruikt voor opslagexperimenten of veeleisende applicaties. Zodra die rollen duidelijk zijn, worden hardwarekeuzes makkelijker uit te leggen: wat moet beschikbaar blijven, wat heeft meer capaciteit nodig en wat kan opnieuw worden gestart zonder het werk van iemand anders te onderbreken?

Begin met afhankelijkheden in plaats van met de lijst met containers. Een applicatie kan correct werken, terwijl gebruikers er geen toegang toe hebben omdat een naam niet meer wordt omgezet of de gekozen toegangsroute niet beschikbaar is. Maak een kort overzicht van een gebruikersactie tot de diensten die deze ondersteunen. Dat overzicht kan een pagina met aantekeningen zijn. De waarde ervan zit in het nauwkeurig genoeg beschrijven van het systeem, zodat onderhoud geen gokwerk meer is.

Een praktische planningskaart voor een klein homelab

Verantwoordelijkheid	Planningsvraag	Een bruikbaar overzicht
Dagelijkse diensten	Wat heeft het huishouden nodig tijdens een gewone dag?	Een afhankelijkheidskaart en een controle op cliëntniveau.
Applicaties	Welke workloads hebben eigen resources of onderhoudsmomenten nodig?	Versie, configuratielocatie en herstartprocedure.
Gedeelde gegevens	Waar staan de gezaghebbende bestanden en wie mag ze wijzigen?	Opslagindeling en toegangsbeslissingen.
Herstel	Wat blijft behouden als een apparaat uitvalt of een wijziging wordt onderbroken?	Een onafhankelijke kopie en een vastgelegd herstelresultaat.

Geef de dagelijkse basis een voorspelbaar onderhoudsschema

Een kleine, altijd ingeschakelde basis wordt nuttig wanneer die zich voorspelbaar gedraagt. Wijs aan elke essentiële dienst een eigenaar toe, leg vast waar de configuratie staat en bepaal hoe je kunt controleren of de dienst echt doet wat die moet doen. Controleer bij een DNS-dienst bijvoorbeeld vanaf een client een representatieve opzoeking. Open bij een huishoudelijke applicatie de applicatie via de route die mensen normaal gebruiken. Een indicator dat het proces actief is, is slechts één onderdeel van die controle.

Houd wijzigingen bescheiden genoeg om ze terug te kunnen draaien. Noteer de huidige applicatieversie en bewaar de configuratie voordat je een update uitvoert. Kies een onderhoudsvenster dat past bij de mensen die het systeem gebruiken en controleer daarna of alles voor de gewone client nog goed werkt. Dit zijn gebruikelijke werkwijzen die een kleine installatie kan toepassen zonder een uitgebreid beheerplatform op te zetten. Een goede maatstaf is hoe goed de eigenaar een wijziging kan uitleggen en herstellen.

Officiële lijst met proxyhosts van Nginx Proxy Manager — De lijst met proxyhosts van het project maakt bestemmingen op één plek zichtbaar; houd ook de context van de bijbehorende applicaties en toegang bij. Afbeelding: Nginx Proxy Manager-project.

Een reverseproxy verdient een eigen plek op de dienstenkaart

De officiële projectdocumentatie van Nginx Proxy Manager beschrijft een grafische aanpak voor proxyhosts en certificaatbeheer. Dat maakt het een handig voorbeeld van een dienst waarvan de configuratie verbinding maakt met verschillende andere applicaties. Houd bij welke hostnaam naar welke bestemming leidt, waar de applicatie zelf gegevens opslaat en welk account de toegang beheert.

Een gebruiksvriendelijke proxyinterface neemt niet weg dat je de achterliggende applicatie moet begrijpen. Bekijk elke route als een volledig pad: client, naam, proxy, bestemming en applicatieaccount. Bepaal bewust welke routes op het lokale netwerk horen en welke via een privétoegang op afstand lopen. Verhuist een applicatie naar een andere machine, werk die kaart dan bij en test het opgeslagen adres vanaf een echte client voordat je de migratie als voltooid beschouwt.

Officieel configuratieformulier voor proxyhosts van Nginx Proxy Manager — Het officiële voorbeeld van de proxyhostconfiguratie van Nginx Proxy Manager toont de bestemmingsinstellingen die in het serviceoverzicht thuishoren. Afbeelding: Nginx Proxy Manager-project.

Plan de stroomvoorziening en het herstel rond de services die mensen opmerken

In een plan voor storingen moet staan wat bruikbaar blijft als een onderdeel van het systeem uitvalt. Bepaal welke apparaten nodig zijn om die route werkend te houden, inclusief relevante netwerkapparatuur, in plaats van alleen de server mee te tellen. Meet bij gebruik van een UPS de werkelijke belasting van de aangesloten apparaten en test het beoogde gedrag bij uitschakeling. De gebruiksduur hangt af van de accu, de belasting en de configuratie; stel die vast voor de installatie in plaats van af te gaan op de grootte van een apparaat.

Zorg dat herstelinstructies ergens beschikbaar zijn buiten de service waarop ze betrekking hebben. Een netwerkdiagram dat alleen toegankelijk is via een defecte inlogservice is juist op het verkeerde moment onhandig. Bewaar een toegankelijke kopie van belangrijke notities, een gedocumenteerde route naar de back-up en een procedure om het systeem in een logische volgorde weer op te starten. Zo is een gewone onderbreking thuis gemakkelijker op te vangen, zonder dat elke storing leidt tot een avond lang alles opnieuw uitzoeken.

Waar past de ZimaCube 2 als de gegevenslaag groeit?

Voor lezers die een vergelijkbare taakverdeling willen toepassen, kan een persoonlijke cloud-NAS ZimaCube 2 de gedeelde gegevenslaag vormen naast een bestaande machine voor dagelijkse services. Dit is ons advies voor de hardwareplanning: de bijdrage van de community beschrijft een andere installatie. Bewaar media, projectbestanden en applicatiegegevens die je wilt behouden op duidelijk beheerde locaties en bepaal welke clients en services toegang nodig hebben tot elk gebied.

De schijflades en uitbreidingsmogelijkheden voor M.2 van de ZimaCube 2 bieden ruimte om een groeiende verzameling in te richten voor verschillende opslagrollen. Stem de configuratie af op de gegevens die je wilt bewaren, de services die daadwerkelijk draaien en de onafhankelijke back-up die je wilt onderhouden. Gegevens naar een grotere behuizing verplaatsen betekent niet dat je alle huishoudelijke services tegelijk hoeft over te zetten. Een gefaseerde overdracht houdt het huidige systeem overzichtelijk terwijl de opslagrol zich verder ontwikkelt.

Officiële vooraanzicht van de zilveren ZimaCube 2, een persoonlijke cloud-NAS — Officiële productfoto van de ZimaCube 2, ter illustratie van de optie voor gedeelde opslag die wordt besproken in de planningsnotities van ZimaSpace. Afbeelding: ZimaSpace.

Maak van de volgende upgrade een overdracht die je kunt uitleggen

Kies één collectie of applicatierecord voor een testmigratie. Behoud de huidige locatie, kopieer het naar de voorgestelde bestemming en controleer de toegang via de beoogde client. Leg eventuele wijzigingen aan paden of accounts vast en herstel vervolgens een voorbeeld uit de back-up naar een aparte locatie. Een overzetting is overtuigender als iemand anders dezelfde informatie kan vinden en kan zien welke kopie de gezaghebbende versie is.

Laat een korte overdrachtsnotitie achter over het systeem: dagelijkse services, gedeelde opslag, herstelkopie en de wijzigingen die nog worden getest. Voor een uitgebreider voorbeeld van virtualisatie laat onze Proxmox-communitybuild met ZimaBoard 2 een andere manier zien om een groeiend lab in te richten. Het doel is dezelfde helderheid: een systeem dat bruikbaar blijft terwijl de eigenaar blijft leren.

De les van Self-Hosting Day

Voor Self-Hosting Day is de belangrijkste les een werkprincipe: zorg dat het dagelijkse systeem begrijpelijk genoeg is om erop te vertrouwen, en houd een aparte plek vrij om te experimenteren. Een compacte servicekern en een goed beheerde gegevenslaag kunnen in een verschillend tempo groeien.

Ontdek verder

Oorspronkelijk verhaal en projectverwijzingen

Gebaseerd op de hierboven gelinkte bijdrage aan Self-Hosting Day. De architectuurinterpretatie en notities voor de hardwareplanning zijn van ZimaSpace. Screenshots en productillustraties zijn toegeschreven aan de oorspronkelijke projecten of fabrikanten.