Implementación de archivos de Bicep mediante una canalización

Completado

Ahora que ha creado una canalización básica, está preparado para configurarla con el fin de implementar los archivos de Bicep. En esta unidad, aprenderá a implementar código de Bicep desde una canalización y a configurar los pasos de la implementación.

Nota:

Los comandos de esta unidad se muestran para ilustrar conceptos. No los ejecute todavía. Pronto va a practicar lo que aprenderá aquí.

Conexiones de servicio

Al implementar un archivo de Bicep desde su propio equipo, se usa la CLI de Azure o Azure PowerShell. Para poder implementar el código, debe iniciar sesión en Azure. Normalmente, las herramientas le piden que escriba su dirección de correo electrónico y la contraseña en un explorador. Una vez comprobadas las credenciales, se confirman los permisos para implementar recursos y ya puede usar las herramientas para implementar el archivo de Bicep.

La implementación con la canalización también requiere autenticación. Dado que las canalizaciones se ejecutan sin intervención del usuario, deben autenticarse en Azure mediante una entidad de servicio. Las credenciales de una entidad de servicio constan de un id. de aplicación y un secreto, que suele ser una clave o un certificado. En Azure Pipelines, use una conexión de servicio para almacenar estas credenciales de forma segura, de modo que la canalización pueda usarlas. Una conexión de servicio también incluye otra información para ayudar a la canalización a identificar el entorno de Azure en el que desea realizar la implementación.

Sugerencia

En este módulo, usará Azure DevOps para crear automáticamente una entidad de servicio cuando cree una conexión de servicio. El módulo Autenticar la canalización de implementación de Azure mediante entidades de servicio proporciona una explicación más detallada de las entidades de servicio, incluido cómo funcionan, así como cómo crearlas, asignarles roles y administrarlas.

Cuando cree una conexión de servicio, asígnele un nombre. Los pasos hacen referencia a la conexión de servicio con este nombre, por lo que no es necesario que el código de YAML de la canalización contenga información secreta.

Cuando se inicia la canalización, el agente que ejecuta los pasos de implementación tiene acceso a la conexión de servicio, incluidas sus credenciales. Un paso de la canalización usa las credenciales para iniciar sesión en Azure, igual que lo hace usted. Después, las acciones definidas en el paso utilizan la identidad de la entidad de servicio.

Debe asegurarse de que la entidad de servicio tenga los permisos necesarios para poder ejecutar los pasos de la implementación. Por ejemplo, es posible que tenga que asignar a la entidad de servicio el rol Colaborador para el grupo de recursos donde implementa los recursos.

Advertencia

Puede parecer más sencillo almacenar las credenciales de la entidad de servicio en el archivo de YAML e iniciar sesión con el comando az login. No debe usar nunca este método para autenticar la entidad de servicio. Las credenciales de un archivo YAML se almacenan en texto sin formato. Cualquier persona que tenga acceso al repositorio puede ver y usar las credenciales. Aunque restrinja el acceso a la organización y al proyecto de Azure DevOps, cada vez que alguien clone el repositorio, el archivo de YAML que contiene las credenciales estará en el equipo de esa persona. Es importante usar una conexión de servicio siempre que trabaje con Azure desde una canalización. Las conexiones de servicio también proporcionan otras características de seguridad y control de acceso.

Las conexiones de servicio se crean en el proyecto de Azure DevOps. Varias canalizaciones pueden compartir una conexión de servicio única. Sin embargo, suele ser aconsejable configurar una conexión de servicio y la entidad de servicio correspondiente para cada canalización y cada entorno en el que se implemente. Esto ayuda a aumentar la seguridad de las canalizaciones y reduce la probabilidad de implementar o configurar recursos accidentalmente en un entorno diferente del previsto.

También puede configurar una conexión de servicio para que solo se pueda usar en canalizaciones específicas. Por ejemplo, cuando se crea una conexión de servicio que se implementa en el entorno de producción de su sitio web, es una buena idea asegurarse de que solo la canalización del sitio web puede usar esta conexión de servicio. La restricción de una conexión de servicio a canalizaciones específicas impide que otra persona use accidentalmente la misma conexión de servicio para un proyecto diferente y pueda dar lugar a que el sitio web de producción deje de funcionar.

Implementación de un archivo de Bicep mediante la tarea Implementación de un grupo de recursos de Azure

Cuando necesite implementar un archivo de Bicep desde una canalización, puede usar la tarea Implementación de un grupo de recursos de Azure. Este es un ejemplo de cómo configurar un paso para usar la tarea:

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    connectedServiceName: 'MyServiceConnection'
    location: 'westus3'
    resourceGroupName: Example
    csmFile: deploy/main.bicep
    overrideParameters: >
        -parameterName parameterValue

La primera línea especifica AzureResourceManagerTemplateDeployment@3. Esto indica a Azure Pipelines que la tarea que desea usar para este paso se denomina AzureResourceManagerTemplateDeployment y que quiere usar la versión 3 de la tarea.

Cuando use la tarea Implementación de un grupo de recursos de Azure, debe especificar una serie de entradas para indicarle a la tarea lo que debe hacer. Estas son algunas entradas que puede especificar al usar la tarea:

• connectedServiceName es el nombre de la conexión de servicio que se va a usar.
• location debe especificarse aunque no se pueda usar su valor. La tarea Implementación de un grupo de recursos de Azure también puede crear un grupo de recursos automáticamente y, si lo hace, debe conocer la región de Azure en la que se va a crear el grupo de recursos. En este módulo, especificará el valor de entrada location, pero su valor no se usa.
• resourceGroupName especifica el nombre del grupo de recursos en el que se debe implementar el archivo de Bicep.
• overrideParameters contiene los valores de parámetro que desea pasar al archivo de Bicep en el momento de la implementación.

Cuando se inicia la tarea, usa la conexión de servicio para iniciar sesión en Azure. Cuando la tarea ejecuta la implementación especificada, la tarea ya se ha autenticado. No es necesario ejecutar az login.

Ejecución de comandos de la CLI de Azure y Azure PowerShell

Dos de las tareas integradas más útiles en Azure Pipelines son las tareas de la CLI de Azure y de Azure PowerShell. Puede usar estas tareas para ejecutar uno o varios comandos de la CLI de Azure o de PowerShell.

En los futuro módulos de Microsoft Learn, verá cómo el comando de la CLI de Azure puede ayudarle a automatizar más partes del proceso de implementación desde una canalización.

Variables

A menudo, las canalizaciones contienen valores que desea mantener separados del archivo YAML. Por ejemplo, al implementar un archivo de Bicep en un grupo de recursos, debe especificar el nombre del grupo de recursos. Es probable que el nombre del grupo de recursos sea distinto cuando la implementación se realice en entornos diferentes. Además, es posible que tenga que proporcionar parámetros para los archivos de Bicep, incluidos secretos, como las contraseñas de los servidores de bases de datos. No almacene estos valores en el archivo de YAML de la canalización ni en ningún otro lugar del repositorio de Git. En su lugar, para aumentar la seguridad y hacer que las definiciones de canalizaciones sean reutilizables, use variables.

Crear una variable

La interfaz web de Azure Pipelines tiene un editor que puede usar para crear variables para la canalización:

Puede establecer un valor de variable de Azure Pipelines como secreto. Cuando se establece un valor de variable como secreto, no se puede ver el valor después de establecerlo. Azure Pipelines está diseñado para no revelar valores secretos en los registros de las canalizaciones.

Advertencia

De forma predeterminada, Azure Pipelines ofusca los valores de variable secretos en los registros de las canalizaciones, pero también debe seguir buenas prácticas. Los pasos de las canalizaciones tienen acceso a todos los valores de variable, incluidos los secretos. Si la canalización incluye un paso que no controla una variable protegida de forma segura, existe la posibilidad de que la variable secreta se pueda mostrar en los registros de la canalización.

También puede permitir que los usuarios invaliden el valor de una variable cuando ejecuten la canalización manualmente. El valor que un usuario proporciona solo se utiliza para esa ejecución específica de la canalización. La invalidación de variables puede ser útil cuando se prueba una canalización.

Uso de una variable en la canalización

Después de crear una variable, usará una sintaxis específica para hacer referencia a la variable en el archivo de YAML de la canalización:

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    connectedServiceName: $(ServiceConnectionName)
    location: $(DeploymentDefaultLocation)
    resourceGroupName: $(ResourceGroupName)
    csmFile: deploy/main.bicep
    overrideParameters: >
      -environmentType $(EnvironmentType)

El formato de archivo de definición de canalización incluye una sintaxis $(VariableName) especial. Con este método, puede hacer referencia a cualquier variable, independientemente de si es secreta o no.

Sugerencia

En el ejemplo anterior, observe que el nombre del archivo de Bicep no se almacena en una variable. Al igual que los parámetros de Bicep, no es necesario crear variables para todo. Es aconsejable crear variables para todo lo que pueda cambiar entre entornos y todo lo que sea secreto. Puesto que la canalización siempre usará el mismo archivo de plantilla, no es necesario crear una variable para la ruta de acceso.

Variables del sistema

Azure Pipelines también utiliza variables del sistema. Las variables del sistema contienen información predefinida que puede usar en la canalización. Estas son algunas de las variables del sistema que puede usar en la canalización:

• Build.BuildNumber es el identificador único para la ejecución de la canalización. A pesar de su nombre, el valor Build.BuildNumber suele ser una cadena, no un número. Puede usar esta variable para dar nombre a la implementación en Azure y así poder realizar un seguimiento de la implementación hasta la ejecución específica de la canalización que la desencadenó.
• Agent.BuildDirectory es la ruta de acceso en el sistema de archivos de la máquina del agente donde se almacenan los archivos de la ejecución de la canalización. Esta información puede ser útil para hacer referencia a archivos que están en el agente de compilación.

Creación de variables en el archivo de YAML de la canalización

Además de usar la interfaz web de Azure Pipelines para crear variables, puede establecer valores de variable en el archivo de YAML de la canalización. Puede usar esta opción si tiene valores que no son secretos, si los valores se pueden almacenar en el repositorio y si desea mantenerlos en un lugar en el archivo para poder hacer referencia a ellos en la definición de la canalización. Puede usar este enfoque para hacer un seguimiento de los cambios que se realicen en la variable en el sistema de control de versiones.

Para establecer una variable en el archivo YAML, agregue una sección variables:

trigger: none

pool:
  vmImage: ubuntu-latest

variables:
  ServiceConnectionName: 'MyServiceConnection'
  EnvironmentType: 'Test'
  ResourceGroupName: 'MyResourceGroup'
  DeploymentDefaultLocation: 'westus3'

jobs:
- job:
  steps:
  - task: AzureResourceManagerTemplateDeployment@3
    inputs:
      connectedServiceName: $(ServiceConnectionName)
      location: $(DeploymentDefaultLocation)
      resourceGroupName: $(ResourceGroupName)
      csmFile: deploy/main.bicep
      overrideParameters: >
        -environmentType $(EnvironmentType)

Este ejemplo de canalización define cuatro variables: ServiceConnectionName, EnvironmentType, ResourceGroupName y DeploymentDefaultLocation.

Más adelante en este módulo, verá cómo puede mezclar variables definidas en diferentes lugares juntos en una canalización.