Automatyzowanie wdrażania zasobów dla aplikacji funkcji w usłudze Azure Functions
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 funkcji 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 | Aby dowiedzieć się więcej, zobacz... |
---|---|---|
Plan użycia usługi Azure Functions | Tylko kod | Plan zużycia |
Plan Flex Consumption usługi Azure Functions | Tylko kod | Plan Flex Consumption |
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 w usłudze Azure Arc (wersja zapoznawcza) |
Podczas korzystania z tego artykułu należy pamiętać o następujących kwestiach:
Nie ma kanonicznego sposobu tworzenia struktury szablonu usługi 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 usługi ARM, zobacz przykłady wdrażania aplikacji funkcji.
- 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 usługi ARM, zobacz przykłady wdrażania aplikacji Flex Consumption.
- 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 | Dokumentacja składni i właściwości |
---|---|---|
Konto magazynu | Wymagania | Microsoft.Storage/storageAccounts |
Składnik usługi Application Insights | Zalecane | Microsoft.Insights/components* |
Plan hostingu | Wymagania | Microsoft.Web/serverfarms |
Aplikacja funkcji | Wymagania | 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 | Wymagania | Microsoft.Storage/storageAccounts |
Składnik usługi Application Insights | Zalecane | Microsoft.Insights/components* |
Aplikacja funkcji | Wymagania | 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 | Dokumentacja składni i właściwości |
---|---|---|
Konto magazynu | Wymagania | Microsoft.Storage/storageAccounts |
Składnik usługi Application Insights | Zalecane | Microsoft.Insights/components* |
Środowisko zarządzane | Wymagania | Microsoft.App/managedEnvironments |
Aplikacja funkcji | Wymagania | 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 | Wymagania | Microsoft.Storage/storageAccounts |
Składnik usługi Application Insights | Zalecane | Microsoft.Insights/components1 |
Środowisko Kubernetes usługi App Service | Wymagania | Microsoft.ExtendedLocation/customLocations |
Aplikacja funkcji | Wymagania | Microsoft.Web/sites |
*Jeśli nie masz jeszcze obszaru roboczego usługi Log Analytics, który może być używany przez wystąpienie usługi Application Insights, musisz również utworzyć ten zasób.
Podczas wdrażania wielu zasobów w jednym pliku Bicep lub szablonie usługi 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 Define the order for deploying resources in ARM templates or Resource dependencies in Bicep (Definiowanie kolejności wdrażania zasobów w szablonach usługi ARM lub zależności zasobów w aplikacji 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>Identyfikator zasobu właściwości>.
- 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 utworzono już niestandardową lokalizację z obsługą usługi App Service w klastrze Kubernetes z obsługą usługi Azure Arc. Aby utworzyć aplikację funkcji hostowaną w niestandardowej lokalizacji w lokalizacji niestandardowej usługi Azure Arc, potrzebujesz zarówno identyfikatora lokalizacji niestandardowej, jak i identyfikatora środowiska Kubernetes.
Tworzenie konta magazynu
Wszystkie aplikacje funkcji wymagają konta usługi Azure Storage. Potrzebujesz konta ogólnego przeznaczenia, 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 magazynu służy do przechowywania ważnych danych aplikacji, czasami w tym samego kodu aplikacji. Należy ograniczyć dostęp z innych aplikacji i użytkowników do konta magazynu.
Ta przykładowa sekcja tworzy konto magazynu ogólnego przeznaczenia w warstwie Standardowa w 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ść parametry połączenia na podstawie utworzonego konta magazynu, co jest najlepszym rozwiązaniem. 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łączanie dzienników 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ść parametry 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 oparty na systemie Linux plan hostingu oparty na modelu płatności za użycie za korzystanie z modelu rozliczeń bezserwerowych. Funkcje planu obsługują sieć prywatną, wybór rozmiaru pamięci wystąpienia i ulepszoną obsługę tożsamości zarządzanej.
Plan Flex Consumption to specjalny typ serverfarm
zasobu. Można ją określić za pomocą FC1
wartości właściwości we sku
właściwości z wartością tier
FlexConsumption
.Name
W tej przykładowej sekcji przedstawiono tworzenie planu Flex Consumption:
resource flexFuncPlan 'Microsoft.Web/serverfarms@2023-12-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 plik complete 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 ją określić przy użyciu wartości EP1
, EP2
lub EP3
dla Name
wartości właściwości we sku
właściwości. 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 Dedykowane (App Service) aplikacja funkcji działa na dedykowanych maszynach wirtualnych w planach podstawowych, standardowych i Premium w planach usługi App Service, podobnie jak w przypadku aplikacji internetowych. Aby uzyskać więcej informacji, zobacz Dedykowany plan.
Aby zapoznać się z przykładowym plikiem Bicep/szablonem usługi Azure Resource Manager, zobacz Aplikacja funkcji w planie usługi aplikacja systemu Azure 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. Po pominięcia tej definicji zasobu plan jest automatycznie tworzony lub wybierany dla poszczególnych regionów podczas tworzenia samego 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ć zasoby aplikacji i planu, musisz już utworzyć ś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 lokalizacji niestandardowej extendedLocation
za pomocą pola. Jak pokazano w tym obciętym przykładzie, extendedLocation
znajduje się poza properties
elementem , jako element równorzędny i kind
location
:
resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
...
{
extendedLocation: {
name: customLocationId
}
}
}
Zasób planu powinien używać wartości Kubernetes (K1
) dla SKU
, kind
pole powinno mieć linux,kubernetes
wartość , a reserved
właściwość powinna mieć true
wartość , ponieważ jest to wdrożenie systemu Linux. Należy również ustawić extendedLocation
identyfikator lokalizacji niestandardowej i kubeEnvironmentProfile.id
identyfikator środowiska Kubernetes, odpowiednio, co może wyglądać następująco:
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
}
}
Tworzenie aplikacji funkcji
Zasób aplikacji funkcji jest definiowany przez zasób typu Microsoft.Web/sites
i kind
zawiera functionapp
wartość , co najmniej.
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 aplikację funkcji hostowaną w systemie Windows w szablonie planu zużycie.
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 lokacji używanych we wdrożeniach szablonów Bicep i ARM. Aby uzyskać więcej informacji, zobacz Konfiguracja aplikacji.
resource flexFuncApp 'Microsoft.Web/sites@2023-12-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 plik complete function.bicep w repozytorium przykładowym planu Flex Consumption.
Uwaga
Jeśli zdecydujesz się opcjonalnie zdefiniować plan Zużycie, musisz ustawić serverFarmId
właściwość w aplikacji, aby wskazać identyfikator zasobu planu. Upewnij się, że aplikacja funkcji ma dependsOn
ustawienie, które również odwołuje się do planu. Jeśli nie zdefiniowano jawnie planu, zostanie on utworzony dla Ciebie.
serverFarmId
Ustaw właściwość w aplikacji, aby wskazywać identyfikator zasobu planu. Upewnij się, że aplikacja funkcji 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 należy zachować obraz podstawowy kontenera zaktualizowany do najnowszego obsługiwanego obrazu podstawowego. 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ół usługi Functions zobowiązuje się do publikowania comiesięcznych 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.
Plik Bicep lub szablon usługi ARM można opcjonalnie zdefiniować wdrożenie kodu funkcji, które może obejmować następujące metody:
W planie Flex Consumption kod projektu jest wdrażany z pakietu skompresowanego zip opublikowanego w kontenerze usługi Blob Storage. Aby uzyskać więcej informacji, zobacz Opcje wdrażania. Określone konto magazynu i kontener używany do wdrożeń, metoda uwierzytelniania i poświadczenia są ustawiane w functionAppConfig.deployment.storage
elemecie properties
dla lokacji. Kontener i wszystkie ustawienia aplikacji muszą istnieć podczas tworzenia aplikacji. Przykład tworzenia kontenera magazynu można znaleźć w temacie Deployment container (Kontener wdrażania).
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 jest tworzony w innym miejscu 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ę funkcji w celu uzyskania dostępu do konta magazynu przy użyciu 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'
}
}
Pełny przykład referencyjny można znaleźć w tym pliku Bicep.
W przypadku używania parametry połączenia zamiast tożsamości zarządzanych należy ustawić authentication.type
StorageAccountConnectionString
wartość i ustawić authentication.storageAccountConnectionStringName
na nazwę ustawienia aplikacji, które zawiera konto magazynu wdrożenia parametry połączenia.
Plik Bicep lub szablon usługi ARM można opcjonalnie zdefiniować wdrożenie dla 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 i aparatu wdrażania usługi Functions. 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, w niektórych przypadkach aplikacja funkcji musi zostać wdrożona przed config/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, ustaw WEBSITE_RUN_FROM_PACKAGE
ustawienie w aplikacji na 1
i dołącz definicję /zipDeploy
zasobu.
W przypadku planu Zużycie w systemie Linux zamiast tego ustaw 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:
- Plany użycia w systemie Linux nie obsługują
WEBSITE_RUN_FROM_PACKAGE = 1
systemu . Zamiast tego należy ustawić identyfikator URI pakietu wdrożeniowego bezpośrednio w ustawieniuWEBSITE_RUN_FROM_PACKAGE
. Aby uzyskać więcej informacji, zobacz WEBSITE_RUN_FROM_PACKAGE. Przykładowy szablon można znaleźć w temacie Aplikacja funkcji hostowana w systemie Linux w planie zużycie.
Musi
packageUri
to być lokalizacja, do którego 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 sygnatury dostępu współdzielonego funkcje nie będą już mogły uzyskać dostępu do udziału dla wdrożeń. Podczas ponownego generowania sygnatury dostępu współdzielonego pamiętaj, aby zaktualizowaćWEBSITE_RUN_FROM_PACKAGE
ustawienie przy użyciu nowej 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ć dołączenie pakietów specyficznych dla systemu Linux w języku Python lub Node.js aplikacji utworzonych 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.
Kontenery systemu Linux
Jeśli wdrażasz konteneryzowaną aplikację funkcji w usłudze Azure Functions — wersja Premium lub Plan dedykowany, musisz:
linuxFxVersion
Ustaw ustawienie witryny przy użyciu identyfikatora obrazu kontenera.- Ustaw wszystkie wymagane
DOCKER_REGISTRY_SERVER_*
ustawienia podczas uzyskiwania kontenera z rejestru prywatnego. - Ustaw
WEBSITES_ENABLE_APP_SERVICE_STORAGE
ustawienie aplikacji nafalse
.
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
.managedEnvironmentId
Ustaw właściwość witryny na w pełni kwalifikowany identyfikator URI środowiska Container Apps.- Dodaj link do zasobu w zbiorze witryny
dependsOn
podczas tworzeniaMicrosoft.App/managedEnvironments
zasobu w tym samym czasie co witryna.
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 tylko do kodu | functionapp,linux,kubernetes |
Wdrażanie kontenera | functionapp,linux,kubernetes,container |
Należy również ustawić customLocationId
wartość 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 wystąpienia | 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:
- Ustawienia oparte na parametrach połączenia:
- Ustawienia oparte na tożsamości zarządzanej:
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 w przypadku korzystania z tożsamości zarządzanych w celu uzyskania obrazu z wystąpienia 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, jakhttp
i pojedynczej funkcji o nazwiehelloworld
, która jest typem wyzwalacza bez grupowania: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 dokumentacjęWEBSITE_CONTENTSHARE
.
- W przypadku wdrożeń kontenerów ustaw również wartość
WEBSITES_ENABLE_APP_SERVICE_STORAGE
false
na , ponieważ zawartość aplikacji jest udostępniana w samym kontenerze.
Ustawienia aplikacji należy zawsze definiować jako
siteConfig/appSettings
kolekcję tworzonegoMicrosoft.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 interfejsu API REST aktualizacji zastępują cały
/config/appsettings
zasób. 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.
Wdrożenia miejsc
Usługa Functions umożliwia wdrażanie różnych wersji kodu w unikatowych punktach końcowych w aplikacji funkcji. 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 aplikacja systemu Azure Service. 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 miejsce produkcyjne, jak i przejściowe w planie Premium, zobacz Aplikacja funkcji platformy Azure z miejscem wdrożenia.
Aby dowiedzieć się, jak zamieniać miejsca przy użyciu szablonów, zobacz Automatyzowanie przy użyciu szablonów usługi Resource Manager.
Podczas pracy z wdrożeniami miejsc należy pamiętać o następujących kwestiach:
Nie ustawiaj
WEBSITE_CONTENTSHARE
jawnie ustawienia w definicji miejsca wdrożenia. To ustawienie jest generowane podczas tworzenia aplikacji w miejscu wdrożenia.W przypadku zamiany miejsc niektóre ustawienia aplikacji są uznawane za "lepkie", ponieważ pozostają z miejscem, a nie z wymienianym kodem. Takie ustawienie miejsca można zdefiniować, uwzględniając
"slotSetting":true
w szablonie konkretną definicję ustawienia aplikacji. 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 funkcji jest definiowana Microsoft.Web/sites/networkConfig
przez zasób. Ta integracja zależy zarówno od przywołyanych 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 końcowe i trasy. Aby uzyskać więcej informacji, zobacz Opcje sieci usługi Azure Functions.
Te projekty zawierają przykłady Bicep oparte na sposobie wdrażania aplikacji funkcji w sieci wirtualnej, w tym z ograniczeniami dostępu do sieci:
- Funkcja wyzwalana przez protokół HTTP o dużej skali łączy się z centrum zdarzeń zabezpieczonym przez sieć wirtualną: funkcja wyzwalana przez protokół HTTP (tryb izolowanego procesu roboczego.NET) akceptuje wywołania z dowolnego źródła, a następnie wysyła treść tych wywołań HTTP do bezpiecznego centrum zdarzeń uruchomionego w sieci wirtualnej przy użyciu integracji z siecią wirtualną.
- Funkcja jest wyzwalana przez kolejkę usługi Service Bus zabezpieczoną w sieci wirtualnej: funkcja języka Python jest wyzwalana przez kolejkę usługi Service Bus zabezpieczoną w sieci wirtualnej. Dostęp do kolejki jest uzyskiwany w sieci wirtualnej przy użyciu prywatnego punktu końcowego. Maszyna wirtualna w sieci wirtualnej służy do wysyłania komunikatów.
Podczas tworzenia wdrożenia korzystającego z zabezpieczonego konta magazynu należy jawnie ustawić WEBSITE_CONTENTSHARE
ustawienie i utworzyć zasób udziału plików o nazwie w tym ustawieniu. Upewnij się, że tworzysz Microsoft.Storage/storageAccounts/fileServices/shares
zasób przy użyciu wartości WEBSITE_CONTENTSHARE
, jak pokazano w tym przykładzie (plik Bicep szablonu|usługi ARM). Należy również ustawić właściwość vnetContentShareEnabled
witryny na wartość true.
Uwaga
Jeśli te ustawienia nie są częścią wdrożenia korzystającego z zabezpieczonego konta magazynu, ten błąd zostanie wyświetlony podczas walidacji wdrożenia: Could not access storage account using provided connection string
.
Te projekty udostępniają przykłady szablonów Bicep i ARM dotyczące sposobu wdrażania aplikacji funkcji w sieci wirtualnej, w tym z ograniczeniami dostępu do sieci:
Scenariusz ograniczony | opis |
---|---|
Tworzenie aplikacji funkcji z integracją sieci wirtualnej | 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 funkcji nie jest ograniczony. Aby uzyskać więcej informacji, zobacz Integracja sieci wirtualnej. |
Tworzenie aplikacji funkcji, która uzyskuje dostęp do zabezpieczonego konta magazynu | Utworzona aplikacja funkcji używa 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. |
Tworzenie aplikacji funkcji i konta magazynu, które używają prywatnych punktów końcowych | Dostęp do utworzonej aplikacji funkcji można uzyskać tylko przy użyciu prywatnych punktów końcowych i używa prywatnych punktów końcowych do uzyskiwania dostępu do zasobów magazynu. 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 funkcji, gdy konto magazynu jest ograniczone do sieci wirtualnej. Aby uzyskać więcej informacji, zobacz Ograniczanie konta magazynu do sieci wirtualnej. |
vnetrouteallenabled |
1 |
Ustawienie lokacji, które wymusza cały ruch z aplikacji funkcji do korzystania z sieci wirtualnej. Aby uzyskać więcej informacji, zobacz Regionalna integracja sieci wirtualnej. To ustawienie witryny zastępuje ustawienie WEBSITE_VNET_ROUTE_ALL aplikacji . |
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 hostów i zarządzać nimi w szablonach usługi 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 name
parametr jest nazwą nowej aplikacji funkcji. Musisz dołączyć dependsOn
ustawienie, aby zagwarantować, że klucz zostanie utworzony przy użyciu nowej aplikacji funkcji. Na koniec obiekt klucza hosta może również zawierać value
właściwość, properties
która może służyć do ustawiania określonego 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 szablonami usługi ARM. Możesz użyć tych narzędzi, aby upewnić się, że kod jest poprawny i zapewnia podstawową walidację.
Witryna Azure Portal: podczas tworzenia aplikacji funkcji i powiązanych zasobów w portalu końcowy ekran Przeglądanie i tworzenie zawiera link Pobierz szablon automatyzacji .
Ten link przedstawia szablon usługi 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 informacje na temat wyglądu szablonu usługi 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 zadanie deploymentMode: '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 wstępne i wdrożenia .
Wdrażanie szablonu
Aby wdrożyć plik i szablon Bicep, możesz użyć dowolnego z następujących sposobów:
Przycisk Wdróż na platformie Azure
Uwaga
Ta metoda nie obsługuje obecnie wdrażania plików Bicep.
Zastąp <url-encoded-path-to-azuredeploy-json>
ciąg wersją zakodowaną w adresie URL ścieżki pierwotnej azuredeploy.json
pliku w usłudze GitHub.
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 usługi ARM, który tworzy aplikację funkcji z wymaganymi zasobami. Aby uruchomić lokalnie, musisz mieć zainstalowany program Azure PowerShell . Uruchom polecenie Connect-AzAccount
, aby się zalogować.
# 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.