You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/cloud-services-extended-support/non-vnet-migration.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,17 +1,17 @@
1
1
---
2
2
title: Migrate cloud services not in a virtual network to a virtual network
3
-
description: How to migrate non-vnet cloud services to a virtual network
3
+
description: How to migrate nonvnet cloud services to a virtual network
4
4
ms.topic: how-to
5
5
ms.service: cloud-services-extended-support
6
6
author: hirenshah1
7
7
ms.author: hirshah
8
8
ms.reviewer: mattmcinnes
9
-
ms.date: 01/24/2024
9
+
ms.date: 07/24/2024
10
10
---
11
11
12
12
# Migrate cloud services not in a virtual network to a virtual network
13
13
14
-
Some legacy cloud services are still running without Vnet support. While there's a process for migrating directly through the portal, there are certain considerations that should be made prior to migration. This article walks you through the process of migrating a non Vnet supporting Cloud Service to a Vnet supporting Cloud Service.
14
+
Some legacy cloud services are still running without virtual network support. While there's a process for migrating directly through the portal, there are certain considerations that should be made before migration. This article walks you through the process of migrating a non virtual network supporting Cloud Service to a virtual network supporting Cloud Service.
15
15
16
16
## Advantages of this approach
17
17
@@ -22,10 +22,10 @@ Some legacy cloud services are still running without Vnet support. While there's
22
22
23
23
## Migration procedure using the Azure portal
24
24
25
-
1. Create a non vnet classic cloud service in the same region as the vnet you want to migrate to. In the Azure portal, select the 'Staging' drop-down.
25
+
1. Create a non virtual network classic cloud service in the same region as the virtual network you want to migrate to. In the Azure portal, select the 'Staging' drop-down.
26
26
27
27
28
-
1. Create a deployment with same configuration as existing deployment by selecting 'Upload' next to the staging drop-down. The platform creates a Default Vnet deployment in staging slot.
28
+
1. Create a deployment with same configuration as existing deployment by selecting 'Upload' next to the staging drop-down. The platform creates a Default virtual network deployment in staging slot.
29
29
30
30
31
31
1. Once staging deployment is created, the URL, IP address, and label populate.
@@ -16,7 +16,7 @@ This article describes how to update the role size and instance count in Azure C
16
16
17
17
## Set the allowModelOverride property
18
18
You can set the **allowModelOverride** property to `true` or `false`.
19
-
* When **allowModelOverride** is set to `true`, an API call will update the role size and instance count for the cloud service without validating the values with the .csdef and .cscfg files.
19
+
* When **allowModelOverride** is set to `true`, an API call updates the role size and instance count for the cloud service without validating the values with the .csdef and .cscfg files.
20
20
> [!Note]
21
21
> The .cscfg file will be updated to reflect the role instance count. The .csdef file (embedded within the .cspkg) will retain the old values.
22
22
@@ -27,7 +27,7 @@ The default value is `false`. If the property is reset to `false` after being se
27
27
The following samples show how to set the **allowModelOverride** property by using an Azure Resource Manager (ARM) template, PowerShell, or the SDK.
28
28
29
29
### ARM template
30
-
Setting the **allowModelOverride** property to `true` here will update the cloud service with the role properties defined in the `roleProfile` section:
30
+
Setting the **allowModelOverride** property to `true` here updates the cloud service with the role properties defined in the `roleProfile` section:
31
31
```json
32
32
"properties": {
33
33
"packageUrl": "[parameters('packageSasUri')]",
@@ -55,7 +55,7 @@ Setting the **allowModelOverride** property to `true` here will update the cloud
55
55
56
56
```
57
57
### PowerShell
58
-
Setting the `AllowModelOverride` switch on the new `New-AzCloudService` cmdlet will update the cloud service with the SKU properties defined in the role profile:
58
+
Setting the `AllowModelOverride` switch on the new `New-AzCloudService` cmdlet updates the cloud service with the SKU properties defined in the role profile:
59
59
```powershell
60
60
New-AzCloudService `
61
61
-Name "ContosoCS" `
@@ -72,7 +72,7 @@ New-AzCloudService `
72
72
-Tag $tag
73
73
```
74
74
### SDK
75
-
Setting the `AllowModelOverride` variable to `true` will update the cloud service with the SKU properties defined in the role profile:
75
+
Setting the `AllowModelOverride` variable to `true` updates the cloud service with the SKU properties defined in the role profile:
Cloud Services (extended support) is a new [Azure Resource Manager](../azure-resource-manager/management/overview.md) based deployment model for [Azure Cloud Services](https://azure.microsoft.com/services/cloud-services/) product and is now generally available. Cloud Services (extended support) has the primary benefit of providing regional resiliency along with feature parity with Azure Cloud Services deployed using Azure Service Manager. It also offers some ARM capabilities such as role-based access and control (RBAC), tags, policy, and supports deployment templates.
14
+
Cloud Services (extended support) is a new [Azure Resource Manager](../azure-resource-manager/management/overview.md) based deployment model for [Azure Cloud Services](https://azure.microsoft.com/services/cloud-services/) product and is now generally available. Cloud Services (extended support) has the primary benefit of providing regional resiliency along with feature parity with Azure Cloud Services deployed using Azure Service Manager. It also offers some Azure Resource Manager capabilities such as role-based access and control (RBAC), tags, policy, and supports deployment templates.
15
15
16
-
With this change, the Azure Service Manager based deployment model for Cloud Services will be renamed [Cloud Services (classic)](../cloud-services/cloud-services-choose-me.md). You will retain the ability to build and rapidly deploy your web and cloud applications and services. You will be able to scale your cloud services infrastructure based on current demand and ensure that the performance of your applications can keep up while simultaneously reducing costs.
16
+
With this change, the Azure Service Manager based deployment model for Cloud Services is renamed to [Cloud Services (classic)](../cloud-services/cloud-services-choose-me.md). You retain the ability to build and rapidly deploy your web and cloud applications and services. You're able to scale your cloud services infrastructure based on current demand and ensure that the performance of your applications can keep up while simultaneously reducing costs.
17
17
18
18
:::image type="content" source="media/inside-azure-for-iot.png" alt-text="YouTube video for Cloud Services (extended support)." link="https://youtu.be/H4K9xTUvNdw":::
19
19
20
20
21
-
## What does not change
21
+
## What doesn't change
22
22
- You create the code, define the configurations, and deploy it to Azure. Azure sets up the compute environment, runs your code then monitors and maintains it for you.
23
23
- Cloud Services (extended support) also supports two types of roles, [web and worker](../cloud-services/cloud-services-choose-me.md). There are no changes to the design, architecture, or components of web and worker roles.
24
-
- The three components of a cloud service, the service definition (.csdef), the service config (.cscfg), and the service package (.cspkg) are carried forward and there is no change in the [formats](cloud-services-model-and-package.md).
24
+
- The three components of a cloud service, the service definition (.csdef), the service config (.cscfg), and the service package (.cspkg) are carried forward and there's no change in the [formats](cloud-services-model-and-package.md).
25
25
- No changes are required to runtime code as data plane is the same and control plane is only changing.
26
26
- Azure GuestOS releases and associated updates are aligned with Cloud Services (classic)
27
27
- Underlying update process with respect to update domains, how upgrade proceeds, rollback and allowed service changes during an update don't change
28
28
29
29
## Changes in deployment model
30
30
31
-
Minimal changes are required to Service Configuration (.cscfg) and Service Definition (.csdef) files to deploy Cloud Services (extended support). No changes are required to runtime code. However, deployment scripts will need to be updated to call the new Azure Resource Manager based APIs.
31
+
Minimal changes are required to Service Configuration (.cscfg) and Service Definition (.csdef) files to deploy Cloud Services (extended support). No changes are required to runtime code. However, deployment scripts need to be updated to call the new Azure Resource Manager based APIs.
32
32
33
33
:::image type="content" source="media/overview-image-1.png" alt-text="Image shows classic cloud service configuration with addition of template section. ":::
34
34
35
35
The major differences between Cloud Services (classic) and Cloud Services (extended support) with respect to deployment are:
36
36
37
-
- Azure Resource Manager deployments use [ARM templates](../azure-resource-manager/templates/overview.md), which is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for your project. The template uses declarative syntax, which lets you state what you intend to deploy without having to write the sequence of programming commands to create it. Service Configuration and Service definition file needs to be consistent with the [ARM Template](../azure-resource-manager/templates/overview.md) while deploying Cloud Services (extended support). This can be achieved either by [manually creating the ARM template](deploy-template.md) or using [PowerShell](deploy-powershell.md), [Portal](deploy-portal.md) and [Visual Studio](deploy-visual-studio.md).
37
+
- Azure Resource Manager deployments use [ARM templates](../azure-resource-manager/templates/overview.md), which is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for your project. The template uses declarative syntax, which lets you state what you intend to deploy without having to write the sequence of programming commands to create it. Service Configuration and Service definition file needs to be consistent with the [ARM Template](../azure-resource-manager/templates/overview.md) while deploying Cloud Services (extended support). This can be achieved either by [manually creating the ARM template](deploy-template.md) or using [PowerShell](deploy-powershell.md), [Portal](deploy-portal.md), and [Visual Studio](deploy-visual-studio.md).
38
38
39
-
- Customers must use [Azure Key Vault](../key-vault/general/overview.md) to [manage certificates in Cloud Services (extended support)](certificates-and-key-vault.md). Azure Key Vault lets you securely store and manage application credentials such as secrets, keys and certificates in a central and secure cloud repository. Your applications can authenticate to Key Vault at run time to retrieve credentials.
39
+
- Customers must use [Azure Key Vault](../key-vault/general/overview.md) to [manage certificates in Cloud Services (extended support)](certificates-and-key-vault.md). Azure Key Vault lets you securely store and manage application credentials such as secrets, keys, and certificates in a central and secure cloud repository. Your applications can authenticate to Key Vault at run time to retrieve credentials.
40
40
41
-
- All resources deployed through the [Azure Resource Manager](../azure-resource-manager/templates/overview.md) must be inside a virtual network. Virtual networks and subnets are created in Azure Resource Manager using existing Azure Resource Manager APIs and will need to be referenced within the NetworkConfiguration section of the .cscfg when deploying Cloud Services (extended support).
41
+
- All resources deployed through the [Azure Resource Manager](../azure-resource-manager/templates/overview.md) must be inside a virtual network. Virtual networks and subnets are created in Azure Resource Manager using existing Azure Resource Manager APIs. They need to be referenced within the NetworkConfiguration section of the .cscfg when deploying Cloud Services (extended support).
42
42
43
-
- Each cloud service (extended support) is a single independent deployment. Cloud services (extended support) does not support multiple slots within a single cloud service.
43
+
- Each cloud service (extended support) is a single independent deployment. Cloud Services (extended support) doesn't support multiple slots within a single cloud service.
44
44
- VIP Swap capability may be used to swap between two cloud services (extended support). To test and stage a new release of a cloud service, deploy a cloud service (extended support) and tag it as VIP swappable with another cloud service (extended support)
45
45
46
46
- Domain Name Service (DNS) label is optional for a cloud service (extended support). In Azure Resource Manager, the DNS label is a property of the Public IP resource associated with the cloud service.
@@ -53,9 +53,9 @@ Cloud Services (extended support) provides two paths for you to migrate from [Az
53
53
54
54
### Additional migration options
55
55
56
-
When evaluating migration plans from Cloud Services (classic) to Cloud Services (extended support) you may want to investigate additional Azure services such as: [Virtual Machine Scale Sets](../virtual-machine-scale-sets/overview.md), [App Service](../app-service/overview.md), [Azure Kubernetes Service](../aks/intro-kubernetes.md), and [Azure Service Fabric](../service-fabric/service-fabric-overview.md). These services will continue to feature additional capabilities, while Cloud Services (extended support) will primarily maintain feature parity with Cloud Services (classic.)
56
+
When evaluating migration plans from Cloud Services (classic) to Cloud Services (extended support), you may want to investigate other Azure services such as: [Virtual Machine Scale Sets](../virtual-machine-scale-sets/overview.md), [App Service](../app-service/overview.md), [Azure Kubernetes Service](../aks/intro-kubernetes.md), and [Azure Service Fabric](../service-fabric/service-fabric-overview.md). These services continue to feature additional capabilities, while Cloud Services (extended support) maintains feature parity with Cloud Services (classic.)
57
57
58
-
Depending on the application, Cloud Services (extended support) may require substantially less effort to move to Azure Resource Manager compared to other options. If your application is not evolving, Cloud Services (extended support) is a viable option to consider as it provides a quick migration path. Conversely, if your application is continuously evolving and needs a more modern feature set, do explore other Azure services to better address your current and future requirements.
58
+
Depending on the application, Cloud Services (extended support) may require substantially less effort to move to Azure Resource Manager compared to other options. If your application isn't evolving, Cloud Services (extended support) is a viable option to consider as it provides a quick migration path. Conversely, if your application is continuously evolving and needs a more modern feature set, do explore other Azure services to better address your current and future requirements.
59
59
60
60
## Next steps
61
61
- Review the [deployment prerequisites](deploy-prerequisite.md) for Cloud Services (extended support).
0 commit comments