Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
When it comes time to upgrade your various components, you can do so by updating the version number in your configuration files and applying the changes in ArgoCD.
Navigate to your cinchy devops.automation repository
Navigate to your deployment.json (You may have renamed this during your original Kubernetes deployment)
In the cinchy_instance_configs section, navigate to the image tags. Replace the version number with the instance that you wish to deploy (Ex: v5.0.0 > 5.1.0).
2. Rerun the deployment script by using the following command in the root directory of your devops.automations repo:
3. Commit and push your changes.
If your environment is not set-up to automatically apply upon configuration, complete the following the apply the newest version:
Navigate to the ArgoCD portal.
Refresh your component(s). If that does not work, re-sync.
The pages under this section deal with upgrading your Cinchy platform.
If you are currently running Cinchy v4+ or v5+ and wish to upgrade your components, please review the documentation here:
If you are currently running Cinchy v4+ and wish to upgrade to v5+, please review the documentation here:
When it comes time to upgrade your various components, you can do so by updating the version number in your configuration files and applying the changes in ArgoCD.
Warning: If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.2, please review and follow the directives for Upgrade 5.2.
Navigate to your cinchy devops.automation repository
Navigate to your deployment.json (You may have renamed this during your original Kubernetes deployment)
In the cinchy_instance_configs section, navigate to the image tags. Replace the version number with the instance that you wish to deploy (Ex: v5.1.0 > 5.2.0).
2. Rerun the deployment script by using the following command in the root directory of your devops.automations repo:
3. Commit and push your changes.
If your environment is not set-up to automatically apply upon configuration, complete the following the apply the newest version:
Navigate to the ArgoCD portal.
Refresh your component(s). If that does not work, re-sync.
This page details information on the Cinchy Upgrade Utility.
The Cinchy Upgrade Utility was first introduced in v5.2 in order to facilitate a mandatory INT to BigInt upgrade. This tool has continued to be used in subsequent releases as an easy way to deploy necessary changes to your Cinchy platform.
Upgrades will also be specified on the applicable Upgrade Guide page for each release.
Depending on your upgrade path, certain upgrades must be performed in sequential and/or specific order. This will be clearly marked in the "Overview and Considerations" section.
For example: To go from v5.1 to v5.5, you would first have to run the 5.2 upgrade utility and deploy the release. Once validated, you would then run the 5.5 upgrade and deploy that version.
Not all new releases will have changes that require the utility to be run. Review the table in section 4 for the full list.
You will need to run this process as a user with admin/dbowner privileges to your database.
You will need to have .NET Core 6.0.x installed on the machine that you will run the utility on.
Retrieve the Upgrade Utility from the Cinchy Releases table.
Release | Upgrade | Kubernetes Upgrade | IIS Upgrade |
---|---|---|---|
We recommend you follow this process during off-peak hours.
Turn off your Cinchy platform. (Note: This step is only required for the 5.2 upgrade)
In a Kubernetes deployment, you can do so via ArgoCD.
In an IIS Deployment:
Open your Windows Services Panel.
Select IIS Admin Service.
Stop the service.
Right-click IIS Admin Service and select Properties.
Change 'Start Up Type' to 'Disabled'.
Create a backup snapshot of your platform.
In a Kubernetes deployment on AWS, you can follow the documentation here.
In a Kubernetes deployment on Azure, you can follow the documentation here.
In an IIS Deployment, you can follow the documentation here.
Retrieve the Upgrade Utility from the Cinchy Releases table if you haven't already.
Run the following command through a command window as an admin/dbowner, using the table below as a guide.
5. You will see the below progress bar as your upgrade completes (Image 1). Once it is done, you will see a VALIDATION PASSED check.
Tip: Click on the image below to enlarge it.
If there are any errors during execution or your validation fails, we suggest that you restore your database from the backup and contact Cinchy support.
6. Deploy your Cinchy Upgrade.
Note: You must deploy whichever version of the platform you ran the upgrade utility for.
7. If it was turned off in step 1, turn your Cinchy platform back on.
1. In a Kubernetes deployment, you can do so via Argo CD
2. In an IIS deployment:
1. Open your Windows Services Panel.
2. Select IIS Admin Service.
3. Start the service.
4. Right-click IIS Admin Service and select Properties.
5. Change 'Start Up Type' to 'Enabled'.
Value | Description |
---|---|
5.2
5.5
-d
Mandatory. "Database type". This can be either "TSQL" or "PGSQL".
-s
Mandatory. "Connection String". You must provide the unencrypted connection string for your database.
-v
Mandatory. This specifies the upgrade version that you wish to deploy. Ex: specifying "5.2" will run the 5.2 upgrade.
-c
Optional and not recommended to be used on your first run of the utility. This "clean up" value will delete any extra metadata the application created on the database
When it comes time to upgrade your various components, you can do so by updating the version number in your configuration files and applying the changes in ArgoCD.
Warning: If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.3, you must first run a mandatory process (Upgrade 5.2) using the Cinchy Utility and deploy version 5.2. Once complete, you can continue on with your 5.3 upgrade.
Navigate to your cinchy devops.automation repository
Navigate to your deployment.json (You may have renamed this during your original Kubernetes deployment)
In the cinchy_instance_configs section, navigate to the image tags. Replace the version number with the instance that you wish to deploy (Ex: v5.2.0 > 5.3.0).
2. Rerun the deployment script by using the following command in the root directory of your devops.automations repo:
3. Commit and push your changes.
If your environment is not set-up to automatically apply upon configuration, complete the following the apply the newest version:
Navigate to the ArgoCD portal.
Refresh your component(s). If that does not work, re-sync.
The Kubernetes project runs a community-owned image registry called registry.k8s.io in which to host its container images. On April 3rd, 2023, the registry k8s.gcr.io was deprecated and no further images for Kubernetes and related subprojects are being pushed to this location.
Instead, there is a new registry: registry.k8s.io.
New Cinchy Deployments: this change will be automatically reflected in your installation.
For Current Cinchy Deployments: please follow the instructions outlined in this upgrade guide to ensure your components are pointed to the correct image repo.
You can review the full details on this change here: https://kubernetes.io/blog/2023/02/06/k8s-gcr-io-freeze-announcement/
In a shell/terminal, run the below command to get a list of all the pods that are pointing to the old registry: k8s.gcr.io. These will need to be updated to point to the new image registry.
Once you find which pods are using old image registry, you need to update its deployment/daemonset/stateful set with new registry.k8s.io registry. Find the right resource type for your pods with below command:
Once you have your pod name and resource type, run the below command to open the manifest file in an editor:
The below command uses the autoscaler as an example. You will want to propagate the command with your correct pod and resource type.
In the editor, find any instances of k8s.gcr.io and replace it with registry.k8s.io.
Save and close the file.
Repeat steps 3-5 for the rest of your pods until they are all pointing to the correct registry.
When it comes time to upgrade your various components, you can do so by following the below instructions.
Warning: Upgrading to v5.4 will require you to take your Cinchy platform offline. We recommend you perform this upgrade during off-peak hours
Warning: If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.4, you must first run a mandatory process (Upgrade 5.2) using the Cinchy Utility and deploy version 5.2. Once complete, you can continue on with your 5.4 upgrade.
If you are upgrading to 5.4+ on an SQL Server Database, you will need to make a change to your connectionString. Adding TrustServerCertificate=True will allow you to bypass the certificate chain during validation.
For a Kubernetes deployment, you can add this value in your deployment.json file:
Download the latest Cinchy Artifacts from the Cinchy Releases Table > Kubernetes Artifacts column (Image 1). For this upgrade, please download the Cinchy v5.4 k8s-template.zip file.
Turn off your Cinchy platform. In a Kubernetes deployment, you can do so via ArgoCD.
Navigate to your cinchy.argocd repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.
Navigate to your cinchy.kubernetes repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.
If you have cinchy.kubernetes\cluster_components\servicemesh\istio\istio-injection\argocd-ns.yaml file and it is not commented then please keep it as it is. Changing this will delete your Argocd namespace, which will force you to delete everything from Kubernetes and redeploy.
Navigate to your cinchy.terraform repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.
Navigate to your cinchy.devops.automation repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.
Open the new Cinchy v5.4 k8s-template.zip file you downloaded from the Cinchy Releases table.
Navigate to the new aws.json/azure.json files and compare them with your current deployment.json file. Any additional fields in the new aws.json/azure.json files should be added to your current deployment.json.
Note that you may have changed the name of the deployment.json file during your original platform deployment. If so, ensure that you swap up the name wherever it appears in this document.
Starting in Cinchy v5.4, you will have the option between Alpine or Debian based image tags for the listener, worker, and connections. Using Debian tags will allow a Kubernetes deployment to be able to connect to a DB2 data source, and that option should be selected if you plan on leveraging a DB2 data sync.
When either installing or upgrading your platform, you can use the following Docker image tags for the listener, worker, and connections:
"5.x.x" - Alpine
"5.x.x-debian" - Debian
3. Perform this step only If you are upgrading to 5.4+ on an SQL Server Database. Navigate to your cinchy_instance_configs section > database_connection_string, and add in the following value to the end of your string: TrustServerCertificate=True
Open a shell/terminal from the cinchy.devops.automations directory and execute the following command:
Commit all of your changes (if there were any) in each repository.
If there were any changes in your cinchy.argocd repository you may need to redeploy ArgoCD.
Launch a shell/terminal with the working directory set to the root of the cinchy.argocd repository.
Execute the following command to deploy ArgoCD:
If there were any change to the cluster components, execute the following command from the cinchy.argocd repository:
If there were any change to the Cinchy instance, execute the following command from the cinchy.argocd repository:
Log in to your ArgoCD application console and refresh the apps to ensure that all changes were picked up.
Turn your platform back on. In a Kubernetes deployment, you can do so via Argo CD
When the new version is started for the first time, one node is made responsible for the migration of the entire database. This process can take upwards of 30 minute to complete and your system will be unavailable during this time.
This page details the instructions for upgrading your Cinchy platform to v5.5 on Kubernetes
When it comes time to upgrade your various components, you can do so by following the below instructions.
Warning: There is a mandatory upgrade for this release that requires you to run the Cinchy Upgrade Utility.
Additionally, If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.5, you must first run a mandatory process (Upgrade 5.2) and deploy version 5.2. Once complete, you can continue on with your 5.5 upgrade.
If you are upgrading from Cinchy v5.3 or lower to Cinchy v5.5 on an SQL Server Database, you will need to make a change to your connectionString. Adding will allow you to bypass the certificate chain during validation.
For a Kubernetes deployment, you can add this value in your deployment.json file:
Download the latest Cinchy Artifacts from the Cinchy Releases Table > Kubernetes Artifacts column (Image 1). For this upgrade, please download the Cinchy v5.5 k8s-template.zip file.
Navigate to your cinchy.argocd repository. Delete all existing folder structure except for the .git folder/directory and any custom changes you may have implemented.
Navigate to your cinchy.kubernetes repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.
If you have cinchy.kubernetes\cluster_components\servicemesh\istio\istio-injection\argocd-ns.yaml file and it is not commented then please keep it as it is. Changing this will delete your Argocd namespace, which will force you to delete everything from Kubernetes and redeploy.
Navigate to your cinchy.terraform repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.
Navigate to your cinchy.devops.automation repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented and your deployment.json.
Open the new Cinchy v5.4 k8s-template.zip file you downloaded from the Cinchy Releases table and check the files into their respective cinchy.kubernete, cinchy.argocd, cinchy.terraform and cinchy.devops.automation repositories.
Navigate to the new aws.json/azure.json files and compare them with your current deployment.json file. Any additional fields in the new aws.json/azure.json files should be added to your current deployment.json.
Note that you may have changed the name of the deployment.json file during your original platform deployment. If so, ensure that you swap up the name wherever it appears in this document.
Starting in Cinchy v5.4, you will have the option between Alpine or Debian based image tags for the listener, worker, and connections. Using Debian tags will allow a Kubernetes deployment to be able to connect to a DB2 data source, and that option should be selected if you plan on leveraging a DB2 data sync.
When either installing or upgrading your platform, you can use the following Docker image tags for the listener, worker, and connections:
"5.x.x" - Alpine
"5.x.x-debian" - Debian
Open a shell/terminal from the cinchy.devops.automations directory and execute the following command:
Commit all of your changes (if there were any) in each repository.
If there were any changes in your cinchy.argocd repository you may need to redeploy ArgoCD.
Launch a shell/terminal with the working directory set to the root of the cinchy.argocd repository.
Execute the following command to deploy ArgoCD:
If there were any change to the cluster components, execute the following command from the cinchy.argocd repository:
If there were any change to the Cinchy instance, execute the following command from the cinchy.argocd repository:
Log in to your ArgoCD application console and refresh the apps to ensure that all changes were picked up.
This page will guide you through how to update your AWS EKS Kubernetes version for your Cinchy v5 platform.
This page will guide you through how to update your AWS EKS Kubernetes version for your Cinchy v5 platform.
Update your Cinchy platform to the
Confirm the latest Cinchy supported version of EKS. You can find the version number in the cinchy.devops.automations\aws-deployment.json as "cluster_version": "1.xx".
You must upgrade your EKS sequentially. For example, if you are on EKS cluster version 1.22 and wish to upgrade to 1.24, you must upgrade from 1.22 > 1.23 > 1.24.
Navigate to your cinchy.devops.automations\aws-deployment.json file.
Change the cluster_version key value to the EKS version you wish to upgrade to. (Example: "1.24")
Open a shell/terminal and navigate to the cinchy.devops.automations directory location.
Execute the following command:
Commit changes for all the repositories (cinchy.argocd, cinchy.kubernetes, cinchy.terraform and cinchy.devops.automation).
Open a new shell/terminal and navigate to the cinchy.terraform\aws\eks_cluster\CLUSTER_NAME directory location.
Execute the following command:
Verify the changes are as expected and then accept.
This process will first upgrade the managed master node version and then the worker nodes. During the upgrade process, existing pods get migrated to new worker nodes and all pods will get migrated to new upgraded worker nodes automatically.
The below two commands can be used to verify that all pods are being migrated to new worker nodes.
To show both old and new nodes:
To show all the pods on the new worker nodes and the old worker nodes.
For EKS version 1.24, the metrics server goes into a crashed loop status. Reinstalling the metrics server will fix this, should you encounter this during your upgrade.
In a code editor, open the cinchy.terraform\aws\eks_cluster\CLUSTER_NAME\new-vpc.tf or existing-VPC.tf file.
Find the enable_metrics_server key and mark its value to false.
Open a new shell/terminal and navigate to the cinchy.terraform\aws\eks_cluster\CLUSTER_NAME file.
Run the below command to remove metrics server.
Revert the enable_metrics_server key value from step 1 to true.
Run the below command within the same shell/terminal as step 3 to deploy metrics server with
When it comes time to upgrade your various components, you can do so by following the below instructions.
Warning: If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.6, you must first run a mandatory process (Upgrade 5.2) and deploy version 5.2.
If you are upgrading from Cinchy v5.3 or lower to Cinchy v5.6 on an SQL Server Database, you will need to make a change to your connectionString. Adding will allow you to bypass the certificate chain during validation.
For a Kubernetes deployment, you can add this value in your deployment.json file:
Warning: If you are upgrading from Cinchy v5.4 or lower to Cinchy v5.6, you must first run a mandatory process (Upgrade 5.5) and deploy version 5.5.
The Kubernetes project runs a community-owned image registry called registry.k8s.io in which to host its container images. On April 3rd, 2023, the registry k8s.gcr.io was deprecated and no further images for Kubernetes and related subprojects are being pushed to this location.
Instead, there is a new registry: registry.k8s.io.
For Current Cinchy Deployments: please follow the instructions outlined in to ensure your components are pointed to the correct image repo.
Download the latest Cinchy Artifacts from the Cinchy Releases Table > Kubernetes Artifacts column (Image 1). For this upgrade, please download the Cinchy v5.6 k8s-template.zip file.
Navigate to your cinchy.argocd repository. Delete all existing folder structure except for the .git folder/directory and any custom changes you may have implemented.
Navigate to your cinchy.kubernetes repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.
If you have cinchy.kubernetes\cluster_components\servicemesh\istio\istio-injection\argocd-ns.yaml file and it is not commented then please keep it as it is. Changing this will delete your Argocd namespace, which will force you to delete everything from Kubernetes and redeploy.
Navigate to your cinchy.terraform repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.
Navigate to your cinchy.devops.automation repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented and your deployment.json.
Open the new Cinchy v5.6 k8s-template.zip file you downloaded from the Cinchy Releases table and check the files into their respective cinchy.kubernete, cinchy.argocd, cinchy.terraform and cinchy.devops.automation repositories.
Navigate to the new aws.json/azure.json files and compare them with your current deployment.json file. Any additional fields in the new aws.json/azure.json files should be added to your current deployment.json.
Note that you may have changed the name of the deployment.json file during your original platform deployment. If so, ensure that you swap up the name wherever it appears in this document.
Starting in Cinchy v5.4, you will have the option between Alpine or Debian based image tags for the listener, worker, and connections. Using Debian tags will allow a Kubernetes deployment to be able to connect to a DB2 data source, and that option should be selected if you plan on leveraging a DB2 data sync.
When either installing or upgrading your platform, you can use the following Docker image tags for the listener, worker, and connections:
"5.x.x" - Alpine
"5.x.x-debian" - Debian
Perform this step only If you are upgrading to 5.6 on an SQL Server Database and did not already make this change in any previous updates.
Open a shell/terminal from the cinchy.devops.automations directory and execute the following command:
Commit all of your changes (if there were any) in each repository.
If there were any changes in your cinchy.argocd repository you may need to redeploy ArgoCD.
Launch a shell/terminal with the working directory set to the root of the cinchy.argocd repository.
Execute the following command to deploy ArgoCD:
If there were any change to the cluster components, execute the following command from the cinchy.argocd repository:
If there were any change to the Cinchy instance, execute the following command from the cinchy.argocd repository:
Log in to your ArgoCD application console and refresh the apps to ensure that all changes were picked up.
Perform this step only If you are upgrading to 5.5 on an SQL Server Database and did not already make this change in any previous updates. Navigate to your cinchy_instance_configs section > database_connection_string, and add in the following value to the end of your string:
Navigate to your cinchy_instance_configs section > database_connection_string, and add in the following value to the end of your string:
This page details the upgrade process for Cinchy v4.21 on IIS.
This process can be run when upgrading from a Cinchy version that is not v5.0+.
Follow this guide to take a backup of your database.
Extract the new build for the version you wish to upgrade to.
Swap out the following configs with your current instance configs:
Cinchy/web.config
CinchySSO/appsettings.json
Log4net.config
Web.config
Execute the following command:
5. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.
6. Execute the following command:
7. Start Cinchy in your browser.
If you encounter an error during this process, restore your database backup and contact Cinchy Support.
This page details the upgrade process for Cinchy v5.2 on IIS.
Warning: If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.2 or higher, you must run a mandatory process (Upgrade 5.2) .
The following process can be run when upgrading any v5.x instance to v5.2 on IIS.
Take a backup of your database.
Extract thefor the version you wish to upgrade to.
Merge the following configs with your current instance configs:
Cinchy/web.config
Cinchy/appsettings.json
CinchySSO/appsettings.json
CinchySSO/web.config
Execute the following command:
3. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.
4. Execute the following command:
5. Open your Cinchy URL in your browser.
6. Ensure you can log in.
If you encounter an error during this process, restore your database backup and contact Cinchy Support.
This page details the upgrade process for Cinchy v5.1 on IIS.
The following process can be run when upgrading from v5.0 to v5.1 on IIS.
Take a backup of your database.
Extract the new build for the version you wish to upgrade to.
Merge the following configs with your current instance configs:
Cinchy/web.config
Cinchy/appsettings.json
CinchySSO/appsettings.json
CinchySSO/web.config
Execute the following command:
3. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.
4. Execute the following command:
5. Open your Cinchy URL in your browser.
6. Ensure you can log in.
If you encounter an error during this process, restore your database backup and contact Cinchy Support.
This page details the upgrade process for Cinchy v4.x to v5.x on IIS.
Warning: If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.2 or higher, please see the Mandatory Upgrade from INT to BigInt and follow the directives on that page.This process can be run when upgrading your IIS v4 instance to any v5+ instance
If you are upgrading to 5.4+ on an SQL Server Database, you will need to make a change to your connectionString in steps 3.2.2 and 3.3.2. Adding TrustServerCertificate=True will allow you to bypass the certificate chain during validation.
Ex:
Follow this guide to take a backup of your database.
Extract the new build for the version you wish to upgrade to.
Open the C:\CinchySSO\appsettings.json file in a text editor and update the values below.
1. Under AppSettings section, update the values outlined in the table.
2. Wherever you see <base url> in the value, replace this with the actual protocol (i.e. http or https) and the domain name (or ip address) you plan to use.
Ex:. if you're using https with the domain app.cinchy.co, then <base url> should be replaced with https://app.cinchy.co
Key | Value |
---|---|
4.18.0+ includes session expiration based on the CinchyAccessTokenLifetime. So for the default of "0.00:30:00", this means that if you have been inactive in Cinchy for 30 minutes, your session will expire and you will need to log in again.
In order for the application to connect to the database, the "SqlServer" value needs to be set.
If you are upgrading to 5.4+ on an SQL Server Database, you will need to make a change to your connectionString. Adding TrustServerCertificate=True will allow you to bypass the certificate chain during validation.
Ex:
Ensure your database type is set to TSQL.
Find and update the value under the "ConnectionStrings" section:
SQL Server Authentication Example:
SQL Server Windows Authentication Example:
Under the "ExternalIdentityClaimSection" section you'll see the following values.
These values are used for SAML SSO. If you are not using SSO, keep these values as blank
There is a "Serilog" property that allows you to configure where it logs to. In the below code, update the following:
"Name" must be set to "File" so it writes to a physical file on the disk.
"Path" must be set to the file path to where you want it to log.
Navigate to C:\Cinchy
Delete the appsettings.Development.json
Navigate to the appsettings.json file and update the following properties:
In order for the application to connect to the database, the "SqlServer" value needs to be set.
If you are upgrading to 5.4+ on an SQL Server Database, you will need to make a change to your connectionString in steps . Adding TrustServerCertificate=True will allow you to bypass the certificate chain during validation.
Ex:
Ensure your database type is set to TSQL
Find and update the value under the "ConnectionStrings" section:
SQL Server Authentication Example:
SQL Server Windows Authentication Example:
There is a "Serilog" property that allows you to configure where it logs to. In the below code, update the following:
"Name" must be set to "File" so it writes to a physical file on the disk.
"Path" must be set to the file path to where you want it to log.
You can also use an alternative setting if you want to have rolling log files with retention settings by adding in the following parameters:
Your full "Serilog" property, if you choose to use the alternative settings, would look like this, inputting your own variables as required:
Open your Internet Information Services (IIS) Manager.
Navigate to Connections > Sites.
Right click on the Cinchy site and select Manage Application > Advanced Settings.
Change the Cinchy folder path to that of the version you're deploying.
Right click on the CinchySSO site and select Manage Application > Advanced Settings
Ensure that both Applications Pools for Cinchy and CinchySSO have their .NET CLR Versions set to No Managed Code.
Change the Cinchy SSO folder path to that of the version you're deploying.
Execute the following command:
9. Execute the following command:
10. Open your Cinchy URL in your browser.
Because Cinchy v5 creates new tables and assets in the background upon initialization, this first startup may take longer to fully load than usual.
11. Ensure that you can log in.
If you encounter an error during this process, restore your database backup and contact Cinchy Support.
This page details the process for upgrading your AKS instance once you've deployed Cinchy v5 on Kuubernetes.
AKS (Azure Kubernetes Service) is a managed K8 service used when deploying Cinchy v5 over Azure. Once you have deployed your v5 instance of Cinchy, you may want to upgrade your AKS to a newer version. You can do so with the below guide.
Before proceeding for the AKS version upgrade, ensure that you have enough IP address space, as this process will need to start new nodes and pods.
You will need more than 1024 IP addresses in total when you have single Cinchy instance/environment.
If you have limited IP address space, you can upgrade the master node and then the worker node pools one by one.
Before proceeding, make sure to check with Cinchy support which versions of Kubernetes are supported by this process.
Navigate to your ArgoCD Dashboard.
Find and click on your Istio app > disable auto-sync.
Find and click on your Istio-ingress app > disable auto-sync.
Open a terminal and run the following command to get the currently available Kubernetes versions for AKS, inputting your AKS cluster name and resource group where specified:
5. Within your cinchy.devops.automations folder/repo, navigate to the deployment-azure.json file and change the values for kubernetes_version
and orchestrator_version
to the currently available Kubernetes version found in step 4.
6. Within the cinchy.devops.automations folder/repo, run the following command to push your new values:
7. Within your cinchy.terraform/azure/aks_cluster/ directory, run bash create.sh
and accept the change.
8. AKS has three node pools, one node pool per availability zone. Terraform will now start the upgrade of the master node and the zone1 node pool.
9. Verify which nodes that the istio-ingressgateway and istiod pods are running on with below command.
10. In the output you will see aks-zone1/2/3-xxxxx under the Nodes column.
If one or both pods are running on aks-zone1-xxxxx then you need to scale up replicas 2 by following steps 12-14. If not, skip to step 15.
11. Use the following command to start replica on zone2 or zone3 nodes; once you scale down it will terminate from zone1 upgrading nodes.
12. Verify that new pods are running on other node pool by running the following command:
13. Run the following command to scale it back. This will remove the pod from cordoned node:
14. Once Maser node and zone1 upgrade is done, you will see a message such as:
15. The Terraform script will continue with the zone2 and zone3 node pool upgrade. You will see messages like the below when thee zone2 and zone3 node pool upgrade is in process:
16. Repeat steps 11-13. This will make sure that istio-ingressgateway and istiod are running on zone1 nodes.
17. Return to your ArgoCD dashboard and re-enable the auto sync for Istio and Istio-ingress apps auto sync on argocd dashboard.
This page details the upgrade process for Cinchy v5.3 on IIS.
Warning: If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.3, you must first run a mandatory process (Upgrade 5.2) and deploy version 5.2. Once complete, you can continue on with your 5.3 upgrade.
The following process can be run when upgrading any v5.x instance to Cinchy v5.3 on IIS.
Take a backup of your database.
Extract thefor the version you wish to upgrade to.
Merge the following configs with your current instance configs:
Cinchy/web.config
Cinchy/appsettings.json
CinchySSO/appsettings.json
CinchySSO/web.config
Execute the following command:
3. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.
4. Execute the following command:
5. Open your Cinchy URL in your browser.
6. Ensure you can log in.
If you encounter an error during this process, restore your database backup and contact Cinchy Support.
This page details the upgrade process for Cinchy v5.4 on IIS.
Warning: If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.4, you must first run a mandatory process (Upgrade 5.2) and deploy version 5.2. Once complete, you can continue on with your 5.4 upgrade.
If you are upgrading to 5.4+ on an SQL Server Database, you will need to make a change to your connectionString in your SSO and Cinchy appsettings. Adding will allow you to bypass the certificate chain during validation.
Ex:
The following process can be run when upgrading any v5.x instance to v5.4 on IIS.
Take a backup of your database.
Extract thefor the version you wish to upgrade to.
Merge the following configs with your current instance configs:
Cinchy/web.config
Cinchy/appsettings.json
CinchySSO/appsettings.json
CinchySSO/web.config
If you are upgrading to 5.4+ on an SQL Server Database, you will need to make a change to your connectionString in both your SSO and Cinchy appsettings. Adding will allow you to bypass the certificate chain during validation.
Ex:
Execute the following command:
4. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.
5. Execute the following command:
6. Open your Cinchy URL in your browser.
7. Ensure you can log in.
If you encounter an error during this process, restore your database backup and contact Cinchy Support.
The following process can be run when upgrading any v5.x instance to v5.5 on IIS.
Warning: There is a mandatory upgrade for this release that requires you to run the Cinchy Upgrade Utility.
Additionally, If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.5, you must first run a mandatory process (Upgrade 5.2) and deploy version 5.2. Once complete, you can continue on with your 5.5 upgrade.
If you are upgrading from Cinchy v5.3 or lower to Cinchy v5.5 on an SQL Server Database, you will need to make a change to your connectionString. Adding will allow you to bypass the certificate chain during validation.
For a Kubernetes deployment, you can add this value in your deployment.json file:
Take a backup of your database.
Extract thefor the version you wish to upgrade to.
Merge the following configs with your current instance configs:
Cinchy/web.config
Cinchy/appsettings.json
CinchySSO/appsettings.json
CinchySSO/web.config
If you are upgrading to 5.5 on an SQL Server Database and did not do so in any previous updates, you will need to make a change to your connectionString in both your SSO and Cinchy appsettings. Adding will allow you to bypass the certificate chain during validation.
Ex:
Execute the following command:
4. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.
5. Execute the following command:
6. Open your Cinchy URL in your browser.
7. Ensure you can log in.
If you encounter an error during this process, restore your database backup and contact Cinchy Support.
The following process can be run when upgrading any v5.x instance to v5.6 on IIS.
Warning: If you are upgrading from Cinchy v5.1 or lower to Cinchy v5.6, you must first run a mandatory process (Upgrade 5.2) and deploy version 5.2.
If you are upgrading from Cinchy v5.3 or lower to v5.5+ on an SQL Server Database, you will need to make a change to your connectionString in your SSO and Cinchy appsettings. Adding will allow you to bypass the certificate chain during validation.
Ex:
Warning: If you are upgrading from Cinchy v5.4 or lower to Cinchy v5.6, you must first run a mandatory process (Upgrade 5.5) and deploy version 5.5.
The upgrade of any version to Cinchy v5.6 requires changes to be made to the App Settings of your Worker/Listener/Connections setup. See section 1.2, step 3, for further details.
Take a backup of your database.
Extract thefor the version you wish to upgrade to.
Merge the following configs with your current instance configs:
Cinchy/web.config
Cinchy/appsettings.json
CinchySSO/appsettings.json
CinchySSO/web.config
If you are upgrading to 5.6 on an SQL Server Database and did not do so in any previous updates, you will need to make a change to your connectionString in both your SSO and Cinchy appsettings. Adding will allow you to bypass the certificate chain during validation.
Ex:
When upgrading to 5.6, you are required to make the following changes to various appsettings.json files:
Execute the following command:
Replace the Cinchy and CinchySSO folders with the new build and your merged configs.
Execute the following command:
Open your Cinchy URL in your browser.
Ensure you can log in.
If you encounter an error during this process, restore your database backup and contact Cinchy Support.
Key | Value |
---|---|
Key | Value |
---|---|
Key | Value |
---|---|
CinchyUri
<base url>
CertificatePath
Adjust the certificate path to point to the CinchySSO v5 folder. C:\CinchySSO\cinchyidentitysrv.pfx
StsPublicOriginUri
Base URL used by the .well-known discovery. If left blank will match the request URL.
<base url>/cinchysso
CinchyAccessTokenLifetime
Duration for the Cinchy Access Token. This determines how long a user can be inactive until they need to re-enter their credentials. It defaults to "0.00:30:00"
DB Type
Set this to "TSQL"
SAMLClientEntityId
Client Entity Id
SAMLIDPEntityId
Identity Provider Entity Id
SAMLMetadataXmlPath
Identity Provider metadata XML file path
SAMLSSOServiceURL
Configure service endpoint for SAML authentication
AcsURLModule
This parameter is needs to be configured as per your SAML ACS URL. For example, if your ACS URL looks like this - "https:///CinchySSO/identity/AuthServices/Acs", then the value of this parameter should be "/identity/AuthServices"
ExternalIdentityClaim > FirstName > ExternalClaimName
ExternalIdentityClaim > LastName > ExternalClaimName
ExternalIdentityClaim > Email > ExternalClaimName
ExternalIdentityClaim -> MemberOf -> ExternalClaimName
StsAuthorityUri
This should match your Cinchy SSO URL
UseHttps
This is "false" by default.
DB Type
Set this to "TSQL"
Table of Contents |
---|
When you upgrade to Cinchy v5 on Kubernetes you are creating a separate instance. You will need to plan the migration of your database, and then follow the deployment installation guide.
To upgrade from v4+ to v5+ on IIS, review the documentation here.
If you choose to upgrade to Cinchy v5 on PostgreSQL, please review the following features that are not currently available in that deployment.
These may be implemented in future versions of the platform.
No Partitioning
No Geospatial
No Column Indexing
No Full Text Indexing
No Column Level Encryption
You may also wish to review the list of CQL functions currently unsupported in PGSQL. Please note that this is a living document and that the development team is actively working on function translations between databases. Make sure to check back for the most up to date information.