MS Azure private cloud for codeBeamer and Retina

What is this document about?

This guide is about how to create, set up your own Microsoft Azure cloud based codeBeamer or Retina servers. Note that your requirements may vary from the hints and best practices you will find here. The recommended deployment way is SaaS, in which case Intland does the complete setup and hosts the solution in Azure cloud. This document describes how to create the deployment in your own Azure subscription.

Getting started with Microsoft Azure cloud services

In order to deploy codeBeamer/Retina on Azure cloud, you need to have an active Azure pay-as-you-go subscription. All resources are created within this subscription, nothing is deployed on Intland-hosted resources, so you have all the management rights over the deployment. The deployment process is simple and straightforward after completing all the required steps.

Azure security management

Azure cloud security management is ISO/IEC 27001, our deployment uses only built-in security solutions from Azure which are properly validated. We apply all best practices from the open field for running the deployments as secure as possible.

Azure availability regions

Azure regions are listed here. The selected region needs to have premium file shares, Azure DB for MySQL and AKS enabled. For this reason we recommend using West Europe or Germany West Central if you are located in Germany, as this regions are tested and provide the best experience.

Estimating costs

Costs can be calculated in advance using this calculator, which is configured to a reliable codeBeamer setup for 100+ users. The major cost components are the AKS cluster, MySQL DB and file storage. This estimate does not include any discounts, for cost optimization we recommend SaaS hosting by Intland.

Deployment security

The deployment is created in a new virtual network, which is linked to your existing virtual network in Azure. The most common scenario is that the codeBeamer is running in a separate virtual network to which a peering is enabled, so it can also reach services in your virtual network. All resources (storage, key vault, MySQL server, Kubernetes cluster) are located in the automatically created virtual network.

Public IP policy: there are no inbound public IPs enabled in the deployment process. This means the service is not accessible from the open network in any way. The deployment uses private endpoints and a private Kubernetes cluster. There is only a single public IP for outbound traffic, for which a Firewall service can be optionally enabled, so the complete traffic can be monitored to the service.

All created DNS zones are private and only available for the deployment and Kubernetes subnetworks.

Azure cloud deployment

In order to create and access this deployment there needs to be a virtual machine called jumpbox, which is located in the virtual network, from which you will enable access to the newly created cluster. This is management access, the users will not be able to reach this service from the application endpoint.

The deployment location is recommended to be “Germany west central” if you are located in Germany, as this location has all services available.

The above diagram describes the basic server configuration. The connection between your company's on-prem and Azure virtual network might be an Azure ExpressRoute or site2site VPN or simply a point2site VPN connection. You will reach the working instance with this connection without public IPs facing the open internet.

In this deployment scheme there is no connection between Intland and the customer, no VPN tunnel setup is required, as all scripts are standalone and they don't need to access any Intland resources.

Please create a management server "jumpbox" running Ubuntu Linux and follow the steps in the document. This instance is only needed for the deployment and can be set up automatically by the provided scripts. Deployment can be done by either following the attached guide, or doing the setup together with a consultant from Intland Software. There is also an option by authorizing an Intland public key, we can do the complete setup for you in a short period of time.

Set up deployment on Azure automatically

The complete setup and installation is done automatically by the provided scripts. As the runtime environment is hard to setup we provided a Docker image which has both the environment and scripts, so the setup time is minimized and focused. We recommend running all scripts on the cloud VM.

The installation technical document can be found here: Intland_Azure_Private_Deployment_v1_1.pdf

The deployment package can be downloaded from here: intland-azure.zip

The automatically deployed architecture will be this:

The public IP address shown above is only outbound, which is required so that you can get the latest release of codeBeamer or Retina and you can start the required microservices after the service is started. After installation this can be blocked, so that no outbound connection will be enabled.

Configuring LDAP/Active Directory

See LDAP/Active Directory configuration instructions.

Configuring Azure firewall & security

By default the deployment does not have any inbound public IP addresses for security reasons. The Kubernetes subnet is protected by an NSG, which can be configured to access traffic from specific endpoints only. After deployment you may configure an NSG or Azure Firewall to monitor and control the traffic to your instances.

edit

Migrating your data to Azure cloud

The easiest way to migrate your data to Azure cloud is either:

• Do a mysql backup/dump and import to Azure
• Or export using codeBeamer's project export and import on Azure server. Note that project export/import has few known limitations!

Azure SLA

Service level agreements from Azure can be fond on this LINK. The used services are AKS, Azure DB for MySQL, Azure Premium Keyvault, Standard Load Balancer, Azure Firewall, Network Security Groups, Premium File Share. For more information please contact us.

Specific configurations, connecting peers and external users

As it's stated above the instance which is created is only accessible from the virtual network. This is the required behavior as we want to ensure maximum security. If you want to connect your external partners or users to the system, there are several possible solutions. One way is to create a VPN endpoint to which they can connect or simply creating a public IP address with very strict inbound rules is also a solution. More detailed configuration can be found in the attached technical description document.