Zagadnienia dotyczące magazynu dla Azure Functions

Podczas tworzenia wystąpienia aplikacji funkcji w Azure należy zapewnić dostęp do domyślnego konta Azure Storage. Na poniższym diagramie i w tabeli opisano, jak Azure Functions korzysta z usług domyślnego konta magazynowego.

Wybierz swój plan hostingu na górze tego artykułu, aby zobaczyć wytyczne dotyczące przechowywania danych dotyczących Twojej aplikacji funkcjonalnej.

Diagram pokazujący, jak Azure Functions używa różnych usług magazynowania na koncie Azure Storage, w tym Blob Storage, Magazyn plików, Queue Storage i Table Storage.

Usługa magazynu Użycie funkcji
Azure Blob Storage Zachowaj stan powiązań i klawisze funkcyjne1.
Źródło wdrożenia dla aplikacji uruchamianych w planie Flex Consumption.
Używane domyślnie dla centrów zadań w Durable Functions.
Może być używane do przechowywania kodu aplikacji funkcji dla zdalnej kompilacji konsumcyjnej na Linuxie lub w ramach wdrożeń z adresów URL zewnętrznych pakietów.
Azure Files2 Zasób plików używany do przechowywania i uruchamiania kodu aplikacji funkcji w planie Zużycie oraz w planie Premium.
Utrzymywanie pakietów rozszerzeń.
Przechowywanie dzienników wdrażania.
Obsługuje zależności zarządzane w programie PowerShell.
Azure Queue Storage Używane domyślnie dla centrów zadań w Durable Functions. Służy do obsługi błędów i ponawiania prób w określonych wyzwalaczach Azure Functions. Służy do śledzenia obiektów przez wyzwalacz usługi Blob Storage.
Azure Table Storage Używane domyślnie dla centrów zadań w Durable Functions.
Służy do śledzenia zdarzeń diagnostycznych.
  1. Magazyn obiektów blob jest domyślnym magazynem kluczy funkcji, ale można skonfigurować magazyn alternatywny.
  2. Azure Files jest domyślnie konfigurowane, ale można stworzyć aplikację bez Azure Files w pewnych warunkach.

Ważne uwagi

Weź pod uwagę następujące fakty dotyczące kont pamięci używanej przez Twoje aplikacje operacyjne:

Gdy hostujesz aplikację funkcjonalną w planie Consumption (Windows) lub Premium, przechowujesz kod funkcji i pliki konfiguracyjne w Azure Files na powiązanym koncie pamięci. Jeśli usuniesz to konto pamięciowe, na stałe usuwasz treść. Aby uzyskać więcej informacji, zobacz Konto magazynowe zostało usunięte.

  • Konto pamięci przechowywanej przechowuje ważne dane, takie jak kod funkcji, klucze dostępu oraz inne ważne dane związane z usługą. Należy dokładnie zarządzać dostępem do kont magazynu używanych przez aplikacje funkcjonalne, w następujący sposób:

    • Przeprowadź inspekcję i ogranicz dostęp aplikacji i użytkowników do konta magazynowego na podstawie modelu z najmniejszymi uprawnieniami. Uprawnienia do konta magazynu mogą pochodzić z akcji danych w przypisanej roli lub poprzez uprawnienia do wykonania operacji listKeys.

    • Monitoruj działanie warstwy sterowania (takie jak pobieranie kluczy) i operacje warstwy danych (takie jak zapisywanie do obiektu blob) w ramach konta magazynu. Rozważ przechowywanie dzienników magazynowych w lokalizacji innej niż Azure Storage. Aby uzyskać więcej informacji, zobacz Dzienniki magazynu.

  • Jeśli używasz Durable Functions, magazyn danych centrum zadań jest szczególnie wrażliwy z punktu widzenia bezpieczeństwa, ponieważ uprawnienia zapisu do niego mogą zostać wykorzystane do zmiany działania aplikacji, w tym do uruchamiania dowolnego kodu. Aby uzyskać więcej informacji, zobacz Zabezpieczanie magazynu centrum zadań.

Wymagania konta magazynu

Konta magazynowe tworzone podczas procesu tworzenia aplikacji funkcjonalnej w portalu Azure działają z nową aplikacją funkcjonalną. Jeśli zdecydujesz się używać istniejącego konta pamięci masowej, dostarczona lista nie zawiera niektórych nieobsługiwanych kont pamięci masowej. W odniesieniu do kont magazynu używanych przez aplikację funkcji obowiązują następujące ograniczenia. Upewnij się, że istniejące konto pamięci masowej spełnia następujące wymagania:

  • Nie można użyć konta magazynu zabezpieczonego przez sieć, gdy aplikacja funkcji jest hostowana w planie konsumpcyjnym.

  • Typ konta musi obsługiwać magazyn obiektów Blob, kolejki oraz tabel. Niektóre konta magazynu nie obsługują kolejek i tabel. Te konta obejmują konta magazynu przeznaczonego wyłącznie dla obiektów blob oraz Azure Premium Storage. Aby dowiedzieć się więcej o typach kont magazynu, zobacz Omówienie konta magazynu.

  • Podczas tworzenia aplikacji funkcji w portalu Azure można wybrać tylko istniejące konto magazynu w tym samym regionie, co aplikacja funkcji, którą tworzysz. To wymaganie jest optymalizacją wydajności, a nie ścisłym ograniczeniem. Aby dowiedzieć się więcej, zobacz Lokalizację konta magazynowego.

  • Po utworzeniu aplikacji funkcji w planie z włączoną obsługą strefy dostępności obsługiwane są tylko konta magazynu strefowo nadmiarowego .

Jeśli używasz automatyzacji wdrażania do tworzenia funkcji aplikacji z kontem magazynu zabezpieczonym siecią, musisz 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ć wskazówki dotyczące szablonu ARM i Bicep, zobacz Secured deployments. Aby zapoznać się z ogólnymi informacjami na temat konfigurowania kont magazynu z siecią, zobacz Jak użyć zabezpieczonego konta magazynu z Azure Functions.

Wskazówki dotyczące konta magazynowego

Każda aplikacja funkcji wymaga, aby konto magazynu działało. Po usunięciu tego konta aplikacja funkcji przestanie działać. Aby rozwiązać problemy związane z magazynem, zobacz Jak rozwiązywać problemy związane z magazynem. Poniższe zagadnienia dotyczą konta magazynowego używanego przez aplikacje funkcji Azure.

Lokalizacja konta magazynu

Aby uzyskać najlepszą wydajność, aplikacja funkcji powinna używać konta magazynu w tym samym regionie, co zmniejsza opóźnienie. Portal Azure wymusza tę najlepszą praktykę. Jeśli musisz użyć konta magazynu w regionie innym niż twoja aplikacja funkcji, powinieneś utworzyć aplikację funkcji poza portalem Azure.

Konto magazynowe musi być dostępne dla aplikacji Function App. Jeśli musisz użyć zabezpieczonego konta magazynu, rozważ ograniczenie konta magazynu do sieci wirtualnej.

Konfiguracja połączenia konta przechowywania

Domyślnie aplikacje funkcji konfigurują połączenie AzureWebJobsStorage jako ciąg połączenia przechowywany w ustawieniu aplikacji AzureWebJobsStorage. Możesz również skonfigurować usługę AzureWebJobsStorage do korzystania z połączenia opartego na tożsamości użytkownika bez sekretu.

Aplikacje funkcji Azure działające w planie Zużycie (tylko Windows) lub planie Elastic Premium (Windows lub Linux) mogą używać Azure Files do przechowywania obrazów niezbędnych do umożliwienia skalowania dynamicznego. W przypadku tych planów ustaw łańcuch połączenia dla konta magazynu w ustawieniu WEBSITE_CONTENTAZUREFILECONNECTIONSTRING oraz nazwę udziału plików w ustawieniu WEBSITE_CONTENTSHARE. Ta wartość jest zazwyczaj tym samym kontem używanym dla AzureWebJobsStorage. Można również utworzyć aplikację funkcji, która nie używa Azure Files, ale skalowanie może być ograniczone.

Uwaga

Należy zaktualizować łańcuch połączenia konta magazynu, gdy klucze magazynu są regenerowane. Aby uzyskać więcej informacji, zobacz Tworzenie konta magazynu Azure.

Udostępnione konta przechowywania

Wiele aplikacji funkcjonalności może współużytkować to samo konto magazynowe bez żadnych problemów. Na przykład w Visual Studio można tworzyć wiele aplikacji przy użyciu emulatora magazynu Azurite. W takim przypadku emulator działa jak pojedyncze konto magazynowe. To samo konto magazynu używane przez aplikację funkcji może również przechowywać dane aplikacji. Jednak takie podejście nie zawsze jest dobrym pomysłem w środowisku produkcyjnym.

Może być konieczne użycie oddzielnych kont przechowywania, 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 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. Zasady mogą usuwać bloby, takie jak klucze, wymagane przez hosta Functions. Jeśli musisz używać zasad, wyklucz kontenery używane przez funkcje, które są poprzedzone prefiksem azure-webjobs lub scm.

Dzienniki pamięci masowej

Ponieważ kod funkcji i klucze mogą być utrwalane na koncie magazynu, rejestrowanie aktywności na koncie magazynu jest dobrym sposobem monitorowania nieautoryzowanego dostępu. Dzienniki zasobów 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 Azure Storage.

Dziennik aktywności Azure Monitor pokazuje wydarzenia płaszczyzny kontrolnej, 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 transferu danych opartych na tożsamości. Aby móc identyfikować modyfikacje danych poza standardowymi operacjami funkcji, powinna być włączona co najmniej kategoria dzienników StorageWrite.

Aby ograniczyć potencjalny wpływ szerokiego zakresu uprawnień do przechowywania, rozważ użycie miejsca docelowego innego niż pamięć dla tych dzienników, takiego jak Log Analytics. Aby uzyskać więcej informacji, zobacz Monitoring Azure Blob Storage.

Optymalizowanie wydajności magazynu

Aby zmaksymalizować wydajność, użyj oddzielnego konta przechowywania dla każdej aplikacji funkcjonalnej. Takie podejście jest szczególnie ważne w przypadku funkcji Durable Functions lub funkcji wyzwalanych przez Event Hubs, które generują dużą liczbę transakcji przechowywania. Gdy logika aplikacji współdziała z Azure Storage, bezpośrednio (przy użyciu Storage SDK) lub za pomocą jednego z powiązań magazynu, należy użyć dedykowanego konta magazynu. Na przykład, jeśli masz funkcję uruchamianą przez Event Hub, która zapisuje dane do magazynu obiektów blob, użyj dwóch kont magazynu: jedno dla aplikacji funkcji, a drugie dla obiektów blob przechowywanych przez tę funkcję.

Spójny routing za pośrednictwem sieci wirtualnych

Wiele aplikacji funkcyjnych hostowanych w tym samym planie może również używać tego samego konta magazynowego dla udziału zawartości Azure Files zdefiniowanego przez WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Po zabezpieczeniu tego konta magazynu przy użyciu sieci wirtualnej, wszystkie te aplikacje (w tym sloty) powinny korzystać z tej samej wartości dla vnetContentShareEnabled (dawniej WEBSITE_CONTENTOVERVNET) oraz z tej samej konfiguracji integracji sieci wirtualnej, aby zapewnić, że ruch będzie kierowany zgodnie z zamierzeniami przez docelową sieć wirtualną. Niezgodność tego ustawienia między aplikacjami korzystającymi z tego samego konta magazynowego Azure Files może spowodować trasowanie ruchu za pośrednictwem sieci publicznych. W tej konfiguracji reguły sieciowe konta magazynu blokują dostęp.

Te vnetContentShareEnabled wytyczne nie mają zastosowania do hostingu Flex Consumption, Dedicated, Container Apps ani Consumption.

Praca z blobami

Kluczowym scenariuszem dla funkcji jest przetwarzanie plików w kontenerze blobów, takich jak przetwarzanie obrazów lub analiza sentymentu. Aby dowiedzieć się więcej, zobacz Process file uploads (Przetwarzanie przekazywania plików).

Wyzwalanie na kontenerze danych blob

Istnieje kilka sposobów uruchamiania kodu funkcji na podstawie zmian w blobach w kontenerze pamięci, jak wskazano na tym diagramie.

Diagram przedstawiający różne opcje wyzwalania funkcji podczas dodawania lub aktualizowania elementów w kontenerze Blob Storage w Azure.

Poniższa tabela pomoże określić, który wyzwalacz funkcji najlepiej pasuje do Twoich potrzeb w zakresie przetwarzania nowych lub zaktualizowanych blobów w kontenerze.

Strategia Wyzwalacz bloba (sondowanie) Wyzwalacz blob (sterowany zdarzeniami) Wyzwalacz kolejki Wyzwalacz usługi Event Grid
Opóźnienie Wysoki (do 10 minut) Niski Średni Niski
Ograniczenia konta magazynowania Nie obsługuje kont typu blob-only¹ ani kont z włączoną hierarchiczną przestrzenią nazw (HNS), takich jak konta magazynu Azure Data Lake Storage Gen2 Nie obsługuje ogólnego przeznaczenia kont v1 Żadne Nie obsługuje ogólnego przeznaczenia kont v1
Typ wyzwalacza Przechowywanie blobów Przechowywanie blobów Queue Storage Siatka zdarzeń
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
Działa z ograniczeniami dostępu przychodzącego Tak Nie. Tak Tak3
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. Pobiera zdarzenia z magazynu blobów z subskrypcji zdarzeń. Wymaga wartości parametru SourceEventGrid. Więcej informacji znajdziesz w Tutorial: Wyzwalanie Azure Functions na kontenerach blob przy użyciu subskrypcji zdarzeń. Nazwa obiektu blob jako ciąg znaków jest ręcznie dodawana do kolejki przechowywania w momencie dodania obiektu blob do kontenera. Wyzwalacz usługi Queue Storage przekazuje tę wartość bezpośrednio 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żywaj, gdy konieczne jest również wyzwolenie funkcji przez zdarzenia inne niż przechowywanie. Aby uzyskać więcej informacji, zobacz Jak pracować z wyzwalaczami i powiązaniami usługi Event Grid w Azure Functions.
  1. Ograniczenie konta tylko dla BLOB dotyczy wyzwalacza Blob opartego na ankietach. Powiązania wejściowe i wyjściowe dla Blob Storage obsługują konta przeznaczone wyłącznie dla obiektów blob.
  2. 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ę.
  3. Ograniczenia dostępu przychodzącego można obejść, ponieważ subskrypcja zdarzeń dostarcza zdarzenia za pośrednictwem zaszyfrowanego kanału w publicznym adresie IP przy użyciu znanej tożsamości użytkownika. Aby uzyskać więcej informacji, zobacz Bezpieczne dostarczanie zdarzeń przy użyciu tożsamości zarządzanych.

Szyfrowanie danych magazynu

Azure Storage szyfruje wszystkie dane na koncie magazynu w spoczynku. Aby uzyskać więcej informacji, zobacz szyfrowanie danych spoczywających w Azure Storage.

Domyślnie dane są szyfrowane przy użyciu kluczy zarządzanych przez Microsoft. Aby uzyskać większą 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 Azure Key Vault, aby usługa Functions mogła uzyskać dostęp do konta magazynu. Aby dowiedzieć się więcej, zobacz Szyfrowanie danych aplikacji w spoczynku przy użyciu kluczy zarządzanych przez klienta.

Rezydencja danych w regionie

Gdy wszystkie dane klientów muszą pozostać w jednym regionie, użyj konta pamięci powiązanej z aplikacją funkcyjną, które ma redundancję w regionie. Używaj też konta redundantnego w regionie z Azure Durable Functions.

Platforma przechowuje inne zarządzane przez platformę dane klientów wyłącznie w obrębie regionu, jeśli aplikacja jest hostowana w usłudze App Service Environment (ASE) z wewnętrznym modułem równoważenia obciążenia. Aby dowiedzieć się więcej, zobacz nadmiarowość stref środowiska ASE.

Zagadnienia dotyczące identyfikatora hosta

Rozważania dotyczące ID hosta w tej sekcji nie dotyczą Flex Consumption. W tym planie hostingowym wartość identyfikatora hosta jest tworzona w taki sposób, by uniknąć tych potencjalnych problemów.

Functions używa wartości ID hosta do jednoznacznej identyfikacji konkretnej aplikacji funkcji w przechowywanych artefaktach. Domyślnie środowisko uruchomieniowe automatycznie generuje ten identyfikator na podstawie nazwy aplikacji funkcji, skróconej do pierwszych 32 znaków. Środowisko uruchomieniowe używa tego identyfikatora podczas przechowywania w połączonym koncie magazynu informacji o korelacji i śledzeniu dla poszczególnych aplikacji. Gdy aplikacje funkcji mają nazwy dłuższe niż 32 znaki, a pierwsze 32 znaki są identyczne, takie przycięcie może skutkować zduplikowanymi wartościami identyfikatora hosta. Gdy dwie aplikacje funkcyjne z identycznymi identyfikatorami hostów używają tego samego konta pamięci, dochodzi do kolizji z ID hosta, ponieważ przechowywane dane nie mogą być jednoznacznie powiązane z odpowiednią aplikacją funkcyjną.

Uwaga

Ten sam rodzaj kolizji ID hosta może wystąpić pomiędzy aplikacją funkcyjną w slocie produkcyjnym a tą samą aplikacją funkcyjną w slocie stagingowym, gdy oba sloty korzystają z tego samego konta pamięci.

W wersji 4.x środowiska wykonawczego Functions rejestrowany jest błąd i host przestaje działać, co skutkuje twardą awarią. Aby uzyskać więcej informacji, zobacz HostID Truncation może powodować kolizje.

Unikanie kolizji identyfikatora hosta

Stosuj następujące strategie, aby uniknąć kolizji z ID hosta:

  • Używaj oddzielnych kont magazynowych, aby każdy kolizujący host zapisywał się na innym koncie.
  • Zmień nazwę jednej z aplikacji funkcyjnych tak, aby jej nazwa była krótsza niż 32 znaki, co zmienia obliczony identyfikator hosta aplikacji i usuwa kolizję.
  • Ustaw jawny identyfikator hosta dla co najmniej jednej zderzającej się aplikacji. Aby uzyskać więcej informacji, zobacz Zastąp identyfikator hosta.

Ważne

Zmiana konta pamięci skojarzonego z istniejącą aplikacją funkcji lub zmiana identyfikatora hosta aplikacji może wpływać na zachowanie istniejących funkcji. Na przykład wyzwalacz pamięci Blob śledzi, czy przetwarza poszczególne bloby, zapisując paragony pod określoną ścieżką ID hosta w pamięci. Gdy identyfikator hosta ulegnie zmianie lub wskażesz nowe konto magazynu, wcześniej przetworzone obiekty blob mogą zostać ponownie przetworzone.

Nadpisanie identyfikatora hosta

Możesz ustawić jawny identyfikator hosta dla swojej aplikacji funkcji w ustawieniach aplikacji za pomocą ustawienia AzureFunctionsWebHost__hostid. Aby uzyskać więcej informacji, zobacz AzureFunctionsWebHost__hostid.

Gdy dochodzi do kolizji między slotami, musisz ustawić konkretny identyfikator hosta dla każdego slotu, w tym dla slotu produkcyjnego. 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.

Tworzenie aplikacji bez 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 planie Elastic Premium lub na Windows w planie rozliczania za użycie, w domyśle tworzony jest udział Azure Files na koncie magazynu. Funkcje mogą wykorzystywać to współdzielenie do funkcji takich jak streaming logów oraz jako współdzielona lokalizacja treści aplikacji. Miejsce wdrożenia zależy od technologii wdrożenia i konfiguracji aplikacji. Na przykład aplikacja używająca zewnętrznego adresu URL pakietu uruchamia swój pakiet z skonfigurowanego URL, zamiast z udostępnionego Azure Files.

Korzystanie z Azure Files wymaga parametry połączenia, który zapisujesz w ustawieniach aplikacji jako .WEBSITE_CONTENTAZUREFILECONNECTIONSTRING Azure Files obecnie nie obsługuje połączeń opartych na tożsamościach. Jeśli Twój scenariusz wymaga, abyś nie przechowywał żadnych sekretów w ustawieniach aplikacji, musisz usunąć zależność aplikacji od Azure Files. Tę zależność można uniknąć, tworząc aplikację bez domyślnej zależności Azure Files.

Uwaga

Powinieneś także rozważyć uruchomienie aplikacji funkcjonalnej w planie Flex Consumption, który zapewnia większą kontrolę nad pakietem wdrożenia, w tym możliwość korzystania z połączeń tożsamości zarządzanych. Aby uzyskać więcej informacji, zobacz Konfigurowanie ustawień wdrażania.

Aby uruchomić aplikację bez udziału plików Azure Files, musisz spełnić następujące wymagania:

Należy również zwrócić uwagę na następujące zagadnienia:

  • Twoja aplikacja nie może opierać się na współdzielonym systemie plików z możliwością zapisu.
  • Edytowanie portalu nie jest obsługiwane.
  • Przesyłanie strumieniowe dzienników w klientach, takich jak portal Azure, domyślnie korzysta z dzienników systemu plików. 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 Azure Files. Utwórz aplikację w jeden z następujących sposobów bez ustawień aplikacji WEBSITE_CONTENTAZUREFILECONNECTIONSTRING i WEBSITE_CONTENTSHARE.

  • Szablony Bicep/ARM: usuń te dwa ustawienia aplikacji z szablonu ARM lub pliku Bicep, a następnie wdroż aplikację, używając zmodyfikowanego szablonu.
  • W portalu Azure wyczyść opcję Dodaj połączenie z usługą Azure Files na karcie Storage podczas tworzenia aplikacji.

Azure Files służy do włączania dynamicznego skalowania w poziomie dla funkcji. Skalowanie może być ograniczone w przypadku uruchamiania aplikacji bez Azure Files w planie Elastic Premium i planach Konsumpcji działających na Windows.

Flex Consumption nie zależy od udostępniania treści Azure Files. Wykorzystuje konfigurowalną pamięć masową wdrożeń Blob i obsługuje połączenia zarządzanych tożsamości. Aby uzyskać więcej informacji, zobacz Konfigurowanie ustawień wdrażania.

Dedykowane aplikacje planowe nie mają domyślnej zależności Azure Files dotyczącej udostępniania treści opisanej w tej sekcji.

Funkcje na Azure Container Apps nie mają domyślnej zależności Azure Files content-share opisanej w tej sekcji.

Instalowanie udziałów plików

Ta funkcjonalność jest dostępna tylko podczas działania na Linuksie.

Możesz zamontować udostępnione Azure Files do swoich aplikacji funkcjonalnych w Linuksie, które pozwalają uzyskać dostęp do istniejących plików, modeli uczenia maszynowego lub dużych plików binarnych w swoich funkcjach. Aby uzyskać wskazówki koncepcyjne dotyczące wyboru między punktami montowania pamięci, powiązaniami i zewnętrznymi bazami danych, zobacz Wybierz strategię dostępu do plików dla Azure Functions.

Flex Consumption obsługuje tylko montowania Azure Files przy użyciu protokołu SMB.

Użyj następującego polecenia, aby zamontować istniejący udział sieciowy w aplikacji funkcji systemu Linux.

az webapp config storage-account add (komenda do dodania konta magazynu w konfiguracji aplikacji webowej)

W tym poleceniu share-name jest nazwą istniejącego udziału Azure Files. custom-id może być dowolnym ciągiem, który jednoznacznie definiuje zasób podczas montowania do aplikacji funkcji. Również, mount-path jest ścieżką, z której uzyskiwany jest 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 Tworzenie aplikacji funkcji Python i zamontowanie udziału Azure Files.

W przypadku usługi Functions on Azure Container Apps skonfiguruj wolumin Azure Files w aplikacji kontenera. Aby uzyskać więcej informacji, zobacz Montowanie pamięci masowej w Azure Container Apps.

Uchwyty do przechowywania nie są obsługiwane w planie Consumption.

Ważne

Aplikacje funkcjonalne, które nadal uruchamiają wycofane z użytku środowisko uruchomieniowe w wersji 3 w systemie Linux w planie konsumpcyjnym, przestaną działać po 30 września 2026 r. Aby uniknąć przerw w działaniu usługi, przeprowadź migrację aplikacji do środowiska uruchomieniowego w wersji 4.

Opcja hostowania aplikacji funkcji w systemie Linux w planie konsumpcyjnym zostanie wycofana 30 września 2028 r. Plan Konsumpcji systemu Linux nie będzie otrzymywał nowych funkcji ani wersji językowych. Aplikacje działające na Windows w planie Zużycie nie mają obecnie wpływu. Przeprowadź migrację aplikacji do planu Flex Consumption przed datą wycofania.

  • Last updated on