Deploy ADONIS with Kubernetes

This guide walks you through the deployment of ADONIS in a Kubernetes environment using Helm charts.

Remarque

Before deployment, make sure that all Hardware/Software Requirements are met.

What You Will Do

The deployment process consists of the following steps:

1. Prepare your environment - Verify that all necessary tools and credentials are in place.

2. Create a database - Set up the database that ADONIS will use to store its data.

3. Configure the deployment - Prepare registry authentication and the Helm values file with your specific settings.

4. Deploy ADONIS - Deploy ADONIS to your Kubernetes cluster.

5. Manage your deployment - Access logs, monitor your application, and perform common tasks.

About This Deployment

This guide describes a minimal setup suitable for development, testing, and evaluation. The configuration provided is functional but needs to be adapted for production use depending on how your cluster is set up and which tooling you use. This is especially important regarding the following points where our example simplifies in comparison to best practices:

• Storage: Uses basic persistent volume storage; production deployments typically require more robust storage solutions.

• Access: Uses port-forwarding for access; production deployments use Ingress or similar exposure methods.

• Networking: Assumes basic network connectivity; production deployments require careful network policy configuration.

For production use, consult your Kubernetes administrator and the official documentation for Kubernetes, Helm, and your infrastructure platform.

Remarque

This deployment guide assumes you have:

• A Kubernetes cluster already set up and accessible

• kubectl, helm, and docker command-line tools installed on your administrative machine

• Network access from your administrative machine to both the Kubernetes cluster, your database server and the BOC OCI registry.

• Appropriate credentials for the BOC OCI registry and the database server

Preparation and Prerequisites

Prepare your environment for ADONIS Kubernetes deployment by verifying prerequisites.

Before you begin the ADONIS deployment, you must verify that your environment meets all requirements and that all necessary tools, files, and credentials are in place.

Required Tools and Access

You will need the following tools installed on your administrative machine:

• Kubernetes (kubectl): Command-line tool for interacting with your Kubernetes cluster.

• Helm: Package manager for Kubernetes used to deploy ADONIS.

• Docker: Container runtime needed for some one-time operations, like creating a database.

Verify Your Tools

Verify that all tools are installed and working correctly:

docker version
kubectl version --client
helm version

Each command should return version information. If any tool is missing, install it according to the official documentation for your platform.

Access to Your Kubernetes Cluster

Verify that you can access your Kubernetes cluster:

kubectl cluster-info

This command should display information about your cluster. If it fails, ensure that your kubeconfig file is properly configured and that you have network access to the cluster.

Database Server

Before deployment of ADONIS, you must have a database server running and accessible from your Kubernetes cluster:

• Database Type: A supported version of PostgreSQL or MS SQL Server according to the Hardware/Software Requirements

• Network Access: Your Kubernetes cluster must have network access to the database server

• Administrator Credentials: You need a username and password for a database administrator account with permissions to create new databases

Write down the following information for later use:

• Database server hostname or IP address

• Database server port

• Database server admin username

• Database server admin password

Container Registry Credentials

ADONIS container images are hosted in a registry provided by BOC. You must have credentials to authenticate which you will receive from your ADONIS consultant. The registry credentials contain:

• Registry URL: The BOC container registry URL

• Access Identifier: Access identifier for the repository containing the images

• Access Token: The authentication token to access these images

These credentials are used both for Helm to access the Helm chart repository and for Kubernetes to pull the container images.

Files You Will Need

Prepare the following files on your administrative machine. In this manual we create a directory /opt/data to store these files, if you want to place them in a different directory, adapt the paths accordingly:

mkdir -p /opt/data/license /opt/data/library /opt/data/logs

Place the following files in the appropriate directories:

• License File: Place your ADONIS license file (e.g., license.xxl) in /opt/data/license/

• Library File (optional): If you are using a custom ADONIS application library instead of the standard library, place your library file (e.g., library.axl) in /opt/data/library

Remarque

If you are using the standard ADONIS library, the library file is included in the container image and you do not need to provide a custom library file.

BOC-Provided Information

You should have received the following from your ADONIS consultant:

• ADONIS license file (license.xxl)

• Container registry access information and credentials

• Custom library file (if applicable)

Checklist

Before proceeding to the next step, verify the following:

• kubectl, helm, and docker are installed and functional

• You can access your Kubernetes cluster with kubectl cluster-info

• You know your database server hostname, port, and administrator credentials

• You have received necessary information to access the container registry from your ADONIS consultant

• You have created the /opt/data directory with appropriate subdirectories

• You have placed your license file in /opt/data/license

• You have placed your custom library file in /opt/data/library (if applicable)

Creating or Upgrading a Database for ADONIS

Create or upgrade a database for ADONIS before deployment in Kubernetes.

Before you can deploy ADONIS in your Kubernetes cluster, you must make sure that you have a dedicated database with the correct schema for ADONIS 19.0. This database stores all ADONIS data and configuration.

If you:

• Perform a new deployment of ADONIS: Please refer to the chapter Create Database for details.

• Upgrade an existing deployment of ADONIS: Please refer to the chapter Upgrade ADONIS for details.

Configuration of the Deployment

Create the Helm values configuration file for ADONIS Kubernetes deployment.

Before deploying ADONIS to your Kubernetes cluster, you must enable Kubernetes to access the Helm chart and images in the BOC OCI registry and create a configuration file that Helm will use during deployment. This file specifies container image locations, database connection details, storage settings, and other deployment options.

Authenticate with the Container Registry

Helm needs credentials to access the BOC OCI container registry where the ADONIS Helm chart is stored. You will receive all necessary information from your ADONIS consultant. There are multiple ways credentials can be safely stored and passed to Helm, including third-party tools.

If you just created a new database or upgraded an existing database, then you will still have the docker config.json containing the credentials for the login. If not, you can create this file manually in a text editor of your choice. The following command will log in to the BOC OCI registry with the supplied credentials:

helm registry login <boc-registry-url> --registry-config <config.json>

Replace the placeholders:

• <boc-registry-url> - The BOC OCI container registry URL

• <config.json> - A JSON file containing the registry access information you received from your ADONIS consultant

Attention

The config.json file contains your credentials in plain text and should be safely deleted after the deployment.

Remarque

Do not pass credentials directly as command parameters, the bash command history stores a list of recent commands and could therefore inadvertently reveal the credentials.

Create an ImagePullSecret for Container Registry

Kubernetes needs credentials to pull the ADONIS container images. The simplest way to give Kubernetes access to the BOC OCI registry is by creating an ImagePullSecret in your cluster which reads the credentials from a file with the same structure as docker uses.

If you just created a new database or upgraded an existing database, then you will still have the docker config.json containing the credentials for the login. If not, you can create this file manually in a text editor of your choice.

The following command will direct Kubernetes to read credentials from a file <config.json>:

kubectl create secret generic <your-secret-name> --from-file=.dockerconfigjson=<config.json> --type=kubernetes.io/dockerconfigjson

Replace the placeholders:

• <your-secret-name> - A name for this secret (e.g., boc-registry-secret). This must match the imagePullSecrets value in the configuration file you create in the next step.

• <config.json> - A JSON file containing the registry access information you received from your ADONIS consultant.

The secret is now stored in your Kubernetes cluster and will be used when pulling images.

Attention

The config.json file contains your credentials in plain text and should be safely deleted after the deployment.

Remarque

Do not pass credentials directly as command parameters, the bash command history stores a list of recent commands and could therefore inadvertently reveal the credentials.

Remarque

There are multiple ways how to handle credentials with Kubernetes, including external tools storing the credentials and only providing them to Kubernetes at runtime. Such tools therefore provide a much higher level of security than an ImagePullSecret because the cluster has only access to the secrets temporarily when needed. Please ensure that all credentials are stored in a safe way.

Create the Configuration File

Create a new file named setup.yaml in your /opt/data directory:

touch /opt/data/setup.yaml

Edit this file with your preferred text editor and copy the following configuration template into it. Replace all placeholder values (shown in angle brackets) with your actual environment details:

axx:
  imagePullSecrets:
    - name: <your-secret-name>

  logMode: <STD|MIXED|FILES>
  aserver:
    env:
      - name: ADOXX_SERVER_DBHOST
        value: <database-hostname>
      - name: ADOXX_SERVER_DBPORT
        value: <database-port>
      - name: ADOXX_SERVER_DBTYPE
        value: <PostgreSQL|SQLServer>
      - name: ADOXX_SERVER_DBNAME
        value: <database-name>
      - name: ADOXX_SERVER_WEBTIERAUTH_TRUSTED_HOSTS
        value: <ip-or-range-of-webserver>
    image:
      repository: <boc-registry-aserver>
      tag: <product-version>
    persistence:
      enabled: true
      mountPath: "/mnt"
      accessMode: "ReadWriteOnce"
      size: <maximum-size-of-storage>
      storageClass: ""
      annotations: {}
  webserver:
    env:
    image:
      repository: "<boc-registry-webserver>"
      tag: <product-version>
    persistence:
      enabled: true
      mountPath: "/mnt"
      accessMode: "ReadWriteOnce"
      size: <maximum-size-of-storage>
      storageClass: ""
      annotations: {}

Placeholder Explanations

Replace the placeholders in your configuration file with the appropriate values. Each placeholder is explained below:

Image Pull Credentials

<your-secret-name>: The name of the Kubernetes secret that contains your container registry credentials. This must exactly match the name of the secret you defined in the previous step.

Remarque

There are multiple ways to handle credentials with Kubernetes, including external tools storing the credentials and providing them to Kubernetes at runtime. Please ensure that all credentials are stored in a safe way.

Logging

<STD|MIXED|FILES>: How ADONIS should handle logging. Choose one of the following:

• MIXED: Writes logs to both standard output and to persistent files in the container volume. This is the recommended value for all use cases. You can either ingest logs with an external log management software or view logs using the Kubernetes built-in kubectl logs command. You can also access the files directly, depending on the Kubernetes storage solution.

• FILES: Writes logs only to persistent files in the container volume. This is commonly used if you have a log management tool which ingests files and you do not want logs to appear in the Kubernetes logs. There are a number of tools for this purpose which often provide some dashboard or other ways to analyze the logs.

• STD: Writes all logs to standard output. This is commonly used if you have a log management tool which offers real-time ingestion and aggregation of logs and you do not want to store the log files on disk. There are a number of tools for this purpose which often provide some dashboard or automated alerts. Please note that if logs are not stored persistently, it is not possible to use the feature to download a Support Information Package (SIP) to provide the logs to the BOC Support Hotline.

Remarque

For contact with BOC Hotline you can use the ADONIS functionality to download a Support Information Package (SIP) from the ADONIS Administration page to provide log files. This will create an encrypted ZIP file to transmit logs securely.

Database Configuration

<database-hostname>: The hostname or IP address of your database server. Example: db-server.example.com or 192.168.1.100.

Database Port

<database-port>: The port on which your database server listens. Common defaults:

• PostgreSQL: 5432

• MS SQL Server: 1433

Database Name

<database-name>: The name of the ADONIS database you created in the previous step. You specified this when running the database creation tool. Example: productdb or product.

Remarque

If the name of the database contains special characters, it must be enclosed in double quotes in the YAML configuration.

Database Type

PostgreSQL or SQLServer: Specify which database system you are using. For supported versions, please refer to the HW/SW Requirements.

Web Server Access

<ip-or-range-of-webserver>: The IP address or IP range from which the web server will connect to the application server. In this minimal setup, both run in the same cluster so you can typically use the pod IP or service name, in production this depends on your network configuration of the Kubernetes cluster. Common values are the service name like adonis-webserver or 10.0.*.*

Container Images

<boc-registry-aserver>|webserver>: The location of the application server or web server image in the BOC OCI container registry. This value is provided by your ADONIS consultant.

ADONIS Version

<product-version>: The version of ADONIS to deploy. This is the version tag of the image and Helm chart in the BOC OCI registry and matches the version you want to deploy, e.g. 19.0.

Storage Configuration

For Development and Testing

The persistence configuration shown in this example is suitable for minimal deployments:

• enabled: true - Enable persistent storage for logs and other data

• size: <maximum-size-of-storage> - Allocate at least 1 GB of storage for the Full Text Search (FTS) files and logs. The size depends on how large your environment is and especially on the number of document files uploaded into the database.

• storageClass: "" - Use the cluster's default storage class

Attention

It is not recommended to use this storage type for production environments. Kubernetes can work with a number of different solutions for providing distributed and high-availability storage to a pod.

For Production

In a production environment, you will typically use a storage provider offering distributed, high-availability storage to a pod. There are a number of different services available. Which one is suitable for your cluster depends on various factors, including the type and location of your storage, the size of the cluster, and other factors. Examples of such services are CEPH/Rook, Longhorn and others.

Some considerations when defining storage for ADONIS:

• Storage size for the Full Text Search (FTS) in large environments with lots of indexed documents can be several gigabytes.

• The Full Text Search (FTS) can be recreated at any time but in large environments this can take a long time, during which search in ADONIS will deliver no or incomplete results. Consider a resilient solution with easy recovery.

• If you are using a centralised logging solution, consider using a separate, dedicated storage for logs.

These topics are specific to your infrastructure and Kubernetes cluster configuration. Consult your Kubernetes administrator or infrastructure team for production-appropriate storage configuration.

Commonly Used Environment Variables

Aside from the required environment variables used in our example, there is a list of commonly used variables for specific purposes. Please check if they apply in your case and add them to the setup.yaml file. In the table below, we specify for which container they apply. Variables for the Application Server must be added to the aserver: section of the file, while variables for the Web Server must be added to the webserver: section.

