Jak provozovat File Browser na vlastní infrastruktuře v roce 2026: svazky, účty a bezpečné sdílení

Vnímejte File Browser jako malý systém, ne jako Docker image. Cíl z pohledu uživatele je jasný: webový správce souborů nad připojeným svazkem; nasazení je přijatelné pouze tehdy, když dokážete vytvořit uživatele s omezenými právy, nahrát a přejmenovat soubor, upravit text, vygenerovat sdílení a ověřit, že uživatel nemůže opustit svůj přiřazený root.

Toto rozlišení odhaluje typický problém, na který operátoři narazí po lokálním testování: připojené soubory používají oprávnění hostitele, ke kterým kontejner nemá přístup. Zároveň díky němu získáte dostatečně konkrétní plán zálohování a aktualizací, který lze otestovat.

Najděte všechna trvalá data ve File Browser

Docker image lze znovu stáhnout; poskytované soubory ani databázi a nastavení File Browser nikoli. Připojte /srv ještě před bootstrapem, zapište neškodná ukázková data a nahraďte kontejner, abyste ověřili, že je tato cesta skutečně persistentní. Zkontrolujte skutečně aktivní mount místo slepé důvěry v název Compose souboru a ověřte, že runtime user může zapisovat tam, kam File Browser očekává.

Zvolte dobu uchování a umístění mimo hostitele, poté si nacvičte obnovu, aniž byste se dotkli produkce. Test je úspěšný pouze tehdy, když se vrátí poskytované soubory, uživatelé, scopes, sdílení a nastavení a účet s omezenými právy zůstane v přiděleném prostoru. U stavu uloženého v databázi kombinujte snapshoty úložiště s exporty konzistentními z pohledu aplikace, jak je popsáno v obnově k určitému bodu v čase versus snapshotech.

Spusťte první instanci odpovídající produkci

První spuštění File Browser udržujte dostatečně reprodukovatelné, aby ho bylo možné zkontrolovat v pull requestu.

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

Po vzniku skutečných dat se nespoléhejte na latest. Zaznamenejte použitý digest, uživatele kontejneru a vlastníka mountů. Sledujte aplikační log během kompletního testu — vytvořte uživatele s omezenými právy, nahrajte a přejmenujte soubor, upravte text, vygenerujte sdílení a ověřte, že uživatel nemůže opustit svůj přiřazený root — a před vystavením routy produkčnímu provozu si poznamenejte případné migrace.

Vymezte runtime hranici File Browser

Zdraví procesu a zdraví produktu jsou u File Browser dvě různé věci. Port 80 může odpovídat, i když transakce z pohledu uživatele stále selhává. Lokální runtime vyžaduje samostatnou persistentní cestu pro databázi a nastavení. Ověřte ji při akceptační zátěži; health check v nečinnosti nemůže prokázat, že je zdrojů dostatek.

Po významných změnách konfigurace použijte toto ověření připravenosti: vytvořte uživatele s omezenými právy, nahrajte a přejmenujte soubor, upravte text, vygenerujte sdílení a ověřte, že uživatel nemůže opustit svůj přiřazený root. Nákladné externí kontroly ponechte mimo liveness probes, aby výpadek poskytovatele nezpůsobil restartovací smyčku. Při plánování kapacity sledujte propustnost disku, velikost uploadů, počet souběžných downloadů a počet adresářů, protože tyto metriky lépe odpovídají skutečnému zatížení File Browser než požadavky na stránky.

Zajistěte jednoznačný veřejný origin

Vystavte File Browser pod jedním HTTPS hostname a surový port 80 ponechte privátní. UI publikujte přes HTTPS, ale served root nastavte pečlivě. Zabráníte tak tomu, aby se prohlížeče a API klienti dozvěděli o dvou konkurenčních adresách.

Z čistého klienta spusťte ověřenou transakci a zkontrolujte první požadavek, který selže. Pokud je problém v DNS nebo TLS, použijte návod na vlastní doménu. Jakmile je route ověřená, berte problém „připojené soubory používají oprávnění hostitele, ke kterým kontejner nemá přístup“ jako samostatnou aplikační diagnózu.

Release gate pro File Browser

Vytvořte malý dočasný fixture pro File Browser a ponechte si ho pro každou release. Fixture by měl ověřovat skutečný workflow: vytvořit uživatele s omezenými právy, nahrát a přejmenovat soubor, upravit text, vygenerovat sdílení a ověřit, že uživatel nemůže opustit svůj přiřazený root. Zaznamenejte digest image, externí hostname, adresu závislosti a očekávaný výsledek, aby mohl pozdější operátor test zopakovat bez interpretace tohoto návodu.

Fixture spusťte třikrát. Poprvé použijte čerstvé nasazení. Podruhé nahraďte kontejner, aniž byste se dotkli trvalého stavu. Potřetí obnovte zálohu do prázdného prostředí. Třetí běh je úspěšný pouze tehdy, když se vrátí poskytované soubory, uživatelé, scopes, sdílení a nastavení a účet s omezenými právy zůstane v přiděleném prostoru. Během každého běhu zaznamenejte latenci a využití zdrojů v souvislosti s propustností disku, velikostí uploadů, počtem souběžných downloadů a počtem adresářů; tyto hodnoty se stanou výchozím bodem pro alerty místo libovolně zvoleného procenta CPU.

