Preparing the AE and Analytics Databases for the Container Installation

You have to prepare new, empty AE and Analytics databases if you want to install a new (v21) AAKE system including an Analytics deployment. You can also decide not to deploy Analytics. For more information, see Disabling the Analytics Installation.

Note: The Event Engine feature is not supported in the Automic Automation Kubernetes Edition.

You also have the option to use a backup of your existing databases.

More information:

This page includes the following:

Using a New Database

The Automation Engine supports Oracle and PostgreSQL databases for the container-based system. Analytics supports only PostgreSQL databases. Only PostgreSQL versions 10 or 11 are supported. Make sure that the databases can be reached from the cluster.

To use a PostgreSQL or Oracle database for the Automation Engine, you have to prepare the database as usual.

In both cases, you have to adapt the values.yaml file. It also allows you to state the default tablespaces provided for the AAKE installation as alternative ones in case you are using cloud-hosted databases and do not have the permissions required to create or rename tablespaces.

Make sure you also adapt the connection settings for the databases that you prepared in the values.yaml, if you want to enable an ingress. For more information, see Connecting to AWI, the JCP and REST Processes Using an Ingress.

You can configure each of the required database connections independently. They can point to the same database server, if that is the case.

Important! It is recommended to use a Kubernetes secret to pass the relevant database connection information.

When using PostgreSQL databases, you can also use TLS/SSL to secure the connection to the DB server. To do so, make sure the secret has the necessary parameters to mount the db-postgresql-root.crt certificate and that the sslmode is defined to secure the connection either with (sslmode=verify-full) or without (sslmode=verify-ca) host verification, see Securing PostgreSQL Database Connections - AAKE.

You have to provide the Kubernetes secret with the name defined in the same namespace.

databases:
  automationEngine:
    secretName: ae-db
  analytics:
    secretName: analytics-db

The Kubernetes secret must contain the following parameters:

  • vendor: vendor name, either postgres or oracle

  • host: hostname where the database can be reached

  • port: port where the database can be reached

  • db: name of the database

  • user: username for the database

  • password: password for the user

  • data-tablespace-name: name of the data-tablespace (only AE DB)

  • index-tablespace-name: name of the index-tablespace (only AE DB)

  • additional-parameters: additional parameters for vendor specific parameters which are sometimes needed, depending on the database configuration

The host parameter definition can vary depending on the database you use and where it is located. For example, if you use a managed database located outside the cluster, the host could be a domain name (<your-db-instance-domain>), an IP address (<your-db-instance-ip-address>), etc. Your cloud provider provides those values. If it is an on-premises database outside the cluster, the definition could be a specific hostname.

If you use, for example, a PostgreSQL database in the same cluster in which AAKE runs, the definition of the host parameter requires a specific format: <db-instance>.<namespace>.svc.cluster.local.

Example AE DB - Oracle

kubectl create secret generic ae-db-oracle \
  --from-literal=host=external-oracle.location \
  --from-literal=vendor=oracle \
  --from-literal=port='1521' \
  --from-literal=user=username \
  --from-literal=db=ORCLCDB.localdomain \
  --from-literal=password=S3cret \
  --from-literal=data-tablespace-name=ae_data \
  --from-literal=index-tablespace-name=ae_index \
  --from-literal=additional-parameters=";SP=NLS_LANGUAGE=AMERICAN,NLS_TERRITORY=AMERICA,CODESET=WE8MSWIN1252,NLS_LENGTH_SEMANTICS=CHAR"

Example AE DB - PostgreSQL

$ kubectl create secret generic ae-db-postgres \
--from-literal=host=external-postgres.location \
--from-literal=vendor=postgres \
--from-literal=port='1521' \
--from-literal=user=username \
--from-literal=db=POSTGRESDB.localdomain \
--from-literal=password=S3cret \
--from-literal=data-tablespace-name=ae_data \
--from-literal=index-tablespace-name=ae_index \
--from-literal=additional-parameters="connect_timeout=10 client_encoding=LATIN9"

Example Analytics DB - PostgreSQL

The Kubernetes secret for the Analytics database does not require you to define the data-tablespace-name and index-tablespace-name parameters. The respective tablespace names are defined on the fly as Analytics is deployed.

kubectl create secret generic analytics-db-postgres \
  --from-literal=host=external-postgres.test.svc.cluster.local \
  --from-literal=vendor=postgres \
  --from-literal=port='1521' \
  --from-literal=user=username \
  --from-literal=db=POSTGRESDB.localdomain \
  --from-literal=password=S3cret

Another option is to define the database connection required in the values.yaml file. However, keep in mind that the values.yaml file definition is also stored in a configmap and passwords may be exposed.

Example Oracle

For Oracle databases, set the vendor parameter to "oracle" and define the additionalParamaters as required.

databases:
  automationEngine:
    vendor: oracle
    host: external-oracle.location
    port: "5432"
    name: ae
    user: ae
    password: ae
    additionalParameters: ;SP=NLS_LANGUAGE=AMERICAN,NLS_TERRITORY=AMERICA,CODESET=WE8MSWIN1252,NLS_LENGTH_SEMANTICS=CHAR
  analytics:
    host: external-postgres.location
    port: "5432"
    user: analytics
    password: analytics
    name: analytics

Example PostgreSQL

For PostgreSQL databases, set the vendor parameter to "postgres". For the AE database, define the dataTablespaceName and indexTablespaceName parameters as required.

No specific setup is required for a new Analytics database. You only have to define the host, port, user, password and database name. The dataTablespaceName and dataTablespaceName parameters are defined on the fly as Analytics is deployed.

databases:
  automationEngine:
    vendor: postgres
    host: external-postgres.location
    port: "5432"
    name: ae
    user: ae
    password: ae
    dataTablespaceName: ae_data
    indexTablespaceName: ae_index
  analytics:
    host: external-postgres.location
    port: "5432"
    user: analytics
    password: analytics
    name: analytics

Using an Existing Database

Using an existing Analytics database does not require any special configuration. You only have to configure the database connection as described before using the data from your existing database.

In the case of the AE database, you use a backup of your existing (12.3) database if you want to migrate your existing on-premises system to a higher AAKE version.

More information:

Pre-Migration Checklist

Before starting the migration, go through the following issues and make sure you have all requirements in place:

  • For the Automation Engine, Automic Automation Kubernetes Edition only supports PostgreSQL and Oracle databases

  • Make sure that you have configured the database connection to the existing AE database

    Example AE DB - PostgreSQL

    $ kubectl create secret generic ae-db-postgres \
--from-literal=host=external-postgres.location \
--from-literal=vendor=postgres \
--from-literal=port='1521' \
--from-literal=user=username \
--from-literal=db=POSTGRESDB.localdomain \
--from-literal=password=S3cret \
--from-literal=data-tablespace-name=ae_data \
--from-literal=index-tablespace-name=ae_index \
--from-literal=additional-parameters="connect_timeout=10 client_encoding=LATIN9"

  • Make sure that you set the existing system name for the Automation Engine and the Automic Web Interface using the respective environment variable in the values.yaml file

  • Create a Kubernetes secret that contains the admin credentials for the existing Client 0. The secret must be created in the namespace in which the AAKE system is installed.

    Example 

    kubectl create secret generic client0-user \
  --from-literal=client='0' \
  --from-literal=user='ADMIN' \
  --from-literal=department='ADMIN' \
  --from-literal=password='UC4'

  • Set the operator.migrate parameter in the values.yaml file is set to true

See also: