Skip to content
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

Make use of NEXTCLOUD_CONFIG_DIR #102

Closed
tobru opened this issue Jun 13, 2017 · 5 comments
Closed

Make use of NEXTCLOUD_CONFIG_DIR #102

tobru opened this issue Jun 13, 2017 · 5 comments
Labels

Comments

@tobru
Copy link
Contributor

tobru commented Jun 13, 2017

Now that version 9 is removed (#99) all available Nextcloud versions support the setting NEXTCLOUD_CONFIG_DIR. This could be leveraged to stop copying the Nextcloud source code to the volume during container startup in the entrypoint script (which I think is a bad practice). This would mean that the volume only contains the configuration, data, apps and themes directory. The environment variable would be configured like NEXTCLOUD_CONFIG_DIR=/var/www/html and PHP so that the programcode is coming from /usr/src/nextcloud/.

What do others think about this change?

@ChessSpider
Copy link

ChessSpider commented Jun 13, 2017

For this issue, also see #23 and #65
tl;dr.. yes plz
tl;dr.. yes plz

@SnowMB
Copy link
Contributor

SnowMB commented Jun 13, 2017

Yeah looks easy in the first place, but is not possible in the way nextcloud and the docker container work today.

One problem lies in the fpm image. It requires static files from the sources (images, stylesheets, ect.) to be available to the webserver, since fpm just processes php files. To make these files available outside we are using volumes. (There is the whole /var/www/html folder defined as volume in the Dockerfile).

But the big problem is, you can't define a volume with content in it. It doesn't matter if the volume is defined in the Dockerfile (so is part of the image) or if it's defined by the docker run or docker-compose.yml file. Every volume is created at first runtime.

That's why the source files are copied in the entrypoint script, so you get your data and source files in a volume and can share it to the webserver.

There might be another reason as well, but I can't remember it right now. 😉

@ChessSpider
Copy link

There's also the problem that the assets seem to be scattered all over the place. There is not one or two neat /static/ folder you'll have to share, but there are multiple mixed with dirty PHP files.

If it was one or two directories with solely static files in them, one could think about some kind of dirty work-around. But even that is not possible now unfortunately.

@tobru
Copy link
Contributor Author

tobru commented Jun 20, 2017

Thanks for the feedback. I see, not an easy task. Looks like this needs some more engineering. If I find a solution, I'll let you know. But there is no promise that I find something 😉

@J0WI
Copy link
Contributor

J0WI commented Nov 4, 2019

I'll close this for now. Feel free to open a PR or a new issue if you found a solution.

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

No branches or pull requests

4 participants