Sdílet prostřednictvím


Aspekty úložiště pro službu Azure Functions

Azure Functions při vytváření instance aplikace funkcí vyžaduje účet služby Azure Storage. Vaše aplikace funkcí může používat následující služby úložiště:

Služba úložiště Využití funkcí
Azure Blob Storage Udržování stavu vazeb a funkčních klíčů1
Ve výchozím nastavení se používá pro centra úloh v Durable Functions.
Dá se použít k ukládání kódu aplikace funkcí pro vzdálené sestavení Consumption pro Linux nebo jako součást nasazení adresy URL externího balíčku.
Soubory Azure 2 Sdílená složka použitá k ukládání a spouštění kódu aplikace funkcí v plánu Consumption a plánu Premium.
Azure Queue Storage Ve výchozím nastavení se používá pro centra úloh v Durable Functions. Používá se k selhání a opakovanému zpracování v konkrétních triggerech Azure Functions. Používá se ke sledování objektů triggerem úložiště objektů blob.
Azure Table storage Ve výchozím nastavení se používá pro centra úloh v Durable Functions.

1 Blob Storage je výchozím úložištěm pro klíče funkcí, ale můžete nakonfigurovat alternativní úložiště.

2 Služba Soubory Azure je ve výchozím nastavení nastavená, ale za určitých podmínek můžete vytvořit aplikaci bez služby Azure Files .

Důležitá poznámka

Musíte zvážit následující fakta týkající se účtů úložiště používaných vašimi aplikacemi funkcí:

  • Pokud je vaše aplikace funkcí hostovaná v plánu Consumption nebo v plánu Premium, kód funkce a konfigurační soubory se ukládají v Azure Files v propojeném účtu úložiště. Když odstraníte tento účet úložiště, obsah se odstraní a nedá se obnovit. Další informace najdete v tématu Odstranění účtu úložiště.

  • Důležitá data, jako je kód funkce, přístupové klíče a další důležitá data související se službou, je možné uchovávat v účtu úložiště. Přístup k účtům úložiště používaným aplikacemi funkcí musíte pečlivě spravovat následujícími způsoby:

    • Auditujte a omezte přístup aplikací a uživatelů k účtu úložiště na základě modelu s nejnižšími oprávněními. Oprávnění k účtu úložiště můžou pocházet z akcí dat v přiřazené roli nebo prostřednictvím oprávnění k provedení operace listKeys.

    • Monitorujte jak aktivitu řídicí roviny (například načítání klíčů), tak operace roviny dat (například zápis do objektu blob) v účtu úložiště. Zvažte údržbu protokolů úložiště v jiném umístění než Azure Storage. Další informace najdete v tématu Protokoly úložiště.

Požadavky na účet úložiště

Účty úložiště vytvořené jako součást toku vytvoření aplikace funkcí na webu Azure Portal jsou zaručené, že budou fungovat s novou aplikací funkcí. Pokud se rozhodnete použít existující účet úložiště, uvedený seznam neobsahuje některé nepodporované účty úložiště. Následující omezení platí pro účty úložiště používané vaší aplikací funkcí, takže musíte zajistit, aby stávající účet úložiště splňoval tyto požadavky:

  • Typ účtu musí podporovat službu Blob, Queue a Table Storage. Některé účty úložiště nepodporují fronty a tabulky. Mezi tyto účty patří účty úložiště jen pro objekty blob a Azure Premium Storage. Další informace o typech účtů úložiště najdete v tématu Přehled účtu úložiště.

  • Účet úložiště zabezpečeného sítí nemůžete použít, když je vaše aplikace funkcí hostovaná v plánu Consumption.

  • Při vytváření aplikace funkcí na portálu můžete zvolit pouze existující účet úložiště ve stejné oblasti jako aplikace funkcí, kterou vytváříte. Jedná se o optimalizaci výkonu, nikoli striktní omezení. Další informace najdete v tématu Umístění účtu úložiště.

  • Při vytváření aplikace funkcí v plánu s povolenou podporou zóny dostupnosti se podporují jenom účty zónově redundantního úložiště.

Při použití automatizace nasazení k vytvoření aplikace funkcí s účtem úložiště zabezpečeného sítí musíte do šablony ARM nebo souboru Bicep zahrnout konkrétní síťové konfigurace. Pokud tato nastavení a prostředky nezahrnete, automatické nasazení může selhat při ověřování. Konkrétnější pokyny k ARM a Bicep najdete v tématu Zabezpečená nasazení. Přehled konfigurace účtů úložiště se sítěmi najdete v tématu Použití zabezpečeného účtu úložiště se službou Azure Functions.

Pokyny k účtu úložiště

Každá aplikace funkcí vyžaduje, aby fungoval účet úložiště. Když se tento účet odstraní, aplikace funkcí se nespustí. Informace o řešení potíží souvisejících s úložištěm najdete v tématu Řešení potíží souvisejících s úložištěm. Následující další aspekty platí pro účet úložiště používaný aplikacemi funkcí.

Umístění účtu úložiště

Pro zajištění nejlepšího výkonu by vaše aplikace funkcí měla používat účet úložiště ve stejné oblasti, což snižuje latenci. Azure Portal vynucuje tento osvědčený postup. Pokud z nějakého důvodu potřebujete použít účet úložiště v jiné oblasti než vaše aplikace funkcí, musíte aplikaci funkcí vytvořit mimo portál.

Účet úložiště musí být přístupný pro aplikaci funkcí. Pokud potřebujete použít zabezpečený účet úložiště, zvažte omezení účtu úložiště na virtuální síť.

Nastavení připojení k účtu úložiště

Aplikace funkcí standardně konfigurují AzureWebJobsStorage připojení jako připojovací řetězec uložené v nastavení aplikace AzureWebJobsStorage, ale můžete také nakonfigurovat AzureWebJobsStorage tak, aby používala připojení založené na identitě bez tajného kódu.

Aplikace funkcí spuštěné v plánu Consumption (jenom Windows) nebo v plánu Elastic Premium (Windows nebo Linux) můžou pomocí služby Azure Files ukládat image potřebné k povolení dynamického škálování. Pro tyto plány nastavte připojovací řetězec pro účet úložiště v nastavení WEBSITE_CONTENTAZUREFILECONNECTIONSTRING a název sdílené složky v nastavení WEBSITE_CONTENTSHARE. To je obvykle stejný účet, který se používá pro AzureWebJobsStorage. Můžete také vytvořit aplikaci funkcí, která nepoužívá Azure Files, ale škálování může být omezené.

Poznámka:

Účet úložiště připojovací řetězec se musí aktualizovat, když znovu vygenerujete klíče úložiště. Další informace o správě klíčů úložiště najdete tady.

Sdílené účty úložiště

Je možné, že několik aplikací funkcí bude sdílet stejný účet úložiště bez jakýchkoli problémů. V sadě Visual Studio můžete například vyvíjet více aplikací pomocí emulátoru úložiště Azurite. V tomto případě emulátor funguje jako jeden účet úložiště. Stejný účet úložiště, který používá vaše aplikace funkcí, můžete také použít k ukládání dat aplikace. Tento přístup ale není vždy vhodný v produkčním prostředí.

Možná budete muset použít samostatné účty úložiště, abyste se vyhnuli kolizím ID hostitele.

Aspekty zásad správy životního cyklu

Zásady správy životního cyklu byste neměli používat u účtu Blob Storage používaného vaší aplikací funkcí. Služba Functions používá úložiště objektů blob k zachování důležitých informací, jako jsou přístupové klíče funkce, a zásady můžou odebrat objekty blob (například klíče) potřebné hostitelem služby Functions. Pokud musíte použít zásady, vylučte kontejnery používané funkcí, které mají předponu azure-webjobs nebo scm.

Protokoly úložiště

Vzhledem k tomu, že kód funkce a klíče můžou být v účtu úložiště trvalé, je protokolování aktivity vůči účtu úložiště dobrým způsobem, jak monitorovat neoprávněný přístup. Protokoly prostředků služby Azure Monitor je možné použít ke sledování událostí v rovině dat úložiště. Podrobnosti o konfiguraci a prozkoumání těchto protokolů najdete v tématu Monitorování služby Azure Storage .

Protokol aktivit služby Azure Monitor zobrazuje události roviny řízení, včetně operace listKeys. Měli byste ale také nakonfigurovat protokoly prostředků pro účet úložiště, abyste mohli sledovat následné použití klíčů nebo jiných operací roviny dat založených na identitách. Měli byste mít alespoň povolenou kategorii protokolu StorageWrite, abyste mohli identifikovat změny dat mimo normální operace funkcí.

Pokud chcete omezit potenciální dopad všech obecně vymezených oprávnění k úložišti, zvažte použití nestorageového cíle pro tyto protokoly, například Log Analytics. Další informace najdete v tématu Monitorování služby Azure Blob Storage.

Optimalizace výkonu úložiště

Pokud chcete maximalizovat výkon, použijte pro každou aplikaci funkcí samostatný účet úložiště. To je zvlášť důležité, pokud máte funkce aktivované Durable Functions nebo centra událostí, které generují velký objem transakcí úložiště. Pokud logika aplikace komunikuje se službou Azure Storage, ať už přímo (pomocí sady SDK služby Storage), nebo prostřednictvím některé z vazeb úložiště, měli byste použít vyhrazený účet úložiště. Pokud máte například funkci aktivovanou centrem událostí, která zapisuje některá data do úložiště objektů blob, použijte dva účty úložiště – jeden pro aplikaci funkcí a druhý pro objekty blob, které funkce ukládá.

Konzistentní směrování prostřednictvím virtuálních sítí

Více aplikací funkcí hostovaných ve stejném plánu může také použít stejný účet úložiště pro sdílenou složku obsahu Azure Files (definovanou ).WEBSITE_CONTENTAZUREFILECONNECTIONSTRING Pokud je tento účet úložiště také zabezpečen virtuální sítí, měly by všechny tyto aplikace také používat stejnou hodnotu , vnetContentShareEnabled WEBSITE_CONTENTOVERVNETaby se zajistilo, že se provoz bude směrovat konzistentně přes zamýšlenou virtuální síť. Neshoda v tomto nastavení mezi aplikacemi používajícími stejný účet úložiště Azure Files může vést k tomu, že se provoz směruje přes veřejné sítě, což způsobí zablokování přístupu pravidly sítě účtu úložiště.

Práce s objekty blob

Klíčovým scénářem služby Functions je zpracování souborů v kontejneru objektů blob, jako je zpracování obrázků nebo analýza mínění. Další informace najdete v tématu Zpracování nahrávání souborů.

Aktivace v kontejneru objektů blob

Poznámka:

Plán Flex Consumption podporuje pouze trigger úložiště objektů blob založený na událostech.

Kód funkce můžete spustit několika způsoby na základě změn objektů blob v kontejneru úložiště. Pomocí následující tabulky určete, která aktivační událost funkce nejlépe vyhovuje vašim potřebám:

Situace Blob Storage (dotazování) Blob Storage (založené na událostech) Queue Storage Event Grid
Latence Vysoká (až 10 minut) Nízká Střední Nízká
Omezení účtu úložiště Účty pouze pro objekty blob se nepodporují¹ Obecné účely verze 1 nejsou podporovány. Žádná Obecné účely verze 1 nejsou podporovány.
Verze rozšíření Všechny Storage v5.x+ Všechny Všechny
Zpracovává existující objekty blob. Yes No No Ne
Filtry Vzor názvu objektu blob Filtry událostí Není k dispozici Filtry událostí
Vyžaduje odběr události. No Ano Ne Ano
Podporuje high-scale² No Ano Ano Yes
Popis Výchozí chování triggeru, které spoléhá na dotazování kontejneru na aktualizace. Další informace najdete v příkladech v referenčních informacích k triggeru úložiště objektů blob. Využívá události úložiště objektů blob z odběru událostí. Vyžaduje hodnotu parametru Source EventGrid. Další informace najdete v tématu Kurz: Aktivace Azure Functions v kontejnerech objektů blob pomocí odběru událostí. Řetězec názvu objektu blob se při přidání objektu blob do kontejneru ručně přidá do fronty úložiště. Tato hodnota se předává přímo triggerem Queue Storage vstupní vazbě úložiště objektů blob ve stejné funkci. Poskytuje flexibilitu aktivace událostí kromě událostí pocházejících z kontejneru úložiště. Tuto funkci můžete aktivovat také v případě, že potřebujete mít události, které nestorage aktivují vaši funkci. Další informace najdete v tématu Práce s triggery a vazbami Event Gridu ve službě Azure Functions.

1 Vstupní a výstupní vazby úložiště objektů blob podporují účty jen pro objekty blob.
2 Vysoké škálování je možné volně definovat jako kontejnery, které mají více než 100 000 objektů blob nebo účty úložiště, které mají více než 100 aktualizací objektů blob za sekundu.

Šifrování dat úložiště

Azure Storage šifruje všechna neaktivní uložená data v účtu úložiště. Další informace najdete v tématu Šifrování služby Azure Storage pro neaktivní uložená data.

Ve výchozím nastavení se data šifrují pomocí klíčů spravovaných Microsoftem. Pro další kontrolu nad šifrovacími klíči můžete zadat klíče spravované zákazníkem, které se použijí k šifrování dat objektů blob a souborů. Tyto klíče musí být k dispozici ve službě Azure Key Vault, aby služba Functions mohla získat přístup k účtu úložiště. Další informace najdete v tématu Šifrování neaktivních uložených dat pomocí klíčů spravovaných zákazníkem.

Rezidenci dat v oblasti

Pokud všechna zákaznická data musí zůstat v jedné oblasti, musí být účet úložiště přidružený k aplikaci funkcí jeden s redundancí v oblasti. Účet redundantního úložiště v oblasti musí být také použit se službou Azure Durable Functions.

Jiná zákaznická data spravovaná platformou se ukládají pouze v rámci oblasti při hostování v prostředí App Service Environment s interním vyrovnáváním zatížení (ASE). Další informace najdete v tématu Redundance zón ASE.

Důležité informace o ID hostitele

Funkce používá hodnotu ID hostitele jako způsob, jak jedinečně identifikovat konkrétní aplikaci funkcí v uložených artefaktech. Ve výchozím nastavení se toto ID automaticky vygeneruje z názvu aplikace funkcí a zkrátí se na prvních 32 znaků. Toto ID se pak použije při ukládání informací o korelaci a sledování jednotlivých aplikací v propojeném účtu úložiště. Pokud máte aplikace funkcí s názvy delšími než 32 znaky a pokud jsou prvních 32 znaků identické, může toto zkrácení vést k duplicitním hodnotám ID hostitele. Pokud dvě aplikace funkcí s identickými ID hostitelů používají stejný účet úložiště, získáte kolize ID hostitele, protože uložená data nemohou být jedinečně propojená se správnou aplikací funkcí.

Poznámka:

Stejný druh kolaison ID hostitele může nastat mezi aplikací funkcí v produkčním slotu a stejnou aplikací funkcí v přípravném slotu, když oba sloty používají stejný účet úložiště.

Počínaje modulem runtime služby Functions verze 3.x se zjistí kolize ID hostitele a zaprotokoluje se upozornění. Ve verzi 4.x se zaprotokoluje chyba a hostitel se zastaví, což vede k pevnému selhání. Další podrobnosti o kolizi ID hostitele najdete v tomto problému.

Předcházení kolizím ID hostitele

Pomocí následujících strategií se můžete vyhnout kolizím ID hostitele:

  • Pro každou aplikaci funkcí nebo slot zapojené do kolize použijte samostatný účet úložiště.
  • Přejmenujte jednu z aplikací funkcí na hodnotu kratší než 32 znaků, čímž se změní ID vypočítaného hostitele aplikace a odebere kolize.
  • Nastavte explicitní ID hostitele pro jednu nebo více kolísajících aplikací. Další informace najdete v tématu Přepsání ID hostitele.

Důležité

Změna účtu úložiště přidruženého k existující aplikaci funkcí nebo změna ID hostitele aplikace může mít vliv na chování existujících funkcí. Trigger služby Blob Storage například sleduje, jestli se zpracovávají jednotlivé objekty blob tím, že zapisují účtenky pod konkrétní cestou ID hostitele v úložišti. Když se ID hostitele změní nebo nasměrujete na nový účet úložiště, dříve zpracované objekty blob je možné znovu zpracovat.

Přepsání ID hostitele

Pomocí nastavení můžete explicitně nastavit konkrétní ID hostitele pro vaši aplikaci funkcí v nastavení AzureFunctionsWebHost__hostid aplikace. Další informace najdete v tématu AzureFunctionsWebHost__hostid.

Když dojde ke kolizi mezi sloty, musíte pro každý slot nastavit konkrétní ID hostitele, včetně produkčního slotu. Tato nastavení musíte také označit jako nastavení nasazení, aby se neprohodila. Informace o vytváření nastavení aplikace najdete v tématu Práce s nastavením aplikace.

Clustery s podporou Azure Arc

Když je vaše aplikace funkcí nasazená do clusteru Kubernetes s podporou Azure Arc, nemusí vaše aplikace funkcí vyžadovat účet úložiště. V takovém případě služba Functions vyžaduje účet úložiště jenom v případě, že vaše aplikace funkcí používá trigger, který vyžaduje úložiště. Následující tabulka uvádí, které triggery můžou vyžadovat účet úložiště a které ne.

Nepovinné může vyžadovat úložiště
Azure Cosmos DB
HTTP
Kafka
RabbitMQ
Service Bus
Azure SQL
Blob Storage
Event Grid
Event Hubs
IoT Hub
Queue Storage
SendGrid
SignalR
Table Storage
Časovač
Twilio

Pokud chcete vytvořit aplikaci funkcí v clusteru Kubernetes s podporou Azure Arc bez úložiště, musíte použít příkaz Azure CLI az functionapp create. Verze Azure CLI musí obsahovat verzi 0.1.7 nebo novější verzi rozšíření appservice-kube. az --version Pomocí příkazu ověřte, že je rozšíření nainstalované a zda je správné verze.

Vytvoření prostředků aplikace funkcí pomocí jiných metod než Azure CLI vyžaduje existující účet úložiště. Pokud plánujete používat všechny triggery, které vyžadují účet úložiště, měli byste ho vytvořit před vytvořením aplikace funkcí.

Vytvoření aplikace bez služby Azure Files

Služba Soubory Azure poskytuje sdílený systém souborů, který podporuje scénáře ve velkém měřítku. Když vaše aplikace funkcí běží ve Windows v plánu Elastic Premium nebo Consumption, ve výchozím nastavení se ve vašem účtu úložiště vytvoří sdílená složka Azure Files. Tuto sdílenou složku používá služba Functions k povolení určitých funkcí, jako je streamování protokolů. Používá se také jako umístění pro nasazení sdíleného balíčku, které zaručuje konzistenci nasazeného kódu funkce ve všech instancích.

Aplikace funkcí hostované v plánech Premium a Consumption ve výchozím nastavení používají nasazení zip s balíčky nasazení uloženými v této sdílené složce Azure. Tato část je relevantní pouze pro tyto plány hostování.

Použití služby Azure Files vyžaduje použití připojovací řetězec, který je uložený v nastavení aplikace jako WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Služba Azure Files v současné době nepodporuje připojení založená na identitách. Pokud váš scénář vyžaduje, abyste v nastavení aplikace neukládali žádné tajné kódy, musíte odebrat závislost vaší aplikace na službě Azure Files. Můžete to udělat tak, že vytvoříte aplikaci bez výchozí závislosti služby Azure Files.

Poznámka:

Měli byste také zvážit spuštění ve své aplikaci funkcí v plánu Flex Consumption, který je aktuálně ve verzi Preview. Plán Flex Consumption poskytuje větší kontrolu nad balíčkem nasazení, včetně možnosti používat připojení spravovaných identit. Další informace naleznete v tématu Konfigurace nastavení nasazení v článku Flex Consumption.

Pokud chcete aplikaci spustit bez sdílené složky Azure, musíte splnit následující požadavky:

Zodpovídáte za ruční aktualizaci balíčku nasazení a údržbu adresy URL balíčku pro nasazení, která pravděpodobně obsahuje sdílený přístupový podpis (SAS).

  • Vaše aplikace se nemůže spoléhat na sdílený zapisovatelný systém souborů.
  • Aplikace nemůže použít verzi 1.x modulu runtime functions.
  • Prostředí streamování protokolů v klientech, jako je azure Portal, ve výchozím nastavení používají protokoly systému souborů. Místo toho byste měli spoléhat na protokoly Application Insights.

Pokud výše uvedené požadavky vyhovují vašemu scénáři, můžete pokračovat vytvořením aplikace funkcí bez služby Azure Files. Můžete to udělat tak, že vytvoříte aplikaci bez WEBSITE_CONTENTAZUREFILECONNECTIONSTRING nastavení aplikace a WEBSITE_CONTENTSHARE aplikace. Začněte tak, že vygenerujete šablonu ARM pro standardní nasazení, odeberete dvě nastavení a pak nasadíte upravenou šablonu.

Vzhledem k tomu, že se služba Azure Files používá k povolení dynamického horizontálního navýšení kapacity pro funkce, může být škálování omezené při spouštění aplikace bez služby Azure Files v plánu Elastic Premium a plánů Consumption běžících ve Windows.

Připojení sdílených složek

Tato funkce je aktuálně dostupná jenom v případě, že běží v Linuxu.

Existující sdílené složky Azure Files můžete připojit k aplikacím funkcí Linuxu. Připojením sdílené složky k aplikaci funkcí pro Linux můžete ve svých funkcích použít existující modely strojového učení nebo jiná data. Pomocí následujícího příkazu můžete připojit existující sdílenou složku k aplikaci funkcí Pro Linux.

az webapp config storage-account add

V tomto příkazu share-name je název existující sdílené složky Azure Files a custom-id může to být libovolný řetězec, který jednoznačně definuje sdílenou složku při připojení k aplikaci funkcí. Je to také cesta, mount-path ze které se sdílená složka přistupuje ve vaší aplikaci funkcí. mount-path musí být ve formátu /dir-namea nemůže začínat na /home.

Úplný příklad najdete ve skriptech v tématu Vytvoření aplikace funkcí Pythonu a připojení sdílené složky Azure Files.

V současné době se podporuje jenom storage-type část.AzureFiles K dané aplikaci funkcí můžete připojit pouze pět sdílených složek. Připojení sdílené složky může zvýšit dobu studeného spuštění alespoň o 200–300 ms nebo i více, pokud je účet úložiště v jiné oblasti.

Připojená sdílená složka je dostupná pro váš kód funkce v zadaném mount-path umístění. Pokud je /path/to/mountto například , mount-path můžete získat přístup k cílovému adresáři pomocí rozhraní API systému souborů, jako v následujícím příkladu Pythonu:

import os
...

files_in_share = os.listdir("/path/to/mount")

Další kroky

Přečtěte si další informace o možnostech hostování azure Functions.