How ReleaseHub Works

Search…
This guide is a deep technical discussion of how ReleaseHub Environments as a Service and Private Applications work when deployed into your cloud account. The examples below mostly refer to AWS but full support for other clouds is available.
Prerequisites
You should have some familiarity with the other pages in the advanced section such as using-datadog-to-monitor-your-release-clusters, Broken link, and Configure access to your K8s cluster​
Step 1, Choose a Base Domain
ReleaseHub environments get deployed underneath a subdomain for isolation and ease of deployment. Typically, ReleaseHub environments get deployed into a subdomain like release.example.com where multiple environments would be reachable as serviceA-envA.release.example.com and serviceB-envA.release.example.com.
Another configuration that is common is to have so-called Wildcard Domains for both preproduction and production environments so that, for example *.service-A-envA.release.example.com and *.staging.example.com would work. The typical use-case for these environments is for categories or languages, for example, allowing us.staging.example.com or shoes.qa.example.com to work.
In the case of a private application deployed into a customer account, let's say that the application is called shoes and the customer is called buyer and the shopping website is shopping.com. Then the customer's private application URLs would usually be of the form shoes-buyer.release.shoppping.com. Custom domains of the form shoes.buyer.com would need an External DNS configuration as documented in that section.
It is possible in advanced configurations to have preproduction applications deployed into one subdomain (*.release.example.com) and production or staging environments deployed directly as www.example.com or staging.example.com as examples.
In any of the above cases, the configuration is handled by the Hostname field in the application template, which applies in either EAAS or Private Application templates.
Step 2, Spin up a Kubernetes Cluster
One of the most freeing parts of using ReleaseHub is that environments and applications can be deployed without any underlying knowledge of the actual infrastructure that is required to run release. In case you do want to peek under the hood, however, we can tell you how we deploy clusters across cloud providers and regions.
1.ReleaseHub offers several Cloud Integrations that allow our platform the ability to deploy code to your accounts. These integrations gain credentials that authorise ReleaseHub to build infrastructure and deploy applications to your cluster. In the case of AWS and GovCloud, a CloudFormation Template creates an IAM role which securely allows our production account credentials to build and deploy infrastructure and code to your account. In the case of GCP, a project credential file allows ReleaseHub to build and deploy code into the project of your choice.
2.For EAAS customers, a Cloud Integration can be configured for each cloud provider account, allowing customers to deploy across clouds and regions.
3.For Private Application customers, a Landing Page is designed for each installation which gains access to the customers' cloud account(s) so the application can be deployed into their account(s).
4.Given secure access to the cloud account, ReleaseHub then spins up all the necessary buckets, Kubernetes cluster(s), and supporting infrastructure needed to support your application. In the case of AWS, several services are used including EKS, ECR, S3, Route53, VPC, RDS, DynamoDB, RDS, CloudFront, ALB, and more. In the case of GCP, several services are used including Container Engine, Container Registry, Google Cloud Virtual Network, Cloud Load Balancing, Cloud DNS, Cloud Storage, and Cloud SQL.
An example diagram of an AWS Cloudformation template for an EKS cluster in ReleaseHub
Step 3, Deploy an Application
ReleaseHub environments are all built from an Application Templatewhich allows many versions of an application to be run simultaneously in a complete stack. This allows multiple branches of code and ideas to be tested and viewed in parallel. Since the development application templates vary only slightly in terms of Environment Variables, the production deployment of applications becomes straightforward. And since multiple production environments differ only slightly from each other for individual customer needs, Private Applications allow different customers the ability to run their own version of an application directly in their own accounts for privacy, regulatory, or security requirements.
Step 4, Request SSL Certificates
ReleaseHub uses AWS Certificate Manager (ACM) with DNS Validation enabled to quickly issue secure SSL certificates for applications. This process is normally transparent if the Subdomain for the EAAS or Private Application is configured in Route53 in the same account and the zone is publicly available. However, there are cases where some exceptions will need to be made to validate the certificates manually:
1.For AWS GovCloud accounts at the time of this writing, Route53 has private-zone-only support. Therefore, the ReleaseHub UI will print out the validation records to be inserted into the public zone to validate the certificate request. A DNS CNAME record will be created and once propagated, ACM will validate the certificate.
2.Similarly, for AWS or GCP accounts with private zones created (for security or VPN access) will need to copy the validation records from the ReleaseHub UI and create a DNS CNAME record in the public zone.
3.In the rare case where public DNS zones do not exist for some reason, a fake public zone can be created just to validate CNAME records. This is not recommended but it can work for obscure use cases as long as the DNS domain is registered, owned by the end user, and valid.
For any of the exceptions listed above, details will be provided for you via our support team.
Step 5, Configure Access to Your Datastores and Services
Because ReleaseHub applications and environments are deployed into a customer cloud account, the application(s) can be granted secure access to resources within the cloud account. In the case of AWS, several options exist as shown in the table below. In the case of GCP, several options are listed in the table below that.
AWS Access Resource
Method
ReleaseHub Support
VPN
VPN Gateway
Manually configured
VPN/VPC Networking
Transit Gateway
Automatic
VPC Networking
VPC Peering
Manually configured
RDS Instances
VPC Peering
Manually configured
AWS Services
Role Sessions
Terraform, Pulumi, etc.
GCP Access Resource
Text
ReleaseHub Support
VPC Networking
VPC Network Peering
Manually configured
Cloud DB
Instance Level Access
Manually configured
VPN
Cloud VPN
Manually configured
Step 6, Monitor and Maintain Your Applications
ReleaseHub handles all of the administration, support, upgrades, and smooth functioning of the infrastructure dedicated to running your applications. However, many customer want more visibility into the infrastructure for cost analysis, auditing, performance, or reliability reasons. And why not, the application is running inside the customer's own account! There are several options available for each use case, we recommend the following.
Visibility Required
Vendors or Technologies
ReleaseHub Support
Application Performance Monitoring (APM)
Datadog, New Relic
Kubernetes Agents
Metrics Collection
Datadog, Cloudwatch, Stackdriver
Kubernetes Agents and Integrations
Log Collection and Analysis
Datadog, ELK, JournalD, ReleaseHub UI
Kubernetes Agents and Integrations
Kubernetes drivers
Lens, K9s, Kubectl, Eksctl, Cloudshell
CLI and API
Shell access to Pods and Containers
Lens, K9s, Kubectl, Cloudshell, ReleaseHub UI
CLI and API
Alerting and Reportin
Datadog, New Relic
Kubernetes Agents
Network Traffic Analysis and Reporting
Datadog, Thousand Eyes
Kubernetes Agents
Step 7, Customise Your DNS Entries
ReleaseHub environments can be run on any valid zone if certificates and DNS records exist. Read Broken link​
Patch
Next - Frequently Asked Questions
AWS Support FAQs
Last modified 7d ago
Copy link
Outline
Prerequisites
Step 1, Choose a Base Domain
Step 2, Spin up a Kubernetes Cluster
Step 3, Deploy an Application
Step 4, Request SSL Certificates
Step 5, Configure Access to Your Datastores and Services
Step 6, Monitor and Maintain Your Applications
Step 7, Customise Your DNS Entries