Wdrażanie do Azure Functions przy użyciu GitHub Actions

Możesz użyć przepływu pracy GitHub Actions, aby automatycznie kompilować i wdrażać kod funkcji do platformy Azure przy użyciu Azure/functions-action.

Aby wdrożyć za pomocą GitHub Actions, wykonaj trzy kluczowe kroki:

Stwórz zarządzaną tożsamość przypisaną przez użytkownika w Azure z federacyjnym poświadczeniem, które ufa twojemu repozytorium GitHub, i przypisz jej rolę Website Contributor w aplikacji funkcjonalnej.
Dodaj identyfikator klienta, identyfikator tenanta oraz identyfikator subskrypcji jako sekrety repozytorium w GitHub.
Dodaj do swojego repozytorium plik YAML przepływu pracy, który używa azure/login z OpenID Connect (OIDC) do uwierzytelniania, a następnie wywołuje Azure/functions-action w celu wdrożenia.

Gdy korzystasz z portalu Azure do włączenia GitHub Actions, Functions automatycznie wykonuje te zadania, zarówno w subskrypcji Azure, jak i w repozytorium GitHub.

Stwórz konfigurację workflow dla Azure Functions

Utrzymujesz plik YAML (.yml), który definiuje konfigurację workflow w ścieżce /.github/workflows/ w twoim repozytorium. Ta definicja zawiera akcje i parametry tworzące przepływ pracy, który jest specyficzny dla języka programowania funkcji.

Wybierz metodę tworzenia pliku workflow, korzystając ze selektora na górze artykułu:

Method	Najlepsze dla	Wsparcie OIDC
Szablon workflow	Pełna kontrola: skopiuj szablon gotowy do OIDC i dostosuj go	Wymaga konfiguracji
Portal Azure	Najprostsza konfiguracja: portal może utworzyć dla Ciebie tożsamość, dane uwierzytelniające i plik workflow	Skonfigurowane dla Ciebie
GitHub Marketplace	GitHub-first: zacznij od wbudowanych szablonów marketplace w GitHub	Wymaga modyfikacji konfiguracji i szablonu

Omówienie uwierzytelniania

GitHub Actions musi uwierzytelnić się z Azure, aby wdrożyć Twój kod. W tym artykule używa się OpenID Connect (OIDC), który jest zalecaną metodą uwierzytelniania. OIDC używa federowanych poświadczeń do tworzenia relacji zaufania między repozytorium GitHub a zarządzaną tożsamością przypisaną przez użytkownika w Microsoft Entra. Na GitHub nie są przechowywane żadne sekrety.

Przykład uwierzytelniania OIDC

Poniższy przykład w linii pokazuje podstawowy wzorzec uwierzytelniania i wdrożenia OIDC stosowany we wszystkich szablonach przepływu pracy:

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 }}

Rozważania dotyczące uwierzytelniania OIDC w GitHub Actions

OIDC korzysta z federacji tożsamości obciążeń i obsługuje wyłącznie zarządzane tożsamości przypisane przez użytkownika.
Gdy włączysz wdrożenie oparte na GitHub Actions w portalu Azure, domyślnie używa się uwierzytelniania OIDC.
W OIDC identyfikator klienta zarządzanej tożsamości, identyfikator tenanta oraz identyfikator subskrypcji są przechowywane jako sekrety repozytorium GitHub.
Użyj kontroli dostępu opartej na rolach Azure (Azure RBAC), aby ograniczyć dostęp tylko do zasobów Azure potrzebnych do wdrożenia.

Wymagania wstępne

Konto Azure z aktywną subskrypcją. Utwórz bezpłatne konto.
Konto GitHub. Jeśli nie masz takiego konta, zarejestruj się bezpłatnie.
Kod źródłowy Project w repozytorium GitHub.
Podstawowa wiedza o workflowach GitHub Actions. Jeśli jesteś nowy w GitHub Actions, zobacz Understanding GitHub Actions.
Działająca aplikacja funkcji hostowana na platformie Azure (oparta wyłącznie na kodzie lub na kontenerach).
(Tylko wdrożenia kontenerowe) Istniejący rejestr kontenerowy, taki jak Azure Container Registry.

Azure CLI podczas lokalnego opracowywania. Możesz również użyć Azure CLI w Azure Cloud Shell.

Stwórz zarządzaną tożsamość dla wdrożenia GitHub Actions

OpenID Connect (OIDC) to zalecana metoda uwierzytelniania dla wdrożeń GitHub Actions na Azure Functions. W OIDC konfigurujesz zarządzaną tożsamość przypisaną przez użytkownika w Azure i tworzysz relację zaufania z repozytorium GitHub. Workflow może wtedy uwierzytelniać się za pomocą Azure bez przechowywania danych uwierzytelniających jako sekretów.

Użyj polecenia az identity create, aby utworzyć zarządzaną tożsamość przypisaną użytkownikowi.
```
az identity create --name myGitHubDeployIdentity --resource-group <RESOURCE_GROUP> \
--query "{clientId: clientId, tenantId: tenantId}" -o table
```
Zastąp <RESOURCE_GROUP> nazwą grupy zasobów.
W wynikach zanotuj wartości clientId i tenantId. Zdobądź też swój identyfikator subskrypcji:
```
az account show --query "{subId: id}" -o table
```
Te trzy wartości potrzebne są później, gdy dodasz dane uwierzytelniające do GitHub.

Użyj polecenia az role assignment create , aby przypisać Website Contributor rolę do zarządzanej tożsamości, ograniczonej do Twojej aplikacji funkcyjnej:

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

Zastąp <APP_NAME> i <RESOURCE_GROUP> nazwą swojej aplikacji i grupy zasobów, odpowiednio.

Użyj polecenia az identity federated-credential create, aby utworzyć federated credential, który ufa tokenom z twojego repozytorium 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

Zastąp <RESOURCE_GROUP>, <GITHUB_ORG>, <REPO_NAME> i <BRANCH_NAME> własnymi wartościami. Temat musi być zgodny z gałęzią, która uruchamia Twój przepływ pracy.

(Opcjonalnie) Jeśli wdrażasz kontener z Azure Container Registry, przypisz acrpull też rolę do tożsamości zarządzanej:

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>

Zastąp <SUBSCRIPTION_ID>, <RESOURCE_GROUP> oraz <REGISTRY_NAME> własnymi wartościami.

Dodaj dane uwierzytelniające do GitHub

Użyj wartości, które skopiowałeś podczas tworzenia tożsamości zarządzanej.

W GitHub przejdź do repozytorium.
Przejdź do Ustawień>Sekrety i zmienne>Akcje.
Na zakładce Sekrety wybierz Nowy sekret repozytorium.

Stwórz każdy z następujących sekretów:

Name	Wartość
`AZURE_CLIENT_ID`	`clientId` tożsamości zarządzanej
`AZURE_TENANT_ID`	`tenantId` tożsamości zarządzanej
`AZURE_SUBSCRIPTION_ID`	Identyfikator subskrypcji, który zawiera Twoją aplikację Function

Do wdrożeń kontenerów z prywatnego rejestru potrzebne są również sekrety specyficzne dla rejestru. Więcej informacji można znaleźć w sekcji Docker Login Action.

Tworzenie przepływu pracy na podstawie szablonu

Najlepszym sposobem ręcznego utworzenia konfiguracji przepływu pracy jest rozpoczęcie od oficjalnie obsługiwanego szablonu.

Wybierz Windows lub Linux aby upewnić się, że został wyświetlony szablon poprawnego systemu operacyjnego.
- Windows
- Linux
Wdrożenia dla systemu Windows używają runs-on: windows-latest. Wdrożenia kontenerowe wymagają Linuxa.

Wdrożenia w systemie Linux używają polecenia runs-on: ubuntu-latest. Używaj Linuksa do wdrożeń kontenerowych.

Użyj specyficznego dla języka szablonu workflow OIDC z repozytorium akcji Azure Functions. Skopiuj pełną zawartość pliku do nowego pliku o nazwie .github/workflows/deploy-function-app.yml w swoim repozytorium:

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'

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: ubuntu-latest # Assumes your target function app is Linux-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: ubuntu-latest # Assumes your target function app is Linux-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'

