เพิ่มพารามิเตอร์และเอาต์พุตไปยังโมดูล

แต่ละโมดูลที่คุณสร้างควรมีวัตถุประสงค์ที่ชัดเจน ให้คิดว่ามอดูลมีสัญญา ซึ่งยอมรับชุดของพารามิเตอร์ สร้างชุดของทรัพยากร และอาจมีผลลัพธ์บางอย่างกลับไปยังเทมเพลตหลัก ไม่ว่าใครก็ตามที่ใช้มอดูลไม่ควรจะต้องกังวลเกี่ยวกับวิธีการทํางาน เพียงแค่ทําตามที่พวกเขาคาดหวัง

เมื่อคุณวางแผนโมดูล ให้พิจารณา:

• สิ่งที่คุณจําเป็นต้องรู้เพื่อให้สามารถเติมเต็มวัตถุประสงค์ของมอดูล
• สิ่งที่ใครก็ตามที่ใช้โมดูลของคุณคาดว่าจะให้
• สิ่งที่ใครก็ตามที่ใช้โมดูลของคุณจะคาดหวังว่าจะเข้าถึงเป็นเอาต์พุต

พารามิเตอร์โมดูล

ลองนึกถึงพารามิเตอร์ที่โมดูลของคุณยอมรับ และระบุว่าแต่ละพารามิเตอร์ควรเป็นทางเลือกหรือจําเป็น

เมื่อคุณสร้างพารามิเตอร์สําหรับเทมเพลต การเพิ่มพารามิเตอร์เริ่มต้นที่คุณสามารถทําได้เป็นแนวทางปฏิบัติที่ดี ในโมดูล การเพิ่มพารามิเตอร์เริ่มต้นไม่ใช่เรื่องสําคัญเสมอไป เนื่องจากเทมเพลตหลักของคุณจะใช้โดยเทมเพลตหลักที่อาจใช้พารามิเตอร์เริ่มต้นของตนเอง หากคุณมีพารามิเตอร์ที่คล้ายกันในทั้งสองไฟล์ ทั้งที่มีค่าเริ่มต้น อาจเป็นเรื่องยากสําหรับผู้ใช้เทมเพลตของคุณที่จะทราบว่าจะใช้ค่าเริ่มต้นใดและเพื่อเสริมความสอดคล้อง การปล่อยค่าเริ่มต้นไว้ในแม่แบบหลักและเอาออกจากโมดูลมักจะดีกว่า

นอกจากนี้คุณควรคิดถึงวิธีที่คุณจัดการพารามิเตอร์ที่ควบคุม SKU สําหรับทรัพยากรของคุณและการตั้งค่าการกําหนดค่าที่สําคัญอื่น ๆ เมื่อคุณสร้างเทมเพลต Bicep แบบสแตนด์อโลน เป็นเรื่องปกติที่จะฝังกฎทางธุรกิจลงในเทมเพลตของคุณ ตัวอย่างเช่น: เมื่อฉันปรับใช้สภาพแวดล้อมการผลิต บัญชีที่เก็บข้อมูลควรใช้ระดับ GRS อย่างไรก็ตาม ในบางครั้งมอดูลก็มีข้อกังวลที่แตกต่างกัน

ถ้าคุณกําลังสร้างโมดูลที่จําเป็นต้องนํามาใช้ใหม่และมีความยืดหยุ่น โปรดทราบว่ากฎทางธุรกิจสําหรับเทมเพลตหลักแต่ละเทมเพลตอาจแตกต่างกัน ดังนั้นจึงอาจไม่เหมาะสมที่จะฝังกฎทางธุรกิจลงในโมดูลทั่วไป พิจารณาการกําหนดกฎทางธุรกิจในเทมเพลตหลักของคุณ จากนั้นส่งผ่านการกําหนดค่าโมดูลผ่านพารามิเตอร์อย่างชัดเจน

อย่างไรก็ตาม หากคุณสร้างโมดูลที่มีวัตถุประสงค์เพื่อทําให้องค์กรของคุณเองปรับใช้ทรัพยากรที่เหมาะกับความต้องการเฉพาะของคุณ เป็นเรื่องง่ายที่จะรวมกฎทางธุรกิจเพื่อลดความซับซ้อนของเทมเพลตหลัก

พารามิเตอร์ใดก็ตามที่คุณใส่ในโมดูลของคุณ ตรวจสอบให้แน่ใจว่าคุณเพิ่มคําอธิบายที่มีความหมายโดยใช้แอตทริบิวต์ @description:

@description('The name of the storage account to deploy.')
param storageAccountName string

ใช้เงื่อนไข

หนึ่งในเป้าหมายของการปรับใช้โครงสร้างพื้นฐานโดยใช้รหัสเช่น Bicep คือเพื่อหลีกเลี่ยงความพยายามซ้ําหรือแม้กระทั่งสร้างเทมเพลตหลายรายการเพื่อวัตถุประสงค์เดียวกันหรือคล้ายกัน คุณลักษณะของ Bicep มอบกล่องเครื่องมือที่มีประสิทธิภาพในการสร้างโมดูลที่นํากลับมาใช้ใหม่ได้ซึ่งใช้งานได้กับสถานการณ์ต่าง ๆ คุณสามารถรวมฟีเจอร์ต่างๆ เช่น โมดูล นิพจน์ ค่าพารามิเตอร์เริ่มต้น และเงื่อนไขเพื่อสร้างโค้ดที่นํามาใช้ใหม่ได้ซึ่งมีความยืดหยุ่นที่คุณต้องการ

สมมติว่าคุณกําลังสร้างมอดูลที่ปรับใช้บัญชี Azure Cosmos DB เมื่อมีการปรับใช้กับสภาพแวดล้อมการผลิตของคุณ คุณจําเป็นต้องกําหนดค่าบัญชีเพื่อส่งบันทึกไปยังพื้นที่ทํางาน Log Analytics ในการกําหนดค่าบันทึกที่จะส่งไปยัง Log Analytics คุณจะต้องกําหนดการวินิจฉัย การตั้งค่า ทรัพยากร

คุณสามารถบรรลุข้อกําหนดของคุณได้โดยการเพิ่มเงื่อนไขในข้อกําหนดของทรัพยากรและทําให้พารามิเตอร์ ID พื้นที่ทํางานเป็นทางเลือกโดยการเพิ่มค่าเริ่มต้น:

param logAnalyticsWorkspaceId string = ''

resource cosmosDBAccount 'Microsoft.DocumentDB/databaseAccounts@2022-08-15' = {
  // ...
}

resource cosmosDBAccountDiagnostics 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' =  if (logAnalyticsWorkspaceId != '') {
  scope: cosmosDBAccount
  name: 'route-logs-to-log-analytics'
  properties: {
    workspaceId: logAnalyticsWorkspaceId
    logs: [
      {
        category: 'DataPlaneRequests'
        enabled: true
      }
    ]
  }
}

เมื่อคุณรวมโมดูลนี้ในเทมเพลต Bicep คุณสามารถกําหนดค่าเพื่อส่งบันทึกบัญชี Azure Cosmos DB ไปยัง Log Analytics ได้อย่างง่ายดายโดยการตั้งค่า ID พื้นที่ทํางาน ถ้าคุณไม่ต้องการบันทึกสําหรับสภาพแวดล้อมที่คุณกําลังปรับใช้ คุณสามารถละเว้นพารามิเตอร์ได้ ซึ่งมีค่าเริ่มต้น โมดูลย่อส่วนตรรกะที่จําเป็นสําหรับการดําเนินการสิ่งที่ถูกต้องตามความต้องการของคุณ

เอาท์พุทของโมดูล

โมดูลสามารถกําหนดเอาต์พุตได้ คุณควรสร้างผลลัพธ์สําหรับข้อมูลที่เทมเพลตหลักอาจจําเป็นต้องใช้ ตัวอย่างเช่น หากโมดูลของคุณกําหนดบัญชีเก็บข้อมูล ให้ลองสร้างเอาต์พุตสําหรับชื่อของบัญชีเก็บข้อมูลเพื่อให้เทมเพลตหลักสามารถเข้าถึงได้

เทมเพลตหลักสามารถใช้เอาต์พุตของโมดูลในตัวแปร สามารถใช้คุณสมบัติสําหรับข้อกําหนดทรัพยากรอื่น ๆ หรือสามารถเปิดเผยตัวแปรและคุณสมบัติเป็นเอาต์พุตเองได้ ด้วยการเปิดเผยและใช้เอาต์พุตตลอดไฟล์ Bicep คุณสามารถสร้างชุดโมดูล Bicep ที่นํามาใช้ใหม่ได้ที่สามารถแชร์กับทีมของคุณ และนํามาใช้ใหม่ในการปรับใช้หลายรายการ นอกจากนี้ยังเป็นแนวทางปฏิบัติที่ดีในการเพิ่มคําอธิบายที่มีความหมายไปยังผลลัพธ์โดยใช้แอตทริบิวต์ @description:

@description('The fully qualified Azure resource ID of the blob container within the storage account.')
output blobContainerResourceId string = storageAccount::blobService::container.id

โมดูลสายโซ่เข้าด้วยกัน

เป็นเรื่องปกติที่จะสร้างไฟล์ Bicep หลักที่ประกอบด้วยหลายโมดูลเข้าด้วยกัน ตัวอย่างเช่น สมมติว่าคุณกําลังสร้างเทมเพลต Bicep ใหม่เพื่อปรับใช้เครื่องเสมือนที่ใช้เครือข่ายเสมือนเฉพาะ คุณสามารถสร้างโมดูลเพื่อกําหนดเครือข่ายเสมือนได้ จากนั้นคุณสามารถใช้รหัสทรัพยากรเครือข่ายย่อยของเครือข่ายเสมือนเป็นเอาต์พุตจากโมดูลนั้นและใช้เป็นข้อมูลป้อนเข้าไปยังโมดูลเครื่องเสมือน:

@description('Username for the virtual machine.')
param adminUsername string

@description('Password for the virtual machine.')
@minLength(12)
@secure()
param adminPassword string

module virtualNetwork 'modules/vnet.bicep' = {
  name: 'virtual-network'
}

module virtualMachine 'modules/vm.bicep' = {
  name: 'virtual-machine'
  params: {
    adminUsername: adminUsername
    adminPassword: adminPassword
    subnetResourceId: virtualNetwork.outputs.subnetResourceId
  }
}

ในตัวอย่างนี้ คุณใช้ชื่อสัญลักษณ์สําหรับการอ้างอิงระหว่างโมดูล การอ้างอิงนี้ช่วยให้ Bicep เข้าใจความสัมพันธ์ระหว่างโมดูลโดยอัตโนมัติ

เนื่องจาก Bicep เข้าใจว่ามีการขึ้นต่อกัน ดังนั้นจึงปรับใช้โมดูลตามลําดับ:

1. Bicep ปรับใช้ทุกอย่างในโมดูล virtualNetwork
2. หากการปรับใช้ดังกล่าวประสบความสําเร็จ Bicep จะเข้าถึงค่าเอาต์พุต subnetResourceId และส่งผ่านไปยังโมดูล virtualMachine เป็นพารามิเตอร์
3. Bicep ปรับใช้ทุกอย่างในโมดูล virtualMachine