2019-09-12

Agosto de 2019

Volumen 34, número 8

[Azure DevOps]

Presentación de Azure Deployment Manager

¿Cuál es la complejidad de sus servicios? ¿Tiene decenas de recursos divididos en varios grupos de recursos y regiones? ¿Cientos? ¿Miles? ¿El sistema de ingeniería facilita la tarea de definir la topología de los recursos de forma declarativa, cómo funcionan y cómo se pueden implementar y actualizar de forma segura y escalable?

Azure Deployment Manager (ADM), actualmente en versión preliminar, proporciona un nuevo conjunto de características de Azure Resource Manager (bit.ly/2Ib6WHM) y amplía enormemente las capacidades de implementación. Si necesita implementar un servicio complejo en varias regiones, u obtener más control sobre cuándo se implementan en relación con otros recursos, o limitan la exposición de su cliente a actualizaciones incorrectas al detectarlas en curso, ADM es para usted.

ADM le permite realizar implementaciones por fases de recursos, lo que significa que se implementan región por región de forma ordenada. Como parte de esta implementación, se supervisa el estado de los servicios, y si se detecta una degradación del rendimiento inaceptable, la implementación se detiene automáticamente, lo que le permite solucionar problemas y reducir la escala del impacto. Cientos de servicios de Microsoft usan estas herramienta internamente para garantizar implementaciones seguras y confiables, así como asegurar la alta disponibilidad y evitar o reducir considerablemente la falta de disponibilidad provocada por regresiones en las actualizaciones.

Conceptos de Azure Deployment Manager

ADM introduce dos nuevos conceptos en la historia de implementación de Azure Resource Manager (ARM): lanzamientos y topologías de servicio.

Como se muestra en la figura 1, una topología de servicio describe la jerarquía de los recursos que implementa en Azure al organizarlos en grupos. Los archivos de plantilla y parámetro forman la base de cualquier implementación de ARM. Representan las unidades de servicio fragmentos de un servicio determinado que se pueden implementar individualmente, como el front-end de un servicio. Un grupo de unidades de servicio consta de un servicio y una topología de servicio no es nada más que un grupo de servicios.

Figura 1 Estructura de topología del servicio

ADM facilita definir estos tipos de topologías complejas incluso cuando los servicios abarcan varias regiones, suscripciones y grupos de recursos. Una vez definidos, se pueden implementar y, a continuación, actualizar tantas veces como sea necesario mediante lanzamientos, que definen la estructura y los momentos de implementación de las unidades del servicio de forma segura y por fases.

Tal como se muestra en la figura 2, un lanzamiento está formado por grupos de pasos. Los grupos de pasos se definen el orden de implementación y admiten las operaciones secuenciales y en paralelo. Por ejemplo, puedo ejecutar el grupo de pasos 2 después del grupo de pasos 1 (como se muestra) o implementar los grupos de pasos 1 y 2 en paralelo antes de implementar el grupo de pasos 3.

Figura 2 Estructura de implementación

Como su propio nombre indica, los grupos de pasos se dividen en pasos, que abarcan los pasos que se deben seguir antes y después de una implementación. Estos son algunos ejemplos de estos pasos:

Espera: Pone en pausa la implementación durante un período determinado de tiempo antes de continuar, lo que permite realizar pruebas manuales, así como tiempo para que los recursos realicen la simulación mediante "bake".
Comprobaciones de estado: ADM se integra con los proveedores de supervisión de servicio existentes para verificar el estado de los servicios mientras las implementaciones están en curso. Si se deteriora el estado de un servicio, se detiene la implementación.

Próximamente habrá más pasos, incluidos los que permiten la ejecución de código personalizado. Para entender mejor estos conceptos, vamos a trabajar con un ejemplo.

Implemente el primer lanzamiento

Antes de empezar, es una buena idea familiarizarse con algunos de los recursos y herramientas con los que trabajará. Estos son algunos vínculos para ayudarle a configurar su entorno y obtener los conocimientos que necesita para trabajar con plantillas de ARM y seguir con el ejemplo:

Familiarícese con las plantillas de Azure Resource Manager (bit.ly/2Ib6WHM)
Visual Studio Code y la extensión de Resource Manager (bit.ly/2MH29lF)
Inicie un terminal de PowerShell en Azure Cloud Shell (bit.ly/2yESmTP)
Descargue e instale el Explorador de Microsoft Azure Storage (bit.ly/2IaaxWA)
Descargue y descomprima los archivos de ejemplo (bit.ly/2F6CInD)

Una vez descargados e instalados los archivos de ejemplo, puede buscar la carpeta ArtifactStore, que contiene una carpeta de plantillas y una carpeta de archivos binarios.

La carpeta de plantillas contiene los artefactos de plantilla de ARM. 1.0.0.0 y 1.0.0.1 representan las dos versiones de los artefactos binarios. Dentro de cada versión, hay una carpeta para cada servicio (Service East US and Service West US). Cada servicio tiene un par de archivos de plantilla y los parámetros para crear una cuenta de almacenamiento y otro par para crear una aplicación web. La plantilla de aplicación web llama a un paquete comprimido que contiene los archivos de la aplicación web. El archivo comprimido es un artefacto binario almacenado en la carpeta de archivos binarios.

La carpeta de archivos binarios contiene los artefactos binarios con 1.0.0.0 y 1.0.0.1, que, de nuevo, representan las dos versiones de los artefactos binarios. Dentro de cada versión, hay un archivo .zip para crear la aplicación web en la ubicación Oeste de EE. UU. y otro archivo .zip para crear la aplicación web en la ubicación Este de EE. UU.

Aunque tanto los artefactos de plantilla como los artefactos binarios tienen dos versiones, solo los artefactos binarios son diferentes entre las dos versiones. En la práctica, los artefactos binarios se actualizan con más frecuencia que los artefactos de plantilla. Para obtener una descripción completa del contenido de estos archivos de artefacto, consulte el tutorial de ADM en aka.ms/admtutorial.

La plantilla de topología de servicio usa los artefactos de plantilla, y la plantilla de lanzamiento usa los artefactos binarios. Tanto la plantilla de topología como la plantilla de lanzamiento definen un recurso de Azure de origen de artefacto, que es un recurso que se usa para orientar a Resource Manager a la plantilla y los artefactos binarios que se usan en la implementación. Para simplificar este ejemplo, se usa una cuenta de almacenamiento para almacenar tanto los artefactos de plantilla como los artefactos binarios. Ambos orígenes de artefacto apuntan a la misma cuenta de almacenamiento, así que vamos a configurarla.

En primer lugar, cree una cuenta de almacenamiento de Azure Para ello, puede seguir las instrucciones del artículo "Guía de inicio rápido: Carga, descarga y enumeración de blobs con Azure Portal” en bit.ly/2F6NMRt.

A continuación, cree un contenedor de blobs en la cuenta de almacenamiento y, luego, copie las dos carpetas (archivos binarios y plantillas) y el contenido de las dos carpetas en el contenedor de blobs. A continuación, obtenga la ubicación de SAS del contenedor mediante los siguientes pasos. Desde el Explorador de Azure Storage, navegue hasta el contenedor de blobs y haga clic en el contenedor de blobs en el panel izquierdo. A continuación, seleccione Obtener firma de acceso compartido. Configure la hora de inicio y la de expiración y, a continuación, seleccione Crear.

Realice una copia de la dirección URL. Esta dirección URL es el URI de SAS necesario para rellenar un campo en los dos archivos de parámetros: el archivo de parámetros de topología y el archivo de parámetros de lanzamiento (en un paso posterior).

Más adelante, en este ejemplo, implementará un lanzamiento. Se necesita una identidad administrada asignada por el usuario para realizar las acciones de implementación. Esta identidad debe tener acceso a la suscripción de Azure en la que va a implementar el servicio y debe tener permisos suficientes para completar la implementación del artefacto. Vamos a crear una identidad administrada asignada por el usuario y a configurar el control de acceso para la suscripción.

Inicie sesión en Azure Portal (portal.azure.com) y cree una identidad administrada asignada por el usuario. Para obtener más información acerca de esto, vea bit.ly/2F7lqqx. Desde el portal, seleccione Suscripciones en el menú izquierdo y, a continuación, seleccione su suscripción. Seleccione el control de acceso (IAM) y, a continuación, seleccione Agregar asignación de roles. Aparecerá el cuadro de diálogo que se muestra en la figura 3.

Figura 3 Crear una identidad administrada asignada por el usuario

Vamos a escribir valores en los campos que se muestran. La lista desplegable Rol proporciona permiso para completar la implementación del artefacto (las aplicaciones web y las cuentas de almacenamiento). En este ejemplo, seleccione Colaborador en la lista. En la práctica, es recomendable restringir los permisos al mínimo.

A continuación, haga clic en la lista desplegable Acceso asignado y seleccione Identidad administrada asignada por el usuario. A continuación, seleccione la identidad administrada asignada por el usuario que creó anteriormente en el ejemplo. Finalmente, seleccione Guardar y asegúrese de anotar el nombre de la identidad administrada, ya que la usará en un paso posterior.

Prepare las plantillas

Ahora que hemos configurado los recursos de la cuenta de Azure necesarios, ha llegado el momento de hacer algunas modificaciones en los archivos proporcionados para poder orientarse correctamente a su suscripción y ubicación de almacenamiento. Para empezar, abra \ADMTemplates\CreateADMServiceTopology.Parameters en Visual Studio Code o cualquier editor de texto. La figura 4 muestra los parámetros de la topología del servicio. A continuación revisaremos cada parámetro.

Figura 4 Parámetros de topología del servicio

namePrefix: este parámetro se usa para crear los nombres de los recursos de Deployment Manager. Por ejemplo, con el prefijo "jdoe", el nombre de la topología de servicio es jdoeServiceTopology. Los nombres de recurso se definen en la sección de variables de esta plantilla. En esta ocasión, use una cadena con entre cuatro y cinco caracteres. Este prefijo se usa para crear nombres de recurso únicos de Azure.

azureResourceLocation: Para simplificar el ejemplo, todos los recursos compartirán esta ubicación, a menos que se especifique lo contrario. No toque este parámetro por ahora.

artifactSourceSASLocation: Este campo debe rellenarse con el URI de SAS guardado en el contenedor de blobs donde se almacenan los archivos de parámetros y la plantilla de unidad de servicio para la implementación.

templateArtifactRoot: Este parámetro proporciona la ruta de desplazamiento del contenedor de blobs donde se almacenan las plantillas y los parámetros. El valor predeterminado es templates/1.0.0.0. No cambie este valor a menos que quiera cambiar la estructura de carpetas usada al cargar los archivos en Azure Storage. En este ejemplo, se usan rutas de acceso relativas. ADM construye automáticamente la ruta de acceso completa. Si, en la práctica, quiere usar rutas de acceso absolutas, ADM también las admite.

targetSubscriptionID: Es, simplemente el identificador de suscripción en que se implementarán y facturarán los recursos de Deployment Manager. En este ejemplo, use el identificador de suscripción.

Ahora, abra \ADMTemplates\CreateADMRollout.Parameters en Visual Studio Code o cualquier editor de texto. Escriba los valores de parámetro como acabamos de describir. Es importante que estos campos tengan los mismos valores en ambos archivos. Hay un nuevo campo en este archivo que se debe rellenar también llamado managedIdentityID. Escriba la identidad administrada asignada por el usuario, reemplazando la parte <ManagedIdentity> con el nombre guardado de la identidad administrada.

Primera implementación

Es el momento de implementar los dos sitios web. Use el terminal de PowerShell de Azure CloudShell para ejecutar los siguientes scripts. Para empezar, ejecutemos un script para implementar la topología de servicio como se indica a continuación:

$resourceGroupName = “<Enter a Resource Group Name>”
$location = “Central US” 
$filePath = “<Enter the File Path to the Downloaded Example Files>”
# Create a resource group
New-AzResourceGroup -Name $resourceGroupName -Location “$location”
# Create the service topology
New-AzResourceGroupDeployment `
  -ResourceGroupName $resourceGroupName `
  -TemplateFile “$filePath\ADMTemplates\CreateADMServiceTopology.json” `
  -TemplateParameterFile “$filePath\ADMTemplates\CreateADMServiceTopology.Parameters.json”

Tenga en cuenta que New-AzResourceGroupDeployment es una llamada asincrónica. El mensaje de éxito solo significa que la implementación se inició correctamente. En un momento, describiré cómo comprobar el estado de implementación. Por ahora, compruebe que la topología de servicio y los recursos subyacentes se hayan creado correctamente mediante Azure Portal, tal y como se muestra en la figura 5.

Figura 5 Ver recursos de implementación ocultos

Ahora vamos a implementar la plantilla de lanzamiento como se indica a continuación:

# Create the rollout
New-AzResourceGroupDeployment `
  -ResourceGroupName $resourceGroupName `
  -TemplateFile “$filePath\ADMTemplates\CreateADMRollout.json” `
  -TemplateParameterFile “$filePath\ADMTemplates\CreateADMRollout.Parameters.json”

Podemos comprobar el progreso del lanzamiento mediante el siguiente script:

# Get the rollout status
$rolloutname = “<Enter the Rollout Name>”
# “adm0925Rollout” is the rollout name used in this example
Get-AzDeploymentManagerRollout `
  -ResourceGroupName $resourceGroupName `
  -Name $rolloutName `
  -Verbose

Después de la correcta implementación del lanzamiento, verá que se han creado otros dos grupos de recursos: uno para cada servicio. Abra Azure Portal y vaya a las aplicaciones web recién creadas en los nuevos grupos de recursos creados por la implementación del lanzamiento. Abra la aplicación web en un explorador web y el código HTML del sitio comprobará la ubicación y la versión.

Para intentar implementar una versión nueva (1.0.0.1) de la aplicación web, abra CreateADMRollout.Parameters.json y, a continuación, actualice binaryArtifactRoot a binaries/1.0.0.1. Vuelva a implementar el lanzamiento como se ha indicado antes. No es necesario volver a implementar la topología del servicio. Para comprobar la actualización, vaya al sitio web y anote el número de versión que muestra la página.

Enhorabuena, acaba de implementar dos servicios en varias regiones con un lanzamiento por fases y los ha actualizado a una nueva versión. A continuación, vamos a examinar la integración de comprobaciones de mantenimiento en estos pasos de modo que, si una actualización de servicio está en mal estado, la implementación se detendrá automáticamente antes de que afecte a las áreas más importantes.

Implemente un lanzamiento de estado integrado

Los proveedores de supervisión de estado ofrecen varios mecanismos para supervisar y avisarle de problemas de estado del servicio. Azure Monitor (azure.microsoft.com/services/monitor) es un ejemplo de uno de estos servicios, que activan alertas cuando se superan determinados umbrales. Algunos umbrales son indicativos de un problema con el estado del servicio cuando se superan. Por ejemplo, si va a implementar una nueva actualización para su servicio y la memoria y el uso de CPU superan los niveles esperados, Azure Monitor y otros proveedores de supervisión de estado le notificarán los problemas para que pueda tomar acciones correctivas.

Normalmente, estos proveedores de estado ofrecen API REST para que pueda examinar mediante programación los monitores del servicio. Las API REST volverán con una señal de estado correcto o incorrecto (normalmente determinado por el código de respuesta HTTP) o con información detallada acerca de las señales que recibe.

El nuevo paso de comprobación de estado de Azure Deployment Manager permite declarar códigos HTTP que indican un servicio en buen estado o, para obtener resultados más complejos de REST, incluso puede especificar expresiones regulares que indiquen una respuesta correcta si coinciden. Para hacerlo aún más fácil de usar, el equipo de Azure Deployment Manager está trabajando estrechamente con los principales proveedores de supervisión de estado para crear previamente estos códigos HTTP y las expresiones regulares, por lo que, simplemente, se puede copiar y pegar esta parte del paso healthCheck si usa uno de estos proveedores.

El proceso de configuración de las comprobaciones de estado de Azure Deployment Manager es sencillo. En primer lugar, cree monitores de mantenimiento a través de un proveedor de servicios de salud de su elección. A continuación, cree uno o varios pasos de comprobación del estado como parte del lanzamiento de Azure Deployment Manager y rellene los pasos con lo siguiente:

El URI para la API de REST para los monitores de estado, tal como lo define su proveedor de servicios de mantenimiento de estado.
Información de autenticación (actualmente solo se admite la autenticación de estilo de clave de API).
Códigos de estado HTTP o expresiones regulares que definen una respuesta correcta.

Por último, invoque los pasos de comprobación del estado en el momento adecuado en el lanzamiento de Azure Deployment Manager y ADM se encargará del resto.

Fases de comprobación de estado

En este momento, ADM sabe cómo consultar el estado del servicio y en qué fases de la implementación hacerlo. Sin embargo, también permite una detallada configuración de la programación de estas comprobaciones. Un paso de comprobación de estado se ejecuta en un proceso sencillo de tres fases de duración configurable, lo suficientemente enriquecido para admitir las necesidades de supervisión de estado de los mayores servicios de Microsoft que conforman Azure.

Una vez completada una operación de implementación, puede que no tenga sentido comprobar el estado de servicio inmediatamente, ya que la actualización tiene que llegar a un estado estable. Los servicios tardan en empezar a emitir señales de estado que el proveedor de supervisión de estado pueda agrupar en algo útil. Del mismo modo, las VM se pueden iniciar por primera vez, reiniciar, o volver a configurar según los datos nuevos. El resultado: El estado del servicio puede oscilar entre estados correctos e incorrectos. Durante la fase de espera, no se supervisa el estado del servicio, de modo que los recursos implementados tienen tiempo de realizar una simulación mediante "bake" antes de empezar el proceso de comprobación de estado.

A menudo es imposible saber cuánto tiempo tardan los recursos en estar estables después del inicio, por lo que la fase Elastic proporciona una período flexible para que adopten un estado estable y correcto. Cuando empieza la fase Elastic, Azure Deployment Manager sondea periódicamente el estado de servicio del punto de conexión REST. El intervalo se establece en tres minutos en la versión preliminar de Azure Deployment Manager, pero se podrá configurar en el futuro. Si el monitor de estado devuelve señales que indican que un servicio no es correcto, estas se ignoran, la fase Elastic se mantiene y el sondeo continúa. Una vez que el monitor de estado vuelve con señales que indican que un servicio tiene un estado correcto, la fase Elastic finaliza y la fase HealthyState empieza. Por lo tanto, la duración especificada para la fase Elastic es el tiempo máximo que puede dedicar a sondear el servicio antes de que una respuesta correcta se considere obligatoria.

Durante la fase HealthyState, el estado del servicio se sondea continuamente con el mismo intervalo que en la fase Elastic. Se espera que el servicio mantenga las señales de estado correcto del proveedor de supervisión de estado para toda la duración especificada. Si en algún momento se detecta una respuesta incorrecta, ADM detiene el lanzamiento y devuelve la respuesta REST que incluye las señales de servicio en mal estado. Una vez que la fase HealthyState ha finalizado, la comprobación del estado se ha completado y la implementación continúa con el paso siguiente.

Introducción

En producción, se suelen usar uno o varios proveedores de supervisión. Para facilitar la integración de estado, Microsoft ha estado trabajando con importantes compañías de supervisión de estado de servicio para ofrecer una solución sencilla de copiar y pegar para integrar las comprobaciones de estado en las implementaciones. Puede consultar una lista de estos proveedores de supervisión de estado en bit.ly/2XOpR0G.

En este ejemplo, creará una función de Azure (bit.ly/2wPgq5d) para simular un servicio de supervisión de estado. Esta función, simplemente, toma un código de estado y devuelve el mismo código.

Para implementar la función de Azure, use el mismo terminal de PowerShell de Azure CloudShell que usó en los pasos anteriores y, a continuación, ejecute el siguiente script. Tenga en cuenta que projectName debe tener menos de 12 caracteres, con solo letras minúsculas y números. Se reutilizará a lo largo del ejemplo, por lo que debe asegurarse de guardarlo. El código es el siguiente:

$projectName = <Enter a project name that is used to generate Azure resource names>
$location = <Enter the location (i.e. centralus)>
$resourceGroupName = “${projectName}rg”
New-AzResourceGroup -Name $resourceGroupName -Location $location
New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -TemplateUri “https://armtutorials.blob.core.windows.net/admtutorial/deploy_hc_azure_function.json” -projectName $projectName

Para comprobar y probar la función de Azure, abra Azure Portal y el grupo de recursos. El nombre predeterminado es el nombre del proyecto con "rg" anexado. Seleccione la instancia de App Service en el grupo de recursos. El nombre predeterminado de la instancia de app service es el nombre del proyecto con "webapp" anexado. Expanda Functions y, a continuación, seleccione HttpTrigger1.

Como se muestra en la figura 6, seleccione </> Obtener la dirección URL de la función y, a continuación, haga clic en Copiar para copiar la dirección URL en el Portapapeles. La dirección URL debe tener un aspecto similar al siguiente:

https://myhc0417webapp.azurewebsites.net/api/healthStatus/{healthStatus}?code=hc4Y1wY4AqsskAkVw6WLAN1A4E6aB0h3MbQ3YJRF3XtXgHvooaG0aw==

Figura 6 Trabajar con Azure Functions

Ahora sustituya {healthStatus} en la URL con un código de estado. En este ejemplo, use unhealthy para probar el escenario con un estado incorrecto y use healthy o warning para probar el escenario con el estado correcto. Cree dos direcciones URL, una con el estado incorrecto y el otra con el estado correcto. Por ejemplo:

https://myhc0417webapp.azurewebsites.net/api/healthStatus/unhealthy?code=hc4Y1wY4AqsskAkVw6WLAN1A4E6aB0h3MbQ3YJRF3XtXgHvooaG0aw==

https://myhc0417webapp.azurewebsites.net/api/healthStatus/healthy?code=hc4Y1wY4AqsskAkVw6WLAN1A4E6aB0h3MbQ3YJRF3XtXgHvooaG0aw==

Guárdelas, ya que las necesitará para completar este ejemplo. Para probar las direcciones URL, puede, simplemente, abrirlas en un explorador. Debería ver una página sencilla con el texto "Estado:" seguido del valor que indique en la dirección URL.

Realizar la segunda implementación

Para acelerar las cosas, los scripts de PowerShell que siguen harán referencia a una topología de servicio actualizado y un nuevo archivo de implementación que contiene un paso de comprobación de estado. Este paso se produce después de la implementación en Oeste de EE. UU., pero antes de la implementación en Este de EE. UU. Por lo tanto, si se produce un error en la comprobación de estado, el servicio de Este de EE. UU. nunca se implementará, lo que impedirá a los usuarios de la región experimentar el error. Esta comprobación de estado está configurada para buscar "Estado: correcto" como respuesta de estado de la función de Azure. Cualquier otra cosa es una respuesta con un estado incorrecto.

Deberá pasar las direcciones URL a la función de Azure como parámetros al iniciar el script. Si quiere descargar estos archivos para inspeccionarlos, puede desproteger la plantilla de topología de servicio (bit.ly/2KdzW45) y la plantilla lanzamiento (bit.ly/31wbP6e).

En primer lugar, implemente la topología del servicio actualizado. Dado que el script es bastante largo, puede copiarlo desde aquí: aka.ms/admhealthdeploy. El código es el siguiente:

$projectName = <Enter the same project name used earlier in this example>
$location = <Enter the location (i.e. centralus)>
$resourceGroupName = “${projectName}rg”
$artifactLocation = “https://aka.ms/admtutorialartifactstore” | ConvertTo-SecureString -AsPlainText -Force
New-AzResourceGroupDeployment `
  -ResourceGroupName $resourceGroupName `
  -TemplateUri “https://armtutorials.blob.core.windows.net/admtutorial/ADMTemplatesHC/CreateADMServiceTopology.json” `
  -namePrefix $projectName -azureResourceLocation $location `
  -artifactSourceSASLocation $artifactLocation

A continuación, compruebe que la topología de servicio y los recursos subyacentes se hayan creado correctamente mediante Azure Portal, tal y como hemos mostrado antes en la figura 5.

A continuación, vamos a usar la dirección URL de la función de Azure con un estado incorrecto que ha creado antes, además del nombre de la identidad administrada asignada por el usuario para implementar el lanzamiento. Como antes, no dude en copiar este script desde aka.ms/admhealthdeploy. La Figura 7 muestra el script.

Figura 7 Implementar un lanzamiento de estado integrado

$projectName = <Enter the same project name used earlier in this example>
$location = <Enter the location (i.e. centralus)>
$managedIdentityID = <Enter the user-assigned managed identity Name>
$healthCheckUrl = <Enter the health check Azure function URL>
$healthCheckAuthAPIKey = $healthCheckUrl.Substring($healthCheckUrl.IndexOf(“?code=”)+6, $healthCheckUrl.Length-$healthCheckUrl.IndexOf(“?code=”)-6)
$healthCheckUrl = $healthCheckUrl.Substring(0, $healthCheckUrl.IndexOf(“?”))
$resourceGroupName = “${projectName}rg”
$artifactLocation = “https://aka.ms/admtutorialartifactstore” | ConvertTo-SecureString -AsPlainText -Force
# Create the rollout
New-AzResourceGroupDeployment `
  -ResourceGroupName $resourceGroupName `
  -TemplateUri “https://armtutorials.blob.core.windows.net/admtutorial/ADMTemplatesHC/CreateADMRollout.json” `
  -namePrefix $projectName `
  -azureResourceLocation $location `
  -artifactSourceSASLocation $artifactLocation `
  -managedIdentityID $managedIdentityID `
  -healthCheckUrl $healthCheckUrl `
  -healthCheckAuthAPIKey $healthCheckAuthAPIKey
As with the previous rollout, you can check the progress using this script:
$projectName = <Enter the same project name used earlier in this example>
$resourceGroupName = “${projectName}rg”
$rolloutName = “${projectName}Rollout”
# Get the rollout status
Get-AzDeploymentManagerRollout `
  -ResourceGroupName $resourceGroupName `
  -Name $rolloutName `
  -Verbose

Cuando haya pasado suficiente tiempo, la comprobación del estado del lanzamiento mostrará un error. Esto es normal, ya que se usó la función de Azure con un estado incorrecto. También verá que se creó un grupo de recursos para el servicio de Oeste de EE. UU., pero no verá el grupo de recursos Este de EE. UU. porque el lanzamiento se detuvo automáticamente antes de continuar en otras regiones. Repita esta implementación con la dirección URL de estado de mantenimiento y , una vez completada, verá que ambos servicios han implementado correctamente.

Eso es todo

ADM le permite realizar implementaciones complejas en varias regiones y suscripciones que se integran con las soluciones de supervisión de estado de servicio mediante plantillas de ARM integradas de Azure. No se requiere ninguna herramienta adicional, y es completamente gratuito. Para empezar, revise la documentación en aka.ms/admdocs o explore el tutorial completo en aka.ms/admtutorial.

David Tepperes el administrador de programas principal de Microsoft en el equipo OneDeploy de Azure. Tiene experiencia en aprendizaje automático y ha trabajado tanto en las tecnologías de implementación como en el shell de Windows.

Gracias a los siguientes expertos técnicos de Microsoft por revisar este artículo: Cristina del Amo Casado, Jonathan Gao, Devesh Guha Oleti Muni, Sriram Ramaswamy
Cristina del Amo Casado es la administradora de programas principal de Azure Compute en Microsoft.
Jonathan Gao (jgao@microsoft.com) es redactor técnico sénior para Azure Resource Manager en Microsoft.
Devesh Guha Oleti Muni (Devesh.Oleti@microsoft.com) es ingeniero de software sénior con el equipo de Azure en Microsoft.

Comente este artículo en el foro de MSDN Magazine

Compartir a través de