🏡Ecosystem Environments
The set of environment parameters represent the context in which a service is executed. Each service needs to know this context to adapt its behavour to the real working condition. At the service level the node .env library allows to read environment of the kind <key,value> this library by default reads from .env file. The data are reads in a process .environment data structure available in the execution context of Node process. A unique file defines the environment and keeps the responsibility to create the shared operative ecosystem.
All Guardian Micro-services share a common set of Environment variables. In this way, Guardian can be seen as an ecosystem with several services and common set of parameters leading his behavour. This environment parameters are shared between all the services of the Guardian ecosystem. All variables are defined in a .env.<GUARDIAN_ENV>.guardian.system file. The file name is parametric so it is possible to define a different files for different possible running configuration, for example production, develop, test1. The ecosystem environment file follow the .env.template.guardian.system file that let write new configurations with the set of necessary variables. Both the template file and the resulting environments files are in the folder ./configs/, they can be discriminated by its name to spread the session.
The parameter GUARDIAN_ENV is defined univocally in an .env file. The containers orchestration will be responsible to push the environment in to the container in a way the environment will be available to the Node server. For example in the execution of Guardian using docker compose tool the tool inject the environment in each container. Docker compose push the environment in the container by the means of the env-file attribute and the environment attribute. Environment attribute can be parametrized using the variables defined in the .env file located next to the docker_compose.yaml this paramenter is used to select the file to read the environment variables from. All the variables defined in the file will be loaded in the container environment and be available to Node.
Also Guardian services are allowed to define specific service variables. This different set of variables allow to have a hierarchical definition of the same variable in a way that a developer could redefine some of them in a service specific way or add new variables extending the usage of the ecosystem environment. The environment variables that are specific to services can be specified by the means of .env.<service_name>.<GUARDIAN_ENV> files located in each service at guardian/<service_name>/configs subfolder.
It has been added a new environment variable named OVERRIDE that can assume values as "true"/"false" to let the variables defined in the .env.<service_name>.<GUARDIAN_ENV>.<GUARDIAN_ENV> to override the common defined ecosystem variables or only add the new ones.
For example If OVERRIDE=true a variable with the same name as the one already defined in the .env.<GUARDIAN_ENV>.guardian.system file will assume the value specify at service level. The OVERRIDE parameter is not mandatory. if OVERRIDE="false" (default value) specific service variables can only be added to the global ones. In each service a new ./configs folder holds the set of parametric service level environment files.
In this way it is possible to use the ecosystem environment plus the service specific variables leaving the service specific variables under the responsibility of the service itself.
The same service specific configuration are used when Guardian is bootstrapped without the docker compose orchestrator in the per service way. In this case every service environment is configured using the two files:
.envfile in the specific service folder./guardian/<service_name>./<service_name>/configs/.env.<service_name>.<GUARDIAN_ENV>file.
The Environment is read in two steps: at first steps the service .env file at service folder ./guardian/<service_name> is loaded by Node while at second step .env.<service_name>.\<GUARDIAN_ENV> file is loaded.
For example If OVERRIDE=true a variable with the same name as the one already defined in the .env file will assume the value specify at service level.
EXAMPLES:
1) Docker Compose Configuration
The following configuration will ignore the guardian-service configuration for variables with same name using only the ecosystem configuration while will add the new specific guardian-service variables for newly defined variables like DB_HOST="localhost", DB_DATABASE="guardian_db" etc..
At root level:
in ./guardian/.env
in ./guardian/configs/.env.develop.guardian.system
At Guardian-service level:
in file ./guardian/guardian-service/configs/.env.guardian.develop
RUN TIME RESULT
The following environment is loaded by the service.
this shows that the root level environment is loaded: OPERATOR_ID defined in the root level "0.0.3422318" is used while "0.0.4523185" specified at service level remains unused.
2) Docker Compose Configuration to maintain the same database already in use
At root level:
in ./guardian/.env
in ./guardian/configs/.env..guardian.system
At Guardian-service level:
RUN TIME RESULT:
At Guardian service level the following environment is loaded at runtime
3) Configure each service without an orchestrator
Configure .env, in ./guardian/<service_name>/.env. Insert the variable GUARDIAN_ENV and give it the name that you choose for you Guardian platform environment (production, develop ...). If you update a production environment to keep working with your previous data leave the field GUARDIAN_ENV="" empty.
The OVERRIDE variable is not mandatory and it default to "false".
Every variable that is used by the service is configured inside the .guardian/<service_name>/configs folder. Because GUARDIAN_ENV is configured as "develop" each service configuration are stored in files with format ./<service_name>/configs/.env.<service_mane>.develop that follows the template in the same folder.
Configure the guardian-service in ./guardian/guardian-service/configs/.env.guardian.develop
Configure the worker-service in ./guardian/worker-service/configs/.env.worker.develop
4) To use the docker-compose configuration and overriding specific service
The docker compose file to be used for this alternative is docker-compose_SSV.yaml together with the .env_SSV in the ./configs folder. Using this configuration both the ecosystem common variables and the service specific variables will be configured in the root folder. using the .env file for specific services variables and the ./config/.env.<GUARDIAN_ENV>.guardian.system for ecosystem variables.
Follow the steps:
In this configuration using the default OVERRIDING=false in the .env.\<GUARDIAN_ENV>.guardian.system grants that the environments that are in each ./<service_name>/configs remain unloaded.
Last updated