Prerequisites
Before you deploy Self-Hosted Deployment to Microsoft Azure
阅读时间5 分钟最后更新于 1 个月前
To deploy Unity Cloud Services to Microsoft Azure, you must have an Azure account and a role with sufficient permissions to create and manage resources.
Before you start deploying Self-Hosted Deployment, complete the following steps.
1. Prepare deployment on Unity's side
Perform these steps on Unity's side:
-
Collect the username and the password for the central Azure Container Registry (ACR) that is managed by Unity.
-
Collect the following licenses:
- Unity Asset Transformer SDK license, in an .xml file
- Unity Asset Transformer SDK license for 3D data streaming;, in an .xml file
- Unity Version Control (UVCS) license, in a string that contains the base64-encoded license key
A valid Unity Asset Transformer license is required for all users who perform asset transformations. The platform uses static licenses, so a floating license server is not required. -
Request the Unity team to create a private offer in Azure Marketplace and make it available for the customer's Azure billing account. The public offer that is visible to everyone isn't intended for real deployments, as stated in its description.
2. Prepare deployment on the client's side
Perform these steps on the client's side:
2.1 Prepare the project name prefix
Prepare the project name prefix with these characteristics:
- The prefix is a string.
- The prefix contains at most six characters.
- The prefix contains only lowercase alphanumeric characters, but no underscores or dashes.
2.2 Collect an IP range for the virtual network
For the full deployment mode
If you chose the full deployment mode, collect an IP range for the virtual network (VNet) that hosts the solution. The recommended size of the VNet is /21.
From that range, a subnet of /22 in size is dedicated to the Azure Kubernetes Service (AKS) cluster, to provide enough address space for the pods.
If the solution VNet is to be connected to the corporate network, then this range must not overlap with any other ranges of the customer environment where clients will reside.
Subsequently, you can peer this VNet with the hub and route it to or from the corporate network.
For the BYO VNet mode
If you chose the BYO VNet mode, collect the IP range of the precreated VNet that is to host the solution. The IP size of the VNet must be sufficient to accommodate the subnets listed further.
If the solution VNet is to be connected to the corporate network, then this range must not overlap with any other ranges of the customer environment where clients reside.
This VNet must contain these subnets:
|
|
|
|---|---|---|
aks-snet | At least /25 | Enable service endpoints for these resource types:
|
postgres-snet | At least /28 | Delegate this subnet to this resource type:
Enable service endpoints for this resource type:
|
private-endpoints-snet | At least /28 | If required for network security groups (NSGs) and route tables, enable the network policy for private endpoints. |
cont-ins-snet | At least /28 | Delegate this subnet to this resource type:
Enable service endpoints for this resource type:
|
注意
It is crucial to enable service endpoints as described. If this configuration is missing, deployment fails and reports errors that aren't relevant to the root cause.
For this VNet, keep the DNS setting at its default value, which is the Azure-provided DNS service.
For the service principal , which is owned by Microsoft, assign the following roles to the resource group where the VNet, NSGs, and route tables reside:
Managed Applications On Behalf Application- Network Contributor
- User Access Administrator, with the option Allow user to assign all roles except privileged administrator roles
After deployment completion, you can remove these role assignments.
2.3 Collect the IP ranges for the pods and services
Collect the IP ranges for the pods and services, in Classless Inter-Domain Routing ranges (CIDR) notation.
The offer UI requests only the network addresses. The network masks are hard-coded:
- /16 for pods
- /22 for services
If the solution VNet is to be connected to the corporate network, then these ranges must not overlap with any other ranges of the customer environment where clients will reside.
These IP ranges are set by default:
- 172.29.0.0/16 for pods
- 172.28.0.0/22 for services
2.4 Collect the fully qualified domain name
Collect the fully qualified domain name (FQDN) of the domain to be used to access Self-Hosted Deployment. After deployment, the relevant DNS record is created in the internal DNS. Read more about postdeployment.
2.5 Prepare the TLS certificate and the private key
Collect the following information in .pem format:
- A TLS certificate for the selected domain name, and issued by a certification authority (CA) that is trusted by the clients who access Self-Hosted Deployment
- The corresponding private key
注意
You can configure this certificate in the DNS and TLS settings during deployment or change it afterwards.
2.6 Prepare the Azure subscription
Prepare your Azure subscription for deployment:
-
Adjust the resource quotas. Read more about deployment size in the deployment procedure.
-
Register the following resource providers for the subscription if they haven't yet been automatically registered during subscription provisioning:
- Microsoft.Network
- Microsoft.Storage
- Microsoft.KeyVault
- Microsoft.ManagedIdentity
- Microsoft.ContainerService
- Microsoft.KubernetesConfiguration
- Microsoft.DBforPostgreSQL
- Microsoft.EventHub
- Microsoft.Insights
- Microsoft.OperationalInsights
- Microsoft.OperationsManagement
- Microsoft.ServiceBus
The recommended practice is to assign the following roles to Self-Hosted Deployment administrators for the subscription for which the solution is to be deployed:
- The Azure Kubernetes Service RBAC Cluster Admin role, which is required to manage the AKS cluster
- The Key Vault Administrator role, which is required to manage the secrets in the key vault
Alternatively, you can assign these roles to the solution resource group after deployment.
2.8 Prepare the VNet and the subnet
Prepare the VNet and the subnet to which you will connect the private endpoint to the Azure Private Link services of the solution. The VNet must already exist in the customer environment that is routed to and from the corporate network. The VNet can reside in any subscription.