-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Any thoughts to remove the /var/www/html
volume?
#381
Comments
See #382 |
The reason for that is some people do mount I think the target for this image are small setup. For bigger setup, I just recommend using this as a base, and then modify the entrypoint to your liking. |
@pierreozoux Thanks for the explanation. Currently I am doing this way. |
For the most part this docker image is an example and aimed at new / unexperienced user that want to get started fast. It also is quite usable at small scale. If you have improvements for larger setups, it would be nice to share them here, but please don't break existing functionalities. I think with scaling up the requirements vary so much, that it is better to customize the underlying dockerfile accordingly or even start from scratch. |
@SnowMB Is it possible to maintain such images for larger setups (as variants, for example) alongside with existing images? So that they can be upgraded automatically and potential issues can be found easily as more and more people are using them. |
I'm not exactly sure if this is feasible, but what might be possible is extracting a base image from the existing one. So it is easier to skip certain "convenience" parts that are not needed for larger installs (like automatic update). But I have no idea if this is possible and what that would look like. One problem we should keep in mind is that each variation multiplies with the existing ones. Let's say we have fpm and apache. We have some work for alpine images. Ideally that would give us fpm-alpine and apache-alpine. With extracting base images, we are at six, that have to maintained and documented in a way that is not confusing to the users. There are so many possible solutions, that we tried to focus on giving examples on how to modify the image for ones own needs. Hence the section in the readme about building derived images. (For some context look at the early issues / prs and my comment in #37) |
can you help me? what is the root password though the terminal I need to delete some files? |
Currently, in the image the Nextcloud files are stored in
/usr/src/nextcloud
. Everytime a Nextcloud container is created,entrypoint.sh
syncs those files to/var/www/html
when the version in/usr/src/nextcloud
is newer than/var/www/html
, then runsphp /var/www/html/occ upgrade --no-app-disable
to upgrade the database structure and so on.This works well for a small group of users. Everything works fine without too much human attention.
But if you are running Nextcloud in production, things will be different:
/var/www/html
as a volume makes it unfriendly to rollback to a earlier version when you are running on Kubernetes or OpenShift.Is it possible to remove the /var/www/html volume? Mounting subdirectories like
custom_apps
,config
,themes
, anddata
should be adequate AFAIK (correct me if I am wrong).After disabling the auto-upgrade, users can still upgrade through the Web UI or
occ
.The text was updated successfully, but these errors were encountered: