Introduction

This section of Cinchy's documentation will guide you through the deployment process for Cinchy version 5: from planning all the way through to installation and upgrades.

• If you are looking to deploy Cinchy v5, please start here and read through all the sub-pages: Deployment Planning Overview and Checklist

  • Once you have familiarized yourself with the above documentation, you may move on to either of the below guides, depending on your preference:

    • Kubernetes Deployment Installation

    • IIS Deployment Installation

• If you are a customer currently on v4 and want to upgrade to v5, start here: Upgrading from v4 to v5

If you have any questions about the processes outlined in this section, please reach out to our Support team:

• Via email: support@cinchy.com

• Via phone: 1-888-792-6051

• Through the support portal: Support Portal

New Rich Text Editing Capabilities in Forms

Customize the appearance of your Form text with our new rich text editing capabilities. Enabling this on your text columns will give you access to exciting new formatting options previously unavailable in Forms such as:

• Bold, Italic, Underlined text

• Checklists

• Headers

• Hyperlinks

• etc.

For more information on how to make a visual impact with our new rich text editing capabilities, please review the documentation here.

Editable GUIDs

A GUID is a globally unique identifier, formatted as a 128-bit text string, that represents a unique ID. All Cinchy Tables and Columns have a GUID.

You now have the ability to display and edit table and column GUIDs within the Design Table screen.

This feature is particularly useful when deploying between Cinchy instances.

For example, in a model deployment, you must have matching GUIDs on your columns in order for them to properly load between environment A and environment B. There might be times when these GUIDs don’t automatically match, however, such as if you manually added a new column to environment B and also manually added it to environment A.

In this case, the two columns would have different GUIDs, and the model deployment would fail. With this new capability, however, you can match up conflicting GUIDs to properly load your model.

Polling Event Data Sync

Version 5.4 of the Cinchy platform introduces data polling, which uses the Cinchy Event Listener to continuously monitor and sync data entries from your SQLServer or DB2 server into your Cinchy table. This capability makes data polling a much easier, effective, and streamlined process and avoids implementing the complex orchestration logic that was previous necessary to capture frequently changing data.

You can read more about setting up Data Polling here.

BigInt Upgrade Utility

A mandatory database upgrade script was introduced in v5.2 that increased the number of possible Cinchy IDs that can be generated (read the releases note here). To streamline this process further, we have created a utility to deploy the changes. This should save you valuable time and resources when performing the upgrade, even on large databases.

For more information on the utility, please review the documentation here.

New Platform Default Timeout

For new environments (or if your setting was previously left blank), we have changed the Cinchy default session timeout from 30 minutes to 7 days. This will keep you logged in and working without interruptions. You can further change or revert this session timeout value in your appsettings.

In an IIS deployment, you can find the value in your CinchySSO > appsettings.json

“ConfigSettings”: {
	“AppSettings”: {
		"CinchyAccessTokenLifetime": "7.00:00:00",

In a Kubernetes deployment, you can find the value in your deployment.json file.

// The Cinchy session timeout
"cinchy_session_timeout" : "7.00:00:00",

Enhancements

• We have upgraded our application components to .NET 6.0 to ensure official Microsoft support for another 2 years. See the documentation here for more on .NET 6.

• We have added a silent refresh to the Connections experience to keep your session active while you're on the UI and to keep you working without interruptions.

• Real time data sync will now continue to retry if an "Out of Memory Exception" is thrown, avoiding unnecessary downtime.

• You now have the ability to choose between Debian or Alpine based Docker images when using a Kubernetes deployment of the Cinchy platform to be able to connect to a DB2 data source in Connections.

  • When either installing or upgrading your platform, you can use the following Docker image tags for the listener, worker, and connections:

    • Alpine: "5.x.x"

    • Debian: "5.x.x-debian"

• You now have the option to update the default passwords for Grafana and Opensearch in a Kubernetes deployment by configuring your deployment.json file. See here for instructions on updating Grafana and here for Opensearch.

• We have increased the average throughput for CDC subscriptions returning the Cinchy ID, so that it will now be able to process a greater number of events per second. Being able to reliably exceed 1000 events per second, based on the average use case, means that you can leverage the CDC capability for more demanding use cases.

• Prior to this release, the Files API could only handle files up to 100mb. We have now upped the maximum default file size to 1GB and have added a configurable property to allow you to set your own upload size should you wish.

  • In an IIS deployment, you can find the value in your Cinchy > appsettings.json

“ConfigSettings”: {
	“AppSettings”: {
		“MaxRequestBodySize”: 1073741824 // 1g

• In a Kubernetes deployment, you can find the value in your deployment.json file.

// this field defaulted at 1gb, dictates the max file upload size set in the web appsettings.json
"web_max_request_body_size" : 1073741824,

Bug Fixes

• We have fixed an error that occurred when attempting a data sync with conflicting target and source data types in link columns, where the error message would read: Value must be specified from the available options

• We have fixed an issue that was preventing new Connection jobs from starting when a previous job got stuck.

• We have fixed an issue where data syncs would fail if your sync key used a Target Column with a Link Column property that is different from the Primary Linked Column in the table definition.

• We have fixed a bug that was impacting write performance to tables on PostgreSQL with Data Change Notifications enabled.

• We have fixed a "cell entitlements failed" error on Forms that would occur if a Form column contained a single quote in the column name.

• We have fixed an issue on Forms where adding a [Created By] or [Modified By] field would return an error.

• The /healthcheck no longer redirects to the initialization screen during a Cinchy startup, allowing you to properly hit the endpoint.

What’s the purpose of Dataware and Data Collaboration?

Dataware is the emergence of a common group of technologies that solve data related problems across many business use cases. One of the most exciting new categories within this group is Data Collaboration.

Data Collaboration solves the costly, time-consuming, and ineffective integration processes born from silo-ing your data in a traditional app-centric environment. Instead of your data serving your applications, data collaboration refocuses and pivots to a model where your data is at the forefront and is being served by your apps (Image 1).

Harnessing this power, Cinchy connects unlimited data sources within a networked architecture, offering persistent delivery of real-time solutions, without complex integrations. And the more data you connect into your data network, the more powerful your processes can be.

The root causes of IT delay and frustration

When a new IT project is green-lit, you often pay a hefty fine called the integration tax where you're continuously building new integrations between applications, just to reuse data that is already available in your systems.

Over time, this never-ending cycle of copying data between fragmented apps gets more complex, resulting in delayed launches, budget overruns, and “shadow IT” projects.

This process of making copies now consumes up to 50% of the resources on large IT projects, and it's the reason that delivery often takes months, sometimes years, and costs millions (Image 2).

How can this be fixed?

Data Collaboration: Using Dataware for accelerated solutions delivery

With data collaboration, you shift your approach from integration for data sharing, to access for data collaboration (Image 3).

For every app you build where you leverage data collaboration, you’re able to access the network to reuse information for future apps. Your IT team will find that previous projects have already connected many of the data sources they need to the network.

Cinchy's data collaboration platform does for application development what the power grid does for individual buildings. In the same way that buildings no longer need to generate their own power thanks to the power grid, with a data collaboration platform applications no longer need to manage, integrate, and protect their own data (Image 4).

Organizations can build data collaboration applications in half the time, while enabling effortless and copyless data sharing across applications. Using Cinchy is unique in that it eliminates the "integration tax" that today consumes half of most enterprise IT budgets -- that is to say, data collaboration makes integration obsolete (Image 5).

Now, instead of connecting apps to gain access to data through costly point-to-point integration, your apps serve your data by leveraging and connecting it all together via Cinchy. In this way, you can still gain the best usage out of your apps through zero-copy integration while avoiding the disadvantages of data silo-ing. You have both full access to and full control of your data (Image 6).

Not just connected, but autonomous.

​Simply putting pipes between data silos, and centralizing a few housekeeping tasks, is not data collaboration. What that's actually doing is leading you down a path of managing endless copies. True data collaboration not only connects your data but upgrades it as part of an interconnected, autonomous network.

Autonomous data exists independently of any application. It is self-controlled, self-protected, and self-describing. This creates a number of benefits compared to traditional app-dependent data, including the ability to simplify cross-application usage and reporting. And when you use autonomous data in an interconnected network, wherein individual contributors maintain their roles and priorities as they apply their unique skills and leadership autonomy in a problem solving process, you get: Collaborative Autonomy.

Collaborative Autonomy is thus the principle underpinning Collaborative Intelligence, the entire basis of Dataware and Cinchy.

Individuals are not homogenized, as in consensus-driven processes, nor equalized through quantitative data processing, as in collective intelligence. Consensus is not required. Problem resolution is achieved through systematic convergence toward coherent results. Collaborative intelligence relies on the principle of collaborative autonomy to overcome “the consensus barrier” and succeed where other methods have failed.

Universal access controls, automated governance

One of the most significant advantages of dataware is the ease with which data owners can set universal data access controls at the cellular level, and automate data quality (Data Governance) with a “golden record” of data.

In effect, it is removing the need to maintain access controls within individual apps and centralizing these functions in an incredibly efficient way.

Compare this with designing and maintaining controls within thousands of apps and systems independently. It’s not only incredibly challenging and costly, but virtually impossible to maintain consistency (Image 7).

Game Changer: Network Effects for IT delivery

Dataware is a game changer for IT delivery: it produces network effects, where each new solution actually speeds up delivery times and reduces costs

Network-based designs scale beautifully and become more efficient as they expand. Consider the human brain; its neuroplasticity helps it learn more as it grows. The more interconnected it gets, the better. The neural pathways are reorganizing themselves such that the fewer connections, the higher the intelligence, because information is more efficient to operationalize.

It's the same with dataware. The more you connect your data, the harder and better it works. It's the ability to have the platform take care of your whole data journey and transformation. You don't have to manage the changes of all your applications, regression testing, the QA you have to go through, etc.

And it's also your time machine - you can have applications based on different points in time of your data, and it's all done through network-based design.

Now that you know how efficient and secure things can be there is no going back.

Let's build the connected future, together.

Cinchy Upgrade Utility

The Cinchy Upgrade Utility was previously introduced in v5.2 in order to facilitate a mandatory INT to BigInt upgrade. This tool will continue to be used in subsequent releases as an easy way to deploy necessary changes to your Cinchy platform.

For version 5.5, you must run the Upgrade Utility in order to fix a row-breaking issue that could be triggered on cells with over 4000 characters, where you are unable to update any column in your record.

Please review the Utility Guide or Upgrade Guide for further details.

New: Personal Access Tokens

You now have the option to use personal access tokens (PATs) in Cinchy, which are alternatives to using passwords for authentication. Similar to Cinchy Bearer Tokens, you can use a Cinchy PAT to call the Cinchy API as your current user, meaning your associated access controls will be honoured as well. Cinchy PATs, however, have an expiration date of up to 1 year. A single user can have up to 5 PATs active at one time.

For information on setting up, configuring, and managing PATs, please review the documentation here.

MongoDB

We have added MongoDB to our Connections offering as both a source and target connector.

MongoDB is a scalable, flexible NoSQL document database platform known for its horizontal scaling and load balancing capabilities, which has given application developers an unprecedented level of flexibility and scalability.

Review the following documentation to utilize this new capability in Cinchy:

• Setting up a MongoDB Collection (Event Triggered) as a source connector

• Setting up a MongoDB Collection as a source connector

• Setting up MongoDB as a target connector

• Setting up a MongoDB change stream

Enhancements

• We are continuing to improve our text editor functionality for forms. You can now embed tables and images into your text. We have also made various styling and usability quality of life updates, including the addition of checkbox style lists.

• We have added support for ephemeral volumes in Connections on a Kubernetes deployment. Unlike persistent volumes, ephemeral storage is unstructured and the space is shared between all pods running on a node**;** it allows pods to be started and stopped without being limited to the location of persistent volume. Running more than one pod for Connections per availability zone enables you to effectively leverage auto-scaling functionality.

• We have updated the Connections experience to enable more use cases. You can now use CDC parameters in Calculated Columns and use the CinchyID in the sync key in real-time syncs.

• Kafka supports cluster encryption and authentication, which can encrypt data-in-transit between your applications and Kafka. We have added the ability to include this encryption/authentication in the Listener Config when setting up real-time syncs using Kafka.

  • Using this parameter will specify which protocol will be used for communication between client and server. Cinchy currently supports the following options: Plaintext, SaslPlaintext, or SaslSsl.

    • Paintext: Unauthenticated, non-encrypted.

    • SaslPlaintext: SASL-based authentication, non-encrypted.

    • SaslSSL: SASL-based authentication, TLS-based encryption.

  • Review the Listener Config documentation on Kafka here.

• We have improved the implementation of tooltips such that linked columns display the tables that they link to. Hovering over the i symbol on a linked column will show the linked domain and table in the following format: Domain - Table; ex: HR - Employees. You can now also see them in the grid view.

• We have introduced a Retry Configuration for REST API sources and targets. This will automatically retry HTTP Requests on failure based on a defined set of conditions. This capability provides a mechanism to recover from transient errors such as network disruptions or temporary service outages.

  • For more information on using this configuration, refer to the documentation here for REST sources and here for REST targets.

• We have increased the default retention for Prometheus from 5GB to 50GB to allow you to store more metric data at a time.

  • This change is automatically reflected in new v5.5 deployments. Customers on previous v5 versions wishing to implement the change are able to rerun the automation script and deploy the new template to reflect the update.

• To make the Forms experience more responsive and process quicker, we have introduced lazy loading of records while searching. Instead of loading and rendering every form record in the search box, which can be a slow process for use cases with millions of records, lazy loading will initially retrieve a limited number of records. These results can then be further optimized by inputting your Lookup Filter Conditions.

• We have added the ability to pass parameters from a REST response into post sync scripts during both real-time and batch data syncs, allowing you to do more with your REST API data.

  • For an example and instructions on this capability, please refer to the documentation here.

• Data changes in Cinchy (CDC) can now be used to trigger a data sync from a REST API or MongoDB data source to a specified target. This works as an alternative to RunQuery.

  • For more information, please review the documentation here (REST API) and here (MongoDB).

• We have added two new functions, JSON_ESCAPE and URL_ESCAPE, which can be used in Connections to escape parameter values when used in constructing the body of a REST API Request or in the URL

• We have added an Authorization header type for REST API data syncs in Connections. An authorization request header can be used to provide credentials that authenticate a user with a server, allowing access to a protected resource.Selecting this header defines the Header Value as a password field.

Bug Fixes

• We have solved an issue that was causing Connections to get stuck behind long running jobs despite there being capacity to execute. This fix enables predictable execution behavior without stoppage.

• We have fixed an issue in the MatchEngine where execution was failing in versions of Cinchy above 5.2.

• File sourced data syncs will no longer fail, allowing you to run Connection jobs with uploaded files without the risk of a file not found error when auto-scaling is enabled.

• In order to prevent needlessly exhausting Cinchy IDs, the platform will no longer continuously retry to update records that have failed to save. This can sometimes occur when a value causes a calculated field to violate a uniqueness constraint. If the below error appears, you will have to manually update the cell to retry the save.

• We have fixed a bug that was causing the Connections UI to crash if you attempted to run a job while there was an empty parameter in the Info tab (ex: no name or formula)

• We have fixed a bug that would causes images in Forms to sometimes appear with a label above them, using the image's URL as the label's value.

• We have fixed a bug that was forcibly terminating authenticated sessions in Grafana, now allowing you to work without interruptions.

• We have solved an issue where using a form as a child form with file links wouldn't render the link thumbnail correctly in the "edit record" view.

• We have fixed a bug that prevented record updates when multiple users attempted to update a row in too quick of a succession.

• We have fixed an issue where doing delta batch syncs with a REST API target wouldn’t replace the @COLUMN parameter correctly.

• We have fixed a bug in Connections where an Oracle sync target would have the wrong tag in the Config XML.

• We have fixed a bug that was causing a “Listener is running” message to erroneously appear when the status of the listener was actually set to Disabled.

• We have fixed a bug that was preventing REST API real-time sync execution errors from being inserted into the execution errors table.

Download the Release Notes

Deprecation of the k8s.gcr.io Kubernetes Image Repository

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 the upgrade guide to ensure your components are pointed to the correct image repo.

You can review the full details on this change on the Kubernetes blog.

Connections UI Change to Sync Behaviours Tab

To continuously improve our Connections experience, we have made changes to the Sync Behaviours tab for Full-File data syncs.

• Record behaviour is now presented via radio buttons so that you can see and select options quicker and easier than ever before.

• We have added a new "Conditional" option for Changed Record Behaviours. When Conditional is selected, you will be able to define the conditions upon which an Update should occur. For instance, you can set your condition such that an update will only occur when a "Status" column is changed to "Red", otherwise it will ignore the changed record. This new feature provides more granularity on the type of data being synced into your destination and allows for more detailed use cases. For more information on this new function please review the documentation here.

Enhancements

Deployment

We have added support AWS EKS EBS volume encryption for customers wishing to take advantage of industry-standard AES-256 data encryption without having to build, maintain, and secure their own key management infrastructure.

By default, the EKS worker nodes will have a gp3 storage class for new deployments. If you are already running a Cinchy environment: make sure to keep your eks_persistent_apps_storage_class to gp2 within the devops automation aws.json file.

If you want to move to gp3 storage or gp3 storage and volume encryption: you will have to delete the existing volumes/pvc's for Kafka, Redis, Opensearch, Logging Operator and Event Listener with StatefulSets so that ArgoCD can recreate the proper resources.

Should your Kafka cluster pods not come back online after deleting the existing volumes/pvc's, restart the Kafka operators. You can verify the change by running the below command:

kubectl get pvc --all-namespaces

Platform

• Miscellaneous security fixes.

• General CDC performance optimizations.

Connections

• Continuing to increase our data sync capabilities and features, you can now use @CinchyID as a parameter in post sync scripts when the source is from a Cinchy Event (such as the Event Broker, the Event Triggered REST API, and the Event Triggered MongoDB sources). This means that you can now design post sync scripts that take advantage of the unique CinchyID value of your records.

• To better communicate the relationship between the Source and any required Listener Configurations, we have added additional help text to event-based sources to the Source step of a connection. This help text will help better elucidate when a listener configuration is required as part of the sync.

• We have expanded on our Cinchy Event Triggered data sync source features (REST API and MongoDB), allowing you more freedom to utilize your data. You now have the ability to reference attributes of the CDC Event in your calculated columns. (Note that syncs making use of this must limit their batch size to 1.)

• To better enable your business security and permission-based needs, you are now able to run the Connections pod under a service account that uses an AWS IAM (Identity and Access Management) role, which is an IAM identity that you can create to have specific permissions and access to your AWS resources. To set up an AWS IAM role for use in Connections, please review the documentation here.

• To make troubleshooting easier, Connections Builders are now able to download batch sync logs directly from the Experience UI. This prevents the need to have to either wait for logs to appear in Opensearch or relying on an administrator/support to provide logs

• You are also able to use AWS IAM roles when syncing S3 file or DynamoDB sources in Connections. For more information, please review the "Auth Type" field in the relevant data sync source pages.

• To increase your data sync security and streamline authentication, we have added support for the use of x.509 certificate authentication for MongoDB Collection Sources, MongoDB (Cinchy Event Triggered) Sources, and MongoDB Targets. This new feature can be accessed directly from the Connections UI when configuring your data sync. For more information, please review the configuration pages for MongoDB Collection Source, MongoDB (Cinchy Event Triggered) Source, and MongoDB Targets.

Bug Fixes

Platform

• We have fixed a bug that was causing bearer token authenticated APIs to stop working on insecure HTTP Cinchy environments.

• We have fixed an issue relating to the .NET 6 upgrade that was causing the Event Listener and Worker to not start as a service on IIS in v5.4+ deployments.

• We have fixed a “Column doesn’t exist” error that could occur in Postgres deployments when incrementing a column (ex: changing a column data type from number to text).

• We have fixed a bug where table views containing only a single linked column record would appear blank for users with “read-only” permissions.

Connections

• We have fixed a bug where the Listener Configuration message for a data sync using the MongoDB Event source would return as "running" after it was disabled during an exception event -- the message will now correctly return an error in this case.

• We have fixed a bug that was preventing DELETE actions from occurring when Change Approvals were enabled on a CDC source.

• In continuing to provide useful troubleshooting tools, we have fixed a bug that was preventing dead messages from appearing in the Execution Errors table when errors occurred during the open connection phase of a target. This error may have also occurred when a MongoDB target had a connection string pointing to a non-existent port/server.

• We have fixed a bug that was preventing Action Type column values of "Delete" from working with REST API target Delta syncs.

• We have fixed a data sync issue preventing users from using environment variables or other parameters in connection strings.

• We have fixed a bug in the Polling Event data sync where records would fail with a “unique constraint violation” if both an insert and an update statement happened at nearly the same time. In order to implement this fix, you need to add the “messageKeyExpression” parameter to your listener config when using the Polling Event as a source. Please review the documentation here for further information.

• We have fixed a bug that was causing data syncs to fail when doing platform event inserts of any type into Salesforce targets.

• We have fixed a bug where using the ID Column in a Snowflake target sync would prevent insert and update operations from working.

• We have fixed a bug where attempting to sync documents using a UUID (Universally Unique IDentifier) as a source ID in a MongoDB Event Triggered batch sync would result in a blank UUID value when saved to a Cinchy table.

Meta-Forms

We have made application stability and quality fixes to Forms, including:

• Custom date formats now work in Grid, Form, and Child Form views.

• A child form that has a Link column reference to a parent record now auto-populates with the parent record's identity.

• A space has now been added between multi-select values when displaying a record in an embedded child table.

• Negative numbers can now be entered into Number type inputs on forms.

• We have fixed an issue where updated file attachments on a form would fail to save.

CQL

• We have fixed a bug that was causing a “Can’t be Bound" error when you attempted to use an UPDATE query on a multi-select link column as a user with multiple filters active.

Table of Contents

New Connector

• A new connector has been added to the Cinchy Connections experience: you can now use Snowflake as a source and target connector when performing data syncs. You can review the documentation on connecting as a source here and as a target here.

GraphQL API Beta Release

• Our GraphQL API provides a complete and understandable description of your data and gives you the power to ask for exactly what data you need and nothing more all in a single request, while leveraging the existing ecosystem of GraphQL developer tools.

• This is a beta release that offers read-only queries. Future releases will include more query features and mutation support (writes).

Enhancements

Connections

• Performing Data Sync from Cinchy to Salesforce no longer requires write access to the sync key column. This means that you can maintain your Salesforce environment and security protocols without needing to either modify them or create additional attributes, for your sync to work.

• We have introduced a new STRING_ESCAPE() function that escapes single quotes when wrapped around data sync parameters. It uses the following syntax to wrap around parameters or column references respectively: STRING_ESCAPE(@COLUMN('yourcolumn')) or STRING_ESCAPE(@yourparameter). This function is particularly useful when used in a post sync script's CQL.

Data Browser

• We have added WCAG 2.1 AA Accessibility fixes to improve screen-reader performance and keyboard navigation accessibility.

• We’ve implemented a new loading screen for when Cinchy is installing and initializing.

Meta Forms

• We have improved the performance of Meta Forms by reducing the rendering time and adding visual guides to help you see which form sections have completed loading.

• Date fields with custom display formats will now render correctly, as opposed to showing up in mm/dd/yyyy format by default.

• In forms that have a 1:1 parent/child hierarchy, we have added the option to render the child form as a flattened form, instead of in a table grid.

• To improve UI consistency across Forms, the record selection drop down will now appear even if no records exist in the destination table.

CQL Updates

• We have added a new function, GetLastModifiedBy([Column]), which will return the CinchyID of the user who last modified the specified column. For more information on this new function, review the documentation here.

Bug Fixes

• We have fixed an error where scrolling in a table with a file column in certain situations prevents the UI from rendering all the data.

• We have fixed an issue where sorting by columns with a ‘%’ in the column name caused the rows not to sort correctly in the UI.

• We have fixed a bug in Meta Forms that prevented queries in child form filters from working as expected when using OR conditions.

Overview

Becoming comfortable with the Cinchy terms and verbiage is an essential step to broaden your understanding of the platform and Data Collaboration as a whole. We have created this handy guide featuring to help you better understand the words and phrases you may see appear throughout this wiki space.

B

Batch Sync

A Batch Sync is one of the two types of Data Syncs that you can perform using Cinchy. by processing a group or a ‘batch’ of data all together rather than each piece of data individually. When the data sync is triggered it will compare the contents of the source to the target. The Cinchy Worker will decide if data needs to be added, deleted or updated. Batch sync can either be run as a one-time data load operation, or it can be scheduled to run periodically using an external Enterprise Scheduler

C

Cinchy Administrator

The is a user or user group with special within the Cinchy platform. An administrator can be either an or a

A Builder Admin can:

• Modify all table data (including system tables), all schema, and all data controls

  • This includes setting up and configuring users, assigning them to groups, and assigning which users have builder access

• View all tables (including system tables) and queries in the platform

A Non-Builder Admin can:

• View all tables (including system tables) and queries in the platform

• Modify data controls for tables

Cinchy Builder

The “Cinchy Builder” has access to perform the following capabilities:

• Change Table Schema (use Cinchy’s “Design Table” functionality)

• Grant access (use Cinchy’s “Design Controls” functionality)

• Edit Cinchy Data in Cinchy System Tables

• Create, Save, and Share Cinchy Queries

• Perform ad hoc Cinchy Queries on the Cinchy data network

• Import/export packaged business capabilities (i.e. deployment packages)

• Build Cinchy Experiences

• Perform integration with Cinchy (e.g. Cinchy Command Line Interface [CLI] operations)

• Create and Deliver an unlimited number of Customer Use Cases within Cinchy

Cinchy CLI

CinchyDXD

CinchyDXD is a downloadable utility used to move Data Experiences (DX) from one environment to another. This includes any and all objects and components that have been built for, or are required in, support of the Data Experience.

Cinchy ID

Cinchy ID is a unique identifier assigned automatically to all records within a normal table. The Cinchy ID is associated with the record permanently and is never reassigned even if the record is deleted.

Cinchy Query Language (CQL)

Cinchy Query Language can be used in many ways, including but not limited to:

• ​Building queries through the query editor that can return, insert, delete, and otherwise manage your data.

• ​Creating, altering or dropping views for tables​

• ​Creating, altering or dropping indexes​

Cinchy Upgrade Utility

Cinchy End-User

• Direct Users log into Cinchy via the data browser

• Indirect Users (also commonly referred to as "external users") view/edit data via a third-party application/page that connects to Cinchy via API

Cinchy End-Users are able to:

• Create and save personal queries. Unlike traditional saved queries made by builders, personal saved queries cannot be shared and are not auto-exposed as APIs.

• Track version history for the full lifecycle of data

• Bookmark and manage data

• Access data through application experiences

Connections Experience

D

Dataware

Data Browser

Data Collaboration

Data Collaboration entails the collection, exchange and use of data from different origins within an organization. This interaction creates data products with data owners acting as experts for their specific data domains. The interaction of these various data set domains also results in dramatically informed insights that are solely driven by the interactions of the data itself.

Data Destination(s)

Data Source(s)

Data Synchronizations

E

Entitlements

Entitlements refers to the set of permissions that you are granted for any piece of data. Cinchy allows entitlements to be set at a very granular level, meaning you can give individual users or user groups access to things like:

• Viewing a data sync

• Running a job

• Viewing a specific table row or column

• Editing a specific table cell

• Etc.

Experiences

L

Listener Configuration

M

MDQE

• Healthchecks returning a critical status

• Upcoming Project Due Dates/Timelines

• Client Risk Ratings reaching a high threshold

• Tracking Ticket Urgency or Status markers

• Unfulfilled and Pending Tasks/Deliverables

• Etc.

In a nutshell, MDQE monitors for specific changes in data, and then pushes out notifications when that change occurs.

Meta Forms

It lives on top of the data collaboration platform, allowing builders to create forms with custom configurations and users to access this data outside of the tabular view that is native to Cinchy.

N

Network Map

Each node represents a table you have access to within Cinchy, and each edge is one link between two tables. The size of the table is determined by the number of links referencing that table. The timeline on the bottom allows you to check out your data network at a point in the past and look at the evolution of your network.

Q

Queries/Saved Queries

R

Real Time Sync

1. Overview

There are various things to consider before deploying Cinchy v5.

The pages in this Deployment Planning section will guide you through the considerations you should think about and the prerequisites that you should implement before deploying version 5 of the Cinchy platform.

The pages in this section include:

• : This page explores your two high-level options for deploying Cinchy, on Kubernetes or on VM, and why we recommend a Kubernetes deployment. It also walks you through the important decision of selecting a database to run your deployment on, as well as some sizing considerations.

  • : This page provides Infrastructure (for both Azure and AWS), Cluster, and Platform component overviews for Kubernetes deployments. It also guides you through considerations concerning your cluster configuration.

  • : This page provides Infrastructure and Platform component overviews for IIS (VM) deployments.

• : This page details important prerequisites for deploying Cinchy v5.

2. Deployment Planning Checklist

We have provided the following checklist for you to use when planning for your Cinchy v5 deployment. Each item is linked to the appropriate documentation page to provide more insight and clarity.

• Will you run on ?

WIndows IIS vs Kubernetes

is an open-source system that manages and automates the full lifecycle of container-based applications. You now have the ability to deploy Cinchy v5 on Kubernetes, and with it comes a myriad of features that help to simplify your deployment and enhance your scaling. Kubernetes can maximize your container capacity and easily scale up/down with your current operations.

You also have the option to run Cinchy on , which was the traditional deployment method prior to Cinchy v5. Internet Information Services (IIS) for Windows Server is a flexible, secure and manageable Web server for hosting anything on the Web.

We recommend using Kubernetes to deploy Cinchy v5, because of the robust features that you can leverage, such as improved logging and metrics. Using Kubernetes allows for a greater ability to scale your Cinchy instances as well as the ability to lower your costs by using PostgreSQL.

The main differences between a Kubernetes based deployment and an IIS deployment are:

If you will be running on Kubernetes, please review the following checklist:

• • Will you be sharing from an existing cluster?

  • Will you be running multiple environments on a single cluster?

  • Will you be using Cinchy's recommended cluster components or your own?

If you will be running on IIS, please review the following checklist:

• • Specifically, install: ASP.NET Core/.NET Core Runtime & Hosting Bundle

Table of Contents

1. Infrastructure Configuration (On Cluster)

The below diagram shows a high level overview of a possible Infrastructure diagram with components on the cluster, however your specific configuration may vary (Image 1).

2. AWS Infrastructure Configuration (Outside Cluster)

When deploying Cinchy version 5 on Kubernetes, you may deploy via Amazon Web Services (AWS). The below diagram shows a high level overview of a possible AWS Infrastructure with components outside the cluster, however your specific configuration may vary (Image 2).

2.1 Infrastructure Component Overview

3. Azure Infrastructure Configuration (Outside Cluster)

When deploying Cinchy version 5 on Kubernetes, you may deploy via Microsoft Azure. The below diagram shows a high level overview of possible Azure Infrastructure with components outside the cluster, however your specific configuration may vary (Image 3).

3.1 Infrastructure Component Overview

4. Cluster Level Component Overview

The following highlighted area provides a high-level overview of cluster level components used when deploying Cinchy on Kubernetes, as well as what versions they are running.

These are created once per cluster. Clients may choose to run these components outside of the cluster or replace with their own comparable components. This diagram shows them in the cluster (Image 4).

Cluster Level Components

These are created once per cluster. Clients may choose to run these components outside of the cluster or replace with their own comparable components.

4.1 Cluster Configuration

There are a few things to consider about your cluster configuration before you deploy Cinchy on Kubernetes:

• How many clusters will you need?

• Will you be sharing from an existing cluster?

• Will you be running multiple environments on a single cluster?

5. Instance Component Overview

Each instance of Cinchy has the following components, which are used to either provide an experience to users/applications or connect data in/out of Cinchy. Since multiple Cinchy instances can be deployed per cluster, these components will repeat for each environment.

The following highlighted area provides a high-level overview of instance level components used when running Cinchy on Kubernetes (Image 5).

• Connections: The Cinchy Connections experience is used to help easily create data syncs in/out of the platform. It features persistent storage.

• Data Browser: Cinchy’s Dataware platform features a Universal Data Browser that allows users to view, change, analyze, and otherwise interact with all data on the network. The Data Browser even enables non-technical business users to manage and update data, build models, and set controls, all through an easy and intuitive UI.

• Identity Provider: An Identity Provider (IdP) creates and manages user credentials and associated identity attributes. IdPs authentication services are used in Cinchy to authenticate end-users.

6. GitOps

Once you configurations are set, ArgoCD automates the deployment of the desired application states into your specified target environments. Implemented as a Kubernetes controller, it continuously monitors running applications and compares the current, live state against the desired target state (as specified in your repositories).

Table of Contents

1. Kubernetes vs IIS

When choosing to deploy Cinchy version 5, you must decide whether to deploy via Kubernetes or on a VM (IIS).

is an open-source system that manages and automates the full lifecycle of container-based applications. You now have the ability to deploy Cinchy v5 on Kubernetes, and with it comes a myriad of features that help to simplify your deployment and enhance your scaling. Kubernetes can maximize your container capacity and easily scale up/down with your current operations.

• Grafana, Opensearch, Opensearch Dashboard: Working together, these three applications provide a visual logging dashboard for all of the information coming in from your database pods. This streamlines your search for information by putting the control into your hands and compiling your logs in one easy to access place — you can now easily write a query against all of your logs, in all of your environments. You will have access to a default configuration out of the box, but you can also customize your dashboards as well.

• Prometheus: With the Kubernetes addition, you now have access to Prometheus for your metrics dashboard. Prometheus records real-time metrics in a time series database used for event monitoring and alerting. You can then create custom dashboards to display your data in an easy to use visual that makes reporting on your metrics easy, and even set up push alerts based on your custom needs.

You also have the option to run Cinchy on , which was the traditional deployment method prior to Cinchy v5. Internet Information Services (IIS) for Windows Server is a flexible, secure and manageable Web server for hosting anything on the Web.

We recommend using Kubernetes to deploy Cinchy v5, because of the robust features that you can leverage, such as improved logging and metrics. Using Kubernetes allows for a greater ability to scale your Cinchy instances as well as the ability to lower your costs by using PostgreSQL.

2. Choosing a Database

Before deploying Cinchy v5, you must select which database you want to use.

The following list outlines which databases we support for Kubernetes Deployments.

For IIS Deployments

2.1 Microsoft SQL Server

• Microsoft SQL Server is a relational database management system. As a database server, it is a software product with the primary function of storing and retrieving data as requested by other software applications—which may run either on the same computer or on another computer across a network.

• Microsoft Azure SQL Database is a managed cloud database provided as part of Microsoft Azure. It runs on a cloud computing platform, and access to it is provided as a service. Managed database services take care of scalability, backup, and high availability of the database.

• SQL Managed Instance is a managed, always up-to-date SQL instance in the cloud that combines broad SQL Server engine compatibility with the benefits of a fully managed PaaS.

2.2 Amazon Aurora

• Amazon Aurora (Aurora) is a fully managed relational database engine that's compatible with MySQL and PostgreSQL. It combines the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases. Aurora is part of the managed database service Amazon Relational Database Service (Amazon RDS). Amazon RDS is a web service that makes it easier to set up, operate, and scale a relational database in the cloud.

2.3 PostgreSQL

• PostgreSQL is a free and open-source relational database management system emphasizing extensibility and SQL compliance. PostgreSQL comes with features aimed to help developers build applications, administrators to protect data integrity and build fault-tolerant environments, and help you manage your data no matter how big or small the dataset.

• Amazon RDS makes it easy to set up, operate, and scale PostgreSQL deployments in the cloud. With Amazon RDS, you can deploy scalable PostgreSQL deployments with cost-efficient and resizable hardware capacity. Amazon RDS manages complex and time-consuming administrative tasks such as PostgreSQL software installation and upgrades; storage management; replication for high availability and read throughput; and backups for disaster recovery. Amazon RDS for PostgreSQL gives you access to the capabilities of the familiar PostgreSQL database engine.

• This is a fully managed and intelligent Azure Database for PostgreSQL. Enjoy high availability with a service-level agreement (SLA) up to 99.99 percent, AI-powered performance optimization, and advanced security. A fully managed database that automates maintenance, patching, and updates. Provision in minutes and independently scale compute or storage in seconds.

3. Sizing Considerations and Requirements

Prior to deploying Cinchy version 5, you need to define your sizing requirements.

3.1 Sizing

3.1.1 Kubernetes Sizing

Cluster sizing recommendations vary and are dependant on a myriad of deployment factors. We have provided the following very general sizing recommendations, but encourage you to explore more personalized options.

CPU: 8 Cores

Memory: 32GB Ram

Number of Servers: 3

AWS: m5.2xlarge

Azure: D8 v3

3.1.2 IIS Sizing

3.2 Application Storage Requirements

If you are choosing to deploy Cinchy v5 on IIS, then you need to ensure that your VM disks have enough application storage to run your clusters.

3.3 Object Storage Requirements

If you are using Terraform for your Kubernetes deployment, you will need to set up a new S3 compatible bucket to manually to store your state file. You will also need a bucket for Connections, to store error files created during data syncs.

Example Terraform Bucket: cinchy-terraform-state

Example Connection Bucket: cinchy-connections-cinchy-nonprod

There is no sizing definitions, as S3 provides unlimited scalability and it charges only for what you use/how much you store on it.

1. How to Enable TLS 1.2

1. Navigate to the CinchySSO Folder > appsettings.json file.

2. Find the following line:

add key="TlsVersion" value=""

3. Replace the above line with the following:

add key="TlsVersion" value="1.2"

4. Navigate to the Cinchy Folder > web.config file.

5. Find the following line:

add key="TlsVersion" value=""

6. Replace the above line with the following:

add key="TlsVersion" value="1.2" 

7. You may need to restart the application pools in IIS for the changes to take effect.

Contacting Support

If at any point you require help or clarification on this documentation or your Cinchy platform, you can reach out to our Support team:

• Via email: support@cinchy.com

• Via phone: 1-888-792-6051

• Through the support portal: Support Portal

Overview

Beginning in Cinchy v5.6, you are now able to run the Connections pod under a service account that uses an AWS IAM (Identity and Access Management) role, which is an IAM identity that you can create to have specific permissions and access to your AWS resources. To set up AWS IAM role authentication, please review the procedure below.

1. AWS IAM Role Authentication

1. To check that you have an OpenID Connect set up with the cluster (the default for deployments made using the Cinchy automation process), run the below command within a terminal:

aws eks describe-cluster --name <CLUSTER_NAME> --query "cluster.identity.oidc.issuer"

1. The output should appear like the below. Make sure to note this down for later use.

https://oidc.eks.<REGION>.amazonaws.com/id/<OIDC_ID>

1. Log in to your AWS account and create an IAM Role policy through the AWS UI. Ensure that it has S3 access.

2. Run the below command in a terminal to create a service account with the role created in step 3. If your cluster has a special character like an underscore, skip to section 1.1.

eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name "my-role" --attach-policy-arn arn:aws:iam::111122223333:policy/my-policy --approve

1.1 Cluster Names with Special Characters

If your cluster name has a special character, like an underscore, you will need to create and apply the yaml. Follow section 1 up until step 4, and then follow the below procedure.

1. In an editor like Visual Code or similar, create a new file titled "my-service-account.yaml" in your working directory. It should contain the below content.

/apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default

1. In a terminal, run the below command:

kubectl apply -f my-service-account.yaml -n <namespace>

1. In an editor like Visual Code or similar, create a new file titled "trust-relationship.json" in your working directory. It should contain the below content.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::$account_id:oidc-provider/$oidc_provider"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "$oidc_provider:aud": "sts.amazonaws.com",
          "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
        }
      }
    }
  ]
}

For example,

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::204393242335:oidc-provider/oidc.eks.ca-central-1.amazonaws.com/id/8A024CF24ADD3925BEFA224C4BDD005B"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.ca-central-1.amazonaws.com/id/8A024CF24ADD3925BEFA224C4BDD005B:aud": "sts.amazonaws.com",
                    "oidc.eks.ca-central-1.amazonaws.com/id/8A024CF24ADD3925BEFA224C4BDD005B:sub": "system:serviceaccount:devops-aurora-1:connections-serviceaccount-s3"
                }
            }
        }
    ]
}

1. Execute the following command to create the role, referencing the above .json file:

aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"

For example,

aws iam create-role --role-name connections-role-test --assume-role-policy-document file://trust-relationship.json --description "testing sa role for pod"

1. Execute the following command to attach the IAM policy to your role:

aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws:iam::$account_id:policy/my-policy

For example,

aws iam attach-role-policy --role-name connections-role-test --policy-arn=arn:aws:iam::aws:policy/AmazonS3FullAccess

1. Execute the following command to annotate your service account with the Amazon Resource Name (ARN) of the IAM role that you want the service account to assume:

kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role

For example,

kubectl annotate serviceaccount -n devops-aurora-1 connections-serviceaccount-s3 eks.amazonaws.com/role-arn=arn:aws:iam::204393242335:role/connections-role-test

1. Confirm that the role and service account are configured correctly by verifying the ouput of the following commands:

aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
aws iam get-role --role-name connections-role-test --query Role.AssumeRolePolicyDocument

1.2 Authorizing for Data Syncs

To ensure that the Connections pod's role has the correct permissions, the role specified by the user in AWS must have its Trusted Relationships configured as such:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"AWS": "<role-arn-created-above>",
				"Service": "s3.amazonaws.com"
			},
			"Action": "sts:AssumeRole"
		}
	]
}

1.3 Confirmation

To confirm that the Connections app is using the service account:

1. Navigate to the cinchy.kubernetes repo > connections/kustomization.yaml file

2. Execute the following:

- op: replace
      path: /spec/template/spec/serviceAccountName
      value: connections-serviceaccount-s3

1. From a terminal, run the below command:

kubectl describe deployment connections-app -n <namespace>

1. The output should look like the following:

1. Overview

Cinchy supports integration with any Identity Provider that issues SAML tokens (e.g. Active Directory Federation Services) for authenticating users.

It follows an SP Initiated SSO pattern where the SP will Redirect to the IdP and the IdP must submit the SAML Response via an HTTP Post to the SP Assertion Consumer Service.

Below is a diagram outlining the flow when a non-authenticated user attempt to access a Cinchy resource (Image 1).