Container	Environment Variable	Description
Application Server	ADOXX_ACCENT_INSENSITIVE	Determines if the search ignores accents, e.g. (ä = a), so searching for test or têst would yield the same results. Type: BOOL Default: True
Application Server	ADOXX_DBMS_ENCRYPTION	If Microsoft SQL Server is used with ODBC driver version 18 and higher, encrypted communication is enforced by default. If your server does not encrypt ODBC connections, this value has to be set to optional otherwise the connection fails. Valid values: optional, mandatory, strict Default: mandatory
Application Server	ADOXX_DBMS_TRUST_SERVER_CERTIFICATE	Sets whether the server certificate should be trusted when opening an encrypted ODBC connection. Valid values: yes, no Default: no
Application Server	ADOXX_LOG_MODE	Logging can be done to files, standard output or both. Valid values: FILES, STD, MIXED Default: FILES
Application Server	ADOXX_SECURITY_DISABLE_AUDIT_LOG_SENSITIVE_DATA_ENCRYPTION	By default, user names and other PII in audit logs are encrypted to protect sensitive information. Can be disabled so administrators can view this information. Type: BOOL Default: False (= encryption is ON)
Application Server	ADOXX_SECURITY_DISABLE_SENSITIVE_DATA_ENCRYPTION	By default, user names and other PII in regular logs are encrypted to protect sensitive information. Can be disabled so Administrators can view this information. Type: BOOL Default: False (= encryption is ON)
Application Server	ADOXX_SERVER_DBNAME	Name of the database. Required.
Application Server	ADOXX_SERVER_DBTYPE	Database system. Required. Valid values: PostgreSQL or SQLServer No default
Application Server	ADOXX_SERVER_PORTS	This determines how many aworker instances will be created. Each port number is a separate aworker instance. Comma-separated. Required. Valid values: Port numbers No default
Application Server	SERVER_AUTO_CLEANUP	Automatically restarts the aworkers at the scheduled day and time. Type: BOOL Default: True
Application Server	SERVER_AUTO_CLEANUP_DAY	List of space-separated numbers designating the days in the week. Valid values, e.g. 1 2 3 Default: 1 2 3 4 5 6 7 (= daily)
Application Server	SERVER_AUTO_CLEANUP_TIME	Time when the restart should be executed. Valid format: 00:00 Default: 00:00
Web Server	AXW_PROPERTIES_aservers	List of aservers separated by commas in the form <Server Number>:<Server Name/IP>. Required. Valid format, e.g. AS1:127.0.0.1 No default
Web Server	AXW_PROPERTIES_aworkers	List of aworker instances and ports in the form <Server Number>:<Port>. Required. Valid format, e.g AS1:41900 No default
Web Server	AXW_PROPERTIES_aworker_purpose_mail	Designates a specific aworker to handle mail jobs. Valid format, e.g AS1:41900 No default
Web Server	AXW_PROPERTIES_aworker_purpose.scheduler	Designates a specific aworker to handle background jobs. Valid format, e.g AS1:41900 No default
Web Server	AXW_PROPERTIES_aworker_purpose_system	Designates a specific aworker to handle system background jobs. Valid format, e.g AS1:41900 No default
Web Server	AXW_PROPERTIES_aworker_purpose_user	Designates a specific aworker to handle user sessions. Valid format, e.g AS1:41900 No default
Web Server	AXW_PROPERTIES_custom_version	Optional version which can be supplied to tell browsers to reload scripts and styles if some file has been changed although the revision has not been changed. Default: empty
Web Server	AXW_PROPERTIES_http_proxy_ip	IP of proxy which handles connections to the internet for certain features and third party services. Valid format: IP address Default: empty
Web Server	AXW_PROPERTIES_http_proxy_port	Port of the proxy. Valid format: Port number Default: empty
Web Server	AXW_PROPERTIES_mail_enable_security	Enable/disable security restrictions for sending emails. Type: BOOL Default: True
Web Server	AXW_PROPERTIES_mail_max_mail_size	The maximum size of an email (kB) allowed to be sent. Setting this too small can prevent emails from being sent. We recommend 500 kB for emails with lots of links. Type: INTEGER Default: 50
Web Server	AXW_PROPERTIES_mail_max_mails_per_hour	Maximum number of mails allowed to be sent in one hour. Type: INTEGER Default: 500
Web Server	AXW_PROPERTIES_mail_max_recipients_per_mail	Maximum number of recipients for one email. Type: INTEGER Default: 500
Web Server	AXW_PROPERTIES_mail_send_smtp_localhost	If mail should be sent via the SMTP of the localhost. Type: BOOL Default: False
Web Server	AXW_PROPERTIES_mail_sender_verbose	How much information is logged on error. Type: BOOL Default: False
Web Server	AXW_PROPERTIES_mail_trusted_recipient_domains	Emails can only be sent to recipients in the list of domains. Valid values: Domains Default: empty
Web Server	AXW_PROPERTIES_report_parallel_execution	This limits how many reports can be created at the same time. Setting this too high can impact performance for users. If more than this number are requested by users, they will be queued. Type: INTEGER Default: 3
Web Server	AXW_PROPERTIES_search_result_max_size	Limits the number of results a search can deliver. Setting this too low may lead to items not shown in search results. Type: INTEGER Default: 10000
Web Server	AXW_PROPERTIES_security_csp	Sets the Content Security Policy. Either the entire policy can be set in this variable or one or more of the _src_ variables below can be used for specific purposes. default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src * data: filesystem:; frame-src 'self'; media-src 'self'; connect-src 'self'; font-src data: 'self'; frame-ancestors 'none'; See reference for information on the exact settings https://content-security-policy.com/
Web Server	AXW_PROPERTIES_security_encrypt_usernames	Whether user names are encrypted in the logs. Setting this to False has implications about data protection of PII. Type: BOOL Default: True
Web Server	AXW_PROPERTIES_security_src_connect_src	Sets the Content Security Policy for AJAX requests. Default: connect-src 'self';
Web Server	AXW_PROPERTIES_security_src_frame_ancestors	Sets the Content Security Policy for embedded resources. Default: frame-ancestors 'none';
Web Server	AXW_PROPERTIES_security_src_frame_src	Sets the Content Security Policy for embedded frames. Default: frame-src 'self';
Web Server	AXW_PROPERTIES_security_src_img_src	Sets the Content Security Policy for images. Default: img-src * data: filesystem:;
Web Server	AXW_PROPERTIES_security_src_media_src	Sets the Content Security Policy for media. Default: media-src 'self';
Web Server	AXW_PROPERTIES_security_src_script_src	Sets the Content Security Policy for script tags. Default: script-src 'self' 'unsafe-inline' 'unsafe-eval';
Web Server	AXW_PROPERTIES_security_src_style_src	Sets the Content Security Policy for style tags. Default: style-src 'self' 'unsafe-inline';
Web Server	AXW_PROPERTIES_translationsvc_microsoft_azure_api_key	Automatic translation using the Microsoft Azure Translation service can be enabled by adding the encrypted API key here. Default: empty (= translation disabled)
Web Server	AXW_PROPERTIES_translationsvc_microsoft_azure_region	The region for the Microsoft Azure Translation service. Default: empty
Web Server	AXW_PROPERTIES_translationsvc_microsoft_azure_subdomain	The custom sub domain for the Microsoft Azure Translation service. Default: empty

