Issue deploying the validator in a production environment using a proxy

[geoportallux]

We have not managed to start the validator in our internal environment.

We are using Docker and Kubernetes to run the validator.

There are several issues:

Configuration

To configure the internal URL to be used, we have to make a custom dockerfile where we unpack the .war, replace the values in the config, repack a .war file and build a new image. That's not very dockeresque.

It would be easier to allow the use of environment variables or the possibility to mount a config file in a volume.

3 Things in one container => 3 Microservices.

The image you are building contains the validator, squid and apache, all in one container. That's not very dockeresque either.
We need to configure http_proxy and https_proxy in our environment for the container to be able to connect to the internet.
With the mix of the 3 services, this is hell, as you use it in your own context for another reason than the one we need it for.

Please split the 3 microservices into 3 images with a docker-compose file as an example.

Proxy

Please allow the use of the environment variables http_proxy and https_proxy (and maybe no_proxy) in your images.

In this way, everyone can deploy the validator in its own environment.

[jenriquesoriano]

Dear @geoportallux,

thank you for your detailed feedback regarding the deployment of the INSPIRE Reference Validator.
We appreciate your insights on the Docker configuration and the use of microservices for Kubernetes.

We are aware that the architecture of the INSPIRE Reference Validator is inherently complex, given the various interconnected components that interact with each other. In this regard, releases are designed to offer a simplified solution for the broader community by providing a single Docker deployment that encapsulates all these components, abstracting the complexity for the end user.

We understand the potential benefits for container orchestration of the proposed parametrization or splitting the different components into separate containers for better modularity in orchestration environments.

Likewise, we believe that your proposal is formally correct for orchestration in large organizations that use Kubernetes, but please understand that the aim is to provide a single deployment with all components without adding the potential complexity of orchestration.

Best regards,

[geoportallux]

Thank you for your answer.

We can understand your approach.

We would nevertheless like to ask you to make the single image configurable with only environment variables and / or mounted config files.

the current image cannot be used by anyone as is because the name of the domain is "hardcoded" to localhost inside the war file in the container and it is impossible to set a http_proxy which is probably necessary in every institutional environment

[HaVRane]

We are a rather small organisation, just needing to install a single container for this in Docker not useing any orchestration or Kubernetes currently. But we are stumbling on this same issue. It is possible not a question of large or small or orchestration, but on running the Inspire validator in a proper server environment at all.
See also #1051