Everything within this section is only visible while editing. Use Page Properties ID "STUB", "REFACTURE", "PROGRESS", "rDEV", "rDOC", "rLANG" and "DONE". Everything contained within the table is displayed in the (INTERNAL) Reports page.
Resources & Remarks Modification History Add a new line to this table and fill it whenever you edit the page.
|
This article explains the usage of service profiles in yuuvis® Momentum—how to add and use custom profiles. |
|
The yuuvis® Momentum service architecture makes each service retrieve configuration files from a central location managed by the CONFIG service. These YAML configuration files extend the base application.yml
configuration file inherent to any Spring boot microservice. Each of the additional configuration files corresponds to a profile, denoted by the suffix of the file, which the service of interest will need to be configured to run in.
The architecture of services and profiles follows the basic concepts of Spring Boot. For more detailed information, please refer to the Spring Boot profiles documentation.
So how is this helpful? There are two main benefits:
The name of the profile file defines whether it will be available to all services or to only one specific service: there are two types of profiles that are distighuished by their naming scheme:
application-<profile type>.yml
naming scheme in order to be referable to by any service in the system. <service-identifier>-<profile type>.yml
. The individual services do not reference a specific profile file name but only the profile type. It is important to consider the strict hierarchy implemented in Spring Boot profile-based configurations. A configuration specific to a single service (i.e., system-prod.yml
) always takes precedence over any global configuration (i.e., application-prod.yml
), which means that overriding a global configuration is entirely possible.
The following profiles are always installed. Click a profile name to open a more detailed description and find the available parameters.
Profile Type | Configuration File Name(s) | Referenced by | Description |
---|---|---|---|
prod, dev | service-specific configurations:
| all services except CONFIG service | Separation of development and production environments. A service with prod (dev) as active profile is running in the production (development) environment. Per default, all services are deployed in the production environment. If you want to build a test environment, you need to manually create the corresponding profiles. The CONFIG service will always try to load parameters from an |
kubernetes | application-kubernetes.yml |
| Used in Kubernetes systems. Furthermore, the API gateway and SYSTEM service query the Kubernetes API Server for other services in the namespace. |
redis | application-redis.yml |
| Redis connection parameters. |
mq | application-mq.yml |
| Messaging queue connection parameters. |
dbs | application-dbs.yml |
| Database connection parameters. |
es | application-es.yml |
| Elasticsearch connection parameters Index configuration used to create Elasticsearch index. |
storage | application-storage.yml |
| Binary data storage connection parameters. |
lc | application-lc.yml | Lifecycle configuration for asynchronous operations. | |
keycloak | - |
| Enables user-role-mapping in Keycloak. |
docker | application-docker.yml |
| The profile |
oauth2 | application-oauth2.yml |
| Contains authentication related parameters. |
metrics | application-metrics.yml |
| Profile under development. In the future, metrics should provide a possibility to monitor responses from the service instance. |
jpapostgres, jpa | - |
| Decides whether PostgreSQL wire protocol (jpapostgres ) or MS SQL (jpa ) should be used for the database connection of the AUDIT and/or REGISTRY service.If jpapostgres is used, the corresponding service uses the PostgreSQL driver that can connect either a PostgreSQL database or a database which implements the PostgreSQL wire protocol, e.g., CockroachDB.For the usage of an MS SQL database, remove the jpapostgres profile from the AUDIT and REGISTRY services and assign the jpa profile instead. |
noamqp | - |
| Decides whether a messaging provider should be used by the API gateway and the COMMANDER service or not. If
If
|
You can set the configuration parameter values in advance during installation.
The configuration parameters are set in the values.yaml
file of the yuuvis
Helm Chart. Modify a value of the listed parameters or add one of the available parameters listed in the above linked fact sheet of the corresponding profile with your desired value to overwrite its default value.
During the deployment, the settings defined in the values.yaml
file will be written into the profile files that are read by the services when they are started.
For changes on a running system, you need to access your Git server.
Navigate to the root directory of the configuration git repositories' appropriate branch and find a list of the configuration files including the above listed profiles. Open the profile, modify it, and check in your changes.
After the modification of a profile, you need to restart the services that reference the profile in order to apply the changes.
New profiles can be added by committing their configuration YAML files to the root directory of the configuration git repositories' appropriate branch.
To activate any custom profile-based configuration, the services that are meant to use them need to set them as their active Spring Profiles.
In Kubernetes, this can be accomplished by modifying the deployment file of the service. Using kubectl edit -n <namespace> deployment <service identifier>
, the active profiles of a given service can be changed. The active profiles are listed under the SPRING_PROFILES_ACTIVE environment variable. Any changes will incur a restart of the services.
Passwords can be outsourced from profile files as Kubernetes Secrets. In the configuration file, placeholders are included instead that are replaced by the actual passwords during the pod's runtime. Please note that passwords as Kubernetes Secrets can be displayed in plain text format in the environment variables of the pods and contained services. The following guideline explains the configuration procedure for the password corresponding to the database connection. The same procedure can also be applied to any other password contained in a profile file.
application-dbs.yml
file to Base64 format.[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("changeme"))
echo -n "changeme" | base64 -w0
Y2hhbmdlbWU=
.Create a yuuvis-secrets.yml
file with the following content:
apiVersion: v1 kind: Secret metadata: name: yuuvis-secrets namespace: yuuvis type: Opaque data: POSTGRES_PASSWORD: Y2hhbmdlbWU= |
The section data contains a list of key-value pairs that can contain multiple entries. As spacers within the string key name, only underscores are allowed. The value is the password in Base64 format.
kubectl apply -f yuuvis-secrets.yml
.Replace the password in the application-dbs.yml
file by a placeholder:
yuuvis.db.password: ${POSTGRES_PASSWORD} |
Adjust the deployments of all yuuvis® services using the profile dbs
by extending the section env
:
env: - name: POSTGRE_PASSWORD valueFrom: secretKeyRef: name: yuuvis-secrets key: POSTGRE_PASSWORD |
The name
and the key
given in secretKeyRef
have to correspond to the name and the data value defined in the file yuuvis-secrets.yml
.
Profiles act as globally reusable configuration elements or allow for the customization of specific service instances. The file name defines whether the configured parameters are available to multiple services or only one specific service. The profiles can be modified directly before the deployment or in a running system. Custom profiles can be added and referenced as well in addition to the always installed profiles. Sensitive data like passwords can be outsourced from the profiles and stored in Kubernetes Secrets instead.
Read on
|