La mayoría de los días, desea pasar el menor tiempo posible dedicado a la forma de implementar un entorno de aplicación y dedicarse a la implementación real. En muchos entornos de TI, se están comenzando a ver equipos de desarrollo y operaciones que colaboran y trabajan estrechamente, y se escucha el término de moda DevOps en muchas conferencias y blogs.
No hay nada inherentemente nuevo o innovador sobre la cultura DevOps, pero es común que los diferentes equipos no trabajen con conjunto como debieran hacerlo. Las herramientas modernas han impulsado el movimiento DevOps, con soluciones de integración continua y entrega continua (CI/CD) capaces de automatizar toda la implementación de entornos de aplicaciones basándose en un único código comprobado por un desarrollador. El equipo de operaciones suele ser el que compila y mantiene estos procesos CI/CD, haciendo posible pruebas e integraciones más rápidas de las actualizaciones de aplicaciones para los desarrolladores.
El modelo de implementación de Azure Resource Manager es fundamental para la forma en que se compilan y ejecutan los recursos, aunque probablemente todavía no se haya dado cuenta. Resource Manager es un método para compilar e implementar recursos, tanto como los procesos de automatización y las plantillas que impulsan esas implementaciones. En este capítulo, aprenderá a utilizar las funciones de Resource Manager, como controles de acceso y bloqueos, implementaciones de plantillas coherentes e implementaciones de múltiples niveles automatizadas.

El enfoque de Azure Resource Manager
Cuando creó una VM o una aplicación web en capítulos anteriores, primero se creó un grupo de recursos como la construcción central para contener todos sus recursos. Un grupo de recursos es central para todos los recursos: una VM, una aplicación web, una red virtual o una tabla de almacenamiento no pueden existir fuera de un grupo de recursos. Pero el grupo de recursos es más que un simple lugar para organizar sus recursos, mucho más. En esta sección se echa un vistazo al modelo de Azure Resource Manager subyacente y se muestra por qué es importante para compilar y ejecutar aplicaciones.

Diseño alrededor del ciclo de vidas de las aplicaciones
Idealmente, cuando se compila una aplicación es sumamente importante mantenerla. Por lo general, tiene actualizaciones que desarrollar e implementar, nuevos paquetes que instalar, nuevas VM que agregar y ranuras de implementación de aplicaciones web adicionales que crear. Es posible que deba realizar cambios en la configuración de la red virtual y en las direcciones IP. En capítulos anteriores mencioné que sus redes virtuales en Azure pueden ser administradas por un equipo diferente. Empiece a pensar en cómo ejecutar en una escala global, grande, y en términos del ciclo de duración y administración de las aplicaciones.
Tiene un par de enfoques principales para agrupar los recursos en Azure:
– Todos los recursos de una aplicación determinada en el mismo grupo de recursos: como se muestra en la figura siguente, este enfoque funciona bien para aplicaciones más pequeñas y para entornos de desarrollo y pruebas. Si no necesita compartir espacios de red grandes y puede administrar individualmente el almacenamiento, puede crear todos los recursos en un lugar y, a continuación, administrar las actualizaciones y los cambios de configuración mediante una sola operación.

– Recursos afines agrupados por función en el mismo grupo de recursos: como se muestra en la figura, este enfoque suele ser más común en aplicaciones y entornos más grandes. La aplicación puede existir en un grupo de recursos solo con las VM y los componentes de aplicación compatibles. Los recursos de red virtual y las direcciones IP pueden existir en un grupo de recursos diferente, protegidos y administrados por un grupo diferente de ingenieros.

