Compartir a través de

Implementación de App Service con Acciones de GitHub

  • Artículo

Comience a usar Acciones de GitHub para automatizar el flujo de trabajo e implementarlo en Azure App Service desde GitHub.

Requisitos previos

Configuración de la implementación de Acciones de GitHub al crear la aplicación

La implementación de las Acciones de GitHub está integrada en la aplicación predeterminada Proceso de creación de aplicaciones web. Establezca Implementación continua en Habilitar en la pestaña Implementación y configure la organización, el repositorio y la rama que desee.

Captura de pantalla que muestra cómo habilitar la implementación de Acciones de GitHub en la pestaña Crear implementación de App Service.

Al habilitar la implementación continua, la creación de aplicaciones elige automáticamente el método de autenticación en función de la selección de autenticación básica y configura la aplicación y el repositorio de GitHub en consecuencia:

Selección de autenticación básica Método de autenticación
Deshabilitar Identidad asignada por el usuario (OpenID Connect) (recomendado)
Habilitar Autenticación básica

Nota:

Es posible que reciba un error al crear la aplicación que la cuenta de Azure no tiene determinados permisos. Es posible que la cuenta necesite los permisos necesarios para crear y configurar la identidad asignada por el usuario. Para obtener una alternativa, consulte Configuración de la implementación de Acciones de GitHub desde el centro de implementación.

Configuración de la implementación de Acciones de GitHub desde el centro de implementación

Para una aplicación existente, puede empezar a trabajar rápidamente con Acciones de GitHub con el centro de implementación de App Service. Este método de llave a paso genera un archivo de flujo de trabajo de Acciones de GitHub basado en la pila de aplicaciones y lo confirma en el repositorio de GitHub.

El Centro de implementación también le permite configurar fácilmente la autenticación de OpenID Connect más segura con una identidad asignada por el usuario . Para obtener más información, consulte la opción de identidad asignada por el usuario.

Si la cuenta de Azure tiene los permisos necesarios , puede crear una identidad asignada por el usuario. De lo contrario, puede seleccionar una identidad administrada asignada por el usuario existente en el menú desplegable Identidad. Puede trabajar con el administrador de Azure para crear una identidad administrada asignada por el usuario con el rol Colaborador del sitio web.

Para más información, consulte Implementación continua en Azure App Service.

Configuración manual de un flujo de trabajo de Acciones de GitHub

Puede implementar un flujo de trabajo sin usar el Centro de implementación. En ese caso, debe realizar tres pasos:

  1. Genere las credenciales de implementación
  2. Configuración del secreto de GitHub
  3. Adición del archivo de flujo de trabajo al repositorio de GitHub

Genere las credenciales de implementación

La manera recomendada de autenticarse con Azure App Services para Acciones de GitHub es con OpenID Connect. Este enfoque es un método de autenticación que usa tokens de corta duración. La configuración de OpenID Connect con Acciones de GitHub es más compleja, pero ofrece seguridad reforzada.

Como alternativa, puede autenticarse con una identidad administrada asignada por el usuario, una entidad de servicio o un perfil de publicación.

En el procedimiento siguiente se describen los pasos para crear una aplicación de Microsoft Entra, una entidad de servicio y credenciales federadas mediante instrucciones de la CLI de Azure. Para más información sobre cómo crear una aplicación de Microsoft Entra, un principal de servicio y credenciales federadas en el portal Azure, consulte Conectar GitHub y Azure.

  1. Si no tiene una aplicación existente, registre una nueva aplicación de Microsoft Entra y una entidad de servicio que puedan acceder a los recursos. Creación de una aplicación de Microsoft Entra.

    az ad app create --display-name myApp

    Este comando devuelve un JSON con un appId que es el client-id. Guarde el valor que se usará como secreto de GitHub de AZURE_CLIENT_ID más adelante.

    Use el valor de objectId al crear credenciales federadas con Graph API y haga referencia a dicho valor como APPLICATION-OBJECT-ID.

  2. Crear una entidad de servicio. Reemplace $appID por el valor de appId de la salida de JSON.

    Este comando genera una salida JSON con un objectId diferente que se usará en el paso siguiente. El nuevo objectId es assignee-object-id.

    Copie el appOwnerTenantId para usarlo como secreto de GitHub para AZURE_TENANT_ID más adelante.

    az ad sp create --id $appId

  3. Cree una asignación de roles por suscripción y objeto. De forma predeterminada, la asignación de roles se vincula a la suscripción predeterminada. Reemplace $subscriptionId por el identificador de suscripción, $resourceGroupName por el nombre del grupo de recursos, $webappName por el nombre de la aplicación web y $assigneeObjectId por el id generado. Obtenga información sobre cómo administrar suscripciones de Azure con la CLI de Azure.

    az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --scope /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/$webappName --assignee-principal-type ServicePrincipal

  4. Ejecute el comando siguiente para crear una nueva credencial de identidad federada para la aplicación Entra.

    • Reemplace APPLICATION-OBJECT-ID por el appId (generado al crear la aplicación) para la aplicación de Active Directory.

    • Establezca un valor para CREDENTIAL-NAME al que haga referencia más adelante.

    • Establezca subject. GitHub define su valor en función del flujo de trabajo:

      • Para trabajos en el entorno de Acciones de GitHub: repo:< Organization/Repository >:environment:< Name >
      • En el caso de los trabajos no vinculados a un entorno, incluya la ruta de acceso de referencia para una rama o etiqueta en función de la ruta de acceso de referencia usada para desencadenar el flujo de trabajo: repo:< Organization/Repository >:ref:< ref path>. Por ejemplo, repo:n-username/ node_express:ref:refs/heads/my-branch o repo:n-username/ node_express:ref:refs/tags/my-tag.
      • En el caso de los flujos de trabajo desencadenados por un evento de solicitud de incorporación de cambios: repo:< Organization/Repository >:pull_request.
    az ad app federated-credential create --id <APPLICATION-OBJECT-ID> --parameters credential.json
("credential.json" contains the following content)
{
    "name": "<CREDENTIAL-NAME>",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:organization/repository:ref:refs/heads/main",
    "description": "Testing",
    "audiences": [
        "api://AzureADTokenExchange"
    ]
}

Configuración del secreto de GitHub

Debe proporcionar el identificador de cliente de la aplicación, Id. de clientey id. de suscripción a la acción inicio de sesión de Azure. Estos valores se pueden proporcionar directamente en el flujo de trabajo o se pueden almacenar en secretos de GitHub y se puede hacer referencia a ellos en el flujo de trabajo. Guardar los valores como secretos de GitHub es la opción más segura.

  1. Abra el repositorio de GitHub y vaya a Configuración>Seguridad>Secretos y variables>Acciones>Nuevo repositorio secreto.

  2. Cree secretos para AZURE_CLIENT_ID, AZURE_TENANT_ID y AZURE_SUBSCRIPTION_ID. Use estos valores de la aplicación de Active Directory para los secretos de GitHub:

    Secreto de GitHub Aplicación de Active Directory
    AZURE_CLIENT_ID Id. de aplicación (cliente)
    AZURE_TENANT_ID Id. de directorio (inquilino)
    AZURE_SUBSCRIPTION_ID Id. de suscripción

  3. Guarde todos los secretos, para lo que debe seleccionar Add secret (Agregar secreto).

Adición del archivo de flujo de trabajo al repositorio de GitHub

Un archivo YAML (.yml) en la ruta de acceso /.github/workflows/ del repositorio de GitHub define un flujo de trabajo. En esta definición se incluyen los diversos pasos y parámetros que componen el flujo de trabajo.

Como mínimo, el archivo de flujo de trabajo tendría los siguientes pasos diferenciados:

  1. Autentíquese con App Service mediante el secreto de GitHub que creó.
  2. Cree la aplicación web.
  3. Implemente la aplicación web.

Para implementar el código en una aplicación de App Service, use la acción azure/webapps-deploy@v3. La acción requiere el nombre de la aplicación web en app-name y, en función de la pila de lenguaje, la ruta de acceso de un *.zip, *.war, *.jar o carpeta para implementar en package. Para obtener una lista completa de las posibles entradas para la acción de azure/webapps-deploy@v3, consulte action.yml.

En los siguientes ejemplos se muestra la parte del flujo de trabajo que compila la aplicación web en los diversos lenguajes admitidos.

Para implementar con OpenID Connect mediante la identidad administrada que configuró, use la azure/login@v2acción con las claves client-id, tenant-idy subscription-id. Haga referencia a los secretos de GitHub que creó anteriormente.

name: .NET Core

on: [push]

permissions:
      id-token: write
      contents: read

env:
  AZURE_WEBAPP_NAME: my-app    # set this to your application's name
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root
  DOTNET_VERSION: '6.0.x'           # set this to the dot net version to use

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # Checkout the repo
      - uses: actions/checkout@main
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      
      # Setup .NET Core SDK
      - name: Setup .NET Core
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }} 
      
      # Run dotnet build and publish
      - name: dotnet build and publish
        run: |
          dotnet restore
          dotnet build --configuration Release
          dotnet publish -c Release --property:PublishDir='${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp' 
          
      # Deploy to Azure Web apps
      - name: 'Run Azure webapp deploy action using publish profile credentials'
        uses: azure/webapps-deploy@v3
        with: 
          app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name
          package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'
      
      - name: logout
        run: |
          az logout

Preguntas más frecuentes

¿Cómo implemento un archivo WAR mediante el complemento Maven?

En caso de configurar el proyecto de Java Tomcat con el Complemento Maven, también puede implementarlo en Azure App Service a través de este complemento. Si usa la acción de GitHub de la CLI de Azure, usa las credenciales de Azure.

    - name: Azure CLI script file
      uses: azure/cli@v2
      with:
        inlineScript: |
          mvn package azure-webapp:deploy

Para más información sobre el complemento Maven y cómo usarlo y configurarlo, consulte Wiki del complemento Maven para Azure App Service.

¿Cómo se implementa un archivo WAR a través de la CLI de zona de disponibilidad?

Si prefiere que la CLI de Azure se implemente en App Service, puede usar la acción de GitHub para la CLI de Azure.

- name: Azure CLI script
  uses: azure/cli@v2
  with:
    inlineScript: |
      az webapp deploy --src-path '${{ github.workspace }}/target/yourpackage.war' --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.RESOURCE_GROUP }}  --async true --type war

Para más información sobre la acción de GitHub para la CLI y cómo usarla y configurarla, consulte Acción de GitHub de la CLI de Azure.

Para obtener más información sobre el comando az webapp deploy, cómo usarlo y los detalles del parámetro, consulte documentación de az webapp deploy.

¿Cómo se implementa un archivo de inicio?

Use la acción de GitHub para la CLI. Por ejemplo:

- name: Deploy startup script
  uses: azure/cli@v2
  with:
    inlineScript: |
      az webapp deploy --src-path ${{ github.workspace }}/src/main/azure/createPasswordlessDataSource.sh --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.RESOURCE_GROUP }} --type startup --track-status false

¿Cómo se implementa en un contenedor?

Gracias a la acción de Azure Web Deploy, puede automatizar el flujo de trabajo para implementar contenedores personalizados en App Service con Acciones de GitHub. Para obtener más información sobre los pasos para implementar mediante Acciones de GitHub, consulte Implementación en un contenedor.

¿Cómo se actualiza la configuración de Tomcat después de la implementación?

En caso de que quiera actualizar la configuración de alguna de sus aplicaciones web una vez implementadas, puede usar la acción Configuración del servicio de aplicaciones.

    - uses: azure/appservice-settings@v1
      with:
        app-name: 'my-app'
        slot-name: 'staging'  # Optional and needed only if the settings have to be configured on the specific deployment slot
        app-settings-json: '[{ "name": "CATALINA_OPTS", "value": "-Dfoo=bar" }]' 
        connection-strings-json: '${{ secrets.CONNECTION_STRINGS }}'
        general-settings-json: '{"alwaysOn": "false", "webSocketsEnabled": "true"}' #'General configuration settings as Key Value pairs'
      id: settings

Para obtener más información sobre esta acción y cómo usarla y configurarla, consulte el repositorio configuración de App Service.

Contenido relacionado

Consulte las referencias en flujos de trabajo y Acciones de GitHub de Azure: