Project Bicep, el ARM DSL de Microsoft

*Post actualizado con las últimas novedades disponibles

¿Qué es Project Bicep?

Bicep es el DSL (lenguaje específico de dominio) para desplegar recursos de Azure de forma declarativa. Su objetivo es simplificar la experiencia en las plantillas ARM para desplegar recursos de Azure, con una sintaxis más limpia, modularidad y reutilización de código.

Proporciona una abstracción transparente sobre las plantillas ARM (sabemos que las plantillas ARM no son las más fáciles de escribir). Todas las cosas que podemos hacer con las plantillas ARM hasta ahora (y en el futuro) se pueden hacer con Bicep (excepto las limitaciones conocidas que Microsoft espera resolver en otras versiones). Sin embargo, Bicep está listo para el uso de producción y, junto con algunas de las herramientas de este post, ahora es mucho más fácil construir plantillas ARM.

Por lo tanto, quería hacer una introducción sencilla, pues me parece útil conocer este nuevo DSL, su simplicidad y las características que tendrá sobre las plantillas ARM tradicionales para desplegar recursos de Azure. Permitirá a los desarrolladores construir plantillas ARM más rápido y fácil que nunca.

¿Por qué debería interesarme?

Ya hay alternativas como Terraform, Pulumi y otras ofertas de IaC para evitar la complejidad de las plantillas ARM. Bueno, me gustaría admitir que he utilizado Terraform para Azure en algunos proyectos y estoy muy contento con él. Sus proveedores de Azure son realmente impresionantes, pero, en algunos casos, como con nuevas características, productos o configuraciones de Azure, tendremos que esperar al proveedor para implementar estos cambios (o no estará disponible en un futuro previsible, como la integración del Portal Azure). Utilizar el “AzAPI Provider” en lugar del “AzureRM provider” resuelve la espera para que el proveedor implemente el soporte para los cambios más recientes en Azure. Si usamos el «AzAPI Provider», estaremos usando la misma API que usa Bicep para desplegar recursos. Sin embargo, tendremos que lidiar con el estado de Terraform, sin integración con Azure Portal y faltando algunas funcionalidades de integración como Azure Policies.

En lugar de esto, Bicep estará cubierto en todos los planes de soporte de Azure a partir de la versión 0.3. Como se compila directamente a plantillas ARM en ficheros JSON y está soportado y respaldado por Microsoft, deberíamos tener todas las nuevas características, productos y configuraciones disponibles out of the box (lo que es tranquilizador).

Esquema de la arquitectura de Azure Resource Manager (extraído de «Project Bicep Demo en Ignite 2020 por Mark Russinovich”)

En mi opinión, después de probar Bicep, creo que merece una oportunidad para los desarrolladores a la hora de desplegar recursos en Azure. Sin embargo, es importante destacar que no hay razón para cambiar a Bicep si ya estás utilizando Terraform u otro proveedor de IaC, ya que los proveedores han puesto mucho esfuerzo para hacer que funcionen bien con Azure, e incluso Microsoft está respaldando este esfuerzo. La realidad es que hay muchos proyectos que utilizan plantillas ARM, y Microsoft está tratando de hacer más fácil la gestión y proporcionar sus propias herramientas para empezar con IaC (sin tener que depender de terceros).

Bicep vs. Terraform

Bicep y Terraform son dos ofertas líderes de IaC (Infraestructura como código). En cuanto a infraestructura, integración y usabilidad, ambos tienen características muy fáciles de usar que los hacen muy similares en algunos aspectos. Un concepto clave que se debe saber es que no hay características de usabilidad importantes cuando se usa Bicep versus Terraform.

Sus funcionalidades respecto a infraestructura e integración facilitan a los desarrolladores la implementación de soluciones IaC. La única decisión importante para tener en cuenta es si está implementando en más de un proveedor (o si su infraestructura consistirá en un entorno múltiple/híbrido). Si la respuesta es afirmativa, entonces Terraform se adaptará mejor, ya que Bicep es únicamente para recursos de Azure.

Al realizar una comparación más profunda, hay algunas diferencias clave que debemos saber:

En cuanto a integración e infraestructura

• Estado y Backend: ambos son de configuración de estado deseada (DSC). Sin embargo, Terraform almacena información de estado y configuración, mientras que Bicep no. Esta información la utiliza el propio cliente de Terraform y se puede almacenar en un archivo local o de forma remota (por ejemplo, en un contenedor de Azure Storage). Por otro lado, Bicep se basa en el despliegue incremental.
• Objetivos de infraestructura: Bicep es específico de Azure y no está diseñado para funcionar con otros proveedores. Con Terraform podemos trabajar con varios proveedores: AWS, Azure, Google Cloud… y la lista sigue creciendo.
• Herramientas: Terraform usa su propia CLI, mientras que Bicep se integra con la CLI de Azure (con az bicep y az deployment). Hay que tener en cuenta que Bicep también se puede utilizar como una herramienta CLI independiente.
• Procesamiento: con Bicep, el procesamiento ocurre dentro del lado del servicio de la infraestructura principal de Azure. Con Terraform, el procesamiento se realiza dentro del cliente de Terraform, lo que implica llamadas a Azure para determinar los cambios necesarios (usando el estado guardado).
• Autenticación: Bicep utiliza un token de autorización proporcionado durante la solicitud para enviar un archivo o plantilla. Por otro lado, Terraform se autentica en función de las credenciales del proveedor (CLI de Azure, entidad de servicio o identidades administradas).
• En Azure: Bicep ofrece una mejor integración con las funciones de Azure, como Azure Policy, que se evalúan previamente para determinar si una política denegará un recurso y fallará la implementación. En este caso específico, Terraform fallará al implementar el recurso.
  • Integración del portal: una de las principales ventajas de trabajar con Bicep en Azure es la capacidad de automatizar las acciones del portal. Se puede usar el portal de Azure para exportar plantillas y utilizarlas más tarde, lo que nos ayuda a entender cómo hacerlo con Bicep (y exponiendo todos sus posibles parámetros). Terraform no proporciona esta misma integración con el portal de Azure como Bicep. Sin embargo, con otras herramientas como Azure Terrafy podemos recuperar la infraestructura de Azure existente bajo la administración de Terraform.
• Cambios fuera de contexto: al realizar cambios en la infraestructura fuera del contexto de la herramienta, se deben conciliar con Bicep y el código de la plantilla ARM (para evitar que esos cambios se sobrescriban en el próximo despliegue). En el caso de Terraform, se deberán importar estos cambios al estado de Terraform y actualizar los archivos relacionados con Terraform (lo que a veces puede ser tedioso).
• Frameworks en la nube: Bicep simplifica el proceso para implementar landing zones con una experiencia de portal basada en plantillas ARM e implementación de landing zones. Terraform utiliza un módulo de landing zones a escala empresarial para implementar, administrar y realizar operaciones con Azure.

En cuanto a la usabilidad

• Lenguaje: Bicep y Terraform son lenguajes específicos de dominio (DSL) fáciles de usar. Ambos tienen palabras clave y conceptos similares, como parametrización, proyectos de varios archivos, módulos externos… Sin embargo, Terraform ofrece funciones integradas para ciertas tareas. Ambos son lenguajes declarativos y ofrecen asistentes de lenguaje para simplificar las tareas de codificación. Además, la experiencia de creación de código puede ser realmente agradable usando extensiones para el IDE usado (por ejemplo, ambos ofrecen complementos para Visual Studio Code).
• Módulos: tanto Bicep como Terraform admiten el concepto de módulos, que te permiten crear componentes reutilizables a partir de tu código.
• Ciclo de vida de aprovisionamiento: tanto Bicep como Terraform permiten validar la configuración antes de las implementaciones y luego aplicar los cambios deseados (con terraform plan o la operación de Bicep what-if). Sin embargo, Terraform brinda más flexibilidad para destruir todos los objetos remotos administrados por una configuración particular.
• Primeros pasos: es fácil y directo comenzar con Bicep o Terraform: ambos ofrecen recursos para ayudarte. Para Bicep, puedes consultar Microsoft Learn y su documentación en Microsoft Docs. En el caso de Terraform, puedes consultar HashiCorp Learn y su documentación en Terraform docs.
• En Azure: Bicep tiene una clara ventaja sobre Terraform cuando se trata de Azure y la configuración de recursos de Azure. Bicep está más integrado con los servicios de Azure con soporte inmediato para las nuevas características de Azure. Con Terraform, tenemos dos proveedores principales que permiten a los usuarios administrar Azure:
  • AzureRM: una experiencia estable para los servicios de Azure, con un poco de retraso con las nuevas funciones de Azure.
  • AzAPI: una capa sobre las API REST de Azure ARM, que permite compatibilidad inmediata con las características de Azure.
• Comunidad y apoyo: ambas comunidades ofrecen un alto nivel de compromiso y apoyo.
  • Para Bicep, tenemos la documentación de Bicep en Microsoft Docs y la posibilidad de consultar su código fuente y bugs abiertos de Bicep.
  • Para Terraform tenemos la documentación de Terraform en Microsoft Docs, la posibilidad de verificar el código fuente del proveedor y reportar/consultar bugs, obtener respuestas a Preguntas básicas de Terraform y Preguntas relacionadas con el proveedor de Terraform.

Debemos asegurarnos de considerar los conceptos anteriores (y los requisitos y preferencias de infraestructura) para tomar la mejor decisión para tu organización.

Primeros pasos…

Es muy sencillo comenzar con Bicep. Solo necesitamos la CLI de Azure. Depende de ti instalar otras herramientas (CLI, la extensión VS Code, etc.). El proceso para estas herramientas es sencillo y está documentado en el repositorio de Bicep. Ten en cuenta que también hay un módulo PowerShell Bicep si queremos tener la misma funcionalidad de Bicep CLI en PowerShell.

El siguiente paso es aprender sobre Bicep y su sintaxis. Un buen punto de partida es el tutorial oficial. También hay grandes recursos para probar, como el Bicep Playground y el Visual Studio Code Devcontainer/Codespaces repo.

Después de este proceso, y tras jugar un poco, deberíamos estar listos para usarlo fácilmente sobre nuestras plantillas de Azure.

Esquema del Proyecto Bicep (Extraído de “Project Bicep Demo en Ignite 2020 por Mark Russinovich”)

Interpretando el esquema anterior, el proceso sería tan simple como

bicep build my-deployment.bicep # Solo este paso extra

az deployment group create my-deployment.json

¡Pero podemos saltarnos ese paso extra! Ya que tanto Az CLI (2.20.0+) como el módulo PowerShell Az (v5.6.0+) tienen soporte para Bicep incorporado:

az deployment group create my-deployment.bicep

Con Bicep, estamos simplificando mucho el proceso de creación de plantillas ARM y obteniendo muchos beneficios. Uno de ellos que me pareció muy interesante es la posibilidad de hacer archivos separados para generar un solo archivo ARM.

Echemos un vistazo rápido a sus diferencias respecto a un archivo ARM (que son equivalentes), a partir de una plantilla quickstart simple del repositorio de Azure:

Implementación de una base de datos SQL simple en la mitad de líneas y mucho más legible (Izquierda: Bicep. Derecha: ARM)

Parece sencillo, y lo es, pero…

¿Cómo convertir plantillas ARM al formato Bicep?

Hay dos enfoques diferentes:

• Existe una hoja de equivalencias disponible para comparar la sintaxis de la plantilla ARM con el equivalente nativo de Bicep. Este documento debería permitirnos comenzar a convertir plantillas ARM existentes a su equivalente en Bicep y empezar a simplificarlas y a usar sus características.
• La opción ‘decompilar’ disponible en el Bicep CLI. Esta opción es genial y, generalmente, funciona muy bien. Es importante tener en cuenta que, debido a que no hay una conversión garantizada de JSON a Bicep, la decompilación puede fallar, o puede quedar con errores/ advertencias en el archivo Bicep generado para arreglar. Sin embargo, es la forma más fácil de obtener archivos de bicep de nuestros ARM. Tan simple como ejecutar: bicep decompile my-arm-template.json o az bicep decompile my-arm-template.json

Sin embargo, es importante destacar que, ya que Bicep compila hasta las plantillas ARM, también podríamos tener plantillas Bicep y ARM que coexisten al mismo tiempo, y convertir gradualmente las plantillas o dejar que la antigua se mantenga como plantilla ARM estándar (como el desarrollador quiera).

El enfoque en nuestro proceso de implementación será casi el mismo, ya que solo introduciremos un paso extra en nuestro proceso de implementación: la compilación de archivos Bicep hasta su equivalente en plantilla JSON ARM antes de desplegar las plantillas ARM.

Bicep en nuestros procesos de despliegue

Con Bicep, su «única» herramienta, podríamos implementar fácilmente la compilación de archivos en casi todos los entornos. Un enfoque simple y genérico sería descargar el binario de las versiones de GitHub y ejecutar el binario con nuestros archivos de Bicep a JSON. Pero esto no es necesario en absoluto como se comentó antes, con las nuevas versiones de Azure CLI y el módulo PowerShell Az.

Aunque es fácil implementar este enfoque genérico, la comunidad y Microsoft en sí están empezando a proporcionarnos las extensiones, paquetes y acciones necesarias para incluir el “tooling” de Bicep en nuestros pipelines.

Azure DevOps Pipelines

Para Azure DevOps Pipelines, ya tenemos algunas tareas implementadas con el fin de abstraer y simplificar el proceso en un par de tareas, que se pueden encontrar en el README del proyecto oficial o en el Visual Studio Marketplace.

Sin embargo, si no te gusta incluir extensiones de terceros en tu organización de Azure DevOps, podemos hacer nuestro propio pipeline (descargando el “tooling” necesario por nuestra cuenta).

GitHub Actions

Existe una acción de GitHub desarrollada por la comunidad para incluir Biceo en nuestro proceso de despliegue al usar GitHub Actions. Como se dice en la sección Azure DevOps Pipelines, podríamos implementar nuestra propia acción (descargando el “tooling” necesario por nuestra cuenta).

Otros escenarios CI/CD

Bicep es solo un binario multiplataforma, así que, hoy en día, creo que no habría ningún problema en cualquier entorno de CI/ CD para introducir un paso adicional con el que manejar archivos ‘.bicep’. No obstante, si el propósito es solo el de desplegar, no es necesario.

Solo sería un ejecutable que podría ser descargado en cada ejecución o guardado en nuestro entorno, que necesitamos para ejecutar contra una serie de archivos ‘.bicep ‘.

En realidad, no hay razón alguna para no darle una oportunidad a Microsoft Bicep.

Hay mucho más sobre el Proyecto Bicep por descubrir (¡y más características por venir!). Por ahora, queríamos darte esta serie de conceptos iniciales para que pruebes todo lo que puede ofrecer.