Deployment prerequisites
This page details various prerequisites for deploying Cinchy v5.
Last updated
Was this helpful?
This page details various prerequisites for deploying Cinchy v5.
Last updated
Was this helpful?
Before deploying Cinchy v5 on Kubernetes, you must follow the steps listed below.
Install the following tools on the machine where the deployment will run:
(v1.23.0+)
(You can also use on Windows)
All your Cinchy environments will need a domain for each of the following:
ArgoCD
OpenSearch
Grafana
Do this through your specific domain registrar. For example, GoDaddy or Google Domains.
You must have valid SSL Certs ready when you deploy Cinchy v5. Cinchy recommends using a wildcard certificate if ArgoCD will be exposed via a subdomain. Without the wildcard certificate, you must create a port forward using kubectl on demand to access ArgoCD's portal.
Although optional, Cinchy strongly recommends secret management for storing and accessing secrets that you use in the deployment process. Cinchy currently supports:
You can use Cinchy Docker images or your own. If you would like to use Cinchy images, please follow the section below to access them.
You will pull Docker images from Cinchy's AWS Elastic Container Registry (ECR).
cinchy.terraform: Contains all Terraform configurations.
cinchy.argocd: Contains all ArgoCD configurations.
cinchy.kubernetes: Contains cluster and application component deployment manifests.
cinchy.devops.automations: 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 repositories created above.
You will need to access and download the Cinchy artifacts before deployment.
To access the Kubernetes artifacts:
Navigate to the release you wish to deploy.
Download the .zip file(s) listed under the Kubernetes Artifacts column.
Please contact Cinchy Support if you are encountering issues accessing the table or the artifacts.
If you are deploying Cinchy v5 on Azure, you require the following:
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 two options available:
Use an existing resource group.
Creating a new one.
If you prefer an existing resource group, you must provision the following before the deployment:
The resource group.
A VNet within the resource group.
A single subnet. It's important that the address range be enough for all executing processes within the cluster, such as a CIDR ending with /22 to provide a range of 1024 IPs.
If you prefer a new resource group, all resources will be automatically provisioned.
The quota limit of the Total Regional vCPUs and the Standard DSv3 Family vCPUs (or equivalent) must offer enough 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).
If you are deploying Cinchy v5 on AWS, you require the following:
The template has two options available:
Use an existing VPC.
Create a new one.
If you prefer an existing VPC, you must provision the following before the deployment:
The VPC. It's important that the address range be enough for all executing processes within the cluster, such as 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 enough for all executing processes within the cluster, such as 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 you prefer a new VPC, all resources will be automatically provisioned.
The limit of the Running On-Demand All Standard vCPUs must offer enough 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).
You must import the SSL certificate into AWS Certificate Manager (or a new certificate can be requested via AWS Certificate Manager).
Before deploying Cinchy v5 on IIS, you require the following:
You need to access and download the Cinchy binary before deployment:
Navigate to the release you wish to deploy
Download the files listed under the Component Artifacts column. This should include zip files for:
Cinchy Platform
An instance of SQL Server 2017+
A Windows Server 2012+ machine with IIS 7.5+ installed
Specifically, install: ASP.NET Core/.NET Core Runtime & Hosting Bundle
2 × 2 GHz Processor
8 GB RAM
4 GB Hard Disk storage available
4 × 2 GHz Processor
12 GB RAM
Hard disk storage dependent upon use case. Note that Cinchy maintains historical versions of data and performs soft deletes which will add to the storage requirements.
Clustering considerations are applicable to both the Web and Database tiers in the Cinchy deployment architecture.
The web tier can be clustered by introducing a load balancer and scaling web server instances horizontally. Each node within Cinchy uses an in-memory cache of metadata information, and expiration of cached elements is triggered upon data changes that would impact that metadata. Data changes processed by one node wouldn't be known to other nodes without establishing connectivity between them. The nodes must be able to communicate over either HTTP or HTTPS through an IP based binding on the IIS server that allows the broadcast of cache expiration messages. The port used for this communication is different from the standard port that's used by the application when a domain name is involved. Often for customers this means that a firewall port must be opened on these servers.
The database tier relies on standard MS SQL Server failover clustering capabilities.
The web application oversees all interactions with Cinchy be it through the UI or connectivity from an application. It interprets/routes incoming requests, handles serialization/deserialization of data, data validation, enforcement of access controls, and the query engine to transform Cinchy queries into the physical representation for the database. The memory footprint for the application is low, as caching is limited to metadata, but CPU use grows with request volume and complexity(For example, insert/update operations are more complex than select operations). As the user population grows or request volume increases, there may be a need to add nodes.
The database tier relies on a persistence platform that scales vertically. As the user population grows and request volume increases, the system may require additional CPU / Memory. Cinchy recommends you start off in an environment that allows flexibility (such as a VM) until you can profile the real-world load and establish a configuration. On the storage side, Cinchy maintains historical versions of records when changes are made and performs soft deletes of data which will add to the storage requirements. The volume of updates occurring to records should be considered when estimating the storage size.
Outside of log files there is no other data generated & stored on the web servers by the application, which means backups are centered around the database. Since the underlying persistence platform is a MS SQL Server, this relies on standard procedures for this platform.
You also have the option to use Self-Signed Certs in Kubernetes deployments. Find more information
If you would like to set up single sign-on for use in your Cinchy v5 environments, .
To gain access to Cinchy's Docker images, you need login credentials to the ECR. Contact for access.
You must create the following four Git repositories. You can use any source control platform that supports Git, such as , , or .
Access the table. Please contact if you don't have the access credentials necessary.
Check the contents of each of the directories into their
Install the on the deployment machine. It must be set to the correct profile/login
that will contain the terraform state.
Install the on the deployment machine. It must be set to the correct profile/login
You must import the SSL certificate , or a new certificate can be requested via
If you are importing it, you will need the PEM-encoded certificate body and private key. You can find this, you can get the PEM file from your chosen domain provider (GoDaddy, Google, etc.)
Access the table. Please contact if you don't have the access credentials necessary.
(optional)
(optional)
Please contact if you are encountering issues accessing the table or the artifacts.