I'm planning to create a new service for handling user image uploads. Although I know that the best practice is to use some external cloud storage dedicated for hosting static files (e.g. Amazon S3), currently I'm tight on the budget and try to store the files in the same shared hosting that also hosts my website. This host already has an Nginx reverse-proxy that directs the request to the appropriate service.
In the traditional non-containerized application, the backend service and Nginx reverse-proxy are in the host and can access the same filesystem. Backend service would just store the uploads, and the Nginx serves the static files directly. But how should it be approached in a containerized way? Currently, I could think of two approaches:
- Create a container containing both the backend service and Nginx. Nginx will reverse proxy between the service's API and the static image files.
- Create a container containing only the backend service. The Nginx reverse-proxy container will share a volume with the backend service so it can access the files.
This is how the traffic would be directed if I use those methods above.
-
- Upload: Client -> Nginx reverse-proxy -> Nginx reverse-proxy #2 -> backend -> store static files
- Download: Client -> Nginx reverse-proxy -> Nginx reverse-proxy #2 -> get static files
-
- Upload: Client -> Nginx reverse proxy -> backend -> store static files in shared volume
- Download: Client -> Nginx reverse proxy -> get static files
I'm quite new with containerized architecture. Is there a better architecture or more efficient way for file uploading case?