Deploy ADONIS

Deploy ADONIS to your Kubernetes cluster using Helm.

This section guides you through deploying ADONIS to your Kubernetes cluster using Helm. You have already performed the authentication for Helm and created the ImagePullSecret for Kubernetes, so the next steps are to retrieve the Helm chart, and deploy your ADONIS application.

Pull and Extract the Helm Chart

Pull the ADONIS Helm chart from the registry and extract it to your local machine:

helm pull oci://<boc-registry>/<helm-repository>
tar zxvf <product>-<product-version>.tgz

Replace:

• <boc-registry> - The BOC OCI registry URL. You will receive this from your ADONIS consultant

• <helm-repository> - The location of the Helm chart in the repository. You will receive this from your ADONIS consultant

Verify Configuration with Dry Run

Before actually deploying, verify that your configuration is correct and complete:

helm install <your-product> ./<chart-filename> -f /opt/data/setup.yaml --dry-run

Replace:

• <your-product> - Choose a suitable name for the deployment. This name will be used as the prefix for all created resources.

• <chart-filename> - This is the filename of the Helm chart you extracted in the previous step.

This command simulates the deployment without making any changes:

• It validates your YAML configuration for syntax errors

• It shows which resources will be created

• It displays any validation errors or warnings

Review the output carefully. If there are errors, correct your setup.yaml file and run the dry-run command again.

Deploy ADONIS

Once the dry run completes successfully, deploy ADONIS to your cluster:

helm install <your-product> ./<chart-filename> -f /opt/data/setup.yaml

Helm will create the necessary Kubernetes resources and start deploying ADONIS. This process may take a few minutes.

Optional: Deploy to a Specific Namespace

To deploy ADONIS into a specific Kubernetes namespace instead of the default namespace:

helm install <your-product> ./<chart-filename> -f /opt/data/setup.yaml --namespace <your-namespace>

If the namespace does not exist, add the --create-namespace flag:

helm install <your-product> ./<chart-filename> -f /opt/data/setup.yaml --namespace <your-namespace> --create-namespace

Verify the Deployment

After deployment, verify that your ADONIS pods are running and healthy:

kubectl get pods --watch

This command displays the status of all pods. Watch the output until you see both the aserver and webserver pods reach the 1/1 state (meaning they are running and ready).

Press Ctrl+C to exit the watch command once both pods are ready.

Expected pod status output

NAME READY STATUS RESTARTS AGE your-product-aserver-0 1/1 Running 0 45s your-product-webserver-0 1/1 Running 0 40s

If pods remain in a Pending or CrashLoopBackOff state, check the logs for errors:

kubectl logs <pod-name>

Refer to Managing Your Deployment for troubleshooting steps.

Remarque

Once pods are started and healthy, the application server and web server load configuration and execution data (bootstrapping), it will take some time before the login page is available.

Access ADONIS

Minimal Setup Access (Development/Testing)

For development and testing purposes, you can use port forwarding to access ADONIS:

kubectl port-forward service/my-product-webserver 8080:8080 --address 0.0.0.0