2. Configure SAML Authentication - IIS Deployments

Cinchy must be registered with the Identity Provider. As part of that process you'll supply the Assertion Consumer Service URL, choose a client identifier for the Cinchy application, and generate a metadata XML file.

The Assertion Consumer Service URL for Cinchy is the base URL for the CinchySSO application followed by "{AcsURLModule}/Acs"

e.g. https:///<CinchySSO URL>/Saml2/Acs

e.g. https://myCinchyServer/Saml2/Acs

To enable SAML authentication within Cinchy, follow the below steps:

1. You can find the necessary metadata XML from the applicable identity provider you're using the login against. Place the metadata file in the deployment directory of the CinchySSO web application.

2. Update the values of the below app settings in the CinchySSO appsettings.json file.

• SAMLClientEntityId - The client identifier chosen when registering with the Identity Provider

• SAMLIDPEntityId - The entityID from the Identity Provider metadata XML

• SAMLMetadataXmlPath - The full path to the metadata XML file

• 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 URL>/Saml2/Acs", then the value of this parameter should be "/Saml2"

Once SSO is enabled, the next time a user arrives at the Cinchy login screen they will see an additional button for "Single Sign-On".

3. Configure SAML Authentication - Kubernetes Deployments

1. Retrieve your metadata.xml file from the identity provider you're using the login against.

2. Navigate to your cinchy.kubernetes\environment_kustomizations_template\instance_template\idp\kustomization.yaml file.

3. Add your metadata.xml patch into your secrets where specified below as <<metadata.xml>>

- target:
    version: v1
    kind: Secret
    name: idp-secret-appsettings
  patch: |-
    - op: replace
      path: /data/appsettings.json
      value: <<idp_appsettings_json>>
    - op: add
      path: /data/metadata.xml
      value: <<metadata.xml>>

4. Navigate to your devops.automation > deployment.json in your Cinchy instance.

5. Add the following fields into the .json and update them below using the metadata.xml.

"sso": {
    "SAMLClientEntityId": "cinchy-dev", // Cinchy instance name
    "SAMLMetadataXmlPath": "/usr/share/appsettings/metadata.xml",
    // All below values get from metadata.xml and fill them here.
    "SAMLIDPEntityId": "",
    "SAMLSSOServiceURL": "",
    "AcsURLModule": "",
    "FirstNameExternalClaimName": "",
    "LastNameExternalClaimName": "",
    "EmailExternalClaimName": "",
    "MemberOfExternalClaimName": "",
    "metadata.xml": "BASE64_ENCODED_METADATA.XML"
}

6. Navigate to your kubernetes\environment_kustomizations_template\instance_template_encoded_vars\idp_appsettings_json.

7. Update the below code with your proper AppSettings and ExternalIdentityClaimSection details.

{
    "ConfigSettings": {
        "AppSettings": {
            "SAMLClientEntityId": "<<SAMLClientEntityId>>",
            "SAMLIDPEntityId": "<<SAMLIDPEntityId>>",
            "SAMLMetadataXmlPath": "<<SAMLMetadataXmlPath>>",
            "SAMLSSOServiceURL": "<<SAMLSSOServiceURL>>",
            "AcsURLModule": "<<AcsURLModule>>",
        },
        "ExternalIdentityClaimSection": {
            "FirstName": {
                "ExternalClaimName": "<<FirstNameExternalClaimName>>"
            },
            "LastName": {
                "ExternalClaimName": "<<LastNameExternalClaimName>>"
            },
            "Email": {
                "ExternalClaimName": "<<EmailExternalClaimName>>"
            },
            "MemberOf": {
                "ExternalClaimName": "<<MemberOfExternalClaimName>>"
            }
        }
    }
}

8. Run devops automation script which will populate the updated outputs into the cinchy.kubernetes repo.

9. Commit your changes and push to your source control system.

10. Navigate to your ArgoCD dashboard and refresh the idp-app to pick up your changes. It will also delete your currently running pods in order to pick up the latest secrets.

11. Once the pods are healthy, you can verify the changes by looking for the SSO Tab on your Cinchy login page.

4. User Management

Before a user is able to login through the SSO flow, the user must be set up in Cinchy with the appropriate authentication configuration.

Users in Cinchy are maintained within the Users table in the Cinchy domain. Each user in the system is configured with 1 of 3 Authentication Methods:

• Cinchy User Account - These are users that are created and managed directly in the Cinchy application. They log into Cinchy by entering their username and password on the login screen.

• Non Interactive - These accounts are intended for application use.

• Single Sign-On - These users authenticate through the SSO Identity Provider (configured using the steps above). They log into Cinchy by clicking the "Login with Single Sign-On" link on the login screen.

