Excerpt | |||||
---|---|---|---|---|---|
| |||||
Add Helm RepositoryAdd the helm repository where the Usage Engine Private Edition helm chart is located by running the following command:
Although it is not a strict requirement, the install commands used throughout this installation guide assume that the repository has been added like this. |
Excerpt | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||
Container ImagesUsage Engine Private Edition consists of the following container images hosted in the Digital Route AWS ECR registry:
Where Note! Since Usage Engine Private Edition 3.1, the container images have multi-architecture support (AMD and ARM). Hosting Container Images in Your Own Container RegistryIf you have your own container registry, it is recommended that you host the Usage Engine Private Edition container images there rather than in the Digital Route AWS ECR registry. In order to access the container images in the Digital Route AWS ECR registry, you will need to authenticate yourself first. Here is how you can do this using the
Where Once authenticated, you can pull the container images, re-tag them and then finally push them to your own container image repository. Depending on how your container registry is configured, you probably need to set up an image pull secret that allows the Kubernetes cluster to pull the container images from your container registry in runtime. Image Pull Secret for Digital Route AWS ECROn the other hand, if you do not have your own container image registry, then you need to set up an image pull secret that allows the Kubernetes cluster to pull the container images from the Digital Route AWS ECR in runtime. Such a secret can be created like this:
Where Since AWS ECR credentials expire after 12 hours, the image pull secret needs to be refreshed regularly. This can be automated through a cron job. The following yaml spec is an example of such a cron job:
Where Simply put the above yaml spec into a file called
|
...
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:
Please note that the Note! If your deployment is intended for a production or production-like environment, skip the self-signed 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:
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 (where “jdbcPassword” in the template parameter is the credential you would like to inspect):
|
...