¿Por qué hay diferentes enfoques? La respuesta no se relaciona completamente con asegurar el trabajo ni con los silos con que algunos equipos prefieren trabajar. Se trata de cómo necesita administrar los recursos subyacentes. En entornos y aplicaciones más pequeños donde todos los recursos existen en el mismo grupo de recursos, usted es responsable de todo en ese entorno. Este enfoque también es adecuado para desarrollo y los entornos de prueba donde todo está empaquetado junto. Los cambios que realice a la red virtual solo afectarán a su aplicación y grupo de recursos.
La verdad es que las redes no cambian de manera frecuente. Los rangos de direcciones suelen estar bien definidos y planificados, de modo que pueden coexistir a través de Azure y oficinas en todo el mundo. Lógicamente, a menudo tiene sentido colocar los componentes de red en su propio grupo de recursos. La red se administra separadamente de la aplicación y el almacenamiento puede administrarse y actualizarse separadamente de la misma manera. No hay nada inherentemente malo en dividir los recursos de esta forma, siempre y cuando el personal de TI no se quede atascado en una mentalidad de silo, ya que resulta en falta de cooperación.
Para sus aplicaciones, la división de recursos también puede ser una ventaja, ya que tiene la libertad suficiente para hacer los cambios y actualizaciones que desee. Precisamente porque no tiene los componentes de red en el grupo de recursos, no necesita preocuparse por ellos cuando realice actualizaciones de las aplicaciones.

Protección y control de recursos
Cada recurso puede tener diferentes permisos de seguridad aplicados. Estas directivas definen quién puede hacer qué. Piénselo: ¿desea que un alumno en práctica reinicie su aplicación web o elimine los discos de datos de la VM? ¿Y cree que sus amigos del equipo de redes quieren que usted cree una nueva subred de red virtual? Probablemente no. En Azure, hay cuatro roles principales que puede asignar a los recursos, similar a los permisos de archivo:
– Propietario: control completo, básicamente un administrador
– Colaborador: administración completa del recurso, excepto para realizar cambios en las asignaciones de roles y seguridad
– Lector: capacidad de ver toda la información del recurso, pero no puede realizar cambios.
– Administrador de acceso de usuarios: capacidad de asignar o eliminar el acceso a los recursos.
El control de acceso basado en roles (RBAC) es una función principal de Azure Resources que se integra automáticamente con las cuentas de usuario en sus suscripciones. Piense en los permisos de archivo en su equipo normal. Los permisos de archivo básicos son leer, escribir y ejecutar. Cuando se combinan estos permisos, se pueden crear diferentes conjuntos de permisos para cada usuario o grupo del equipo. Al trabajar con recursos compartidos de archivos de red, los permisos son herramientas comunes para controlar el acceso. RBAC en Azure trabaja en las mismas líneas para controlar el acceso a los recursos, al igual que los permisos de archivo en su equipo local o en red compartida.

Pruébelo ahora
Abra Azure Portal en un navegador web y, a continuación, seleccione cualquier recurso que tenga, como cloud-shell-storage. Elija el botón Control de acceso (IAM), como se muestra en la figura. Revise las asignaciones de roles actuales. Vea cómo agregar una asignación de roles y explore todas las asignaciones disponibles. El icono de información de cada rol muestra qué permisos se asignan.
A medida que explora las roles disponibles, puede observar varios roles específicos de los recursos, entre ellos:
– Colaborador de máquina virtual
– Colaborador de sitio web
– Colaborador de red
¿Puede adivinar qué significan esos roles? Toman la función de Colaborador de la plataforma principal y lo aplican a un tipo de recurso específico. Este caso de uso se remonta al concepto de manejar los recursos afines. Es posible que se le haya asignado el rol de colaborador de máquina virtual o de sitio web. A continuación, cualquier VM o aplicaciones web creadas en ese grupo de recursos estarán disponibles para que usted las administre. Pero no puede administrar los recursos de red, que pueden estar en un grupo de recursos completamente diferente.

Protección de recursos con bloqueos
El enfoque basado en permisos de RBAC es genial para limitar quién puede acceder a qué. Pero los errores siempre ocurren. Hay una razón por la que normalmente no inicia sesión en un servidor como usuario con permisos administrativos o raíz. Una tecla o clic incorrecto, y podría eliminar recursos por equivocación. Aunque tenga copias de seguridad (las tiene, ¿verdad? ¿y las prueba periódicamente?), es un proceso que requiere mucho tiempo y que puede significar pérdida de productividad o ingresos para el negocio.
Otra función incorporada al modelo de Resource Manager son los bloqueos de recursos. Cada recurso puede tener un bloqueo aplicado que lo limita para acceso solo de lectura o impide las operaciones de eliminación. El bloqueo de eliminación es particularmente útil, ya que puede ser demasiado fácil eliminar el grupo de recursos incorrecto. Cuando se inicia una operación de eliminación, no hay vuelta atrás ni se puede cancelar la operación después de que la plataforma Azure ha aceptado su solicitud.
Para las cargas de trabajo de producción, le sugiero que implemente bloqueos en los recursos principales para evitar que se eliminen. Estos bloqueos son solo en los niveles de recursos y plataformas Azure, y no para los datos dentro de sus recursos. Por ejemplo, puede eliminar archivos dentro de una VM o eliminar la tabla de una base de datos. Los bloqueos de recursos Azure solo se aplicarían si intentó eliminar toda la base de datos de VM o Azure SQL. La primera vez que se inicie un bloqueo y evite la eliminación del grupo de recursos incorrecto, ¡me lo agradecerá!

Pruébelo ahora
Complete los siguientes pasos para ver los bloqueos de recursos Azure en acción, como se muestra en la figura:
1 Abra Azure Portal en un navegador web y, a continuación, seleccione cualquier grupo de recursos que tenga, como cloud-shell-storage.
2 Seleccione Bloqueos en el lado izquierdo del portal.
3 Escriba un Nombre de bloqueo, como Proteger; elija Eliminar del menú desplegable Tipo de bloqueo; elija Aceptar. El nuevo bloqueo aparece en la lista.
4 Seleccione Descripción general para el grupo de recursos y, a continuación, intente eliminar el grupo de recursos. Debe escribir el nombre del grupo de recursos para confirmar que desea eliminarlo (lo que es además un buen aviso mental para asegurarse de que va a eliminar el recurso correcto).
5 Cuando elija el botón Eliminar, revise el mensaje de error que se muestra para ver cómo el bloqueo impidió que Azure eliminara el recurso.

Administración y agrupación de recursos con etiquetas
Una última función del modelo Azure Resource Manager que queremos mencionar son las etiquetas. No hay nada nuevo o especial acerca de cómo etiquetar recursos en Azure, pero este concepto de administración suele pasarse por alto. Puede aplicar etiquetas a un recurso de Azure que describa propiedades como la aplicación de la que forma parte, el departamento responsable de la misma, o si se trata de un recurso de desarrollo o de producción.
A continuación, puede identificar recursos basándose en las etiquetas para aplicar bloqueos o roles RBAC, o informar sobre los costos y el consumo de los recursos. Las etiquetas no son exclusivas de un grupo de recursos y pueden reutilizarse en su suscripción. Se pueden aplicar hasta 50 etiquetas a un único recurso, por lo que tiene mucha flexibilidad en la forma de etiquetar y luego filtrar los recursos etiquetados.
Pruébelo ahora
Complete los siguientes pasos para ver las etiquetas de recursos de Azure en acción:
1 Abra Azure Portal en un navegador web y, a continuación, seleccione cualquier recurso que tenga, como cloud-shell-storage. Aunque puede etiquetar un grupo de recursos por sí mismo, no elija un grupo de recursos para este ejercicio
2 Con su recurso seleccionado, elija el botón Etiquetas, como se muestra en la figura.
3 Escriba un Nombre, como workload y un Valor, como development.
4 Seleccione Guardar.
5 Abra Cloud Shell.
6 Para filtrar los recursos basados en etiquetas, utilice la lista de recursos az con el parámetro –tag. Utilice su propio nombre y valor de la siguiente manera:

Plantillas de Azure Resource Manager
Hasta ahora, ha creado un pequeño número de recursos Azure a la vez. Para ello, utilizó Azure Portal o la CLI de Azure. Aunque no le hemos mostrado Azure PowerShell, hablamos acerca de este en el primer capítulo y está disponible en Cloud Shell. Tal vez lo haya probado sin mí.
Azure tiene herramientas que le permiten elegir lo más cómodo para usted y el entorno en el que trabaja.
La desventaja de utilizar el portal o los comandos CLI o PowerShell es que debe hacer clic en un montón de botones del navegador web o escribir líneas de comandos para compilar el entorno de la aplicación. Puede crear scripts para hacer todas estas cosas, pero luego debe crear la lógica para controlar la forma de crear varios recursos al mismo tiempo o el orden en el que crearlos.
Un script que reúne los comandos de la CLI de Azure o PowerShell comienza a moverse en la dirección correcta en términos de cómo debe compilar e implementar entornos de aplicaciones, no solo en Azure, sino en cualquier plataforma. Hay una tendencia hacia la infraestructura como código (IaC), que no es nada nuevo si ha estado en el mundo de TI durante algún tiempo. Básicamente, significa que no confía en un humano para escribir comandos y seguir un conjunto de pasos; en lugar de ello, crea su infraestructura mediante programación a partir de un conjunto de instrucciones. Las implementaciones manuales introducen un elemento humano que a menudo puede conducir a pequeñas configuraciones erróneas y diferencias en las VM finales.

Incluso cuando tiene scripts, todavía necesita que alguien los escriba, mantenga y actualice a medida que se liberan las nuevas versiones de los módulos CLI de Azure o PowerShell. Sí, a veces hay cambios importantes en las herramientas para acomodar las nuevas funciones, aunque son raras.

Creación y uso de plantillas
Las plantillas de Resource Manager pueden ayudar a reducir el error humano y la dependencia de scripts escritos manualmente. Las plantillas se escriben en JavaScript Object Notation (JSON), un enfoque abierto, estándar y multiplataforma que permite editarlas en un editor de texto básico. Con las plantillas, puede crear implementaciones uniformes y reproducibles que minimicen los errores. Otra función incorporada de las plantillas es que la plataforma comprende las dependencias y puede crear recursos en paralelo cuando sea posible para acelerar el tiempo de implementación. Por ejemplo, si crea tres VM, no es necesario esperar a que la primera VM finalice la implementación antes de crear la segunda; Resource Manager puede crear las tres VM al mismo tiempo.
Como ejemplo de las dependencias, si crea una NIC virtual, es necesario conectarla a una subred. Lógicamente, la subred debe existir antes de poder crear la NIC virtual, y la subred debe formar parte de una red virtual, por lo que esa red debe crearse antes de la subred. La figura 6.7 muestra la cadena de dependencias en acción. Si intenta escribir un script usted mismo, debe planificar cuidadosamente el orden en que se crean los recursos, e incluso después, debe crear una lógica para saber cuando los recursos primarios estén listos y pueda pasar a los recursos dependientes.

¿Quiere saber algo asombroso? Ya utilizó plantillas de Resource Manager en una entrada anterior y en la primera VM que creó. Al crear una VM en el portal o en la CLI de Azure, a la vez se crea y se implementa una plantilla mediante programación. ¿Por qué? Bueno, ¿para qué reinventar la rueda y pasar por el proceso de desarrollar toda esa lógica para las implementaciones? ¡Deje que Azure Resource Manager lo haga automáticamente!
Así es cómo se ve una sección de una plantilla de Resource Manager. El siguiente listado muestra la sección que crea una dirección IP pública, tal como en ejemplos anteriores cuando creó una VM.

Creación de una dirección IP pública en una plantilla de Resource Manager
{
«apiVersion»: «2019-04-01»,
«type»: «Microsoft.Network/publicIPAddresses»,
«name»: «publicip»,
«location»: «eastus»,
«properties»: {
«publicIPAllocationMethod»: «dynamic»,
«dnsSettings»: {
«domainNameLabel»: «azuremol»
}
}
}

Incluso si JSON es nuevo para usted, está escrito en un formato bastante legible para el ser humano. Primero define un tipo de recurso, en este ejemplo, Microsoft.Network/publicIPAddresses. Luego, proporciona un nombre, como publicip y una ubicación, como eastus. Finalmente, define el método de asignación dynamic en este ejemplo,
y un nombre de etiqueta DNS, como azuremol. Estos son los mismos parámetros que proporcionó cuando usó Azure Portal o la CLI de Azure. Si usa PowerShell, adivine qué… Se le solicitan los mismos parámetros.
La diferencia con la plantilla es que no tenía que escribir ninguna información, Toda la información estaba en el código. Puede estar pensando: «Genial, pero ¿qué pasa si quiero usar nombres diferentes cada vez?» Al igual que con un script, puede asignarlos dinámicamente usando parámetros y variables:
– Los parámetros son valores que se le solicitan. A menudo se utilizan para las credenciales de usuario, el nombre de la VM y la etiqueta de nombre DNS.
– Se puede asignar de forma previa un valor a las variables, pero también se ajustan cada vez que se implementa la plantilla, como el tamaño de VM o el nombre de red virtual.

Creación de varios tipos de recursos
A medida que compile sus plantillas, intente ir pensando cómo podría necesitar ampliar sus aplicaciones en el futuro. Es posible que solo necesite una VM única cuando implemente por primera vez la aplicación, pero a medida que aumente su demanda, podría tener que crear instancias adicionales.
En una implementación tradicional con scripts, se crean bucles for o while para crear varios tipos de recursos. ¡Resource Manager tiene esta funcionalidad incorporada! Hay más de 50 tipos de funciones en Resource Manager, al igual que en la mayoría de los lenguajes de programación y lenguajes de scripts. Dentro de funciones comunes de Resource Manager se incluyen length, equals or y trim. Usted controla el número de instancias que se crearán con la función copy.
Cuando utilice la función copy, Resource Manager creará el número de recursos que especifique. Cada vez que Resource Manager reitera la operación Crear, habrá un valor numérico disponible para que nombre recursos de manera secuencial. Puede acceder a este valor con la función copyIndex(). En el ejemplo del listado se creó una sola dirección IP pública. En el ejemplo del listado 6.2 se utiliza el mismo tipo de proveedor de recursos Microsoft.Network/publicIPAddresses, pero se crean dos direcciones IP públicas. Utilice copy para definir cuántas direcciones desea crear y copyIndex() para nombrar las direcciones secuencialmente.

Listado Creación de varias direcciones IP públicas con copy
{
«apiVersion»: «2019-04-01»,
«type»: «Microsoft.Network/publicIPAddresses»,
«name»: «[concat(‘publicip’, copyIndex())]»,
«copy»: {
«count»: 2
}
«location»: «eastus»,
«properties»: {
«publicIPAllocationMethod»: «dynamic»,
}
}

También se utiliza la función concat para combinar el nombre de la dirección IP pública y el valor numérico de cada instancia que se crea. Una vez implementada esta plantilla, sus dos direcciones IP públicas se denominan publicip0 y publicip1. Estos nombres no son muy descriptivo, pero este ejemplo básico muestra el concepto de cómo se puede utilizar una convención de numeración a medida que se crean varios recursos de la función copy.

