Práce se staršími proxy servery
Důležité
Proxy služby Azure Functions je starší funkce pro verze 1.x až 3.x modulu runtime Azure Functions. Podporu proxy serverů je možné znovu povolit ve verzi 4.x, abyste mohli úspěšně upgradovat aplikace funkcí na nejnovější verzi modulu runtime. Co nejdříve byste měli přejít na integraci aplikací funkcí se službou Azure API Management. API Management vám umožní využívat ucelenější sadu funkcí pro definování, zabezpečení, správu a monetizaci vašich rozhraní API založených na službě Functions. Další informace najdete v tématu Integrace služby API Management.
Informace o opětovném povolení podpory proxy serverů ve službě Functions verze 4.x najdete v tématu Opětovné povolení proxy serverů ve službě Functions v4.x.
Tento článek odkazuje na ekvivalentní obsah služby API Management, který je k dispozici, a usnadňuje tak migraci ze stávajících implemetací proxy serveru.
Tento článek vysvětluje, jak nakonfigurovat proxy služby Azure Functions a pracovat s jejich pomocí. Pomocí této funkce můžete zadat koncové body ve vaší aplikaci funkcí, které jsou implementované jiným prostředkem. Tyto proxy servery můžete použít k rozdělení velkého rozhraní API do více aplikací funkcí (jako v architektuře mikroslužeb) a současně prezentovat jednu plochu rozhraní API pro klienty.
Fakturace standardních funkcí se vztahuje na spouštění proxy serveru. Další informace najdete v tématu Ceny služby Azure Functions.
Opětovné povolení proxy serverů ve službě Functions v4.x
Po migraci aplikace funkcí na verzi 4.x modulu runtime Functions budete muset konkrétně znovu použít proxy servery. Přesto byste měli co nejdříve přepnout na integraci aplikací funkcí se službou Azure API Management a nespoléhejte jenom na proxy servery.
Opětovné povolení proxy vyžaduje, abyste v AzureWebJobsFeatureFlags
nastavení aplikace nastavili příznak jedním z následujících způsobů:
AzureWebJobsFeatureFlags
Pokud nastavení ještě neexistuje, přidejte toto nastavení do aplikace funkcí s hodnotouEnableProxies
.Pokud toto nastavení již existuje, přidejte
,EnableProxies
na konec existující hodnoty.
AzureWebJobsFeatureFlags
je pole příznaků oddělených čárkami, které slouží k povolení náhledu a dalších dočasných funkcí. Další informace o tom, jak vytvořit a upravit nastavení aplikace, najdete v tématu Práce s nastavením aplikace.
Poznámka:
I v případě opětovného povolení pomocí příznaku EnableProxies
nemůžete pracovat s proxy servery na webu Azure Portal. Místo toho musíte pracovat přímo se souborem proxies.json pro vaši aplikaci funkcí. Další informace naleznete v tématu Rozšířená konfigurace.
Vytvoření proxy serveru
Důležité
Ekvivalentní obsah pomocí služby API Management najdete v tématu Zveřejnění bezserverových rozhraní API z koncových bodů HTTP pomocí služby Azure API Management.
Proxy servery jsou definované v souboru proxies.json v kořenovém adresáři vaší aplikace funkcí. Kroky v této části ukazují, jak pomocí webu Azure Portal vytvořit tento soubor v aplikaci funkcí. Ne všechny jazyky a kombinace operačního systému podporují úpravy na portálu. Pokud nemůžete upravovat soubory aplikace funkcí na portálu, můžete místo toho vytvořit a nasadit ekvivalentní proxies.json
soubor z kořenové složky místního projektu. Další informace o podpoře úprav portálu najdete v podrobnostech podpory jazyků.
- Otevřete web Azure Portal a přejděte do aplikace funkcí.
- V levém podokně vyberte Proxy servery a pak vyberte +Přidat.
- Zadejte název proxy serveru.
- Nakonfigurujte koncový bod, který je vystavený v této aplikaci funkcí, zadáním šablony trasy a metod HTTP. Tyto parametry se chovají podle pravidel pro triggery HTTP.
- Nastavte adresu URL back-endu na jiný koncový bod. Tento koncový bod může být funkcí v jiné aplikaci funkcí nebo může to být jakékoli jiné rozhraní API. Hodnota nemusí být statická a může odkazovat na nastavení a parametry aplikace z původního požadavku klienta.
- Vyberte Vytvořit.
Váš proxy server teď ve vaší aplikaci funkcí existuje jako nový koncový bod. Z hlediska klienta je to stejné jako HttpTrigger ve funkcích. Nový proxy server si můžete vyzkoušet tak, že zkopírujete adresu URL proxy serveru a otestujete ji s vaším oblíbeným klientem HTTP.
Úprava požadavků a odpovědí
Důležité
Služba API Management umožňuje změnit chování rozhraní API prostřednictvím konfigurace pomocí zásad. Zásady představují kolekci příkazů, které se postupně provádí na základě požadavku nebo odezvy z rozhraní API. Další informace o zásadách služby API Management najdete v tématu Zásady ve službě Azure API Management.
Pomocí proxy serverů můžete upravit požadavky na back-end a odpovědi z back-endu. Tyto transformace můžou používat proměnné definované v proměnných Použít.
Úprava back-endového požadavku
Ve výchozím nastavení se back-endový požadavek inicializuje jako kopie původního požadavku. Kromě nastavení back-endové adresy URL můžete provádět změny parametrů metody HTTP, hlaviček a řetězce dotazu. Změněné hodnoty mohou odkazovat na nastavení a parametry aplikace z původního požadavku klienta.
Back-endové požadavky lze na portálu upravit tak, že rozbalíte část přepsání požadavku na stránce podrobností proxy serveru.
Úprava odpovědi
Ve výchozím nastavení se odpověď klienta inicializuje jako kopie back-endové odpovědi. Můžete provádět změny stavového kódu odpovědi, fráze důvodu, záhlaví a textu odpovědi. Upravené hodnoty můžou odkazovat na nastavení aplikace, parametry z původního požadavku klienta a parametry z back-endové odpovědi.
Back-endové odpovědi lze na portálu upravit tak, že rozbalíte část přepsání odpovědi na stránce podrobností proxy serveru.
Použití proměnných
Konfigurace proxy serveru nemusí být statická. Můžete ji podmínit tak, aby používala proměnné z původního požadavku klienta, odpovědi back-endu nebo nastavení aplikace.
Odkaz na místní funkce
Můžete použít localhost
odkaz na funkci uvnitř stejné aplikace funkcí přímo bez požadavku proxy zaokrouhlení.
"backendUri": "https://localhost/api/httptriggerC#1"
bude odkazovat na místní funkci aktivovanou protokolem HTTP na trase. /api/httptriggerC#1
Poznámka:
Pokud vaše funkce používá úroveň autorizace funkce, správce nebo sys , budete muset zadat kód a ID klienta podle původní adresy URL funkce. V tomto případě by odkaz vypadal takto: "backendUri": "https://localhost/api/httptriggerC#1?code=<keyvalue>&clientId=<keyname>"
Doporučujeme uložit tyto klíče v nastavení aplikace a odkazovat na klíče ve vašich proxy serverech. Tím se zabrání ukládání tajných kódů do zdrojového kódu.
Referenční parametry požadavku
Parametry požadavku můžete použít jako vstupy do vlastnosti adresy URL back-endu nebo jako součást úprav požadavků a odpovědí. Některé parametry můžou být vázané ze šablony trasy zadané v konfiguraci základního proxy serveru a jiné můžou pocházet z vlastností příchozího požadavku.
Parametry šablony trasy
Na parametry, které se používají v šabloně trasy, se dají odkazovat podle názvu. Názvy parametrů jsou uzavřeny ve složených závorkách ({}).
Pokud má proxy například šablonu trasy, například /pets/{petId}
back-endovou adresu URL může obsahovat hodnotu {petId}
, jako je například .https://<AnotherApp>.azurewebsites.net/api/pets/{petId}
Pokud se šablona trasy ukončí v zástupné znaky, například /api/{*restOfPath}
, je hodnota {restOfPath}
řetězcové vyjádření zbývajících segmentů cesty z příchozího požadavku.
Další parametry požadavku
Kromě parametrů šablony trasy je možné v konfiguračních hodnotách použít následující hodnoty:
- {request.method}: Metoda HTTP použitá v původním požadavku.
- {request.headers.<HeaderName>}: Hlavička, která se dá přečíst z původního požadavku. Nahraďte <HeaderName> názvem záhlaví, které chcete přečíst. Pokud hlavička není součástí požadavku, hodnota bude prázdný řetězec.
- {request.querystring.<ParameterName>}: Parametr řetězce dotazu, který lze číst z původního požadavku. Nahraďte <ParameterName> názvem parametru, který chcete přečíst. Pokud parametr není součástí požadavku, hodnota bude prázdný řetězec.
Referenční parametry odpovědi back-endu
Parametry odpovědi lze použít jako součást úpravy odpovědi na klienta. V konfiguračních hodnotách je možné použít následující hodnoty:
- {backend.response.statusCode}: Stavový kód HTTP vrácený v odpovědi back-endu.
- {backend.response.statusReason}: Fráze důvodu HTTP vrácená v odpovědi back-endu.
- {backend.response.headers.<HeaderName>}: Hlavička, která se dá přečíst z back-endové odpovědi. Nahraďte <HeaderName> názvem záhlaví, které chcete přečíst. Pokud hlavička není součástí odpovědi, hodnota bude prázdný řetězec.
Referenční nastavení aplikace
Můžete také odkazovat na nastavení aplikace definované pro aplikaci funkcí tak, že název nastavení uzavřete pod znaménka procent (%).
Adresa URL back-endu https://%ORDER_PROCESSING_HOST%/api/orders by například nahradila %ORDER_PROCESSING_HOST% hodnotou nastavení ORDER_PROCESSING_HOST.
Tip
Nastavení aplikace pro back-endové hostitele použijte, pokud máte více nasazení nebo testovacích prostředí. Tímto způsobem se můžete ujistit, že vždy mluvíte se správným back-endem pro dané prostředí.
Řešení potíží s proxy servery
Přidáním příznaku "debug":true
do libovolného proxy serveru ve vašem proxies.json
prostředí povolíte protokolování ladění. Protokoly se ukládají a D:\home\LogFiles\Application\Proxies\DetailedTrace
jsou přístupné prostřednictvím pokročilých nástrojů (kudu). Všechny odpovědi HTTP budou také obsahovat hlavičku Proxy-Trace-Location
s adresou URL pro přístup k souboru protokolu.
Proxy server můžete z klienta ladit přidáním hlavičky Proxy-Trace-Enabled
nastavené na true
. Tím se také zapíše trasování do systému souborů a vrátí adresu URL trasování jako hlavičku v odpovědi.
Blokování trasování proxy serveru
Z bezpečnostních důvodů možná nebudete chtít povolit, aby někdo, kdo volá vaši službu, vygeneroval trasování. Nebudou mít přístup k obsahu trasování bez přihlašovacích údajů, ale generování trasování spotřebovává prostředky a zveřejňuje, že používáte proxy funkcí.
Zakažte trasování úplně přidáním "debug":false
do libovolného konkrétního proxy serveru ve vašem proxies.json
.
Rozšířená konfigurace
Proxy servery, které nakonfigurujete, se ukládají do souboru proxies.json , který se nachází v kořenovém adresáři aplikace funkcí. Tento soubor můžete ručně upravit a nasadit ho jako součást aplikace, když použijete některou z metod nasazení, které Functions podporuje.
Tip
Pokud jste nenastavili některou z metod nasazení, můžete také pracovat se souborem proxies.json na portálu. Přejděte do aplikace funkcí, vyberte Funkce platformy a pak vyberte Editor služby App Service. Uděláte to tak, že zobrazíte celou strukturu souborů aplikace funkcí a pak provedete změny.
Proxies.json je definován objektem proxy, který se skládá z pojmenovaných proxy serverů a jejich definic. Pokud ho váš editor podporuje, můžete pro dokončení kódu odkazovat na schéma JSON. Ukázkový soubor může vypadat takto:
{
"$schema": "http://json.schemastore.org/proxies",
"proxies": {
"proxy1": {
"matchCondition": {
"methods": [ "GET" ],
"route": "/api/{test}"
},
"backendUri": "https://<AnotherApp>.azurewebsites.net/api/<FunctionName>"
}
}
}
Každý proxy server má popisný název, například proxy1 v předchozím příkladu. Odpovídající objekt definice proxy serveru je definován následujícími vlastnostmi:
- matchCondition: Povinný objekt – objekt definující požadavky, které aktivují spuštění tohoto proxy serveru. Obsahuje dvě vlastnosti sdílené s triggery HTTP:
- metody: Pole metod HTTP, na které proxy reaguje. Pokud není zadaný, proxy reaguje na všechny metody HTTP na trase.
- route: Povinné – definuje šablonu trasy, která určuje adresy URL požadavků, na které proxy server reaguje. Na rozdíl od triggerů HTTP neexistuje žádná výchozí hodnota.
- back-endUri: Adresa URL back-endového prostředku, na který má být požadavekxiován. Tato hodnota může odkazovat na nastavení a parametry aplikace z původního požadavku klienta. Pokud tato vlastnost není zahrnutá, Služba Azure Functions odpoví v pořádku HTTP 200.
- requestOverrides: Objekt, který definuje transformace na back-endový požadavek. Viz Definice objektu requestOverrides.
- responseOverrides: Objekt, který definuje transformace na odpověď klienta. Viz Definice objektu responseOverrides.
Poznámka:
Vlastnost route v proxy serverech Azure Functions neresplňuje vlastnost routePrefix konfigurace hostitele aplikace funkcí. Pokud chcete zahrnout předponu, například /api
, musí být zahrnuta do vlastnosti trasy .
Zakázání jednotlivých proxy serverů
Jednotlivé proxy servery můžete zakázat tak, že do souboru přidáte "disabled": true
proxy proxies.json
server. To způsobí, že všechny žádosti o schůzku matchCondition vrátí hodnotu 404.
{
"$schema": "http://json.schemastore.org/proxies",
"proxies": {
"Root": {
"disabled":true,
"matchCondition": {
"route": "/example"
},
"backendUri": "https://<AnotherApp>.azurewebsites.net/api/<FunctionName>"
}
}
}
Nastavení aplikace
Chování proxy serveru může být řízeno několika nastaveními aplikace. Všechny jsou uvedené v referenčním Nastavení aplikace Functions.
Rezervované znaky (formátování řetězců)
Proxy servery čtou všechny řetězce ze souboru JSON pomocí \ jako řídicího symbolu. Proxy servery také interpretují složené závorky. Podívejte se na úplnou sadu příkladů níže.
Znak | Řídicí znak | Příklad |
---|---|---|
{ nebo } | {{ nebo }} | {{ example }} -->{ example } |
\ | \\ | example.com\\text.html -->example.com\text.html |
" | \" | \"example\" -->"example" |
Definování objektu requestOverrides
Objekt requestOverrides definuje změny provedené v požadavku při zavolání back-endového prostředku. Objekt je definován následujícími vlastnostmi:
- backend.request.method: Metoda HTTP, která se používá k volání back-endu.
- backend.request.querystring.<ParameterName>: Parametr řetězce dotazu, který lze nastavit pro volání back-endu. Parametr ParameterName> nahraďte <názvem parametru, který chcete nastavit. Pokud je zadaný prázdný řetězec, parametr je stále součástí back-endového požadavku.
- backend.request.headers.<HeaderName>: Hlavička, která se dá nastavit pro volání back-endu. Nahraďte <HeaderName> názvem záhlaví, které chcete nastavit. Pokud je zadaný prázdný řetězec, parametr je stále součástí back-endového požadavku.
Hodnoty můžou odkazovat na nastavení a parametry aplikace z původního požadavku klienta.
Příklad konfigurace může vypadat takto:
{
"$schema": "http://json.schemastore.org/proxies",
"proxies": {
"proxy1": {
"matchCondition": {
"methods": [ "GET" ],
"route": "/api/{test}"
},
"backendUri": "https://<AnotherApp>.azurewebsites.net/api/<FunctionName>",
"requestOverrides": {
"backend.request.headers.Accept": "application/xml",
"backend.request.headers.x-functions-key": "%ANOTHERAPP_API_KEY%"
}
}
}
}
Definování objektu responseOverrides
Objekt requestOverrides definuje změny provedené v odpovědi předané zpět klientovi. Objekt je definován následujícími vlastnostmi:
- response.statusCode: Stavový kód HTTP, který se má vrátit klientovi.
- response.statusReason: Fráze důvodu HTTP, která se má vrátit klientovi.
- response.body: Řetězcová reprezentace těla, která se má vrátit klientovi.
- response.headers.<HeaderName>: Hlavička, která se dá nastavit pro odpověď na klienta. Nahraďte <HeaderName> názvem záhlaví, které chcete nastavit. Pokud zadáte prázdný řetězec, hlavička se do odpovědi nezahrne.
Hodnoty můžou odkazovat na nastavení aplikace, parametry z původního požadavku klienta a parametry z back-endové odpovědi.
Příklad konfigurace může vypadat takto:
{
"$schema": "http://json.schemastore.org/proxies",
"proxies": {
"proxy1": {
"matchCondition": {
"methods": [ "GET" ],
"route": "/api/{test}"
},
"responseOverrides": {
"response.body": "Hello, {test}",
"response.headers.Content-Type": "text/plain"
}
}
}
}
Poznámka:
V tomto příkladu je tělo odpovědi nastaveno přímo, takže není nutná žádná backendUri
vlastnost. Příklad ukazuje, jak můžete použít proxy služby Azure Functions pro napodobování rozhraní API.