Deployment Prerequisites
This page details various prerequisites for deploying Cinchy v5.

Table of Contents

1. General Kubernetes Deployment Prerequisites

The following is a list of steps that are required prior to deploying Cinchy v5 on Kubernetes.

1.1 Download your Tools

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

1.2 Creating your Domains

All of your Cinchy environments will need a domain for each of the following:
  • ArgoCD
  • Opensearch
  • Grafana

1.3 SSL Certs

You will need to have valid SSL Certs ready when you deploy Cinchy v5. This should be a wildcard certificate if ArgoCD will be exposed via a subdomain (preferred). Without the wildcard certificate, accessing ArgoCD's portal requires a port forward to be created using kubectl on demand.
You also have the option to use Self-Signed Certs in Kubernetes deployments. Find more information here.

1.4 Secrets Management

Secrets management is optional, however Cinchy recommends it for securely storing and accessing secrets that will be used in the deployment process. Cinchy currently supports:

1.5 Single Sign-On

This is optional, but if you would like to set up single sign-on for use in your Cinchy v5 environments, please review the documentation here.

1.6 Docker Images

You have the option to either use Cinchy's Docker images or your own. If you would like to use Cinchy's, please follow the section below to access them.

1.6.1 Accessing Cinchy's Docker images

You will pull Docker images from Cinchy's AWS Elastic Container Registry (ECR).
To gain access to Cinchy's Docker images, you will need login credentials to the ECR. You can gain these by contacting Cinchy Support.

1.7 Create your Repositories

The following four Git repositories must be created. Any source control platform supporting Git may be used, e.g. Gitlab, Azure DevOps, Github
  • 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.

1.8 Access to Cinchy Artifacts

You will need to access and download the Cinchy artifacts prior to deployment.
To access the Kubernetes artifacts:
  1. 1.
    Access the Cinchy Releases table
  2. 2.
    Navigate to the release you wish to deploy
  3. 3.
    Download the .zip file(s) listed under the Kubernetes Artifacts column
  4. 4.
    Check the contents of each of the directories into their respective repository.
Please contact Cinchy Support if you are encountering issues accessing the table or the artifacts.

2. Kubernetes Deployments (Azure Specific Requirements)

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 Azure CLI should be installed on the machine where the deployment will be run. It must be set to the correct profile/login
  • 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).

3. Kubernetes Deployments (AWS Specific Requirements)

The following prerequisites are required if you are deployment Cinchy v5 on AWS.
  • Terraform Backend Requirements:
    • An S3 bucket that will contain the terraform state.
  • The AWS CLI should be installed on the machine where the deployment will be run. It must be set to the correct profile/login
  • 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).
  • The SSL certificate must be imported into AWS Certificate Manager (or a new certificate can be requested via AWS Certificate Manager).

4. IIS Deployment Prerequisites

The following is a list of steps that are required prior to deploying Cinchy v5 on IIS

4.1 Access the Artifacts

You will need to access and download the Cinchy binary prior to deployment:
Please contact Cinchy Support if you are encountering issues accessing the table or the artifacts.

4.2 General Requirements

  1. 1.
    An instance of SQL Server 2012+
  2. 2.
    A Windows Server 2012+ machine with IIS 7.5+ installed
    Install these IIS features in addition to the defaults:
    • Application Development Features:
      • ASP.NET 3.5
      • ASP.NET 4.7
    • Common HTTP Features
      • HTTP Redirection
    • Health & Diagnostics
      • Request Monitor
    • Performance Features
      • Dynamic Content Compression
    • Web Management Tools
      • IIS Management Scripts and Tools
      • IIS Management Service
  3. 3.
    Install .Net Framework 4.7.2 on the server
  4. 4.
    Install .net core Hosting bundle Version 3.1 - https://www.microsoft.com/net/download/dotnet-core/3.1
Cinchy Platform 4.18.0+ uses .NET Core 3.1, previous versions use .NET Core 2.1

4.3 System Requirements

Minimum Web Server Hardware Recommendations
  • 2 x 2 GHz Processor
  • 8 GB RAM
  • 4 GB Hard Disk storage available
Minimum Database Server Hardware Recommendations
  • 4 x 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 overall storage requirements.

4.4 Clustering

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 immediately be known to other nodes without establishing connectivity between them. For this reason the nodes must be able to communicate over either http or https through an IP based binding on the IIS server that allows cache expiration messages to be broadcast. The port used for this communication is different from the standard port that is 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.

4.5 Scaling Considerations

The web application is responsible for 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 fairly low as caching is limited to metadata, but the CPU utilization grows with request volume and complexity (e.g. insert / update operations are more complex than select operations). As the user population grows or request volume increases from batch processes / upstream system API calls 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 from batch processes / upstream system API calls the system may require additional CPU / Memory. Starting off in an environment that allows flexibility (e.g. a VM) would be advised until the real world load can be profiled and a configuration established. 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.

4.6 Backups

Outside of log files there is no other data generated & stored on the web servers by the application, which means backups are generally centered around the database. Since the underlying persistence platform is a MS SQL Server, this relies on standard procedures for this platform.