Bir önceki yazımızda Custom Resoırce Providers kavramını tanımlamak ve ona bağlı olan komponentleri anlamak ile ilgilenmiştik. Bu yazımızda ise, Custom Resource Providers tanımlamasının nasıl olduğundan bahsediyor olacağız.

Custom Resource Provider nasıl tanımlanır?

Custom Resource Providers, Azure ile endpoint (Azure Function) arasında karşılıklı ilişkileri tanımlayan bir listedir. Bu karşılıklı tanımlamalar Azure'un herhangi bir endpoint ile nasıl etkileşime girmesi gerektiğini açıklar. Custom Resource Provider'lar bir proxy gibi davranır ve belirtilen endpoint için gelen istekleri alır ve yanıtları onlara iletir. Bu kısımda endpoint arkasında çalışan bizim geliştirdiğimiz bir adet Powershell Core yazılmış Script olduğunu düşünelim ve onu Azure Function hizmetine deploy edip, endpoint olarak kullanacağız Azure Function olmasının sebebi tamamen Azure Servislerinden faydalanmak. Bir Custom Resource Provider iki tür sözleşme/tanımlar modeli belirtebilir bunlar sırasıyla;

• resourceTypes
• Actions

Bunlar endpoint tanımlarını belirtirken kullanılır ve her ikiside farklı API özellikleri bizlere sunar ve onlar aracılığıyla etkileşim içine geçilebiliriz.

• name,
• routingType
• endpoint.

Yukarıda gördüğünüz, bir endpoint tanımının alması gereken öznitelikler yani propertyleri görebilirsiniz. Bu property'lerin ne iş yaptıklarına kısaca göz gezdirelim.

Tablo içerisinde bahsettiğimiz ve yukarıda ki örnek JSON dosyası içerisinde sıradan bir Endpoint tanımlasını nasıl yapmamız gerektiğinden bahsettik. Şimdi ise bu endpoint tanımlasını Azure Resource Manager içerisinde nasıl kullanabileceğiz ve nasıl Custom Resource tanımlası yapabiliriz buna beraber bakalım. Öncelikle Custom Resource için Resouce Types anlaşma/tanım özelliğini kullanılım. Aşağıda gördüğünüz tanımın temelinde bize yeni bir API sunar ve tüm operasyonunda RESTful özelinde Create, Read, Update, Delete (CRUD) yöntemlerini ortaya koyar ve destekler.

Yukarıdaki tanımladığımız JSON içerisinde artık Azure API bu detayları gönderdikten sonra Custom Resource ile nasıl iletişime geçeceğini ve eklenen API Detayları aşağıda bulabilirsiniz. Girdiğiniz resourceType adına göre Azure REST API gerekli CRUD işlemleri için API tanımlamaları yapılacaktır. ResourceType olarak kullanılan Custom Resource Provider tipinde yapılan istek sonrası endpoint kesinlikle Id, Name ve Type göndermelidir. Bunlar sırasıyla,

• Id: "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CustomProviders/resourceProviders/{customResourceName}",
• Name: "{customResourceName}",
• Type: "Microsoft.CustomProviders/resourceProviders/{resourceTypeName}"

Bunların detaylarını geliştirmiş olduğum Powershell code bloğu içerisinde bulabilirsiniz. Return Response olarak bu değerleri geriye dönmeniz gerekiyor, Deployment sürecinin başarılı tamamladığını anlatmak için Azure API tarafına göndermeniz şart.

Custom Resource Provier için Custom Actions nasıl tanımlanır?

Daha öncede söylediğimiz gibi iki adet farklı karşılıklı anlaşma modelimiz var idi. Bunlardan diğeri olan Custom Actions en basit haliyle, Custom Resource Provider tanımlamasını yaptığımız zaman Azure bize, Action için bir Rest API sunar ama sadece Post methodunu destekler. Yazı serimiz boyunca ResourceType tanımı üzerinde yoğunlaşıp onu kullanarak endpoint kullanımı gerçekleştireceğiz.

Yukarıdaki örnekte bir Actions tanımlaması Custom Resource Providers için görebilirsiniz. Bu tanımlama ile bahsettiğim gibi, Custom Resource Providers için RESTful operasyona denk gelen aksiyonları belirtip endpoint talepleri iletebileceğiz. Tanımlanan Actions ile aşağıdaki API Detayları elde edilebilir.

Actions olarak kullanılan Custom Resource Provider tipinde yapılan istek sonrası endpoint kesinlikle aşağıda bulunan geçerli tipte veriler döndürmelidir. Bunlar sırasıyla,

• Content tipi: "application/json; charset=utf-8" olmalı.
• Geçerli bir JSON formatında, object array.

Custom Resorce Provider özelinde Resource Type ve Actions tipinde farklı karşılıklı anlaşma modellerinin nasıl yapılacağını gördük, aralarındaki farklılıklardan bahsettik ve artık ön gereksinimlerimize geçebiliriz.

Azure Functions hizmetine ihtiyacımız var çünkü bizim için bir endpoint gibi davranıp Custom Resource Provider tarafından gelen eylemleri işleyip Azure Function içerisinde çalışan Powershell Function veya Script artık nasıl bir süreç yönetmek istiyorsanız sizin isteğiniz doğrultusunda aksiyon almasını sağlayacağız. Makale içerisinde sizleri Azure Function nasıl oluşturulur, neler yapmanız gerektiğini bilmenize gerek kalmadan kendi gitHub hesabım üzerinden Azure Resource Manager Template'lerine erişebilir ve hızlıca kendi ortamınıza dağıtabilirsiniz. Bu yüzden Azure Function nasıl oluşturacağım, nelere dikkat etmem gerekiyor gibi sorunlara sizi boğmadan Azure Function oluşturmak için aşağıdaki adımları seyrederseniz çok hızlı bir şekilde Custom Resource Provider için bir endpoint tanımlaması gerçekleştirebilirsiniz.

Azure Function Dağıtım adımları için lütfen aşağıdaki adımları takip ediniz.

Gördüğünüz gibi Deploy to Azure butonuna bastığınız zaman sizler için yayınladığım Azure Function hizmetini deploy ediyor olacak. Function içerisinde geliştirdiğim, StartContainer isimli Function job tanımlanmış olacak. Bu sayede bunu Custom Resource Provider kullanabilirsiniz. Deployment başarılı olduğu zaman sizin için bir Deploy ettğiniz Function adında bir adet App Registration oluşturacak ( Service Principal Account ) bunun demo ortamı için azure hesabınıza yetkilendirmesini yapmanız gerekmektir. Daha fazlası için gitHub sayfamı takip edebilirsiniz. Özetle bu function depoy ederek, endpoint tanımlamasının bir şablon halinde hesabınıza dağıtarak kullanmaya başlayacaksınız.

Aşağıdaki paylaştığım Azure Function içerisinde Powershell Core ile geliştirmiş olduğum bir kod bloğu var, yaptığı işi kısaca özetlemek gerekir ise gelen talep doğrultusunda bir adet container oluşturup console içerisine birşeyler yazdırmak. Tahmin edebileceğiniz gibi bunu zaten Azure Resoırce Manager Templateleri ile yapabiliyoruz ama burada vermek istediğim örnek tamamen sizin hizmetinize özel geliştirmiş olduğunuz Custom Resource Provider için belirli bir nitelikler göndererek ( endpoint'e yani Azure Function uç noktasına) bu değerler Azure Function tarafından işlenip sizin için bir aksiyon almasını sağlamak. Yani özetle Azure deneyimini bozmadan, Azure Resource Manager üzerinden abonelik içerisinde Custom Resource Provider register edip, sadece talep edilen propertyleri göndermek olacak. Aşağıda bulunan kod bloğunu incelediğiniz zaman request edilen container adında hızlıca bir ACI oluşturup console üzerine birşeyler yazıyor olacak.

Bir sonraki yazımızda Azure Function ve Custom Resoırce Provider için yapmamız gereken yapılandırmalara devam edeceğiz.

Bir süredir yazmak istediğim seri ile karşınızdayım. Öncelike seriyi okumadan önce lütfen Mshowto Blog'u üzerinde ve internette takip edebileceğiniz Azure Resource Manager Template isimli yazıları okumanızı tavsiye ederim. Eğer Azure Resource Manager az bir seviyede aşina iseniz, bununla beraber kendinizi DevOps kültürünün bir parçası olduğunuzu farkettiğiniz zaman Infrastrature As Code ile uğraşmaya başladınız demektir. Temel amacımız bu yazı seri içerisinde vermek istediğimiz veya aktarmak istediğimiz konu Azure Resource Manager'ın bir parçası olan Custom Resource Provider kullanarak ve işin içerisine son zamanlarda gözde servisimiz olan Azure Function dahil ederek bu muhteşem ikilinin aralarında bulunan çalışma ilişkisini göstermek olacak. Bu terimleri yazımızın ilerleyen kısımlarında tek tek açıklıyor olacağım.

Custom Resoırce Provider tanımına geçmeden önce hızlıca Azure Resource Manager ve Azure Functions konularından bahsedelim. Öncelikle Azure Resource Manager Template dağıtım modelini kullanmanın avantajlarından kısaca bahsedelim. En basit haliyle Azure Resource Manager Template dağıtım modelini kullanarak geliştirmiş olduğunuz JSON ( declarative syntax ) ile tekrar edilebilir, validate edilmiş, DevOps kültürüne uygun olarak deployment patternleri hazırlayabilir ve tekrar tekrar kullanmaıza yardımcı olur. Green Field bir deployment yaptığınız zaman veya hali hazırda mevcut bir ortamınız için geliştirilmiş olan Azure Resource Template'lerini Dev, UAT, Production ortamlarınız için tutarlı deployment pattern hazırlayabilirsiniz. Bildiğiniz gibi farklı deployment araçları kullanarak Terraform, Ansible(her ne kadar configuration as code giriyor olsada IaC ve CaC ) olarak da kullanabilir) dağıtım yapabilirsiniz.

Azure Resource Manager templateleri daha önce dediğimiz gibi bize tutarlı, tekrar edilebilir, moduler hale getirilmiş, validate edilmiş ve CI/CD süreçlerine entegre olurken çok farklı avantajlar sağlıyor. Deployment süreçlerini yönetirken hangi tool ile bu işi sırtlanmanız gerektiğini siz belirleyebilirsiniz. Daha öncesinde farklı deployment aracı olan Terraform video serisimize Bulut Bilişim Çözümleri ve Ötesi isimlı youtube kanalı içerisinden bakabilirsiniz.

Azure Function ile ilgili yaklaşık iki sene önce bir yazı yazmıştım ama o kadar hızlı değişiyor ki yetişmek mümkün değil. Uzun bir süredir Azure Automation kullanarak schedule edilen standard tasklarımı veya WebHook kullanarak request ettiğim custom süreçlerimi öncelikli olarak Azure Automation içerisinden yönetiyordum ancak oyuna Azure Function hizmetinin Powershell desteği ile girmesiyle beraber şimdi ise iki tarafıda yoğun olarak kullanıyorum fakat Serverless Automation kavramında Azure Function oyuna dahil olduğu için bu Azure Function hizmeti içerisinde Powershell kullanmayı daha çok tercih etmeye başladım şu sıralar. Azure Functions en çok DevOps tarafında Servleress Automation olarak karşımıza çıkıyor ve EventGrid, Storage Queue veya Services Bus ile yaptığınız entegrelerde inanılmaz sonuçlar alabilirsiniz. Bu konuyu başka bir yazıda ele alacağım. Muhtemelen Event Driven Orchestration dünyasının nimetlerinden faydalanmamak imkansız gibi gözüküyor.

Azure Function kendi içerisinde v1 ve v2 olarak ikiye ayrılmakta, yeni bir Azure Function oluşturmak istediğiniz zaman hangi versiyonu seçmeniz gerektiğinize emin olmalısınız. Temel anlamıyla, v1 Powershell Core desteklemiyor. Powershell Core kullanmak istiyorsanız v2 ile devam etmenizi tavsiye ederim. Sebebi ise Powershell Core dışında, Azure Function v2 bize çok fazla kolaylık sağlıyor, en temeli custom bir Powershell Modülüne ihtiyacınız olur ise bunları yönetmek için Dependancy Management kullanarak Package Management üzerinden Custom Powershell Modüllerini alabilir veya Managed Identiy tadına vararak Azure Function code bloğunuzun çalışırken karşılaşacağı authentication sorunlarını kolayca atalabilirsiniz.

Şimdi tekrar Azure Function hizmetini nimetlerine dönmeceğim ama önce artık Custom Resource Provider nedir, ne için kullanabiliriz bunu biraz daha açalım. Bunları şu cümleler ile özetleyebiliriz.

Öncelikle şunu bilmenizi isterim ki, Custom Resource Providers henüz release olmadı. Birkaç cümle ile Azure'da bulunan Publisher'lar yani Vendor veya Partner artık nasıl çağırmak isterseniz onların hizmet vermek istediği müştlerine kaynaklarını dağıtmak, configure etmek için bir yol sağlamaktır. Kullanıcıların Azure dışından gelen kaynaklar için eylemler tanımlamasına izin verir ve bunları Azure Resource Manager şablonu ile dağıtımına yardımcı olur. Senaryoyu biraz daha açmak gerekir ise düşünseniz F5 bir load balancer deploy etmeye çalıştığınız firmanın bir takım orkestrasyon yapması gerekir dağıtılan kaynaklar içerisinde işte tam bu noktada Azure Custom Resource Provider yardımımıza koşuyor. Azure Managed Application detaylarına baktığınız zaman Custom Resource Provider ile ilişkisi olduğunu göreceksiniz. Aslında cevap çok basit, eğer custom bir uygulamanız var ise ve bunu Market Place üzerinden hizmet vermesini istiyorsanız Custom Resource Provider kullanarak Custom Resource için API'lar yayımlayabilir ve kullandırabilirsiniz.

• Azure Resource Manager REST API - isteğimiz doğrultusunda genişletebiliriz. Bunlar organizasyonuza bağlı olarak tasarlanan uygulamalar Internal ve External hizmet sağlayıcıları olabilir.
• Mevcut Azure Deployment süreçlerinizde ihtiyacımız olan özel yapılandırmaları otomatikleştirebiriz.
• Azure Resource Manager Template kullanarak daha fazla denetim altına alabilir ve etki eden deployment süreçlerini daha detaylı kontrol edebiliriz.

Daha fazla örnekleri genişletmemiz gerekir ise sizin bir uygulamanız var bir servis sağlayıcı olarak bu uygulamanızı Azure üzerinde kullanan müşterinize sunarken bir deployment süreçinden geliştirmek istiyorsunuz. Bu herhangi bir third-party uygulama, firewall, aklınıza gelebilecek Azure kaynaklarına dokunna her türlü bir süreç olabilir. Siz bir partner olarak hizmetleriniz var bunları Azure Resource Manager üzerinden dağıtabiir hale getirmek istiyorsunuz ve arada yer alan dağıtım süreçlerini otomatik hale getirerek tamamlamak istiyorsunuz. Benim yakın zamanda yaptığım ve Pre-Production bir sistemde kullanmak olduğunuz Custom Resource Providers kullanarak bir dağıtım yönetimden bahsetmek istiyorum tamamen internal-organizasyon içerisindeki istekler özeli dahilinde kullanıyoruz.Bir Custom Resoırce Provier geliştirdik fakat bu sadece şirket içerisindeki departmanlara hizmet veriyor. En basit haliyle, şirket içerisinde farklı departmanlar var bu departmanların kendi özgü kaynakları abonelikleri olduğunu düşünün. Departmanların isteği doğrultusunda kendi ortamlarına kolayca Jumpbox VM ihtyaçlarını olduğunu ve bunu yine basit bir Azure Resource Manager Template ile kullanabildiklerini ama arkadaki bir çok automation süreçlerini çok fazla soru sorulmadan kolayca ve güvenli bir biçimde halledildiğini düşünün.

Özetle; Bu servisi ben {Jumbox-On-Demand} olarak çağırıyorum. Business Departmanlar merkezi olarak kendi ihtiyaçları doğrultusunda Jumbox on demand hizmetini talep etmek için Azure Resource Template kullanıyorlar ama bu template içerisinde kullanmak istedikleri Azure kaynakları tek tek tanıtmıyorlar, sadece template hizmeti veren ekip tarafından geliştirip, talep edilen parametreler aslında Azure Function içerisine Post ediliyor ve deployment tamemen Azure Function üzerinden kontrol ediliyor. Azure Resource Manager Template'ler sadece bu noktada endpoint ( Azure Function) olarak tanımlamak için ve talep edilen parametrik değerli almak için kullanılıyor. Eğer aşağıda süreçleri düşünürseniz, bu işleri yapmak için basit bir kullanıcının nelere yetkili olması gerektiğini farkına varabilirsiniz. Bu yüzden business departman kullancısı sadece istediği talebi Azure Resource Manager içerisinde tanımlı olan Custom Resource Provider resource'una iletip daha sonrasında Azure Function endpoint'ine gönderiyor ve tüm kontroller, authentication ve authorization Azure Function tarafında yazdığınız Powershell Script tarafından kontrol edilecektir. Senaryonun bir tık ilerisi aslında aynı Azure Function hizmetini, ITSM hizmetleri ile birleştirmekten ibaret yani aynı talebi firmanın talebi ile beraber ServiceNow gibi hizmetlere entegre edebilirsiniz sebebi ise Azure Function geliştirdiğiniz Powershell bloğunuz bir Rest API gibi davranabilir ve önüne Azure API Management hizmetini koyabilirsiniz.

• Creating - Virtual Machine – Sanal Makine oluşturma
• Impelementing – Disk Encyrption – Oluşturulan Sanal Makineyi Disk Encryption süreçlerini otomatik hale getirme
• Creating Firewall Rules on Firewall for spesific IP Ranges. Oluşturulan sanal makine için Firewall üzerinde ingress kurallar tanımlama ( belirtilen source adresler üzerinden)
• Creating CIS Based Imaged – Enrolling Azure Automation Account to get latest DSC Configuration – CIS Image ( Hardening olaması için geliştirdiğim DSC Config alabilmesi için Azure Automation otomatik register etmek)
• Automatically Enroll to Backup Vault – Jumbox amaçlı oluşturulan sanal makinenin Azure Backup Vault içerisine otomatik olarak kaydedilmesi
• To Schedule – Azure Runbook for deleting and redeploying Jumpbox. Deployment süreçinde Azure Automation DSC ve Runbook özelliğinden faydalanılıyor. Mevcut bir Runbook ile güvenlik gereksinimlerinden dolayı her 30 günde bir dağıtılan Jumpbox silinip tekrar oluşturup domain ortamına dahil ediliyor.

Diğer bir örnek verebilecek olur ise, Custom Resource Provider ile mesela, Azure Active Directory tarafında Group Oluşturmak, Group Member'ları ekleme çıkarma gibi değişik senaryolar yapabilirsiniz. Senaryolar oldukça genişletilebilir.Bir sonraki yazımızda Custom Resoırce Provider yapısını oluşturmak için temel bileşemlere bakıyor olacağız.

Her yıl düzenli olarak Nisan ayında tüm Dünya üzerindeki ülkelerde eş zamanlı gerçekleşen en büyük Azure etkinliği bu sene de 27 Nisan 2019 Cumartesi İzmir Yüksek Teknoloji Enstitüsü'nde gerçkleştirdik. MsHowto olarak İzmir lokasyonunda çok büyük bir kitleye seslendik. Konuşmacı olarak yer aldığım seminerde sevgili Fırat Yaşar ile birlikte Infrastructure with Terraform and Azure Pipelines isimli sunum ile katıldım. Keyifli bir organizasyon oldu. Katılım gösteren tüm herkese teşekkür ediyorum.

]

Her yıl Nisan ayında tüm Dünya üzerindeki ülkelerde eş zamanlı gerçekleşen en büyük Azure etkinliği bu sene de 27 Nisan 2019 Cumartesi günü gerçekleştiriliyor. Bu sene ise MsHowto ekibi olarak, İzmir Yüksek Teknoloji Enstitüsü'nde yerimizi aldık. Global Azure Bootcamp etkinlik haritasını ve lokasyonlarını bu linkten görebilirsiniz. Bu etkinlikte özellikle Microsoft Azure DevOps platformu hakkında edindiğim tecrübelerimi aktarıyor olacağım.

MCT (Microsoft Certified Trainer) olan Hakan Marangoz ile birlikte bu videoda The Hybrid Challenge konusu içerisinde Microsoft Hybrid agent ile yeni gelen özellikleri detaylı bir şekilde anlattık.Microsoft Hybrid agent ile Exchange Online hizmetine geçişlerin çok kolay olduğunu bu video içerisinde şahit olacaksınız. Video serisine ulaşmak için aşağıdaki kapak fotoğrafına tıklamanız yeterli olacaktır.

Microsoft Cloud and Datacenter Management MVP (Microsoft Valuable Professional) unvanına sahip olan Fırat Yaşar ile birlikte Infrastracture as Code yaklaşımını Terraform ile uygulayarak değerlendirdiğimiz ikinci içeriğimize videomuzdan ulaşabilirsiniz. Konunun devamı için Fırat Yaşar ile hazırladığımız diğer videomuza kanalımızdan ulaşabilirsiniz.

Microsoft Cloud and Datacenter Management MVP (Microsoft Valuable Professional) unvanına sahip olan Fırat Yaşar ile birlikte Infrastracture as Code yaklaşımını Terraform ile uygulayarak değerlendirdiğimiz birinci içeriğimize videomuzdan ulaşabilirsiniz. Konunun devamı için Fırat Yaşar ile hazırladığımız diğer videomuza kanalımızdan ulaşabilirsiniz.

Bulut Çözümleri ve Ötesinde, MCT (Microsoft Certified Trainer) olan Hakan Marangoz ile birlikte bu video içerisinde Azure AD Pass-through Authentication konusu detaylı bir şekilde anlattık.Azure AD Pass-through Authentication kullanarak Office 365 ile Single Sign on yapılandırmanın kolaylıklarını, artı ve eksi yönlerini videomuzda bulabilirsiniz. Video serisine ulaşmak için aşağıdaki kapak fotoğrafına tıklamanız yeterli olacaktır.

Bulut Çözümleri ve Ötesi Programı, Bulut bilişim ve bilgi teknolojileri dünyasında yer alan, bu alanlarda danışmanlık yaparak farklı bulut platformlarında kendilerini uzmanlaştırmış profesyonel kişilerin bilgi ve deneyimlerini objektif bir şekilde aktardığı, izleyicisine teknik bilgi vermeyi amaçlayan içeriklerden oluşmaktadır.Video içerikleri; Microsoft, Amazon, DevOps ve Open Source dünyasındaki yenilikleri ve teknik uzmanların deneyimlerini aktarmayı hedeflemektedir. Video serilerinde gerçek senaryolar üzerinden gidilerek, örnek uygulamalar yapılmaktadır. Kullanıcı deneyimlerinden çok ilgili bulut platformlarının sağladığı hizmetlere ilişkin detaylı teknik açıklamalara yer vermek, platformu kurmaktaki en birincil amacımızdır.

Cloud Solutions and Beyond Programme, which is involved in the world of Cloud Informatics and Information Technologies, consists of contents that aim to share the knowledge and experience of experts who have been consultant in these fields but also improved themselves in various cloud platforms or to provide technical informations for its own spectators.The main purpose of the contents is expounding informations and experiences of technical experts in platforms such as Microsoft,Amazon,Vmware and OpenSource. With following real scenarios in video series, instance implementations are being actualized. Rather than the end-user experiences, our first priority is to sharing technical explanations about services provided by the related cloud platforms.

Bildiğiniz gibi artık API kullanımının meşhur olduğu bir dünyada yaşıyoruz. Hemen hemen her incelediğim projede bir yerinde bir ucunda API ile iletişim haline geçip iş yapmaya çalışıyoruz. Bu yazı içerisinde biraz eğlenceli ve tuhaf ama keyifli bir konuyu aktarmak istiyorum. Microsoft Graph API bizlere Azure Active Directory, Office 365 Bileşenleri, Intune, Planner etc, içerisindeki istediğimiz kullanıcının özniteliklerine ulaşmayı ve bunları alarak raporlar oluşturmamıza olanak sağlanıyor. Bunu sadece kullanıcı bazında sınırlamamak lazım, Intune, Mobile Device Report gibi genişletebiliriz. Her türlü raporları bu API sorgular yaparak alma şansınız var. Office 365 tarafı ile ilgilinen arkadaşlar için, şimdilerde Powershell Module geçişleri yapıyorlar, ya da daha önceki yazdıkları kod bloklarını dönüştürmeleri lazım. Bunun başında, MSOnline adındaki module artık, AzureAD adındaki olan ve arka tarafta Microsoft Graph API v2.0 ( Beta ) olarak kullanılan sürüme dâhil edilerek geliştirilmiştir. Bu yüzden iki farklı Powershell Modulunu kullandığınız zaman farklı öznitelikler(propertyler) görebilirsiniz.

Powershell ile Microsoft Graph API kullanırken yukarıda bahsettiğim sadece belirli bir objeleri değerlerini getirmek ve raporlamak için değil daha farklı yöntemler içinde kullanabilirsiniz. Microsoft Graph API en basit haliyle REST API olarak Azure Active Directory erişim sağlayabilirsiniz. Bu sayede Azure Active Directory içerisindeki Applicationlar ( App Registrations) verdiğiniz izinlere göre, Azure Active Directory içerisindeki verileri okur, nesneler oluşturur, onların değerlini okur ve güncelleme ve silme işlemlerini gerçekleştirmek tamamiyle Azure AD Graph API'sini kullanabilir. Örneğin, Microsoft Graph API'na sorgu yaparak bir kullanıcı nesnesi için aşağıdaki değerleri döndürebilirsiniz; Bunları bir süreç olarak düşenebilirsiniz.

• User oluşturma, lisans ve manager atama, mobile device provision etmek,
• Assign to Office 365 Groups or Assign to Azure Active Directory Groups etc.

Özetle bu API sayesinde bir süreç haline getirip hayatımızı kolaylaştırabilirsiniz. Microsoft Graph API ile erişebileceğiniz servislerin hepsini özetlemek gerekir ise,

• Azure Active Directory
• Office 365 services
  • SharePoint, OneDrive, Outlook/Exchange, Microsoft Teams, OneNote, Planner, Excel
• Enterprise Mobility and Security services
  • Identity Manager, Intune, Advanced Threat Analytics, Advanced Threat Protection
• Windows 10 services
  • Activities, Devices
• Education

Daha farklı bir senaryo ise, siz Software as a Service veren bir firma olarak bu API müşterleriniz için kullanarak onların süreçleri için değişik uygulamalar geliştirme şansınız var. Daha önce farklı isimler ile duymuş olabilirsiniz, yada yukarıdaki tüm servislere farklı şekilde API sorgulamaları yapmış olabilirsiniz, artık Microsoft Graph API' olarak geliştirmeye devam edecek. Yavaştan nasıl bağlanacağımızı Powershell ile REST API sorgular yaparak neler yapabildiğimizi görelim, öncelikle bir adet Service Principal ihtiyacımız var. Bunu oluşturmak için, Azure Active Directory içerisinde, App Registration sekmesine giderek oluşturabilirsiniz, Aslında bu yaratacağımız Application ile Microosft Graph API RestFull istekler yaparak istediğimiz oluşturma, silme, güncelleme gibi talepleri gönderiyor olacağız.

Yukarıdaki resimde adımları anlatmak için bir ekran görüntüsü paylaşıyorum, yeni bir adet Application Registration oluşturmak çok zor bir süreç değil. Sadece oluşturduktan sonra gereken yetkileri vermeniz gerekiyor. Dilerseniz şu makaleyi takip ederek yapabilirsiniz. Link : Microsoft Graph API Started. Benim hali hazırda oluşturduğum kendi Azure Active Directory için bir adet Application Registration bilgilerim var ve bu Application için Azure Active Directory üzerinde Graph API ve diğer servisler için gereken yetkilendirmeleri yaptım. Şimdi Powershell tarafında ilk başta nasıl bir değişkenlere ihtiyacımız var hızlıca tanıyalım.

$tennantid        = 'tenantId'         ## Tenant bilginiz
$ApplicationID    = 'AppClientdId'     ## Application Id ( App Registration )
$ApplicationKey   = 'AppClientSecret'  ## Application Secret
$TokenEndpoint    = {https://login.windows.net/{0}/oauth2/token} -f $tennantid 
$ARMResource      = "https://graph.microsoft.com"

Yukarıdaki değişkenleri oluşturduktan sonra karşınıza gerekli değerleri girmeniz gerekmektedir. Çünkü bu değerlerin hepsini Powershell içerisinden Rest API istek yaparken kullanıyor olacağız. Aşağıdaki örnek içerisinde nasıl bir değerler geldiğini anlayabilirsiniz.

Aslında bu tarz istekleri yapmadan önce PostMan veya HttpMaster kullanarak test etme şansınız var. Ayrıca Microsoft bu kısımda devreye giriyor ve bize Microsoft Graph API Explorer sunuyor. Bu sayede yapacağınız sorguları daha öncesinden anlamanıza yardımcı olur ve nasıl parametreler kullanamanız gerektiğine karar verebilirsiniz. Aşağıdaki sayfaya giderek yukaıdaki belirttiğimiz tüm servisler için sorgulamalar yapma şansınız var. Eğer Microsoft Idniz ile oturum açarsanız ve izin verdikten sonra çok daha farklı deneyimler yaşabilirsiniz. Burası işin tamamen kendinizi bu API kullanımında ne tür bilgiler ve aksiyonlar alabileceğiniz için sizlere yol göstermesi için hizmet vermektedir.

Powershell tarafında kaldığımız yerden devam edelim, Application Id ve Application Secret bilgilerini aldıktan sonra artık API içerisine authorization/authentication olmak için gereken değerlerimizi gönderelim. Bu işlemleri hepsi tamamen token alıp Microsoft Graph API erişmeye devam etmek olacak.

$tennantid        = 'tenantId'         ## Tenant bilginiz
$ApplicationID    = 'AppClientdId'     ## Application Id ( App Registration )
$ApplicationKey   = 'AppClientSecret'  ## Application Secret
$TokenEndpoint    = {https://login.windows.net/{0}/oauth2/token} -f $tennantid 
$ARMResource      = "https://graph.microsoft.com"

#request Body for Microsoft API
$Body = @{
        'resource'= $ARMResource
        'client\_id' = $ApplicationID
        'grant\_type' = 'client\_credentials'
        'client\_secret' = $ApplicationKey
}

Yukarıdaki kod bloğundan sonra aşağıdakileri yazıp artık REST API üzerinende gereken token alma işlemizi tamamlayalım.

$tennantid        = 'tenantId'         ## Tenant bilginiz
$ApplicationID    = 'AppClientdId'     ## Application Id ( App Registration )
$ApplicationKey   = 'AppClientSecret'  ## Application Secret
$TokenEndpoint    = {https://login.windows.net/{0}/oauth2/token} -f $tennantid 
$ARMResource      = "https://graph.microsoft.com"

#request Body for Microsoft API
$Body = @{
        'resource'= $ARMResource
        'client\_id' = $ApplicationID
        'grant\_type' = 'client\_credentials'
        'client\_secret' = $ApplicationKey
}

$params = @{
    ContentType = 'application/x-www-form-urlencoded'
    Headers = @{'accept'='application/json'}
    Body = $Body
    Method = 'Post'
    URI = $TokenEndpoint
}

$token = Invoke-RestMethod @params

Yukarıdaki Powershell satırları sayesinde Microsoft Graph API istek yaptığınız zaman token almış olacaksınız. Bu token yine gördüğünüz gibi '$token' değişkenine atanmış olacak. Şimdi ise artık bu token alıp başına authorization sürecini bitirmek için, Header ekleyip Rest API tarafına göndereceğiz. Bu sayede artık sorgulamak istediğimiz herşeye sahip olacağız.

$headers = @{}
$headers.Add("authorization","Bearer $($token.access\_token)")

Neredeyse API tarafında istek yapabilir konumdayız. Serimizin bir sonraki bölümünde birkaç sorgular ve istekler ile Microsoft Graph API kullanımı örnekler ile genişletmeye çalışalım.