...
Excerpt | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
System Database
The Usage Engine Private Edition helm chart is capable of automatically creating the system database at install time. However, that assumes that you are able to supply database administrator credentials (see Bootstrapping System Credentials). If, for one reason or another, you are unable to supply that, the system database must be created manually prior to installing the Usage Engine Private Edition helm chart. A tool called To use it, simply go to Release Information, download it for the relevant version, and then execute it like this:
The instructions on screen will guide you through the process of configuring the database, and once done, a set of database scripts will be generated. These database scripts can then be used to create the system database. |
Excerpt | ||||||
---|---|---|---|---|---|---|
| ||||||
TLS
It is recommended to install Usage Engine Private Edition with TLS enabled, and there are two different ways of providing the required certificate:
Here follows an explanation of the preparations required for each of the two. |
Excerpt | ||||
---|---|---|---|---|
| ||||
cert-managerThe most automated and secure way to provide the certificate is to use https://cert-manager.io/ . If it is not already installed in your Kubernetes cluster, follow these instructions on how to install the cert-manager https://cert-manager.io/docs/installation/helm/ chart. Make sure to install a version that is listed in the Compatibility Matrix.
|
Excerpt | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
Cert-manager must be backed by a certificate authority (CA) to sign the certificates. Once configured with a CA, cert-manager will automatically sign and renew certificates for the system as needed. Configuring cert-manager with a CA is done by creating an Refer to https://cert-manager.io/docs/configuration/ for a all the details. It’s also possible to use an issuer specifiction that will issue a self-signed certificate:
Note that this is only recommended for testing purposes and not in production. Regardless of the chosen issuer specification, to create the issuer, simply put the specification in a yaml file (here we call it
Based on the example above the created
|
...
Excerpt | |||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||
Bootstrapping System Credentials
Usage Engine Private Edition uses a number of system credentials in order to function as expected. These system credentials are kept in a Kubernetes secret called This secret can be populated in three different ways:
Note that the three options are not mutually exclusive. It is possible to populate some credentials in advance, some through helm values, and let some be automatically generated. Here follows an explanation of the system credentials used by Usage Engine Private Edition:
This is an example of how to create and populate the secret with some credentials:
To inspect the content of the secret, simply execute the following command:
To retrieve a given credential in cleartext, simply execute a command like this:
|
...