Implementación de aplicaciones web de Python en App Service mediante Acciones de GitHub (Linux)

En este artículo se describe cómo usar la plataforma de integración continua y entrega continua (CI/CD) en Acciones de GitHub para implementar una aplicación web de Python en Azure App Service en Linux. El flujo de trabajo de Acciones de GitHub compila automáticamente el código e lo implementa en la instancia de 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 el código de la aplicación

Para completar los procedimientos de este artículo, necesita una aplicación web de Python confirmada en un repositorio de GitHub.

• Aplicación existente: para usar una aplicación web de Python existente, asegúrese de que la aplicación está confirmada en un repositorio de GitHub.

• Nueva aplicación: si necesita una nueva aplicación web de Python, puede bifurcar y clonar el https://github.com/Microsoft/python-sample-vscode-flask-tutorial repositorio de GitHub. El código de ejemplo admite el tutorial de Flask en Visual Studio Code y proporciona una aplicación de Python en funcionamiento.

Creación de una instancia de App Service 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 el procedimiento siguiente, usará el comando az webapp up para crear la instancia de App Service y realizar la implementación inicial de la aplicación.

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

2. Para abrir la CLI de Azure, seleccione la opción Cloud Shell en la barra de herramientas del portal:

   

3. En Cloud Shell, seleccione la opción Bash en el menú desplegable:

   

4. En Cloud Shell, clone el repositorio mediante el comando git clone .

   Sugerencia

   Para pegar comandos o texto en Cloud Shell, use el método abreviado de teclado Ctrl+Mayús+V o haga clic con el botón derecho y seleccione Pegar en el menú contextual.

   • Para la aplicación de ejemplo de Flask, puede usar el siguiente comando. Reemplaza la parte <github-user> por el nombre de la cuenta de GitHub donde bifurcaste el repositorio.

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

   • Si la aplicación está en un repositorio diferente, configure Acciones de GitHub para el repositorio determinado. Reemplace la cuenta de GIthub <github-user> sección por el nombre de la donde bifurcó el repositorio y proporcione el nombre real del repositorio en el marcador de posición <repo-name>:

     git clone https://github.com/<github-user>/<repo-name>.git
     

   Nota:

   Cloud Shell está respaldado por una cuenta de Azure Storage en un grupo de recursos denominado cloud-shell-storage-your-region<>. Esa cuenta de almacenamiento contiene una imagen del sistema de archivos de Cloud Shell, que almacena el repositorio clonado. Este almacenamiento tiene un pequeño costo. Puede eliminar la cuenta de almacenamiento después de completar este artículo, junto con otros recursos que cree.

5. En Cloud Shell, cambie el directorio a la carpeta del repositorio de la aplicación de Python, por lo que el comando az webapp up reconoce la aplicación como Python. Para la aplicación de ejemplo de Flask, use el siguiente comando:

   cd python-sample-vscode-flask-tutorial
   

6. En Cloud Shell, use el comando az webapp up para crear una instancia de App Service y realizar la implementación inicial de la aplicación:

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

   • Para el marcador de posición <app-service-name>, 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.

   • Para obtener una lista de los entornos de ejecución disponibles en el sistema, use el comando az webapp list-runtimes.

   • Cuando escriba el valor en tiempo de ejecución en el comando, use el formato PYTHON:X.Y, donde X.Y es la versión principal y secundaria de Python.

   • También puede especificar la ubicación de región de la instancia de App Service mediante el --___location parámetro . Para obtener una lista de ubicaciones disponibles, use el az account list-locations --output table comando .

7. Si la aplicación tiene un script de inicio personalizado, use el comando az webapp config para iniciar el script.

   • Si la aplicación no tiene un script de inicio personalizado, continúe con el paso siguiente.

   • Para la aplicación de ejemplo de Flask, debe acceder al script de inicio en el archivo startup.txt mediante la ejecución del comando siguiente:

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

     Proporcione el nombre del grupo de recursos y el nombre de la instancia de App Service en los <resource-group-name> y <app-service-name> placeholders. Para buscar el nombre del grupo de recursos, compruebe la salida del comando anterior az webapp up . El nombre del grupo de recursos incluye el nombre de la cuenta de Azure seguido del sufijo _rg , como en <azure-account-name>_rg_.

8. Para ver la aplicación en ejecución, abra un explorador y vaya al punto de conexión de implementación de la instancia de App Service. En la siguiente dirección URL, reemplace el marcador de posición <app-service-name> con el nombre de su instancia de App Service.

   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 una página genérica, confirme que implementó desde la carpeta correcta.
   • Para la aplicación de ejemplo de Flask, confirme que implementó desde la carpeta python-sample-vscode-flask-tutorial . Compruebe también que ha establecido el comando de inicio correctamente.

Configura la implementación continua en el App Service

En el siguiente procedimiento, configurará la entrega continua (CD), lo que significa que se produce una nueva implementación de código cada vez que se desencadena un flujo de trabajo. El desencadenador del ejemplo de artículo es cualquier cambio en la rama principal del repositorio, como con una solicitud de incorporación de cambios (PR).

1. En Cloud Shell, confirme que está en el directorio raíz del sistema (~) y no en una subcarpeta de aplicación, como python-sample-vscode-flask-tutorial.

