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

[tenthe]

Hi @obermeier,

thank you for providing the PR and the detailed explanation here.
I would like to clarify my understanding of the problem:

• The problem seems to be limited to the “HttpServerProtocol” adapter, which receives the data from the system via the “HttpServerAdapterResource” endpoint.
• The main problem is that we can't always predict the container name the adapter is running on, so we need a mechanism to set or override this value at startup.

If I understand correctly, installations that do not rely on the HttpServerProtocol adapter are not affected by this problem.

Is this correct, or are there other parts that could be affected by this change?

Cheer,s
Philipp

[obermeier]

Hi @tenthe,

You’re absolutely correct.

Cheers,
Stefan

[tenthe]

Thanks! I believe a modified version of option 2 from your list is the best approach.

Since this primarily affects users who utilize HttpServerProtocol, we could ship the image with a default.conf that does not include the endpoint configuration. Given that users must manually expose the port to the service anyway, they should also be able to provide their own default.conf with the necessary endpoint definition.

To make this as seamless as possible for those using HttpServerProtocol, I suggest adding a detailed explanation in the element documentation, along with a dedicated section in the main documentation. We could also include a ready-to-use configuration template that users can copy and paste.

This way, users who don't need the adapter get a simple, clean setup by default, while those who do can easily configure it. Since they already know the service name, there's no need for an additional environment variable.

@obermeier, what do you think?