This command forwards port 8080 on your machine to port 8080 on the web server service. You can then access ADONIS at:

http://localhost:8080/

Attention

Important: Port forwarding is not suitable for production use. It provides direct access from a single administrative machine and is intended only for testing the environment after deployment. Port forwarding is only temporary and does not survive restarts of the pod or the machine where the port forward is running.

Production Setup: Service Exposure

In a production environment, you need a proper service exposure method. The webserver is exposed as a ClusterIP service by default.

Frequently used production service exposure options include the following, but there are a number of other options available depending on your Kubernetes setup and requirements:

• Ingress Controller: Use an Ingress resource with a controller such as Nginx, Traefik, or your cloud provider's ingress controller. This provides URL-based routing, TLS termination, and load balancing.

• LoadBalancer Service: Change the service type to LoadBalancer if your Kubernetes cluster provider supports it. This exposes the service through your cloud provider's load balancing service.

Each approach requires specific configuration and knowledge of your Kubernetes environment. Consult your Kubernetes administrator and infrastructure team to determine the appropriate method for your organization.

Service exposure is a cluster management decision and is not covered by this deployment guide. Your infrastructure team should decide how to expose the ADONIS service based on your organizational requirements and infrastructure platform.

Managing Your Deployment

Manage and maintain your ADONIS Kubernetes deployment.

After ADONIS is successfully deployed and running, you can use these commands and procedures to manage, monitor, and maintain your deployment.

Viewing Deployment Status

Check Pod Status

View the status of all ADONIS pods:

kubectl get pods

This displays all running pods. Both the application server (aserver) and webserver pods should show status Running with 1/1 Ready.

For more detailed information, use:

kubectl describe pod <pod-name>

View Logs and Resource Usage

View Application Logs

In case you do not have a dedicated solution for managing and aggregating logs and the log mode is set to logMode: MIXED or logMode: STD, you can use the built-in Kubernetes command to access logs.

kubectl logs <pod-name>

Follow logs in real time (streaming) with the -f flag:

kubectl logs -f <pod-name>

View Previous Logs

If a pod has crashed and been restarted, view logs from the previous instance:

kubectl logs --previous <pod-name>

Resource Usage

View CPU and memory usage of pods:

kubectl top pods

These commands show resource consumption of cluster nodes and individual pods.

Database Backups

Regular backups of your ADONIS database are essential. We strongly recommend automated backups using your backup solution or the database system's native backup tools. Also make sure to define a suitable retention time for database backups.

Backup procedures are database-specific and outside the scope of this deployment guide. Consult your database administrator or database documentation for proper backup strategies.

Getting Help

If you encounter issues that are not covered in this guide:

1. Check the ADONIS logs for detailed error messages

2. Consult your Kubernetes administrator for cluster-specific issues

3. Contact your ADONIS consultant for ADONIS-specific issues

4. Contact the BOC Support Hotline for software issues

Undeploy ADONIS

Undeploy ADONIS.

To undeploy ADONIS, you can use the appropriate Helm command. This will remove ADONIS from the cluster and, depending on the options you provide to this command, delete resources created during deployment.

Delete Deployment

To remove ADONIS from your cluster:

helm uninstall <your-product>

Optional: Delete Deployment from a Specific Namespace

If you deployed ADONIS into a specific Kubernetes namespace instead of the default namespace, specify the namespace when undeploying:

helm uninstall <your-product> --namespace <your-namespace>

This removes ADONIS from the cluster, your database remains unchanged and can be reused for a future ADONIS deployment.

Delete Persistent Storage

Persistent storage is used for Full Text Search (FTS) data and logs. Depending on the configuration, your storage solution and the command options, it may be necessary to remove persistent storage manually.

Clean up images

After undeployment of ADONIS, Kubernetes will typically clean up old images automatically. This depends on your configuration of the cluster.

For more information on how Kubernetes deals with unused data, please refer to the chapter Garbage Collection.

Clean up database

The database is typically not deleted during undeployment of ADONIS. Removing the database is a manual task which depends on the type of database system you have running (PostgreSQL or MS SQL Server) and the database administration tool you are using.