Azure App Service’te Runtime Patch Kontrolü ve WebSSH
Linux üzerindeki App Service uygulamalarını güncel tutmakla dağıtım, test ve sorun giderme üzerindeki kontrolü elde tutmak çoğu zaman birbirini zorlar. 8 Ekim tarihli Azure App Service Community Standup: Platform Release Channels & WebSSH for Custom Containers oturumunda ekip, bu dengeyi kolaylaştıran özellikleri canlı gösterdi: runtime yamalarının ne zaman uygulanacağını seçmek, portal üzerinden ZIP dağıtıp geri dönmek, SSH sunucusu olmayan custom container’lara bağlanmak ve Node.js uygulamalarında CPU, bellek ile ağ kanıtı toplamak.
Aşağıda oturumda gösterilenleri, sunulan sınırlarıyla birlikte özetliyorum. Rollback, Secure Builds, az webapp exec, Node.js tanılama ve Network Capture kayıt sırasında preview olarak tarif edildi. Bu yüzden buradaki anlatımı bir duyuru gibi değil, gösterilen davranışın aktarımı olarak okuyun.
Platform Release Channel: yamayı ne zaman alacağınızı seçmek
Runtime yamaları güvenlik düzeltmeleri ve platform iyileştirmeleri getirir, ancak bazı uygulamalar yeni bir patch seviyesine geçmeden önce doğrulama ister. Platform Release Channel, Linux uygulamalarına güncelleme temposunu seçme imkanı veriyor.
| Kanal | Amaç |
|---|---|
| Latest | Yeni yamaları ilk alan kanal. Erken doğrulama için düşünülmüş; production iş yükleri için tasarlanmadı. |
| Standard | Varsayılan kanal. Normal App Service yayılma temposunu izler ve çoğu production uygulaması için önerilir. |
| Extended | Daha geride kalarak ek doğrulama süresi sağlar; tipik olarak Standard’ın bir sürüm gerisindedir. |
Demoda aynı.NET uygulamasının üç kopyası, her biri farklı bir kanalda çalıştırıldı. SCM (Kudu) üzerinden runtime sürümleri incelendiğinde Latest → Standard → Extended ilerleyişi somut biçimde görülüyordu. Görülen sürümlerin yayılma sürecinin o anki fotoğrafı olduğunu atlamayın; kalıcı olarak sabitlenmiş sürümler ya da sabit bir güncelleme takvimi söz konusu değil.
Ekibin önerdiği pratik desen, production’ı Standard kanalında bırakıp bir deployment slot’u Latest kanalına almak ve yaklaşan yamaları orada test etmek. Kanal seçimi slot bazında farklılaşabiliyor. Sunumda ayrıca kanal değiştirmenin uygulamayı yeniden başlattığı (recycle) ve ilgili runtime imajına geçildiği belirtildi.
Kanalı Azure portalında Stack settings altından ya da Azure CLI ile ayarlayabilirsiniz. Varsayılan kanalı açıkça seçmek için:
az webapp update \
--resource-group <resource-group> \
--name <web-app> \
--platform-release-channel StandardKanallar yamanın ne zaman geleceğini kontrol eder; runtime güncellemelerinden süresiz kaçınmanın bir yolu değildir. Doğrulama planınızı, belirli bir yamanın bir kanalda kalacağını varsayarak değil, yayılma takvimine göre kurgulayın.
Quick Deploy, rollback ve Secure Builds
Quick Deploy, ZIP yüklemeyi doğrudan Azure portalındaki Deployment Center içine taşıyor. Paketi inceleyebiliyor, dağıtım öncesinde sunucu tarafı build çalıştırıp çalıştırmayacağınızı seçebiliyorsunuz. Başlangıç ve test senaryoları için pratik bir yol, ama tekrarlanabilir production dağıtımları için yine CI/CD hattı kullanılmalı.
Oturumda çalışan bir sayfayı bozuk sürümle değiştiren bir ZIP paketi yüklendi, ardından SCM (Kudu) içindeki preview Rollbacks deneyimi açıldı, saklanan önceki dağıtımlardan biri seçildi ve eski paketi yeniden yüklemeye gerek kalmadan çalışan sayfa geri geldi.
Demoda güncel dağıtım ile iki önceki sürüm görünüyordu. Sunucular, saklama süresinin kullanılabilir dosya sistemi alanına bağlı olduğunu belirtti. Yani bunu “her uygulamada her dağıtımın geri alınabileceği” garantisi saymayın, gösterilen bir kurtarma akışının önizlemesi olarak değerlendirin. Sürümlenmiş release artifact’lerini saklamaya ve production yayın sürecinde deployment slot kullanmaya devam edin.
Secure Builds ile bileşen zafiyetlerini görmek
Ekip ayrıca Secure Builds özelliğini önizledi. Dağıtıma özgü bir rapor, kullanılan bileşenleri GitHub güvenlik danışmanlıklarıyla eşleştiriyor; bir bulguya tıklandığında ilgili advisory açılıyor ve geliştiriciye düzeltme için bir başlangıç noktası veriyor. Gösterilen deneyimde bulgular raporlanıyor, dağıtımı engellemiyordu.
Rollback ve Secure Builds kayıt sırasında preview olarak tanımlandı. Bunların güncel bölge, plan, runtime ve dağıtım yöntemi kapsamı yayımlanmış dokümantasyonda bağımsız olarak doğrulanmadı; bu yazı yalnızca gösterileni aktarıyor.
Container’ı yeniden derlemeden sorun gidermek
SSH sunucusu olmadan terminal açmak
Custom Linux container’larında eski WebSSH deneyimi için imajın kendi SSH sunucusunu barındırması gerekiyordu. Tulika, böyle bir yapılandırması olmayan bir container gösterdi: eski bağlantı yöntemi başarısız oldu, ancak az webapp exec çalışan uygulama container’ında başarıyla bir shell açtı.
Komut, Azure CLI 2.90.0 ile preview olarak kullanılabiliyor ve Windows, macOS ile Linux’ta yerel terminali tutarlı şekilde kullanıyor. Güncel bir Azure CLI kullanın ve imajınızda var olan bir shell seçin:
az webapp exec \
--resource-group <resource-group> \
--name <web-app> \
--shell /bin/shOturumda SCM (Kudu) içindeki Try the new terminal seçeneğinin de aynı container’a bağlandığı gösterildi. Bu platform yolu, imaja SSH daemon kurma veya imaj içine SSH kimlik bilgisi gömme ihtiyacını ortadan kaldırıyor. Platform yayılması tamamlanana kadar kullanılabilirlik değişebilir.
az webapp exec etkileşimli shell dışında detached (ayrık) çalıştırmayı da destekliyor. Sunucular, gerekli ağ erişimine zaten sahip bir uygulama örneğinden tek seferlik veritabanı migration’ı çalıştırma senaryosunu tartıştı. Kritik ayrıntıyı atlamayın, accepted yanıtı yalnızca isteğin kabul edildiğini gösterir, komutun başarıyla tamamlandığını değil. Detached çalıştırma komutun çıktısını veya exit code’unu döndürmez.
Shell erişimi ayrıcalıklı bir operasyonel yetenektir. İhtiyacı olmayan uygulamalarda erişim sshEnabled yapılandırma özelliğiyle kapatılabilir.
CPU ve bellek belirtilerinden kanıta geçmek
Linux üzerindeki Node.js uygulamaları için ekip, SCM (Kudu) > Diagnostic Tools altındaki CPU ve bellek tanılamasını gösterdi. Yerel analiz için bir artifact toplayabiliyor ya da Collect & analyze ile yerleşik bir rapor üretebiliyorsunuz.
Bellek raporu, şüphelenilen bir sızıntıyı daraltmaya yardımcı olabilecek büyük string’leri, closure’ları ve dizileri öne çıkardı. CPU demosunda ise uygulama boştayken alınan bir yakalama ile yüksek CPU etkinliği ve event loop bloklanması tespit eden bir yakalama karşılaştırıldı. Bu raporlar otomatik bir çözüm vermez, araştırma için ipucu sağlar.
Bellek dökümü (memory dump) tek bir ana ait fotoğraf çeker, CPU profili ise seçilen bir aralık boyunca etkinliği gözlemler. Dolayısıyla kanıtı sorun yaşanırken toplayın. Dump’lar depolama tüketir, toplama ve analiz işlemi de uygulamanıza hizmet veren örneği etkileyebilir. Sunucular kısa süreli yakalamalar yapmayı ve uygun olduğunda sorunu, trafiğin kontrollü bir bölümünü alan bir deployment slot üzerinde yeniden üretmeyi önerdi.
Kayıt sırasında bu tanılama deneyimi, önce Node.js desteğiyle yayılan bir preview olarak tanımlandı. Aynı CPU ve bellek araçlarının her Linux runtime’ında hazır olduğunu varsaymayın.
Backend bağlantı hatalarını uygulama hatalarından ayırmak
Network Capture demosunda, bir backend’e ulaşmaya çalışırken hata döndüren bir uygulama incelendi. Üretilen rapor başarısız TCP handshake’leri ve retransmission’ları gösterdi, böylece dikkat yalnızca frontend web sunucusuna değil bağlantı yoluna yöneldi.
Network Capture, App Service for Linux için preview aşamasında ve SCM (Kudu) içinde isteğe bağlı yerleşik analizle toplama yapılmasını destekliyor. Yayımlanmış dokümantasyon ayrıca, dedicated App Service planlarındaki Linux web uygulamaları için az webapp troubleshoot collect network-capture ile Azure CLI desteğini tanımlıyor. Oturumda ek CLI tanılamalarının yolda olduğu da konuşulmuştu.
Yakalamalar seçilen bir uygulama örneğini hedefler, 100 MB‘ta durur ve en fazla 300 saniye sürebilir. HTTPS trafiği şifreli kalır. Paket yakalamaları hassas uygulama verisi içerebileceğinden buna uygun şekilde saklanmalıdır. Analizi uygulama örneği üzerinde çalıştırmak istemiyorsanız Collect only seçip .pcap dosyasını indirerek incelemeyi yerelde yapabilirsiniz.
Özetle ne değişiyor
Oturumun ortak teması, operasyonel kararları uygulamayı yeniden paketlemeden alabilmek. Yamayı ne zaman alacağınızı kanal seçimiyle, hatalı bir dağıtımdan dönüşü saklanan sürümlerle, container’a erişimi SSH daemon kurmadan platform üzerinden, performans ve ağ sorunlarını ise imajı değiştirmeden toplanan kanıtlarla ele alabiliyorsunuz. Preview niteliğindeki parçalar için kapsamı kendi bölge, plan ve runtime’ınızda doğrulamak yine de gerekiyor.
Kaynaklar ve İleri Okuma
- Azure App Service Community Standup: Platform Release Channels & WebSSH (orijinal yazı)
- Oturumun YouTube kaydı
- Platform Release Channel ile runtime yama güncellemelerini yönetme
- Azure portalından ZIP paketi dağıtma (Quick Deploy)
- Azure CLI 2.90.0: container erişimi ve Linux sorun giderme
- Linux’ta Node.js uygulamalarında CPU ve bellek sorunlarını teşhis etme
- Linux’ta ağ izlerini yakalama ve analiz etme
- az webapp troubleshoot collect komut referansı
- Azure Portal’dan ZIP ile App Service Dağıtımı
- Azure App Service Linux’ta Startup Log Komutları
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder