İlk bölümde Bicep‘e kısa bir girişle birlikte basit bir de örnek yapmıştım. Bu bölümde yine aynı örnek üzerinden devam ederek template’e parametreler ekleyerek Bicep‘in bize sağlamış olduğu özellikleri göstermeye çalışacağım. İlk bölümdeki örnekte bir container registry oluşturmuştum. Resim-1‘de de göreceğiniz gibi location değerini beğenmeyip altını sarı ile çizmişti. Hatta eğer bu template’i deploy etmek istersem de Azure CLI üzerinde bir warning ile karşılacağım. Burada uyardığı kısım ise location bilgisinin hard-coded olmaması gerektiği. Detay için buraya tıklayabilirsiniz.
Resim-1
Parametre tanımı oldukça kolay. Parametre olduğunu belirtmek için “param” keyword’ü, sonra parametre adı ve son olarak da parametre tipi olarak string yazmam yeterli (Resim-2). Location bilgisini de parametreden alması için de gerekli değişikliği yaptıktan sonra, “hard-coded location” uyarısının da gittiğini görebiliyorum.
Resim-2
İsterseniz bir kaç parametre daha eklemeden, Bicep template’lerde kullanabilceğimiz veri tiplerinden kısaca bahsetmek istiyorum:
- array
- bool
- int
- object
- string
Bunlara ait farklı örnekleri de ilerleyen bölümlerde yapacağım. Name ve SKU için 2 parametre daha ekleyelim (Resim-3).
Resim-3
Mevcut template’i tamamen parametrik hale getirdim, şimdi de Azure CLI üzerinden deneyelim. Parametre değerlerini bize tek tek soracak (Resim-4). Buraya kadar her şey güzel görünüyor. Burada kullanıcıların işlerini biraz daha kolaylaştırabilir miyiz diye bakalım.
Resim-4
Bu kısımda aslında 2 sorun var. İlki burada sorulan sorulara verilecek cevapları her seferinde yazmamız gerekmesi, ikincisi de location ve SKU name gibi “çoktan seçmeli” sorulara verilecek cevapları bilemeyebiliriz.
İlk önce ilk sorundan başlayalım. Parametrelere varsayılan bir değer atayabiliyoruz. Hatta bunun için ileride detaylarına gireceğim hazır fonksiyonları da kullanabiliyoruz. Örnek olarak location bilgisi için resource group’un olduğu location bilgisini kullanmak istiyorum, resource group ile içerisinde yer alan resource’ların farklı bölgelerde olmasına gerek yok. Eğer bu template’i farklı bir resource group ile çalıştırırsam, “parametre olarak ne geçeceğim bir bakayım” ya da “default değeri de değiştirmem gerekli” gibi sorunlardan kurtulmuş oldum (Resim-5).
Resim-5
Deployment’ı tekrar çalıştırdığımda bu kez bana 2 parametre soruyor (Resim-6).
Resim-6
İsim için de varsayılan bir değer verelim, ama bu kez 2 farklı özellikten faydalanacağım: Interpolation ve hazır fonksiyonları birlikte kullanıyorum. Burada uniqueString fonksiyonu, parametre olarak verdiğimi resource group id değerinden bir hash oluşturuyor. Bunu da mshowtocr string değeri ile birleştiriyorum (Resim-7).
Resim-7
Burada dikkat edilmesi gereken kısım bu fonksiyonu aynı parametre ile ( örnekte resourceGroup().id ) çağırdığınızda her seferinde farklı bir değer oluşturmayacak, yani bu şekilde tekrar çalıştırdığınızda yeni bir resource oluşturmayacaksınız.
Resim-8
Son olarak da SKU name parametresi kaldı. Burada tanımlayabileceğim değerleri ilk bölümden de hatırlayacağınız üzere ctrl + space ile görebiliyordum. Bu değerler Classic, Basic, Standard ve Premium. Eğer bunlar dışında bir isim yazarsanız “Registry SKU name is invalid. Expected SKU names are Classic, Basic, Standard, Premium” hatası alırsınız. Ancak burada sadece Basic ve Standard SKU kullanılmasını istersem ne yapmam gerekir? Cevap: Decorators.
Parametrelere farklı amaçlarla decorator ekleyebiliyoruz. Bunlardan ilk olarak “allowed”, adından da anlayabileceğiniz üzere izin verilen değerleri belirleyebiliyoruz. Böylede Basic ve Standard dışında bir değer girilmesini de engellemiş oluyorum (Resim-9).
Resim-9
Kullanabileceğim decorator tipleri:
- allowed
- description
- maxLength
- minLength
- maxValue
- minValue
- metadata
- secure
İlerleyen bölümlerde detaylı olarak inceleyeceğim ama description için şimdiden bir örnek yapabilirim. Adından da anlaşıldığı üzere parametre ile ilgili detay yazmak için kullandığımız ve özellikle portal üzerinden deployment yaparken görebileceğimiz bilgileri tooltip bilgilerini description içerisinde yazabiliyoruz.
Resim-10
Resim-11
Peki bu parametreleri varsayılan değerleri dışında kullanmak istiyorum ama her seferinde de CLI üzerinden tekrar tekrar yazmak istemiyorsanız da çözümü Resim-12‘de göreceğiniz gibi –parameters’a parametre dosyasının adını vermek.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"name": {
"value": "mshowtocr"
},
"location": {
"value": "westeurope"
},
"skuName": {
"value": "Basic"
}
}
}
Resim-12
Buradaki önemli detay ise parametrelerin ezilme sırası. CLI parametreleri parametre dosyasında yer alan parametreleri, parametre dosyasındakiler de varsayılan parametreleri eziyor.
az deployment group create -g mshowto-rg \
--template-file main.bicep \
--parameters main.parameters.json skuName=Standard
Bir sonraki bölümde Bicep’in diğer özellikleri ile birlikte bu bölümde de isim olarak bahsettiğim özellikleri de örnekler üzerinden anlatmaya çalışacağım.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
Bicep documentation | Microsoft Docs
GitHub – mertyeter/bicep-samples
TAGs: Azure, Yazılım Geliştiriciler için Azure, Bicep, ARM Templates, JSON, Azure Resource Manager, IaC, Infrastructure as Code, VS Code, Visual Studio Code, Azure CLI, bicep nedir
