Primeros pasos con AKS: Namespaces línea de comando

 

En la entrada anterior vimo cómo crear un namespace desde al portal de Azure, ahora vamos a ver cómo podemos hacer lo mismo usando la línea de comando.

Ingresamos a Azure Cloud Shell, desde allí podemos usar el comando kubectl el cual nos permite enviar instrucciones a la API de Kubernetes, 

Ahora,veamos cómo conectarnos a nuestro cluster de AKS utilizando Azure CLI, para ello corremos el siguiente comando:

az aks get-credentials --resource-group [nombre-grupo-recursos] --name [nombre-cluster-kubernetes]

Ahora veamos los namespaces que tenemos, para ello corremos lo siguiente:

kubectl get namespaces

Como se puede apreciar en la imagen anterior, vemos exactamente lo mismo que vimos desde el portal de Azure.

Vamos a crear un nuevo namespace usando el comando kubectl:

kubectl create namesapce  [nombre-namespace]

Ahora, volvamos a consultar los namespaces, deberiamos ver nuestro namespace recién creado testcmd

Por ahora ya tenemos nuestro namespace creado, pero aún no hemos desplegado ningún recurso sobre el mismo, ya veremos en entregas posteriores más detalles sobre otros recursos como pods, servicios, etc, pero para resumir un poco, es posible desplegar recursos en un namespace existente, si no especificamos sobre cual namespace desplegar nuestra app, kubernetes lo hará sobre el namespace default. Por ejemplo vamos a crear un pod con el siguiente código YAML:

El código anterior lo guardé en un archivo llamado mypod.yml y lo ejecutaré corriendo lo siguiente:

kubectl apply -f mypod.yml

Como no especificamos sobre cuál namespace desplegar Kubernetes lo hará sobre default, y esto lo podemos verificar si ejecutamos lo siguiente:

kubectl get pods -o yaml

En la salida YAML que aparece en pantalla podemos buscar la sección donde muestra el nombre del namespace, y podemos comprobar que se trata del namespace default

Si ejecutamos el siguiente comando para ver el despliegue que hicimos, veremos nuestro pod en ejecución:

Pero aquí nos surge la duda sobre cómo desplegar el pod por ejemplo en el namespace test que creamos, básicamente vamos a realizar un cambio en el archivo mypod,yml para que quede de la siguiente forma:

Como podemos ver hemos simplemente agregado el namespace en la definición y lo ejecutamos de la misma forma.

si volvemos a consultar los pods veremos que esta vez no aparece:

Lo anterior sucede porque estamos ubicados en el namespace por defecto, y este nuevo pod lo hemos creado en el namespace test, así que una de las formas que tenemos para consultar recursos en otros namespaces es especificarlo a través del parámetro --namespace de la siguiente forma:

kubectl get pods --namespace=test

De esta forma si veremos el pod recién creado sobre este espacio de nombres

Otra opción que tenemos para desplegar un pod en otro espacio de nombres sin necesidad de especificarlo en el archivo YAML, es hacerlo desde la misma línea de comando, para ello basta con agregar el parámetro --namespace durante la ejecución de kubectl apply tal como se muestra a continuación:

kubectl apply -f mypod.yml --namespace=test

Ahora bien, si por ejemplo estamos en el namespace default y no queremos estar especificando el espacio de nombres cada vez que ejecutemos algún comando, basta con cambiar el contexto a otro namespace, en el siguiente ejemplo voy a establecer el namespace test como mi nuevo cotexto:

kubectl config set-context --current --namespace=test

Ahora podemos volver a ejecutar kubectl para listar los pods pero sin poner el espacio de nombres, y podemos observar que esta vez lo muestra sin necesidad de especificar el espacio de nombres test, esto es porque hemos cambiado el contexto:

Bien, y esto es todo por hoy! espero sea de utilidad.

Primeros pasos con AKS: Namespaces

 

En la entrada anterior vimos cómo crear nuestro primer servicio de AKS, ahora vamos a empezar a conocer un poco más acerca de sus componentes, para ello hoy vamos a hablar de namespaces o espacios de nombres en español, así que iniciemos.

Dentro del servicio de AKS tenemos una sección llamada Kubernetes resources, allí mismo podemos encontrar Namespaces

Qué es un Namespace?

Un namespace es básicamente algo que nos ofrece Kubernetes para poder aislar nuestros recursos de forma lógica. Esto nos permite organizar nuestros recursos en el cluster, también nos sirve para temas de seguridad debido a que tenemos aislados los recursos e incluso por temas de rendimiento resulta util usar namesapces.

Namespaces por defecto

Al ingresar a namespaces vemos que por defecto el servicio de AKS nos ha desplegado cuatro: default, kube-node-lease, kube-public y kube-system.

Como se puede apreciar en la imagen anterior, tenemos la opción Add para agregar namespaces adicionales en caso que lo necesitemos, por ahora no hay mucho por lo cual debamos preocuparnos acerca de estos espacios de nombres, por lo pronto debemos saber que por ejemplo kube-system se encarga de manejar algunos temas del cluster tales como la resolución DNS, por otro lado nuestras apps serán creadas en el namespace default, asi que este es el primer namespace con el que generalmente tenemos contacto.

Crear primer namespace

Ahora vamos a crear nuestro primer namespace, para ello basta con hacer clic en + Add

Vamos a ver un cuadro de texto vacío donde se espera pongamos algo ya sea en formato YAML o JSON para crear el namespace.

En nuestro caso, vamos a usar el siguiente fragmento de código en formato YAML:

Hacemos clic en el botón Add 

Una vez creado el namespace podemos verlo en la lista:

Por ahora hemos cerado nuestro primer namespace usando el portal de Azure, pero claramente todo esto es posible hacerlo usando Azure CLI, asi que en la próxima entrada del blog veremos cómo podemos hacer esto mismo desde la línea de comandos.

Primeros pasos con AKS

 

Este es el primer post de una serie de entradas que voy a escribir sobre el servicio de Kubernetes que ofrece Microsoft Azure llamado AKS (Azure Kubernetes Service), básicamente el objetivo es explicar los conceptos básicos y aprender lo que debemos hacer para iniciar a trabajar de manera rápida con este servicio, una vez termine de explicar las generalidades para poder iniciar, empezaré a escribir entradas sobre temas específicos relacionados con diferentes componentes del servicio. Así que en esta primer entrada vamos a ver cómo desplegar el servicio con la configuración más básica.

Lo primero que debemos hacer es ir al Azure Marketplace y en la categoría de Containers buscar Kubernetes Service

Ahora debemos diligenciar la siguiente información necesaria para el despliegue:

1. Selecciona el grupo de recursos en el cual se creará el cluster.
2. Escribe el nombre que tendrá tu cluster
3. Selecciona la región de Azure sobre la cual se creará el cluster
4. Selecciona en cuántas zonas de Azure se desplegará tu cluster, esto con fines de tener una alta disponibilidad en caso de que la zona donde se encuentra el cluster tenga alguna afectación, en este caso seleccioné dos zonas de tres posibles que ofrece la región seleccionada.
5. La versión de Kubernetes, mantuve la opción por defecto en este momento 1.18.10, esto puede variar a medida que salgan nuevas versiones.
6. Seleccionamos el tamaño que tendrán nuestros nodos del cluster.
7. Cantidad de nodos del cluster, por tratarse de una demostración he puesto solo uno, pero Microsoft recomienda tener al menos tres nodos para entornos de producción.

Por último, hacemos clic en Review + create

Una vez hayan sido superadas las validaciones, hacemos clic en Create para que inicie el despliegue del servicio.

Solo debemos esperar hasta que el proceso de creación finalice, y si vamos a nuestro grupo de recursos veremos el servicio disponible.

Al hacer clic sobre el servicio se abrirá el blade donde podemos ver todos los detalles de nuestro nuevo cluster de Kubernetes listo para usar.

Y eso es todo, hasta aquí dejaremos esta primer entrada donde básicamente vimos cómo desplegar el servicio de AKS con su configuración más básica, en las siguientes entradas empezaremos a revisar más en detalle lo que hemos desplegado y cómo empezar a usarlo.

Conectar a VM Linux en Azure usando SSH desde Windows

 

En este post les explicaré cómo conectarse a una máquina virtual en Azure con sistema operativo Linux usando SSH desde un sistema operativo Windows 10.

Cuando creamos una máquina virtual en Azure con sistema operativo Linux, tenemos dos opciones para conectarnos a esta a través de SSH, una es utilizando un nombre de usuario y contraseña, y la otra usando un par de llaves de cifrado, que es la que explicaré en esta entrada. Por lo cual al crear la máquina por primera vez en Authentication type debemos seleccionar SSH public key. Ponemos un nombre de usuario para la conexión y otro para la llave.

Antes de crear la máquina veremos un mensaje que nos pide bajar la llave privada, se creará un recurso en Azure que almacenará la llave pública, por lo cual debemos hacer clic en Download private key and create resource, como podemos ver en el mensaje de advertencia, si no descargamos la llave en ese momento no será posible descargarla después de que el recurso haya sido creado en Azure.

En este caso he bajado la llave a la siguiente ruta local C:\sshkey\LinuxVM_key.pem

Al finalizar, podemos ver en nuestro grupo de recursos que efectivamente tenemos un nuevo recurso donde Azure almacena la llave pública.

Si ingresamos al recurso veremos la llave pública.

Ahora, vamos a intentar conectarnos, para ello vamos a nuestro recurso de máquina virtual y hacemos clic en la opción Connect del menú desplegable seleccionamos SSH

Nos aparecerá una lista de instrucciones paso a paso para hacer la conexión, pero nos fijaremos por ahora en el segundo paso, que nos indica que debemos tener permisos de solo lectura al archivo de llave privada, y vemos un ejemplo con el comando chmod de Linux, pero en este caso vamos a realizar la conexión desde una máquina Windows, así que en este caso simplemente he dado permisos de solo lectura a mi usuario sobre la carpeta C:\sshkey

Una vez otorgados los permisos, desde la terminal de Windows ejecutar el comando ssh tal como se muestra en el paso 4.

En mi caso puedo copiar el mismo comando y solamente reemplazar la ruta donde dice <private key path> quedando de la siguiente forma:

ssh -i C:\sshkey\LinuxVM_key.pem azureuser@40.117.73.151

Escribimos yes para confiar en la llave pública y eso es todo, ya estamos conectados a nuestra máquina Linux en Azure usando SSH desde Windows

Espero les sea de utilidad.

Usar Azure Cloud Shell desde Windows Terminal

 

En este post mostraré cómo usar Azure Cloud Shell usando la nueva terminal de Windows, desde luego esta herramienta se ha convertido en algo muy útil en mi trabajo del día a día, y para muchas personas que admistren recursos en Azure seguro también les será de bastante utilidad. A continuación veremos lo sencillo que resulta usar Azure Cloud Shell desde Windows Terminal.

primero abrimos la termial de Windows, luego en la pare superior hacemos clic en el desplegable para ver las diferentes consolas que podemos usar, en este caso seleccionamos Azure Cloud Shell, cuyo método abreviado es Ctrl+Shift+4

Ahora te pedirá que ingreses a la URL https://microsoft.com/devicelogin y uses el código que te aparece en la terminal.

Una vez se abra el navegador pega el código que aparece en la terminal.

Se te solicitará tu dirección de correo, debes poner la dirección asociada a la suscripción de Azure que quieres usar, una vez termines te aparecerá el siguiente mensaje:

Tal como indica el mensaje anterior, ya puedes cerrar el navegador y volver a la terminal. Si tienes asociados varios tenants a tu suscripción te preguntará cuál de ellos quieres utilizar.

En mi caso seleccionaré el primero, es decir el Tenant 0.

Y listo! eso es todo ya tenemos acceso a Azure Cloud Shell desde nuestra terminal de Windows. Ahora veamos un ejemplo, vamos a listar todas las tallas de máquina virtual disponibles en la región westus:

az vm list-sizes -l westus

Espero les sea de utilidad.

Cómo implementar un grupo de hosts de Windows Virtual Desktop con Infraestructura como código de Azure DevOps

En este artículo se describe le proceso que se debe llevar a cabo para automatizar el despliegue y actualización de máquinas pertenecientes a un host pool de Windows Virtual Desktop, para ello se usará Infraestructura como código, IaC (por sus siglas en inglés) desde Azure DevOps.

Este artículo asume que ya tienes conocimiento o experiencia con Windows Virtual Desktop (WVD, en adelante), y en general con temas de infraestructura, ya que el tema será abordado desde el punto de vista de un ITPro, sin embargo no es necesario que cuentes con experiencia en Azure DevOps, a lo largo de este artículo podrás comprender la utilidad de este servicio y como le podemos sacar gran provecho a la hora de automatizar la creación y actualización de infraestructura.

El presente documento está basado en el trabajo realizado por Tom Hickling, se ha replicado el proceso y se adaptó al idioma español. Puedes encontrar el artículo original en inglés en este enlace: How to deploy a Windows Virtual Desktop host pool using Infrastructure as code from Azure DevOps
Al final de este artículo tendrás:

1. Dos imágenes doradas. Un Windows 10 1903 y 1909 Multi-Session, pero con el conocimiento de cómo crear fácilmente una imagen de 20nn cuando esté disponible. Esto usará un pipeline de build en Azure DevOps

2. Un método automatizado para actualizar un grupo de hosts existente, que es el principal caso de uso aquí, ya que estamos hablando de hacer que la vida de un administrador de WVD sea lo más fácil posible. Pero también, cómo construir un nuevo grupo de hosts basado en una de sus imágenes. Esto usará un pipeline de release en Azure DevOps. Luego lo habilitaremos para que cuando cree una nueva imagen, su grupo de hosts WVD existente se actualice automáticamente con esta nueva imagen. Esto se ocupa de nuestra necesidad de actualizar regularmente las máquinas virtuales session host en un grupo de hosts con una imagen actualizada, para aprovechar las nuevas aplicaciones, parches o cualquier otra cosa que hayamos agregado a la imagen.

Dentro de Azure DevOps crearemos:

• Un repositorio de código para almacenar las plantillas de compilación, así como las plantillas ARM de implementación y actualización de WVD.

• Luego una canalización de construcción (Build Pipeline). El cual usa el repositorio, así como también un recurso compartido de archivos SMB de Azure Files donde almacenamos los medios de instalación para aplicaciones en nuestra imagen dorada. Luego usa Key Vault donde almacenamos las contraseñas para acceder a algunos servicios confidenciales. Esta canalización de compilación crea una imagen administrada de Azure con esas aplicaciones instaladas. Utiliza Hashicorp Packer para hacer esa compilación.

• El segundo paso utiliza una canalización de lanzamiento (Release Pipeline) para tomar esa imagen y usar las plantillas ARM de WVD existentes para construir un nuevo grupo de hosts o actualizar un grupo de hosts existente. Esto se configurará para que iniciemos una nueva compilación y Azure DevOps no solo completará la compilación, sino que implementará o actualizará automáticamente el grupo de hosts sin interacción adicional.

Lo anterior luce de la siguiete forma:

Los requisitos previos para esto son una suscripción de Azure, un tenant de WVD y una cuenta de Azure DevOps. A lo largo de esta guía también necesitará varios archivos ya creados. Estos están disponibles en el repositorio de GitHub de Tom Hickling aquí. Descargue todos estos archivos a una ubicación local.

Este artículo tiene dos secciones principales:

Sección 1: creación de Azure DevOps Repo donde almacenamos todas las plantillas JSON. También pasa por el proceso de creación de la infraestructura de Azure necesaria que usamos en la compilación.

Sección 2: creación de las canalizaciones de compilación (Build) y lanzamiento (Release) de Azure DevOps que compilan una imagen y crean o actualizan grupos de hosts WVD con la nueva imagen.

Sección 1

Para comenzar, necesita una cuenta de Azure DevOps. Vaya a este sitio para crear su cuenta. Esto lo llevará a través del proceso para configurar su propia cuenta en Azure DevOps (ADO, en adelante) para que pueda comenzar a construir cosas.

Entonces, si ya tiene su cuenta en Azure DevOps, comencemos.


Lo primero que debe hacer es crear un nuevo proyecto.

Paso 1. En la página de inicio de ADO, haga clic en + New project:

Paso 2. Déle a su proyecto un nombre significativo. Luego, dependiendo de la configuración de ADO, elija la visibilidad adecuada. Haga clic en Advanced y luego seleccione "Git" en Version Control y "Basic" en Work item process:

Haga clic en Create y tendrá su nuevo proyecto ADO listo para funcionar:

Paso 3. Crea un Repo.

A la izquierda, haga clic en Repos.

Deje los valores predeterminados y haga clic en Initialize en la parte inferior.

Esto ha creado un Repo vacío y lo ha inicializado listo para recibir algún contenido.

Paso 4. Crea algunas carpetas para almacenar tus archivos y luego súbelos

En la parte superior derecha, haga clic en los puntos suspensivos verticales y seleccione + New> Folder:

Asigne el nombre ARM Templates a esta carpeta e ingrese README.md en el campo New file name:

En la parte superior derecha, haga clic en el botón Commit.

En la ventana Commit, simplemente haga clic en el botón Commit en la parte inferior.

Paso 5. Haz clic en WVD-Auto-HostPool (o el nombre de tu poyecto) en la parte superior de la pantalla Repo y repite los mismos pasos para crear una carpeta llamada - Packer Build - Win 10 1903 EVD

Paso 6. Repita lo anterior y cree ahora una carpeta llamada - Packer Build - Win 10 1909 EVD


Ahora debería tener una estructura de carpetas similar a esta:

Paso 7. Ahora cargaremos las dos plantillas ARM de "implementación" para las implementaciones del grupo de hosts WVD, que usaremos justo al final en la "Canalización de lanzamiento" que crea o actualiza un grupo de hosts.

Haga clic en la carpeta ARM Templates y luego haga clic en el icono de puntos suspensivos en la parte superior derecha y haga clic en Upload file(s).

Luego vaya a mainTemplate, el archivo JSON que descargó anteriormente, luego haga clic en Commit en la parte inferior derecha.

Elimine el archivo README.md debido a que ya no es necesario. Seleccione el archivo, luego haga clic en los puntos suspensivos y por último haga clic en Delete.

Luego haga clic en Commit en la parte inferior derecha.

Paso 8. Repita este paso y cargue el archivo UpdateTemplate.json (también es posible cargar los dos en un solo paso).

Paso 9. Ahora cargaremos las dos plantillas de Packer que compilan la imagen EVD de Windows 10 1903 y la imagen EVD de Windows 10 1909.

Haga clic en la carpeta "Packer Build - Win 10 1903 EVD" y haga clic en los puntos suspensivos en la parte superior derecha y cargue y confirme el archivo packer-win10_1903.json que descargó anteriormente.

También elimine el archivo README.md en esta carpeta. También puede eliminar un archivo haciendo clic en los puntos suspensivos a la derecha del archivo y seleccionando Delete y luego haciendo clic en Commit.

Ahora echemos un vistazo a este archivo de plantilla. Haga clic en el archivo packer-win10_1903.json.

La sección de variables tiene varias variables que se establecen en Key Vault o en un Pipeline, que estableceremos un poco más adelante.

La sección de builders (Constructores) es donde ocurre la acción y crea la imagen administrada de Azure.

Es aquí donde especificamos qué compilación de Windows 10 queremos. En la línea 32 llamamos a 19h1-evd:

Esta es la construcción de 1903. Si cambia esto a 19h2-evd, construirá 1909. En el futuro, aquí es donde ingresaría 20h1-evd y generará la construcción 200n.

También tenga en cuenta que las líneas 41-44 hacen referencia a una red virtual. Esta red virtual es aquella en la que se coloca la máquina virtual para crear la imagen. Tendremos que crear esto más tarde.

La sección de provisioners (aprovisionadores) realiza la instalación de las aplicaciones. En el archivo que se descargó del repositorio se han ingresado dos métodos para instalar aplicaciones. Debe seleccionar solo el que sea más apropiado para usted. Se han agregado ambos métodos en un solo archivo para mostrar las opciones (al menos dos opciones, ya que hay muchas más). Deberá seleccionar solo uno y eliminar el otro en un momento.

La instalación de las aplicaciones se realiza en esta sección en las líneas 79 - 86:

El primer método tiene dos ejemplos en las líneas 79-83.

Estos dos ejemplos instalan dos aplicaciones (Notepad ++ y FSLogix).

Esto depende de tener disponible un recurso compartido SMB de Azure Files, que crearemos un poco más tarde en el que hayamos colocado todos los instaladores de aplicaciones. También necesita tener asignada la unidad "I", lo cual hacemos en las líneas 71-74.

Luego, cree el archivo cmd para cada aplicación con el fin de instalar silenciosamente las aplicaciones.

Como referencia, FSlogix.cmd solo tiene este comando dentro de él:

i: \ fslogix \ x64 \ Release \ FSLogixAppsSetup.exe / install / quiet / norestart

Este enfoque permite la flexibilidad de incluir o eliminar aplicaciones según sea necesario.

Si está instalando aplicaciones de esta manera, recuerde eliminar el "," al final de la línea 83 y luego elimine las líneas 85 y 86.


Sin embargo, las líneas 85 y 86 muestran la segunda forma de implementar aplicaciones, que es crear un script de PowerShell que tenga todas las aplicaciones que desea instalar en un solo archivo:

Nota: En mi caso, he utilizado el segundo método propuesto, así que para mis pruebas eliminé las líneas 79-83 dejando solamente las líneas 85 y 86 para hacer la instalación de aplicaciones usando el archivo de PowerShell.

Esto llama a otro archivo cmd que a su vez llama a un archivo PS1 con todas las instalaciones de aplicaciones realizadas dentro de un archivo.

El archivo cmd contiene solo esta línea:

powershell.exe -executionpolicy bypass -windowstyle hidden -noninteractive -nologo -file "I: \ GoldImage \ Installapps.ps1"

El archivo Installapps.ps1 tiene todos los comandos de PowerShell para descargar e instalar todas las aplicaciones que necesita dentro de su Golden Image. Este método descarga los instaladores de aplicaciones directamente desde Internet localmente y luego los instala. Esto ahorra la necesidad de descargar los instaladores de aplicaciones y colocarlos en el recurso compartido de Azure Files.

El archivo se ve así:

Si prefiere implementar aplicaciones de esta manera, elimine las líneas 79-83.

Paso 10. Haz clic en la carpeta Packer Build - Win 10 1909 EVD y sube el archivo packer-win10_1909.json como se indica arriba.

Una vez cargado, tenga en cuenta que la línea 32 tiene 19h2-evd. Además, también tenga en cuenta la sección de instalación de las aplicaciones entre las líneas 76-83. Elimine las secciones que no quiera.

Eliminar el archivo README.md

Ahora quedará una estructura Repo que se ve así:

Nuestro Repo ahora está completo, y podemos pasar a Build Pipeline, que usará Packer de Hashicorp para hacer la construcción real.

Sección 2

Paso 11. Lo primero que necesitamos es un Service Principal para Packer.

Packer, como cualquier otro servicio que se integra con su suscripción de Azure, necesita un mecanismo seguro para hacerlo. WVD en sí es otro ejemplo de este tipo de acceso. Packer crea algunos componentes de infraestructura en su suscripción de Azure al igual que WVD y, por lo tanto, necesita este SPN.

Dos formas de crear un Director de servicio:

1. A través del portal de Azure.
2. Powershell.

Comencemos haciendo esto a través del Portal de Azure.


En Azure Portal, vaya a su Azure Active Directory, y luego seleccione App registratons.

Haga clic en + New registration.

Paso 12. Déle un nombre razonable, seleccione "Accounts in this organizational directory only..." y en Redirect URI (optional) ingrese una URL ficticia ya que en este contexto no es necesario.

Haga clic en Register en la parte inferior.

Paso 13. Asigne un rol a este SPN.

Vaya a su suscripción, y seleccione Access Control (IAM)

A la derecha, seleccione Add a role assignment

Seleccione el rol apropiado, he seleccionado Contributor, luego asigne acceso a: Azure AD user, group, or service principal. En el campo Select, escriba los primeros caracteres de su SPN y luego seleccione su SPN.

Haga clic en Save en la parte inferior.

Paso 14. Obtenga los valores de inicio de sesión para este SPN.

Regrese al SPN en la sección de App registrations de AAD

En la pestaña de resumen, copie el Application (client) ID y guárdelo en algún lugar. Le sugiero que almacene esto temporalmente en el bloc de notas y lo mantenga abierto, ya que habrá una serie de elementos a los que tendremos acceso más adelante. Lo necesitaremos más adelante en el paso 18 cuando agreguemos esto a Key Vault para un almacenamiento seguro.

Haga clic en Certificates & secrets

Haga clic en + New client secret

Escriba una descripción y seleccione un tiempo de expiración.

Copie Value y guárdelo temporalmente en el bloc de notas. Deberá copiar esto ahora, ya que no se volverá a mostrar. Si no lo copia, deberá crear uno nuevo. Necesitamos esto y la identificación de la aplicación más adelante. Los almacenaremos de forma segura en Azure Key Vault, más adelante en el paso 18.

La otra forma que será más rápida es usar Powershell.

Paso 15. Ejecute estos comandos de Powershell para crear el SPN:

$aadContext = Connect-AzureAD
$svcPrincipal = New-AzureADApplication -AvailableToOtherTenants $true -DisplayName "Packer-ServicePrincipal"
$svcPrincipalCreds = New-AzureADApplicationPasswordCredential -ObjectId $svcPrincipal.ObjectId

#Get Password (secret)
$svcPrincipalCreds.Value

#Get App id:
$svcPrincipal.AppId

Repita los pasos anteriores para dar a este SPN al menos acceso de Contributor a su suscripción.

Paso 16. Cree un recurso compartido para almacenar los instaladores de las aplicaciones.

Utilizaremos Azure Files para crear un simple recurso compartido de archivos SMB. Este recurso compartido es lo que asignamos en la compilación de Packer y se define en las plantillas de compilación de Packer que subimos al Repo y editamos anteriormente.

En Azure Portal, cree un nuevo grupo de recursos. Llámelo Packer-Build. Este grupo de recursos permanecerá y terminará conteniendo algunos servicios, como la cuenta de Almacenamiento y el Almacén de claves. También será donde almacenaremos permanentemente las imágenes resultantes.

Cree una nueva cuenta de almacenamiento.

En su grupo de recursos, haga clic en + Add y escriba storage account, cuando aparezca haga clic en Create

Déle un nombre y asegúrese de seleccionar la misma región de Azure donde le gustaría implementar sus nuevos hosts de sesión.

Haga clic en Review + create o vaya a las otras secciones.

Cree la cuenta de almacenamiento.

Paso 17. Cree el recurso compartido de archivos de Azure.

Ahora solo necesitamos crear el recurso compartido de Azure File en la cuenta de almacenamiento. Aquí es donde colocaremos el archivo para la instalación de aplicaciones.

Vaya a su cuenta de almacenamiento recién creada y en Overview, haga clic en File shares.

Luego haga clic en + File share

Dele al archivo un nombre y una cuota:

Haga clic en Crete en la parte inferior.

Vaya al recurso compartido de archivos y haga clic en Upload

Ahora cargue los archivos de instalación de las aplicaciones y los archivos de instalación de cmd para cada uno.

También tenga en cuenta que si va a implementar aplicaciones a través del archivo Powershell, no necesita cargar los instaladores. Todo lo que necesita hacer es crear una carpeta como "GoldImage" y colocar los archivos "InstallApps.cmd" e "InstallApps.ps1".

De cualquier manera (o ambas) deberías terminar con algo similar a lo siguiente:

Además, necesitamos poder asignar un disco a este recurso compartido un poco más tarde.

Con el recurso compartido de archivos seleccionado, haga clic en Connect en la parte superior, Seleccione Windows y copie todo el texto:

Péguelo en el bloc de notas o algo similar y luego copie solo la ruta al recurso compartido y guárdelo, ya que lo necesitaremos más adelante. Es la línea que comienza con New-PSDrive ...

es decir, en mi ejemplo es:

\\packerstoragemvp.file.core.windows.net\appinstalls

En la cuenta de almacenamiento, regrese a Access Keys:

Copie y almacene el nombre de la cuenta de almacenamiento y la clave. Los necesitaremos en el Paso 18.

Paso 18. Cree una bóveda de Azure Key.

Regrese al grupo de recursos que acaba de crear y haga clic en + Add

Busque Key Vault y haga clic en Create

Dé un nombre a Key Vault y haga clic en Review + create en la parte inferior:

Ahora tendrá una nueva bóveda de claves. Ahora agregaremos los diversos detalles que ha almacenado anteriormente como secretos en el almacén de claves. Más adelante, recuperaremos estos secretos de Build Pipeline para no almacenarlos en ningún lugar del código.

Paso 19. Agregue secretos a Key Vault

Abra el nuevo almacén de claves y haga clic en Secrets 

y luego haga clic en + Generate / Import:

Ahora agregue los siguientes ocho secretos. Esto requiere los elementos que ha guardado anteriormente, además de algunas de las credenciales utilizadas en su implementación de WVD existente:

Nombre	Valor
AppInstallsStorageAccountName	Nombre de la cuenta de almacenamiento
AppInstallsStorageAccountKey	Llave de acceso de la cuenta de  almacenamiento
DomainJoinAccountUPN	Cuenta de AD para unir al dominio
DomainJoinAccountPassword	Contraseña de la cuenta anterior
PackerDevOpsVMProvisioningServicePrincipalAppID	DevOps SPN App ID
PackerDevOpsVMProvisioningServicePrincipalSecret	Secreto del SPN anterior
WVDServicePrincipalAppID	Service Principal para WVD
WVDServicePrincipalSecret	Secreto del SPN anterior

Ahora debería tener una lista como esta:

Paso 20. Agregue una política de acceso.

Necesitamos que el Service Principal al menos enumere y lea estas claves para poder recuperarlas en DevOps.

Haga clic en Access policies:

Luego haga clic en + Add Access Policy

En el menú desplegable Configure from template (optional) puede seleccionar un conjunto de permisos preconfigurado. La más fácil es Key & Secret Management. Opcionalmente, puede seleccionar permisos más granulares en el menú desplegable Key permissions

Seleccionaremos esa plantilla.


En Select principal, busque y agregue su SPN creado anteriormente y haga clic en Seleccionar en la parte inferior.

Asegúrese de hacer clic en Save en la parte superior.

Paso 21. Obtenga esos secretos de Key Vault y colóquelos en DevOps.

Para poder obtener estos valores con DevOps, necesitamos agregarlos a una biblioteca dentro de la canalización (pipeline).

De vuelta en Azure DevOps, haga clic en Pipelines/Library:

Luego haga clic en + Variable group

Asigne un nombre al grupo y active el botón "Link secrets from an Azure key vault as variables". Esto es necesario para conectarse a su almacén de claves para recuperar los secretos. Sin esto, solo le permitirá ingresar variables manualmente.

Paso 22. En el menú desplegable Azure subscription, seleccione la suscripción que ha estado usando y en la que desea que se implemente DevOps.

En el menú desplegable del botón azul Authorize, seleccione Advanceed options Ahora crearemos una conexión de servicio DevOps a la suscripción de Azure.

Paso 23. Haga clic en el enlace"... use the full version of the service connection".

Ingrese el Service principal client ID del SPN de Packer y la clave o secreto del mismo, el cual creó y almacenó previamente en Key Vault:

Haga clic en Verify connection, y debería obtener el mensaje Verified junto a un icono verde como se muestra a continuación:
:

Si esto falla, regrese al blade Subscription y luego a Access Control (IAM) y verifique que el SPN de Packer que creó tiene al menos acceso de Contributor a su suscripción.

Haga clic en OK

Paso 24. En el menú desplegable Key vault name, seleccione su almacén de claves recién creado y haga clic en el botón azul Authorize (en la siguiente imagen no se muestra el botón ya que hice clic antes de sacar el pantallazo, así que duisculpas por favor)

Haga clic en Save en la parte superior.

Ahora en la sección Variables, haga clic en + Add. Esto enumerará todos los secretos en su almacén de claves.

Selecciónelos todos y haga clic en OK.

Su sección de Variables ahora enumerará todos sus secretos dentro de ella.

Haga clic en Save en la parte superior.

De vuelta en la sección Library DevOps, ahora se enumeran sus variables de Azure Key Vault.

El siguiente paso es crear otro grupo de variables que no requiera ser almacenado en el almacén de claves.

Paso 25. Crear un grupo de variables.

En DevOps, vaya a Pipelines/Library.

En la parte superior, haga clic en + Variable group

Dé un nombre a su grupo de variables y haga clic en + Add cuatro veces para crear cuatro nuevas variables.

Ahora agregue cuatro nuevas variables:

ARM_Subscription_ID	El ID de su suscripción
AZ_Tenant_ID	El ID de su tenant de Azure AD
wvd_goldimage_rg	Este es el nombre del grupo de recursos donde el pripeline de compilación colocará la imagen que construye. Use el mismo grupo de recursos que tiene su almacén de claves y su cuenta de almacenamiento
packaged_app_installs_path	Esta es la ruta al recurso compartido de archivos SMB de Azure Files. Debería haber copiado esto en el paso 17. Se verá como \\packerstoragemvp.file.core.windows.net\appinstalls

Haga clic en Save en la parte superior.

El siguiente requisito aquí es crear una conexión de servicio para que DevOps pueda autenticarse sin problemas durante la creación de la imagen.

Paso 26. DevOps: conexión de servicio de Azure.

En su proyecto DevOps en la parte inferior izquierda haga clic en Project settings, luego haga clic en Service Connections. 

En la sección de pipelines. Haga clic en New service connection y seleccione Azure Resource Manager:

Haga clic en Next

Seleccione Service principal (automatic) y haga clic en Next.

En la sección New Azure service connection, seleccione su suscripción de Azure (es posible que se le soliciten nuevamente sus credenciales de Azure). Seleccione el grupo de recursos creado previamente

Déle a la conexión un nombre y, opcionalmente, una descripción.

Haga clic en Save en la parte inferior, esto creará su conexión de servicio de suscripción de Azure DevOps.

Entonces ahora tiene dos conjuntos de variables. Uno almacenado en su almacén de claves, el otro en el propio proyecto.

Esto ahora significa que la sección de variables del archivo packer-win10_1903.json en el repositorio tiene sentido.

Estas son las variables que ya hemos definido y ahora deberían ser obvio con lo que se relacionan.

Dentro de la sección de Builders(constructores) están los valores para el grupo de recursos temporal donde se compila la imagen, así como la red virtual permanente que debe existir para colocar la VM.

Paso 27. Cree una red virtual para que la imagen de la VM en la plantilla resida

Muy importante, necesitamos crear una red virtual sobre la cual residirá la VM de la que tomamos la imagen. Como es probable que construya muchas de estas imágenes, la red virtual debe ser permanente (no tiene costo), por lo que mantenemos esto en el grupo de recursos junto con los otros elementos que también son permanentes.

La red virtual y la subred definidas en las líneas 41 y 42 deben crearse ahora mismo en el grupo de recursos definido en la línea 44 de la imagen anterior.

Entonces, como resumen antes de comenzar un pipeline de compilación:

• Hemos creado un proyecto DevOps, en el que hemos cargado las plantillas estándar de implementación y actualización de WVD ARM.
• También hemos subido dos plantillas JSON para la construcción de una imagen de Windows 10 1903 y 1909.
• Hemos creado un recurso compartido de archivos de Azure con el software ubicado en él para su uso en esa compilación.
• Hemos creado una bóveda de claves para almacenar secretos confidenciales, que llamamos desde las plantillas de compilación, así como para almacenar otras variables dentro del proyecto.

Crear un pipeline de complicación (Build pipeline)

Entonces, lo siguiente que debe hacer es crear build pipeline para construir nuestra primera imagen. A partir de esta imagen crearemos un grupo de hosts con varios hosts de sesión basados en esta imagen. Esta imagen es tu imagen corporativa.

Un build pipeline es una colección de tareas de tipo de compilación combinadas para producir código, una aplicación, infraestructura y, en nuestro caso, una máquina virtual con Windows 10 que se convierte en una imagen. La compilación en realidad ocurre desde un agente hospedado que es una VM genérica detrás de escena que ejecuta su canalización y produce la salida.

Paso 28. De vuelta en Azure DevOps, seleccione Pipelines/ Pipelines.

Haga clic en Create pipeline

Seleccione Use the classic editor en la parte inferior.

Seleccione Azure Repos Git y haga clic en Continue.

Seleccione comenzar con Empty job.

Paso 29. Déle a su trabajo un nombre corto pero significativo. Este nombre también se usará para el nombre de la imagen que se crea al final de este proceso de compilación.

Seleccione windows-2019 como la especificación del agente.

En la sección Agent Job 1, haga clic en +

A la derecha, escriba packer en el campo de búsqueda y luego seleccione "Packer Tool Installer"

Paso 30. Ahora repita estos pasos y agrege las siguientes cuatro tareas restantes:

La tarea Build machine image

La tarea Copy files

La tarea Variable save task

Finalmente, la tareas Publish build artifacts

Ahora debería tener una lista de tareas de compilación en su pipeline que se ve así:

Ahora necesitamos aplicar algunas configuraciones para algunas de estas tareas.

Paso 31. Haga clic en Agent job 1.

A la derecha, cambie el nombre para mostrar a algo más apropiado, como Packer Build.

Paso 32. Haga clic en la tarea Use Packer.


Modifique el nombre para mostrar y agregue 1.3.4 y en el campo Versión ingrese 1.3.4

Paso 33. Vaya a la tarea Build immutable image.


Cambie Packer template a User provided:

En Packer template location, busque el archivo packer-win10_1903.json de su repositorio.

Haga clic en OK

En Template parameters, elimine el {} existente y pegue lo siguiente:

{"client_id":"$(PackerDevopsVMProvisioningServicePrincipalAppID)","client_secret":"$(PackerDevopsVMProvisioningServicePrincipalSecret)","AppInstallsStorageAccountName":"$(AppInstallsStorageAccountName)","AppInstallsStorageAccountKey":"$(AppInstallsStorageAccountKey)"}

Ahora haga clic en los puntos suspensivos a la derecha para confirmar en un formato más legible las variables que acaba de pegar.

Desplácese hacia abajo a la sección Output y en el campo Image URL or Name ingrese BuildImage.

Paso 34. Seleccione la tarea Copy files to:

Cambie el nombre para mostrar a Copy files to: $ (build.artifactstagingdirectory)

En el campo Source Folder busque ARM Templates en el repositorio y seleccionela.

En el campo Target Folder, pegue $ (build.artifactstagingdirectory)

Su tarea Copy files to: ahora debería verse así:

Paso 35. Seleccione la tarea Save Build Variables

Cambie el nombre para mostrar a: Save Build Variables BuildImage. Cambie Prefixes a: BuildImage.

Esta tarea ahora se verá así:

Paso 36. Seleccione la tarea Publish Artifact

Cambie el nombre para mostrar a: Publish Artifact: Build Image and WVD Template.

Cambie Artifact name a: Build Image.

Ahora se verá así:

Paso 37. También necesitamos algunas variables adicionales para este específico pipeline.

En la parte superior, haga clic en Variables:

Haga clic en Variable groups y luego en Link variable group

Haga clic en el botón de radio a la izquierda de Azure Key Vault Variables (8).

Haga clic en Link en la parte inferior.

Repita esto para su grupo My variables (4):

Paso 38. Es importante guardar este pipeline.

En la parte superior, haga clic en el menú desplegable del botón Save & queue y luego haga clic en Save.

Resumen del pipeline

Por lo tanto, acabamos de construir un DevOps Build Pipeline. Este pipeline:

• Instala Packer 1.3.4.
• Luego construye una máquina virtual de Azure con Packer. Esta compilación utiliza cuatro variables seguras en Key Vault. Crea una variable de salida de BuildImage.
• Copia los contenidos de la carpeta ARM Templates que son las plantillas ARM de compilación y actualización de nuestro Repo en el directorio de artefactos de compilación. Luego se pueden usar en nuestros pipelines de lanzamiento para crear un nuevo grupo de hosts o actualizar uno existente.
• Luego convierte nuestras variables en artefactos, para que se conserven y estén disponibles para su uso más adelante en el pipeline de lanzamiento (release pipeline).
• También usa las otras variables necesarias en este pipeline que no están almacenadas en Key Vault.

Es muy probable que necesite editar este pipeline, para hacerlo. Regrese a la sección de Pipelines, haga clic en Pipelines.

La vista ahora ha cambiado y muestra su pipeline "Windows 10 1903 build". Haga clic en el pipeline y la pantalla resultante es donde lo ejecutaría. Pero en la parte superior derecha hay un botón Edit. Al hacer clic en él, vuelve a la sección Editar, donde acabamos de crear el pipeline.

Ahora está listo para ejecutar esta compilación de Windows 10 1903 Multi-Session

Paso 39. Ejecutar el Build Pipeline.

Si está editando el pipeline, la forma más fácil de comenzar la compilación es hacer clic en el botón Queue en la parte superior derecha.

En la pantalla Run pipeline, haga clic en Run en la parte inferior:

Su build comenzará ahora.

Haga clic en Packer Build en la sección Jobs para ver el progreso:

El progreso y los errores se mostrarán en la ejecución del trabajo:

Esto ahora creará un nuevo grupo de recursos llamado PackerBuild-Temp y comenzará a implementar cierta infraestructura en él (VM, IP pública, NIC, disco) para construir una imagen. La imagen resultante se volverá a colocar en el grupo de recursos PackerBuild, por lo que se conserva de forma permanente.

El grupo de recursos PackerBuild-Temp se eliminará al final de este pipeline.

Esto ahora dejará una imagen en su grupo de recursos PackerBuild llamada:

Windows-10-1903-Build- "Fecha y hora" - "Build No." como se muestra a continuación:

Su job de build pipeline habrá finalizado y debería demorar aproximadamente 10 minutos; también recibirá un correo electrónico a tal efecto de notificaciones de Azure DevOps.

Puede confirmar que los artefactos se han publicado correctamente haciendo clic en la sección Packer Build en la parte superior y luego haciendo clic en el enlace 1 artifact produced

Ese enlace lo llevará a los artefactos que se verán así:

Solución de problemas. Cosas que podrían salir mal:

• Tiene errores tipográficos en los nombres de las variables de Azure Key Vault o las variables de DevOps.
• Tiene errores en el nombre o las rutas para su recurso compartido de archivos de Azure. Asegúrese de que los nombres y las rutas sean los definidos en la plantilla JSON.
• Los archivos de instalación cmd o los archivos PS1 no son correctos.

¿Cómo se crea una imagen de compilación de Windows 10 1909?

Todo lo que tiene que hacer es reemplazar las referencias a 1903 con 1909 en el pipeline existente, y seleccionar el archivo packer-win10_1909.json en Packer template location, en la tarea Build immutable image dentro del build pipeline:

Este es exactamente el mismo proceso para construir una compilación de 20nn (20h1) cuando se lanza.

Construir un pipeline de lanzamiento (release pipeline)


Ahora necesitamos construir un pipeline de lanzamiento (release pipeline) que tomará nuestra imagen recién creada y los artefactos de la compilación y luego compilará un nuevo grupo de hosts o actualizará uno existente.

Mi caso de uso aquí, solo como recordatorio es que usted es un profesional de TI que conoce WVD pero no ADO. En ese caso, es probable que ya haya realizado muchas implementaciones de Host Pool, pero ahora desea un método simple, rápido, repetible y confiable para actualizar los hosts de sesión en el pool de hosts.

En este proceso, crearemos un nuevo grupo de hosts solo para mostrar el proceso y luego lo actualizaremos mediante una implementación continua (Continous Deployment).

Paso 40. En ADO ve a Pipelines/Relases

Luego haga clic en New pipeline. Luego haga clic en Empty job

Paso 41. Déle un nombre a su grupo de hosts.

Haga clic en el botón Save en la parte superior y guárdelo en la carpeta predeterminada.

Haga clic en OK

Paso 42. Haga clic en el enlace de la tarea (1 job, 0 task) en la étapa de actualización que acaba de crear.

Haga clic en Agent job y luego en Agent Specification seleccione windows-2019.

Haga clic en Save en la parte superior y OK

Paso 43. Vaya a la pestaña Options en la parte superior

Reemplace el formato del nombre de release con: REL $ (rev: r). Esto se usará en la asignación de nombres de host de sesión, y es importante que se reemplace ya que sin el nombre de la VM será demasiado largo.

Haga clic en Save en la parte superior y luego OK

Paso 44. Vaya a la pestaña Pipeline en la parte superior, allí ahora vamos a agregar un nuevo artefacto, para ello hacemos clic en +Add an artifact

El tipo de origen de compilación es el predeterminado, su proyecto ADO se seleccionará en el campo Project.

En el menú desplegable Source (build pipeline), seleccione su pipeline de compilación de Windows 10 1903. En Default version debe ser Latest

En Source alias, asígnele un nombre apropiado: Latest Windows 10 1903 Build Artifacts

Haga clic en Add

Paso 45. Regrese y edite la tarea nuevamente. Esto es similar al proceso de creación de Build Pipeline.

Agregar una tarea Variable Load Task. Buscar load variable.

Seleccione Variable Load Task y haga clic en Add.

Paso 46. Agregar una tarea Azure resource group deployment

Haga clic en Add.

Paso 47. Las variables de construcción de carga no necesitan ningún cambio. Esto copiará las variables de la compilación a la versión.

En el grupo de recursos de Azure, necesitamos realizar algunas actualizaciones.

Regrese a la tarea de Azure resource group deployment. Ahora actualice las siguientes secciones:

• La suscripción de Azure.
• La acción predeterminada está bien para Create or update resource group.
• El grupo de recursos en el que desea que se creen los recursos del conjunto de hosts.
• La ubicación deseada.

Un poco más adelante en la sección Template, la ubicación de la plantilla es "Linked artifact".

Luego navegue dentro del campo Plantilla y seleccione su archivo mainTemplate.json:

En Override template parameters, pegue el siguiente texto:

-_artifactsLocation "https://raw.githubusercontent.com/Azure/RDS-Templates/master/wvd-templates/" -_artifactsLocationSasToken "" -rdshImageSource CustomImage -vmImageVhdUri "" -rdshGalleryImageSKU "Windows-10-Enterprise-multi-session-with-Office-365-ProPlus" -rdshCustomImageSourceName $(BuildImage) -rdshCustomImageSourceResourceGroup $(wvd_goldimage_rg) -rdshNamePrefix VM-WVD-$(Release.ReleaseName) -rdshNumberOfInstances 1 -rdshVMDiskType Premium_LRS -rdshVmSize Standard_D2s_v3 -enableAcceleratedNetworking false -rdshUseManagedDisks true -storageAccountResourceGroupName "" -domainToJoin LOCALAD -existingDomainUPN $(DomainJoinAccountUpn) -existingDomainPassword $(DomainJoinAccountPassword) -ouPath OU=WVD,DC=LOCALAD,DC=COM -existingVnetName YOURVNET -newOrExistingVnet existing -existingSubnetName YOURSUBNET -virtualNetworkResourceGroupName YOURRG -rdBrokerURL https://rdbroker.wvd.microsoft.com -existingTenantGroupName "Default Tenant Group" -existingTenantName YOURTENANT -hostPoolName YOURHOSTPOOL -serviceMetadataLocation United-States -enablePersistentDesktop false -defaultDesktopUsers AUSERACCOUNT -tenantAdminUpnOrApplicationId $(WVDServicePrincipalAppID) -tenantAdminPassword $(WVDServicePrincipalSecret) -isServicePrincipal false -aadTenantId $(az_tenant_id) -location "North Europe"

Luego, a la derecha de este campo, haga clic en la elipse. Esto mostrará las variables en un formato más fácil de leer y mostrará cualquier error si hay alguno.

Notará que algunos artículos están en MAUSCULA. Estos son valores que debe cambiar para reflejar su entorno. Actualizarlos es un poco más fácil en esta interfaz de usuario.

Los valores que deberán actualizarse son:

• domainToJoin: este es su nombre de dominio FQDN
• existnigVnetName: este es su vnet en el que los hosts de sesión WVD deben residir, es decir, uno que tenga acceso a su AD DC.
• existingSubnetName: la subred en la red virtual anterior.
• VirtualNetworkResourceGroupName: el RG en el que se encuentra la vNet anterior.
• existingTenantName: su nombre de tenant de WVD.
• HostPoolName -Su nombre de host pool WVD.
• defaultDesktopUsers: una cuenta de usuario para presentar este escritorio publicado.

En el modo de implementación, seleccionaremos Incremental, que implementará toda la infraestructura nueva y dejará todo lo que no esté en la plantilla. Tenga en cuenta que puede hacer una validación de la plantilla si selecciona el modo Validar.

Haga clic en Save en la parte superior y OK.

Paso 48. Elimine el desencadenador de condición previa a la implementación. Actualmente, esta tarea se iniciará automáticamente cuando se complete una nueva compilación y se cree un nuevo artefacto. Lo eliminaremos.

Regrese al pipeline en la parte superior.

Haga clic en el botón Pre-depoyment conditions

Luego seleccione el trigger Manual only

Haga clic en Save en la parte superior y OK.

Paso 49. Agregue las variables a la versión.

Haga clic en Variables en la parte superior y seleccione Variable groups. luego haga clic en Link variable group

Seleccione Azure Key Vault Variables y luego haga clic en Link

Repita esto para el grupo My variables y haga clic en Link en la parte inferior.

Haga clic en Save en la parte superior y OK.

Paso 50. Cree el nuevo grupo de hosts con este pipeline

Vuelva a la pestaña Pipeline en la parte superior y luego seleccione Create release al lado derecho.

Ahora Deploy Host Pool es manual, por lo que no se puede activar aquí, así que simplemente haga clic en Create en la parte inferior y lo iniciaremos manualmente.

Ahora se ha creado una versión pero aún no se está ejecutando nada.

Haga clic en el enlace "REL-no".

Ahora, en la sección Stages, desplace el cursor sobre Deploy Host Pool y verá debajo en la parte inferior el botón Deploy, haga clic sobre él.

Luego, haga clic en Deploy

El stage cambia a Queued y luego a In progress.

Al hacer clic en In progress lo direcciona al progreso del release.

La plantilla ARM ahora se está ejecutando e implementando un grupo de hosts como de costumbre, pero con los detalles que hemos especificado en las variables y secciones de texto anteriores.

Cuando esto se complete, tendrá un nuevo grupo de recursos de Azure con todos los recursos necesarios para este nuevo grupo de hosts WVD.

Además, también habrá creado el nuevo grupo de hosts y presentado el grupo escritorio predeterminado al usuario que especificó en el paso 46.

Paso 51. Cree una tarea Update host pool.

Ahora crearemos la tarea Actualizar un host pool y luego habilitaremos la implementación continua para esta versión, de modo que cada vez que construyamos una nueva imagen a través de Build Pipeline, se inicie automáticamente la el pipeline de lanzamiento (release pipeline) para actualizar los host pool existentes.

Utilizaremos el nuevo grupo de hosts recién creado para actualizar.

Vuelva a sus Release pipeline y haga clic en Edit.

En Stages, haga clic una vez en la tarea Deploy host pool para que se seleccione.

Haga clic en el botón desplegable + Add y seleccione Clone stage.

Esto creará una tarea que sigue a la tarea Implementar un nuevo grupo de hosts, que es lo que no queremos.

Haga clic en el botón Pre-deployment conditions

Cambie el trigger a After Release:

Esta opción inicia esta nueva tarea una vez que se completa la compilación, que aún no tiene habilitada la implementación continua, todavía.

Su pipeline ahora debería verse así:

Paso 52. Necesitamos modificar esta tarea para hacer una actualización.

Haga clic en el enlace en la tarea.

Cambie el nombre de esta tarea a: "Update Host Pool".

Haga clic en Save en la parte superior y OK.

Load Build Variables está bien tal como está.

Haga clic en la tarea de implementación de Azure.

Modifique el nombre para mostrar elimine "Create or"

Las otras configuraciones son las mismas que en la tarea Implementar. Sin embargo, necesitamos cambiar la plantilla que estamos usando de la plantilla principal a la plantilla de actualización

En el campo Template, haga clic en los puntos suspensivos a la derecha y busque el archivo UpdateTemplate.json.

Haga clic en OK.

En Override template parameters, pegue el siguiente texto:

-_artifactsLocation "https://raw.githubusercontent.com/Azure/RDS-Templates/master/wvd-templates/" -_artifactsLocationSasToken "" -rdshImageSource CustomImage -vmImageVhdUri "" -rdshGalleryImageSKU "Windows-10-Enterprise-multi-session-with-Office-365-ProPlus" -rdshCustomImageSourceName $(BuildImage) -rdshCustomImageSourceResourceGroup $(wvd_goldimage_rg) -rdshNamePrefix VM-WVD-$(Release.ReleaseName) -rdshNumberOfInstances 1 -rdshVMDiskType Premium_LRS -rdshVmSize Standard_D2s_v3 -enableAcceleratedNetworking false -rdshUseManagedDisks true -storageAccountResourceGroupName "" -domainToJoin LOCALAD -existingDomainUPN $(DomainJoinAccountUpn) -existingDomainPassword $(DomainJoinAccountPassword) -ouPath OU=WVD,DC=LOCALAD,DC=com -existingVnetName YOURVNET -newOrExistingVnet existing -existingSubnetName YOURSUBNET -virtualNetworkResourceGroupName YOURRG -rdBrokerURL https://rdbroker.wvd.microsoft.com -existingTenantGroupName "Default Tenant Group" -existingTenantName YOURTENANT -existingHostpoolName WYOURHOSTPOOL -serviceMetadataLocation United-States -enablePersistentDesktop false -tenantAdminUpnOrApplicationId $(WVDServicePrincipalAppID) -tenantAdminPassword $(WVDServicePrincipalSecret) -isServicePrincipal false -aadTenantId $(az_tenant_id) -actionOnPreviousVirtualMachines "Delete" -userLogoffDelayInMinutes 1 -userNotificationMessage "Scheduled maintenance, please save your work and logoff as soon as possible" -location "North Europe"

Nuevamente, haga clic en la elipse en el lado derecho, esto leerá sus variables y notará que algunos elementos están en MAYUSCULA. Estos son valores que debe cambiar para reflejar su entorno. Actualizarlos es un poco más fácil en esta interfaz de usuario. Estos son exactamente los mismos que antes, recuerde que ahora estamos ejecutando la plantilla de actualización, no la plantilla de implementación, hay algunas diferencias.

Reemplace los elementos en mayuscula con los valores de su entorno.

Haga clic en Save en la parte superior y OK.


Paso 53. Ahora implementaremos este pipeline de lanzamiento para actualizar las máquinas virtuales en nuestro grupo de hosts existente.

Haga clic en Create release en la parte superior.

La tarea Update host ahora se resalta para mostrar que esta tarea es automática y tan pronto como hagamos clic en Create el release pipeline comenzará. Esto es diferente a la tarea de implementación que es manual.

Haga clic en Create en la parte inferior

La tarea de lanzamiento ya ha comenzado.

Haga clic en release-no.

Esto le mostrará el progreso de esta tarea:

También puede ver el progreso volviendo al portal de Azure, yendo al grupo de recursos y luego haciendo clic en Implementaciones. Verá esta implementación en progreso.

Al hacer clic en la implementación, se le mostrarán más detalles y esta es la salida de la plantilla ARM estándar, a la que sin duda está acostumbrado si ya ha realizado implementaciones de WVD.

El último paso es habilitar el trigger de implementación continua que significará que cuando cree una nueva imagen, actualizará automáticamente su grupo de hosts.

Regrese a su pipeline de lanzamiento.

En la sección Artefacts, haga clic en el botón del trigger Continous Deployment y actívelo.

Haga clic en Save en la parte superior y OK.

Cuando el el tigger es manual el pipeline luce de la siguiente forma:

Nótese la palabra Manually triggered

Ahora veamos como luce nuestro pipeline con Continous Deployment habilitado, lo cual significa que epnas creemos una nueva build se implementará de forma automática:

Nótese ahora la palabra Continuous deployment la cual se desató de forma automática una vez lancé una nueva build.

La próxima vez que actualice su imagen ejecutando Build Pipeline ADO actualizará automáticamente su grupo de hosts con esta nueva imagen.

Ya terminaste, bien hecho por seguir con esto.

Esto muestra el poder que Azure DevOps puede aportar a una implementación de WVD. Le ahorra tiempo de implementación, errores y resolución de problemas, y le brinda un método confiable y repetible para crear una Imagen y para actualizar todos sus grupos de hosts existentes, así como para crear nuevos.

Esta guía solo trata la superficie de la capacidad, pero con suerte es suficiente para aprender los conceptos básicos y usarla en mayor medida, como lo he hecho yo.

Hay muchas otras características y capacidades que podrían usarse dentro de este proceso, como las pruebas automatizadas, pero que podrían agregarse a un artículo de la "Parte 2".

Gracias