Så driftar du File Browser själv 2026: volymer, konton och säker delning

Betrakta File Browser som ett litet system, inte som en Docker-avbild. Målet för användaren är tydligt: en webbaserad filhanterare för en ansluten volym. Driftsättningen är godtagbar först när du kan skapa en begränsad användare, ladda upp och byta namn på en fil, redigera text, skapa en delning och bekräfta att användaren inte kan lämna sin tilldelade rotkatalog.

Den distinktionen fångar det fel som operatörer stöter på efter lokala tester: de monterade filerna använder behörigheter på värden som containern inte kan läsa. Den gör också planen för säkerhetskopiering och uppgraderingar tillräckligt specifik för att kunna testas.

Hitta alla beständiga data i File Browser

En containeravbild kan laddas ned igen, men de visade filerna samt File Browsers databas och inställningar kan inte det. Montera /srv före bootstrap, skriv ofarliga exempeldata och byt ut containern för att bevisa att sökvägen faktiskt är beständig. Inspektera den effektiva monteringen i stället för att lita på ett Compose-filnamn, och kontrollera att runtime-användaren kan skriva där File Browser förväntar sig det.

Välj retention och en destination utanför värden, och öva sedan på återställning utan att röra produktionen. Övningen är godkänd först när de visade filerna, användarna, åtkomstomfången, delningarna och inställningarna återkommer och ett begränsat konto fortfarande är begränsat till rätt område. För databasbaserat tillstånd kombinerar du snapshots av lagringen med applikationskonsistenta exporter enligt beskrivningen i återställning till en tidpunkt jämfört med snapshots.

Kör den första produktionsliknande instansen

Gör den första File Browser-starten tillräckligt reproducerbar för att kunna granskas i en pull request.

docker run -d \
  --name file-browser \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v file-browser-data:/srv \
  -v file-browser-db:/database \
  -v file-browser-config:/config \
  filebrowser/filebrowser:latest

Förlita dig inte på latest när riktiga data finns. Dokumentera den fungerande digesten, containeranvändaren och monteringsägarskapet. Följ applikationsloggen genom ett fullständigt test — skapa en begränsad användare, ladda upp och byt namn på en fil, redigera text, skapa en delning och bekräfta att användaren inte kan lämna sin tilldelade rotkatalog — och notera eventuella migreringar innan du lägger routen bakom produktionstrafik.

Dra gränsen för File Browsers runtime

Processhälsa och produkthälsa är separata i File Browser. Port 80 kan svara samtidigt som transaktionen ur användarens perspektiv fortfarande misslyckas. Det lokala runtime-kravet är en separat beständig sökväg för databasen och inställningarna. Validera den under den avsedda belastningen; en health check i viloläge kan inte bevisa att resursen räcker till.

Använd den här readiness-övningen efter meningsfulla konfigurationsändringar: skapa en begränsad användare, ladda upp och byt namn på en fil, redigera text, skapa en delning och bekräfta att användaren inte kan lämna sin tilldelade rotkatalog. Lägg inte kostsamma externa kontroller i liveness-prober, så att ett avbrott hos en leverantör inte orsakar en omstartsloop. Kapacitetsarbetet bör följa den underliggande diskgenomströmningen, uppladdningsstorleken, antalet samtidiga nedladdningar och antalet kataloger, eftersom det bättre speglar File Browsers verkliga belastning än sidförfrågningar.

Gör den publika origin-adressen entydig

Exponera ett HTTPS-värdnamn för File Browser och håll råport 80 privat. Publicera gränssnittet över HTTPS, men begränsa den visade roten noggrant. Då slipper webbläsare och API-klienter lära sig två konkurrerande adresser.

Kör den kända fungerande transaktionen från en ren klient och inspektera den första förfrågan som misslyckas. Använd guiden för anpassade domäner när DNS eller TLS är fel. Betrakta ”de monterade filerna använder behörigheter på värden som containern inte kan läsa” som en separat applikationsdiagnos när routen väl är bekräftad.

Go/no-go-grind för File Browser

Skapa en liten, temporär File Browser-fixture och behåll den för varje release. Fixturen ska testa det verkliga arbetsflödet: skapa en begränsad användare, ladda upp och byt namn på en fil, redigera text, skapa en delning och bekräfta att användaren inte kan lämna sin tilldelade rotkatalog. Dokumentera avbildens digest, externa värdnamn, beroendeadress och förväntat resultat, så att nästa operatör kan upprepa testet utan att behöva tolka den här guiden.

Kör fixturen tre gånger. Använd först den nya driftsättningen. Byt sedan ut containern utan att röra beständiga data. Återställ slutligen säkerhetskopian till en tom miljö. Den tredje körningen är godkänd först när de visade filerna, användarna, åtkomstomfången, delningarna och inställningarna återkommer och ett begränsat konto fortfarande är begränsat till rätt område. Fånga underliggande diskgenomströmning, uppladdningsstorlek, samtidiga nedladdningar och antal kataloger under varje körning, tillsammans med svarstider och resursanvändning. Det blir baslinjen för larm i stället för en godtycklig CPU-procent.

Testa slutligen den negativa vägen medvetet: skicka ofarlig indata nära resurs- eller formatgränsen som hör till den här gränsen: de monterade filerna använder behörigheter på värden som containern inte kan läsa. Bekräfta att File Browser misslyckas tydligt utan att tillståndet skadas, återställ rätt förutsättning och upprepa den lyckade transaktionen. En releasepost med dessa fyra resultat är starkare bevis än skärmbilder av en dashboard eller ett engångssvar från curl.

Kontroller av kapacitet och uppgraderingar

En health check i viloläge säger inte mycket om File Browser. Övervaka underliggande diskgenomströmning, uppladdningsstorlek, samtidiga nedladdningar och antal kataloger, och larma på det symptom som användarna upplever: att åtgärden ”skapa en begränsad användare, ladda upp och byt namn på en fil, redigera text, skapa en delning och bekräfta att användaren inte kan lämna sin tilldelade rotkatalog” misslyckas. Håll liveness lokal och billig; låt readiness rapportera migreringar eller initiering utan att orsaka en omstartsstorm.

Det riskfyllda vid uppgraderingar är att migreringar av File Browsers databas och inställningar spelar roll även om de visade filerna ligger på en separat montering. Läs release notes, skapa en snapshot av tillståndet, driftsätt målversionen mot en återställd kopia och upprepa acceptanstestet. Om de monterade filerna använder behörigheter på värden som containern inte kan läsa, kopplar du klientförfrågan till den första relevanta applikationsloggen i stället för att radera tillstånd eller lägga till omdirigeringar på måfå.

Minska den behörighet som File Browser har

Bootstrap-uppgifter är tillfälliga; trust-modellen är permanent. I File Browser bör du se upp med att exponera / eller en katalog med secrets i stället för en dedikerad delning. Använd en dedikerad katalog i stället för värdens rotkatalog och ge varje konto det snävaste filomfång det behöver.

File Browser har ingen obligatorisk bootstrap-hemlighet i den här baslinjen. Skydda i stället det faktiska administratörskontot eller autentiseringen uppströms. Kör avbilden utan onödiga Linux capabilities och exponera endast den publika applikationsrouten. Gör administratörsaktivitet synlig utan att logga hemliga värden.

Använd Dockup för plattformslagret

För File Browser är Dockup mest användbart i gränsen mellan en avbild och en beständig tjänst. Det håller routen till port 80, TLS, hemliga värden och ansluten lagring intakta vid containerbyten, oavsett om beräkningsresurserna tillhandahålls av Dockup eller av din anslutna server.

Avsluta med applikationsspecifik kunskap: publicera gränssnittet över HTTPS, men begränsa den visade roten noggrant; bekräfta det lokala kravet — en separat beständig sökväg för databasen och inställningarna — och kör den här verifieringen: skapa en begränsad användare, ladda upp och byt namn på en fil, redigera text, skapa en delning och bekräfta att användaren inte kan lämna sin tilldelade rotkatalog. Spara resultatet som en driftsättningskontroll, så att nästa uppdatering av avbilden bedöms utifrån beteende i stället för containerstatus.

Vanliga frågor

Vad behöver File Browser för en produktionsdriftsättning?

Routa File Browser-containern på port 80 via en enda HTTPS-origin. Det lokala runtime-kravet är en separat beständig sökväg för databasen och inställningarna. Kalla inte File Browser redo förrän du kan skapa en begränsad användare, ladda upp och byta namn på en fil, redigera text, skapa en delning och bekräfta att användaren inte kan lämna sin tilldelade rotkatalog.

Vilka File Browser-data ska ingå i en säkerhetskopia?

Gör /srv beständig och inkludera de visade filerna samt File Browsers databas och inställningar i samma återställningsmanifest. En ren File Browser-återställning är godkänd först när de visade filerna, användarna, åtkomstomfången, delningarna och inställningarna återkommer och ett begränsat konto fortfarande är begränsat till rätt område.

Kräver File Browser HTTPS bakom en reverse proxy?

Använd HTTPS för den publika File Browser-originen och behåll port 80 på den interna routen. Tillämpa File Browser-inställningen korrekt: publicera gränssnittet över HTTPS, men begränsa den visade roten noggrant. För File Browser skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och håller klientbeteende som är känsligt för origin konsekvent.

Hur bör en uppgradering av File Browser testas?

Återställ det aktuella File Browser-tillståndet till en isolerad driftsättning, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom migreringar av File Browsers databas och inställningar spelar roll även om de visade filerna ligger på en separat montering. Behåll den tidigare File Browser-avbilden tills gränsen för datamigrering och rollback är klarlagd.