У нас есть несколько сервисов, где пользователи загружают файлы, отправляют файлы, обмениваются файлами.
И делать в каждом сервисе свой сервер, где можно было бы получить ссылку на файл, передать через очередь, отправить, обработать - может быть не надо?
В одном сервисе - это загрузка аватарок, в другом - это различные пользовательские файлы, по сути в транзите, в третьем - это файлы, загружаемые для конфигурирования сервиса, используются время от времени.
В каждом сервисе надо было делать директорию для файлов, следить чтобы там было достаточно места, выставить права на запись, монтировать или синхронизировать с хранилищем по необходимости.
Поэтому появился filebump - простой http сервер, где мы можем загружать, хранить и скачивать файлы.
В принципе, это простая файлопомойка. Куда можно скинуть файл и позже забрать его. Возможно, неоднократно.
Как это работает?
Сервис выполняет одну функцию - хостинга файлов по API.
Схема работы:
- у вас в сервисе появился файл (или от пользователя, или прилетел с другого сервиса),
- вы сохраняете файл в filebump,
- в сервисе сохраняете полученныую ссылку от filebump,
- по потребности загружаете файл с filebump,
- или отправляете ссылку на файл в filebump.
Чем-то напоминает пользовательские файлопомойки в расшаренных директориях в локальной сети. Но здесь нет API, которое показывает все файлы на filebump. Только что загрузил - на то и получил свою уникальную ссылку. Сохранил? Да, тогда можешь использовать. А если нет, то все файл где-то там канул в filebump'е.
Что и как можно загружать?
Есть два метода - загрузка файла (upload) и загрузка файла по url (download).
Upload file - загрузкой файлов вы пользуетесь, когда у вас уже есть файл.
Download file - а загрузкой файла по url вы пользуетесь, например, когда вам прилетела ссылка с файлом, и вместо того чтобы скачать и зааплоадить на filebump, вы поручаете эту загрузку самому filebump.
Загружать можно любые файлы.
И удобно пользоваться?
Да, вполне, работает схема полтора года. Сейчас немного причесал и добавил в npm клиента. Удобно. Каждый день прилетают сотни файлов, сотни и тысячи файлов скачиваются.
В разрабатываемых проектах просто подключаете клиент filebump'а, и просто работаете по сути только со ссылками на файлы. В некоторых случаях все файлы как бы вообще мимо разрабатываемого сервиса проходят.
Безопасность?
Использую во внутреннем периметре. Также есть ключи, т.е. http-запросы для upload'а и download'а обязательно содержат API-key. Чтобы никто посторонний не начал лить свои файлы. У каждого сервиса, работающего с filebump, свой ключ. Список ключей задается в конфиге.
Что можно улучшить?
Улучшать можно много чего.
Во-первых, схему хранения файлов. Если их много, то надо как-то оптимизировать структуру директорий. Сейчас обхожусь тем, что просто удаляю все файлы старше 3-х месяцев скриптом по крону.
Во-вторых, хочу разделить на зоны хранения файлов. Т.е. часть файлов хочется хранить долго (вечно), а часть как транзитные файлы, которые нужны только чтоб скачать и отправить дальше, то их можно удалять. Тут или метод добавить, или также по крону в этой зоне хранения просто чистить файлы. Либо пока просто раздельные filebump'ы поставить и сделать свои условные политики хранения файлов.
В-третьих, добавить таки UI и аналитику. Для управления, подсчетов, какой-то визуализации.
Как установить?
В репозитории проекта - docker-compose.yml, в котором есть пример настройки filebump. Образ filebump есть на docker hub.
Подробнее по методам, установке и коду - в гитхабе проекта filebump, написан на javascript под node.js.
Была мысль переписать на Go, чтоб докер образ был не такой жирный. Но, вероятно, если сильно заморочиться да еще и на хотелки и улучшения, то получится какой-нибудь аналог s3 хранилища.
Идеи, мнения приветствуются. Может и не воспользуетесь, но наведет на какую-то дельную мысль - тоже буду рад ))
