Udostępnij za pośrednictwem

Automatyzowanie wdrażania zasobów dla aplikacji funkcji w usłudze Azure Functions

  • Artykuł

Aby zautomatyzować proces wdrażania aplikacji funkcji, możesz użyć pliku Bicep lub szablonu usługi Azure Resource Manager (ARM). Podczas wdrażania można użyć istniejących zasobów platformy Azure lub utworzyć nowe. Automatyzacja ułatwia wykonanie następujących scenariuszy:

  • Integrowanie wdrożeń zasobów z kodem źródłowym w usłudze Azure Pipelines i wdrożeniach opartych na funkcji GitHub Actions.
  • Przywracanie aplikacji funkcjonalnej i powiązanych zasobów z kopii zapasowej.
  • Wdrażanie topologii aplikacji wiele razy.

W tym artykule pokazano, jak zautomatyzować tworzenie zasobów i wdrażanie dla usługi Azure Functions. W zależności od wyzwalaczy i powiązań używanych przez funkcje może być konieczne wdrożenie innych zasobów, które wykraczają poza zakres tego artykułu.

Wymagany kod szablonu zależy od żądanych opcji hostingu dla aplikacji funkcji. Ten artykuł obsługuje następujące opcje hostingu:

Opcja hostingu Typ wdrożenia Przykładowy szablon
Plan użycia usługi Azure Functions Tylko kod Plan zużycia
Plan elastycznego zużycia w usłudze Azure Functions Tylko kod Elastyczny Plan Konsumpcji
Plan elastycznej wersji Premium usługi Azure Functions Kod | Kontener Plan Premium
Plan usługi Azure Functions Dedicated (App Service) Kod | Kontener Dedykowany plan
Azure Container Apps Tylko kontener Hostowanie usługi Azure Functions w usłudze Container Apps
Azure Arc Kod | Kontener App Service, Functions i Logic Apps na platformie Azure Arc (wersja zapoznawcza)

Podczas korzystania z tego artykułu należy pamiętać o następujących kwestiach:

  • Nie ma kanonicznego sposobu na zbudowanie struktury szablonu ARM.

  • Wdrożenie Bicep można modularyzować w wielu plikach Bicep.

  • W tym artykule założono, że masz podstawową wiedzę na temat tworzenia plików Bicep lub tworzenia szablonów usługi Azure Resource Manager.

  • Przykłady są wyświetlane jako poszczególne sekcje dla określonych zasobów. Aby zapoznać się z szerokim zestawem kompletnych przykładów plików Bicep i szablonów ARM, zobacz te przykłady wdrażania aplikacji funkcji.
  • Przykłady są wyświetlane jako poszczególne sekcje dla określonych zasobów.

Wymagane zasoby

Musisz utworzyć lub skonfigurować te zasoby dla wdrożenia hostowanego w usłudze Azure Functions:

Zasób Wymaganie Odniesienie do składni i właściwości
Konto magazynu Wymagane Microsoft.Storage/storageAccounts
Składnik usługi Application Insights Zalecane Microsoft.Insights/components*
Plan hostingu Wymagane Microsoft.Web/serverfarms
Aplikacja funkcyjna Wymagane Microsoft.Web/sites

Musisz utworzyć lub skonfigurować te zasoby dla wdrożenia hostowanego w usłudze Azure Functions:

Zasób Wymaganie Dokumentacja składni i właściwości
Konto magazynu Wymagane Microsoft.Storage/storageAccounts
Składnik usługi Application Insights Zalecane Microsoft.Insights/components*
Aplikacja funkcjonalna Wymagane Microsoft.Web/sites

Wdrożenie hostowane w usłudze Azure Container Apps zwykle składa się z następujących zasobów:

Zasób Wymaganie Odniesienie do składni i właściwości
Konto magazynu Wymagane Microsoft.Storage/storageAccounts
Składnik usługi Application Insights Zalecane Microsoft.Insights/components*
Środowisko zarządzane Wymagane Microsoft.App/managedEnvironments
Aplikacja funkcji Wymagane Microsoft.Web/sites

Wdrożenie hostowane w usłudze Azure Arc zwykle składa się z następujących zasobów:

Zasób Wymaganie Dokumentacja składni i właściwości
Konto magazynu Wymagane Microsoft.Storage/storageAccounts
Składnik usługi Application Insights Zalecane Microsoft.Insights/components1
Kubernetesowe środowisko App Service Wymagane Microsoft.ExtendedLocation/customLocations
Aplikacja funkcjonalna Wymagany Microsoft.Web/sites

*Jeśli nie masz jeszcze obszaru roboczego Log Analytics, który może być używany przez usługę Application Insights, musisz również utworzyć ten zasób.

Podczas wdrażania wielu zasobów w jednym pliku Bicep lub szablonie ARM ważna jest kolejność tworzenia zasobów. To wymaganie jest wynikiem zależności między zasobami. W przypadku takich zależności należy użyć dependsOn elementu do zdefiniowania zależności w zasobie zależnym. Aby uzyskać więcej informacji, zobacz Definiowanie kolejności wdrażania zasobów w szablonach ARM lub Zależności zasobów w Bicep.

Wymagania wstępne

  • Przykłady są przeznaczone do wykonania w kontekście istniejącej grupy zasobów.
  • Zarówno usługa Application Insights, jak i dzienniki magazynu wymagają istniejącego obszaru roboczego usługi Azure Log Analytics. Obszary robocze mogą być współużytkowane między usługami, a jako reguła należy utworzyć obszar roboczy w każdym regionie geograficznym, aby zwiększyć wydajność. Aby zapoznać się z przykładem tworzenia obszaru roboczego usługi Log Analytics, zobacz Tworzenie obszaru roboczego usługi Log Analytics. Identyfikator zasobu w pełni kwalifikowanego obszaru roboczego można znaleźć na stronie obszaru roboczego w witrynie Azure portal w obszarze Ustawienia>Właściwości>Identyfikator zasobu.
  • W tym artykule założono, że utworzono już środowisko zarządzane w usłudze Azure Container Apps. Potrzebujesz zarówno nazwy, jak i identyfikatora środowiska zarządzanego, aby utworzyć aplikację funkcji hostowaną w usłudze Container Apps.
  • W tym artykule założono, że utworzyłeś już niestandardową lokalizację z obsługą App Service na klastrze Kubernetes z obsługą Azure Arc. Aby utworzyć aplikację funkcji hostowaną w niestandardowej lokalizacji usługi Azure Arc, potrzebujesz zarówno identyfikatora lokalizacji niestandardowej, jak i identyfikatora środowiska Kubernetes.

