Azure İşlev Proxy'leri ile çalışma

Bu makalede, yapılandırma ve çalışma hakkında bilgi Azure İşlev Proxy'leri. Bu özellik sayesinde işlev uygulamanıza başka bir kaynak tarafından uygulanan uç noktalar belirtebilirsiniz. Büyük bir API'yi birden çok işlev uygulamasına (mikro hizmet mimarisinde olduğu gibi) bozmak ve istemciler için tek bir API yüzeyi sunmak için bu ara sunucularını kullanabilirsiniz.

Standart İşlevler faturalaması ara sunucu yürütmeleri için geçerlidir. Daha fazla bilgi için bkz. Azure İşlevleri fiyatlandırması.

Bu, Azure Işlevleri geliştiricileri için başvuru bilgileri. Azure Işlevleri 'ni kullanmaya yeni başladıysanız aşağıdaki kaynaklarla başlayın:

Not

Proxies, 1.x Azure İşlevleri 3.x sürümleriyle kullanılabilir.

Ayrıca, uygulamanız için Azure API Management kullanmayı da göz önünde bulundurabilirsiniz. İşlevLer Aracıları ile aynı özellikleri ve OpenAPI tümleştirmesi, hız sınırlaması ve gelişmiş ilkeler gibi API'leri oluşturmak ve korumak için diğer araçları sağlar.

Ara sunucu oluşturma

Bu bölümde, İşlevler portalında nasıl ara sunucu oluşturabilirsiniz?

  1. uygulamasını [Azure portal]ve ardından işlev uygulamanıza gidin.
  2. Sol bölmede Yeni ara sunucu'ya tıklayın.
  3. Ara sunucu için bir ad girin.
  4. Yol şablonunu ve HTTP yöntemlerini belirterek bu işlev uygulamasında ortaya çıkarılan uç noktayı yapılandırma. Bu parametreler HTTP tetikleyicileri [kurallarına göre davranır.]
  5. Arka uç URL'sini başka bir uç nokta olarak ayarlayın. Bu uç nokta başka bir işlev uygulamasındaki bir işlev veya başka bir API olabilir. Değerin statik olması gerekli değildir ve özgün istemci isteğinden [uygulama ayarlarına] [ve parametrelerine başvurabilirsiniz.]
  6. Oluştur’a tıklayın.

Proxy'niz artık işlev uygulamanıza yeni bir uç nokta olarak bulunuyor. İstemci perspektifinden bakıldığında, istemcide httpTrigger ile Azure İşlevleri. Proxy URL'sini kopyalayıp sık kullanılan HTTP istemciniz ile test etmek için yeni proxy'nizi sınabilirsiniz.

İstekleri ve yanıtları değiştirme

Bu Azure İşlev Proxy'leri, istekleri ve yanıtlarını arka uçtan değiştirebilirsiniz. Bu dönüştürmeler Değişkenleri kullan içinde tanımlandığı [gibi değişkenleri kullanabilir.]

Arka uç isteğini değiştirme

Varsayılan olarak, arka uç isteği özgün isteğin bir kopyası olarak başlatılır. Arka uç URL'sini ayarlamaya ek olarak HTTP yönteminde, üst bilgilerde ve sorgu dizesi parametrelerinde de değişiklik yapabilirsiniz. Değiştirilen değerler, özgün istemci [isteğinden] [uygulama ayarlarına ve parametrelerine başvurur.]

Arka uç istekleri, ara sunucu ayrıntı sayfasının istek geçersiz kılma bölümü genişleterek portalda değiştirilebilir.

Yanıtı değiştirme

Varsayılan olarak, istemci yanıtı arka uç yanıtının bir kopyası olarak başlatılır. Yanıtın durum kodunda, neden tümceciğinde, üst bilgilerde ve gövdede değişiklik yapabilirsiniz. Değiştirilen değerler uygulama [ayarlarına,]özgün [istemci isteğinden parametrelere ve]arka uç [yanıttan parametrelere başvurabilirsiniz.]

Arka uç istekleri, ara sunucu ayrıntı sayfasının yanıt geçersiz kılma bölümü genişleterek portalda değiştirilebilir.

Değişken kullanma

Ara sunucu yapılandırmasının statik olması gerek değildir. Özgün istemci isteğinden, arka uç yanıttan veya uygulama ayarlarından değişkenleri kullanmak için bunu koşulleyebilirsiniz.

Yerel işlevlere başvuru

Gidiş dönüş localhost proxy isteği olmadan aynı işlev uygulaması içindeki bir işleve doğrudan başvuru yapmak için kullanabilirsiniz.

"backendUri": "https://localhost/api/httptriggerC#1" , rotada http ile tetiklenen yerel bir işleve başvurur /api/httptriggerC#1

Not

İşleviniz işlev, yönetici veya sys yetkilendirme düzeylerini kullanıyorsa, özgün işlev URL'sini kullanarak kodu ve clientId'yi sağlayabilirsiniz. Bu durumda başvuru şöyle olabilir: Bu anahtarları uygulama ayarlarında depolamanızı ve bu anahtarlara kendi "backendUri": "https://localhost/api/httptriggerC#1?code=<keyvalue>&clientId=<keyname>" güvenliklerinize [] başvurulmanızı öneririz. Bu, gizli dizilerin kaynak kodunda depolanmasına engel olur.

Başvuru isteği parametreleri

İstek parametrelerini arka uç URL özelliğine giriş olarak veya istekleri ve yanıtları değiştirmenin bir parçası olarak kullanabilirsiniz. Bazı parametreler, temel ara sunucu yapılandırmasında belirtilen yol şablonundan, bazıları ise gelen isteğin özelliklerinden gelebilir.

Yol şablonu parametreleri

Yol şablonunda kullanılan parametrelere ad ile başvurulabilirsiniz. Parametre adları küme ayraçları () içine {} alınır.

Örneğin, bir ara sunucu gibi bir yol şablonuna sahipse, arka uç URL'si içinde olduğu /pets/{petId} gibi {petId} değerini https://<AnotherApp>.azurewebsites.net/api/pets/{petId} içerebilir. Yol şablonu gibi bir joker karakterde sonlandırılırsa değer, gelen istekten kalan yol /api/{*restOfPath} {restOfPath} kesimlerinin dize gösterimidir.

Ek istek parametreleri

Yol şablonu parametrelerine ek olarak, yapılandırma değerlerde aşağıdaki değerler kullanılabilir:

  • {request.method}: Özgün istekte kullanılan HTTP yöntemi.
  • {request.headers. <HeaderName> }: Özgün istekten okunan bir üst bilgi. <HeaderName> yerine okumak istediğiniz üst bilginin adını yazın. Üst bilgi istekte yer alıyorsa değer boş dize olur.
  • {request.querystring. <ParameterName> }: Özgün istekten okunan bir sorgu dizesi parametresi. <ParameterName> yerine okumak istediğiniz parametrenin adını yazın. parametresi istekte yer alamayacaksa değer boş dize olur.

Başvuru arka uç yanıt parametreleri

Yanıt parametreleri, istemciye yanıtı değiştirmenin bir parçası olarak kullanılabilir. Yapılandırma değerlerde aşağıdaki değerler kullanılabilir:

  • {backend.response.statusCode}: Arka uç yanıtta döndürülen HTTP durum kodu.
  • {backend.response.statusReason}: Arka uç yanıtta döndürülen HTTP nedeni tümceciği.
  • {backend.response.headers. <HeaderName> }: Arka uç yanıttan okunan bir üst bilgi. yerine <HeaderName> okumak istediğiniz üst bilginin adını yazın. Yanıtta üst bilgi yoksa değer boş dize olur.

Başvuru uygulaması ayarları

Yüzde işaretleri (%) ile ayar adını çevrelerken işlev uygulaması için tanımlanan uygulama ayarlarına da başvurabilirsiniz.

Örneğin, bir arka uç URL'sinin "%ORDER_PROCESSING_HOST%" değeri, ORDER_PROCESSING_HOST https://%ORDER_PROCESSING_HOST%/api/orders olur.

İpucu

Birden çok dağıtımınız veya test ortamlarınız olduğunda arka uç konakları için uygulama ayarlarını kullanın. Bu şekilde, her zaman bu ortam için doğru arka uçla konuştuğundan emin olun.

Hata Gidericileri Sorunlarını Giderme

bayrağını dosyanız "debug":true içinde herhangi bir ara sunucuya ekleyerek hata ayıklama günlüğünü proxies.json etkinleştirirsiniz. Günlükler içinde depolanır D:\home\LogFiles\Application\Proxies\DetailedTrace ve gelişmiş araçlar (kudu) aracılığıyla erişilebilir. Tüm HTTP yanıtları ayrıca günlük dosyasına erişmek Proxy-Trace-Location için URL içeren bir üst bilgi içerir.

olarak ayarlanmış bir üst bilgi ekleyerek istemci tarafında ara sunucu Proxy-Trace-Enabled hata ayıklaması sebilirsiniz. true Bu işlem ayrıca dosya sistemine bir izleme günlüğe kaydedilir ve yanıtta bir üst bilgi olarak izleme URL'sini geri döner.

Ara sunucu izlemelerini engelleme

Güvenlik nedeniyle hizmetinizi çağıran kimsenin izleme oluşturmasına izin vermek istemeyabilirsiniz. Oturum açma kimlik bilgileriniz olmadan izleme içeriğine erişemeden izleme içeriğine erişemeye devam etmek mümkün olmayacaktır, ancak izlemenin üretilmesi kaynakları tüketir ve İşlevLer'i kullanmakta olduğunu ortaya çıkarır.

içinde belirli bir ara sunucuya ekleyerek "debug":false izlemeleri tamamen devre dışı proxies.json bırakma.

Gelişmiş yapılandırma

Yapılandırılan sunucular bir işlev uygulaması dizininin kökünde bulunan bir proxies.json dosyasında depolanır. İşlevler'in desteklediği dağıtım yöntemlerini kullanarak bu dosyayı el ile düzenleyebilir ve uygulamanızın bir parçası olarak dağıtabilirsiniz.

İpucu

Dağıtım yöntemlerinden birini ayarlamadısanız portalda proxies.json dosyasıyla da çalışabilirsiniz. İşlev uygulamanıza gidin, Platform özellikleri'ne ve ardından App Service Düzenleyicisi. Bunu yaparak işlev uygulamanın dosya yapısının tamamını görüntüp değişiklikler yapabilirsiniz.

Proxies.json, adlandırılmış ve kendi tanımlarından oluşan bir yanallık nesnesi tarafından tanımlanır. İsteğe bağlı olarak, düzenleyiciniz destekliyorsa, kod tamamlama için bir JSON şemasına başvurabilirsiniz. Örnek bir dosya aşağıdaki gibi olabilir:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "proxy1": {
            "matchCondition": {
                "methods": [ "GET" ],
                "route": "/api/{test}"
            },
            "backendUri": "https://<AnotherApp>.azurewebsites.net/api/<FunctionName>"
        }
    }
}

Her ara sunucu, önceki örnekte proxy1 gibi kolay bir ada sahip olur. Karşılık gelen ara sunucu tanımı nesnesi aşağıdaki özelliklerle tanımlanır:

  • matchCondition: Gerekli-- Bu ara sunucu yürütmeyi tetikleyen istekleri tanımlayan bir nesne. HTTP tetikleyicileriyle paylaşılan iki [özellik içerir:]
    • Yöntemler: proxy 'nin yanıt verdiği http yöntemlerinin bir dizisi. Belirtilmemişse, ara sunucu rotadaki tüm HTTP yöntemlerine yanıt verir.
    • yol: gerekli--proxy 'nizin hangi Istek URL 'lerine yanıt vereceğini denetleyen yol şablonunu tanımlar. HTTP tetikleyicilerinin aksine, varsayılan değer yoktur.
  • Backenduri: isteğin proxy olması gereken arka uç kaynağının URL 'si. Bu değer, özgün istemci isteğinden uygulama ayarlarına ve parametrelere başvurabilir. Bu özellik dahil değilse, Azure Işlevleri bir HTTP 200 Tamam ile yanıt verir.
  • requestOverrides: arka uç isteğine dönüştürmeleri tanımlayan bir nesne. Bkz. requestOverrides nesnesi tanımlama.
  • Responsekılmalar: istemci yanıtına dönüştürmeleri tanımlayan bir nesne. Bkz. [Responsegeçersiz kılmalar nesnesi tanımlama].

Not

Azure İşlev Proxy'leri route özelliği, işlev uygulaması ana bilgisayar yapılandırmasının routeprefix özelliğini karşılamıyor. Gibi bir ön ek eklemek istiyorsanız /api , route özelliğine eklenmelidir.

Ayrı proxy 'leri devre dışı bırak

Dosyadaki ara sunucuya ekleyerek ayrı proxy 'leri devre dışı bırakabilirsiniz "disabled": true proxies.json . Bu, matchCondition 'a uyan isteklerin 404 döndürmesini sağlar.

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "Root": {
            "disabled":true,
            "matchCondition": {
                "route": "/example"
            },
            "backendUri": "https://<AnotherApp>.azurewebsites.net/api/<FunctionName>"
        }
    }
}

uygulama Ayarlar

Proxy davranışı birkaç uygulama ayarı tarafından denetlenebilir. bunlar, işlevler uygulama Ayarlar başvurusu ' nda özetlenmiştir

Ayrılmış karakterler (dize biçimlendirme)

Proxy 'ler, bir JSON dosyasının dışında tüm dizeleri okur ve bunu çıkış simgesi olarak kullanın. Proxy 'ler Ayrıca küme ayraçları da yorumlayabilir. Aşağıdaki örnek bir dizi örneğe bakın.

Karakter Kaçan karakter Örnek
veya {{veya}} {{ example }} --> { example }
\ \\ example.com\\text.html --> example.com\text.html
" \" \"example\" --> "example"

RequestOverrides nesnesi tanımlama

RequestOverrides nesnesi, arka uç kaynağı çağrıldığında istek üzerinde yapılan değişiklikleri tanımlar. Nesnesi aşağıdaki özellikler tarafından tanımlanır:

  • arka uç. Request. Method: arka ucu çağırmak IÇIN kullanılan http yöntemi.
  • arka uç. Request. QueryString <ParameterName> .: arka uca çağrı için ayarlanyleyebileceğiniz bir sorgu dizesi parametresi. <ParameterName> Ayarlamak istediğiniz parametrenin adıyla değiştirin. Boş bir dize sağlanırsa, parametrenin yine de arka uç isteğine dahil edildiğini unutmayın.
  • arka uç. Request. Headers <HeaderName> .: arka uca çağrı için ayarlayabilme üst bilgi. <HeaderName> Ayarlamak istediğiniz üstbilginin adıyla değiştirin. Boş bir dize sağlanırsa, parametrenin yine de arka uç isteğine dahil edildiğini unutmayın.

Değerler, özgün istemci isteğinden uygulama ayarlarına ve parametrelere başvurabilir.

Örnek bir yapılandırma aşağıdaki gibi görünebilir:

{
    "$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%"
            }
        }
    }
}

Responsekılmalar nesnesi tanımlama

RequestOverrides nesnesi, istemciye geri geçirilmiş yanıtta yapılan değişiklikleri tanımlar. Nesnesi aşağıdaki özellikler tarafından tanımlanır:

  • Response. StatusCode: ISTEMCIYE döndürülecek http durum kodu.
  • Response. statusReason: ISTEMCIYE döndürülecek http neden tümceciği.
  • Response. Body: istemciye döndürülecek gövdenin dize temsili.
  • Response. Headers. <HeaderName>: istemciye yanıt olarak ayarlanabilir bir üst bilgi. <HeaderName> Ayarlamak istediğiniz üstbilginin adıyla değiştirin. Boş bir dize sağlarsanız, üst bilgi yanıta eklenmez.

Değerler uygulama ayarlarına, özgün istemci isteğinden parametrelere ve arka uç yanıtından parametrelere başvurabilir.

Örnek bir yapılandırma aşağıdaki gibi görünebilir:

{
    "$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"
            }
        }
    }
}

Not

Bu örnekte, yanıt gövdesi doğrudan ayarlanır, bu nedenle hiçbir backendUri özellik gerekmez. Örnek, sahte işlem API 'leri için Azure işlev proxy'leri nasıl kullanabileceğinizi gösterir.