geonode-project
geonode-project copied to clipboard
GeoNode
nginx configs inside volume
Changes made to nginx configuration for geonode are saved inside a volume, this leads to situations where you rebuild the image changing the configuration file, but the configuration doesn't change unless you delete the volume. I don't see the need of persisting files that are copied in the image during the build phase, but then are overwritten by the volume.
@d3netxer Just drop the volume entirely to have the nginx configuration generated each time using environmental variables. Otherwise, you can just mount a folder as a volume and edit the generated files.
The docker-entrypoint should update the conf files from the conf_envsubst templates. Isn't it working?
Il mer 22 mar 2023, 09:38 Francesco Frassinelli @.***> ha scritto:
@d3netxer https://github.com/d3netxer Just drop the volume entirely to have the nginx configuration generated each time using environmental variables. Otherwise, you can just mount a folder as a volume and edit the generated files.
— Reply to this email directly, view it on GitHub https://github.com/GeoNode/geonode-project/issues/185#issuecomment-1479109535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAELN6NRF7QPBNQNV4TBVILW5K27VANCNFSM45W3MG4Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I remember about this issue as well, but it should not happen, since it looks like the entrypoint (which is executed inside the Dockerfile with RUN for some reason?) should override the files. Still, even if it overwrites the files, there should be no volume in my opinion.
I didn't try running the entrypoint.sh file, but I did delete the {{project-name}}-nginxconfd volume and rebuilt the geonode container using the --no-cache option after making changes to the geonode.conf.envsubst file and it worked for me. Thanks
@d3netxer entrypoint.sh is executed each time the container is started. Your experience matches with what I have seen previously: the configuration seems persistent, for some reason. I am glad the workaround worked for you.