Comprobación de errores y validación del código de Bicep
Ahora que sabe para qué sirven los trabajos de flujo de trabajo, verá el primer conjunto de pasos de validación que puede agregar al flujo de trabajo de implementación de Bicep. En esta unidad, descubrirá cómo validar plantillas de Bicep. También obtendrá información sobre las dos actividades de validación que se usan habitualmente: linting y validación preparatoria.
¿Qué es un archivo de Bicep válido?
Un archivo Bicep válido es el que no contiene errores de sintaxis. Además, las definiciones de los recursos de Azure que planea implementar son válidas. Y cuando se implementan los recursos definidos en el archivo, se mantienen dentro de las cuotas y límites que existen en la suscripción de Azure.
Algunas de las comprobaciones se realizan en el archivo de Bicep de forma aislada, como las de errores de sintaxis, las definiciones de recursos de Azure válidas y la calidad del código. Estos pasos forman parte de un proceso denominado linting. Para comprobar si hay otros problemas, debe solicitar que el servicio Azure Resource Manager valide la plantilla y tenga en cuenta el entorno de Azure.
Una plantilla de Bicep válida tiene una mayor posibilidad de implementarse de forma correcta. Obtendrá comentarios sin implementar realmente la plantilla de Bicep. La validación es un procedimiento recomendado porque, si implementa un archivo Bicep que no es válido, es posible que Azure implemente o cambie únicamente un subconjunto de los recursos descritos en la plantilla. Una implementación parcial podría significar que el estado del entorno es incoherente y es posible que no se comporte de la manera esperada.
Creación y linting de código de Bicep
Al implementar un archivo de Bicep, las herramientas de Bicep ejecutan primero algunos pasos de validación básicos. Son los mismos pasos que se ejecutan al modificar el archivo mediante Visual Studio Code. Comprueban que ha usado correctamente las palabras clave del lenguaje de Bicep y que ha definido los recursos de Azure según los requisitos de cada tipo de recurso.
Además, Bicep ejecuta un linter en los archivos. Linting es el proceso de comprobar el código con un conjunto de recomendaciones. El linter de Bicep examina el archivo y comprueba que ha seguido los procedimientos recomendados de mantenimiento, corrección, flexibilidad y extensibilidad.
Un linter contiene un conjunto predefinido de reglas para cada una de estas categorías. Entre las reglas de linter de ejemplo se incluyen las siguientes:
- Parámetros sin utilizar. El linter busca los parámetros que no se usan en ningún lugar del archivo de Bicep. Al eliminar los parámetros sin utilizar, se facilita la implementación de la plantilla, ya que no es necesario proporcionar valores innecesarios. También reduce la confusión cuando alguien intenta trabajar con el archivo de Bicep.
- Interpolación de cadenas. El linter comprueba si el archivo usa la función
concat()en lugar de la interpolación de cadenas de Bicep. La interpolación de cadenas hace que los archivos de Bicep sean más legibles. - Valores predeterminados para parámetros seguros. El linter le advierte si establece valores predeterminados para los parámetros marcados con el decorador
@secure(). Establecer valores predeterminados para parámetros seguros no es un procedimiento recomendado, ya que asignará al parámetro seguro un valor legible por el usuario y es posible que los usuarios no lo cambien antes de la implementación.
El linter de Bicep se ejecuta automáticamente cuando se usan las herramientas de Bicep. Cada vez que se compila un archivo de Bicep, el linter lo comprueba con sus procedimientos recomendados. Esta comprobación sucede de forma automática al implementar un archivo Bicep en Azure.
Sin embargo, en un flujo de trabajo, normalmente querrá ejecutar los pasos de validación y linting antes de implementar el archivo. Puede indicarle a Bicep que compruebe el archivo creando manualmente el archivo de Bicep mediante la CLI de Bicep:
az bicep build --file main.bicep
bicep build main.bicep
Nota:
Al ejecutar el comando build, Bicep también transpila el código de Bicep en una plantilla de ARM JSON. Por lo general, no necesita el archivo que genera, por lo que puede omitirlo.
Como quiere que se comprueben los errores en las plantillas de Bicep cada vez que alguien inserte código en el repositorio, puede agregar un trabajo de linting al flujo de trabajo:
Esta incorporación se expresa en el archivo YAML del flujo de trabajo de la siguiente manera:
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- script: |
az bicep build --file deploy/main.bicep
Advertencias y errores de linter
De manera predeterminada, el linter emite una advertencia cuando descubre que un archivo de Bicep infringe una regla. Las advertencias que emite el linter de Bicep no se tratan como errores, por lo que no detienen la ejecución del flujo de trabajo ni la de los trabajos posteriores.
Puede cambiar este comportamiento si configura Bicep para que trate las infracciones de la regla de linter como errores en lugar de advertencias. Para configurarlo de esta forma, agregue un archivo bicepconfig.json a la carpeta que contiene el archivo de Bicep. Puede decidir qué problemas de linter se deben tratar como errores y cuáles deben permanecer como advertencias. Más adelante en este módulo configurará linter.
Sugerencia
El archivo bicepconfig.json también controla cómo muestra Visual Studio Code los errores y las advertencias en el editor. Muestra líneas onduladas de color rojo y amarillo bajo los elementos mal configurados en la plantilla de Bicep. Estos indicadores proporcionan comentarios incluso más rápidos al escribir el código de Bicep, lo que reduce aún más la posibilidad de un error.
Después de volver a configurar el linter para emitir errores, cada vez que este detecta un problema, el flujo de trabajo detiene su ejecución y los trabajos posteriores no se ejecutan. Esta configuración ayuda a garantizar que no se implementa código de Bicep problemático.
Validación preparatoria
También debe comprobar si es probable que la plantilla de Bicep se implemente correctamente en el entorno de Azure. Este proceso se conoce como validación preparatoria y ejecuta comprobaciones para las que es necesario que Azure proporcione información. Estos tipos de comprobaciones incluyen las siguientes:
- ¿Son válidos los nombres especificados para los recursos de Bicep?
- ¿Los nombres especificados para los recursos de Bicep ya están en uso?
- ¿Son válidas las regiones en las que va a implementar los recursos?
Para la validación preparatoria se necesita comunicación con Azure, pero en realidad no se implementa ningún recurso.
Use la acción arm-deploy y establezca deploymentMode en Validate a fin de enviar un archivo de Bicep para la validación preparatoria:
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
name: Run preflight validation
with:
resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
template: ./deploy/main.bicep
deploymentMode: Validate
También puede usar el comando az deployment group validate de la CLI de Azure.
La validación preparatoria es similar a una implementación normal, pero en realidad no implementa ningún recurso. Realiza comprobaciones adicionales en los recursos que se usan en la plantilla.
Por ejemplo, imagine que el archivo de Bicep contiene una cuenta de almacenamiento. La validación preparatoria comprueba si otra cuenta de almacenamiento ya tomó el nombre que se eligió. También comprueba si el nombre que ha elegido para la cuenta de almacenamiento cumple las convenciones de nomenclatura.
El comando de validación preparatoria también ejecuta el linter de Bicep. Pero normalmente es recomendable ejecutar el linter por separado. De este modo, si hay errores de linter, los detectará rápidamente en lugar de esperar a que se complete el proceso de validación. Este tarda más tiempo.
Importante
Al ejecutar una validación preparatoria, cada uno de los proveedores de recursos de Azure realiza sus propias comprobaciones. Algunos proveedores de recursos no ejecutan muchas comprobaciones, mientras que otros sí. Por lo que no puede confiar en la validación preparatoria para estar seguro de que el archivo es válido. No obstante, es una herramienta útil y merece la pena incluirla en el flujo de trabajo.
Al agregar trabajos de validación al flujo de trabajo para ejecutar el linter y realizar una validación preparatoria, tendrá más confianza antes de implementar el archivo de Bicep.