Configuring Container-Based Systems

As a system administrator, you set up and configure your Automic Automation Kubernetes Edition system.

Note: The Install Operator watches the configmap and it restarts all AE pods (wp, cp, jcp-rest, jcp-ws, jwp) once you have saved your changes.

This page includes the following:

Changing INI Settings

After your system is successfully provisioned, you must edit the ae-properties section of the configmap to change the settings of the INI file of the Automation Engine.

You can use the following kubectl command to edit the ae-properties section of the configmap:

kubectl edit configmap ae-properties

Example of the ae-properties configmap

apiVersion: v1
data:
  AUTOMIC_TRACE_TRC03: '1'
  AUTOMIC_REST_CORSSUPPORTENABLED: '1'
  AUTOMIC_REST_CORSACCESSCONTROLALLOWORIGIN: '*'
  AUTOMIC_GLOBAL_STARTMODE: 'COLD'
kind: ConfigMap
metadata:
  ...

Changing Automic Web Interface Settings

After your system is successfully provisioned, you must edit the awi-properties section of the configmap to change the settings of the Automic Web Interface.

You can use the following kubectl command to edit the awi-properties section of the configmap:

kubectl edit configmap awi-properties

Example of the awi-properties configmap

apiVersion: v1
data:
  AUTOMIC_SYSTEM_NAME: 'AUTOMIC'
  AUTOMIC_CONNECTION_NAME: 'AE_TEST'
  AUTOMIC_MAINCOLOR: '#E61063'
  AUTOMIC_SESSION_COLORS: '#21DE4A,#DE6621,#133AD4'
  AUTOMIC_SSO_SAML_ENABLED: 'true'
kind: ConfigMap
metadata:
    ...

Updating the values.yaml File

The values.yaml file that is provided with the AAKE includes examples of default Helm Chart and external database configuration. You can use this file to configure different aspects of your system.

Important! When configuring containers, take into account that on-disk files are ephemeral. They are lost when containers or pods stop and restart. To store and refer to resources in the cluster (for example, to files such as logs, traces, images and so on), you must first define the names of the corresponding Persistent Volumes (pv) and Persistent Volume Claims (pvc) in the appropriate sections of the values.yaml file. For more information about Volumes in Kubernetes please refer to the official Kubernetes product documentation.

Setting Environment Variables

You can set environment variables using the values.yaml file before you install your system. For more information, see Setting Environment Variables.

For example, you can use them to define where to reach the JCP and REST endpoints. However, once your AAKE system is provisioned, you must use the ae-properties and awi-properties sections of the configmap to change the respective environment variables.

Service Accounts

A default service account is created and automatically mounted into all pods in the namespace, which could be a security risk. Therefore, it is recommended to disable the automount function in the default service account. To do so, set the automountServiceAccountToken parameter to false.

Example

apiVersion: v1
kind: ServiceAccount
metadata:
  name: automic
automountServiceAccountToken: false

Only the operator requires a service account for the installation of AAKE. Therefore, you have to define the name of the dedicated serviceAccount that is used by the operator in the operator: section of the values.yaml file. Make sure you create the service account with the relevant permissions in the namespace.

Example

operator:
  serviceAccount:
    create: true
    name: automic-operator-sa

Stating Alternative Database Tablespaces

When you use cloud-hosted databases, you might not have the permissions required to create or rename tablespaces. In this case, you can state the default tablespaces provided for the AAKE installation as alternative ones in the values.yaml file.

Example

databases:
  automationEngine:
    ...
    dataTablespaceName: <AE data tablespace name>
    indexTablespaceName: <AE index tablespace name>
    ...
  analytics:
    ...
    dataTablespaceName: <Analytics data tablespace name>
    indexTablespaceName: <Analytics index tablespace name>
    ...

For more information, see Preparing the AE and Analytics Databases for the Container Installation.

Setting the Log Target

All AE, Analytics and AWI processes write their activities (logs and traces) to the console by default. However, you can also configure a file to which logs, traces and dumps can be written. If you want to write logs and traces to a file, make sure you define a file for each component (jcp-rest, jcp-ws, jwp, cp, wp, analytics, awi, initialdata).

If you want to use a file instead of the console (default), it is mandatory to define the name of the persistent volume claim (pvc name) to which you want to write log/trace files.

Note: Make sure the access nodes of the PV and PVC you use are set to ReadWriteMany if the pods that access them run on different nodes. If all pods run on a single node, you can also set them to ReadWriteOnce.

Example

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-logging
spec:
  storageClassName: manual
  capacity:
    storage: 4Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: /home/luf/helm/log
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-logging
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

For more information and examples of persistent volumes and persistent volume claims, see the official Kubernetes documentation.

Change the definition of the log and trace parameters from console to file to write the log and trace to the corresponding pvc.

Example

logging:
    pvc:   pvc-logging
    log:   file
    trace: file

If you want to change the trace level, you can do so in the ae-properties and/or awi-properties section of the configmap respectively.

By default, log and trace files are overwritten every time the system is restarted. To keep older files for later use, you can specify the number of history files to be kept by changing the trace level in the respective section of the configmap.

The history files are named 01, 02, and so on, and are moved with every restart. The oldest file (with the highest number) is deleted and all other files are renamed (number is increased by 1).

More information:

Setting the Custom Logo

You can customize the logo that is displayed in the AWI menu bar using two environment variables, one to set the image and another one to specify the MIME type. You configure the custom logo in the [environment] > [AWI] > [logo] section of the values.yaml file.

Prerequisite: You have already defined the pvc and pv names.

To specify the image add and configure one of the following environment variables:
- AUTOMIC_LOGO_BASE64
  
  Use this variable to enter the text that corresponds to the image in BASE64 format.
- AUTOMIC_LOGO_FILENAME
  
  Use this variable to enter the name of the image file.
Specify the MIME type.

Add and configure an AUTOMIC_LOGO_MIMETYPE variable for image types other than .PNG.

Changing the AE Certificate within the Cluster

Within the Kubernetes cluster, the JCP by default uses a generated, self-signed certificate. Therefore, you do not have to prepare a TLS/SSL certificate for the server processes within the cluster.

However, you can replace the generated, self-signed certificate with a custom one and configure it accordingly. To do so, you have to do the following before the installation:

Depending on how you want to connect to the system, define either the IP address or DNS name for the Subject Alternative Name (SAN). You can choose multiple SANs.
Create the KeyStore for jcp-ws and your custom SANs. Make sure that the jcp-ws is also a DNS entry for the Subject Alternative Name (SAN).

Note: You can use any alias, passwords, and keystore names you want.
Export the certificate from the KeyStore.
Use base64 to encode your relevant data: certificate, keystore, alias, and passwords.
Create the secret in the Kubernetes namespace, in which AAKE is going to be installed.

Note: Make sure that the name of the secret is jcp-ws-certificate and enter your base64-encoded values with the following keys:
- * certificate
- * pc12-keystore
- * keystore-password
- * key-alias
- * key-password
Make sure that you run the AAKE installation in the same namespace in which you created the secret.
Connect to the jcp-ws using one of the Subject Alternative Name (SAN) addresses and the port of the service.

More information: