Rugalmasság hozzáadása paraméterek és változók használatával

  • 10 perc

A sablonok újrafelhasználhatóságuk miatt hatékonyak. A Bicep használatával olyan sablonokat írhat, amelyek több környezetet vagy erőforráspéldányt helyeznek üzembe.

A toy cég rendszeresen indít új termékeket, és a Bicep-sablonokkal kell létrehoznia az egyes termékbemutatókhoz szükséges Azure-erőforrásokat. El kell kerülnie a rögzített erőforrásnevek használatát. Az Azure-erőforrások számos típusának egyedi nevekre van szüksége, ezért a sablonokba ágyazott nevek azt jelentik, hogy nem használhatja újra a sablont több termékindításhoz. Az erőforrásokat különböző helyeken is üzembe kell helyeznie attól függően, hogy hol fogják elindítani a játékokat, ami azt jelenti, hogy az erőforráshelyeket sem ágyazhatja be a sablonba.

Ebben a leckében megismerheti a paramétereket és a változókat, amelyek két Bicep-funkció, amelyek rugalmassá és újrafelhasználhatóvá teszik a sablonokat. A kifejezések is bevezetésre kerülnek.

Feljegyzés

Az egység parancsai a fogalmakat szemléltetik. Még ne futtassa a parancsokat. Hamarosan gyakorolja, amit itt tanul.

Paraméterek és változók

A paraméterrel a sablonfájlon kívülről is bevihet értékeket. Ha például manuálisan helyezi üzembe a sablont az Azure CLI vagy az Azure PowerShell használatával, a rendszer felkéri, hogy adjon meg értékeket az egyes paraméterekhez. Létrehozhat egy paraméterfájlt is, amely felsorolja az üzembe helyezéshez használni kívánt paramétereket és értékeket. Ha a sablon egy automatizált folyamatból, például egy üzembe helyezési folyamatból van üzembe helyezve, a folyamat meg tudja adni a paraméterértékeket.

Egy változó definiálva van, és a sablonon belül van beállítva. A változók lehetővé teszik a fontos információk egy helyen történő tárolását, és a sablonban való hivatkozását anélkül, hogy ki kellene másolnia és beillesztenie.

Általában érdemes paramétereket használni az egyes üzemelő példányok között változó dolgokhoz, például:

  • Egyedi erőforrásnevek.
  • Az erőforrások üzembe helyezésének helyei.
  • Az erőforrások díjszabását befolyásoló beállítások, például az SKU-k, a tarifacsomagok és a példányok száma.
  • A sablonban nem definiált más rendszerek eléréséhez szükséges hitelesítő adatok és információk.

A változók általában akkor ajánlottak, ha minden üzembe helyezéshez ugyanazokat az értékeket fogja használni, de a sablonon belül újra felhasználhatóvá szeretne tenni egy értéket, vagy ha kifejezésekkel szeretne összetett értéket létrehozni. Olyan erőforrásokhoz is használhat változókat, amelyeknek nincs szükségük egyedi nevekre.

Tipp.

Fontos, hogy a paraméterekhez és változókhoz jó elnevezést használjon, így a sablonok könnyen olvashatók és érthetők. Ügyeljen arra, hogy egyértelmű, leíró és konzisztens neveket használjon.

Paraméter hozzáadása

A Bicepben a következőhöz hasonló paramétert definiálhat:

param appServiceAppName string

Tekintsük át a definíció egyes részeinek működését:

  • param azt jelzi a Bicepnek, hogy egy paramétert definiál.
  • appServiceAppName a paraméter neve. Ha manuálisan helyezi üzembe a sablont, előfordulhat, hogy egy értéket kell megadnia, ezért fontos, hogy a név egyértelmű és érthető legyen. A név a sablon paraméterértékére is hivatkozik, ugyanúgy, mint az erőforrás szimbolikus neveinél.
  • string a paraméter típusa. A Bicep-paraméterekhez, például string a szöveghez, int a számokhoz és bool a logikai igaz vagy hamis értékekhez több különböző típust is megadhat. Összetettebb paramétereket is megadhat a típusok és object a array típusok használatával.

Tipp.

Próbálja meg nem túl általánosítani a sablonokat túl sok paraméter használatával. Az üzleti forgatókönyvhöz szükséges paraméterek minimális számát kell használnia. Ne feledje, hogy a jövőben bármikor módosíthatja a sablonokat, ha változnak a követelmények.

Alapértelmezett értékek megadása

Megadhat alapértelmezett értéket egy paraméterhez. Ha alapértelmezett értéket ad meg, a paraméter nem kötelező lesz. A sablont üzembe helyező személy megadhat egy értéket, ha szeretné, de ha nem, akkor a Bicep az alapértelmezett értéket használja.

Az alábbiak szerint adhat hozzá alapértelmezett értéket:

param appServiceAppName string = 'toy-product-launch-1'

Feljegyzés

Ebben a példában a Azure-alkalmazás Service-alkalmazás neve rögzített alapértelmezett értékkel rendelkezik. Ez nem jó ötlet, mert az App Service-alkalmazásoknak egyedi nevekre van szükségük. Ezt hamarosan kijavíthatja.

Paraméterértékek használata a sablonban

Miután deklarált egy paramétert, a sablon többi részében hivatkozhat rá. Lássuk, hogyan használhatja az új paramétert az erőforrásdefiníción belül:

resource appServiceApp 'Microsoft.Web/sites@2023-12-01' = {
  name: appServiceAppName
  location: 'eastus'
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}

Figyelje meg, hogy a sablon most már a paraméterérték használatával állítja be az alkalmazás-erőforrás erőforrásnevét a nem rögzített érték helyett.

Tipp.

A Visual Studio Code Bicep-bővítménye vizuális mutatókat jelenít meg, amelyek jelzik, ha nem követi az ajánlott eljárásokat. Figyelmezteti például, ha olyan paramétert határoz meg, amelyet nem használ. A Bicep linter folyamatosan futtatja ezeket az ellenőrzéseket munka közben.

Változó hozzáadása

A következőhöz hasonló változót definiálhat:

var appServicePlanName = 'toy-product-launch-plan'

A változók a paraméterekhez hasonlóan vannak definiálva, de van néhány különbség:

  • var A kulcsszó használatával közölheti a Bicep-et, hogy deklarál egy változót.
  • Meg kell adnia egy változó értékét.
  • A változóknak nincs szükségük típusokra. A Bicep a beállított érték alapján tudja meghatározni a típust.

Kifejezések

Amikor sablonokat ír, gyakran nem szeretne kódolni értékeket, és nem is szeretné, hogy egy paraméterben meg legyen adva. Ehelyett értékeket szeretne felderíteni a sablon futtatásakor. Előfordulhat például, hogy egy sablon összes erőforrását egyetlen Azure-régióban szeretné üzembe helyezni: azt a régiót, ahol létrehozta az erőforráscsoportot. Vagy előfordulhat, hogy automatikusan létre szeretne hozni egy egyedi nevet egy erőforráshoz egy adott elnevezési stratégia alapján, amelyet a vállalat használ.

A Bicep-kifejezések hatékony funkciók, amelyekkel számos érdekes forgatókönyvet kezelhet. Tekintsünk meg néhány helyet, ahol kifejezéseket használhat egy Bicep-sablonban.

Erőforrás-helyek

Amikor sablont ír és helyez üzembe, gyakran nem kell minden erőforrás helyét külön-külön megadnia. Ehelyett előfordulhat, hogy van egy egyszerű üzleti szabálya, amely szerint alapértelmezés szerint az összes erőforrást ugyanarra a helyre helyezik üzembe, ahol az erőforráscsoport létrejött.

A Bicepben létrehozhat egy úgynevezett locationparamétert, majd egy kifejezéssel állíthatja be az értékét:

param location string = resourceGroup().location

Tekintse meg a paraméter alapértelmezett értékét. Egy úgynevezett resourceGroup() függvényt használ, amely hozzáférést biztosít arról az erőforráscsoportról, amelybe a sablont telepítik. Ebben a példában a sablon a tulajdonságot location használja. Gyakori, hogy ezzel a megközelítéssel az erőforrásokat ugyanabban az Azure-régióban helyezi üzembe, mint az erőforráscsoport.

Ha valaki telepíti ezt a sablont, dönthet úgy, hogy felülbírálja az alapértelmezett értéket, és egy másik helyet használ.

Feljegyzés

Az Azure egyes erőforrásai csak bizonyos helyeken helyezhetők üzembe. Előfordulhat, hogy az erőforrások helyének beállításához külön paraméterekre van szükség.

Most már használhatja az erőforráshely paramétert a sablonon belül, az alábbi módon:

resource appServiceApp 'Microsoft.Web/sites@2023-12-01' = {
  name: appServiceAppName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}

Erőforrásnevek

Számos Azure-erőforrásnak egyedi nevekre van szüksége. A forgatókönyvben két olyan erőforrással rendelkezik, amelyek egyedi neveket igényelnek: a tárfiókot és az App Service-alkalmazást. Ha ezeket az értékeket paraméterként szeretné beállítani, az megnehezítheti a sablont használó személyek számára, mert olyan nevet kell találniuk, amelyet senki más nem használt.

A Bicep-nek van egy másik, az erőforrásnevek létrehozásakor hasznosnak nevezett uniqueString() függvénye. Ha ezt a függvényt használja, meg kell adnia egy magértéket, amelynek eltérőnek kell lennie a különböző üzemelő példányokban, de konzisztensnek kell lennie az összes üzembe helyezésben ugyanazon erőforrásokhoz.

Ha jó kezdőértéket választ, ugyanazt a nevet minden alkalommal megkaphatja, amikor ugyanazt az erőforráskészletet telepíti, de más nevet kap, amikor egy másik erőforráskészletet helyez üzembe ugyanazzal a sablonnal. Nézzük meg, hogyan használhatja a függvényt uniqueString() :

param storageAccountName string = uniqueString(resourceGroup().id)

A paraméter alapértelmezett értéke ismét a függvényt resourceGroup() használja, ahogyan az erőforrás helyének beállításakor tette. Ezúttal azonban egy erőforráscsoport azonosítóját kapja meg. Így néz ki egy erőforráscsoport-azonosító:

/subscriptions/1a12b123-123c-123a-1a2b-1ab23cd45e67/resourceGroups/MyResourceGroup

Az erőforráscsoport azonosítója tartalmazza az Azure-előfizetés azonosítóját (1a12b123-123c-123a-1a2b-1ab23cd45e67) és az erőforráscsoport nevét (MyResourceGroup). Az erőforráscsoport azonosítója gyakran jó választás az erőforrásnevek kezdőértékéhez, mert:

  • Minden alkalommal, amikor ugyanazokat az erőforrásokat telepíti, azok ugyanabba az erőforráscsoportba kerülnek. A uniqueString() függvény minden alkalommal ugyanazt az értéket adja vissza.
  • Ha az Azure-előfizetésben két különböző erőforráscsoportban helyezi üzembe az üzembe helyezést, az resourceGroup().id érték eltérő lesz, mivel az erőforráscsoport neve eltérő lesz. A uniqueString() függvény különböző értékeket ad az egyes erőforrásokhoz.
  • Ha két különböző Azure-előfizetésben telepít, még akkor is, ha ugyanazt az erőforráscsoportnevet használja, az resourceGroup().id érték eltérő lesz, mert az Azure-előfizetés azonosítója eltérő lesz. A uniqueString() függvény ismét különböző értékeket ad az egyes erőforrásokhoz.

Tipp.

Gyakran érdemes sablonkifejezéseket használni az erőforrásnevek létrehozásához. Számos Azure-erőforrástípus rendelkezik szabályokkal az engedélyezett karakterekre és a nevük hosszára. Az erőforrásnevek sablonba történő beágyazása azt jelenti, hogy a sablont használóknak nem kell emlékezniük arra, hogy maguk kövessék ezeket a szabályokat.

Kombinált sztringek

Ha csak az erőforrásnevek beállításához használja a uniqueString() függvényt, valószínűleg egyedi neveket fog kapni, de ezek nem lesznek értelmesek. A jó erőforrásnévnek leírónak is kell lennie, hogy egyértelmű legyen, mire való az erőforrás. Gyakran érdemes létrehozni egy nevet egy értelmes szó vagy sztring egyedi értékekkel való kombinálásával. Így olyan erőforrásokat fog használni, amelyek jelentéssel és egyedi névvel is rendelkeznek.

A Bicep rendelkezik egy sztring interpoláció nevű funkcióval, amely lehetővé teszi a sztringek kombinálását. Lássuk, hogyan működik:

param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'

A paraméter alapértelmezett értéke storageAccountName mostantól két részből áll:

  • toylaunch egy kemény kóddal rendelkező sztring, amely segít mindenkinek, aki az Azure-ban üzembe helyezett erőforrást vizsgálja a tárfiók céljának megértésében.
  • ${uniqueString(resourceGroup().id)} a Bicep egy módja a függvény kimenetének kiértékelésére uniqueString(resourceGroup().id) , majd a sztringbe való összefűzésére.

Tipp.

Előfordulhat, hogy a uniqueString() függvény számmal kezdődő sztringeket hoz létre. Egyes Azure-erőforrások, például a tárfiókok, nem engedélyezik, hogy a nevük számokkal kezdődjön. Ez azt jelenti, hogy érdemes sztring interpolációval erőforrásneveket létrehozni, például az előző példában.

Erőforrások termékváltozatainak kiválasztása

A csapat többi tagját lenyűgözte az eddig létrehozott Bicep-kód. Közösen döntött úgy, hogy a sablonnal telepíti az erőforrásokat az új bemutatók támogatásához.

Az egyik munkatársa azt javasolta, hogy minden termékindításhoz hozzon létre nem éles környezeteket, hogy a marketingcsapat tesztelje a webhelyeket, mielőtt azok elérhetők lennének az ügyfelek számára. Azonban gondoskodni szeretne arról, hogy ne költsön túl sok pénzt a nem éles környezetekre, ezért közösen dönt néhány szabályzat mellett:

  • Éles környezetben a tárfiókok a Standard_GRS (georedundáns tárolás) termékváltozatban lesznek üzembe helyezve a nagy rugalmasság érdekében. Az App Service-csomagok a nagy teljesítmény érdekében az P2v3 SKU-n lesznek üzembe helyezve.
  • Nem éles környezetekben a tárfiókok a Standard_LRS (helyileg redundáns) termékváltozatban lesznek üzembe helyezve. Az App Service-csomagok az ingyenes F1 termékváltozatban lesznek üzembe helyezve.

Ezeknek az üzleti követelményeknek az egyik módja, ha paraméterekkel adja meg az egyes termékváltozatokat. Az összes termékváltozat paraméterként való megadása azonban nehézkes lehet, különösen akkor, ha nagyobb sablonokkal rendelkezik. Egy másik lehetőség az üzleti szabályok beágyazása a sablonba paraméterek, változók és kifejezések kombinációjával.

Először megadhat egy paramétert, amely jelzi, hogy az üzembe helyezés éles vagy nem éles környezethez tartozik-e:

@allowed([
  'nonprod'
  'prod'
])
param environmentType string

Figyelje meg, hogy ez a kód néhány új szintaxist használ a paraméter engedélyezett értékeinek listájának megadásáhozenvironmentType. A Bicep csak akkor engedélyezi a sablon üzembe helyezését, ha nem ad meg egy ilyen értéket.

Ezután létrehozhat változókat, amelyek meghatározzák a tárfiókhoz és az App Service-csomaghoz használandó termékváltozatokat a környezet alapján:

var storageAccountSkuName = (environmentType == 'prod') ? 'Standard_GRS' : 'Standard_LRS'
var appServicePlanSkuName = (environmentType == 'prod') ? 'P2V3' : 'F1'

Itt is megfigyelheti az új szintaxist. Bontsuk le:

  • (environmentType == 'prod') logikai (igaz vagy hamis) értékre van kiértékelve attól függően, hogy melyik érték használható a paraméterhez environmentType .
  • ?ternáris operátornak nevezzük, és kiértékel egy utasítástif/then. Az operátor utáni ? érték, ha a kifejezés igaz. Ha a kifejezés értéke hamis, akkor a kettőspont (:) utáni értéket használja a rendszer.

Ezeket a szabályokat lefordíthatjuk a következőre:

  • Ha a paraméter prodértéke storageAccountSkuName environmentType a változó, használja az Standard_GRS SKU-t. Ellenkező esetben használja az termékváltozatot Standard_LRS .
  • Ha a paraméter prodértéke environmentType appServicePlanSkuName a változó, használja az P2V3 SKU-t és a rétegetPremiumV3. Ellenkező esetben használja az termékváltozatot F1 .

Tipp.

Ha ilyen többrészes kifejezéseket hoz létre, a legjobb, ha változókat használ ahelyett, hogy közvetlenül az erőforrás tulajdonságaiba ágyazza be a kifejezéseket. Ez megkönnyíti a sablonok olvasását és megértését, mivel elkerüli az erőforrás-definíciók logikával való zsúfoltságát.

Amikor paramétereket, változókat és kifejezéseket használ a sablonban, újra felhasználhatja a sablont, és gyorsan üzembe helyezhet egy új erőforráskészletet. Például minden alkalommal, amikor a marketingosztály egy új webhely üzembe helyezését kéri a következő bemutatóhoz, minden üzembe helyezett környezethez új paraméterértékeket kell megadnia, és ön be lesz állítva!