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 Acciones de GitHub se integra en el asistente de creación de aplicaciones predeterminado. Solo tiene que establecer Implementación continua en Habilitar en la pestaña Implementación y configurar 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 el Asistente para crear App Service.

Al habilitar la implementación continua, el asistente de creación de aplicaciones selecciona 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:

Si recibe un error al crear la aplicación diciendo que la cuenta de Azure no tiene determinados permisos, es posible que no tenga 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 llave en mano genera automáticamente 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 la opción identidad asignada por el usuario.

Si la cuenta de Azure tiene los permisos necesarios, puede seleccionar crear una identidad asignada por el usuario. De lo contrario, puede seleccionar una identidad administrada asignada por el usuario existente en la lista 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

También puede implementar un flujo de trabajo sin usar el centro de implementación. En ese caso, debe realizar 3 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

1. Genere las credenciales de implementación.

La manera recomendada de autenticarse con Azure App Services para Acciones de GitHub es con OpenID Connect. Se trata de 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.

A continuación se describen los pasos para crear una aplicación de Active Directory, 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 directorio activo, 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 Active Directory y una entidad de servicio que puedan acceder a los recursos. Cree la aplicación de Active Directory.

    az ad app create --display-name myApp

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

    Usará el valor de objectId al crear credenciales federadas con Graph API y hará 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 de JSON con un objectId diferente y se usará en el siguiente paso. 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 siguiente comando para crear una credencial de identidad federada para la aplicación de Active Directory.

    • 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. Su valor lo define GitHub en función del flujo de trabajo:
      • 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"
    ]
}

2. Configuración del secreto de GitHub

Debe especificar el identificador de cliente, el identificador de inquilino y el identificador de suscripción en la acción de Azure/login. 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 secreto de repositorio.

  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).

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

Un archivo YAML (.yml) define un flujo de trabajo en la ruta de acceso /.github/workflows/ de su repositorio de GitHub. 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 azure/webapps-deploy@v3, consulte la definición de 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 acción azure/login@v1 con las claves de client-id, tenant-id y subscription-id, y 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@v1
        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, usará las credenciales de inicio de sesión de Azure.

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

Puede encontrar más información sobre el complemento de Maven y sobre cómo usarlo y configurarlo en la wiki del Complemento de 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

Puede encontrar más información sobre la acción GitHub para CLI y sobre cómo usarla y configurarla, consulte la Acción Azure CLI GitHub. Puede encontrar más información sobre el comando de implementación de aplicaciones web az, cómo utilizarlo y los detalles de los parámetros en la documentación de implementación de aplicaciones web az.

¿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. Puede encontrar información sobre los pasos para la implementación a través de las acciones de GitHub en la sección 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

Puede encontrar más información sobre esta acción y sobre cómo usarla y configurarla en el repositorio Configuración de App Service.

Pasos siguientes

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