Nakonec záměrně otestujte negativní scénář: odešlete neškodný vstup poblíž limitu zdroje nebo formátu souvisejícího s touto hranicí: připojené soubory používají oprávnění hostitele, ke kterým kontejner nemá přístup. Ověřte, že File Browser selže viditelně, aniž by poškodil stav, obnovte správnou podmínku a úspěšnou transakci zopakujte. Záznam o release obsahující tyto čtyři výsledky je silnějším důkazem než screenshoty dashboardu nebo jednorázová odpověď z curl.

Kontroly kapacity a aktualizací

Health check v nečinnosti o File Browser mnoho neřekne. Sledujte propustnost disku, velikost uploadů, počet souběžných downloadů a počet adresářů a upozorňujte na příznak, který uživatel skutečně pocítí: selhání akce „vytvořit uživatele s omezenými právy, nahrát a přejmenovat soubor, upravit text, vygenerovat sdílení a ověřit, že uživatel nemůže opustit svůj přiřazený root“. Liveness udržujte lokální a nenáročný; readiness může hlásit migrace nebo inicializaci, aniž by vyvolala restartovací smyčku.

Rizikovou oblastí aktualizace jsou migrace databáze a nastavení File Browser, přestože poskytované soubory žijí na samostatném mountu. Přečtěte si release notes, vytvořte snapshot stavu, nasaďte cílovou verzi nad obnovenou kopií a akceptační akci zopakujte. Pokud připojené soubory používají oprávnění hostitele, ke kterým kontejner nemá přístup, propojte požadavek klienta s prvním relevantním aplikačním logem, místo abyste bez rozmyslu mazali stav nebo přidávali redirecty.

Omezte oprávnění, která má File Browser

Bootstrap credentials jsou dočasné; trust model je trvalý. U File Browser si dávejte pozor, abyste neposkytovali / nebo adresář se secrets místo vyhrazeného share, a poskytujte vyhrazený adresář namísto rootu hostitele. Každému účtu přidělte co nejužší file scope, který potřebuje.

File Browser v tomto výchozím nastavení nemá povinný bootstrap secret; chraňte skutečný administrátorský účet nebo upstream authentication jiným způsobem. Image spouštějte bez zbytečných linuxových capabilities a vystavujte pouze veřejnou aplikační route. Aktivitu administrátorů uchovávejte v logu, ale nezaznamenávejte hodnoty secrets.

Použijte Dockup pro platformní vrstvu

U File Browser je Dockup nejužitečnější na hranici mezi imagí a persistentní službou. Zachová route na port 80, TLS, hodnoty secrets a připojené storage i při výměně kontejneru, ať už compute zajišťuje Dockup, nebo váš připojený server.

Dokončete nasazení s využitím znalostí aplikace: UI publikujte přes HTTPS, ale served root nastavte pečlivě; potvrďte lokální požadavek — samostatnou persistentní cestu pro databázi a nastavení — a spusťte toto ověření: vytvořte uživatele s omezenými právy, nahrajte a přejmenujte soubor, upravte text, vygenerujte sdílení a ověřte, že uživatel nemůže opustit svůj přiřazený root. Výsledek uložte jako deployment check, aby se další aktualizace image posuzovala podle chování, nikoli podle stavu kontejneru.

Často kladené otázky

Co File Browser potřebuje pro produkční nasazení?

Kontejner File Browser veďte přes port 80 na jeden HTTPS origin. Lokální runtime vyžaduje samostatnou persistentní cestu pro databázi a nastavení. File Browser neoznačujte za připravený, dokud nedokážete vytvořit uživatele s omezenými právy, nahrát a přejmenovat soubor, upravit text, vygenerovat sdílení a ověřit, že uživatel nemůže opustit svůj přiřazený root.

Která data File Browser patří do zálohy?

Persistujte /srv a do stejného recovery manifestu zahrňte poskytované soubory i databázi a nastavení File Browser. Obnova File Browser je úspěšná pouze tehdy, když se vrátí poskytované soubory, uživatelé, scopes, sdílení a nastavení a účet s omezenými právy zůstane v přiděleném prostoru.

Vyžaduje File Browser za reverse proxy HTTPS?

Pro veřejný origin File Browser použijte HTTPS a port 80 ponechte na interní route. Nastavení File Browser aplikujte správně: UI publikujte přes HTTPS, ale served root nastavte pečlivě. U File Browser HTTPS chrání credentials a uživatelský obsah při přenosu a zajišťuje konzistentní chování klienta závislé na originu.

Jak otestovat aktualizaci File Browser?

Obnovte aktuální stav File Browser do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte akceptační transakci. Věnujte tomu zvláštní pozornost, protože migrace databáze a nastavení File Browser jsou důležité, přestože poskytované soubory žijí na samostatném mountu. Předchozí image File Browser si ponechte, dokud neporozumíte hranicím migrace dat a rollbacku.