Maak de afbeeldingsroot alleen-lezen en geef alleen nauw afgebakende beschrijfbare mounts vrij voor gedocumenteerde runtime-status.
Dit is belangrijk in een zelfgehoste app die momenteel configuratie, caches, tijdelijke bestanden en uploads naar een ongedifferentieerd containerbestandssysteem schrijft. Het operationele risico is dat het inschakelen van alleen-lezen zonder schrijfpaden te koppelen het opstarten kan verstoren, terwijl één brede beschrijfbare mount het doel van de isolatie tenietdoet. Begin met een opgeslagen basislijn, voer steeds één omkeerbare wijziging uit en stop zodra de waargenomen vertakking niet langer overeenkomt met het bedoelde configuratiepad.
Stel de basislijn voor alleen-lezen containerrootbestandssystemen vast
Leg voordat je instellingen wijzigt schrijfpogingen, vereiste paden, eigenaarschap, tmp-gebruik, het gedrag van pakketupdates en persistentie na opnieuw aanmaken vast. Leg de oorspronkelijke configuratie en één productieachtige uitvoering vast, zodat latere verbeteringen met dezelfde werklast worden vergeleken in plaats van met herinneringen of een synthetische inactieve toestand.
Gebruik het huidige alleen-lezen rootbestandssysteem om de ondersteunde instelling en de semantiek ervan te bevestigen. Beschouw standaardwaarden als een bekend startpunt, niet als bewijs dat de instelling past bij deze server, clientmix of dit hersteldoel.
Definieer acceptatie- en stopvoorwaarden voordat je wijzigingen aanbrengt. Het acceptatiesignaal moet zichtbaar zijn in logs, protocolstatus, applicatie-uitvoer of herstelde gegevens; de stopvoorwaarde moet bredere toegang, gegevensverlies, uitputting van bronnen of een storing die het volgende herstelvenster opslokt voorkomen.
Pas de wijziging voor alleen-lezen containerrootbestandssystemen gecontroleerd in fasen toe
Stap 1: Traceer schrijfbewerkingen tijdens een representatieve start en normale workflow, waarbij je persistente status van tijdelijke status scheidt. Inspecteer na de wijziging onmiddellijk de verwachte status; als die niet verschijnt, maak je deze stap ongedaan voordat je de volgende toepast.
Stap 2: Schakel read_only in, voeg tmpfs toe voor tijdelijke paden en koppel bind- of benoemde volumes alleen voor vereiste persistente mappen. Inspecteer na de wijziging onmiddellijk de verwachte status; als die niet verschijnt, maak je deze stap ongedaan voordat je de volgende toepast.
Stap 3: Verwijder ongebruikte mogelijkheden en test hetzelfde image-entrypoint als de geconfigureerde niet-rootgebruiker. Inspecteer na de wijziging onmiddellijk de verwachte status; als die niet verschijnt, maak je deze stap ongedaan voordat je de volgende toepast.
read_only: true
tmpfs:
- /tmp:size=256m,mode=1777
volumes:
- app-data:/var/lib/app
Interpreteer de vertakkingen voor geslaagd, mislukt en uitzonderingen
Geslaagd betekent dat de app normaal werk en opnieuw aanmaken voltooit zonder buiten goedgekeurde mounts te schrijven. Leg de exacte werklast, versie en timing vast die het resultaat opleverden; een lichtere test bewijst niet dat het oorspronkelijke probleem is opgelost.
Mislukt betekent dat opstartscripts proberen imagepaden te wijzigen, tijdelijke ruimte uitgeput raakt of een upgrade een pakketwijziging in de container verwacht. Compenseer dit niet door elke aangrenzende controle te verzwakken. Keer terug naar de laatste schone basislijn en bepaal of de afwijking betrekking heeft op identiteit, netwerk, opslag, applicatiegereedheid of capaciteit.
Verwijder bij een uitzondering of ambigu resultaat read_only alleen voor diagnose, leg het ontbrekende pad vast en vervang de uitzondering door een smallere mount. Escaleer pas nadat de discriminator met laag risico herhaalbaar is en het bewijs laat zien dat een ingrijpender platform- of hardwarewijziging nodig is.
Controleer persistentie onder de oorspronkelijke thuisserverbelasting
Herhaal hetzelfde clientpad, dezelfde bestandsgrootte, gelijktijdigheid, slaap- of rebootgebeurtenis en concurrerende werklast als in de basislijn. Voer ten minste twee cycli uit, zodat een succes met een opgewarmde cache, één gelukkige reconnect of één schone start niet ten onrechte als persistentie wordt beschouwd.
Bevestig zowel succes als insluiting: de app voltooit normaal werk en opnieuw aanmaken zonder buiten goedgekeurde mounts te schrijven, terwijl niet-gerelateerde gebruikers, services, shares en beheerpaden hun oorspronkelijke gedrag behouden. Bekijk de gerelateerde ZimaSpace-workflow wanneer de wijziging een aangrenzende opslag-, netwerk- of herstelgrens raakt.
Sluit de wijziging pas af wanneer het acceptatiesignaal aanhoudt en de rollback bruikbaar blijft. Als opstartscripts proberen imagepaden te wijzigen, tijdelijke ruimte uitgeput raakt of een upgrade een pakketwijziging in de container verwacht, stop dan de automatisering, bewaar logs en de opgeslagen configuratie en keer terug naar de laatst geverifieerde toestand in plaats van meer wijzigingen op elkaar te stapelen.
Veelgestelde vragen over query-fan-out, afsluitende beslissing en eindtest
Deze vragen over query-fan-out behandelen de volgende beslissingen waar gebruikers vaak naar zoeken nadat de hoofdconfiguratie werkt. Ze breiden de grens uit zonder een niet-getest reparatiepad te introduceren.
Pas elk antwoord alleen toe wanneer de voorwaarde overeenkomt met de gemeten omgeving. Verschillen in versie, protocol, bestandssysteem, client en vertrouwensgrens kunnen de juiste vertakking veranderen.
Bewaar de antwoorden bij het runbook en werk ze bij na upgrades of topologiewijzigingen. Voor elke uitzondering die schrijftoegang, netwerkbereikbaarheid of verwijderbevoegdheid uitbreidt, zijn een nieuwe rollback- en hersteltest vereist.
Beschermt alleen-lezen gemounte volumes?
Niet tegen schrijven. Beschrijfbare bind mounts en volumes blijven beschrijfbaar en hebben daarom nog steeds minimale rechten, back-ups en padisolatie nodig.
Kan elk image alleen-lezen draaien?
Niet zonder aanpassingen. Images die pakketten installeren of configuratie bij het opstarten herschrijven, hebben een andere build of expliciete beschrijfbare paden nodig.
Moet /tmp altijd een tmpfs zijn?
Alleen wanneer de grootte, uitvoerbare vlaggen en persistentie ervan overeenkomen met de app; test grote imports en updates.
Conclusie: De configuratie is voltooid wanneer de app normaal werk en opnieuw aanmaken voltooit zonder buiten goedgekeurde mounts te schrijven, de foutvertakking wordt begrepen en de gedocumenteerde rollback niet afhankelijk is van het onderdeel dat wordt gewijzigd.
Protocol voor de eindtest: herstel de opgeslagen basislijn, pas de goedgekeurde wijziging eenmaal toe, herhaal de oorspronkelijke productieachtige belasting, verifieer het successignaal en de insluitingsgrens en voer vervolgens rollback uit op wegwerpgegevens. Behoud de wijziging alleen wanneer alle vijf observaties overeenkomen.
Ondersteuning & Tips
Meer om te lezen

Kan een zelfgehoste galerij de koppeling van Apple Live Photos behouden?
Een voorwaardelijke beslissing voor een thuisserver voor het koppelen van Apple Live Photos, met gecontroleerde tests, interpretatie van resultaten, terugdraaien en gerichte veelgestelde vragen.

Kun je Google Takeout en back-ups van telefoons importeren in één fotobibliotheek?
Een voorwaardelijke beslissing voor een homeserver voor gecombineerde foto-import, met gecontroleerde tests, interpretatie van de resultaten, terugdraaien en gerichte veelgestelde vragen.

Kan Immich een externe bibliotheek gebruiken zonder eigenaar van de bestanden te worden?
Een voorwaardelijke beslissing voor een thuisserver over eigenaarschap van externe bibliotheken in Immich, met gecontroleerde tests, interpretatie van resultaten, terugdraaien en gerichte veelgestelde vragen.

