Compartir a través de

Cambios posteriores a la migración

  • Artículo

La implementación de Cloud Services (clásico) se convierte en una implementación de Cloud Services (soporte extendido). Para obtener más información, consulte Documentación de Cloud Services (soporte extendido).

Cambios en los archivos de implementación

Se realizan cambios menores en los archivos .csdef y .cscfg del cliente para que los archivos de implementación cumplan con los requisitos de Azure Resource Manager y Cloud Services (soporte extendido). Después de la migración, recupera los nuevos archivos de implementación o actualiza los archivos existentes, que son necesarios para las operaciones de actualización y eliminación.

  • Virtual Network usa el identificador de recurso de Azure Resource Manager completo en lugar de simplemente el nombre del recurso en la sección NetworkConfiguration del archivo .cscfg. Por ejemplo, /subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.Network/virtualNetworks/vnet-name. En el caso de las redes virtuales que pertenecen al mismo grupo de recursos que el servicio en la nube, puede optar por actualizar el archivo .cscfg para que vuelva a usar solo el nombre de la red virtual.

  • Los tamaños clásicos, como Small, Large y ExtraLarge, se sustituyen por los nuevos nombres de tamaño, Standard_A*. Los nombres de tamaño deben cambiarse a sus nuevos nombres en el archivo .csdef. Para obtener más información, consulte Requisitos previos para implementar Cloud Services (soporte extendido).

  • Use la API Get para obtener la copia más reciente de los archivos de implementación.

Actualización de la configuración de Azure Traffic Manager tras la migración de Cloud Service

Después de migrar Cloud Services (clásico) a Cloud Services (soporte extendido), puede encontrarse con problemas a la hora de actualizar o eliminar configuraciones de puntos de conexión en Azure Traffic Manager. Esto se debe a problemas de sincronización de id. de recursos, en los que el punto de conexión de Traffic Manager todavía apunta al antiguo id. de recursos para Cloud Services (clásico), pero la implementación de Cloud Services (soporte extendido) tiene un nuevo id. de recursos. Para resolver este problema, siga estos pasos:

  1. Migración del punto de conexión temporal del tráfico: migre el tráfico de su Azure Traffic Manager a un punto de conexión secundario.
  2. Eliminación de los puntos de conexión del proceso clásico en Azure Traffic Manager: una vez que el tráfico se dirija a un punto de conexión temporal, elimine el punto de conexión del proceso clásico del perfil de Traffic Manager.
  3. Migración a Cloud Services (soporte extendido): migre el recurso de Cloud Service a Cloud Services (soporte extendido).
  4. Adición de nuevos puntos de conexión en ATM: cree nuevos puntos de conexión en su perfil de Traffic Manager para el recurso migrado de Cloud Services (soporte extendido). Este punto de conexión tiene el nuevo id. de recurso para la instancia de Cloud Services migrada.
  5. Reanudación del tráfico hacia el punto de conexión primario de Cloud Services (soporte extendido): el punto de conexión secundario puede eliminarse o ajustarse a un peso inferior. El tráfico se servirá al nuevo recurso (soporte extendido). Este proceso garantiza que su Traffic Manager esté correctamente alineado con los id. de recursos actualizados y evita problemas de configuración que pueden retrasar los proyectos.

Cambios en la automatización del cliente, la canalización de CI/CD, los scripts personalizados, los paneles personalizados, las herramientas personalizadas, etc.

Los clientes tienen que actualizar sus herramientas y automatización para empezar a usar las nuevas API y comandos para administrar su implementación. Los clientes pueden adoptar fácilmente las nuevas características y funcionalidades de Azure Resource Manager y Cloud Services (soporte extendido) como parte de este cambio.

  • Cambios en los nombres de recursos y grupos de recursos después de la migración

  • Vuelva a crear las reglas y directivas necesarias para administrar y escalar servicios en la nube

    • Las reglas de escalabilidad automática no se migran. Después de la migración, vuelva a crear las reglas de escalabilidad automática.
    • Las alertas no se migran. Después de la migración, vuelva a crear las alertas.
    • Key Vault se crea sin ninguna directiva de acceso. Para ver o administrar los certificados, cree directivas adecuadas en Key Vault. Los certificados están visibles en la configuración de la pestaña denominada Secretos.

Cambios en la administración de certificados después de la migración

Como práctica estándar para administrar los certificados, todos los archivos de certificado .pfx válidos deben agregarse al almacén de certificados en Key Vault y la actualización funcionaría perfectamente a través de cualquier cliente: Portal, PowerShell o API de REST.

Actualmente, Azure Portal realiza una validación para que compruebe si todos los certificados necesarios se cargan en el almacén de certificados de Key Vault y advierte si no se encuentra un certificado. Sin embargo, si tiene previsto usar certificados como secretos, estos certificados no se pueden validar para su huella digital y cualquier operación de actualización que implique la adición de secretos producirá un error a través del portal. Se recomienda a los clientes que utilicen PowerShell o la API de REST para continuar con las actualizaciones relacionadas con los secretos.

Cambios para actualizar a través de Visual Studio

Si ha publicado actualizaciones a través de Visual Studio directamente, primero tendría que descargar el archivo CSCFG más reciente de la implementación posterior a la migración. Use este archivo como referencia para agregar detalles de configuración de red al archivo CSCFG actual en el proyecto de Visual Studio. A continuación, compile la solución y publíquela. Es posible que tenga que elegir el almacén de claves y el grupo de recursos para esta actualización.

Pasos siguientes