Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

You can install Adeptia Connect microservices using Helm Charts. A Helm Chart is a collection of files and templates that describe Kubernetes resources governing the deployment of microservices.

Follow the steps below in the same order to install Adeptia Connect. 

Ensure that you have met all the prerequisites and system requirements before you begin to install the application.

Creating Service Accounts, ClusterRoles, and ClusterRoleBindings

Before you begin to install the application, you need to create Service Accounts, Roles, and RoleBindings. This section makes you aware of the:

  • Service Accounts required by Adeptia Connect application.
  • ClusterRoles, and ClusterRoleBindings required for the these Service Accounts.
  • Permission required by the user who is deploying the helm chart.
  • Roles and RoleBindings required by this user.
  • External secret crd yaml.
  • External secret ClusterRoleBindings.

Adeptia provides you with a roles zip file along with the Adeptia Connect Helm chart. This zip contains the YAML files required to create Service Accounts, ClusteRoles, ClusterRoleBindings, etc. The following table helps you understand the purpose of each yaml file. 

File Name

Purpose

Description

For Service Accounts required by Adeptia Connect application

serviceaccount-adeptia.yaml

It creates a Service Account with the name “adeptia”.

This Service Account is used by all the Adeptia core services except autoscaler. You need to update the namespace in which you want to deploy the Adeptia Connect helm chart.

clusterrole-adeptia.yaml

It creates a ClusterRole with the name “adeptia-connect”.

As a best practice, if you are deploying multiple instances of the application, append the namespace to the name of the ClusterRole on subsequent deployments. This prevents overwriting of the existing ClusterRole.

This ClusterRole contains the permission required by the above service account.

clusterrolebinding-adeptia.yaml

It creates a ClusterRoleBinding for the service account “adeptia” with the “adeptia-connect” cluster role.

As a best practice, if you are deploying multiple instances of the application, append the namespace to the name of the ClusterRoleBinding on subsequent deployments. This prevents overwriting of the existing ClusterRoleBinding.

In this file, you need to update the namespace in which you will deploy the Adeptia Connect helm.

serviceaccount-autoscaler.yaml

It creates a Service Account with the name “autoscaler-runtime”.

This Service Account will be used by the runtime autoscaler to launch a runtime deployment whenever a queue is created within the Adeptia Connect application. For this Service Account, Role and RoleBinding will get created automatically during helm deployment by autoscaler sub chart. You need to update the namespace in which you want to deploy the Adeptia Connect helm chart.

For the user, who will deploy the helm chart

role-deployment-user.yaml

It creates the Role with name “adeptia-user”

This Role contains the permission required by the user who will deploy the Adeptia Connect helm chart. In this file, you need to update the namespace in which you want to deploy the Adeptia Connect helm chart.

rolebinding-deployment-user.yaml

It creates the RoleBinding with the name “adeptia-user”.

In this file, you need to update the namespace in which you want to deploy the Adeptia Connect helm chart. You also need to update the name of the user, who will deploy the Adeptia Connect helm chart.

Required for External Secret

This is needed only when you will use the external secret to fetch the secrets from the external vault.

serviceaccount-adeptia-es.yaml

It creates a Service Account with the name “adeptia- es”.

This Service Account will be used by external secret. You need to enter namespace in this file.

clusterrole-adeptia-es.yaml

It creates a ClusterRole with the name “adeptia- connect-es”.

This ClusterRole contains the permission required by the above service account used by external secret.

clusterrolebinding-adeptia-es.yaml

It creates a ClusterRoleBinding for the service account “adeptia-es” with the “adeptia-connect-es” ClusterRole.

In this file, you need to update the namespace in which you will deploy the Adeptia Connect helm.

es-crd.yaml

It creates the external secret component CRDs.

This is needed only when you will use the external secret to fetch the secrets from the external vault.

es-clusterrolebinding-deployment-user.yaml

It creates a ClusterRoleBinding to provide “system:auth-delegator” permission to the user who will deploy the Adeptia Connect helm.

In this file you need to update the name of the user, who will deploy the Adeptia Connect helm.

To create Service Accounts, ClusteRoles, ClusterRoleBindings, follow the steps given below.

  1. Download the roles.tgz (roles zip) file from the following link:
    https://adeptia.github.io/adeptia-connect-roles/charts/roles-4.0.tgz
  2. Unzip this file.
  3. Update the yaml files as explained in the table above.

  4. Run the following command to deploy the yaml files. 

    kubectl apply -f adeptia_roles/


    This creates the required Service Accounts, ClusterRoles, ClusterRoleBindings, Roles, and RoleBindings.

    If you want to use external secret, run the following command to create Service Accounts, ClusterRoles, ClusterRoleBindings and external crd for external secret.

    kubectl apply -f es/

Enabling OCI support in the Helm 3 client

Helm 3 supports Open Container Initiative (OCI) for package distribution. Set the HELM_EXPERIMENTAL_OCI in the environment to enable OCI support in the Helm 3 client by running the following command on the Helm CLI.

export HELM_EXPERIMENTAL_OCI=1

Installing Adeptia Connect

Follow the steps below to install Adeptia Connect.

  1. Go to https://artifacthub.io/packages/helm/adeptia-connect/adeptia-connect to view the details of Adeptia Connect helm package.

  2. Add Adeptia Connect repo using following command:

    helm repo add adeptia-connect https://adeptia.github.io/adeptia-connect-helm-package/charts/
  3. Click DEFAULT VALUES to download the values.yaml file.
  4. Update the values.yaml as per instruction given in this section.

  5. Run the the following command to deploy the application.

    helm install adeptia-connect adeptia-connect/adeptia-connect -f <PATH_OF_VALUES.YAML> --timeout 10m

    This command deploys Adeptia Connect on the Kubernetes cluster.

    Once you've completed the deployment, you need to configure your domain specific SSL certificate by using either of the two options:

    • Use Ingress in front of the Gateway service and configure SSL on Ingress.
    • Configure SSL directly on the Gateway service.

    To know more about configuring SSL, click here.

Properties in values.yaml

Update the following properties in values.yaml before you run the helm install command to install the application.

Defining the required database properties

PropertyValueDescription
BACKEND_DB_USERNAME<User defined>

Username for your backend database.

If you're using external Secrets, you need not provide a value for this property.

BACKEND_DB_PASSWORD<User defined>

Password for your backend database.

If you're using external Secrets, you need not provide a value for this property.

LOG_DB_USERNAME<User defined>

Username for your log database.

If you're using external Secrets, you need not provide a value for this property.

LOG_DB_PASSWORD<User defined>

Password for your log database.

If you're using external Secrets, you need not provide a value for this property.

LOG_ARCHIVE_DB_PASSWORD<User defined>

Password for your log archive database.

If you're using external Secrets, you need not provide a value for this property.

LOG_ARCHIVE_DB_USERNAME<User defined>

Username for your log archive database.

If you're using external Secrets, you need not provide a value for this property.

QUARTZ_DB_USERNAME<User defined>

Username for your quartz database. This value will be the same as that for the backend database.

If you're using external Secrets, you need not provide a value for this property.

QUARTZ_DB_PASSWORD<User defined>

Password for your quartz database. This value will be the same as that for the backend database.

If you're using external Secrets, you need not provide a value for this property.

BACKEND_DB_URL
  • jdbc:sqlserver://<DB Hostname>:<Port Number>;database=<Backend Database Name>
  • jdbc:oracle:thin:@<hostName>:<portNumber>:<S ID/ServiceName>
Backend database name and its URL. Currently, only the MS Azure SQL database is certified.

BACKEND_DB_DRIVER_CLASS

  • com.microsoft.sqlserver.jdbc.SQLServerDriver
  • oracle.jdbc.OracleDriver
Driver class name based on the backend db. Do not change the value for this pre-defined property.
BACKEND_DB_TYPE

SQL-Server, Oracle

Currently, only the MS Azure SQL database is certified. Do not change the value for this pre-defined property.
BACKEND_DB_DIALECT
  • org.hibernate.dialect.SQLServer2008Dialect
  • org.hibernate.dialect.Oracle12cDialect
Currently, only the MS Azure SQL database is certified. Do not change the value for this pre-defined property.
LOG_DB_DRIVER_CLASS
  • com.microsoft.sqlserver.jdbc.SQLServerDriver
  • oracle.jdbc.OracleDriver
Driver class name based on the log db. Do not change the value for this pre-defined property.
LOG_DB_URL
  • jdbc:sqlserver://<DB Hostname>:<Port Number>;database=<Log Database Name>
  • jdbc:oracle:thin:@<hostName>:<portNumber>:<S ID/ServiceName>
Log database name and its URL. Currently, only the MS Azure SQL database is certified.
LOG_DB_TYPE

SQL-Server, Oracle

Currently, only the MS Azure SQL database is certified. Do not change the value for this pre-defined property.
LOG_DB_DIALECT
  • org.hibernate.dialect.SQLServer2008Dialect
  • org.hibernate.dialect.Oracle12cDialect
Currently, only the MS Azure SQL database is certified. Do not change the value for this pre-defined property.
LOG_ARCHIVE_DB_URL
  • jdbc:sqlserver://<DB Hostname>:<Port Number>;database=<Log Archive Database Name>
  • jdbc:oracle:thin:@<hostName>:<portNumber>:<S ID/ServiceName>
Log archive database name and its URL. Currently, only the MS Azure SQL database is certified.

LOG_ARCHIVE_DB_DRIVER_CLASS

  • com.microsoft.sqlserver.jdbc.SQLServerDriver
  • oracle.jdbc.OracleDriver
Driver class name based on the log archive db. Do not change the value for this pre-defined property.
LOG_ARCHIVE_DB_TYPE

SQL-Server, Oracle

Currently, only the MS Azure SQL database is certified. Do not change the value for this pre-defined property.
LOG_ARCHIVE_DB_DIALECT
  • org.hibernate.dialect.SQLServer2008Dialect
  • org.hibernate.dialect.Oracle12cDialect
Currently, only the MS Azure SQL database is certified. Do not change the value for this pre-defined property.

QUARTZ_DB_URL

  • jdbc:sqlserver://<DB Hostname>:<Port Number>;database=<Backend Database Name>
  • jdbc:oracle:thin:@<hostName>:<portNumber>:<S ID/ServiceName>
Quartz database name and its URL. Currently, only the MS Azure SQL database is certified. This value will be the same as that for the backend database.
QUARTZ_DB_DRIVER_CLASS
  • com.microsoft.sqlserver.jdbc.SQLServerDriver
  • oracle.jdbc.OracleDriver
Driver class name based on the quartz db. This value will be the same as that for the backend database.
QUARTZ_DB_TYPE

SQL-Server, Oracle

Currently, only the MS Azure SQL database is certified. Do not change the value for this pre-defined property.
QUARTZ_DB_DIALECT
  • org.hibernate.dialect.SQLServer2008Dialect
  • org.hibernate.dialect.Oracle12cDialect
Currently, only the MS Azure SQL database is certified. Do not change the value for this pre-defined property. This value will be the same as that for the backend database.

Defining required Secrets properties

You need to set these properties only when you're using external Secrets. If you're not using external Secrets, skip to the next step.

The following table contains the properties to be set if you're using an external tool such as 'Vault' for managing Secrets. Refer to this page to know more about configuring Secrets. 

PropertyValueDescription
config.image.pullSecret.enabledtrue (Default)

If set to false, external Secrets will be used.

infra.secret.enabledfalse (Default)You'd need to set this value to true to work with external Secrets.
infra.secret.vaultMountPoint
Authentication method that you have created in the external tool.
infra.secret.vaultRole
Role that you've created in the tool.
infra.secret.dbDataFrom
Path of the database Secret created in the tool.
infra.secret.imageDataFrom
Path of the image Secret created in the tool.
infra.secret.env.VAULT_ADDR
URL of the external tool such as Vault.

Removing the resources if installation fails

If the installation fails for any reason, you need to take the following steps before you reinstall the application.

  1. Check if there is an entry of the release (Name given to the release while installing) in the namespace. Use the following command to check the entry:

    helm list -n <Namespace>

  2. Remove the entry of the release. Use the following command to remove the release.

    helm delete <Name of the release> -n <Namespace>
  3. Remove the resources that were deployed during the failed installation. 
    Ensure that you have removed the following resources before you begin to install the application once again.
    1. Jobs (For example, Migration)
    2. Deployment of the microservices
    3. Secrets
    4. PVC

Uninstalling Adeptia Connect

If you wish to uninstall the application, run the following command.


helm uninstall <adeptia-connect>

Where,

adeptia-connect is name of the deployment.

When you uninstall the application, there are some resources that you need to remove from the system manually. The resources on the following list are subject to be deleted manually, and their removal ensures a successful installation of the application in the future.

  • Service Account 
  • Secrets
  • PVC

If you've configured external Secrets, you need to manually delete the Secrets and its deployment after you uninstall the application.
  • No labels