Azure Function App 'Runtime Unreachable' sorunu eksik VNet entegrasyonu ve private DNS'a bağlandı

Kod dağıtılmadan önce Azure Portal'da 'Runtime Unreachable' hatası veren bir Linux Azure Function App'in sorununun uygulama değil, ağ kaynaklı olduğu ortaya çıktı. dev.to'da yayımlanan bir anlatıma göre çözüm iki parçadan oluşuyordu: uygulamaya sanal ağa giden erişim sağlayan bölgesel VNet entegrasyonu ve uygulamanın kullandığı ikinci bir storage hesabı için ayrı bir private endpoint ile Private DNS yapılandırması.

Başarısızlık

Yazar, özel kaynakları barındıran paylaşımlı bir VNet'in zaten bulunduğu bir ortamda Elastic Premium EP1 planında yeni bir Linux Function App oluşturuyordu. Oluşturmanın hemen ardından Portal Functions runtime sürümünü gösteremedi ve ZIP dağıtımları kullanılabilir uygulama düzeyinde log üretmeden başarısız oldu. Henüz hiç Python kodu bulunmadığından, bozuk bir fonksiyon dosyası, hatalı bağımlılıklar veya kusurlu bir paket gibi şüpheler baştan elendi. Makaleye göre host, kodunuz çalışmadan önce başlatılamıyorsa, bakılacak ilk yer host'un bağımlı olduğu altyapı, özellikle de storage'dır.

Özel storage engeldi

Bu Function App'e bağlı storage hesabı ağ kısıtlamalarıyla korunuyordu ve yalnızca özel ağ üzerinden erişilebilirdi. Ortamda zaten çalışan Function App'ler VNet ile entegre edildikleri için sorunsuz çalışıyordu; yeni uygulama edilmemişti. Bu tek uyumsuzluk, uygulamayı ihtiyaç duyduğu storage'a giden yoldan yoksun bıraktı.

dev.to gönderisinin belirttiği gibi, Azure Functions temel host işlemleri için yapılandırılmış storage hesabına güvenir ve Premium planlar genellikle fonksiyon içeriği ve dağıtım için Azure Files kullanır; bu, AzureWebJobsStorage ve WEBSITE_CONTENTAZUREFILECONNECTIONSTRING gibi ayarlar üzerinden bağlanır. Bu hesap özelse, uygulama ona VNet üzerinden ulaşır ya da hiç ulaşamaz.

Entegrasyon giden yön içindir; private endpoint'ler adrestir

Anlatım, yeni başlayanların takıldığı bir ayrıma dikkat çekiyor. Bölgesel VNet entegrasyonu bir giden yön (outbound) yeteneğidir: Function App'in private endpoint'ler üzerinden sunulan kaynaklar dahil VNet'e çağrı yapmasını sağlar. Uygulamanın kendisini o ağdan özel olarak erişilebilir kılmaz. Buna karşılık bir private endpoint, bir Azure kaynağına VNet içinde özel bir IP adresi verir. Hangi yarı bozuksa sorun giderme de farklılaşır.

İlk çözüm

Yazar, çalışan bir Function App'in yapılandırmasını yansıttı. Portal'da Function App, ardından Networking, ardından Virtual Network Integration altında uygulamayı aynı VNet'e ve adanmış bir entegrasyon alt ağına bağladılar. Bu alt ağın Microsoft.Web/serverFarms'a devredilmiş (delegasyon) olması gerekir. Microsoft, Elastic Premium entegrasyonu için en düşük boyut olarak /28'i belgeler ve Linux Premium iş yükleri için daha büyük bir alt ağ önerir; çünkü çalışan her örnek bir IP adresi tüketir ve ölçekleme geçici olarak daha fazlasını gerektirebilir. Makalenin açıkça vurguladığı bir kural: private-endpoint alt ağını entegrasyon alt ağı olarak yeniden kullanmayın, çünkü ikisi farklı amaçlara hizmet eder ve Microsoft'un kendi örnekleri bile onları ayrı tutar. Bir yeniden başlatma ve ağ değişikliklerinin oturması için birkaç dakikanın ardından runtime geri geldi.

İkinci başarısızlık DNS'ti

Host sağlıklı olduğunda, basit bir health-check fonksiyonu Key Vault'a erişilebildiğini ama blob storage'ın şu hatayla başarısız olduğunu bildirdi: Failed to resolve 'contentarchive.blob.core.windows.net', no address associated with hostname. Yazar bunun neden önemli olduğunu vurguluyor: Bu, AuthorizationPermissionMismatch veya 403 değil, bir ad çözümleme hatasıydı; yani uygulamanın bir yolu vardı ama çözülebilir bir adresi yoktu. Bu storage hesabı, uygulamanın kendi storage'ından farklı olarak, işlenmiş belgeler için kullandığı ayrı bir iş içeriği deposuydu. Anlatıma göre çözüm, bu hesap için eşleşen Private DNS yapılandırmasıyla birlikte adanmış bir private endpoint oluşturmaktı; yazar bağlantının geri gelmesini buna borçlu.

Neden önemli

'Runtime Unreachable', Azure Functions'taki en anlaşılması zor başarısızlık biçimlerinden biridir ve genellikle tam bu hikâyede olduğu gibi, storage'ın özel olduğu kilitli ortamlarda ortaya çıkar. Bu örnek, aktarılabilir iki ders sunuyor. Birincisi, host herhangi bir kod gönderilmeden önce başarısız olursa, uygulamadan değil storage bağlantısı ve DNS gibi platform bağımlılıklarından şüphelenin. İkincisi, VNet entegrasyonu ile private endpoint'ler sorunun farklı yarılarını çözer: entegrasyon giden erişim sağlarken, private endpoint'ler ve Private DNS bölgeleri çözülebilir özel adresler sağlar. Alt ağ delegasyonunu, boyutlandırmayı ve ayrımı ilk seferde doğru yapmak, körleme geçen bir hata ayıklama oturumunu tekrarlanabilir bir kontrol listesine dönüştürür.