2. Agregue Acciones de GitHub con el comando az webapp deployment github-actions add . Reemplace los marcadores de posición por sus valores específicos:

   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 y complete la autenticación.

   • Si el sistema encuentra un archivo de flujo de trabajo existente con el mismo nombre de instancia de App Service, siga las indicaciones para elegir si se sobrescribe el flujo de trabajo. Puede usar el --force parámetro con el comando para sobrescribir automáticamente los flujos de trabajo en conflicto.

   El add comando completa las siguientes tareas:

   • Crea un nuevo archivo de flujo de trabajo en la ruta .github/workflows/<workflow-name>.yml de tu repositorio. El nombre de archivo contiene el nombre de la instancia de App Service.
   • Captura un perfil de publicación con secretos para la instancia de App Service y lo agrega como un secreto de acción de GitHub. El nombre del secreto comienza por AZUREAPPSERVICE_PUBLISHPROFILE_. Se hace referencia a este secreto en el archivo de flujo de trabajo.

3. Obtenga los detalles de una configuración de implementación de control de código fuente con el comando az webapp deployment source show . Reemplace los parámetros de marcador de posición por sus valores específicos:

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

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

Examen del flujo de trabajo y las acciones de GitHub

Se especifica una definición de flujo de trabajo en 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, y cada trabajo es un conjunto de pasos. Cada paso es un script de shell o una acción. Cada trabajo tiene una sección Acción en el archivo de flujo de trabajo.

En términos del flujo de trabajo configurado con el código de Python para la implementación en Azure 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 workflow se desencadena por eventos de envío sobre 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 push de la rama main:

on:
  push:
    branches:
    - main

Aplicaciones autorizadas de OAuth

Al configurar la implementación continua, autoriza Azure App Service como una aplicación de OAuth autorizada para su cuenta de GitHub. App Service utiliza el acceso autorizado para crear un archivo YAML de acción de GitHub en la ruta .github/workflows/<workflow-name>.yml de tu repositorio.

Para ver las aplicaciones autorizadas y revocar permisos en las cuentas de GitHub, vaya a Configuración>Integrations/Applications:

Secreto del perfil de publicación del workflow

En el archivo de workflow .github/workflows/<workflow-name>.yml agregado a tu repositorio, hay un marcador de posición para las credenciales del perfil de publicación necesarias para la tarea de implementación del workflow. La información del perfil de publicación se almacena cifrada en el repositorio.

Para ver el secreto, vaya a Configuración>Seguridad>Secretos y variables>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 Connect. Para obtener más información, consulte Implementación en App Service mediante Acciones de GitHub.

Ejecución y prueba del flujo de trabajo

El último paso es probar el flujo de trabajo realizando un cambio en el repositorio.

1. En un explorador, vaya a la bifurcación del repositorio de ejemplo (o el repositorio que usó) y seleccione la rama que estableció como parte del desencadenador:

   

2. Realice un pequeño cambio en la aplicación web de Python.

   Para el tutorial de Flask, este es un cambio sencillo:

   1. Vaya al archivo /hello-app/templates/home.html de la rama del desencadenador.
   2. Seleccione Editar (lápiz).
   3. En el Editor, busque la instrucción print <p> y agregue el texto "Redeployed!"

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

   1. En el Editor, seleccione Confirmar cambios en la parte superior derecha. Se abre la ventana Confirmar cambios .
   2. En la ventana Confirmar cambios , modifique el mensaje de confirmación según sea necesario y seleccione Confirmar cambios.

   El proceso de confirmación desencadena el flujo de trabajo de Acciones de GitHub.

También puede desencadenar manualmente el flujo de trabajo:

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

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 flujo de trabajo fallido

Puede comprobar el estado de un flujo de trabajo en la pestaña Acciones del repositorio de aplicaciones. Al examinar el archivo de flujo de trabajo creado en este artículo, verá dos trabajos: compilar e implementar. Como recordatorio, el flujo de trabajo se basa en la plantilla Azure/actions-workflow-samples .

Para un trabajo fallido, examine los resultados de las tareas del trabajo para obtener una indicación del error.

Estos son algunos problemas comunes para investigar:

• 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 az webapp up comando como se muestra en este artículo.

• Si aprovisionaste el servicio de aplicaciones a través del portal, es posible que la acción de compilación SCM_DO_BUILD_DURING_DEPLOYMENT no esté configurada. 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 relacionado 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 de aplicaciones. Puede determinar si el tiempo de espera (timeout) es un problema temporal.

• Si configura la implementación continua para la aplicación contenedora como se muestra en este artículo, el archivo de flujo de trabajo inicial .github/workflows/<workflow-name>.yml se crea automáticamente. Si ha modificado el archivo, quite las modificaciones para ver si están causando el error.

Ejecución del script posterior a la implementación

Un script posterior a la implementación puede completar varias tareas, como 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 ejecute el script mediante el comando de inicio.

Para evitar valores de variables de codificación rígida en el archivo YAML de flujo de trabajo, considere la posibilidad de configurar las variables en GitHub y hacer referencia a los nombres de 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 Uso de secretos en Acciones de GitHub.

Revisión de las consideraciones de Django

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

En el artículo Configuración de la aplicación Python en App Service: proceso de inicio de contenedor se describe cómo 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 código siguiente 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 el python manage.py migrate 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 la instancia 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 y si desea guardar o eliminar el archivo.

az webapp deployment github-actions remove \
  --repo "<github-username>/<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 artículo, 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>

Eliminar cuenta de almacenamiento

Para eliminar la cuenta de almacenamiento que mantiene el sistema de archivos de Cloud Shell, que incurre en 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.

Actualización de la cuenta y el repositorio de GitHub

Si elimina el grupo de recursos de Azure, considere la posibilidad de realizar las siguientes modificaciones en la cuenta de GitHub y el repositorio que se conectó para la implementación continua:

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

Contenido relacionado

• Repositorios y flujos de trabajo comunes para Acciones de GitHub
• Referencia del comando: az webapp deployment github-actions