Як розгорнути File Browser на власному сервері у 2026 році: томи, облікові записи та безпечний обмін файлами

Сприймайте File Browser як невелику систему, а не як Docker-образ. Користувацька мета File Browser зрозуміла: вебфайловий менеджер для підключеного тому; розгортання можна вважати прийнятним лише тоді, коли ви можете створити користувача з обмеженими правами, завантажити й перейменувати файл, відредагувати текст, створити share і підтвердити, що користувач не може вийти за межі призначеного йому кореневого каталогу.

Ця відмінність допомагає виявити проблему, з якою оператори стикаються після локального тестування: змонтовані файли використовують права доступу хоста, тому контейнер не може їх прочитати. Вона також дає змогу скласти достатньо конкретний план резервного копіювання та оновлення, який можна протестувати.

Знайдіть усі довговічні дані File Browser

Docker-образ можна завантажити повторно, а обслуговувані файли, база даних File Browser і налаштування — ні. Змонтуйте /srv до початкової ініціалізації, запишіть нешкідливі тестові дані та замініть контейнер, щоб переконатися, що цей шлях справді зберігається. Перевіряйте фактичне монтування, а не покладайтеся на назву файлу Compose, і переконайтеся, що користувач, від імені якого працює процес, може записувати туди, куди очікує File Browser.

Визначте термін зберігання та зовнішнє сховище, а потім відрепетируйте відновлення, не торкаючись production. Перевірку пройдено лише тоді, коли повернулися обслуговувані файли, користувачі, області доступу, shares і налаштування, а обліковий запис з обмеженими правами залишився в межах свого кореневого каталогу. Для стану, що зберігається в базі даних, поєднуйте snapshots сховища з узгодженими із застосунком exports, як описано в матеріалі відновлення на певний момент часу проти snapshots.

Запустіть перший instance, наближений до production

Зробіть початковий запуск File Browser достатньо відтворюваним, щоб його можна було перевірити в 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

Не покладайтеся на latest, щойно з’являться реальні дані. Зафіксуйте робочий digest, користувача контейнера та власника змонтованих каталогів. Перегляньте лог застосунку протягом повного тесту — створіть користувача з обмеженими правами, завантажте й перейменуйте файл, відредагуйте текст, створіть share і підтвердьте, що користувач не може вийти за межі призначеного йому кореневого каталогу, — та зафіксуйте всі migrations, перш ніж спрямовувати маршрут на production-трафік.

Визначте межі виконання File Browser

Стан процесу та стан продукту — це різні речі для File Browser. Порт 80 може відповідати, навіть якщо користувацька операція все ще завершується помилкою. Локальна вимога до середовища виконання — окремий постійний шлях для бази даних і налаштувань. Перевіряйте його під час приймального навантаження: health check у стані простою не доводить, що ресурсу достатньо.

Використовуйте цю перевірку готовності після суттєвих змін конфігурації: створіть користувача з обмеженими правами, завантажте й перейменуйте файл, відредагуйте текст, створіть share і підтвердьте, що користувач не може вийти за межі призначеного йому кореневого каталогу. Не додавайте дорогі зовнішні перевірки до liveness probes, щоб збій у провайдера не спричинив цикл перезапусків. Під час планування capacity відстежуйте пропускну здатність диска, розмір завантажень, кількість одночасних завантажень і кількість каталогів — це ближче до реального навантаження File Browser, ніж кількість запитів до сторінок.

Зробіть публічне джерело однозначним

Опублікуйте File Browser на одному HTTPS-хості, а необроблений порт 80 залиште приватним. Публікуйте UI через HTTPS, але ретельно обмежте кореневий каталог, який обслуговується. Це не дасть браузерам та API-клієнтам дізнатися про дві конкуруючі адреси.

На чистому клієнті виконайте відому успішну операцію та визначте перший запит, який завершується помилкою. Якщо проблема пов’язана з DNS або TLS, скористайтеся посібником із custom domain. Коли маршрут уже перевірено, розглядайте проблему «змонтовані файли використовують права доступу хоста, тому контейнер не може їх прочитати» як окрему діагностику застосунку.

Критерії випуску File Browser

Створіть невеликий тимчасовий fixture для File Browser і зберігайте його для кожного випуску. Fixture має перевіряти реальний workflow: створіть користувача з обмеженими правами, завантажте й перейменуйте файл, відредагуйте текст, створіть share і підтвердьте, що користувач не може вийти за межі призначеного йому кореневого каталогу. Запишіть digest образу, зовнішній hostname, адресу dependency та очікуваний результат, щоб наступний оператор міг повторити тест без додаткової інтерпретації цього посібника.

Запустіть fixture тричі. Спочатку використайте свіже розгортання. Потім замініть контейнер, не змінюючи довговічний стан. Втретє відновіть резервну копію в порожньому середовищі. Третій запуск пройдено лише тоді, коли повернулися обслуговувані файли, користувачі, області доступу, shares і налаштування, а обліковий запис з обмеженими правами залишився в межах свого кореневого каталогу. Під час кожного запуску збирайте latency і використання ресурсів у контексті пропускної здатності диска, розміру завантажень, кількості одночасних завантажень і кількості каталогів; це стане базовим рівнем для alerting замість довільного відсотка CPU.

