Implante no Azure Functions usando o GitHub Actions

Você pode usar um fluxo de trabalho GitHub Actions para construir e implantar automaticamente seu código de função no Azure usando o Azure/functions-actionarquivo .

Para implantar usando o GitHub Actions, complete estes três passos principais:

  1. Crie uma identidade gerenciada atribuída pelo usuário no Azure com uma credencial federada que confie no seu repositório GitHub, e atribua-lhe o papel de Contribuidor do Site no seu aplicativo de funções.
  2. Adicione o ID do cliente, o ID do tenant e o ID de assinatura da identidade como segredos do repositório no GitHub.
  3. Adicione um arquivo YAML de workflow ao seu repositório que use azure/login com OpenID Connect (OIDC) para autenticar, e então chame Azure/functions-action para implantar.

Quando você usa o portal do Azure para habilitar o GitHub Actions, o Functions executa automaticamente essas tarefas, tanto na sua assinatura do Azure quanto no seu repositório do GitHub.

Crie uma configuração de fluxo de trabalho para o Azure Functions

Você mantém um arquivo YAML (.yml) que define a configuração do fluxo de trabalho no /.github/workflows/ caminho do seu repositório. Essa definição contém as ações e parâmetros que compõem o fluxo de trabalho, que é específico para a linguagem de desenvolvimento de suas funções.

Escolha um método para criar seu arquivo de fluxo de trabalho usando o seletor no topo do artigo:

Método Mais adequado para Suporte OIDC
Modelo de fluxo de trabalho Controle total: copie um template pronto para OIDC e personalize-o Requer configuração
Portal do Azure Configuração mais fácil: o portal pode criar a identidade, credenciais e arquivo de fluxo de trabalho para você Configurado para você
Marketplace do GitHub GitHub-first: comece pelos templates embutidos do marketplace do GitHub Requer configuração e modificação de template

Visão geral da autenticação

GitHub Actions deve autenticar com o Azure para implantar seu código. Este artigo utiliza o OpenID Connect (OIDC), que é o método de autenticação recomendado. O OIDC utiliza credenciais federadas para criar uma relação de confiança entre seu repositório GitHub e uma identidade gerenciada atribuída pelo usuário no Microsoft Entra. Nenhum segredo está armazenado no GitHub.

Exemplo de autenticação OIDC

O exemplo inline a seguir mostra o padrão central de autenticação e implantação OIDC usado em todos os modelos de workflow:

permissions:
  id-token: write
  contents: read

steps:
  - name: 'Login via OIDC'
    uses: azure/login@v3
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  - name: 'Deploy to Azure Functions'
    uses: Azure/functions-action@v1
    with:
      app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
      package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}

Considerações de autenticação OIDC no GitHub Actions

  • O OIDC utiliza federação de identidades de carga de trabalho e suporta apenas identidades gerenciadas atribuídas pelo usuário.
  • Quando você ativa uma implantação baseada em GitHub Actions no portal Azure, a autenticação OIDC é usada por padrão.
  • Com o OIDC, o ID do cliente, o ID do tenant e o ID de assinatura da identidade gerenciada são armazenados como segredos do repositório GitHub.
  • Use o controle de acesso baseado em função do Azure (Azure RBAC) para limitar o acesso apenas aos recursos do Azure necessários para sua implantação.

Pré-requisitos

  • Uma conta Azure com uma assinatura ativa. Crie uma conta gratuitamente.

  • Uma conta GitHub. Caso ainda não tenha uma, inscreva-se gratuitamente.

  • Código-fonte do Project em um repositório do GitHub.

  • Um entendimento básico dos fluxos de trabalho do GitHub Actions. Se você é novo no GitHub Actions, veja Entendendo GitHub Actions.

  • Um aplicativo funcional em funcionamento hospedado no Azure (apenas código ou baseado em contêiner).

  • (Apenas implantações de contêineres) Um registro de contêineres existente, como Registro de Contêiner do Azure.

  • CLI do Azure, ao desenvolver localmente. Você também pode usar o CLI do Azure em Azure Cloud Shell.

Crie uma identidade gerenciada para a implantação no GitHub Actions

OpenID Connect (OIDC) é o método de autenticação recomendado para implantações do GitHub Actions no Azure Functions. Com o OIDC, você configura uma identidade gerenciada atribuída pelo usuário no Azure e cria uma relação de confiança com seu repositório GitHub. O fluxo de trabalho pode então autenticar com o Azure sem armazenar credenciais como segredos.

  1. Use o comando az identity create para criar uma identidade gerenciada atribuída pelo usuário:

    az identity create --name myGitHubDeployIdentity --resource-group <RESOURCE_GROUP> \
    --query "{clientId: clientId, tenantId: tenantId}" -o table
    

    Substitua <RESOURCE_GROUP> pelo nome do grupo de recursos.

  2. A partir da saída, note os clientId valores de e tenantId . Também obtenha seu ID de assinatura:

    az account show --query "{subId: id}" -o table
    

    Você precisa desses três valores depois, quando adicionar credenciais ao GitHub.

  3. Use o comando create de atribuição de papel do az para atribuir a Website Contributor função à identidade gerenciada, com escopo para o seu app de função:

    IDENTITY_PRINCIPAL=$(az identity show --name myGitHubDeployIdentity --resource-group <RESOURCE_GROUP> --query 'principalId' -o tsv)
    FUNCTION_APP_ID=$(az functionapp show --name <APP_NAME> --resource-group <RESOURCE_GROUP> --query 'id' -o tsv)
    az role assignment create --assignee $IDENTITY_PRINCIPAL --role "Website Contributor" --scope $FUNCTION_APP_ID
    

    Substitua <APP_NAME> e <RESOURCE_GROUP> pelos nomes do seu app e do grupo de recursos, respectivamente.

  4. Use o comando create de credenciais federadas da identidade az para criar uma credencial federada que confie nos tokens do seu repositório do GitHub:

    az identity federated-credential create \
        --identity-name myGitHubDeployIdentity \
        --resource-group <RESOURCE_GROUP> \
        --name github-deploy-credential \
        --issuer https://token.actions.githubusercontent.com \
        --subject repo:<GITHUB_ORG>/<REPO_NAME>:ref:refs/heads/<BRANCH_NAME> \
        --audiences api://AzureADTokenExchange
    

    Substitua <RESOURCE_GROUP>, <GITHUB_ORG>, <REPO_NAME>e <BRANCH_NAME> com seus valores. O sujeito deve corresponder ao ramo que aciona seu fluxo de trabalho.

  5. (Opcional) Se você está implantando um container do Registro de Contêiner do Azure, também atribua a acrpull função à identidade gerenciada:

    IDENTITY_PRINCIPAL=$(az identity show --name myGitHubDeployIdentity --resource-group <RESOURCE_GROUP> --query 'principalId' -o tsv)
    az role assignment create --assignee $IDENTITY_PRINCIPAL --role acrpull \
        --scope /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.ContainerRegistry/registries/<REGISTRY_NAME>
    

    Substitua <SUBSCRIPTION_ID>, <RESOURCE_GROUP> e <REGISTRY_NAME> por seus valores.

Adicionar credenciais ao GitHub

Use os valores que você copiou ao criar a identidade gerenciada.

  1. Em GitHub, vá para o repositório.

  2. Vá para Configurações>Segredos e variáveis>Ações.

  3. Na aba Segredos , selecione Novo segredo do repositório.

  4. Crie cada um dos seguintes segredos:

    Name Valor
    AZURE_CLIENT_ID A clientId da identidade gerenciada
    AZURE_TENANT_ID A tenantId da identidade gerenciada
    AZURE_SUBSCRIPTION_ID O ID de assinatura que contém seu aplicativo de função

Para implantações de contêineres a partir de um registro privado, você também precisa de segredos específicos do registro. Para mais informações, veja Ação de Login no Docker.

Criar um fluxo de trabalho com base em um modelo

A melhor maneira de criar manualmente uma configuração de fluxo de trabalho é começar a partir do modelo com suporte oficial.

  1. Escolha Windows ou Linux para garantir que você obtenha o modelo para o sistema operacional correto.

    As implantações no Windows usam runs-on: windows-latest. Implantações em contêineres exigem Linux.

  2. Use o modelo de workflow OIDC específico para linguagem do repositório de ações do Azure Functions. Copie o conteúdo completo do arquivo para um novo arquivo nomeado .github/workflows/deploy-function-app.yml no seu repositório:

    name: Build and deploy .NET project to Azure Function App using OIDC
    
    on:
      push:
        branches: [ main ]
      workflow_dispatch:
    
    env:
      AZURE_FUNCTIONAPP_NAME: 'APP_NAME'         # Set this to your function app name on Azure 
      AZURE_FUNCTIONAPP_PROJECT_PATH: '.'        # Set this to the path to your function app project, defaults to the repository root. The deploy action will package the contents of this path.
      DOTNET_VERSION: '10.0.x'                   # Set this to the .NET version of your project
      BUILD_ARTIFACT_NAME: 'released-package'    # Set this according to your team's naming convention
      
    jobs:
      build:
        runs-on: windows-latest # Assumes your target function app is Windows-based
        permissions:
          id-token: write  # Required for OIDC
          contents: read   # Required for actions/checkout
        defaults:
          run:
            shell: bash
            working-directory: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
        steps:
          - name: 'Checkout repository'
            uses: actions/checkout@v6
    
          - name: 'Set up .NET version: ${{ env.DOTNET_VERSION }}'
            uses: actions/setup-dotnet@v5
            with:
              dotnet-version: ${{ env.DOTNET_VERSION }}
    
          # Perform additional steps such as running tests, if needed
    
          - name: 'Build and prepare .NET project for deployment'
            run: dotnet publish --configuration Release --output ./output
    
          - name: Upload artifact for the deployment job
            uses: actions/upload-artifact@v7
            with:
              name: ${{ env.BUILD_ARTIFACT_NAME }}
              path: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/output
              include-hidden-files: true  # Required for .NET projects
      
      deploy:
        runs-on: windows-latest # Assumes your target function app is Windows-based
        needs: build
        permissions:
          id-token: write  # Required for OIDC
        steps:
          - name: 'Download artifact from build job'
            uses: actions/download-artifact@v8
            with:
              name: ${{ env.BUILD_ARTIFACT_NAME }}
              path: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'
         
          - name: 'Log in to Azure with AZ CLI'
            uses: azure/login@v3
            with:
              client-id: ${{ vars.AZURE_CLIENT_ID }}
              tenant-id: ${{ vars.AZURE_TENANT_ID }}
              subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
            
          - name: 'Run the Azure Functions action'
            uses: Azure/functions-action@v1
            id: deploy-to-function-app
            with:
              app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
              package: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}/downloaded-artifact'
    
  3. No modelo, atualize as env: variáveis do seu projeto. Todo template requer AZURE_FUNCTIONAPP_NAME. As outras variáveis dependem do seu idioma:

    Variable Obrigatório Description
    AZURE_FUNCTIONAPP_NAME Sim Seu nome do aplicativo de função no Azure
    DOTNET_VERSION Sim A versão .NET do seu projeto (por exemplo, 10.0.x)
    AZURE_FUNCTIONAPP_PROJECT_PATH Não Caminho para a pasta do seu projeto. Padrão: . (raiz do repositório)
  4. Os templates OIDC já incluem a azure/login etapa com autenticação OIDC. Verifique se os secrets.AZURE_CLIENT_ID, secrets.AZURE_TENANT_ID, e secrets.AZURE_SUBSCRIPTION_IDreferências correspondem aos segredos do repositório que você criou.

  5. Adicione esse novo arquivo YAML no caminho /.github/workflows/ em seu repositório.

Criar a configuração do fluxo de trabalho no portal

Quando você usa o portal para ativar o GitHub Actions, o Functions cuida de toda a configuração automaticamente. Você não precisa criar manualmente uma identidade gerenciada, configurar credenciais ou escrever um arquivo de fluxo de trabalho. Funções realiza as seguintes tarefas para você:

Na sua assinatura do Azure:

  • Cria uma identidade gerenciada atribuída pelo usuário e atribui a ela a função de Contribuidor do Site no seu aplicativo de função.
  • Adiciona uma credencial federada à identidade gerenciada para autenticação OIDC do GitHub.

No seu repositório do GitHub:

  • Adiciona os valores do ID do cliente, ID de assinatura e ID de tenant como segredos do GitHub Actions.
  • Cria um arquivo de fluxo de trabalho baseado na sua pilha de aplicações e o faz commit em .github/workflows.

Durante a criação do aplicativo de funções

Você pode começar rapidamente com GitHub Actions por meio da guia Implantação ao criar uma função no portal Azure. Para adicionar um fluxo de trabalho GitHub Actions ao criar um novo aplicativo de funções:

  1. No portal Azure, selecione Implantação no fluxo Criar Aplicativo de Função.

  2. Habilite a Implantação Contínua se quiser que cada atualização de código dispare um push de código para o Portal do Azure.

  3. Nas configurações do GitHub, selecione Autorizar para conectar sua conta no GitHub. Faça login com a conta do GitHub que tem acesso de escrita ao seu repositório.

  4. Insira sua organização, repositório e branch do GitHub.

  5. Opcionalmente, selecione Arquivo de Pré-visualização para ver como o arquivo de fluxo de trabalho fica antes de ser gerado e adicionado ao seu repositório.

  6. Conclua a configuração do aplicativo de funções. Seu repositório GitHub agora inclui um novo arquivo de fluxo de trabalho em /.github/workflows/.

Adicionar a um aplicativo de funções existente

Para adicionar um fluxo de trabalho GitHub Actions a um aplicativo de funções existente:

  1. Vá ao seu aplicativo de funções no portal do Azure e selecione Centro de Implantação(Deployment >Deployment Center).

  2. Selecione Implantação Contínua (CI/CD). Em Fonte, selecione GitHub. Se você não vir a construção de mensagens padrão com GitHub Actions, selecione o provedor de alteração, escolha GitHub Actions e selecione OK.

  3. Se você ainda não autorizou o acesso ao GitHub, selecione Autorizar. Forneça suas credenciais de GitHub e selecione Sign in. Para autorizar uma conta de GitHub diferente, selecione Alterar Conta e faça login com outra conta.

  4. Selecione seu GitHub Organization, Repository e Branch. Para implantar usando o GitHub Actions, você deve ter acesso de escrita a esse repositório.

  5. Para a opção Fluxo de Trabalho, selecione Adicionar um fluxo de trabalho. Essa opção cria um novo arquivo de fluxo de trabalho em /.github/workflows/. Para usar um fluxo de trabalho existente, selecione Usar fluxo de trabalho disponível e escolha seu arquivo de workflow.

  6. Nas configurações de autenticação, escolha Identidade atribuída ao usuário para usar o OpenID Connect (OIDC), o que é recomendado porque não exige que você armazene segredos no GitHub. Selecione sua assinatura e o nome de identidade sugerido (Novo ). Uma nova identidade gerenciada atribuída pelo usuário é criada e recebe acesso ao papel de Contribuidor do Site . Se você usar uma identidade existente, primeiro deve conceder a ela acesso ao papel de Contribuidor do Site .

    Importante

    Quando você seleciona Autenticação Básica, seu perfil de publicação, que contém segredos compartilhados, é armazenado no GitHub Secrets. Você também deve ativar a autenticação básica SCM, o que torna seu app menos seguro.

  7. Selecione Preview file para ver o arquivo de fluxo de trabalho que é adicionado ao repositório GitHub no .github/workflows/.

  8. Selecione Salvar para adicionar o arquivo de fluxo de trabalho ao repositório. Selecione a aba Logs para ver o status das implantações atuais e anteriores.

Criar o arquivo de configuração de fluxo de trabalho

Você pode criar o arquivo de configuração do fluxo de trabalho do GitHub Actions a partir dos modelos do Azure Functions diretamente do seu repositório do GitHub.

  1. Em GitHub, vá para o repositório.

  2. Selecione Ações e Novo fluxo de trabalho.

  3. Pesquise por funções.

    Captura de tela da pesquisa de modelos de funções do GitHub Actions.

  4. Nos fluxos de trabalho do aplicativo de funções exibidas criados por Microsoft Azure, localize aquele que corresponda ao idioma do código e selecione Configure.

  5. No arquivo YAML recém-criado, atualize o parâmetro env.AZURE_FUNCTIONAPP_NAME com o nome do recurso do aplicativo de funções no Azure. Você também pode precisar atualizar o parâmetro que define a versão da linguagem usada pelo seu app, como DOTNET_VERSION para C# ou PYTHON_VERSION para apps Python.

  6. Os templates padrão podem usar autenticação de publicar perfil em vez do OIDC recomendado. Para migrar para o OIDC e alinhar com os comportamentos do portal, faça as seguintes alterações:

    • Remova os publish-profileparâmetros , scm-do-build-during-deployment, e enable-oryx-build parâmetros de Azure/functions-action.

    • Remova a environment configuração do trabalho (se presente), pois o sujeito da credencial federada deve corresponder ao gatilho do ramo.

    • Adicione um azure/login passo antes do Azure/functions-action passo:

      - name: 'Login via OIDC'
        uses: azure/login@v3
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      
      - name: 'Run Azure Functions Action'
        uses: Azure/functions-action@v1
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
      
    • Adicione as seguintes permissões ao trabalho:

      permissions:
        id-token: write
        contents: read
      
  7. Verifique se o novo arquivo de fluxo de trabalho está salvo com um nome apropriado em /.github/workflows/ e selecione Commit alterações.

Ação do Azure Functions

A ação Azure Functions (Azure/functions-action) define como seu código é publicado em um aplicativo de funções existente em Azure ou em um slot específico em seu aplicativo.

Parâmetros

A tabela a seguir descreve os parâmetros de entrada suportados por Azure/functions-action:

Parâmetro Description
app-name (Obrigatório) O nome do seu aplicativo de funções no Azure.
package (Obrigatório) O caminho para o seu projeto publicar. Padrão: . (todos os arquivos no repositório).
Construção remota Defina para true habilitar uma ação de build do Kudu ao implantar em um app Flex Consumption. A build do Oryx é sempre realizada; Também não defina scm-fazer-build-during-deployment ou enable-oryx-build. Padrão: false.
SCM-do-build-during-deployment Permita que o site Kudu realize operações pré-implantação, como compilações remotas. Defina para true que o Kudu construa seu projeto durante a implantação. Padrão: false. Para obter mais informações, consulte SCM_DO_BUILD_DURING_DEPLOYMENT.
enable-oryx-build Permita que o Kudu resolva dependências de projetos usando o Oryx. Defina tanto isso quanto o scm-do-build-during-deployment para true usar o Oryx em vez do fluxo de trabalho. Padrão: false. Somente Linux.
slot-name O slot de implantação para ser implantado. Padrão: slot de produção.
publish-profile (Opcional) O nome do segredo do GitHub para seu perfil de publicação. Não é necessário ao usar a autenticação OIDC recomendada.
Sku Defina para flexconsumption ao autenticar com publish-profile em um plano Flex Consumption. Não é necessário com autenticação OIDC ou outros planos de hospedagem.
respeito-pom-xml (somente Java) Defina para true derivar o artefato de implantação a partir de pom.xml. Quando true, defina o pacote para .. Padrão: false.
respeitar-funcionar Defina para true honrar seu arquivo .funcignore e exclua caminhos listados. Padrão: false.

A tabela a seguir mostra quais parâmetros são suportados para cada plano de hospedagem:

Parâmetro Consumo Flexível Elástico Premium Dedicado Consumo
app-name Obrigatório Obrigatório Obrigatório Obrigatório
package Obrigatório Obrigatório Obrigatório Obrigatório
Construção remota Optional
SCM-do-build-during-deployment Optional Optional Optional
enable-oryx-build Opcional (Linux) Opcional (Linux) Opcional (Linux)
slot-name Sem suporte Optional Optional Optional
publish-profile Não recomendado Não recomendado Não recomendado Não recomendado
Sku Apenas publicar perfil
respeito-pom-xml Opcional (Java) Opcional (Java) Opcional (Java) Opcional (Java)
respeitar-funcionar Optional Optional Optional Optional

Métodos de implantação

Quando você usa o GitHub Actions, o método de implantação depende do seu plano de hospedagem:

Plano de hospedagem Método de implantação
Consumo flexível One deploy
Elástico Premium Implantação de zip
Dedicado (Serviço de Aplicativo) Implantação de zip
Consumo Windows: implantação Zip
Linux: URL do pacote externo*

* A capacidade de executar seus aplicativos no Linux em um plano de Consumo está programada para descontinuação. Para obter mais informações, consulte Hospedagem no Plano de Consumo do Azure Functions.

Para obter mais informações, consulte Deployment technologies in Azure Functions.

Próximas etapas