Prerequisites
NOTE Before going through the below mentioned prerequisites for this section, ensure that all the Prerequisites for Installing Infoworks on AKS are validated.
Ensure the current deployment’s chart is present in /opt/infoworks.
Python 3.8 or later version with the pip module is installed in the Bastion VM.
Stable internet connectivity on the Bastion VM to download the required python packages from the python repository during installation/upgrades.
Validate that the version of the old chart is 5.3.1.
Ensure to take backup of MongoDB Atlas and PostgresDB PaaS. In case you don't take the backup, jobs will fail after the rollback operation. For more information, refer to the MongoDB Backup and PostgresDB PaaS Backup.
Upgrading Infoworks on Kubernetes
To upgrade Infoworks on Kubernetes:
It is assumed that the existing chart is placed in the /opt/infoworks directory and the user has the access permission.
Before selecting the type of upgrade execute the following commands.
Step 1: Create the required directories and change the path to that directory.
Internet-free Upgrade
NOTE If you are upgrading via Internet-based procedure, skip to the next section.
Step 1: Download the upgrade tar files shared by the Infoworks team to the Bastion (Jump host) VM and place it under $IW_HOME/downloads.
Step 2: To configure Internet-free upgrade, execute the following command:
Internet-based Upgrade
Step 1: Download the Update script tar file.
Common Steps for Both Internet-free and Internet-based
NOTE Once you have selected the type of upgrade, the below mentioned steps are common for both Internet-free and Internet-based.
Step 1: Extract the iwx_updater _k8s_5.4.0. tar.gz under $IW_HOME/downloads.
Do not extract the tar file to /opt/infoworks/iw-k8s-installer as it would result in loss of data.
This should create two new files as follows - update-k8s.sh and configure.sh.
Step 2: Edit the following variables which need to be overridden in the newly created configure.sh.
Alternatively, you can enter them in the respective prompts while running the script.
NOTE Exporting these variables manually may not work as expected
Field | Description | Details |
|---|---|---|
USE_GCP_REGISTRY | This field enables separate registry for cloud. GCR is being used by Infoworks by default. To override cloud specific registry images, provide input "false". | Select true or false. Default value: true. |
Autoscaling Configuration
Field | Description | Details |
|---|---|---|
KEDA_ENABLED | This field enables to configure autoscaling to Infoworks deployment using KEDA. | Select true or false. Default value: false. NOTE If the field is set to false, Infoworks is reset to Horizontal Pod Autoscaling (HPA) mode. |
KEDA_AUTO_PROVISIONER | This field enables installing KEDA Kubernetes deployment automatically by Infoworks deployment | Select true or false. Default value: false. NOTE Infoworks recommends setting up KEDA externally with the required configuration. To set up KEDA externally, refer to External KEDA Setup. |
Keyvault Configuration
NOTE If the Service Principal or Identities (Managed or User) are provided, then they should have permissions over the given Keyvault. For more details, refer to Assigning Keyvault Access in Azure Portal. If the permissions are not assigned, the upgrade might fail.
Field | Description | Details |
|---|---|---|
KEYVAULT_GLOBAL_ENABLED | The flag indicates whether all secrets like Databricks Tokens will always be stored on an External Keyvault | Enter true if Infoworks forces all secret keys to be stored on an External Keyvault. Enter false if the user will be given the option to store them in encrypted form in the MetaDB. |
KEYVAULT_ENABLED | This flag indicates whether a default Keyvault to store external MongoDB and PostgresDB Credentials will be given | Only Applicable if either or both of the Databases are external Enter true if a default keyvault to store external DB credentials will be used Enter false if all DB credentials will be stored natively,i.e. as part of Kubernetes Secrets and Pod Environment Variables |
AZURE_KEYVAULT_URI | The URI of the Azure Keyvault containing any External DB Credentials | Only Applicable if KEYVAULT_ENABLED= "true" The URI of the Azure Keyvault which will store the DB credentials, generally following the format - https://keyvault-name.vault.azure.net/ |
FLAG_AZURE_KEYVAULT_AUTH_SP | This flag indicates whether the aforementioned Keyvault is to be accessed through a service principal | Only Applicable if KEYVAULT_ENABLED="true" Enter true if Infoworks uses a Service Principal to authenticated to the Keyvault, and proceed to provide SP details Enter false if the Nodes have been granted User or System Managed Identity to Authenticate. |
AZURE_SERVICE_PRINCIPAL_TENANT_ID | The ID of the Service Principal Tenant | Only Applicable if FLAG_AZURE_KEYVAULT_AUTH_SP="true" Enter the Azure Object ID/Tenant ID of the Service Principal |
AZURE_SERVICE_PRINCIPAL_SUBSCRIPTION_ID | The ID of the Subscription the Service Principal Exists In | Only Applicable if FLAG_AZURE_KEYVAULT_AUTH_SP= "true" Enter the Azure Object ID of the Service Principal |
AZURE_SERVICE_PRINCIPAL_CLIENT_ID | The Client ID of the Service Principal | Only Applicable if FLAG_AZURE_KEYVAULT_AUTH_SP= "true" Enter the Azure Client ID of the Service Principal |
AZURE_SERVICE_PRINCIPAL_CLIENT_SECRET | The Encrypted Client Secret of the Service Principal | Only Applicable if FLAG_AZURE_KEYVAULT_AUTH_SP= "true" Keep it empty if not sure. During Installation Client Secret prompt will be displayed and then Infoworks encrypts the password on the fly. |
AZURE_MI_TYPE_IS_USER | Flag whether the Managed Identity use to authenticate to keyvault is System Assigned or User-Managed | Only Applicable if FLAG_AZURE_KEYVAULT_AUTH_SP= "false" Enter true if Managed Identity used is User Assigned, and proceed to enter ID in next input Enter false if the Nodes have been granted System Managed Identity to Authenticate (default is false) |
AZURE_USER_MI_CLIENT_ID | The Client ID of the User-assigned Managed Identity attached to the nodes | Only Applicable if AZURE_MI_TYPE_IS_USER= "true" |
Keyvault Configuration for MongoDB
The following fields are applicable if EXTERNAL_MONGO= true and KEYVAULT_ENABLED=true.
NOTE If KEYVAULT_GLOBAL_ENABLED= true, the following will default to true. If KEYVAULT_GLOBAL_ENABLED=false, configure the following fields.
Field | Description | Details |
|---|---|---|
KEYVAULT_FLAG_METADB_HOST | This flag indicates whether to use the default Keyvault to store external Mongo Host | This field appears only if KEYVAULT_GLOBAL_ENABLED="false", else MONGODB_HOSTNAME will always be stored as a Keyvault Secret. |
KEYVAULT_FLAG_METADB_USER | This flag indicates whether to use the default Keyvault to store external Mongo User | This field appears only if KEYVAULT_GLOBAL_ENABLED="false", else MONGODB_USERNAME will always be stored as a Keyvault Secret. |
MongoDB Configuration
The following fields are applicable if EXTERNAL_MONGO= true and KEYVAULT_ENABLED=true.
NOTE If KEYVAULT_ENABLED=false, the following fields are not used.
NOTE To add secrets to your keyvault, refer to Adding a Secret to Keyvault.
Field | Description | Details |
|---|---|---|
MONGODB_HOSTNAME | The keyvault Secret Name that will store the Mongo Host URL to connect to | Only Applicable if MONGODB_HOSTNAME is a keyvault secret, else it will default to the older hostname Default: METADBHOST |
MONGODB_USERNAME | The keyvault Secret Name that will store the Mongo User to authenticate as. | Only Applicable if MONGODB_USERNAME is a keyvault secret, else it will default to the older user Default: METADBUSER |
MONGODB_ENCRYPTED_PASSWORD | The keyvault Secret Name that will store the Password of the aforementioned MONGODB_USERNAME | Only Applicable if MONGODB_ENCRYPTED_PASSWORD is a keyvault secret, else it will default to the older password Default “METADBPASS” |
Keyvault Configuration for PostgresDB
The following fields are applicable if EXTERNAL_POSTGRESDB=true and KEYVAULT_ENABLED=true.
NOTE If KEYVAULT_GLOBAL_ENABLED= true, the following will default to true. If KEYVAULT_GLOBAL_ENABLED=false, configure the following fields.
Field | Description | Details |
|---|---|---|
KEYVAULT_FLAG_POSTGRESDB_HOST | This flag indicates whether to use the default Keyvault to store external PostgresDB Host | This field appears only if KEYVAULT_GLOBAL_ENABLED="false", else POSTGRESDB_HOSTNAME will always be stored as a Keyvault Secret. |
KEYVAULT_FLAG_POSTGRESDB_USER | This flag indicates whether to use the default Keyvault to store external PostgresDB User | This field appears only if KEYVAULT_GLOBAL_ENABLED="false", else POSTGRESDB_HOSTNAME will always be stored as a Keyvault Secret. |
PostgresDB Configuration
The following fields are applicable if EXTERNAL_POSTGRESDB= true and KEYVAULT_ENABLED=true.
NOTE If KEYVAULT_ENABLED=true, the following fields are used.
NOTE To add secrets to your keyvault, refer to Adding a Secret to Keyvault.
Field | Description | Details |
|---|---|---|
POSTGRESDB_HOSTNAME | The keyvault Secret Name that will store the PostgresDB Host URL to connect to | Only Applicable if POSTGRESDB_HOSTNAME is a keyvault secret, else it will default to the older hostname Default: POSTGRESDBHOST |
POSTGRESDB_USERNAME | The keyvault Secret Name that will store the PostgresDB User to authenticate as. | Only Applicable if POSTGRESDB_USERNAME is a keyvault secret, else it will default to the older user Default: POSTGRESDBUSER |
POSTGRESDB_ENCRYPTED_PASSWORD | The keyvault Secret Name that will store the Password of the aforementioned POSTGRESDB_USERNAME | Only Applicable if POSTGRESDB_ENCRYPTED_PASSWORD is a keyvault secret, else it will default to the older password. Default: POSTGRESDBPASS |
Step 3: Run the script.
NOTE At the end of the above command's execution, if you want to run helm upgrade manually, then type N and press Enter. There is a 30-second timeout set to abandon the deployment of the upgraded version. If no input is received within the timeout duration, the deployment is triggered.
Step 4 (Applicable only for Databricks Persistent Clusters): A change in the Infoworks jar requires libraries being uninstalled and cluster restart. Without this step, there will be stale jars. Perform the following steps:
(i) Go to the Databricks workspace, navigate to the Compute page, and select the cluster that has stale jars.
(ii) In the Libraries tab, select all the Infoworks jars and click Uninstall.
(iii) From Infoworks UI or Databricks dashboard, select Restart Cluster.
NOTE If Infoworks upgrade fails, refer to Infoworks Setup Failure in Kubernetes Cluster due to NGINX.
NOTE For scalability related configuration, refer to Enabling Scalability.
Updating the MongoDB and PostgresDB Credentials
NOTE The following steps are deprecated if the KEYVAULT_ENABLED=true.
To update the MongoDB and/or PostgresDB credentials in the Infoworks deployment, follow the below given procedure.
Updating the MongoDB Credentials
Updating Encrypted Passwords Stored in values.yaml
There are two methods to update password:
Method 1
To update MongoDB encrypted passwords that are stored in values.yaml file, with the existing configure.sh file, use the IW_DEPLOY script to populate values.yaml:
Step 1: Download and untar the Infoworks kubernetes template, if not already present, according to the iwx-version in your existing deployment.
Step 2: If a new template was downloaded, replace the iw-k8s-installer/configure.sh as well as iw-k8s-installer/infoworks/values.yaml with the older file.
Step 3: Change the directory path to iw-k8s-installer.
Step 4: Replace the following values with a blank string in the configure.sh file.
Step 5: Run iw_deploy.sh. Once you receive "Seems like you have already configured Infoworks once. Do you want to override? y/n Default: n", enter “Y”. This will prompt the user to provide input for the values that were blank in the previous step. The script will then replace the infoworks/values.yaml file with the updated values.
Step 6: Run the following command to upgrade by specifying your namespace and helm release name according to the values given in the configure.sh file.
Method 2
To update MongoDB encrypted passwords, you can directly modify the values.yaml file.
Step 1: Download and untar the Infoworks Kubernetes Template, if not already present, according to the iwx-version in your existing deployment.
Step 2: If a new template was downloaded, replace the iw-k8s-installer/infoworks/values.yaml with the older file.
Step 3: Change the directory path to iw-k8s-installer directory.
Step 4: Generate the encrypted passwords as needed. To generate any encrypted string, execute the following command.
This generates your passwords in a secure encrypted format, which has to be provided in the following steps.
Step 5: Replace the following yaml keys with the new values in the infoworks/values.yaml file, if needed.
Step 6: Run the following command to upgrade by specifying your namespace and helm release name according to the installed kubernetes deployment specifications.
Updating Encrypted Passwords Stored as a Separate Secret
To update the MongoDB password:
Step 1: Run the following commands from the iw-k8s-installer directory.
Step 2: Restart all pods except the databases.
Updating the PostgresDB Credentials
Updating Encrypted Passwords Stored in values.yaml
There are two methods to update password:
Method 1
To update PostgresDB passwords that are stored in values.yaml file, with the existing configure.sh file, use the IW_DEPLOY script to populate values.yaml.
Step 1: Download and untar the Infoworks Kubernetes Template, if not already present, according to the iwx-version in your existing deployment.
Step 2: If a new template was downloaded, replace the iw-k8s-installer/configure.sh as well as iw-k8s-installer/infoworks/values.yaml with the older file.
Step 3: Change the directory path to iw-k8s-installer.
Step 4: Replace the following values with a blank string in the configure.sh file.
Step 5: Run iw_deploy.sh. Once you receive "Seems like you have already configured Infoworks once. Do you want to override? y/n Default: n", enter “Y”. This will prompt the user to provide input for the values that were blank in the previous step. The script will then replace the infoworks/values.yaml file with the updated values.
Step 6: Run the following command to upgrade by specifying your namespace and helm release name according to the values given in the configure.sh file.
Method 2
To update PostgresDB encrypted passwords, you can directly modify the values.yaml file.
Step 1: Download and untar the Infoworks Kubernetes Template, if not already present, according to the iwx-version in your existing deployment.
Step 2: If a new template was downloaded, replace the iw-k8s-installer/infoworks/values.yaml with the older file.
Step 3: Change the directory path to iw-k8s-installer.
Step 4: Generate the encrypted passwords as needed. To generate any encrypted string, execute the following command.
This generates your passwords in a secure encrypted format, which has to be provided in the following steps.
Step 5: Replace the following yaml keys with the new values in the infoworks/values.yaml file, if needed.
Step 6: Run the following command to upgrade by specifying your namespace and helm release name according to the installed kubernetes deployment specifications.
Updating Encrypted Passwords Stored as a Separate Secret
To update the PostgresDB password:
Step 1: Run the following commands from the iw-k8s-installer directory.
Step 2: Restart the orchestrator and orchestrator-scheduler pods.