4.1 How to define a new SSO User

Create a new record within the Users table with the Authentication Method set to "Single Sign-On".

4.2 How to convert an existing user to SSO User

Change the Authentication Method of the existing user to "Single Sign-On".

4.3 Logging in with SSO

Once a user is configured for SSO, they can then click the "Login with Single Sign-On" link on the login page and that will then take them through the Identity Provider's authentication flow and bring them into Cinchy.

5. Automatic User Creation - IIS Deployments

Once SSO has been enabled on your instance of Cinchy, by default, any user that does not exist in the Cinchy Users table will not be able to login regardless if they are authenticated by the Identity Provider.

Enabling Automatic User Creation means that upon login, if the Identity Provider authorizes the user, an entry for this user will automatically be created in the Cinchy Users table if one does not already exist. This means that any SSO authenticated user is guaranteed to be able to access the platform.

In addition to creating a user record, if AD Groups are configured within Cinchy, then the authenticated user will automatically be added to any Cinchy mapped AD Groups where they are a member. See AD Group Integration for additional information on how to define AD Groups in Cinchy.

See below for details on how to enable Automatic User Creation.

5.1 Prerequisites for Automatic User Creation

The Identity Provider configuration must include the following claims in addition to the base configuration in the SAML token response:

• First Name

• Last Name

• Email

In order to enable automatic group assignment for newly created users (which is applicable if you plan on using AD Groups), then you must also include an attribute that captures the groups that this user is a member of (e.g. memberOf field in AD)

5.2 Configuration Setup

Enabling automatic user creation requires the following changes. For IIS Deployments this will be done to the appsettings.json file in the CinchySSO web application.

1. Add ExternalClaimName attribute values under "ExternalIdentityClaimSection" in appsettings.json file. Do not add the value for "MemberOf" if you don't want to enable automatic group assignment .

2. The ExternalClaimName value must be updated to create a mapping between the attribute name in the SAML response and the required field. (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname is the name in the SAML response for the FirstName field)

"ExternalIdentityClaimSection": {
			"FirstName": {
				"ExternalClaimName": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
			},
			"LastName": {
				"ExternalClaimName": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
			},
			"Email": {
				"ExternalClaimName": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
			},
			"MemberOf": {
				"ExternalClaimName": "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
			}
		}

6. Further Reading

• Configuring ADFS

• AD Group Integration

Table of Contents

New Connector

Kafka

We are continuing to improve our Connections offerings, and we now support Kafka as a data sync target in Connections.

Apache Kafka is an end-to-end event streaming platform that:

• Publishes (writes) and subscribes to (reads) streams of events from sources like databases, cloud services, and software applications.

• Stores these events durably and reliably for as long as you want.

• Processes and reacts to the event streams in real-time and retrospectively.

Event streaming thus ensures a continuous flow and interpretation of data so that the right information is at the right place, at the right time for your key use cases.

For information on setting up data syncs with Kafka as a target, please review the documentation here.

New Inbound Data Format for Connections

Apache AVRO

We have also added support for Apache AVRO (inbound) as a data format and added integration with the Kafka Schema Registry, which helps enforce data governance within a Kafka architecture.

Avro is an open source data serialization system that helps with data exchange between systems, programming languages, and processing frameworks. Avro stores both the data definition and the data together in one message or file. Avro stores the data definition in JSON format making it easy to read and interpret; the data itself is stored in binary format making it compact and efficient.

Some of the benefits for using AVRO as a data format are:

• It's compact;

• It has a direct mapping to/from JSON;

• It's fast;

• It has bindings for a wide variety of programming languages.

For more about AVRO and Kafka, read the documentation here.

For information on configuring AVRO in your platform, review the documentation here.

Custom Results in the Network Map

Focus the results of your Network Map to show only the data that you really want to see with our new URL parameters.

You can now add Target Node, Depth Level, and Max Depth Level Parameters, if you choose.

Example: <base url>/apps/datanetworkvisualizer?targetNode=&maxDepth=&depthLevel=

• Target Node: Using the Target Node parameter defines which of your nodes will be the central node from which all connections branch from.

  • Target Node uses the TableID number, which you can find in the URL of any table.

  • Example: <base url>/apps/datanetworkvisualizer?targetNode=8 will show TableID 8 as the central node

• Max Depths: This parameter defines how many levels of network hierarchy you want to display.

  • Example: <base url>/apps/datanetworkvisualizer?maxDepth=2 will only show you two levels of connections.

• Depth Level: Depth Level is a UI parameter that will highlight/focus on a certain depth of connections.

  • Example: <base url>/apps/datanetworkvisualizer?DepthLevel=1 will highlight all first level network connections, while the rest will appear muted.

The below example visualizer uses the following URL: <base url>/apps/datanetworkvisualizer?targetNode=8&maxDepth=2&depthLevel=1

• It shows Table ID 8 ("Groups") as the central node.

• It only displays the Max Depth of 2 connections from the central node.

• It highlights the nodes that have a Depth Level of 1 from the central node.

Enhancements

• We have increased the length of the [Parameters] field in the [Cinchy].[Execution Log] to 100,000 characters.

• Two new parameters are now available to use in real time syncs that have a Cinchy Table as the target. @InsertedRecordIds() and @UpdatedRecordIds() can be used in post sync scripts to insert and update Record IDs respectively, with the desired value input as comma separated list format.

Bug Fixes

• We have fixed a bug that was preventing some new SSO users belonging to existing active directory groups from seeing tables that they should have access to.

• We have fixed a bug where a Webhook would return a 400 error if a JSON body was provided, and the key was in the query parameter of the HTTP request.

GraphQL

• We continue to optimize our GraphQL beta capabilities by improving memory utilization and performance.

Table of Contents

1. Group Management

This section defines how to manage Groups.

1.1 Cinchy Groups

Cinchy Groups are containers that have Users and other Groups within them as members. They are used to provision access controls throughout the platform. Cinchy Groups enable centralized administration for access controls.

Groups are defined in the "Groups" table within the Cinchy domain. By default this table can only be managed by members of the Cinchy Administrators group. Each group has the following attributes:

1.2 How to Define a New AD Group

1. To define a new AD Group, create a new record within the Groups Table with the same name as the AD Group (using the cn attribute).

2. Set the Group Type to "AD Group".

1.3 How to Convert an Existing Group to Sync with AD

1. To convert an existing group, update the Name attribute of the existing group record to match the AD Group (using the cn attribute).

2. Set the Group Type to "AD Group".

2. Group Membership Sync

AD Groups defined in Cinchy have their members synced from AD through a batch process that leverages the Cinchy Command Line Interface (CLI).

2.1 Execution Flow

The sync operation performs the following high-level steps:

1. Fetches all Cinchy registered AD Groups using a Saved Query.

2. Retrieves the usernames of all members for each AD Group. The default attribute for username that is retrieved is "userPrincipalName", but configurable as part of the sync process.

3. For each AD Group, it loads the users that are both a member in AD and exist in the Cinchy Users table (matched on the Username) into the "Users" attribute of the Cinchy Groups table.

2.2 Dependencies

1. The Cinchy CLI Model must be installed in your instance of Cinchy. See here for more details.

2. An instance of the Cinchy CLI must be available to execute the sync.

3. A task scheduler is required to perform the sync on a regular basis (e.g. Autosys).

2.3 Configuration Steps

2.3.1 Create a Saved Query to retrieve AD Groups from Cinchy

1. Create a new query within Cinchy with the below CQL to fetch all AD Groups from the Groups table. The domain & name assigned to the query will be referenced in the subsequent step.

SELECT [Name]
FROM [Cinchy].[Cinchy].[Groups]
WHERE [Group Type] = 'AD Group' 
AND [Deleted] IS NULL

2.3.2 Create the Sync Config

1. Copy the below XML into a text editor of your choice and update the attributes listed in the table below the XML to align to your environment specific settings.

2. Once complete, create an entry with the config in your Data Sync Configurations table (part of the Cinchy CLI model).

<?xml version="1.0" encoding="utf-16" ?>
<BatchDataSyncConfig name="AD_GROUP_SYNC" version="1.0.0" xmlns="http://www.cinchy.co">
  <Parameters />
  <LDAPDataSource objectCategory="group" ldapserver="LDAP:\\activedirectoryserver.domain.com" username="encryptedUsername" password="encryptedPassword" >
    <Schema>
      <Column name="cn" ordinal="1" dataType="Text" maxLength="5000" isMandatory="false" validateData="false" trimWhitespace="true" description=""/>
      <Column name="member.userPrincipalName" ordinal="2" dataType="Text" maxLength="200" isMandatory="false" validateData="false" trimWhitespace="true" description=""/>
    </Schema>
    <Filter>
      lookup('Domain Name','Query Name')
    </Filter>
  </LDAPDataSource>
  <CinchyTableTarget model="" domain="Cinchy" table="Groups" suppressDuplicateErrors="false">
    <ColumnMappings>
      <ColumnMapping sourceColumn="cn" targetColumn="name" />
      <ColumnMapping sourceColumn="member.userPrincipalName" targetColumn="Users" linkColumn="Username" />
    </ColumnMappings>
    <SyncKey>
      <SyncKeyColumnReference name="name" />
    </SyncKey>
	<ChangedRecordBehaviour type="UPDATE" />
    <DroppedRecordBehaviour type="IGNORE" />
  </CinchyTableTarget>
</BatchDataSyncConfig>

2.3.3 Sync Execution & Scheduling

1. The below CLI command (see here for additional information on the syncdata command) should be used to execute the sync.

2. Update the command parameters (described in the table below) with your environment specific settings.

3. Execution of this command can be scheduled at your desired frequency using your scheduler of choice.

dotnet Cinchy.CLI.dll syncdata -s cinchyAppServer -u username -p "encryptedPassword" -m "Model" -f "AD_GROUP_SYNC" -d "TempDirectory" 

Parameters

3. High Number of Groups in ADFS

If you are syncing someone with a lot of ADFS groups, the server may reject the request for the header being too large. If you are able to login as a user with a few groups in ADFS but run into an error with users with a lot of ADFS groups (regardless of if those ADFS groups are in Cinchy), you will need to make the following changes:

3.1 Update the Server Max Request Header Size

1. Follow the instructions outlined in this document.

3.2 CinchySSO App Settings

1. In your CinchySSO app settings, you will also need to increase the max size of the request, as follows:

"AppSettings": {
  ...
  "MaxRequestHeadersTotalSize": {max size in bytes},
  "MaxRequestRequestBufferSize": {max size in bytes, use same as above},
  "MaxRequestBodySize": -1
}

Table of Contents

1. Component Diagram

The below diagram shows a high level overview of Cinchy's Infrastructure components when deploying on IIS.

2. Component Overview

Table of Contents

1. Introduction

This page details the instructions for deployment of Cinchy v5 on Kubernetes. We recommend, and have documented below, that this is done via Terraform and ArgoCD. This setup involves a utility to centralize and streamline your configurations.

The Terraform scripts and instructions provided enable deployment on Azure and AWS cloud environments.

2. Deployment Prerequisites

The following lists are required prerequisites for installing Cinchy v5 on Kubernetes.

Note that some prerequisites will depend on whether you are deploying on Azure or on AWS.

2.1 All Platforms

These prerequisites apply whether you are installing on Azure or on AWS.

• • cinchy.terraform: This repo contains all Terraform configurations.

  • cinchy.argocd: This repo contains all ArgoCD configurations.

  • cinchy.kubernetes: This repo contains cluster and application component deployment manifests.

  • cinchy.devops.automations: This repo contains the single configuration file and binary utility that maintains the contents of the above three repositories.

• You must have a service account with read/write permissions to the git repos created above.

• The following tools should be installed on the machine where the deployment will run:

• You will need a single domain for accessing ArgoCD, Grafana, Opensearch Dashboard, and any deployed Cinchy instances. There are two routing options for accessing these applications - path based or subdomains. See below for an example with multiple cinchy instances:

2.2 Azure Deployment

The following prerequisites are required if you are deployment Cinchy v5 on Azure.

• Terraform Backend Requirements:

  • A resource group that will contain the Azure Blob Storage with the terraform state.

  • A storage account and container (Azure Blob Storage) for persisting terraform state.

• The deployment template has the option of either leveraging an existing resource group or creating a new one:

  • If an existing resource group is preferred, the prerequisite requires the following be provisioned in advance of the deployment:

    • The resource group.

    • A VNet within the resource group.

    • A single subnet. It's important that the address range be sufficient for all executing processes within the cluster, e.g. a CIDR ending with /22 to provide a range of 1024 IPs.

  • If a new resource group is preferred, all resources will be automatically provisioned.

• The quota limit of the Total Regional vCPUs and the Standard DSv3 Family vCPUs (or equivalent) must provide sufficient availability for the required number of vCPUs (minimum of 24).

• An AAD user account to connect to Azure, which has the necessary privileges to create resources in any existing resource groups and the ability to create a resource group (if required).

2.3 AWS Deployment

The following prerequisites are required if you are deployment Cinchy v5 on AWS.

• Terraform Backend Requirements:
• The template has the option of either leveraging an existing VPC or creating a new one:

  • If an existing VPC is preferred, the prerequisite requires the following be provisioned in advance of the deployment:

    • The VPC. It's important that the address range be sufficient for all executing processes within the cluster, e.g. a CIDR ending with /21 to provide a range of 2048 IPs.

    • 3 Subnets (one per AZ). It's important that the address range be sufficient for all executing processes within the cluster, e.g. a CIDR ending with /23 to provide a range of 512 IPs.

    • If the subnets are private, a NAT Gateway is required to enable node group registration with the EKS cluster.

  • If a new VPC is preferred, all resources will be automatically provisioned.

• The limit of the Running On-Demand All Standard vCPUs must provide sufficient availability for the required number of vCPUs (minimum of 24).

• An IAM user account to connect to AWS which has the necessary privileges to create resources in any existing VPC and the ability to create a VPC (if required).

3. Initial Configuration

The following steps detail the instructions for setting up the initial configurations.

3.1 Configure the Deployment.json

1. Navigate to your cinchy.devops.automations repository where you will see an aws.json and azure.json.

2. Depending on the cloud platform that you are deploying to, select the appropriate file and copy it into a new file named deployment.json (or <cluster name>.json) within the same directory.

3. This file will contain the configuration for the infrastructure resources and the Cinchy instances to deploy. Each property within the configuration file has comments in-line describing its purpose along with instructions on how to populate it.

4. Follow the guidance within the file to configure the properties.

5. Commit and push your changes.

3.2 Execute cinchy.devops.automations

This utility updates the configurations in the cinchy.terraform, cinchy.argocd, and cinchy.kubernetes repositories.

1. From a shell/terminal, navigate to the cinchy.devops.automations directory location and execute the following command:

3. The console output should terminate with a "Completed successfully".

4. Terraform Deployment

The following steps detail how to deploy Terraform.

Cinchy.terraform Repo Structure - AWS

If deploying on AWS: Within the Terraform > AWS directory, a new folder named eks_cluster is created. Nested within that is a subdirectory with the same name as the newly created cluster.

To perform terraform operations, the cluster directory must be the working directory during execution. This applies to everything within step 4 of this guide.

Cinchy.terraform Repo Structure - Azure

If deploying on Azure: Within the Terraform > Azure directory, a new folder named aks_cluster is created. Nested within that is a subdirectory with the same name as the newly created cluster.

To perform terraform operations, the cluster directory must be the working directory during execution.

4.1 Cloud Provider Authentication

1. Launch a shell/terminal with the working directory set to the cluster directory within the cinchy.terraform repo.

2. If you are using AWS, run the following commands to authenticate the session:

3. If using Azure, run the following command and follow the on screen instructions to authenticate the session:

4.2 Deploy the Infrastructure

1. Execute the following command to create the cluster:

2. Type yes when prompted to apply the terraform changes.

The resource creation process can take approx. 15-20 minutes. At the end of the execution there will be a section with the following header

======= Output Variables =======

If deploying on AWS, this section will contain 2 values: Aurora RDS Server Host and Aurora RDS Password

If deploying on Azure, this section will contain a single value: Azure SQL Database Password

These variable values are required to update the connection string within the deployment.json file (or equivalent) in the cinchy.devops.automations repo.

4.3 Retrieve the SSH Keys

The following section breaks down how to retrieve your SSH keys for both AWS and Azure deployments.

4.3.1 AWS SSH Keys

1. The SSH key to connect to the Kubernetes nodes is maintained within the terraform state and can be retrieved by executing the following command:

4.3.2 Azure SSH Keys

1. The SSH key is output to the directory containing the cluster terraform configurations.

5. Update the Deployment.json

The following section pertains to updating the Deployment.json file.

5.1 Update the Database Connection String

2. Each object within represents an instance that will be deployed on the cluster. Each instance configuration contains a database_connection_string property. This has placeholders for the host name and password that must be updated using output variables from the previous section.

5.2 Create the IAM User for S3 (AWS Only)

The terraform script will create an S3 bucket for the cluster that must be accessible to the Cinchy application components.

To access this programmatically, an IAM user that has read/write permissions to the new S3 bucket is required. This can be an existing user.

The Access Key and Secret Access Key for the IAM user must be specified under the object_storage section of the deployment.json

5.3 Update Blob Storage Connection Details (Azure Only)

1. Within the deployment.json, the azure_blob_storage_conn_str must be set.

2. The in-line comments outline the commands required to source this value from the Azure CLI.

5.3.1 Enabling Azure Key Vault Secrets

If you have the key_vault_secrets_provider_enabled=true value in the azure.json then the below secrets files would have been created during the execution of step 3.2:

You will need to add the following secrets to your azure key vault:

• worker-secret-appsettings-<cinchy_instance_name>

• web-secret-appsettings-<cinchy_instance_name>

• maintenance-cli-secret-appsettings-<cinchy_instance_name>

• idp-secret-appsettings-<cinchy_instance_name>

• forms-secret-config-<cinchy_instance_name>

• event-listener-secret-appsettings-<cinchy_instance_name>

• connections-secret-config-<cinchy_instance_name>

• connections-secret-appsettings-<cinchy_instance_name>

To create your new secrets:

1. Navigate to your key vault in the Azure portal.

2. Open your Key Vault Settings and select Secrets.

3. Select Generate/Import.

4. On the Create a Secret screen, choose the following values:

   1. Upload options: Manual.

   2. Name: Choose the secret name from the above list. They will all follow the format of: <app>-secret-appsettings-<cinchy_instance_name> or <app>-secret-config-<cinchy_instance_name>

   3. Value: The value for the secret will be the content of each app JSON located in the cinchy.kubernetes\environment_kustomizations\nonprod<cinchy_instance_name>\secrets folder, and as shown in above image.

   4. Content type: JSON

5. Leave the other values to their defaults.

6. Select Create.

Once you receive the message that the first secret has been successfully created, you may proceed to create the other secrets. There are a total of 8 secrets to create as shown in the above list of secret names.

5.4 Execute cinchy.devops.automations

