Привет, ситуация такова - у меня есть несколько сервисов в

контейнерах:
- MongoDB - просто контейнер с базой;
- db_service - контейнер с API которая принимает файлы (зипованные JSON), распаковывает, валидирует, ищет копии, сохраняет в MongoDB GridFS, версионирует и т.п.
- conversion_service - контейнер с API, которая запускает задачи Celery, проверяет их статус и отдаёт результат.
- celery_worker - в этом сервисе выкачиваются указанные файлы из db_service и происходит конвертация в нужный формат (stp, stl и т.п.).
- Redis - контейнер, использующийся как message broker.
- nginx_proxy - контейнер, в котором крутится nginx, между собой все сервисы общаются только через него, во внешний мир выставлен тоже только он.

После сохранения файла или его апдейта, db_service автоматически дёргает сервис конвертации, так как необходимо иметь определённые форматы уже сконвертированными в момент когда пользователь захочет получить их.
Сейчас между conversion_service и celery_worker есть расшаренный докеровский volume. Запрос о конвертации приходит в conversion_service, тот запускает задачу, celery_worker выкачивает файл из db_service, конвертирует, помещает результат в этот volume. Пользователь проверяет статус задачи, если конвертация прошла, то забирает результат через эндпоинт в conversion_service.
Меня это не совсем устраивает, я думаю, что эти файлы должны отдаваться напрямую nginx'ом. Но, меня смущает, что в таком случае непонятно, как решать, имеет право человек получить данный файл или нет? И вообще, есть мысль перестать хранить файлы в GridFS, складировать в папке в том же зипованном виде, а в MongoDB оставить только мета-данные. Помогите понять, что не так сейчас, что не так может быть в будущем? Что искать в доках nginx по этой теме? Может на примете есть у кого статьи или другие материалы по схожим проблемам?

Мне кажется, вам пора уже в Service Discovery с таким количеством контейнеров. Какой смысл гонять внутренний трафик через nginx?

Мы не знаем где какой сервис, но знаем где nginx, отправляем ему запрос на известный адрес, а он уже смотрит куда переправить, нет? Это плохой подход?

Это не очень нативный подход для микросервисной архитектуры, котороб вы строите.

ну, рано или поздно вы просто забьете nginx своими запросами. Service Discovery для того и нужен, чтобы каждый сервис знал, где сейчас находится другой сервис, чтобы ходить напрямую к нему

Ну, не сказал бы, что у меня прямо таки микросервисы, просто набор сервисов, а между ними происходит как бы интеграция, то есть, запись в базу будет работать и без конвертации, а конвертировать ты можешь не только файлы из базы. Как-то так, но я не особо опытен в этих делах.

Спасибо, обязательно почитаю про это.

https://www.consul.io например, или etcd (если кубер будет)

А что контейнер нецмы не работают ?

кубер бери, там уже все костыли написали за тебя и такой примитив там называется Service а твои микросервисы это Deployment, они могут быть заскейлены в N экземпляров, и по имени Service кубер будет балансить запросы между ними