name: Build and deploy Java 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. Ensure that `functionAppName` in your pom.xml file matches. 
  POM_XML_DIRECTORY: '.'                      # set this to the directory which contains the pom.xml file. The deploy action will package the contents of this path.
  JAVA_VERSION: '21'                          # set this to the Java 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 to fetch an OIDC token to authenticate with the job
        contents: read # Required for actions/checkout
    defaults:
      run:
        shell: bash
        working-directory: ${{ env.POM_XML_DIRECTORY }}
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      - name: 'Set up Java version: ${{ env.JAVA_VERSION }}'
        uses: actions/setup-java@v4
        with:
          java-version: ${{ env.JAVA_VERSION }}
          distribution: 'microsoft'

      - name: 'Build project with Maven'
        run: mvn clean package -DfunctionAppName=${{ env.AZURE_FUNCTIONAPP_NAME }}

      # Perform additional steps such as running tests, if needed
      
      - name: 'Upload artifact for the deployment job'
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.POM_XML_DIRECTORY }}/target/azure-functions/${{ env.AZURE_FUNCTIONAPP_NAME }}

  deploy:
    runs-on: windows-latest # Assumes your target function app is Windows-based
    needs: build
    permissions:
      id-token: write  # Required to fetch an OIDC token to authenticate with the job
    steps:
      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v8
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: '${{ env.POM_XML_DIRECTORY }}/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.POM_XML_DIRECTORY }}/downloaded-artifact'
          respect-pom-xml: false # Set to `true` if the build artifact path is ${{ env.POM_XML_DIRECTORY }}

name: Build and deploy Java 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. Ensure that `functionAppName` in your pom.xml file matches. 
  POM_XML_DIRECTORY: '.'                      # set this to the directory which contains the pom.xml file. The deploy action will package the contents of this path.
  JAVA_VERSION: '21'                          # set this to the Java version of your project
  BUILD_ARTIFACT_NAME: 'released-package'     # Set this according to your team's naming convention

jobs:
  build:
    runs-on: ubuntu-latest # Assumes your target function app is Linux-based
    permissions:
        id-token: write  # Required to fetch an OIDC token to authenticate with the job
        contents: read # Required for actions/checkout
    defaults:
      run:
        shell: bash
        working-directory: ${{ env.POM_XML_DIRECTORY }}
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      - name: 'Set up Java version: ${{ env.JAVA_VERSION }}'
        uses: actions/setup-java@v4
        with:
          java-version: ${{ env.JAVA_VERSION }}
          distribution: 'microsoft'

      - name: 'Build project with Maven'
        run: mvn clean package -DfunctionAppName=${{ env.AZURE_FUNCTIONAPP_NAME }}

      # Perform additional steps such as running tests, if needed
      
      - name: 'Upload artifact for the deployment job'
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.POM_XML_DIRECTORY }}/target/azure-functions/${{ env.AZURE_FUNCTIONAPP_NAME }}

  deploy:
    runs-on: ubuntu-latest # Assumes your target function app is Linux-based
    needs: build
    permissions:
      id-token: write  # Required to fetch an OIDC token to authenticate with the job
    steps:
      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v8
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: '${{ env.POM_XML_DIRECTORY }}/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.POM_XML_DIRECTORY }}/downloaded-artifact'
          respect-pom-xml: false # Set to `true` if the build artifact path is ${{ env.POM_XML_DIRECTORY }}

name: Build and deploy Node.js 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.
  NODE_VERSION: '22'                        # Set this to the Node 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 Node version: ${{ env.NODE_VERSION }}'
        uses: actions/setup-node@v6
        with:
          node-version: ${{ env.NODE_VERSION }}

      - name: 'Install project dependencies'
        run: npm install # Use `npm ci` if you have a package-lock.json file and want to ensure a clean install
      
      - name: 'Build project'
        run: npm run build --if-present
      
      - name: 'Run tests'
        run: npm run test --if-present
      
      - name: 'Prune development dependencies'
        run: npm prune --production
      
      - name: 'Upload artifact for the deployment job'
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
  
  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'

name: Build and deploy Node.js 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.
  NODE_VERSION: '22'                        # Set this to the Node version of your project
  BUILD_ARTIFACT_NAME: 'released-package'   # Set this according to your team's naming convention
  
jobs:
  build:
    runs-on: ubuntu-latest # Assumes your target function app is Linux-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 Node version: ${{ env.NODE_VERSION }}'
        uses: actions/setup-node@v6
        with:
          node-version: ${{ env.NODE_VERSION }}

      - name: 'Install project dependencies'
        run: npm install # Use `npm ci` if you have a package-lock.json file and want to ensure a clean install
      
      - name: 'Build project'
        run: npm run build --if-present
      
      - name: 'Run tests'
        run: npm run test --if-present
      
      - name: 'Prune development dependencies'
        run: npm prune --production
      
      - name: 'Upload artifact for the deployment job'
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
  
  deploy:
    runs-on: ubuntu-latest # Assumes your target function app is Linux-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'

name: Build and deploy Python 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.
  PYTHON_VERSION: '3.13.x'                  # Set this to the Python version of your project
  BUILD_ARTIFACT_NAME: 'released-package'   # Set this according to your team's naming convention
  
jobs:
  build:
    runs-on: ubuntu-latest # Python function apps are Linux-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 Python version: ${{ env.PYTHON_VERSION }}'
        uses: actions/setup-python@v6
        with:
          python-version: ${{ env.PYTHON_VERSION }}

      - name: 'Install project dependencies'
        run: pip install -r requirements.txt --target ".python_packages/lib/site-packages"  # Ensure requirements.txt contains all dependencies
      
      # Perform additional steps such as running tests, if needed

      - name: 'Upload artifact for the deployment job'
        uses: actions/upload-artifact@v7
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}
  
  deploy:
    runs-on: ubuntu-latest # Python function apps are Linux-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'

name: Deploy PowerShell 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.
  
jobs:
  # PowerShell projects do not require a build step
  deploy:
    runs-on: windows-latest # For PowerShell projects, the OS of the runner does not affect deployment. You may use either ubuntu-latest or windows-latest.
    permissions:
      id-token: write  # Required for OIDC
      contents: read   # Required for actions/checkout
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v6

      # Perform additional steps such as running tests, if needed
     
      - 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 }}

# Action Requires
# 1. Setup the AZURE_CREDENTIALS secrets in your GitHub Repository
name: Linux_Container_Workflow

on:
  push:
    branches:
    - master

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    environment: dev
    steps:
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@v3

    - name: 'Login via Azure CLI'
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: 'Docker Login'
      uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - name: 'Compose Customized Docker Image'
      shell: bash
      run: |
        # If your function app project is not located in your repository's root
        # Please change the path to your directory for docker build
        docker build . -t REGISTRY/NAMESPACE/IMAGE:TAG
        docker push REGISTRY/NAMESPACE/IMAGE:TAG

    - name: 'Run Azure Functions Container Action'
      uses: Azure/functions-container-action@v1
      id: fa
      with:
        app-name: PLEASE_REPLACE_THIS_WITH_YOUR_FUNCTION_APP_NAME
        image: REGISTRY/NAMESPACE/IMAGE:TAG

    #- name: 'use the published functionapp url in upcoming steps'
    #  run: |
    #    echo "${{ steps.fa.outputs.app-url }}"

    - name: Azure logout
      run: |
        az logout

Ważne

Do wdrażania nowych aplikacji funkcyjnych opartych na kontenerach korzystaj z natywnego modelu hostingu Azure Container Apps. Zobacz Wdrażanie do usługi Azure Container Apps za pomocą GitHub Actions. Pokazane tutaj Azure/functions-container-action wdraża obrazy kontenerów do istniejących zasobów aplikacji funkcji na platformie Azure.

Zanim użyjesz tego pliku YAML, wykonaj następujące kroki:

Zaktualizuj wartości REGISTRY, NAMESPACE, IMAGE i TAG na podstawie rejestru kontenerów.
Zaktualizuj dane uwierzytelniające repozytorium kontenerów w akcji docker/login-action.

W szablonie zaktualizuj env: zmienne dla swojego projektu. Każdy szablon wymaga AZURE_FUNCTIONAPP_NAME. Pozostałe zmienne zależą od twojego języka:

Zmienna	Wymagane	Description
`AZURE_FUNCTIONAPP_NAME`	Yes	Nazwa Twojej aplikacji funkcji w Azure
`DOTNET_VERSION`	Yes	Wersja .NET Twojego projektu (na przykład, `10.0.x`)
`AZURE_FUNCTIONAPP_PROJECT_PATH`	No	Ścieżka do folderu projektu. Domyślne: `.` (root repozytorium)

Zmienna	Wymagane	Description
`AZURE_FUNCTIONAPP_NAME`	Yes	Nazwa Twojej aplikacji funkcji w Azure. Musi odpowiadać `functionAppName` w pliku pom.xml.
`JAVA_VERSION`	Yes	Wersja Java twojego projektu (na przykład, `21`)
`POM_XML_DIRECTORY`	No	Ścieżka do katalogu zawierającego pom.xml. Domyślne: `.` (root repozytorium)

Zmienna	Wymagane	Description
`AZURE_FUNCTIONAPP_NAME`	Yes	Nazwa Twojej aplikacji funkcji w Azure
`NODE_VERSION`	Yes	Wersja Node.js Twojego projektu (na przykład, `22`)
`AZURE_FUNCTIONAPP_PROJECT_PATH`	No	Ścieżka do folderu projektu. Domyślne: `.` (root repozytorium)

Zmienna	Wymagane	Description
`AZURE_FUNCTIONAPP_NAME`	Yes	Nazwa Twojej aplikacji funkcji w Azure
`PYTHON_VERSION`	Yes	Wersja Python twojego projektu (na przykład, `3.13.x`)
`AZURE_FUNCTIONAPP_PROJECT_PATH`	No	Ścieżka do folderu projektu. Domyślne: `.` (root repozytorium)

Zmienna	Wymagane	Description
`AZURE_FUNCTIONAPP_NAME`	Yes	Nazwa Twojej aplikacji funkcji w Azure
`AZURE_FUNCTIONAPP_PROJECT_PATH`	No	Ścieżka do folderu projektu. Domyślne: `.` (root repozytorium)

Zmienna	Wymagane	Description
`AZURE_FUNCTIONAPP_NAME`	Yes	Nazwa Twojej aplikacji funkcji w Azure
`REGISTRY`	Yes	Twój serwer logowania rejestru kontenerów (na przykład, `contoso.azurecr.io`)
`NAMESPACE`	Yes	Przestrzeń nazw/repozytorium w Twoim rejestrze
`IMAGE`	Yes	Nazwa obrazu kontenera
`TAG`	Yes	Tag obrazu (na przykład ) `${{ github.sha }}`

Szablony OIDC już zawierają krok azure/login z uwierzytelnianiem OIDC. Sprawdź, czy odwołania secrets.AZURE_CLIENT_ID, secrets.AZURE_TENANT_ID i secrets.AZURE_SUBSCRIPTION_ID są zgodne z sekretami repozytorium, które zostały utworzone.
Dodaj ten nowy plik YAML do ścieżki /.github/workflows/ w swoim repozytorium.

Tworzenie konfiguracji przepływu pracy w portalu

Gdy używasz portalu do włączenia GitHub Actions, Functions automatycznie obsługuje całą konfigurację. Nie musisz ręcznie tworzyć zarządzanej tożsamości, konfigurować danych uwierzytelniających ani pisać pliku workflow. Functions wykonuje za Ciebie następujące zadania:

W Twojej subskrypcji Azure:

Tworzy zarządzaną tożsamość przypisaną przez użytkownika i przypisuje jej rolę Współtwórcy Strony w aplikacji funkcyjnej.
Dodaje federowane dane uwierzytelniające do zarządzanej tożsamości dla uwierzytelniania GitHub OIDC.

W twoim repozytorium GitHub:

Dodaje wartości identyfikatora klienta, identyfikatora subskrypcji oraz identyfikatora tenanta jako sekrety GitHub Actions.
Tworzy plik przepływu pracy na podstawie stosu technologicznego Twojej aplikacji i zatwierdza go w .github/workflows.

Podczas tworzenia aplikacji funkcyjnej

Możesz szybko rozpocząć pracę z GitHub Actions za pomocą karty Wdrażanie podczas tworzenia funkcji w portalu Azure. Aby dodać przepływ pracy GitHub Actions do nowej aplikacji funkcjonalnej podczas jej tworzenia:

W portalu Azure wybierz Deployment w przepływie Utwórz aplikację funkcji.
Włącz Continuous Deployment jeśli chcesz, aby każda aktualizacja kodu wyzwoliła wypychanie kodu do portalu Azure.
W ustawieniach GitHub wybierz Autoryzuj, aby połączyć konto GitHub. Zaloguj się przy użyciu konta GitHub, które ma uprawnienia do zapisu w Twoim repozytorium.
Wprowadź swoją organizację, repozytorium i gałąź GitHub.
Opcjonalnie wybierz plik podglądu , aby zobaczyć, jak wygląda plik workflow przed jego wygenerowaniem i dodaniem do repozytorium.
Zakończ konfigurowanie aplikacji funkcji. Repozytorium GitHub zawiera teraz nowy plik przepływu pracy w /.github/workflows/.

W przypadku istniejącej funkcjonalności aplikacji

Aby dodać przepływ pracy GitHub Actions do istniejącej aplikacji funkcjonalnej:

Przejdź do swojej aplikacji funkcji w portalu Azure i wybierz Wdrażanie>Centrum wdrażania.
Wybierz Continuous Deployment (CI/CD). W polu Źródło wybierz pozycję GitHub. Jeśli nie widzisz domyślnego komunikatu Building with GitHub Actions, wybierz Zmień dostawcę, wybierz GitHub Actions i OK.
Jeśli jeszcze nie autoryzowałeś dostępu do GitHub, wybierz Autoryzuj. Podaj poświadczenia GitHub i wybierz pozycję Sign in. Aby autoryzować inne konto GitHub, wybierz pozycję Zmień konto i zaloguj się przy użyciu innego konta.
Wybierz GitHub Organization, Repository i Branch. Aby wdrażać przy użyciu GitHub Actions, musisz mieć uprawnienia do zapisu w tym repozytorium.
W opcji Workflow wybierz Dodaj workflow. Ta opcja tworzy nowy plik workflow w /.github/workflows/. Aby użyć istniejącego workflow, wybierz Użyj dostępnego workflow i wybierz swój plik workflow.
W ustawieniach uwierzytelniania wybierz tożsamość przypisaną przez użytkownika, aby korzystać z OpenID Connect (OIDC), co jest zalecane, ponieważ nie wymaga przechowywania sekretów w GitHub. Wybierz swoją subskrypcję oraz ( Nową) sugerowaną nazwę tożsamości. Tworzona jest nowa zarządzana przez użytkownika tożsamość, która otrzymuje dostęp do roli Współtwórcy Strony Internetowej . Jeśli używasz istniejącej tożsamości, najpierw musisz przyznać jej dostęp do roli Współtwórcy Strony Internetowej .

Ważne

Gdy wybierzesz Uwierzytelnianie podstawowe, twój profil publikowania, który zawiera współdzielone wpisy tajne, jest przechowywany w usłudze GitHub Secrets. Musisz także włączyć podstawową autentyzację SCM, co zmniejsza bezpieczeństwo aplikacji.
Wybierz pozycję Podgląd pliku, aby zobaczyć plik przepływu pracy, który zostanie dodany do Twojego repozytorium GitHub w .github/workflows/.
Wybierz pozycję Zapisz , aby dodać plik przepływu pracy do repozytorium. Wybierz zakładkę Logi, aby zobaczyć status bieżących i poprzednich wdrożeń.

Tworzenie pliku konfiguracji przepływu pracy

Plik konfiguracji przepływu pracy GitHub Actions można utworzyć na podstawie szablonów Azure Functions bezpośrednio z repozytorium GitHub.

W GitHub przejdź do repozytorium.
Wybierz pozycję Akcje i Nowy przepływ pracy.
Wyszukaj funkcje.
W wyświetlonych przepływach pracy aplikacji funkcji utworzonych przez Microsoft Azure znajdź przepływ pracy zgodny z językiem kodu i wybierz Konfiguruj.
W nowo utworzonym pliku YAML zaktualizuj parametr env.AZURE_FUNCTIONAPP_NAME nazwą zasobu aplikacji funkcyjnej w Azure. Możesz też potrzebować zaktualizować parametr określający wersję języka używaną przez twoją aplikację, na przykład DOTNET_VERSION dla C# lub PYTHON_VERSION aplikacji Python.
Domyślne szablony mogą używać uwierzytelniania za pomocą profilu publikowania zamiast zalecanego mechanizmu OIDC. Aby przejść na OIDC i dostosować się do zachowań portalu, wprowadź następujące zmiany:
- Usuń parametry publish-profile, scm-do-build-during-deployment i enable-oryx-build z elementu Azure/functions-action.
- Usuń environment to ustawienie z zadania (jeśli jest obecne), ponieważ temat federowanego uwierzytelniania musi odpowiadać wyzwalaczowi gałęzi.
- Dodaj krok azure/login przed krokiem Azure/functions-action:
```
- 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 }}
```
- Dodaj następujące uprawnienia do zadania:
```
permissions:
  id-token: write
  contents: read
```
Sprawdź, czy nowy plik przepływu pracy został zapisany pod odpowiednią nazwą w /.github/workflows/, a następnie wybierz Commit changes.

akcja Azure Functions

Akcja Azure Functions (Azure/functions-action) definiuje sposób publikowania kodu w istniejącej aplikacji funkcji w Azure lub do określonego miejsca w aplikacji.

Parametry

Poniższa tabela opisuje parametry wejściowe obsługiwane przez Azure/functions-action:

Parametr	Description
nazwa aplikacji	(Wymagane) Nazwa Twojej aplikacji funkcjonalnej w Azure.
package	(Wymagane) Ścieżka do projektu, który chcesz opublikować. Domyślne: `.` (wszystkie pliki w repozytorium).
Budowa zdalna	Ustaw wartość `true`, aby zażądać zdalnej kompilacji podczas wdrażania do aplikacji w planie Flex Consumption. Zdalna wersja zawsze używa Oryxa. Nie ustawiaj też scm-do-build-during-deployment ani enable-oryx-build. Wartość domyślna: `false`.
SCM-DO-Build-Doring-Deployment	Pozwól witrynie Kudu wykonywać operacje przed wdrożeniem, takie jak zdalne kompilacje. Ustaw na `true`, aby Kudu kompilował twój projekt podczas wdrożenia. Wartość domyślna: `false`. Aby uzyskać więcej informacji, zobacz `SCM_DO_BUILD_DURING_DEPLOYMENT`.
enable-oryx-build	Pozwól Kudu rozwiązywać zależności projektów za pomocą Oryxa. Ustaw zarówno tę opcję, jak i scm-do-build-during-deployment na `true`, aby używać Oryx zamiast przepływu pracy. Wartość domyślna: `false`. Tylko system Linux.
nazwa miejsca	Slot wdrożeniowy, do którego ma zostać wykonane wdrożenie. Domyślnie: slot produkcyjny.
profil publikowania	Nazwa tajemnicy GitHub zawierającej profil wydawniczy. Nie jest to potrzebne w przypadku korzystania z zalecanej metody uwierzytelniania OIDC.
SKU	Ustaw na `flexconsumption` podczas uwierzytelniania za pomocą publish-profile w planie Flex Consumption. Nie jest potrzebny przy uwierzytelnianiu OIDC ani innych planach hostingowych.
respect-pom-xml	(tylko dla języka Java) Ustaw na `true`, aby określić artefakt wdrożeniowy na podstawie pliku pom.xml. Gdy `true`, ustaw package na `.`. Wartość domyślna: `false`.
respect-funcignore	Ustaw tak, `true` aby szanować twój plik .funcignore i wykluczyć wymienione ścieżki. Wartość domyślna: `false`.

Poniższa tabela pokazuje, które parametry są obsługiwane dla każdego planu hostingowego:

Parametr	Zużycie elastyczne	Elastiska premia	Dedykowana	Zużycie
nazwa aplikacji	Wymagane	Wymagane	Wymagane	Wymagane
package	Wymagane	Wymagane	Wymagane	Wymagane
Budowa zdalna	Optional	—	—	—
SCM-DO-Build-Doring-Deployment	—	Optional	Optional	Optional
enable-oryx-build	—	Opcjonalne (Linux)	Opcjonalne (Linux)	Opcjonalne (Linux)
nazwa miejsca	Niewspierane	Optional	Optional	Optional
profil publikowania	Niezalecane	Niezalecane	Niezalecane	Niezalecane
SKU	Tylko publikowanie profilu	—	—	—
respect-pom-xml	Opcjonalne (Java)	Opcjonalne (Java)	Opcjonalne (Java)	Opcjonalne (Java)
respect-funcignore	Optional	Optional	Optional	Optional

Metody wdrażania

Gdy korzystasz z GitHub Actions, metoda wdrożenia zależy od planu hostingu:

Plan hostingu	Metoda wdrażania
Elastyczne zużycie	Wdrażanie pakietów
Elastiska premia	Wdrożenie ZIP
Dedykowane (App Service)	Wdrożenie ZIP
Zużycie	Windows: Wdrożenie ZIP Linux: zewnętrzny adres URL pakietu^*

Planowane jest wycofanie możliwości uruchamiania aplikacji na Linuxie w planie Konsumpcja. Aby uzyskać więcej informacji, zobacz Azure Functions Hosting planu zużycie.

Aby uzyskać więcej informacji, zobacz Technologie wdrażania w usłudze Azure Functions.

Następne kroki

Opinia

Czy ta strona była pomocna?

Last updated on 2026-09-16