justincorrigible
commented
3 years ago As Arranger's images are built and published before being used by other projects, the way these images are going to be run may vary, based on the environment's specific requirements. These conditions must therefor be passed into the containers at runtime, but the admin UI doesn't get access to those, since the prebuilt code is executed client-side.
Generally, this would easily be done by exposing the variables through an endpoint (not justifiable in our case), we'll instead substitute the variables in a file, which is then made available to be loaded by the browser on page load. However, our k8s setup doesn't allow doing that, since the containers run in read-only capacity (as per best practices). For these cases, a folder in the container may be linked to a writable volume elsewhere in the host, as it was already the case for the nginx configurations.
Though it'd be enough to add an argument to indicate the writable location for this new file, changing the helm charts would require intervention from other members of the team, and the corresponding testing and deployment of the changes.
Thus, as a stopgap, we're going to be using the hostname variable passed by every building process, as a means to determine whether Arranger is being built/deployed into k8s or elsewhere, and set the path accordingly.
Ideally, along with the redesign, we will improve the helm charts to support taking value maps given by the app; ensuring better maintainability and extendibility.
b-f-chan
Arranger services should function correctly when deployed as a subdirectory of a platform (e.g. DMS)
This ticket is Arranger's response to https://github.com/overture-stack/dms/issues/108