Utwórz konto magazynowe

Wszystkie aplikacje funkcji wymagają konta usługi Azure Storage. Potrzebujesz konta ogólnego zastosowania, które obsługuje obiekty blob, tabele, kolejki i pliki. Aby uzyskać więcej informacji, zobacz Wymagania dotyczące konta magazynu usługi Azure Functions.

Ważne

Konto magazynowe służy do przechowywania ważnych danych aplikacji, czasami łącznie z samym kodem aplikacji. Należy ograniczyć dostęp z innych aplikacji i użytkowników do konta przechowywania.

Ta przykładowa sekcja tworzy konto magazynu typu Standard o ogólnym przeznaczeniu wersji 2.

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
  properties: {
    supportsHttpsTrafficOnly: true
    defaultToOAuthAuthentication: true
    allowBlobPublicAccess: false
  }
}

Aby uzyskać więcej informacji na temat kontekstu, zobacz pełny plik main.bicep w repozytorium szablonów.

Aby uzyskać więcej informacji na temat kontekstu, zobacz pełny plik storage-account.bicep w przykładowym repozytorium.

Musisz ustawić parametry połączenia tego konta magazynu jako AzureWebJobsStorage ustawienie aplikacji, którego wymaga usługa Functions. Szablony w tym artykule tworzą tę wartość ciągu połączenia na podstawie utworzonego konta składowania, co jest najlepszą praktyką. Aby uzyskać więcej informacji, zobacz Konfiguracja aplikacji.

Kontener wdrażania

Wdrożenia w aplikacji uruchomionej w planie Flex Consumption wymagają kontenera w usłudze Azure Blob Storage jako źródła wdrożenia. Możesz użyć domyślnego konta magazynu lub określić oddzielne konto magazynu. Aby uzyskać więcej informacji, zobacz Konfigurowanie ustawień wdrażania.

To konto wdrożenia musi być już skonfigurowane podczas tworzenia aplikacji, w tym określonego kontenera używanego do wdrożeń. Aby dowiedzieć się więcej na temat konfigurowania wdrożeń, zobacz Źródła wdrożenia.

W tym przykładzie pokazano, jak utworzyć kontener na koncie magazynu:

resource blobServices 'blobServices' = if (!empty(containers)) {
  name: 'default'
  properties: {
    deleteRetentionPolicy: deleteRetentionPolicy
  }
  resource container 'containers' = [for container in containers: {
    name: container.name
    properties: {
      publicAccess: contains(container, 'publicAccess') ? container.publicAccess : 'None'
    }
  }]
}

Aby zapoznać się z fragmentem kodu w kontekście, zobacz ten przykład wdrożenia.

Inne ustawienia wdrożenia są konfigurowane przy użyciu samej aplikacji.

Włącz dzienniki magazynu

Ponieważ konto magazynu jest używane dla ważnych danych aplikacji funkcji, należy monitorować konto pod kątem modyfikacji tej zawartości. Aby monitorować konto magazynu, należy skonfigurować dzienniki zasobów usługi Azure Monitor dla usługi Azure Storage. W tej przykładowej sekcji obszar roboczy usługi Log Analytics o nazwie myLogAnalytics jest używany jako miejsce docelowe tych dzienników.

resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2021-09-01' existing = {
  name:'default'
  parent:storageAccountName
}

resource storageDataPlaneLogs 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: '${storageAccountName}-logs'
  scope: blobService
  properties: {
    workspaceId: myLogAnalytics.id
    logs: [
      {
        category: 'StorageWrite'
        enabled: true
      }
    ]
    metrics: [
      {
        category: 'Transaction'
        enabled: true
      }
    ]
  }
}

Tego samego obszaru roboczego można użyć dla zasobu usługi Application Insights zdefiniowanego później. Aby uzyskać więcej informacji, w tym sposób pracy z tymi dziennikami, zobacz Monitorowanie usługi Azure Storage.

Tworzenie usługi Application Insights

Do monitorowania wykonań aplikacji funkcji należy używać usługi Application Insights. Usługa Application Insights wymaga teraz obszaru roboczego usługi Azure Log Analytics, który można udostępnić. W tych przykładach założono, że używasz istniejącego obszaru roboczego i masz w pełni kwalifikowany identyfikator zasobu dla obszaru roboczego. Aby uzyskać więcej informacji, zobacz Obszar roboczy usługi Azure Log Analytics.

W tej sekcji przykładowej zasób usługi Application Insights jest definiowany z typem Microsoft.Insights/components i typem web:

resource applicationInsight 'Microsoft.Insights/components@2020-02-02' = {
  name: applicationInsightsName
  location: appInsightsLocation
  tags: tags
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: '<FULLY_QUALIFIED_RESOURCE_ID>'
  }
}

Aby uzyskać więcej informacji na temat kontekstu, zobacz pełny plik main.bicep w repozytorium szablonów.

Połączenie musi zostać dostarczone do aplikacji funkcji przy użyciu APPLICATIONINSIGHTS_CONNECTION_STRING ustawienia aplikacji. Aby uzyskać więcej informacji, zobacz Konfiguracja aplikacji.

Przykłady w tym artykule uzyskują wartość ciągu połączenia dla utworzonego wystąpienia. Starsze wersje mogą zamiast tego używać APPINSIGHTS_INSTRUMENTATIONKEY do ustawiania klucza instrumentacji, który nie jest już zalecany.

Tworzenie planu hostingu

Aplikacje hostowane w ramach planu Flex Consumption usługi Azure Functions, planu Premium lub planu dedykowanego (App Service) muszą mieć jawnie zdefiniowany plan hostingu.

Flex Consumption to plan hostingu na platformie Linux, który korzysta z bezserwerowego modelu rozliczeniowego płatności za użycie. Plan obejmuje funkcje wsparcia dla sieci prywatnych, wyboru rozmiaru pamięci dla instancji oraz ulepszonego wsparcia dla tożsamości zarządzanej.

Plan Flex Consumption to specjalny typ serverfarm zasobu. Można to określić, używając FC1 dla wartości właściwości Name we właściwości sku z wartością tierFlexConsumption.

W tej przykładowej sekcji przedstawiono tworzenie planu Flex Consumption:

resource flexFuncPlan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: planName
  location: location
  tags: tags
  kind: 'functionapp'
  sku: {
    tier: 'FlexConsumption'
    name: 'FC1'
  }
  properties: {
    reserved: true
  }
}