This utility updates the configurations in the cinchy.terraform, cinchy.argocd, and cinchy.kubernetes repositories.

1. From a shell/terminal, navigate to the cinchy.devops.automations directory and execute the following command:

3. The console output should terminate with a "Completed successfully".

4. The updates must be committed to Git before proceeding to the next step.

6. Connect with kubectl

6.1 Update the Kubeconfig

6.1.1 AWS

1. From a shell/terminal run the following command, replacing <region> and <cluster_name> with the accurate values for those placeholders:

6.1.2 Azure

1. From a shell/terminal run the following commands, replacing <subscription_id>, <deployment_resource_group>, and <cluster_name> with the accurate values for those placeholders.

6.2 Verify the Connection

1. Verify that the connection has been established and the context is the correct cluster by running the following command:

7. Deploy and Access ArgoCD

In this step, we will deploy and access ArgoCD.

7.1 Deploy ArgoCD

1. Launch a shell/terminal with the working directory set to the root of the cinchy.argocd repository.

2. Execute the following command to deploy ArgoCD:

3. Monitor the pods within the argocd namespace by running the following command every 30 seconds until they all move into a healthy state:

7.2 Access ArgoCD

1. Launch a new shell/terminal with the working directory set to the root of the cinchy.argocd repository.

2. Execute the following command to access ArgoCD:

This script creates a port forward using kubectl to enable ArgoCD to be accessed at http://localhost:9090

8. Deploy Cluster Components

In this step, you will deploy your cluster components.

8.1 Deploy ArgoCD Applications

1. Launch a shell/terminal with the working directory set to the root of the cinchy.argocd repository.

2. Execute the following command to deploy the cluster components using ArgoCD:

3. Navigate to ArgoCD at http://localhost:9090 and login. Wait until all components are healthy (this may take a few minutes).

8.2 Update the DNS

1. Execute the following command to get the External IP used by the istio ingress gateway.

2. DNS entries must be created using the External IP for any subdomains / primary domains that will be used, including Opensearch, Grafana, and ArgoCD.

8.3 Accessing Opensearch

The default path to access Opensearch, unless you have configured it otherwise in your deployment.json, is <baseurl>/dashboard

8.4 Accessing Grafana

The default path to access Grafana, unless you have configured it otherwise in your deployment.json, is <baseurl>/grafana

9. Deploy Cinchy Components

In this step, you will deploy your Cinchy components.

9.1 Deploy ArgoCD Application

1. Launch a shell/terminal with the working directory set to the root of the cinchy.argocd repository.

2. Execute the following command to deploy the Cinchy application components using ArgoCD:

3. Navigate to ArgoCD at http://localhost:9090 and login. Wait until all components are healthy (may take a few minutes)

10. Troubleshooting

• If ArgoCD Application Sync is stuck waiting for PreSync jobs to complete, you can run the below command to restart the application controller.

1. Overview

In Cinchy v5.2, we implemented the ability to free up database space by using S3 compatible or Azure Blob Storage for file storage. This configuration is set in the deployment.json of a Kubernetes installation, or the appsettings.json of an IIS installation.

2. Kubernetes File Storage

1. If you are using a Kubernetes deployment, you will change your file storage config in the deployment.json.

2. Navigate to the object storage section, where you will see either S3 or Azure Blob storage, depending on your deployment structure.

Azure Example

AWS Example

3. To utilize Blob Storage or S3, update each line with your own parameters.

4. To utilize Local storage, leave each line blank with the exception of the Connections_Storage_Type, which should be set to Local:

5. Run the deployment script by using the following command in the root directory of your devops.automations repo:

6. Commit and push your changes.

3. IIS File Storage

1. If you are using an IIS deployment, you will change your file storage config in the Cinchy Web appsettings file.

2. Locate the StorageType section of the file and set it to either "Local", "AzureBlobStorage" or "S3".

3. If you selected "AzureBlobStorage", fill out the following lines in the same file:

4. If your selected "S3", fill out the following lines in the same file:

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:

1. Disabling your Applications

There may be times when you want to temporarily disable your Kubernetes pods in order to perform maintenance or certain upgrades. You can do so through the following steps:

1. Access your ArgoCD

2. Navigate to the application directory for the namespace you wish to disable, in this case development-cinchy (Image 1). You should see your cluster component applications.

3. Click on the main application (i.e. development-cinchy) (Image 2).

4. Navigate to Summary > Sync Policy > Automated. Click on Disable Auto-Sync > OK (Image 3).

5. For each of the cluster applications that you wish to disable, click on the "..." > Delete (Image 5).

6. Your apps should all appear as "out of sync" (Image 6).

2. Re-enabling your Applications

1. To re-enable your applications, return to the application directory for your disabled namespace (Image 7).

2. Click on the main application (i.e. development-cinchy) (Image 8).

3. Navigate to Summary > Sync Policy. Click on Enable Auto-Sync > OK (Image 9).

1. Upgrading on Kubernetes

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.

1.1 Configuring to the Newest Version

1. Navigate to your cinchy devops.automation repository

   1. Navigate to your deployment.json (You may have renamed this during your original Kubernetes deployment)

   2. 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.

1.2 Apply your Configurations

If your environment is not set-up to automatically apply upon configuration, complete the following the apply the newest version:

1. Navigate to the ArgoCD portal.

2. Refresh your component(s). If that does not work, re-sync.

1. Overview

The sub-pages in this section will refer you to upgrade guides for each Cinchy version. Ensure that you select either IIS Upgrades or Kubernetes Upgrades depending on your deployment type.

1. Upgrading on Kubernetes

When it comes time to upgrade your various components, you can do so by following the below instructions.

2. Prerequisites

• 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.

3. Take your Platform Offline

4. Configuring to the Newest Version

1. Navigate to your cinchy.argocd repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.

2. Navigate to your cinchy.kubernetes repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.

1. Navigate to your cinchy.terraform repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.

2. 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.

3. Open the new Cinchy v5.4 k8s-template.zip file you downloaded from the Cinchy Releases table.

4. 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.

1. Open a shell/terminal from the cinchy.devops.automations directory and execute the following command:

1. Commit all of your changes (if there were any) in each repository.

2. If there were any changes in your cinchy.argocd repository you may need to redeploy ArgoCD.

   1. Launch a shell/terminal with the working directory set to the root of the cinchy.argocd repository.

   2. Execute the following command to deploy ArgoCD:

1. If there were any change to the cluster components, execute the following command from the cinchy.argocd repository:

1. If there were any change to the Cinchy instance, execute the following command from the cinchy.argocd repository:

1. Log in to your ArgoCD application console and refresh the apps to ensure that all changes were picked up.

1.3 Turn your Platform On and Apply your Configurations

1. Overview

The pages under this section can be used to help guide you through an upgrade of your Cinchy instance.

1. Overview

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.

2. Considerations

• Upgrades will also be specified on the applicable 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 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.

3. Prerequisites

• You will need to run this process as a user with admin/dbowner privileges to your database.

• You will need to have installed on the machine that you will run the utility on.

• Retrieve the Upgrade Utility from the

4. Upgrades

5. Upgrade Overviews and Considerations

6. Upgrade Instructions

1. Turn off your Cinchy platform. (Note: This step is only required for the 5.2 upgrade)

   2. In an IIS Deployment:

      1. Open your Windows Services Panel.

      2. Select IIS Admin Service.

      3. Stop the service.

      4. Right-click IIS Admin Service and select Properties.

      5. Change 'Start Up Type' to 'Disabled'.

2. Create a backup snapshot of your platform.
4. 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.

7. If it was turned off in step 1, turn your Cinchy platform back on.

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'.

1. Overview

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.

2. Prerequisites

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.

Upgrading AKS

1. Navigate to your ArgoCD Dashboard.

2. Find and click on your Istio app > disable auto-sync.

3. Find and click on your Istio-ingress app > disable auto-sync.

4. 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.

1. Overview

This page will guide you through how to update your AWS EKS Kubernetes version for your Cinchy v5 platform.

2. Prerequisites

• 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".

3. Considerations

• 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.

4. Upgrade Instructions

1. Navigate to your cinchy.devops.automations\aws-deployment.json file.

2. Change the cluster_version key value to the EKS version you wish to upgrade to. (Example: "1.24")

3. Open a shell/terminal and navigate to the cinchy.devops.automations directory location.

4. Execute the following command:

1. Commit changes for all the repositories (cinchy.argocd, cinchy.kubernetes, cinchy.terraform and cinchy.devops.automation).

2. Open a new shell/terminal and navigate to the cinchy.terraform\aws\eks_cluster\CLUSTER_NAME directory location.

3. Execute the following command:

1. 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.

5. Reinstalling the Metrics Server

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.

1. In a code editor, open the cinchy.terraform\aws\eks_cluster\CLUSTER_NAME\new-vpc.tf or existing-VPC.tf file.

2. Find the enable_metrics_server key and mark its value to false.

3. Open a new shell/terminal and navigate to the cinchy.terraform\aws\eks_cluster\CLUSTER_NAME file.

4. Run the below command to remove metrics server.

1. Revert the enable_metrics_server key value from step 1 to true.

2. Run the below command within the same shell/terminal as step 3 to deploy metrics server with

Overview

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/

Update Instructions

1. 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.

1. 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:

1. Once you have your pod name and resource type, run the below command to open the manifest file in an editor:

1. In the editor, find any instances of k8s.gcr.io and replace it with registry.k8s.io.

2. Save and close the file.

3. Repeat steps 3-5 for the rest of your pods until they are all pointing to the correct registry.