Нарешті, навмисно перевірте негативний сценарій: надішліть нешкідливі вхідні дані поблизу обмеження ресурсу або формату, пов’язаного з цією межею: змонтовані файли використовують права доступу хоста, тому контейнер не може їх прочитати. Переконайтеся, що File Browser помітно повідомляє про помилку, не пошкоджуючи стан, виправте умову та повторіть успішну операцію. Запис про випуск, що містить ці чотири результати, є переконливішим доказом, ніж screenshots dashboard або одноразова відповідь curl.

Перевірки capacity та оновлення

Health check у стані простою мало що говорить про File Browser. Відстежуйте пропускну здатність диска, розмір завантажень, кількість одночасних завантажень і кількість каталогів, а alerting налаштовуйте за симптомом, який бачать користувачі: помилкою під час операції «створити користувача з обмеженими правами, завантажити й перейменувати файл, відредагувати текст, створити share і підтвердити, що користувач не може вийти за межі призначеного йому кореневого каталогу». Liveness залишайте локальним і простим; readiness має повідомляти про migrations або ініціалізацію, не спричиняючи лавину перезапусків.

Ризикована частина оновлення полягає в тому, що migrations бази даних і налаштувань File Browser мають значення, навіть якщо обслуговувані файли розташовані на окремому mount. Прочитайте release notes, створіть snapshot стану, розгорніть цільову версію на відновленій копії та повторіть приймальну операцію. Якщо змонтовані файли використовують права доступу хоста, тому контейнер не може їх прочитати, зіставте клієнтський запит із першим релевантним записом у логу застосунку, а не видаляйте стан і не додавайте redirects навмання.

Зменште повноваження File Browser

Bootstrap-облікові дані тимчасові, а модель довіри — постійна. У File Browser стежте, щоб замість виділеного share не обслуговувався / або каталог із secrets, а також щоб обслуговувався виділений каталог, а не кореневий каталог хоста, і кожен обліковий запис отримував найвужчу file scope, яка йому потрібна.

У цьому baseline File Browser не має обов’язкового bootstrap secret; натомість захистіть фактичний обліковий запис адміністратора або upstream authentication. Запускайте образ без непотрібних Linux capabilities і відкривайте лише публічний маршрут застосунку. Зберігайте видимість адміністративної активності, не записуючи значення secrets.

Використовуйте Dockup для platform layer

Для File Browser Dockup найкорисніший на межі між образом і довговічним сервісом. Він зберігає маршрут до 80, TLS, значення secrets і підключене сховище під час заміни контейнерів — незалежно від того, чи належать обчислювальні ресурси Dockup, чи вашому підключеному серверу.

Завершіть перевірку з урахуванням особливостей застосунку: публікуйте UI через HTTPS, але ретельно обмежте кореневий каталог, який обслуговується; підтвердьте локальну вимогу — окремий постійний шлях для бази даних і налаштувань; і виконайте цю перевірку: створіть користувача з обмеженими правами, завантажте й перейменуйте файл, відредагуйте текст, створіть share і підтвердьте, що користувач не може вийти за межі призначеного йому кореневого каталогу. Збережіть результат як deployment check, щоб наступне оновлення образу оцінювалося за поведінкою, а не за статусом контейнера.

Поширені запитання

Що потрібно File Browser для розгортання в production?

Спрямуйте контейнер File Browser на порт 80 через одне HTTPS-джерело. Локальна вимога до середовища виконання — окремий постійний шлях для бази даних і налаштувань. Не вважайте File Browser готовим, доки не зможете створити користувача з обмеженими правами, завантажити й перейменувати файл, відредагувати текст, створити share і підтвердити, що користувач не може вийти за межі призначеного йому кореневого каталогу.

Які дані File Browser потрібно включати до резервної копії?

Зберігайте /srv і включайте обслуговувані файли, базу даних File Browser та налаштування до одного recovery manifest. Чисте відновлення File Browser пройдено лише тоді, коли повернулися обслуговувані файли, користувачі, області доступу, shares і налаштування, а обліковий запис з обмеженими правами залишився в межах свого кореневого каталогу.

Чи потрібен File Browser HTTPS за reverse proxy?

Використовуйте HTTPS для публічного джерела File Browser, а порт 80 залиште у внутрішньому маршруті. Правильно застосуйте налаштування File Browser: публікуйте UI через HTTPS, але ретельно обмежте кореневий каталог, який обслуговується. Для File Browser HTTPS захищає облікові дані або вміст користувачів під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення File Browser?

Відновіть поточний стан File Browser в ізольованому розгортанні, застосуйте candidate version і повторіть приймальну операцію. Зверніть особливу увагу, оскільки migrations бази даних і налаштувань File Browser мають значення, навіть якщо обслуговувані файли розташовані на окремому mount. Зберігайте попередній образ File Browser, доки не буде зрозумілою межа міграції даних і rollback.