Uso de CI/CD con Acciones de GitHub para implementar una aplicación web de Python en Azure App Service en Linux

Use la plataforma de integración continua y entrega continua (CI/CD) de Acciones de GitHub para implementar una aplicación web de Python en App de Azure Service en Linux. El flujo de trabajo de Acciones de GitHub compila automáticamente el código e lo implementa en App Service siempre que haya una confirmación en el repositorio. Puede agregar otra automatización en el flujo de trabajo de Acciones de GitHub, como scripts de prueba, comprobaciones de seguridad y implementación de varias fases.

Creación de un repositorio para almacenar el código de la aplicación

Si ya tiene una aplicación web de Python para usarla, asegúrese de que se confirma en un repositorio de GitHub.

Si necesita una aplicación con la que trabajar, puede bifurcar y clonar el repositorio en https://github.com/Microsoft/python-sample-vscode-flask-tutorial. El código procede del tutorial de Flask en Visual Studio Code.

Creación del servicio App de Azure de destino

La forma más rápida de crear una instancia de App Service es usar la interfaz de la línea de comandos (CLI) de Azure a través de Azure Cloud Shell interactivo. Cloud Shell incluye Git y la CLI de Azure. En los pasos siguientes, usará az webapp para crear App Service y realizar la primera implementación de la aplicación.

Paso 1. Inicie sesión en Azure Portal en https://portal.azure.com.

Paso 2. Para abrir la CLI de Azure, seleccione el icono de Cloud Shell en la barra de herramientas del portal.

Paso 3. En Cloud Shell, seleccione Bash en la lista desplegable.

Paso 4. En Cloud Shell, clone el repositorio mediante git clone. Por ejemplo, si usa la aplicación de ejemplo de Flask, el comando es:

git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.git

Reemplace <github-user> por el nombre de la cuenta de GitHub donde bifurca el repositorio. Si usa un repositorio de aplicaciones diferente, este repositorio es donde configurará Acciones de GitHub.

Paso 5. En Cloud Shell, cambie el directorio a la carpeta del repositorio que tiene la aplicación de Python para que el comando az webapp up reconozca la aplicación como Python. Por ejemplo, para la aplicación de ejemplo de Flask:

cd python-sample-vscode-flask-tutorial

Paso 6. En Cloud Shell, use az webapp up para crear una instancia de App Service e implementar inicialmente la aplicación.

az webapp up --name <app-service-name> --runtime "PYTHON:3.9"

Especifique un nombre de App Service que sea único en Azure. El nombre debe tener entre 3 y 60 caracteres y solo puede contener letras, números y guiones. El nombre debe comenzar con una letra y terminar con una letra o un número.

Use az webapp list-runtimes para obtener una lista de los entornos de ejecución disponibles. Use el PYTHON|X.Y formato , donde X.Y es la versión de Python.

También puede especificar la ubicación de App Service con el --location parámetro . Use el az account list-locations --output table comando para obtener una lista de ubicaciones disponibles.

Paso 7. Si la aplicación usa un comando de inicio personalizado, use el comando az webapp config use ese comando. Si la aplicación no tiene un comando de inicio personalizado, omita este paso.

Por ejemplo, la aplicación python-sample-vscode-flask-tutorial contiene un archivo denominado startup.txt que contiene un comando de inicio que puede usar de la siguiente manera:

az webapp config set \
  --resource-group <resource-group-name> \
  --name <app-service-name> \
  --startup-file startup.txt

Puede encontrar el nombre del grupo de recursos en la salida del comando anterior az webapp up . El nombre del grupo de recursos comenzará con <azure-account-name>_rg_.

Paso 8. Para ver la aplicación en ejecución, abra un explorador y vaya a http:// app-service-name.azurewebsites.net><.

Si ve una página genérica, espere unos segundos para que se inicie la instancia de App Service y actualice la página. Si sigue viendo la página genérica, compruebe que implementó desde la carpeta correcta. Por ejemplo, si usa la aplicación de ejemplo de Flask, la carpeta es python-sample-vscode-flask-tutorial. Además, para la aplicación de ejemplo de Flask, compruebe que establece el comando de inicio correctamente.

Configuración de la implementación continua en App Service

En los pasos siguientes, configurará la implementación continua (CD), lo que significa que se produce una nueva implementación de código cuando se desencadena un flujo de trabajo. El desencadenador de este tutorial es cualquier cambio en la rama principal del repositorio, como con una solicitud de incorporación de cambios (PR).

Paso 1. Agregue Acción de GitHub con el comando az webapp deployment github-actions add .

az webapp deployment github-actions add \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

El --login-with-github parámetro usa un método interactivo para recuperar un token de acceso personal. Siga las indicaciones para completar la autenticación.

Si hay un archivo de flujo de trabajo existente que entra en conflicto con el nombre que usa App Service, se le pedirá que elija si desea sobrescribir. Use el --force parámetro para sobrescribir sin preguntar.

Qué hace el comando add:

• Crea un nuevo archivo de flujo de trabajo: .github/workflows/<workflow-name.yml> en el repositorio; el nombre del archivo contendrá el nombre de app Service.
• Captura un perfil de publicación con secretos para App Service y lo agrega como secreto de acción de GitHub. El nombre del secreto comenzará con AZUREAPPSERVICE_PUBLISHPROFILE_. Se hace referencia a este secreto en el archivo de flujo de trabajo.

Paso 2. Obtenga los detalles de una configuración de implementación de control de código fuente con el comando az webapp deployment source show .

az webapp deployment source show \
  --name <app-service-name> \
  --resource-group <resource-group-name>

En la salida del comando , confirme los valores de las repoUrl propiedades y branch . Estos valores deben coincidir con los valores especificados en el paso anterior.

Flujo de trabajo y acciones de GitHub explicados

Un flujo de trabajo se define mediante un archivo YAML (.yml) en la ruta de acceso /.github/workflows/ del repositorio. Este archivo YAML contiene los distintos pasos y parámetros que componen el flujo de trabajo, un proceso automatizado asociado a un repositorio de GitHub. Puede compilar, probar, empaquetar, liberar e implementar cualquier proyecto en GitHub con un flujo de trabajo.

Cada flujo de trabajo se compone de uno o varios trabajos. Cada trabajo a su vez es un conjunto de pasos. Y, por último, cada paso es un script de shell o una acción.

En términos del flujo de trabajo configurado con el código de Python para la implementación en App Service, el flujo de trabajo tiene las siguientes acciones:

La plantilla de flujo de trabajo que se usa para crear el flujo de trabajo es Azure/actions-workflow-samples.

El flujo de trabajo se desencadena en eventos de inserción en la rama especificada. El evento y la rama se definen al principio del archivo de flujo de trabajo. Por ejemplo, el siguiente fragmento de código muestra que el flujo de trabajo se desencadena en eventos de inserción en la rama principal :

on:
  push:
    branches:
    - main

Aplicaciones autorizadas de OAuth

Al configurar la implementación continua, autoriza App de Azure Service como una aplicación de OAuth autorizada para su cuenta de GitHub. App Service usa el acceso autorizado para crear un archivo YML de acción de GitHub en .github/workflows/<workflow-name.yml>. Puede ver las aplicaciones autorizadas y revocar permisos en las cuentas de GitHub Configuración, en Integraciones o aplicaciones.

Secreto de perfil de publicación de flujo de trabajo

En el archivo de flujo de trabajo .github/workflow-name.yml<> que se agregó al repositorio, verá un marcador de posición para las credenciales de perfil de publicación necesarias para el trabajo de implementación del flujo de trabajo. La información del perfil de publicación se almacena cifrada en el repositorio Configuración, en Seguridad y acciones.

En este artículo, la acción de GitHub se autentica con una credencial de perfil de publicación. Hay otras maneras de autenticarse, como con una entidad de servicio o openID Conectar. Para obtener más información, consulte Implementación en App Service mediante Acciones de GitHub.

Ejecutar el flujo de trabajo

Ahora probará el flujo de trabajo realizando un cambio en el repositorio.

Paso 1. Vaya a la bifurcación del repositorio de ejemplo (o el repositorio que usó) y seleccione la rama que estableció como parte del desencadenador.

Paso 2. Realice un pequeño cambio.

Por ejemplo, si usó el tutorial de FLASK de VS Code, puede

• Vaya al archivo /hello-app/templates/home.html de la rama del desencadenador.
• Seleccione Editar y agregue el texto "Redeployed!".

Paso 3. Confirme el cambio directamente en la rama en la que trabaja.

• En la esquina superior derecha de la página que está editando, seleccione el botón Confirmar cambios ... . Se abre la ventana Confirmar cambios . En la ventana Confirmar cambios , modifique el mensaje de confirmación si lo desea y, a continuación, seleccione el botón Confirmar cambios .
• La confirmación inicia el flujo de trabajo de Acciones de GitHub.

También puede iniciar manualmente el flujo de trabajo.

Paso 1. Vaya a la pestaña Acciones del repositorio configurado para la implementación continua.

Paso 2. Seleccione el flujo de trabajo en la lista de flujos de trabajo y, a continuación, seleccione Ejecutar flujo de trabajo.

Solución de problemas de un flujo de trabajo con errores

Para comprobar el estado de un flujo de trabajo, vaya a la pestaña Acciones del repositorio. Al profundizar en el archivo de flujo de trabajo creado en este tutorial, verá dos trabajos "build" y "deploy". Para un trabajo con errores, examine la salida de las tareas de trabajo para obtener una indicación del error. Algunos de los problemas más comunes son:

• Si se produce un error en la aplicación debido a una dependencia que falta, el archivo requirements.txt no se procesó durante la implementación. Este comportamiento se produce si creó la aplicación web directamente en el portal en lugar de usar el comando az webapp up como se muestra en este artículo.

• Si aprovisionó el servicio de aplicaciones a través del portal, es posible que no se haya establecido la acción de compilación SCM_DO_BUILD_DURING_DEPLOYMENT configuración. Esta configuración debe establecerse en true. El az webapp up comando establece automáticamente la acción de compilación.

• Si ve un mensaje de error con el tiempo de espera del protocolo de enlace TLS, ejecute el flujo de trabajo manualmente seleccionando Desencadenar implementación automática en la pestaña Acciones del repositorio para ver si el tiempo de espera es un problema temporal.

• Si configura la implementación continua para la aplicación contenedora como se muestra en este tutorial, el archivo de flujo de trabajo (.github/workflows/<workflow-name.yml>) se crea inicialmente automáticamente. Si lo modificó, quite las modificaciones para ver si están causando el error.

Ejecución de un script posterior a la implementación

Un script posterior a la implementación puede, por ejemplo, definir variables de entorno esperadas por el código de la aplicación. Agregue el script como parte del código de la aplicación y ejecútelo mediante el comando de inicio.

Para evitar valores de variables de codificación rígida en el archivo YML de flujo de trabajo, puede hacerlos en la interfaz web de GitHub y, a continuación, hacer referencia al nombre de la variable en el script. Puede crear secretos cifrados para un repositorio o para un entorno (repositorio de cuentas). Para obtener más información, consulte Secretos cifrados en La documentación de GitHub.

Consideraciones para Django

Como se indicó anteriormente en este artículo, puede usar Acciones de GitHub para implementar aplicaciones de Django en App de Azure Service en Linux, si usa una base de datos independiente. No se puede usar una base de datos SQLite, ya que App Service bloquea el archivo db.sqlite3, lo que impide tanto las lecturas como las escrituras. Este comportamiento no afecta a una base de datos externa.

Como se describe en el artículo Configuración de la aplicación python en App Service: proceso de inicio de contenedor, App Service busca automáticamente un archivo wsgi.py dentro del código de la aplicación, que normalmente contiene el objeto de aplicación. Cuando usó el webapp config set comando para establecer el comando de inicio, usó el --startup-file parámetro para especificar el archivo que contiene el objeto de aplicación. El webapp config set comando no está disponible en la acción webapps-deploy. En su lugar, puede usar el startup-command parámetro para especificar el comando de inicio. Por ejemplo, el siguiente fragmento de código muestra cómo especificar el comando de inicio en el archivo de flujo de trabajo:

startup-command: startup.txt

Al usar Django, normalmente quiere migrar los modelos de datos mediante python manage.py migrate el comando después de implementar el código de la aplicación. Puede ejecutar el comando migrate en un script posterior a la implementación.

Desconectar acciones de GitHub

La desconexión de Acciones de GitHub de App Service permite volver a configurar la implementación de la aplicación. Puede elegir lo que sucede con el archivo de flujo de trabajo después de desconectarse, ya sea para guardar o eliminar el archivo.

az webapp deployment github-actions remove \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

Limpieza de recursos

Para evitar incurrir en cargos en los recursos de Azure creados en este tutorial, elimine el grupo de recursos que contiene la instancia de App Service y el plan de App Service.

az group delete --name <resource-group-name>

Para eliminar la cuenta de almacenamiento que mantiene el sistema de archivos para Cloud Shell, lo que conlleva un pequeño cargo mensual, elimine el grupo de recursos que comienza con cloud-shell-storage-. Si es el único usuario del grupo, es seguro eliminar el grupo de recursos. Si hay otros usuarios, puede eliminar una cuenta de almacenamiento en el grupo de recursos.

Si eliminó el grupo de recursos de Azure, considere la posibilidad de realizar también las siguientes modificaciones en la cuenta de GitHub y el repositorio conectados para la implementación continua:

• En el repositorio, quite el archivo .github/workflows/<workflow-name.yml>.
• En la configuración del repositorio, quite la clave secreta AZUREAPPSERVICE_PUBLISHPROFILE_ creada para el flujo de trabajo.
• En la configuración de la cuenta de GitHub, quite App de Azure Service como una aplicación de Oauth autorizada para su cuenta de GitHub.