Removal of Temporary Migration Step in nginx Dockerfile

[tenthe]

Hi @obermeier,

if I saw it correctly, you added following part to the Dockerfile for the UI container, right? See #2473.

# Store a copy to have a version if the other is hidden in the volume.  
# Required for migration from 0.93.0 to 0.95.0.  
# Could be removed after the release of 0.95.0.  
RUN mkdir -p /etc/opt/nginx/  
RUN chown -R nginx:nginx /etc/opt/nginx/  
COPY nginx_config/default.conf.template /etc/opt/nginx/default.conf.template  
RUN chown -R nginx:nginx /etc/opt/nginx/default.conf.template  

Can this section now be safely removed? Does its removal impact existing installations? Is there anything we need to consider when removing it?

What is the current best practice if users want to use their own default nginx configuration?

Cheers,
Philipp

[obermeier]

Hi @tenethe,

Thank you for bringing this up.

Yes, this section can be safely removed since a default.conf.template should now exist in /etc/nginx/conf.d.
I will provide a PR to clean it up.

Regarding best practices for customizing the NGINX I think a good practice would be to have the possibility to mount a custom default.conf.

But currently, there are scripts which are changing this configuration and will influence the default.conf

1. If the env var NGINX_SSL=true the configuration from /app/nginx-confs/ssl.conf is used
2. The host of the http server adapter is configured base on SP_HTTP_SERVER_ADAPTER_ENDPOINT
   E.g.
   - SP_HTTP_SERVER_ADAPTER_ENDPOINT=extensions-iiot-minimal:8090
   - SP_HTTP_SERVER_ADAPTER_ENDPOINT=extensions-all-jvm:8090

Three possible solutions just came to my mind:

1. Adding an environment variable which tells the scripts not to manipulate or replace the default.conf
2. The second solution would be to instruct users to mount a /app/nginx-confs/ssl.conf bzw. a custom /etc/nginx/conf.d/default.conf.template
3. Do not provide a default.conf in the OCI image. If it a default.conf is mounted, it would be used; otherwise, the current behavior from docker-entrypoint.sh would apply.
   I like this idea, but I’m concerned that many users might not be aware that if they change the HTTP server image (e.g., extensions-iiot-minimal, extensions-all-jvm), they would also need to update the NGINX configuration accordingly.

What do you think of these ideas?

Cheers,
Stefan