Feature/configurable port

[saretter]

This change allows to set environment variable APACHE_PORT in order to change the Apache port. My motivation is using the image inside Kubernetes running it as non-root user which requires to run Apache on an unprivileged port. I tried to keep the changes as minimal as possible.

[J0WI]

We use the PHP base image, so this is kind of a duplicate of docker-library/php#94

[saretter]

Yes, seems to be a similar discussion. Nevertheless from my point of view the difference is that docker-library/php is a typical base-image while nextcloud is an application used by many users without building their own images and this minimal change would allow to let people run the image directly even if they need/want to follow the best-practice and run the container in unprivileged mode.

[danihodovic]

I think you need to modify this file https://github.com/nextcloud/docker/blob/master/21.0/apache/entrypoint.sh for it to work.

I applied your patch there and it worked for me.

[saretter]

This is done by update.sh which is managing the different versions if understood it correctly. If one of the maintainers tells me to do so, I'll run update.sh and commit the changes.

[saretter]

Any additional comments, remarks ... Is there any chance this PR will be accepted?

[J0WI]

IMHO this should be addressed in the php/httpd base image. This affects all images based on php and some solutions have already been discussed there.

[saretter]

IMHO this should be addressed in the php/httpd base image. This affects all images based on php and some solutions have already been discussed there.

In general not each an every feature can make it into a library/framework. It requires a strict management of requirements and precise idea of the purpose of a lib.

I agree, from an applications perspective it would be best to implement it in the library because it would solve the issue not just for the nextcloud-image but for many other applications. Nevertheless I don't know much about and had no time to dig deeper into the design of docker-library and there might be reasons to reject the implementation of such a feature. From my point of view, in this case a simple and minimal change of the application is the second best option and is by far better than leaving it as it is.