Skip to main content

Serverless automation using PowerShell Core in Azure Functions – Bölüm 2

· 5 min read
Hasan Gural

Fonksiyonlarımız için ne tür Triggers ( tetikleyiciler) kullanabileceğimizden bahsettik ve örneklerini anlattık. Şimdi hız kesmeden Bindings (tam türkçeye çeviremiyorum. Bağlar/Bağlantılar) kavramına açmak istiyorum. Bindings size fonksiyonunuz içerisinden verilere bağlanmanız için bir yol veya yöntem için yardımcı olurlar. Bir önceki yazımızda bildiğimiz gibi Triggers ( tetikleyicilerin ) bize geliştirdiğimiz fonksiyonun hangi servisler tarafından tetiklenebileceğini söyleyebiliyorduk. Örneğin, Azure Queue Servisi ile fonksiyonunuz tetiklenmesini ( yani çalışmasını/aksiyon almasını ) sağlayabiliyoruz. Fakat bu tetiklemeden sonra Storage Queue servisinden gelen veri bizim için fonksiyonun içerisindeki parametreye atanıyor. Bindings kullanmak zorunda değiliz fakat kullanma senaryomuzu biraz daha açmak ister isek, Storage Queue'den bir mesaj geldiği zaman tetiklenecek olan Azure Fonksiyonumla beraber Storage Table tuttuğum transcation verileriminde bindings kullanarak bir parametreye atanması sağlayıp, daha sonra bu verileri karşılaştırabilir ve fonskiyonumun onun sonuca göre çalışmasını sağlayabilirim. Bindings tamamen isteğe bağlıdır. Bu yüzden karşımıza farklı Bindings türleri çıkıyor olacak. Bir önceki yazımızda herhangi bir kod yazmadan tetikleyen servise erişmemizi sağlayacağından bahsetmiştik. Bindings sayesinde yine farklı servislere kod yazmadan erişip bir parametreye atayıp veriler elde edebilir ve onları değerlendirebiliriz.

Yukarıda gördüğünüz ekran görüntüsünde en sol kısımda Bindings tiplerini göreceksiniz. Görüntünün en sağ tarafında ise son iki sutünda Input ve Output şeklinde iki tane kavram karşımıza çıkıyor olacak şimdi bunları anlamaya çalışalım. Öncelikle Function trigger eden bir Queue Storage olsun, bu kısımdan akan mesaj bize parametreye atanması gerçekleştirelecektir.Ama Trigger tarafından tetiklenen fonksiyon sırasında yukarıda desteklenen Input Bindings gelen servislerden Azure fonksiyonu içerisine veriler elde etmemiz mümkün. Bindings isteğe bağlıdır ve bir fonksiyonun talebe göre bir veya daha fazla Input ve / veya Output bindings (bağlaması) olabilir.

Input Bindings: Function – Trigger tarafından tetiklendikten sonra alınmak istenen veriler için kullanılır. Input Bindings tanımlaması yapılırken (IN) olarak görebilirsiniz. Table Storage'dan okunacak veriyi almak için örneğin 'Input' tipinde binding tanımlanırlar.Yukarıda tablo'da desteklenen Input Binding'lerden ancak veriler alabilirsiniz.

Output Bindings: Trigger tarafından fonksiyonunuz tetiklendi ve talebinze göre Input Bindings tanımlayarak başka servisten veriler alma şansınızda vardı. Aynı şekilde fonksiyon bittiği zaman desteklenen servislere Output Bindings kullanarak veri gönderebilirsiniz.

Not: Yukarıda resim içerisinde farklı bir örnek bulunmaktadır. Trigger tarafından tetiklenen Azure Function daha sonra Input ve Ouput Bindings kullanarak çalışma sürecini tamamlayıp işlevini gerçekleştiriyor. Yazılarımız devam ettikçe Bindings atamasını fonksiyon bazında 'function.json' dosyasından yönettiğimize şahit olacaksınız. Bu dosya tamamen Bindings yönetimi ve diğer konfigürasyonlar için her fonksiyon özelinde bulunmalıdır.

Genel anlamıyla fonksiyonlarınızın temel yapı taşları olan özelliklerinden bahsettim. Makale başlığımızdan çıkmadan 'Serverless automation' hakkında konuşmaya başlayabiliriz. Neden Azure Functions App seçmeliyiz diye düşünme zamanı olduğunu düşünüyorum. Şu zamana kadar konuştuklarımız aslında Azure Servisleri ile çok kolay bir şekilde entegre olup servisler arası veri okuma sağlamak, etkileşim haline geçmek, servisler ile içli dışlı olmak için minumum seviyede kod yazmak gibi düşünebiliriz. Fakat bunu Infrastructure seviyesinde düşünebilirsek Powershell Core ve arkamıza Azure Functions App alıp tüm bu özelliklerden faydalanabilirsek harika şeyler ortaya çıkabilir. Hemen gelin beraber biraz örnekler üzerinden konuşalım.

Event-Based Automation hakkında örnekler

Örnek 1: Event Grid servisini kullanarak, Azure Resource Group içerisinde yapılan olayları ( Write, Delete, Action ) dinleyip ve bunları alıp Azure Functions içerisine gönderebiliyoruz. Şu şekilde genişletelim, Azure aboneliğiniz bulunmakta, Resource Group oluşturulduğu zaman yapılan işleri alıp, Azure Functions gönderebilme şansınız var. ( Azure Functions Trigger – Event Grid ). Aşağıda görebilemeniz için bir resim bırakıyorum. Aslında bu bize, Azure aboneliğinizin, Event Grid içerisine Subscribe olmasını sağlayan adımlardan bahsediyor. Bu işlemleri yaptıktan sonra Azure Subscription içerisinde oluşacak her yeni olay ( yani Event ) Event Grid' tarafından alınacak ve talebinize göre, Azure Functions içerisine gönderebileceksiniz. Peki bunları yapmam bana ne tür fayda sağlar? Abonelikten bu bilgilerin Azure functions akmasında amaç nedir diye düşünürseniz, işte bu kısımda artık 'Event-Based – Automation' başladınız demektir. Örneğin Bu adımları gerçekleştirdiniz, abonelik üzerinde yeni bir Resource oluşturuldu ve onun içerisinde meela 'Tags ( Etiket )' ataması yapmak isteyebilirsiniz, veya farklı bir örnek yeni bir Resource oluşturuldu, bu resource tipine göre farklı kontroller yapmak istiyor olabilirim. Azure Policy, Azure Web App üzerinde bir çok kontroller, yeni bir kaynak yaratıldığı zaman, CMDB ile varlığını kontrol etmek vb adımlar gerçekleştirebilir.

Örnek 2: Event-Based automation özelinde somut bir kavram bulmak çabasına girelim, özetle Infrastructure ortamında şu tipte bir olay olduğu zaman şu servislerin çalışması gerektiğini ve onları olay gerçekleştiği zaman çözümleyici olduğunu söylemek yeterli olabilir. Farklı bir örnek olması açısından, örneğin Azure Active Directory özelinde 'Diagnostic Settings' sekmesinden 'AuditLogs', 'SignInLogs' izleyebiliyoruz. Bunları dilerseniz Azure Log Analytics Workspace, Storage Account veya Event Hub gönderme şansınız var. Burdan gelecek tüm events(olayları) Azure Functions tetikleyip istediğimiz kontrolleri yaptırabiliriz.

Örnek 3: Azure Sentinel bildiğimiz gibi Cloud- Native bir SIEM hizmeti ve bu servis üzerinden gelen veriyi Event Grid üzerine gönderip, ihtiyacımız olan kısmı ile Azure Functions tarafından işlenmesini sağlayabilir buda bize herhangi bir olayla karşılaştığımız zaman almamız gerek aksiyonu otomatikleştirmemize olanak sağlayan farklı bir örnek.

Örnek 4: Event-Based Automation sadece Azure functions olarak düşünülmemelidir. Azure Logic Apps– Servlerss workflow hizmeti olarak karşımıza çıkıyor ve bir çok Azure Servisi ile native bir şekilde connectorleri sayesinde entegrasyon yapabiliyorsunuz. Azure functions zorlandığı yerde, Azure Logic Apps çağırıp veya Azure Functions Logic Apps içerisinde kullanabilirsiniz. Bu tarz özelliklere Azure Active Directory üzerinde yaptığınız event-based automation süreçlerinde denk gelebilirsiniz.

Örnek 5: Scheduler Trigger sayesinde Azure Function – Hybrid Connection özelliği sayesinde sadece Azure kaynaklarınıza değil, On-Premise loksayonunuzda sanal sunucu ve diğer kaynaklarınız üzerinde işlem yapabilirsiniz. Hybrid Connection bir nevi sizin On-Premise bağlamak için kullanılan bir agent gibi düşünebilirsiniz. O yüzden Event-Based automation sadece azure özelinde değil – Hybrid ve Cloud automation olarak düşünülmelidir.