Herramientas para compilar sus propias plantillas
Digamos las cosas como son: si bien las plantillas de Resource Manager son claras y una de las principales formas en las que recomendamos compilar e implementar aplicaciones en Azure, necesitará escribir las plantillas de todas maneras. Un par de herramientas diferentes simplifican esta tarea, y hay disponibles cientos de plantillas de ejemplo de Microsoft y de terceros. De hecho, una de las mejores maneras de aprender cómo crear y utilizar plantillas es examinar las plantillas de inicio rápido que Microsoft pone a su disposición en su repositorio de ejemplos en https://github.com/Azure/azure-quickstart-templates.
Si quiere subirse las mangas y empezar a escribir sus propias plantillas, le recomendamos dos herramientas principales. La primera es Visual Studio Code, un editor multiplataforma, gratuito y open source (https://code.visualstudio.com). Junto con algunas funcionalidades incorporadas como control de código fuente e integración de GitHub, hay extensiones disponibles que pueden compilar automáticamente las diferentes secciones, o proveedores, para que los recursos construyan una plantilla, como se muestra en la figura 6.8. Si descarga e instala VS Code, elija a Ver > Extensiones y luego busque Azure.

Una forma más gráfica de crear plantillas de Azure Resource Manager es utilizar el editor de Visual Studio completo, como se muestra en la figura 6.9. Hay versiones para Windows y macOS, pero se necesita una licencia distinta para usar el editor. Existe una edición comunitaria, pero tenga cuidado si compila plantillas dentro de su empresa: normalmente necesita una versión con licencia. Consulte a sus expertos en licencias, porque Visual Studio está dirigido a los desarrolladores de aplicaciones.
Por supuesto, puede utilizar un editor de texto básico. Parte de la razón por la que las plantillas de Azure Resource Manager están escritas en JSON es que elimina la necesidad de cualquier herramienta especial. Hay una curva de aprendizaje para trabajar con JSON, motivo por el que le recomendamos que explore las plantillas de inicio rápido en el repositorio de ejemplos de Azure. Tenga mucho cuidado con la sangría, las comas al final, el uso de paréntesis, los corchetes y las llaves.

Almacenamiento y uso de plantillas
Así que le encanta la idea de las plantillas de Azure Resource Manager e instaló Visual Studio o Code para escribir sus propias plantillas. Ahora, ¿cómo las almacena e implementa? En el laboratorio de fin del capítulo, implementará una plantilla desde el repositorio de ejemplos de Azure en GitHub. Este repositorio es público, y probablemente no quiera que sus plantillas de aplicación estén a disposición de todo el mundo.
Hay un par de métodos comunes para almacenar las plantillas de Resource Manager de forma privada:
– Uso de un repositorio privado o un recurso compartido de archivos de red dentro de su organización.
– Uso de Azure Storage para almacenar y proteger las plantillas de forma centralizada para su implementación.
No hay manera correcta o incorrecta de almacenar e implementar plantillas, tiene la flexibilidad de utilizar cualquier proceso y herramientas existentes. La ventaja de utilizar un repositorio es que normalmente tiene algún tipo de control de versión para que pueda garantizar implementaciones uniformes y revisar el historial de sus plantillas si fuera necesario. La única limitación es que cuando se implementa la plantilla, es necesario proporcionar las credenciales apropiadas para acceder a la ubicación compartida. Este proceso de autenticación puede variar, como proporcionar un nombre de usuario o token de acceso como parte de la dirección URL a una plantilla de un repositorio o proporcionar un token de firma de acceso compartido (SAS) si utiliza Azure Storage.
Los repositorios públicos como GitHub también son grandes maneras de aprender y compartir. Le sugerimos que mantenga sus plantillas de producción almacenadas en privado, pero si crea una plantilla clara para un entorno de laboratorio o para probar algunas funciones nuevas, puede compartirla en GitHub para devolverle la mano a la comunidad de TI y ayudar a otros que quieran hacer la misma implementación. A medida que comience a compilar sus propias plantillas, asegúrese de comprobar qué plantillas ya existen para que no empiece desde cero y tenga que reinventar la rueda cada vez.

Laboratorio: Implementación de recursos de Azure desde una plantilla
Toda esta teoría sobre los modelos y enfoques de implementación es fantástica, pero (idealmente) empezará a ver las ventajas y su eficiencia cuando utilice plantillas de verdad:

1 Vaya a Ejemplos de inicio rápido de Azure en GitHub (https://github.com/Azure/azure-quickstart-templates), y encuentre uno de su interés. Un buen lugar para empezar es una simple VM Linux o Windows.
2 Hay botones incorporados en las muestras de GitHub para implementar directamente a Azure. Cuando encuentre una plantilla que le guste, seleccione Implementar en Azure, como se muestra en la figura 6.10, y siga los pasos del portal. El proceso es muy parecido al de la creación de una VM, pero solo se necesitan unas pocas indicaciones para completar los parámetros necesarios. Todos los otros recursos se crean e incorporan.
3 El paso final para implementar la plantilla es aceptar el acuerdo de licencia que se muestra y luego seleccionar Comprar. Cuando implementa una plantilla, está creando recursos de Azure, por lo que Comprar significa que acuerda pagar los costos de esos recursos de Azure.
Una de las plantillas básicas, como una VM Linux o Windows simple, cuesta aproximadamente lo mismo que cualquier otra VM que haya creado hasta ahora. Asegúrese de eliminar el grupo de recursos cuando finalice la implementación, así como limpiar después de cualquier otro ejercicio.

4 Cuando su plantilla haya sido implementada, vuelva a GitHub y examine el archivo azure-deploy.json. Este archivo corresponde a la plantilla de Azure Resource Manager que usó para crear e implementar el ejemplo. Vea si puede entender los diferentes tipos de recursos y configuraciones que se aplicaron. A medida que trabaje con más tipos de recursos y plantillas de Azure, el formato JSON será más fácil de entender.

Y bien amigos hasta aqui la entrada de hoy, que pasen un buen fin de semana y nos vemos en la proxima entrada!!!