Override the Default System YAML File in Helm Installation

The system.yaml serves as one of the most important configuration files for JFrog products. Our Helm charts build it with some pre-built values that you can modify in the values.yaml file, such as artifactory.database.maxOpenConnections.

However, in advanced use cases, you might want to add some extra values that you cannot modify directly in the values.yaml file.

You can use the following methods to override the system.yaml in the order of preference:

Using extraSystemYaml
Using extraEnvironmentVariables
Using External system.yaml (systemYamlOverride secret)

Using extraSystemYaml

Note

Starting from Artifactory version 107.84.x and above, we recommend to use the extraSystemYaml to override the system.yaml file.

You can provide the specific values that you want to override, by adding them in the following sections:

artifactory.extraSystemYaml for Artifactory
xray.extraSystemYaml for Xray
distribution.extraSystemYaml for Distribution

The entries provided under extraSystemYaml are merged with the system.yaml file in this location (files/system.yaml) to create the final system.yaml. Ensure to add the values correctly, if any typos or wrong keys are added they will not be registered by the product:

Artifactory

artifactory:
  extraSystemYaml:
    shared:
      security:
        bootstrapKeysReadTimeoutSecs: 120

Xray

xray:
  extraSystemYaml:
    shared:
      security:
        bootstrapKeysReadTimeoutSecs: 120

Distribution

distribution:
  extraSystemYaml:
    shared:
      security:
        bootstrapKeysReadTimeoutSecs: 120

Using extraEnvironmentVariables

Another way to modify the system.yaml parameters is by using environment variables. The variables must start with JF, use underscores to separate key order, and have all keys in uppercase.

For example, if the system.yaml parameter shared.security.bootstrapKeysReadTimeoutSecs=120 then its corresponding environment variable will be JF_SHARED_SECURITY_BOOTSTRAPKEYSREADTIMEOUTSECS.

You can provide the specific values that you want to override, by adding them in the following sections:

artifactory.extraEnvironmentVariables for Artifactory
xray.extraEnvironmentVariables for Xray
distribution.extraEnvironmentVariables for Distribution

Artifactory

artifactory:
  extraEnvironmentVariables:
    - name: JF_SHARED_SECURITY_BOOTSTRAPKEYSREADTIMEOUTSECS
      value: "120"

Xray

xray:
  extraEnvironmentVariables:
    - name: JF_SHARED_SECURITY_BOOTSTRAPKEYSREADTIMEOUTSECS
      value: "120"

Distribution

distribution:
  extraEnvironmentVariables:
    - name: JF_SHARED_SECURITY_BOOTSTRAPKEYSREADTIMEOUTSECS
      value: "120"

Using External System.yaml Secret

Warning

This method is not recommended because system.yaml is already generated under files/system.yaml, by incorporating values from values.yaml. Using this method forces you to manage system.yaml manually and should only be used for legacy regressions.

Follow these steps to create an external system.yaml as Kubernetes secret:

Create an external system.yaml file for one of the services. For example, Xray, and create an external system.yaml with the filename (xray-cus-sy.yaml):

configVersion: 1
shared:
    logging:
        consoleLog:
            enabled: true
    jfrogUrl: "http://artifactory-artifactory.rt:8082"
    database:
        type: "postgresql"
        driver: "org.postgresql.Driver"
        username: "xray"
        url: "postgres://xray-postgresql:5432/xraydb?sslmode=disable"
server:
    mailServer: ""
    indexAllBuilds: "true"

Create a Kubernetes secret for the external system.yaml file (xray-cus-sy.yaml):
```
kubectl create secret generic sy --from-file ./xray-cus-sy.yaml
```
Reference the secret and its key under the systemYamlOverride section. Note that, these steps are the same for Artifactory and Distribution charts:
```
systemYamlOverride:
  existingSecret: sy
  dataKey: xray-cus-sy.yaml
```