Zagadnienia dotyczące magazynu dla usługi Azure Functions
Usługa Azure Functions wymaga konta usługi Azure Storage podczas tworzenia wystąpienia aplikacji funkcji. Następujące usługi magazynu mogą być używane przez aplikację funkcji:
| Usługa magazynu | Użycie funkcji |
|---|---|
| Azure Blob Storage | Zachowaj stan powiązań i kluczefunkcji 1. Źródło wdrożenia dla aplikacji uruchamianych w planie Flex Consumption. Używany domyślnie w przypadku centrów zadań w usłudze Durable Functions. Może służyć do przechowywania kodu aplikacji funkcji dla zdalnego użycia systemu Linux kompilacji zdalnej lub w ramach wdrożeń zewnętrznych adresów URL pakietów. |
| Azure Files2 | Udział plików używany do przechowywania i uruchamiania kodu aplikacji funkcji w planie zużycia i planie Premium. |
| Azure Queue Storage | Używany domyślnie w przypadku centrów zadań w usłudze Durable Functions. Służy do obsługi błędów i ponawiania prób w określonych wyzwalaczach usługi Azure Functions. Służy do śledzenia obiektów przez wyzwalacz usługi Blob Storage. |
| Azure Table storage | Używany domyślnie w przypadku centrów zadań w usłudze Durable Functions. |
- Magazyn obiektów blob jest domyślnym magazynem kluczy funkcji, ale można skonfigurować magazyn alternatywny.
- Usługa Azure Files jest domyślnie skonfigurowana, ale możesz utworzyć aplikację bez usługi Azure Files w określonych warunkach.
Ważne uwagi
Należy zdecydowanie wziąć pod uwagę następujące fakty dotyczące kont magazynu używanych przez aplikacje funkcji:
Gdy aplikacja funkcji jest hostowana w planie Zużycie lub planie Premium, kod funkcji i pliki konfiguracji są przechowywane w usłudze Azure Files na połączonym koncie magazynu. Po usunięciu tego konta magazynu zawartość zostanie usunięta i nie można jej odzyskać. Aby uzyskać więcej informacji, zobacz Konto magazynu zostało usunięte
Ważne dane, takie jak kod funkcji, klucze dostępu i inne ważne dane związane z usługą, mogą być utrwalane na koncie magazynu. Należy dokładnie zarządzać dostępem do kont magazynu używanych przez aplikacje funkcji w następujący sposób:
Przeprowadź inspekcję i ogranicz dostęp aplikacji i użytkowników do konta magazynu na podstawie modelu z najmniejszymi uprawnieniami. Uprawnienia do konta magazynu mogą pochodzić z akcji danych w przypisanej roli lub za pomocą uprawnień do wykonania operacji listKeys.
Monitoruj działanie płaszczyzny sterowania (takie jak pobieranie kluczy) i operacje płaszczyzny danych (takie jak zapisywanie w obiekcie blob) na koncie magazynu. Rozważ obsługę dzienników magazynu w lokalizacji innej niż Usługa Azure Storage. Aby uzyskać więcej informacji, zobacz Dzienniki magazynu.
Wymagania konta magazynu
Konta magazynu utworzone w ramach przepływu tworzenia aplikacji funkcji w witrynie Azure Portal mają gwarancję pracy z nową aplikacją funkcji. Jeśli zdecydujesz się używać istniejącego konta magazynu, podana lista nie zawiera niektórych nieobsługiwanych kont magazynu. Następujące ograniczenia dotyczą kont magazynu używanych przez aplikację funkcji, więc upewnij się, że istniejące konto magazynu spełnia następujące wymagania:
Typ konta musi obsługiwać obiekty blob, kolejki i usługi Table Storage. Niektóre konta magazynu nie obsługują kolejek i tabel. Te konta obejmują konta magazynu tylko dla obiektów blob i platformę Azure Premium Storage. Aby dowiedzieć się więcej o typach kont magazynu, zobacz Omówienie konta magazynu.
Nie można użyć konta magazynu zabezpieczonego przez sieć, gdy aplikacja funkcji jest hostowana w planie Zużycie.
Podczas tworzenia aplikacji funkcji w portalu możesz wybrać istniejące konto magazynu tylko w tym samym regionie, w którym tworzysz aplikację funkcji. Jest to optymalizacja wydajności, a nie ścisłe ograniczenie. Aby dowiedzieć się więcej, zobacz Lokalizacja konta magazynu.
Podczas tworzenia aplikacji funkcji w planie z włączoną obsługą strefy dostępności obsługiwane są tylko konta magazynu strefowo nadmiarowego.
W przypadku używania automatyzacji wdrażania do tworzenia aplikacji funkcji przy użyciu konta magazynu zabezpieczonego przez sieć należy uwzględnić określone konfiguracje sieciowe w szablonie usługi ARM lub pliku Bicep. Jeśli nie uwzględnisz tych ustawień i zasobów, automatyczne wdrożenie może zakończyć się niepowodzeniem w weryfikacji. Aby uzyskać bardziej szczegółowe wskazówki dotyczące usługi ARM i Bicep, zobacz Zabezpieczone wdrożenia. Aby zapoznać się z omówieniem konfigurowania kont magazynu z siecią, zobacz How to use a secured storage account with Azure Functions (Jak używać zabezpieczonego konta magazynu w usłudze Azure Functions).
Wskazówki dotyczące konta magazynu
Każda aplikacja funkcji wymaga, aby konto magazynu działało. Po usunięciu tego konta aplikacja funkcji nie zostanie uruchomiona. Aby rozwiązać problemy związane z magazynem, zobacz Jak rozwiązywać problemy związane z magazynem. Poniższe inne zagadnienia dotyczą konta magazynu używanego przez aplikacje funkcji.
Lokalizacja konta magazynu
Aby uzyskać najlepszą wydajność, aplikacja funkcji powinna używać konta magazynu w tym samym regionie, co zmniejsza opóźnienie. Witryna Azure Portal wymusza to najlepsze rozwiązanie. Jeśli z jakiegoś powodu musisz użyć konta magazynu w regionie innym niż aplikacja funkcji, musisz utworzyć aplikację funkcji poza portalem.
Konto magazynu musi być dostępne dla aplikacji funkcji. Jeśli musisz użyć zabezpieczonego konta magazynu, rozważ ograniczenie konta magazynu do sieci wirtualnej.
Ustawienie połączenia konta magazynu
Domyślnie aplikacje funkcji konfigurują AzureWebJobsStorage połączenie jako parametry połączenia przechowywane w ustawieniu aplikacji AzureWebJobsStorage, ale można również skonfigurować usługę AzureWebJobsStorage do korzystania z połączenia opartego na tożsamości bez wpisu tajnego.
Aplikacje funkcji działające w planie Zużycie (tylko system Windows) lub elastyczny plan Premium (Windows lub Linux) mogą używać usługi Azure Files do przechowywania obrazów wymaganych do włączenia dynamicznego skalowania. W przypadku tych planów ustaw parametry połączenia dla konta magazynu w ustawieniu WEBSITE_CONTENTAZUREFILECONNECTIONSTRING i nazwę udziału plików w ustawieniu WEBSITE_CONTENTSHARE. Jest to zwykle to samo konto używane dla programu AzureWebJobsStorage. Możesz również utworzyć aplikację funkcji, która nie korzysta z usługi Azure Files, ale skalowanie może być ograniczone.
Uwaga
Konto magazynu parametry połączenia należy zaktualizować podczas ponownego generowania kluczy magazynu. Przeczytaj więcej na temat zarządzania kluczami magazynu tutaj.
Udostępnione konta magazynu
Istnieje możliwość, aby wiele aplikacji funkcji współużytkować to samo konto magazynu bez żadnych problemów. Na przykład w programie Visual Studio można tworzyć wiele aplikacji przy użyciu emulatora magazynu Azurite. W takim przypadku emulator działa jak pojedyncze konto magazynu. To samo konto magazynu używane przez aplikację funkcji może być również używane do przechowywania danych aplikacji. Jednak takie podejście nie zawsze jest dobrym pomysłem w środowisku produkcyjnym.
Może być konieczne użycie oddzielnych kont magazynu, aby uniknąć kolizji identyfikatorów hosta.
Zagadnienia dotyczące zasad zarządzania cyklem życia
Nie należy stosować zasad zarządzania cyklem życia do konta usługi Blob Storage używanego przez aplikację funkcji. Usługa Functions używa usługi Blob Storage do utrwalania ważnych informacji, takich jak klucze dostępu do funkcji, a zasady mogą usuwać obiekty blob (takie jak klucze) wymagane przez hosta usługi Functions. Jeśli musisz używać zasad, wyklucz kontenery używane przez funkcje, które są poprzedzone prefiksem azure-webjobs lub scm.
Dzienniki magazynu
Ponieważ kod funkcji i klucze mogą być utrwalane na koncie magazynu, rejestrowanie aktywności względem konta magazynu jest dobrym sposobem monitorowania nieautoryzowanego dostępu. Dzienniki zasobów usługi Azure Monitor mogą służyć do śledzenia zdarzeń względem płaszczyzny danych magazynu. Aby uzyskać szczegółowe informacje na temat konfigurowania i analizowania tych dzienników, zobacz Monitorowanie usługi Azure Storage .
Dziennik aktywności usługi Azure Monitor zawiera zdarzenia płaszczyzny sterowania, w tym operację listKeys. Należy jednak również skonfigurować dzienniki zasobów dla konta magazynu, aby śledzić kolejne użycie kluczy lub innych operacji płaszczyzny danych opartych na tożsamościach. Powinna być włączona co najmniej kategoria dzienników StorageWrite, aby móc identyfikować modyfikacje danych poza normalnymi operacjami funkcji.
Aby ograniczyć potencjalny wpływ wszystkich uprawnień do magazynowania w szerokim zakresie, rozważ użycie miejsca docelowego innego niż magazyn dla tych dzienników, takiego jak Log Analytics. Aby uzyskać więcej informacji, zobacz Monitorowanie usługi Azure Blob Storage.
Optymalizowanie wydajności magazynu
Aby zmaksymalizować wydajność, użyj oddzielnego konta magazynu dla każdej aplikacji funkcji. Jest to szczególnie ważne, gdy masz wyzwalane funkcje Durable Functions lub Event Hub, które generują dużą ilość transakcji magazynu. Gdy logika aplikacji współdziała z usługą Azure Storage bezpośrednio (przy użyciu zestawu SDK usługi Storage) lub za pomocą jednego z powiązań magazynu, należy użyć dedykowanego konta magazynu. Jeśli na przykład masz funkcję wyzwalaną przez centrum zdarzeń zapisując dane w magazynie obiektów blob, użyj dwóch kont magazynu — jednego dla aplikacji funkcji, a drugiego dla obiektów blob przechowywanych przez funkcję.
Spójny routing za pośrednictwem sieci wirtualnych
Wiele aplikacji funkcji hostowanych w tym samym planie może również używać tego samego konta magazynu dla udziału zawartości usługi Azure Files (zdefiniowanego przez WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGusługę ). Gdy to konto magazynu jest również zabezpieczone przez sieć wirtualną, wszystkie te aplikacje powinny również używać tej samej wartości dla vnetContentShareEnabled (dawniej ) w celu zagwarantowania, że ruch jest kierowany spójnie WEBSITE_CONTENTOVERVNETprzez docelową sieć wirtualną. Niezgodność tego ustawienia między aplikacjami korzystającymi z tego samego konta magazynu usługi Azure Files może spowodować kierowanie ruchu przez sieci publiczne, co powoduje zablokowanie dostępu przez reguły sieci konta magazynu.
Praca z obiektami blob
Kluczowym scenariuszem dla usługi Functions jest przetwarzanie plików w kontenerze obiektów blob, takich jak przetwarzanie obrazów lub analiza tonacji. Aby dowiedzieć się więcej, zobacz Process file uploads (Przetwarzanie przekazywania plików).
Wyzwalanie w kontenerze obiektów blob
Istnieje kilka sposobów wykonywania kodu funkcji na podstawie zmian w obiektach blob w kontenerze magazynu. Skorzystaj z poniższej tabeli, aby określić, który wyzwalacz funkcji najlepiej odpowiada Twoim potrzebom:
| Strategia | Kontener (sondowanie) | Kontener (zdarzenia) | Wyzwalacz kolejki | Event Grid |
|---|---|---|---|---|
| Opóźnienie | Wysoki (do 10 minut) | Niski | Śred. | Niski |
| Ograniczenia konta magazynu | Konta tylko do obiektów blob nie są obsługiwane | ogólnego przeznaczenia, wersja 1 nie jest obsługiwana | Brak | ogólnego przeznaczenia, wersja 1 nie jest obsługiwana |
| Typ wyzwalacza | Blob Storage | Blob Storage | Queue Storage | Event Grid |
| Wersja rozszerzenia | Dowolne | Storage v5.x+ | Dowolne | Dowolne |
| Przetwarza istniejące obiekty blob | Tak | Nie. | Nie. | Nie. |
| Filtry | Wzorzec nazwy obiektu blob | Filtry zdarzeń | nie dotyczy | Filtry zdarzeń |
| Wymaga subskrypcji zdarzeń | Nie. | Tak | Nie | Tak |
| Obsługuje plan Flex Consumption | Nie. | Tak | Tak | Tak |
| Obsługuje dużą skalę² | Nie. | Tak | Tak | Tak |
| opis | Domyślne zachowanie wyzwalacza, które polega na sondowaniu kontenera pod kątem aktualizacji. Aby uzyskać więcej informacji, zobacz przykłady w dokumentacji wyzwalacza usługi Blob Storage. | Używa zdarzeń magazynu obiektów blob z subskrypcji zdarzeń. Source Wymaga wartości parametru .EventGrid Aby uzyskać więcej informacji, zobacz Samouczek: wyzwalanie usługi Azure Functions w kontenerach obiektów blob przy użyciu subskrypcji zdarzeń. |
Ciąg nazwy obiektu blob jest ręcznie dodawany do kolejki magazynu po dodaniu obiektu blob do kontenera. Ta wartość jest przekazywana bezpośrednio przez wyzwalacz usługi Queue Storage do powiązania wejściowego usługi Blob Storage w tej samej funkcji. | Zapewnia elastyczność wyzwalania zdarzeń oprócz zdarzeń pochodzących z kontenera magazynu. Użyj polecenia , jeśli konieczne jest również wyzwolenie funkcji przez zdarzenia inne niżtorage. Aby uzyskać więcej informacji, zobacz Jak pracować z wyzwalaczami i powiązaniami usługi Event Grid w usłudze Azure Functions. |
- Powiązania wejściowe i wyjściowe usługi Blob Storage obsługują konta tylko do obiektów blob.
- Duża skala może być luźno zdefiniowana jako kontenery, które mają więcej niż 100 000 obiektów blob w nich lub konta magazynu, które mają więcej niż 100 aktualizacji obiektów blob na sekundę.
Szyfrowanie danych magazynu
Usługa Azure Storage szyfruje wszystkie dane na koncie magazynu magazynowanych. Więcej informacji można znaleźć w sekcji Szyfrowanie danych przechowywanych w usłudze Azure Storage.
Domyślnie dane są szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft. Aby uzyskać dodatkową kontrolę nad kluczami szyfrowania, można podać klucze zarządzane przez klienta do użycia do szyfrowania obiektów blob i danych plików. Te klucze muszą znajdować się w usłudze Azure Key Vault dla usługi Functions, aby móc uzyskać dostęp do konta magazynu. Aby dowiedzieć się więcej, zobacz Szyfrowanie magazynowane przy użyciu kluczy zarządzanych przez klienta.
Miejsce przechowywania danych w regionie
Gdy wszystkie dane klienta muszą pozostać w jednym regionie, konto magazynu skojarzone z aplikacją funkcji musi być jedno z nadmiarowością w regionie. Należy również używać konta magazynu nadmiarowego w regionie z usługą Azure Durable Functions.
Inne dane klienta zarządzane przez platformę są przechowywane tylko w regionie, gdy hostuje się w środowisku App Service Environment (ASE) ze zrównoważonym obciążeniem wewnętrznym. Aby dowiedzieć się więcej, zobacz nadmiarowość stref środowiska ASE.
Zagadnienia dotyczące identyfikatora hosta
Usługa Functions używa wartości identyfikatora hosta jako sposobu unikatowego identyfikowania określonej aplikacji funkcji w przechowywanych artefaktach. Domyślnie ten identyfikator jest automatycznie generowany z nazwy aplikacji funkcji, obcięty do pierwszych 32 znaków. Ten identyfikator jest następnie używany podczas przechowywania informacji korelacji dla aplikacji i śledzenia na połączonym koncie magazynu. Jeśli masz aplikacje funkcji o nazwach dłuższych niż 32 znaki i gdy pierwsze 32 znaki są identyczne, to obcinanie może spowodować zduplikowanie wartości identyfikatora hosta. Gdy dwie aplikacje funkcji z identycznymi identyfikatorami hostów używają tego samego konta magazynu, występuje kolizja identyfikatora hosta, ponieważ przechowywane dane nie mogą być unikatowo połączone z poprawną aplikacją funkcji.
Uwaga
Ten sam rodzaj kolizji identyfikatora hosta może wystąpić między aplikacją funkcji w miejscu produkcyjnym a tą samą aplikacją funkcji w miejscu przejściowym, gdy oba miejsca używają tego samego konta magazynu.
Począwszy od wersji 3.x środowiska uruchomieniowego usługi Functions, wykryto kolizję identyfikatora hosta i jest rejestrowane ostrzeżenie. W wersji 4.x jest rejestrowany błąd, a host jest zatrzymany, co powoduje awarię. Więcej szczegółów na temat kolizji identyfikatora hosta można znaleźć w tym problemie.
Unikanie kolizji identyfikatora hosta
Aby uniknąć kolizji identyfikatorów hosta, można użyć następujących strategii:
- Użyj oddzielnego konta magazynu dla każdej aplikacji funkcji lub miejsca związanego z kolizją.
- Zmień nazwę jednej z aplikacji funkcji na wartość mniejszą niż 32 znaki, która zmienia obliczony identyfikator hosta dla aplikacji i usuwa kolizję.
- Ustaw jawny identyfikator hosta dla co najmniej jednej zderzającej się aplikacji. Aby dowiedzieć się więcej, zobacz Zastępowanie identyfikatora hosta.
Ważne
Zmiana konta magazynu skojarzonego z istniejącą aplikacją funkcji lub zmiana identyfikatora hosta aplikacji może mieć wpływ na zachowanie istniejących funkcji. Na przykład wyzwalacz usługi Blob Storage śledzi, czy są przetwarzane poszczególne obiekty blob, zapisując potwierdzenia w ramach określonej ścieżki identyfikatora hosta w magazynie. Gdy identyfikator hosta zmieni się lub wskażesz nowe konto magazynu, wcześniej przetworzone obiekty blob mogą zostać ponownie przetworzone.
Przesłanianie identyfikatora hosta
Możesz jawnie ustawić określony identyfikator hosta dla aplikacji funkcji w ustawieniach aplikacji przy użyciu AzureFunctionsWebHost__hostid ustawienia . Aby uzyskać więcej informacji, zobacz AzureFunctionsWebHost__hostid.
W przypadku wystąpienia kolizji między miejscami należy ustawić określony identyfikator hosta dla każdego miejsca, w tym miejsce produkcyjne. Należy również oznaczyć te ustawienia jako ustawienia wdrożenia, aby nie zostały zamienione. Aby dowiedzieć się, jak tworzyć ustawienia aplikacji, zobacz Praca z ustawieniami aplikacji.
Klastry z obsługą usługi Azure Arc
Po wdrożeniu aplikacji funkcji w klastrze Kubernetes z włączoną usługą Azure Arc konto magazynu może nie być wymagane przez aplikację funkcji. W takim przypadku konto magazynu jest wymagane tylko przez usługę Functions, gdy aplikacja funkcji używa wyzwalacza, który wymaga magazynu. W poniższej tabeli przedstawiono wyzwalacze, które mogą wymagać konta magazynu i które nie.
| Niewymagane | może wymagać magazynu |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Service Bus |
• Azure SQL • Magazyn obiektów blob • Event Grid • Event Hubs • IoT Hub • Queue Storage • SendGrid • SignalR • Magazyn tabel • Czasomierz • Twilio |
Aby utworzyć aplikację funkcji w klastrze Kubernetes z obsługą usługi Azure Arc bez magazynu, musisz użyć polecenia interfejsu wiersza polecenia platformy Azure az functionapp create. Wersja interfejsu wiersza polecenia platformy Azure musi zawierać wersję 0.1.7 lub nowszą wersję rozszerzenia appservice-kube. az --version Użyj polecenia , aby sprawdzić, czy rozszerzenie jest zainstalowane i czy jest poprawną wersją.
Tworzenie zasobów aplikacji funkcji przy użyciu metod innych niż interfejs wiersza polecenia platformy Azure wymaga istniejącego konta magazynu. Jeśli planujesz używać wyzwalaczy, które wymagają konta magazynu, przed utworzeniem aplikacji funkcji należy utworzyć konto.
Tworzenie aplikacji bez usługi Azure Files
Usługa Azure Files udostępnia udostępniony system plików, który obsługuje scenariusze o dużej skali. Gdy aplikacja funkcji działa w systemie Windows w ramach planu Elastic Premium lub Consumption, udział usługi Azure Files jest tworzony domyślnie na koncie magazynu. Ten udział jest używany przez funkcje do włączania niektórych funkcji, takich jak przesyłanie strumieniowe dzienników. Jest on również używany jako lokalizacja wdrożenia pakietu udostępnionego, która gwarantuje spójność wdrożonego kodu funkcji we wszystkich wystąpieniach.
Domyślnie aplikacje funkcji hostowane w planach Premium i Zużycie używają wdrożenia zip z pakietami wdrożeniowymi przechowywanymi w tym udziale plików platformy Azure. Ta sekcja dotyczy tylko tych planów hostingu.
Korzystanie z usługi Azure Files wymaga użycia parametry połączenia, która jest przechowywana w ustawieniach aplikacji jako WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Usługa Azure Files obecnie nie obsługuje połączeń opartych na tożsamościach. Jeśli twój scenariusz wymaga, aby nie przechowywać żadnych wpisów tajnych w ustawieniach aplikacji, musisz usunąć zależność aplikacji od usługi Azure Files. Możesz to zrobić, tworząc aplikację bez domyślnej zależności usługi Azure Files.
Uwaga
Należy również rozważyć uruchomienie w aplikacji funkcji w planie Flex Consumption, który jest obecnie w wersji zapoznawczej. Plan Flex Consumption zapewnia większą kontrolę nad pakietem wdrożeniowym, w tym możliwość korzystania z połączeń tożsamości zarządzanych. Aby uzyskać więcej informacji, zobacz Konfigurowanie ustawień wdrażania w artykule Flex Consumption .
Aby uruchomić aplikację bez udziału plików platformy Azure, musisz spełnić następujące wymagania:
- Pakiet należy wdrożyć w zdalnym kontenerze usługi Azure Blob Storage, a następnie ustawić adres URL zapewniający dostęp do tego pakietu jako
WEBSITE_RUN_FROM_PACKAGEustawienie aplikacji. Ta opcja umożliwia przechowywanie zawartości aplikacji w usłudze Blob Storage zamiast usługi Azure Files, która obsługuje tożsamości zarządzane.
Użytkownik jest odpowiedzialny za ręczne aktualizowanie pakietu wdrożeniowego i utrzymywanie adresu URL pakietu wdrożeniowego, który prawdopodobnie zawiera sygnaturę dostępu współdzielonego (SAS).
- Aplikacja nie może polegać na udostępnionym systemie plików zapisywalnym.
- Aplikacja nie może używać wersji 1.x środowiska uruchomieniowego usługi Functions.
- Środowiska przesyłania strumieniowego dzienników na klientach, takich jak domyślna wartość dzienników systemu plików w witrynie Azure Portal. Zamiast tego należy polegać na dziennikach usługi Application Insights.
Jeśli powyższe wymagania odpowiadają Twojemu scenariuszowi, możesz utworzyć aplikację funkcji bez usługi Azure Files. Możesz to zrobić, tworząc aplikację bez WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ustawień aplikacji i .WEBSITE_CONTENTSHARE Aby rozpocząć, wygeneruj szablon usługi ARM dla wdrożenia standardowego, usuń te dwa ustawienia, a następnie wdróż zmodyfikowany szablon.
Ponieważ usługa Azure Files służy do włączania dynamicznego skalowania w poziomie dla usługi Functions, skalowanie może być ograniczone w przypadku uruchamiania aplikacji bez usługi Azure Files w ramach planu Elastic Premium i planów Zużycie działających w systemie Windows.
Instalowanie udziałów plików
Ta funkcja jest dostępna tylko w przypadku uruchamiania w systemie Linux.
Istniejące udziały usługi Azure Files można zainstalować w aplikacjach funkcji systemu Linux. Instalowanie udziału w aplikacji funkcji systemu Linux umożliwia używanie istniejących modeli uczenia maszynowego lub innych danych w funkcjach. Aby zainstalować istniejący udział w aplikacji funkcji systemu Linux, możesz użyć następującego polecenia.
az webapp config storage-account add
W tym poleceniu share-name jest nazwą istniejącego udziału usługi Azure Files i custom-id może być dowolnym ciągiem, który jednoznacznie definiuje udział podczas instalacji w aplikacji funkcji. Jest również ścieżką, mount-path z której jest uzyskiwany dostęp do udziału w aplikacji funkcji. mount-path musi być w formacie /dir-name, a nie może zaczynać się od /home.
Aby zapoznać się z kompletnym przykładem, zobacz skrypty w temacie Tworzenie aplikacji funkcji języka Python i instalowanie udziału usługi Azure Files.
Obecnie obsługiwany jest tylko element storage-type z AzureFiles . W danej aplikacji funkcji można zainstalować tylko pięć udziałów. Instalowanie udziału plików może zwiększyć zimny czas rozpoczęcia o co najmniej 200–300 ms, a nawet więcej, gdy konto magazynu znajduje się w innym regionie.
Zainstalowany udział jest dostępny dla kodu funkcji w mount-path określonym miejscu. Na przykład, gdy mount-path ma /path/to/mountwartość , można uzyskać dostęp do katalogu docelowego za pomocą interfejsów API systemu plików, jak w poniższym przykładzie języka Python:
import os
...
files_in_share = os.listdir("/path/to/mount")
Następne kroki
Dowiedz się więcej o opcjach hostingu usługi Azure Functions.