As runnable application component, I should verify and access to environment variables in a safe way to collaborate with other resources/infrastructure systems #159
Description
- implementation of reusable generic class (WriteModelConfigurationVariable, ReadModelConfigurationVariable) by application context (e.g redis adapter) which manage the find/access of properties specific to the current runtime
- Avoid usage of Maven profile in application (e.g put documentation to doc about usage of environment variable and context utility class)
- generic HealthyOperableComponentChecker and ExecutableComponentChecker about environment variables management
- add unit test per application component (ExecutableAdapterCheckerUseCaseTest for UIS adapter impl) about all defined value of all resources to avoid missing by java developers between a value called dynamically by a java code via the Checker class
- all the settings that are variable for a java component should be managed/defined/changeable only at the infrastructure layer and accessible dynamically without any change/rebuild of java component that is stateless > over Environment Variables
- check class verifying (by default constructor) that all variables required by the component are defined (Context.get(IReadableConfiguration config) method ) currently in the system instance (e.g if Infrastructure-as-Code missed to defined value in Docker/Helm/Terraform codes) which can be call anytime by a bounded context adapter to manage a waiting time for operator to define/change the environment variable in the current instance through his administration tool. Example of auto verification by adapter (UISAdapterImpl).
- Implementation of automatic variable types and valued existing (ExecutableAdapterChecker for UIS adapter, ExecutableBackendChecker for reactive-messaging-gateway) in the current started java app (ExecutableBackendChecker of Reactive messaging gateway)
- environment variables (e.g url to middleware) managed via helm/terraform (see Helm variable environment setting on https://phoenixnap.com/kb/helm-environment-variables) relative to running environment allowing dynamic change (e.g via JMX or via OS/docker instance access via secure/dedicated configuration/administration system)
- setting via Helm when building the containerized backend + test of redeployment into Kubernetes