Descripción de las implementaciones de un extremo a otro
Los flujos de trabajo de Acciones de GitHub son herramientas flexibles que puede configurar de muchas maneras diferentes para satisfacer sus necesidades. En esta unidad, aprenderá a usar flujos de trabajo para implementar una solución completa, incluida la configuración de la infraestructura de Azure, y a realizar otras operaciones de implementación.
¿Cuántos flujos de trabajo?
En algunas organizaciones, el equipo que administra el entorno de Azure es diferente del que desarrolla el código que se ejecuta en el entorno. En estas situaciones, a menudo resulta tentador crear varios flujos de trabajo, cada uno propiedad del equipo responsable de su área en particular. Por ejemplo, puede crear un flujo de trabajo para implementar el código de Bicep que implementa los recursos de Azure del sitio web y otro flujo de trabajo que implementa la aplicación del sitio web.
Aunque este enfoque puede ofrecer cierta flexibilidad en la forma de administrar los flujos de trabajo, puede ser complicado mantener todo sincronizado. Por ejemplo, suponga que el equipo del sitio web necesita una configuración nueva en la aplicación de Azure App Service para habilitar una característica que está compilando. El flujo de trabajo de implementación de aplicaciones no se puede ejecutar hasta que el de implementación de la infraestructura haya finalizado correctamente. Además, puede ser complicado enviar datos, como los nombres de los recursos de Azure creados por el flujo de trabajo de infraestructura, entre los flujos de trabajo.
En su lugar, a menudo es mejor crear un único flujo de trabajo que implemente todo lo necesario para la solución, incluso si diferentes equipos o diferentes personas administran los componentes. Puede usar herramientas como Git y GitHub para coordinar su trabajo. Cuando se agrega una característica nueva, puede usar una rama para realizar los cambios necesarios en el archivo de Bicep. Cuando el cambio esté listo para integrarse y liberarse, un único flujo de trabajo realiza todos los pasos necesarios para compilar e implementar la solución, lo que reduce la posibilidad de que las cosas se salgan de la sincronización.
Sugerencia
Al compilar código para la solución, probablemente deba implementarlo con frecuencia a fin de poder probar cómo funciona. Es posible que la implementación de la infraestructura junto con el código de la aplicación haga que el flujo de trabajo se ejecute lentamente e impida el progreso.
Si este es el caso, considere la posibilidad de deshabilitar la implementación de la infraestructura para el entorno de desarrollo. Puede usar filtros de ruta de acceso, flujos de trabajo reutilizables y condiciones para lograrlo. Pero debe dejar intacta la secuencia de implementación completa para los demás entornos.
El plano de control y el plano de datos
Muchos recursos de Azure proporcionan dos planos diferentes para el acceso. El plano de control implementa y configura el recurso. El plano de datos permite acceder a la función del recurso.
Al crear e implementar archivos de Bicep, se interactúa con el plano de control. En Azure, el plano de control es Azure Resource Manager. Resource Manager se usa para definir la configuración de cada uno de los recursos.
Sin embargo, el flujo de trabajo a menudo necesita hacer más que simplemente interactuar con el plano de control. Por ejemplo, podría ser necesario:
- Cargar un blob a una cuenta de almacenamiento
- Implementar un esquema de la base de datos
- Realizar una llamada API a un servicio de terceros
- Desencadene una actualización del modelo de Machine Learning.
- Implementar un sitio web en una aplicación de Azure App Service
- Implementar software en una máquina virtual
- Registrar una entrada DNS con un proveedor de terceros
Cuando considere un flujo de trabajo de un extremo a otro, normalmente necesita implementar los recursos de Azure y, a continuación, realizar una serie de operaciones en los planos de datos de esos recursos. A veces, estas operaciones se denominan el tramo final de la implementación, porque se realiza la mayor parte de la implementación mediante el plano de control y solo quedan unos pocos ajustes de configuración.
Nota:
Algunos recursos no tienen una división clara entre su plano de control y el plano de datos. Entre estos se incluyen Azure Data Factory y Azure API Management. Ambos servicios admiten implementaciones totalmente automatizadas mediante Bicep, pero requieren consideraciones especiales. En la página Resumen al final del módulo encontrará vínculos para obtener más información.
Cómo realizar operaciones de plano de datos
Al crear un flujo de trabajo de implementación que interactúe con el plano de datos de los recursos, puede usar cualquiera de entre tres enfoques comunes:
- Scripts de implementación de Resource Manager
- Scripts de flujo de trabajo
- Acciones de flujo de trabajo
Los scripts de implementación de Resource Manager se definen en el archivo de Bicep. Ejecutan scripts de Bash o PowerShell, y pueden interactuar con comandos de la CLI de Azure y con cmdlets de Azure PowerShell. Debe crear una identidad administrada para que el script de implementación se use a fin de autenticarse en Azure. Por su lado, Azure aprovisiona y administra automáticamente los demás recursos que necesita para ejecutar el script de implementación.
Los scripts de implementación son buenos cuando necesita ejecutar un script básico dentro del proceso de implementación, pero no proporcionan fácilmente acceso a otros elementos del flujo de trabajo.
También puede ejecutar su propia lógica en un flujo de trabajo de implementación. Acciones de GitHub proporciona un amplio ecosistema de acciones para cosas comunes que debe hacer. Si no encuentra una acción que satisfaga sus necesidades, puede usar un script para ejecutar su propio código de Bash o PowerShell. Las acciones de flujo de trabajo y los scripts se ejecutan desde el ejecutor del flujo de trabajo. A menudo, debe autenticar la acción o el script en el plano de datos del servicio que usa y cómo lo hace depende del servicio.
Las acciones y los scripts del flujo de trabajo proporcionan flexibilidad y control. También le permiten acceder a artefactos de flujo de trabajo, que aprenderá pronto. En este módulo, nos centramos en las acciones del flujo de trabajo. En la página Resumen al final del módulo ofrecemos vínculos para obtener más información sobre los scripts de implementación de Resource Manager.
Salidas
Normalmente, un flujo de trabajo crea y configura los recursos de Azure implementando un archivo de Bicep. A continuación, las partes posteriores del flujo de trabajo interactúan con el plano de datos de esos recursos. Para poder interactuar con los recursos, las acciones y los pasos del flujo de trabajo necesitan información sobre el recurso de Azure que se ha creado.
Por ejemplo, supongamos que tiene un archivo de Bicep que implementa una cuenta de almacenamiento. Quiere que el flujo de trabajo implemente la cuenta de almacenamiento y, después, cargue algunos blobs en un contenedor de blobs de la cuenta de almacenamiento. El paso del flujo de trabajo que carga los blobs debe conocer el nombre de la cuenta de almacenamiento a la que se conectará y el nombre del contenedor de blobs en el que se cargará el archivo.
Una buena práctica consiste en que el archivo de Bicep decida los nombres de los recursos de Azure. Puede usar parámetros, variables o expresiones para crear los nombres de la cuenta de almacenamiento y el contenedor de blobs. Después, el archivo de Bicep puede exponer una salida que proporcione el nombre de cada recurso. Los pasos posteriores del flujo de trabajo pueden leer el valor de salida. De este modo, la definición del flujo de trabajo no necesita codificar de forma rígida ningún nombre u otra información que pueda cambiar entre entornos o basarse en reglas definidas en el archivo de Bicep.
Con Acciones de GitHub, puede propagar los valores de las salidas mediante variables de flujo de trabajo. La acción azure/arm-deploy crea automáticamente variables para cada una de sus salidas de implementación de Bicep. También puede crear manualmente variables de flujo de trabajo en scripts. Encontrará vínculos a más información en la página Resumen al final de este módulo.
Al acceder a las variables que se crearon en otro trabajo, debe publicar la variable para que sea accesible para el trabajo que la lee. Por ejemplo, suponga que crea un trabajo que implementa un archivo de Bicep y necesita propagar la salida appServiceAppName al flujo de trabajo. Usa la palabra clave outputs para especificar que la variable de flujo de trabajo appServiceAppName debe establecerse en el valor de la variable de salida appServiceAppName creada por el paso deploy:
job1:
runs-on: ubuntu-latest
outputs:
appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
name: Sign in to Azure
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
id: deploy
name: Deploy Bicep file
with:
failOnStdErr: false
deploymentName: ${{ github.run_number }}
resourceGroupName: Playground1
template: ./deploy/main.bicep
A continuación, en un trabajo posterior, crea una dependencia explícita en el trabajo que creó la variable mediante la inclusión de la palabra clave needs, y hace referencia a la variable mediante el nombre de la variable publicada:
job2:
needs: job1
runs-on: ubuntu-latest
steps:
- run: |
echo "${{needs.job1.outputs.appServiceAppName}}"
Mediante el uso de salidas de Bicep y variables de flujo de trabajo, puede crear un flujo de trabajo que implemente el código de Bicep y, a continuación, realice diversas acciones en los recursos como parte de la implementación.