Comprobación de errores y validación del código de Bicep

Completado

Ahora que sabe para qué sirven las fases de canalización, verá el primer conjunto de pasos de validación que puede agregar a la canalización de implementación de Bicep. En esta unidad, descubrirá cómo validar plantillas de Bicep. También obtendrá información sobre las dos actividades que normalmente realiza una fase de validación: linting y validación preparatoria.

¿Qué es un archivo de Bicep válido?

Un archivo de 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 la plantilla de Bicep. La validación es un procedimiento recomendado porque, si implementa un archivo de Bicep que no es válido, es posible que Azure implemente o cambie únicamente un subconjunto de los recursos descritos en la plantilla. El resultado puede ser que el estado del entorno sea incoherente y es posible que no se comporte de la manera esperada.

Compilación y linting del 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 no usados: 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 los parámetros de seguridad: el linter le advierte si establece valores predeterminados para los parámetros marcados con el decorador @secure(). Asignar un valor predeterminado para un parámetro seguro es un procedimiento no recomendado, ya que asignará al parámetro seguro un valor legible 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. El linting sucede de forma automática al implementar un archivo de Bicep en Azure.

Pero, en una canalización, 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 linter compruebe las plantillas de Bicep cada vez que alguien inserte código en el repositorio, puede agregar una fase y un trabajo de linting a la canalización:

Puede expresar esta adición en el archivo YAML de la canalización de la siguiente forma:

stages:

- stage: Lint
  jobs: 
  - job: Lint
    steps:
      - 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 ha infringido una regla. Las advertencias que emite el linter de Bicep no se tratan como un error, por lo que no detienen la ejecución de canalización ni la de las fases 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. Verá cómo actualizar las reglas de linter más adelante en este módulo.

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, la canalización detiene su ejecución y los trabajos o las fases posteriores no se ejecutan. Esta configuración ayuda a garantizar que no se implemente código de Bicep con errores.

Validación preparatoria

También debe comprobar si es probable que la plantilla de Bicep se implemente correctamente en el entorno de Azure. Esta comprobación se denomina validación preparatoria y ejecuta comprobaciones adicionales que necesitan que Azure proporcione información. Estos tipos de comprobaciones incluyen las siguientes:

• ¿Son válidos los nombres que ha especificado para los recursos de Bicep?
• ¿Los nombres que ha especificado 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.

Puede usar la tarea AzureResourceManagerTemplateDeployment para enviar un archivo de Bicep para la validación preparatoria y configurar deploymentMode en Validation:

- stage: Validate
  jobs:
  - job: Validate
    steps:
      - task: AzureResourceManagerTemplateDeployment@3
        inputs:
          connectedServiceName: 'MyServiceConnection'
          location: $(deploymentDefaultLocation)
          deploymentMode: Validation
          resourceGroupName: $(ResourceGroupName)
          csmFile: deploy/main.bicep

Este comando es similar a la tarea de implementación que ya ha usado, pero no implementa realmente 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 comprobará si otra cuenta de almacenamiento ya ha tomado 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í que lo hacen, por lo que no puede confiar en la validación preparatoria para asegurarse de que el archivo sea válido. Pero es una herramienta útil y merece la pena incluirla en la canalización.

Al agregar fases de validación a la canalización para ejecutar el linter y realizar una validación preparatoria, tendrá más confianza antes de implementar el archivo de Bicep.