Productivización de la IaC utilizando Azure Blueprint

Definimos IaC (Infraestructura como código) como la la gestión de la infraestructura utilizando técnicas similares a las de gestión del ciclo de vida del software.

La virtualización y la adopción de la nube han hecho necesario el desarrollar una automatización del proceso de aprovisionamiento y gestión de la infraestructura. Anteriormente, el crecimiento de la infraestructura estaba limitado por el hecho de tener que comprar nuevo equipamiento, lo cual se dilataba en el tiempo y reducía la presión sobre el equipo de IT para preparar el equipamiento cuando este llegaba.

Actualmente, todas las nubes públicas ofrecen su propia solución para gestionar toda la infraestructura utilizando una metodología de IaC. En concreto en el caso de Azure se utiliza Azure Resource Manager. Sin embargo Azure Resource Manager (ARM) supone una serie de retos cuando se utiliza en proyectos a gran escala:

• ¿Cómo utilizamos una plantilla de ARM para desplegar en 50,100, 1.000 suscripciones diferentes?
• ¿Cómo mantenemos las plantillas modulares para maximizar su reutilización?
• ¿Cómo aseguramos que los entornos están actualizados respecto a la plantilla utilizada para su despliegue?

Para resolver todos estos problemas podemos utilizar el servicio Azure Blueprints, un servicio de Azure que permite definir un repositorio centralizado de artefactos y gestionar la asignación de esos artefactos en las diferentes suscripciones de una cuenta.

Azure Blueprints

Actualmente BluePrint soporta los siguientes artefactos:

• Plantillas de Azure Resource Manager
• Grupos de recursos
• Azure Policies
• Asignación de Roles

Ciclo de vida

Un Blueprint pasa por los siguientes estados en su ciclo de vida:

1. Creación de un Blueprint. Cuando se crea un Blueprint se queda en estado Draft. En este estado el Blueprint puede ser modificado las veces que sea necesario pero no podrá asignarse a ninguna suscripción hasta que no se publique.

2. Publicación de un BluePrint. Para poder asignar un Blueprint a una suscripción debemos publicar. Una vez hecho esto su estado pasará de Draft a Published.

3. Crear una nueva versión de un Blueprint. Cuando un Blueprint está en estado Published no puede ser modificado, pero se puede crear una nueva versión y modificarla. Cuando se guardar los cambios de la nueva versión el Blueprint se queda en estado Unpublished Changes. Estos cambios corresponden a la versión Draft del blueprint.

4. Publicación de una nueva versión del BluePrint. Cuando publicamos los cambios de una versión de un blueprint pasa del estado Unpublished Changes a Published. Un mismo Blueprint puede tener múltiples versiones, cada una de las cuales puede ser asignada a una suscripción diferente.

5. Asignar un Blueprint a una suscripción. Una vez el blueprint esta en version Published puede asignarse cualquiera de sus versiones a una suscripción de Azure.

6. Actualizar una asignación. Una asignación de un Blueprint se puede a actualizar para realizar una de las siguientes acciones:

• Activar o desactivar el bloqueo de recursos.
• Cambiar el valor de los parámetros dinámicos.
• Actualizar la asignación a una nueva versión publicada del Blueprint.

7. Eliminar una versión publicada. Se puede borrar una versión específica de un Blueprint publicado sin embargo primero deberemos eliminar todas las asignaciones de esa versión de ese blueprint.

8. Eliminar un blueprint. Se puede eliminar el blueprint y todas sus versiones pero para ello primero hay que eliminar todas las asignaciones que tenga ese blueprint.

Ciclo de vida Azure Blueprint

Gracias al ciclo de vida de un blueprint tenemos una visión de que versión de la infraestructura está desplegada en cada una de las suscripciones de una cuenta de Azure.

Personalización de Blueprints

Los parámetros sirven para personalizar los blueprints y hacerlos reusables de manera que tengan ciertos valores que puedan ser definidos en el momento de asignar un blueprint a una suscripción. De esta manera generamos componentes reutilizables en diferentes entornos/suscripciones.

Es posible definir parámetros a nivel del propio blueprint o a nivel de los artefactos contenidos dentro de uno. Cuando se define un parámetro a nivel de blueprint, éste puede ser utilizado por los artefactos que están contenidos dentro de ese blueprint. Un buen ejemplo sería uno que sirviera para definir el prefijo de nombrado de los recursos, de manera que todos los recursos que cuelguen del blueprint compartirán el mismo prefijo para establecer una política de nombrado de recursos consistente.

También podemos diferenciar los parámetros en función de en qué momento se asigna su valor:

• Parámetros estáticos: Son aquellos que su valor se define en el momento de definir el blueprint y que después no puede ser alterado en el momento de la asignación del blueprint.
• Parámetros dinámicos: Son aquellos cuyo valor se define en el momento de asignar un blueprint a una suscripción. El valor de estos parámetros se puede actualizar posteriormente una vez el blueprint esté asignado, lo que provocará que se actualice la asignación del blueprint a la suscripción.

Bloqueo de recursos

Esta característica permite asegurar la consistencia de los recursos desplegados con Azure Blueprint evitando, en función del tipo de bloqueo elegido, que los recursos puedan ser modificados o eliminados desde fuera del ámbito del blueprint.

Los bloqueos de recursos se definen dentro de cada blueprint en el momento de asignar un blueprint a una suscripción. Estos bloqueos solo se pueden cambiar desde el propio blueprint al crear una nueva asignación o actualizar una asignación existente.

Actualmente se soportan los siguientes modos de bloqueo de recursos:

• Don’t Lock
• Read Only
• Do Not Delete

Conclusión sobre Azure Blueprint

Usando las características descritas de Azure Blueprint podemos tener una herramienta centralizada que nos aportará las siguientes funcionalidades:

• Versionado de las diferentes versiones de las plantillas de nuestra infraestructura.
• Visión de que version de nuestras plantillas está desplegada en cada suscripción de nuestra cuenta y trazabilidad de los diferentes despliegues realizados a lo largo del tiempo.
• Aprovisionamiento rápido y sencillo de infraestructura en múltiples suscripciones.
• Reutilización de componentes gracias a la utilización de parámetros estáticos y dinámicos en nuestros blueprints.
• Salvaguarda de la consistencia de nuestra infraestructura mediante el uso de bloqueo de recursos.