Skip to content

Where to store persistent storage files? #6095

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ghost opened this issue Dec 31, 2015 · 8 comments
Closed

Where to store persistent storage files? #6095

ghost opened this issue Dec 31, 2015 · 8 comments

Comments

@ghost
Copy link

ghost commented Dec 31, 2015

In another issue (sabre-io/Baikal#427) we discussed if there should be an own directory /data/ for persistent files, which differ from each installation, like a user database.

I thought it would be better to add /var/data/ for such files. But then somebody explained me that /var/ is just for temporary installation-based files like log files, cache files, etc.

The Linux Filesystem Hierarchy also use the /var/ directory only for such temporary installation-based files and not for persistent installation-based files.

Currently the file app/config/parameters.yml, which differs from each installation, is in app/config/ and not in something like /var/ or /data/.

I think the Symfony documentation should contain some tips or Best Practices how you should storage persistent installation-based files. The parameters.yml file is a good example because it differs from each installation but is not temporary like log files or cache files.

@stof
Copy link
Member

stof commented Dec 31, 2015

There is a difference. app/config/parameters.yml is not a storage file. It does not need to be writable by the webserver.
A storage folder would need to be writable.

The Symfony structure defines /var as being a writable folder, not as being a temporary folder. So I would probably put the data folder inside /var.

But I would not make it an official recommendation either. Storage is better done outside of the application itself. Otherwise, you will face issues as soon as you scale horizontally behind a load-balancer (unless you replicate stored files on all servers, which would probably be even more complex than separating the storage itself from the app). And you would also face issues when using disposable infrastructure, where the server can be replaced entirely with a new one (see Heroku or Platform.sh for instance), as the replacement server would not have the stored files (and you can replicate to a non-existent server)

@Pazns
Copy link

Pazns commented Dec 31, 2015

If we read this : http://symfony.com/doc/current/quick_tour/the_architecture.html , /var is explicitly designed to hold generated files.
My question could be : Is a database or, let's say, a stock image used internally (like some sort of template image, I don't know) really a "generated" file ?
The example of a database is not very good, but the "stock template image" maybe is a bit more useful : it is not generated when the application runs, it is already there before the start ; but still it is not a web asset nor a configuration-related file.

Moreover, the possibility to use SQLite, therefore with a local database file, leads to a recurrent case of people asking (understandably) "Where should I put my sqlite file ?", and variations, on Internet.

@stof
Copy link
Member

stof commented Dec 31, 2015

@Pazns the discussion about creating the new structure was talking about putting things needing writable permissions in /var (which is indeed related to generated files).

A stock image is a read-only file which is part of the codebase AFAICT, so it does not belong to var. I would put it in app/Resources/<something> (for instance app/Resources/data, but it could also be app/Resources/stock-images if you have many such images).
A sqlite database would go into /var/ as it needs write access (it is kind of generated).

@ghost
Copy link
Author

ghost commented Dec 31, 2015

In this case it would be helpful to change the Symfony documentation to explain this better. It would be helpful to write something like "things needing writable permissions" if this is really the philosophy of the Symfony directory structure.

@andrerom
Copy link
Contributor

See #6132 for updating doc in regards to permissions for var folder.

For eZ Platform we have similar needs as reporter by @JHGitty, and we plan to adopt 3.0 structure later this year so mentioning it:

  • var/storage (or data or binary or ..) folder for any persisted files provided by user*
  • var/public (or some other name) for files generated by user that should be exposed on web/, folder would typically symlink to web folder, or we would need to write to web/public directly to avoid the symlink.

* In single server mode, we use Flysystem, so won't write to local folder if setup is in cluster mode, however we may still need a public folder in both cases for caching files persisted to NFS/GridFS/.. to allow web server to directly serve the file if already there.

@ghost
Copy link
Author

ghost commented Jan 12, 2016

@andrerom Great idea! I agree with you. The directories var/storage and var/public are a good solution and this should be added to the Symfony standard or something like "Suggestion from the Symfony community" (Best Practices?).

@bdunogier
Copy link

From my perspective, it sounds clear that var can be used for this. There are situations, as @stof pointed out, where it doesn't apply, and those should be covered by the application (until something better shows up).

I'm with @JHGitty about covering the recommendations of generated, persistent data, both public (e.g. exposed via HTTP) or private (streamed or internal).

@javiereguiluz
Copy link
Member

Closing it as fixed by #6136.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants