Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Şunlar için geçerlidir: Geliştirici | Premium
Şirket içinde barındırılan ağ geçidi, her API Management örneğine dahil edilen varsayılan yönetilen ağ geçidinin isteğe bağlı, kapsayıcılı bir sürümüdür. Ağ geçitlerini API'lerinizi barındırdığınız ortamlara yerleştirme gibi senaryolar için kullanışlıdır. API trafik akışını geliştirmek ve API güvenlik ve uyumluluk gereksinimlerini karşılamak için şirket içinde barındırılan ağ geçidini kullanın.
Bu makalede, Azure API Management'ın şirket içinde barındırılan ağ geçidi özelliğinin karma ve çoklu bulut API yönetimini nasıl sağladığı açıklanmaktadır. Ayrıca özelliğin üst düzey mimarisini sunar ve özelliklerini açıklar.
Yönetilen ve şirket içinde barındırılan ağ geçitleri arasındaki farklara genel bakış için bkz. API Management'ta API ağ geçidi.
Karma ve çoklu bulut API yönetimi
Şirket içinde barındırılan ağ geçidi özelliği, hibrit ve çoklu bulut ortamları için API Management desteğini genişletir ve Azure'daki tek bir API Management örneğinden şirket içinde ve bulutlarda barındırılan API'leri verimli ve güvenli bir şekilde yönetmenizi sağlar.
Yerinde barındırılan ağ geçidi ile API Management ağ geçidi bileşeninin konteynerleştirilmiş bir sürümünü API'lerinizi barındırdığınız ortamlara dağıtma esnekliğine sahip olursunuz. Yerel olarak barındırılan tüm ağ geçitleri, federe edildikleri API Yönetimi örneğinden yönetilir ve bu sayede tüm iç ve dış API'lerde görünürlük ve tekil yönetim deneyimi sağlar.
Her API Management örneği aşağıdaki temel bileşenlerden oluşur:
- Azure portalı, PowerShell ve desteklenen diğer teknolojiler aracılığıyla hizmeti yapılandırmak için kullanılan, API olarak kullanıma sunulan bir yönetim düzlemi
- API isteklerine vekil sunucu olarak çalışmak, ilkeleri uygulamak ve telemetri toplama işlemlerinden sorumlu bir ağ geçidi (veya veri düzlemi)
- Geliştiricilerin API'leri keşfetmesi, öğrenmesi ve kullanması için kullanılan bir portal olan geliştirici portalı.
Varsayılan olarak, tüm bu bileşenler Azure'da dağıtılır ve API'leri uygulayan arka uçların nerede barındırıldığına bakılmaksızın tüm API trafiğinin (aşağıdaki görüntüde düz siyah oklar olarak gösterilir) Azure'da akmasına neden olur. Bu modelin operasyonel basitliği, artan gecikme süresi, uyumluluk sorunları ve bazı durumlarda ek veri aktarımı ücretlerinin maliyetinden kaynaklanmıştır.
Şirket içinde barındırılan ağ geçitlerinin arka uç API uygulamalarının barındırıldığı ortamlara dağıtılması, API trafiğinin doğrudan arka uç API'lerine akmasını sağlar. Bu sayede gecikme süresini azaltır, veri aktarımı maliyetlerini iyileştirir ve uygulamalarının barındırıldığı konumdan bağımsız olarak kuruluştaki tüm API'ler için tek bir yönetim, gözlemlenebilirlik ve bulma noktasına sahip olmanın avantajlarını korur.
Ambalaj
Yerel barındırılan ağ geçidi, Microsoft Artifact Registry'den Linux tabanlı bir Docker kapsayıcı görüntüsü olarak kullanılabilir. Şirket içi bir sunucu kümesinde, bulut altyapısında veya değerlendirme ve geliştirme amacıyla kişisel bir bilgisayarda çalışan Docker, Kubernetes veya başka bir kapsayıcı düzenleme çözümüne dağıtılabilir. İçeride barındırılan ağ geçidini Azure Arc özellikli Kubernetes kümesine küme uzantısı olarak dağıtma imkanına sahipsiniz.
Konteyner görüntüleri
Kendi kendine barındırılan ağ geçitleri için çeşitli kapsayıcı görüntüleri mevcuttur.
| Etiket kuralı | Tavsiye | Örnek | Dönen etiket | Üretim için önerilir |
|---|---|---|---|---|
{major}.{minor}.{patch} |
Her zaman ağ geçidinin aynı sürümünü çalıştırmak için bu etiketi kullanın. | 2.0.0 |
❌ | ✔️ |
v{major} |
Her yeni özellik ve düzeltme eki ile her zaman ağ geçidinin ana sürümünü çalıştırmak için bu etiketi kullanın. | v2 |
✔️ | ❌ |
v{major}-preview |
Her zaman en son önizleme kapsayıcı görüntüsünü çalıştırmak istiyorsanız bu etiketi kullanın. | v2-preview |
✔️ | ❌ |
latest |
Kendi kendine barındırılan ağ geçidini değerlendirmek istiyorsanız bu etiketi kullanın. | latest |
✔️ | ❌ |
beta
1 |
Kendi altyapınızda barındırılan ağ geçidinin önizleme sürümlerini değerlendirmek istiyorsanız bu etiketi kullanın. | beta |
✔️ | ❌ |
Kullanılabilir etiketlerin tam listesini burada bulabilirsiniz.
1Önizleme sürümleri resmi olarak desteklenmez ve yalnızca deneysel amaçlıdır. Kendi kendine barındırılan ağ geçidi destek ilkelerine bakın.
Resmi dağıtım seçeneklerinde etiketlerin kullanımı
Azure portalındaki dağıtım seçenekleri, kendi kendine barındırılan ağ geçidi v2 konteyner imajının tüm özellik güncelleştirmeleri ve düzeltme ekleriyle en son sürümünü kullanmanıza olanak tanıyan v2 etiketini kullanır.
Uyarı
Komut ve YAML kod parçacıkları başvuru olarak sağlanır. İsterseniz daha belirgin bir etiket kullanabilirsiniz.
Helm grafiğine sahip bir ağ geçidi yüklediğinizde görüntü etiketleme iyileştirilir. Helm grafiğinin uygulama sürümü, ağ geçidini belirli bir sürüme sabitler ve latest'e güvenmez.
Daha fazla bilgi için bkz. Helm ile Kubernetes'e API Management şirket içi ağ geçidi yükleme.
Dönen etiketleri kullanma riski
Sıralı etiketler, kapsayıcı görüntüsünün yeni bir sürümü yayımlandığında güncelleştirilebilecek etiketlerdir. Bu tür etiketlerin kullanılması, kapsayıcı kullanıcılarının dağıtımlarını güncelleştirmek zorunda kalmadan kapsayıcı görüntüsü güncelleştirmelerini almasını sağlar.
Bu tür bir etiket kullandığınızda, fark etmeden, örneğin etiket güncelleştirildikten sonra v2 ölçeklendirme eylemleri gerçekleştirirken farklı sürümleri paralel olarak çalıştırabilirsiniz.
Örnek: v2 etiket, 2.0.0 kapsayıcı görüntüsüyle birlikte serbest bırakılır. Yayınlandığında 2.1.0 , v2 etiketi 2.1.0 görüntüsüne bağlanır.
Önemli
Daha yeni bir sürüme yanlışlıkla yükseltmeleri önlemek için üretimde belirli bir sürüm etiketi kullanmayı göz önünde bulundurun.
Azure ile bağlantı
Kendi kendine barındırılan ağ geçitleri, 443 numaralı bağlantı noktasında Azure'a dışarıya giden TCP/IP bağlantısı gerektirir. Şirket içinde barındırılan her ağ geçidi, tek bir API yönetimi örneğiyle ilişkilendirilmeli ve onun yönetim düzlemi aracılığıyla yapılandırılmalıdır. Kendi kendine barındırılan bir ağ geçidi, Azure'a bağlantıyı aşağıdakiler için kullanır:
- Durumunu, her dakika nabız mesajları göndererek bildirir.
- Kullanılabilir olduğunda düzenli olarak (her 10 saniyede bir) yapılandırma güncelleştirmelerini denetler ve uygular.
- Bunu yapmak için yapılandırılmışsa ölçümleri Azure İzleyici'ye gönderme.
- Bunu yapmak için yapılandırılmışsa Application Insights'a olay gönderme.
FQDN bağımlılıkları
Kendi barındırılan her ağ geçidinin düzgün çalışabilmesi için, bulut tabanlı API Management örneğiyle ilgili aşağıdaki uç noktalara 443 numaralı bağlantı noktasından dışa doğru bağlantı gerekir.
| Bitiş noktası | Gerekli mi? | Notlar |
|---|---|---|
| Yapılandırma uç noktasının ana bilgisayar adı |
<api-management-service-name>.configuration.azure-api.net
1 |
Özel konak adları da desteklenir ve varsayılan konak adı yerine kullanılabilir. |
| API Management örneğinin genel IP adresi | ✔️ | Birincil konumun IP adresi yeterlidir. |
| Azure Depolama hizmeti etiketinin genel IP adresleri | İsteğe bağlı2 | IP adresleri API Management örneğinin birincil konumuna karşılık gelmelidir. |
| Azure Blob Depolama hesabının ana bilgisayar adı | İsteğe bağlı2 | Örnek (<blob-storage-account-name>.blob.core.windows.net) ile ilişkilendirilmiş hesap. |
| Azure Tablo Depolama hesabının ana bilgisayar adı | İsteğe bağlı2 | Örnek (<table-storage-account-name>.table.core.windows.net) ile ilişkilendirilmiş hesap. |
| Azure Resource Manager için uç noktalar | İsteğe bağlı3 | Gerekli uç nokta management.azure.com. |
| Microsoft Entra entegrasyonu için uç noktalar | İsteğe bağlı4 | Gerekli uç noktalar <region>.login.microsoft.com ve login.microsoftonline.com'dir. |
| Azure Application Insights tümleştirmesi için uç noktalar | İsteğe bağlı5 | En az gerekli uç nokta: rt.services.visualstudio.com:443, dc.services.visualstudio.com:443ve {region}.livediagnostics.monitor.azure.com:443. Daha fazla bilgi için Azure İzleyici belgelerine bakın. |
| Event Hubs tümleştirmesi için uç noktalar | İsteğe bağlı5 | Daha fazla bilgi için Azure Event Hubs belgelerine bakın. |
| Dış önbellek tümleştirmesi için uç noktalar | İsteğe bağlı5 | Bu gereksinim, kullanılmakta olan dış önbelleğe bağlıdır. |
1bir iç sanal ağdaki API Management örneği hakkında bilgi için bkz. İç sanal ağda bağlantı.
2Yalnızca ilkelerde API denetçisi veya kotalar kullanıldığında v2'de gereklidir.
3Yalnızca RBAC izinlerini doğrulamak için Microsoft Entra kimlik doğrulaması kullanılırken gereklidir.
4Yalnızca Microsoft Entra kimlik doğrulamasını veya Microsoft Entra ile ilgili ilkeleri kullandığınızda gereklidir.
5Yalnızca özellik kullanıldığında ve genel IP adresi, bağlantı noktası ve ana bilgisayar adı bilgileri gerektirdiğinde gereklidir.
Önemli
- DNS ana bilgisayar adları IP adresleriyle çözümlenebilir olmalı ve buna karşılık gelen IP adreslerine ulaşılabilir olmalıdır.
- İlişkili depolama hesabı adları, Hizmetin Azure portalındaki Ağ bağlantısı durumu sayfasında listelenir.
- İlişkili depolama hesaplarını temel alan genel IP adresleri dinamiktir ve bildirimde bulunmadan değişebilir.
İç sanal ağda bağlantı
Özel bağlantı. Şirket içinde barındırılan ağ geçidi bir sanal ağda dağıtılıyorsa, örneğin eşlenmiş bir ağda özel DNS kullanarak şirket içinde barındırılan ağ geçidinin konumundan v2 yapılandırma uç noktasına özel bağlantıyı etkinleştirin.
İnternet bağlantısı. Kendi kendine barındırılan ağ geçidinin v2 yapılandırma uç noktasına internet üzerinden bağlanması gerekiyorsa, yapılandırma uç noktası için özel bir konak adı yapılandırın ve Azure Application Gateway kullanarak uç noktayı erişime açın.
Kimlik doğrulama seçenekleri
Ağ geçidi kapsayıcısının yapılandırma ayarları , şirket içinde barındırılan ağ geçidi ile bulut tabanlı API Management örneğinin yapılandırma uç noktası arasındaki bağlantının kimliğini doğrulamak için aşağıdaki seçenekleri sağlar.
| Seçenek | Değerlendirmeler |
|---|---|
| Microsoft Entra kimlik doğrulaması | Ağ geçidine erişmek için bir veya daha fazla Microsoft Entra uygulaması yapılandırın. Erişimi uygulama başına ayrı ayrı yönetin. Gizli bilgiler için kuruluşunuzun politikalarına uygun olarak daha uzun geçerlilik süreleri yapılandırın. Uygulamalara kullanıcı veya grup izinleri atamak veya geri almak ve gizli bilgileri güncellemek için standart Microsoft Entra prosedürlerini kullanın. |
| Ağ geçidi erişim belirteci. (Kimlik doğrulama anahtarı olarak da adlandırılır.) | Belirtecin süresi en az 30 günde bir sona erer ve kapsayıcılarda yenilenmelidir. Bağımsız olarak döndürülebilen bir ağ geçidi anahtarıyla (örneğin, erişimi iptal etmek için) yedeklenmiştir. Ağ geçidi anahtarının yeniden oluşturulması, onunla oluşturulan tüm erişim belirteçlerini geçersiz kılır. |
Tavsiye
Öz barındırılan bir ağ geçidi tarafından ağ geçidi erişim belirtecinin süresi dolmasına yakın veya süresi dolduğunda oluşturulan Event Grid olayları hakkında bilgi için bkz. Event Grid kaynağı olarak Azure API Management. Dağıtılan ağ geçitlerinin her zaman ilişkili API Management örneğiyle kimlik doğrulaması yapabilmesini sağlamak için bu olayları kullanın.
Bağlantı hataları
Azure bağlantısı kaybolduğunda, yerel olarak barındırılan ağ geçidi yapılandırma güncellemelerini alamaz, durumunu raporlayamaz veya telemetriyi karşıya yükleyemez.
Şirket içinde barındırılan ağ geçidi "statik olarak başarısız" olacak şekilde tasarlanmıştır ve Azure'a olan bağlantı kaybolduğunda geçici bir kaybı tolere edebilir. Yerel yapılandırma yedeklemesi ile veya olmadan dağıtılabilir. Yapılandırma yedeklemesi ile kendi kendine barındırılan ağ geçidi, en son indirilen yapılandırmanın yedek kopyasını kapsayıcılarına veya podlarına bağlı kalıcı depolama birimine düzenli olarak kaydeder.
Yapılandırma yedeklemesi kapatıldığında ve Azure bağlantısı kesildiğinde:
- İçeride barındırılan ağ geçitleri, yapılandırmanın bellek içi bir kopyasını kullanarak çalışmaya devam eder.
- Durdurulan kendinden barındırılan ağ geçitleri başlatılamaz.
Yapılandırma yedeklemesi açıldığında ve Azure bağlantısı kesildiğinde:
- Çalışmakta olan kendi barındırmalı ağ geçitleri, yapılandırmanın bellek içi bir kopyasını kullanarak işlevlerini sürdürür.
- Durdurulmuş öz barındırılan ağ geçitleri, yapılandırmanın yedek bir kopyasını kullanarak başlayabilir.
Bağlantı geri yüklendiğinde, kesintiden etkilenen kendi kendine barındırılan her ağ geçidi, ilişkili API Management örneğine otomatik olarak yeniden bağlanır ve ağ geçidinin çevrimdışı olduğu süre boyunca gerçekleşen tüm yapılandırma güncellemelerini indirir.
Güvenlik
Sınırlamalar
Yönetilen ağ geçitlerinde kullanılabilen aşağıdaki işlevler şirket içinde barındırılan ağ geçitlerinde kullanılamaz:
- TLS oturum yeniden başlatma.
- İstemci sertifikası yeniden anlaşması. İstemci sertifikası kimlik doğrulamasını kullanmak için API tüketicilerinin ilk TLS el sıkışmasının bir parçası olarak sertifikalarını sunması gerekir. Bu davranışı sağlamak için, kendinden barındırılan bir ağ geçidi özel ana bilgisayar adı (etki alanı adı) yapılandırırken İstemci Sertifikası Müzakere ayarını etkinleştirin.
Aktarım Katmanı Güvenliği (TLS)
Desteklenen protokoller
Kendi barındırılan ağ geçitleri TLS v1.2'yi varsayılan olarak destekler.
Özel etki alanları kullanıyorsanız, denetim düzleminde TLS v1.0 ve/veya v1.1'i etkinleştirebilirsiniz.
Kullanılabilir şifreleme paketleri
Şirket içinde barındırılan ağ geçitleri hem istemci hem de sunucu bağlantıları için aşağıdaki şifreleme paketlerini kullanır:
TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_DHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_DHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384TLS_DHE_RSA_WITH_AES_256_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_DHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHATLS_ECDHE_RSA_WITH_AES_256_CBC_SHATLS_DHE_RSA_WITH_AES_256_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHATLS_ECDHE_RSA_WITH_AES_128_CBC_SHATLS_DHE_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_CBC_SHA256TLS_RSA_WITH_AES_128_CBC_SHA256TLS_RSA_WITH_AES_256_CBC_SHATLS_RSA_WITH_AES_128_CBC_SHA
Şifreleme paketlerini yönetme
v2.1.1 ve üzeri sürümlerle, yapılandırma aracılığıyla kullanılan şifreleri yönetebilirsiniz:
-
net.server.tls.ciphers.allowed-suites, API istemcisi ile şirket içinde barındırılan ağ geçidi arasındaki TLS bağlantısı için kullanılacak şifrelerin virgülle ayrılmış bir listesini tanımlamanızı sağlar. -
net.client.tls.ciphers.allowed-suites, şirket içinde barındırılan ağ geçidi ile arka uç arasındaki TLS bağlantısı için kullanılacak şifrelerin virgülle ayrılmış bir listesini tanımlamanızı sağlar.
İlgili içerik
- API ağ geçidine genel bakış
- Kendi kendine barındırılan ağ geçidi için destek politikası
- Hibrit ve çoklu bulut dünyasında API Management
- Üretimde Kubernetes'te kendi kendine barındırılan ağ geçidini çalıştırmak için rehber
- Docker'da öz barındırılan bir ağ geçidini dağıtın
- Kubernetes'e bir kendi kendine barındırılan ağ geçidi dağıtma
- Azure Arc özellikli Kubernetes kümesine kendi üzerinde barındırılan bir ağ geçidi dağıtın
- Kendi kendine barındırılan bir ağ geçidini Azure Container Apps'te dağıtma
- Kendi bünyesinde barındırılan ağ geçidi yapılandırma ayarları
- API Management'ta gözlemlenebilirlik özellikleri
- Kendi kendine barındırılan ağ geçidi ile Dapr entegrasyonu