Aby uzyskać więcej informacji na temat kontekstu, zobacz kompletny plik function.bicep w repozytorium przykładowym planu Flex Consumption.

Ponieważ plan Flex Consumption obecnie obsługuje tylko system Linux, należy również ustawić reserved właściwość na true.

Plan Premium oferuje takie samo skalowanie jak plan Zużycie, ale obejmuje dedykowane zasoby i dodatkowe możliwości. Aby dowiedzieć się więcej, zobacz Plan premium usługi Azure Functions.

Plan Premium to specjalny typ serverfarm zasobu. Można to określić, używając wartości EP1, EP2 lub EP3 dla wartości właściwości Name we właściwości sku. Sposób definiowania planu hostingu usługi Functions zależy od tego, czy aplikacja funkcji działa w systemie Windows, czy w systemie Linux. Ta przykładowa sekcja tworzy EP1 plan:

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  sku: {
    name: 'EP1'
    tier: 'ElasticPremium'
    family: 'EP'
  }
  kind: 'elastic'
  properties: {
    maximumElasticWorkerCount: 20
  }
}

Aby uzyskać więcej informacji na temat kontekstu, zobacz pełny plik main.bicep w repozytorium szablonów.

Aby uzyskać więcej informacji na temat sku obiektu, zobacz SkuDefinition lub przejrzyj przykładowe szablony.

W ramach Planu Dedykowanego (App Service) aplikacja funkcji działa na dedykowanych maszynach wirtualnych w SKU Podstawowe, Standardowe i Premium w planach App Service, podobnie jak w przypadku aplikacji internetowych. Aby uzyskać więcej informacji, zobacz Dedykowany plan.

Aby zapoznać się z przykładowym plikiem Bicep lub szablonem Azure Resource Manager, zobacz Aplikacja funkcji na planie Azure App Service.

W usłudze Functions plan dedykowany to zwykły plan usługi App Service, który jest definiowany serverfarm przez zasób. Musisz podać co najmniej name wartość. Aby uzyskać listę obsługiwanych nazw planów, zobacz --sku ustawienie w az appservice plan create sekcji dla bieżącej listy obsługiwanych wartości dla planu dedykowanego.

Sposób definiowania planu hostingu zależy od tego, czy aplikacja funkcji działa w systemie Windows, czy w systemie Linux:

resource hostingPlanName 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  sku: {
    tier: 'Standard'
    name: 'S1'
    size: 'S1'
    family: 'S'
    capacity: 1
  }
}

Aby uzyskać więcej informacji na temat kontekstu, zobacz pełny plik main.bicep w repozytorium szablonów.

Tworzenie planu hostingu

Nie musisz jawnie definiować zasobu planu hostingu Zużycie. W przypadku pominięcia tej definicji zasobu, plan jest automatycznie tworzony lub wybierany dla każdego regionu w momencie tworzenia zasobu aplikacji funkcji.

Możesz jawnie zdefiniować plan Zużycie jako specjalny typ serverfarm zasobu, który określa się przy użyciu wartości Dynamic właściwości computeMode i sku . W tej przykładowej sekcji pokazano, jak jawnie zdefiniować plan zużycia. Sposób definiowania planu hostingu zależy od tego, czy aplikacja funkcji działa w systemie Windows, czy w systemie Linux.

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  sku: {
    name: 'Y1'
    tier: 'Dynamic'
    size: 'Y1'
    family: 'Y'
    capacity: 0
  }
  properties: {
    computeMode: 'Dynamic'
  }
}

Aby uzyskać więcej informacji na temat kontekstu, zobacz pełny plik main.bicep w repozytorium szablonów.

Środowisko Kubernetes

Usługę Azure Functions można wdrożyć na platformie Kubernetes z włączoną usługą Azure Arc jako projekt kodu lub konteneryzowaną aplikację funkcji.

Aby utworzyć aplikację i zaplanować zasoby, musisz już mieć utworzone środowisko Kubernetes usługi App Service dla klastra Kubernetes z obsługą usługi Azure Arc. W przykładach w tym artykule założono, że masz identyfikator zasobu lokalizacji niestandardowej (customLocationId) i środowiska Kubernetes usługi App Service (kubeEnvironmentId), w którym wdrażasz, które zostały ustawione w tym przykładzie:

param kubeEnvironmentId string
param customLocationId string

Zarówno witryny, jak i plany muszą odwoływać się do niestandardowej lokalizacji za pomocą pola extendedLocation. Jak pokazano w tym obciętym przykładzie, extendedLocation znajduje się poza elementem properties, jako element równorzędny z kind i location.

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  ...
  {
    extendedLocation: {
      name: customLocationId
    }
  }
}

Zasób planu powinien używać wartości Kubernetes (K1) dla SKU, pole kind powinno mieć wartość linux,kubernetes, i właściwość reserved powinna mieć wartość true, ponieważ jest to wdrożenie systemu Linux. Należy również ustawić extendedLocation na identyfikator lokalizacji niestandardowej oraz kubeEnvironmentProfile.id na identyfikator środowiska Kubernetes, odpowiednio, co może wyglądać następująco w przykładowej sekcji:

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  kind: 'linux,kubernetes'
  sku: {
    name: 'K1'
    tier: 'Kubernetes'
  }
  extendedLocation: {
    name: customLocationId
  }
  properties: {
    kubeEnvironmentProfile: {
      id: kubeEnvironmentId
    }
    reserved: true
  }
}

Utwórz aplikację funkcji

Zasób aplikacji funkcji jest zdefiniowany przez zasób typu Microsoft.Web/sites i kind, który zawiera co najmniej functionapp.

Sposób definiowania zasobu aplikacji funkcji zależy od tego, czy hostujesz w systemie Linux, czy w systemie Windows:

Aby uzyskać listę ustawień aplikacji wymaganych podczas uruchamiania w systemie Windows, zobacz Konfiguracja aplikacji. Aby zapoznać się z przykładowym plikiem Bicep/szablonem usługi Azure Resource Manager, zobacz aplikacja funkcji hostowana na Windows w szablonie planu zużycia.

Aby uzyskać listę ustawień aplikacji wymaganych podczas uruchamiania w systemie Windows, zobacz Konfiguracja aplikacji.

Flex Consumption zastępuje wiele standardowych ustawień aplikacji i właściwości konfiguracji witryny używanych we wdrożeniach szablonów Bicep i ARM. Aby uzyskać więcej informacji, zobacz Konfiguracja aplikacji.

resource flexFuncApp 'Microsoft.Web/sites@2024-04-01' = {
  name: appName
  location: location
  tags: tags
  kind: 'functionapp,linux'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    serverFarmId: flexFuncPlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'AzureWebJobsStorage__accountName'
          value: storage.name
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsights.properties.ConnectionString
        }
      ]
    }
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storage.properties.primaryEndpoints.blob}${deploymentStorageContainerName}'
          authentication: {
            type: 'SystemAssignedIdentity'
          }
        }
      }
      scaleAndConcurrency: {
        maximumInstanceCount: maximumInstanceCount
        instanceMemoryMB: instanceMemoryMB
      }
      runtime: { 
        name: functionAppRuntime
        version: functionAppRuntimeVersion
      }
    }
  }
}

Aby uzyskać więcej informacji na temat kontekstu, zobacz pełny plik function.bicep w repozytorium z przykładem planu Flex Consumption.

Uwaga

Jeśli zdecydujesz się zdefiniować plan Zużycia, musisz ustawić serverFarmId właściwość w aplikacji, aby wskazywała na identyfikator zasobu planu. Upewnij się, że funkcja aplikacji ma dependsOn ustawienie, które również odwołuje się do planu. Jeśli nie zdefiniowano jawnie planu, zostanie on utworzony dla Ciebie.

Ustaw właściwość serverFarmId w aplikacji, aby wskazywała na identyfikator zasobu planu. Upewnij się, że aplikacja funkcjonalna ma dependsOn ustawienie, które również odwołuje się do planu.

resource functionAppName_resource 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: hostingPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'WEBSITE_CONTENTSHARE'
          value: toLower(functionAppName)
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~14'
        }
      ]
    }
  }
}

Aby zapoznać się z kompletnym przykładem, zobacz ten plik main.bicep.

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: hostingPlan.id
    siteConfig: {
      alwaysOn: true
      appSettings: [
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~14'
        }
      ]
    }
  }
}

Aby zapoznać się z kompletnym przykładem, zobacz ten plik main.bicep.

Źródła wdrożenia

Możesz użyć linuxFxVersion ustawienia witryny, aby zażądać wdrożenia określonego kontenera systemu Linux w aplikacji podczas jego tworzenia. Aby uzyskać dostęp do obrazów w repozytorium prywatnym, wymagane są więcej ustawień. Aby uzyskać więcej informacji, zobacz Konfiguracja aplikacji.

Ważne

Podczas tworzenia własnych kontenerów musisz zachować obraz bazowy kontenera zaktualizowany do najnowszej obsługiwanej wersji. Obsługiwane obrazy podstawowe dla usługi Azure Functions są specyficzne dla języka i znajdują się w repozytoriach obrazów podstawowych usługi Azure Functions.

Zespół Functions zobowiązuje się do comiesięcznego publikowania aktualizacji dla tych obrazów podstawowych. Regularne aktualizacje obejmują najnowsze aktualizacje wersji pomocniczej i poprawki zabezpieczeń dla środowiska uruchomieniowego i języków usługi Functions. Należy regularnie aktualizować kontener z najnowszego obrazu podstawowego i ponownie wdrożyć zaktualizowaną wersję kontenera. Aby uzyskać więcej informacji, zobacz Obsługa kontenerów niestandardowych.

Plik Bicep lub szablon ARM może także opcjonalnie definiować wdrożenie dla kodu funkcji, które może obejmować następujące metody:

Plan Flex Consumption utrzymuje kod projektu w skompresowanym pliku pakietu zip w kontenerze magazynującym obiekty blob, znanym jako kontener wdrażania. Możesz skonfigurować zarówno konto magazynu, jak i kontener używany do wdrożenia. Aby uzyskać więcej informacji, zobacz Opcje wdrażania.

Aby opublikować pakiet kodu w kontenerze wdrażania, należy użyć jedno wdrożenie. Podczas wdrażania usługi ARM lub Bicep można to zrobić, definiując źródło pakietu korzystające z /onedeploy rozszerzenia. Jeśli zamiast tego zdecydujesz się bezpośrednio przekazać pakiet do kontenera, pakiet nie zostanie wdrożony automatycznie.

Kontener wdrażania

Określone konto magazynu i kontener używany do wdrożeń, metoda uwierzytelniania i poświadczenia są ustawiane w functionAppConfig.deployment.storage elemencie properties dla lokalizacji. Kontener i wszystkie ustawienia aplikacji muszą istnieć podczas tworzenia aplikacji. Przykład, jak utworzyć kontener magazynu, można znaleźć w temacie kontener wdrożeniowy.

W tym przykładzie użyto przypisanej przez system tożsamości zarządzanej w celu uzyskania dostępu do określonego kontenera magazynu obiektów blob, który został utworzony w innym kroku wdrożenia.

deployment: {
  storage: {
    type: 'blobContainer'
    value: '${storage.properties.primaryEndpoints.blob}${deploymentStorageContainerName}'
    authentication: {
      type: 'SystemAssignedIdentity'
    }
  }
}

W przypadku korzystania z tożsamości zarządzanych należy również włączyć aplikację funkcjonalną, aby uzyskać dostęp do konta magazynu za pomocą tożsamości, jak pokazano w tym przykładzie:

// Allow access from function app to storage account using a managed identity
resource storageRoleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
  name: guid(storage.id, storageRoleDefinitionId)
  scope: storage
  properties: {
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', storageRoleDefinitionId)
    principalId: flexFuncApp.identity.principalId
    principalType: 'ServicePrincipal'
  }
}

Aby zobaczyć pełny przykład referencyjny, zapoznaj się z tym plikiem Bicep.

Ten przykład wymaga znajomości wartości identyfikatora GUID dla przypisanej roli. Tę wartość identyfikatora można uzyskać dla dowolnej przyjaznej nazwy roli, używając polecenia az role definition list , jak w tym przykładzie:

az role definition list --output tsv --query "[?roleName=='Storage Blob Data Owner'].{name:name}"

W przypadku używania ciągu połączeniowego zamiast tożsamości zarządzanych, należy ustawić wartość authentication.type na StorageAccountConnectionString oraz ustawić authentication.storageAccountConnectionStringName na nazwę ustawienia aplikacji, które zawiera ciąg połączeniowy do konta magazynu wdrożenia.

Pakiet wdrożeniowy

Plan „Flex Consumption” używa jednego wdrożenia do implementacji twojego projektu kodu. Sam pakiet kodu jest taki sam, jak w przypadku wdrożenia zip w innych planach hostingu usługi Functions. Jednak sama nazwa pliku pakietu musi mieć wartość released-package.zip.

Aby dołączyć jeden pakiet wdrożeniowy do szablonu, użyj /onedeploy definicji zasobu dla zdalnego adresu URL zawierającego pakiet wdrożeniowy. Host usługi Functions musi mieć dostęp zarówno do tego źródła pakietu zdalnego, jak i kontenera wdrożenia.

W tym przykładzie dodano jedno źródło wdrożenia do istniejącej aplikacji:

@description('The name of the function app.')
param functionAppName string

@description('The location into which the resources should be deployed.')
param location string = resourceGroup().location

@description('The zip content URL for released-package.zip.')
param packageUri string

resource functionAppName_OneDeploy 'Microsoft.Web/sites/extensions@2022-09-01' = {
  name: '${functionAppName}/onedeploy'
  location: location
  properties: {
    packageUri: packageUri
    remoteBuild: false 
  }
}

Plik Bicep lub szablon usługi ARM może opcjonalnie definiować wdrożenie dla twojego kodu funkcji przy użyciu pakietu wdrożeniowego zip.

Aby pomyślnie wdrożyć aplikację przy użyciu usługi Azure Resource Manager, ważne jest, aby zrozumieć, jak zasoby są wdrażane na platformie Azure. W większości przykładów konfiguracje najwyższego poziomu są stosowane przy użyciu polecenia siteConfig. Ważne jest, aby ustawić te konfiguracje na najwyższym poziomie, ponieważ przekazują informacje do środowiska uruchomieniowego Functions i modułu wdrażania. Informacje najwyższego poziomu są wymagane przed zastosowaniem zasobu podrzędnego sourcecontrols/web . Chociaż można skonfigurować te ustawienia w zasobie na poziomie config/appSettings podrzędnym, niekiedy konieczne jest, aby aplikacja funkcji została wdrożona przedconfig/appSettings zastosowaniem.

Pakiet wdrożeniowy zip

Wdrożenie zip to zalecany sposób wdrażania kodu aplikacji funkcji. Domyślnie funkcje korzystające z wdrożenia zip są uruchamiane w samym pakiecie wdrożeniowym. Aby uzyskać więcej informacji, w tym wymagania dotyczące pakietu wdrożeniowego, zobacz Wdrażanie zip dla usługi Azure Functions. W przypadku korzystania z automatyzacji wdrażania zasobów można odwołać się do pakietu wdrożeniowego .zip w szablonie Bicep lub ARM.

Aby użyć wdrożenia zip w szablonie, skonfiguruj ustawienie WEBSITE_RUN_FROM_PACKAGE w aplikacji na 1 i dołącz /zipDeploy definicję zasobu.

W przypadku planu zużycia w systemie Linux należy ustawić identyfikator URI pakietu wdrożeniowego bezpośrednio w WEBSITE_RUN_FROM_PACKAGE ustawieniu, jak pokazano w tym przykładowym szablonie.

W tym przykładzie dodano źródło wdrożenia zip do istniejącej aplikacji:

@description('The name of the function app.')
param functionAppName string

@description('The location into which the resources should be deployed.')
param location string = resourceGroup().location

@description('The zip content url.')
param packageUri string

resource functionAppName_ZipDeploy 'Microsoft.Web/sites/extensions@2021-02-01' = {
  name: '${functionAppName}/ZipDeploy'
  location: location
  properties: {
    packageUri: packageUri
  }
}

Podczas dołączania zasobów wdrożenia zip do szablonu należy pamiętać o następujących kwestiach:

  • Musi packageUri to być lokalizacja, do której można uzyskać dostęp za pomocą usługi Functions. Rozważ użycie usługi Azure Blob Storage z sygnaturą dostępu współdzielonego (SAS). Po wygaśnięciu SAS, funkcje nie będą już mogły uzyskać dostępu do udziału dla wdrożeń. Podczas ponownego generowania SAS, pamiętaj, aby zaktualizować WEBSITE_RUN_FROM_PACKAGE ustawienie nową wartością identyfikatora URI.

  • Podczas ustawiania WEBSITE_RUN_FROM_PACKAGE identyfikatora URI należy ręcznie zsynchronizować wyzwalacze.

  • Pamiętaj, aby zawsze ustawiać wszystkie wymagane ustawienia aplikacji w appSettings kolekcji podczas dodawania lub aktualizowania ustawień. Istniejące ustawienia, które nie są jawnie ustawione, są usuwane przez aktualizację. Aby uzyskać więcej informacji, zobacz Konfiguracja aplikacji.

  • Usługa Functions nie obsługuje narzędzia Web Deploy (msdeploy) dla wdrożeń pakietów. Zamiast tego należy użyć wdrożenia zip w potokach wdrażania i automatyzacji. Aby uzyskać więcej informacji, zobacz Wdrażanie zip dla usługi Azure Functions.

Kompilacje zdalne

W procesie wdrażania przyjęto założenie, że używany plik .zip lub wdrożenie zip zawiera aplikację gotową do uruchomienia. Oznacza to, że domyślnie nie są uruchamiane żadne dostosowania.

Istnieją scenariusze, które wymagają zdalnego ponownego kompilowania aplikacji. Przykładem może być konieczność dołączenia pakietów specyficznych dla systemu Linux w aplikacjach Python lub Node.js, które zostały utworzone na komputerze z systemem Windows. W takim przypadku można skonfigurować funkcje tak, aby wykonywały zdalną kompilację kodu po wdrożeniu zip.

Sposób żądania kompilacji zdalnej zależy od systemu operacyjnego, do którego wdrażasz:

Po wdrożeniu aplikacji w systemie Windows są uruchamiane polecenia specyficzne dla języka (na przykład dotnet restore dla aplikacji języka C# lub npm install dla aplikacji Node.js).

Aby włączyć te same procesy kompilacji, które uzyskujesz z ciągłą integracją, dodaj SCM_DO_BUILD_DURING_DEPLOYMENT=true do ustawień aplikacji w kodzie wdrożenia i usuń je WEBSITE_RUN_FROM_PACKAGE całkowicie.

Linuxowe kontenery

Jeśli wdrażasz konteneryzowaną aplikację funkcji do usługi Azure Functions w planie Premium lub Dedykowanym, musisz:

Jeśli brakuje niektórych ustawień, aprowizacja aplikacji może zakończyć się niepowodzeniem z powodu tego błędu HTTP/500:

Function app provisioning failed.

Aby uzyskać więcej informacji, zobacz Konfiguracja aplikacji.

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: hostingPlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~14'
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_URL'
          value: dockerRegistryUrl
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_USERNAME'
          value: dockerRegistryUsername
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_PASSWORD'
          value: dockerRegistryPassword
        }
        {
          name: 'WEBSITES_ENABLE_APP_SERVICE_STORAGE'
          value: 'false'
        }
      ]
      linuxFxVersion: 'DOCKER|myacr.azurecr.io/myimage:mytag'
    }
  }
  dependsOn: [
    storageAccount
  ]
}

Podczas wdrażania konteneryzowanych funkcji w usłudze Azure Container Apps szablon musi:

  • kind Ustaw pole na wartość functionapp,linux,container,azurecontainerapps.
  • Ustaw właściwość witryny managedEnvironmentId na kompletny identyfikator URI dla środowiska Container Apps.
  • Dodaj link do zasobu w kolekcji witryny dependsOn podczas tworzenia zasobu Microsoft.App/managedEnvironments jednocześnie z witryną.

Definicja konteneryzowanej aplikacji funkcji wdrożonej z prywatnego rejestru kontenerów w istniejącym środowisku usługi Container Apps może wyglądać następująco:

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  kind: 'functionapp,linux,container,azurecontainerapps'
  location: location
  properties: {
    serverFarmId: hostingPlanName
    siteConfig: {
      linuxFxVersion: 'DOCKER|myacr.azurecr.io/myimage:mytag'
      appSettings: [
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
      ]
    }
    managedEnvironmentId: managedEnvironmentId
  }
  dependsOn: [
    storageAccount
    hostingPlan
  ]
}

Podczas wdrażania funkcji w usłudze Azure Arc wartość ustawiona dla kind pola zasobu aplikacji funkcji zależy od typu wdrożenia:

Typ wdrożenia kind wartość pola
Wdrożenie wyłącznie kodu functionapp,linux,kubernetes
Wdrażanie kontenera functionapp,linux,kubernetes,container

Należy również ustawić customLocationId tak, jak w przypadku zasobu planu hostingu.

Definicja konteneryzowanej aplikacji funkcji korzystającej z obrazu szybkiego startu platformy .NET 6 może wyglądać następująco:

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  kind: 'kubernetes,functionapp,linux,container'
  location: location
  extendedLocation: {
    name: customLocationId
  }
  properties: {
    serverFarmId: hostingPlanName
    siteConfig: {
      linuxFxVersion: 'DOCKER|mcr.microsoft.com/azure-functions/4-dotnet-isolated6.0-appservice-quickstart'
      appSettings: [
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
      ]
      alwaysOn: true
    }
  }
  dependsOn: [
    storageAccount
    hostingPlan
  ]
}

Konfiguracja aplikacji

W planie Flex Consumption skonfigurujesz aplikację funkcji na platformie Azure z dwoma typami właściwości:

Konfigurowanie Microsoft.Web/sites własność
Konfiguracja aplikacji functionAppConfig
Ustawienia aplikacji siteConfig.appSettings kolekcja

Te konfiguracje aplikacji są obsługiwane w programie functionAppConfig:

Zachowanie Ustawienie w functionAppConfig
Zawsze gotowe instancje scaleAndConcurrency.alwaysReady
Źródło wdrożenia deployment
Rozmiar pamięci wystąpienia scaleAndConcurrency.instanceMemoryMB
Współbieżność wyzwalacza HTTP scaleAndConcurrency.triggers.http.perInstanceConcurrency
Środowisko uruchomieniowe języka runtime.name
Wersja języka runtime.version
Maksymalna liczba wystąpień scaleAndConcurrency.maximumInstanceCount

Plan Flex Consumption obsługuje również następujące ustawienia aplikacji:

Funkcje udostępnia następujące opcje konfigurowania aplikacji funkcji na platformie Azure:

Konfigurowanie Microsoft.Web/sites własność
Ustawienia witryny siteConfig
Ustawienia aplikacji siteConfig.appSettings kolekcja

Te ustawienia witryny są wymagane we siteConfig właściwości :

Te ustawienia witryny są wymagane tylko przy korzystaniu z tożsamości zarządzanych, aby uzyskać obraz z instancji usługi Azure Container Registry.

Te ustawienia aplikacji są wymagane (lub zalecane) dla określonego systemu operacyjnego i opcji hostingu:

Te ustawienia aplikacji są wymagane w przypadku wdrożeń kontenerów:

Te ustawienia są wymagane tylko podczas wdrażania z prywatnego rejestru kontenerów:

Należy pamiętać o tych kwestiach podczas pracy z ustawieniami witryny i aplikacji przy użyciu plików Bicep lub szablonów usługi ARM:

  • Ustawienie opcjonalne alwaysReady zawiera tablicę co najmniej jednego {name,instanceCount} obiektu z jedną dla każdej grupy skalowania poszczególnych funkcji. Są to grupy skalowania używane do podejmowania zawsze gotowych decyzji dotyczących skalowania. W tym przykładzie ustawiono zawsze gotowe liczby zarówno dla grupy, jak http i pojedynczej funkcji o nazwie helloworld, która jest typem wyzwalacza niezgrupowanego:
      alwaysReady: [
    {
      name: 'http'
      instanceCount: 2
    }
    {
      name: 'function:helloworld'
      instanceCount: 1
    }
  ]
  • Ważne zagadnienia dotyczące tego, kiedy należy ustawić WEBSITE_CONTENTSHARE w zautomatyzowanym wdrożeniu. Aby uzyskać szczegółowe wskazówki, zobacz odwołanie WEBSITE_CONTENTSHARE.

  • Ustawienia aplikacji należy zawsze definiować jako siteConfig/appSettings kolekcję tworzonego Microsoft.Web/sites zasobu, tak jak w przykładach w tym artykule. Ta definicja gwarantuje, że ustawienia, które aplikacja funkcji musi uruchomić, są dostępne podczas początkowego uruchamiania.

  • Podczas dodawania lub aktualizowania ustawień aplikacji przy użyciu szablonów upewnij się, że wszystkie istniejące ustawienia są uwzględniane w aktualizacji. Należy to zrobić, ponieważ podstawowe wywołania REST API aktualizacji zastępują cały zasób /config/appsettings. Jeśli usuniesz istniejące ustawienia, aplikacja funkcji nie zostanie uruchomiona. Aby programowo zaktualizować poszczególne ustawienia aplikacji, możesz zamiast tego użyć interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell lub witryny Azure Portal, aby wprowadzić te zmiany. Aby uzyskać więcej informacji, zobacz Praca z ustawieniami aplikacji.

  • Jeśli to możliwe, należy użyć połączeń opartych na tożsamości zarządzanej z innymi usługami platformy Azure, w tym z połączeniem AzureWebJobsStorage . Aby uzyskać więcej informacji, zobacz Konfigurowanie połączenia opartego na tożsamościach.

Wdrożenia slotów

Usługa Functions umożliwia wdrażanie różnych wersji kodu w unikalnych punktach końcowych w aplikacji Function. Ta opcja ułatwia opracowywanie, weryfikowanie i wdrażanie aktualizacji funkcji bez wpływu na funkcje działające w środowisku produkcyjnym. Miejsca wdrożenia to funkcja usługi aplikacji Azure. Liczba dostępnych miejsc zależy od planu hostingu. Aby uzyskać więcej informacji, zobacz Funkcje miejsc wdrożenia usługi Azure Functions.

Zasób miejsca jest definiowany w taki sam sposób jak zasób aplikacji funkcji (Microsoft.Web/sites), ale zamiast tego należy użyć identyfikatora Microsoft.Web/sites/slots zasobu. Aby zapoznać się z przykładowym wdrożeniem (zarówno w szablonach Bicep, jak i ARM), które tworzy zarówno slot produkcyjny, jak i slot przejściowy w planie Premium, zobacz Aplikacja funkcji platformy Azure z miejscem wdrożeniowym.

Aby dowiedzieć się, jak zamieniać miejsca przy użyciu szablonów, zobacz Automatyzacja za pomocą szablonów usługi Resource Manager.

Podczas pracy z wdrożeniami slotów należy pamiętać o następujących kwestiach:

  • Nie ustawiaj jawnie ustawienia WEBSITE_CONTENTSHARE w definicji miejsca wdrożenia. To ustawienie jest generowane dla Ciebie podczas tworzenia aplikacji w gnieździe wdrożeniowym.

  • W przypadku zamiany slotów, niektóre ustawienia aplikacji są uznawane za „lepkie”, ponieważ pozostają z slotem, a nie z zamienianym kodem. Takie ustawienie slotu można zdefiniować, uwzględniając "slotSetting":true w definicji konkretnego ustawienia aplikacji w szablonie. Aby uzyskać więcej informacji, zobacz Zarządzanie ustawieniami.

Zabezpieczone wdrożenia

Aplikację funkcji można utworzyć we wdrożeniu, w którym co najmniej jeden z zasobów został zabezpieczony przez integrację z sieciami wirtualnymi. Integracja sieci wirtualnej dla aplikacji funkcjonalnej jest definiowana przez zasób Microsoft.Web/sites/networkConfig. Ta integracja zależy zarówno od przywoływanej aplikacji funkcji, jak i zasobów sieci wirtualnej. Aplikacja funkcji może również zależeć od innych zasobów sieci prywatnych, takich jak prywatne punkty dostępu i trasy. Aby uzyskać więcej informacji, zobacz Opcje sieci usługi Azure Functions.

Te projekty przedstawiają przykłady oparte na Bicep, jak wdrażać aplikacje typu funkcja w sieci wirtualnej, w tym z ograniczeniami dostępu do sieci.

Podczas tworzenia wdrożenia korzystającego z zabezpieczonego konta storage, należy jawnie ustawić parametr WEBSITE_CONTENTSHARE oraz utworzyć zasób udziału plików o nazwie określonej w tym parametrze. Upewnij się, że stworzysz Microsoft.Storage/storageAccounts/fileServices/shares zasób z wykorzystaniem wartości WEBSITE_CONTENTSHARE, jak pokazano w tym przykładzie (szablon ARM|plik Bicep). Należy również ustawić właściwość vnetContentShareEnabled witryny na wartość true.

Uwaga

Jeśli te ustawienia nie są częścią wdrożenia, które korzysta z zabezpieczonego konta magazynowego, błąd ten pojawi się podczas walidacji wdrożenia: Could not access storage account using provided connection string.

Projekty te udostępniają przykłady zarówno szablonów Bicep, jak i ARM, dotyczące sposobu wdrażania aplikacji funkcjonalnych w sieci wirtualnej, w tym także z ograniczeniami dostępu sieciowego.

Scenariusz ograniczony opis
Utwórz aplikację funkcji z integracją z siecią wirtualną Aplikacja funkcji jest tworzona w sieci wirtualnej z pełnym dostępem do zasobów w tej sieci. Dostęp przychodzący i wychodzący do aplikacji funkcjonalnej nie jest ograniczony. Aby uzyskać więcej informacji, zobacz Integracja sieci wirtualnej.
Utwórz aplikację funkcji, która uzyskuje dostęp do zabezpieczonego konta magazynu Utworzona aplikacja funkcji korzysta z zabezpieczonego konta magazynu, do którego usługa Functions uzyskuje dostęp przy użyciu prywatnych punktów końcowych. Aby uzyskać więcej informacji, zobacz Ograniczanie konta magazynu do sieci wirtualnej.
Utwórz aplikację funkcji i konto magazynu, które obie używają prywatnych punktów końcowych Dostęp do utworzonej aplikacji funkcji jest możliwy tylko przy użyciu prywatnych punktów końcowych. Wykorzystuje ona prywatne punkty końcowe do uzyskiwania dostępu do zasobów przechowywania. Aby uzyskać więcej informacji, zobacz Prywatne punkty końcowe.

Ustawienia sieci z ograniczeniami

Może być również konieczne użycie tych ustawień, gdy aplikacja funkcji ma ograniczenia sieci:

Ustawienie Wartość opis
WEBSITE_CONTENTOVERVNET 1 Ustawienie aplikacji, które umożliwia skalowanie aplikacji funkcyjnej, gdy konto magazynu jest ograniczone do sieci wirtualnej. Aby uzyskać więcej informacji, zobacz Ograniczanie konta magazynu do sieci wirtualnej.
vnetrouteallenabled 1 Ustawienie witryny, które wymusza cały ruch z funkcji aplikacji na korzystanie z sieci wirtualnej. Aby uzyskać więcej informacji, zobacz Regionalna integracja sieci wirtualnej. To ustawienie witryny zastępuje ustawienie WEBSITE_VNET_ROUTE_ALLaplikacji .

Zagadnienia dotyczące ograniczeń sieci

Jeśli ograniczasz dostęp do konta magazynu za pośrednictwem prywatnych punktów końcowych, nie możesz uzyskać dostępu do konta magazynu za pośrednictwem portalu ani żadnego urządzenia spoza sieci wirtualnej. Możesz udzielić dostępu do zabezpieczonego adresu IP lub sieci wirtualnej na koncie magazynu, zarządzając domyślną regułą dostępu do sieci.

Klucze dostępu funkcji

Klucze dostępu funkcji na poziomie hosta są definiowane jako zasoby platformy Azure. Oznacza to, że można tworzyć klucze hosta i zarządzać nimi w szablonach ARM i plikach Bicep. Klucz hosta jest definiowany jako zasób typu Microsoft.Web/sites/host/functionKeys. W tym przykładzie tworzony jest klucz dostępu na poziomie hosta o nazwie my_custom_key podczas tworzenia aplikacji funkcji:

resource functionKey 'Microsoft.Web/sites/host/functionKeys@2022-09-01' = {
  name: '${parameters('name')}/default/my_custom_key'
  properties: {
    name: 'my_custom_key'
  }
  dependsOn: [
    resourceId('Microsoft.Web/Sites', parameters('name'))
  ]
}

W tym przykładzie parametr name jest nazwą nowej aplikacji funkcji. Musisz dołączyć dependsOn ustawienie, aby zagwarantować, że klucz zostanie utworzony przy użyciu nowej aplikacji funkcjonalnej. Na koniec obiekt klucza hosta może również zawierać właściwość properties, która może służyć do ustawienia konkretnego klucza.

Jeśli właściwość nie zostanie ustawiona value , usługa Functions automatycznie wygeneruje nowy klucz podczas tworzenia zasobu, co jest zalecane. Aby dowiedzieć się więcej na temat kluczy dostępu, w tym najlepszych rozwiązań w zakresie zabezpieczeń dotyczących pracy z kluczami dostępu, zobacz Praca z kluczami dostępu w usłudze Azure Functions.

Tworzenie szablonu

Eksperci z szablonami Bicep lub ARM mogą ręcznie kodować wdrożenia przy użyciu prostego edytora tekstów. Dla reszty z nas istnieje kilka sposobów, aby proces programowania był łatwiejszy:

  • Visual Studio Code: dostępne są rozszerzenia ułatwiające pracę zarówno z plikami Bicep, jak i z szablonami ARM. Możesz użyć tych narzędzi, aby upewnić się, że kod jest poprawny i zapewnia podstawową walidację.

  • Portal Azure: podczas tworzenia aplikacji funkcji i powiązanych zasobów w portalu końcowy ekran Przejrzyj + utwórz zawiera link Pobierz szablon do automatyzacji.

    Pobierz link szablonu z procesu tworzenia usługi Azure Functions w witrynie Azure Portal.

    To łącze przedstawia szablon ARM wygenerowany na podstawie opcji wybranych w portalu. Ten szablon może wydawać się nieco złożony podczas tworzenia aplikacji funkcji z wieloma nowymi zasobami. Jednak może to zapewnić dobre odniesienie do tego, jak może wyglądać Twój szablon ARM.

Weryfikowanie szablonu

Podczas ręcznego tworzenia pliku szablonu wdrożenia ważne jest zweryfikowanie szablonu przed wdrożeniem. Wszystkie metody wdrażania weryfikują składnię szablonu i zgłaszają validation failed komunikat o błędzie, jak pokazano w poniższym przykładzie sformatowanym w formacie JSON:

{"error":{"code":"InvalidTemplate","message":"Deployment template validation failed: 'The resource 'Microsoft.Web/sites/func-xyz' is not defined in the template. Please see https://aka.ms/arm-template for usage details.'.","additionalInfo":[{"type":"TemplateViolation","info":{"lineNumber":0,"linePosition":0,"path":""}}]}}

Następujące metody mogą służyć do weryfikowania szablonu przed wdrożeniem:

Następujące zadaniedeploymentMode: 'Validation' wdrażania grupy zasobów platformy Azure w wersji 2 powoduje, że usługa Azure Pipelines zweryfikuje szablon.

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    deploymentScope: 'Resource Group'
    subscriptionId: # Required subscription ID
    action: 'Create Or Update Resource Group'
    resourceGroupName: # Required resource group name
    location: # Required when action == Create Or Update Resource Group
    templateLocation: 'Linked artifact'
    csmFile: # Required when  TemplateLocation == Linked Artifact
    csmParametersFile: # Optional
    deploymentMode: 'Validation'

Możesz również utworzyć testową grupę zasobów, aby znaleźć błędy przedwdrożeniowe i błędy wdrażania.

Wdrażanie szablonu

Aby wdrożyć plik i szablon Bicep, możesz użyć dowolnego z następujących sposobów:

Przycisk Wdrażania do Azure

Uwaga

Ta metoda nie obsługuje obecnie wdrażania plików Bicep.

Zastąp <url-encoded-path-to-azuredeploy-json> zakodowaną wersją ścieżki pliku w formacie URL znajdującą się w GitHubie.

Oto przykład, który używa języka Markdown:

[![Deploy to Azure](https://azuredeploy.net/deploybutton.png)](https://portal.azure.com/#create/Microsoft.Template/uri/<url-encoded-path-to-azuredeploy-json>)

Oto przykład, który używa kodu HTML:

<a href="https://portal.azure.com/#create/Microsoft.Template/uri/<url-encoded-path-to-azuredeploy-json>" target="_blank"><img src="https://azuredeploy.net/deploybutton.png"></a>

Wdrażanie przy użyciu programu PowerShell

Następujące polecenia programu PowerShell tworzą grupę zasobów i wdrażają plik Bicep lub szablon ARM, który tworzy aplikację funkcji z wymaganymi zasobami. Aby uruchomić lokalnie, musisz mieć zainstalowany program Azure PowerShell . Aby zalogować się do platformy Azure, musisz najpierw uruchomić polecenie Connect-AzAccount.

# Register Resource Providers if they're not already registered
Register-AzResourceProvider -ProviderNamespace "microsoft.web"
Register-AzResourceProvider -ProviderNamespace "microsoft.storage"

# Create a resource group for the function app
New-AzResourceGroup -Name "MyResourceGroup" -Location 'West Europe'

# Deploy the template
New-AzResourceGroupDeployment -ResourceGroupName "MyResourceGroup" -TemplateFile main.bicep  -Verbose

Aby przetestować to wdrożenie, możesz użyć szablonu takiego jak ten , który tworzy aplikację funkcji w systemie Windows w planie Zużycie.

Następne kroki

Dowiedz się więcej o sposobie tworzenia i konfigurowania usługi Azure Functions.