บทนำ

เสร็จสมบูรณ์เมื่อ

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

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

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

หากไม่มีความช่วยเหลือจาก AI วงจรการเขียนโครงสร้างพื้นฐานเป็นโค้ด (IaC) จะมีลักษณะดังนี้:

1. เขียนเทมเพลต
2. ค้นหาเอกสารประกอบ
3. แก้ไขไวยากรณ์
4. ตรวจสอบความถูกต้องภายในเครื่อง
5. เรียกใช้ what-if
6. ปรับใช้กับการแสดงละคร
7. ตรวจสอบการเปลี่ยนแปลง
8. ปรับใช้กับการผลิต

และทําซ้ําเช่นเดียวกันสําหรับการปรับใช้แต่ละครั้ง ไม่ว่าจะเป็นแบบใหม่หรือการอัปเดต

วัตถุประสงค์การเรียนรู้

ในตอนท้ายของโมดูลนี้ คุณสามารถ:

• อธิบายว่า Infrastructure as Code คืออะไร และเหตุใดจึงมีความสําคัญในการดําเนินงานระบบคลาวด์สมัยใหม่
• อธิบายความแตกต่างระหว่างแนวทางการประกาศและแนวทางที่จําเป็นสําหรับ IaC
• ระบุเวิร์กโฟลว์การเขียน IaC แบบดั้งเดิมและจุดเสียดทาน
• อธิบายว่า GitHub Copilot เปลี่ยนลูปภายใน IaC อย่างไร
• อธิบายความสามารถของ GitHub Copilot ที่เกี่ยวข้องกับงานโครงสร้างพื้นฐานมากที่สุด

ความท้าทายของโครงสร้างพื้นฐานเป็นโค้ด

แต่ละขั้นตอนมีแรงเสียดทาน การเขียนเทมเพลต Bicep ตั้งแต่เริ่มต้นจําเป็นต้องมีความรู้เกี่ยวกับชนิดทรัพยากร เวอร์ชัน API คุณสมบัติที่จําเป็น และแบบแผนการตั้งชื่อเฉพาะ Azure การค้นหาเวอร์ชัน API ที่ถูกต้องสําหรับ Microsoft.Network/virtualNetworks หมายถึงการนําทางเอกสารประกอบหรือการคัดลอกจากโครงการก่อนหน้า ข้อผิดพลาดทางไวยากรณ์ถูกจับได้หลังจากเรียกใช้คําสั่งบิลด์ และการอัปเดตเทมเพลตให้ทันสมัยอยู่เสมอเมื่อ Azure API พัฒนาขึ้นเป็นภาระการบํารุงรักษาอย่างต่อเนื่อง

ผลที่ได้คือ IaC มักถือว่าเป็นทักษะเฉพาะทาง วิศวกรที่ไม่ได้เขียนเทมเพลตเป็นประจําจะหันกลับไปที่การเลือกพอร์ทัลทําลายความสอดคล้องที่ IaC มีไว้ให้

แนวทางการประกาศเทียบกับแนวทางที่จําเป็น

IaC มีสองรูปแบบพื้นฐาน การทําความเข้าใจความแตกต่างช่วยให้คุณเลือกเครื่องมือที่เหมาะสมและสร้างข้อความแจ้งที่ดีขึ้นสําหรับ GitHub Copilot

IaC ที่ประกาศ

ในแนวทางการประกาศ คุณอธิบาย สถานะสิ้นสุดที่ต้องการ ของโครงสร้างพื้นฐานของคุณ เครื่องมือจะหาวิธีไปที่นั่น

"ฉันต้องการ VNet ที่มีพื้นที่แอดเดรส 10.0.0.0/16 และซับเน็ตสองเครือข่าย"

เทมเพลต Azure Bicep และ ARM เป็นการประกาศ คุณกําหนดทรัพยากรที่ควรมีอยู่ และ Azure Resource Manager จะจัดการการจัดลําดับและการสร้าง หากทรัพยากรอยู่ในสถานะที่ถูกต้องอยู่แล้ว จะไม่มีการเปลี่ยนแปลงใดๆ หากไม่มีอยู่จริง มันก็ถูกสร้างขึ้น หากแตกต่างออกไป จะได้รับการอัปเดต

IaC เชิงไวยากรณ์

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

"ตรวจสอบว่า VNet มีอยู่จริงหรือไม่ ถ้าไม่วิ่ง az network vnet create..."

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

คุณควรใช้อันไหน?

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

ในทางปฏิบัติวิศวกรระบบคลาวด์ส่วนใหญ่ใช้ทั้งสองอย่าง และ GitHub Copilot ก็ช่วยทั้งสองอย่างเช่นกัน

GitHub Copilot เปลี่ยนกระบวนการเขียนเทมเพลตอย่างไร

GitHub Copilot ช่วยลดความยุ่งยากและลดความซับซ้อนในทุกขั้นตอนของวงจรการเขียน IaC

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

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

ในขั้นตอนการแปลง Copilot สามารถแปลงระหว่าง Azure CLI และ PowerShell ระหว่าง JSON และ Bicep Azure Resource Manager หรือระหว่าง Azure Pipelines และ GitHub Actions ลดต้นทุนในการสลับเครื่องมือหรือดัดแปลงตัวอย่างจากเอกสารประกอบ

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

การเปลี่ยนไม่ใช่แค่เรื่องความเร็วเท่านั้น มันเกี่ยวกับการลดอุปสรรคในการเข้า วิศวกรที่ไม่ใช่ผู้เชี่ยวชาญด้าน Bicep สามารถสร้างเทมเพลตที่ถูกต้องและมีโครงสร้างที่ดีได้โดยอธิบายเจตนาของตนด้วยภาษาธรรมดา

ความสามารถของ GitHub Copilot สําหรับงานโครงสร้างพื้นฐาน

GitHub Copilot ปรากฏตัวในหลายวิธีภายใน VS Code ซึ่งแต่ละวิธีเหมาะกับส่วนต่างๆ ของเวิร์กโฟลว์ IaC

คําแนะนําแบบอินไลน์

ขณะที่คุณพิมพ์ไฟล์ .bicep, .yaml, .ps1 หรือ .sh Copilot จะนําเสนอการทําให้เสร็จสมบูรณ์แบบเรียลไทม์ หากคุณพิมพ์จุดเริ่มต้นของข้อกําหนดทรัพยากร Copilot จะคาดการณ์ส่วนที่เหลือ รวมถึงคุณสมบัติที่จําเป็น ค่าเริ่มต้น และรูปแบบทั่วไป คุณยอมรับด้วยTabหรือยกเลิกด้วยEscape

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

แชท Copilot

Copilot แชท (Ctrl+Alt+I) เป็นอินเทอร์เฟซการสนทนาที่คุณสามารถถามคําถามอธิบายสิ่งที่คุณต้องการสร้างวางโค้ดที่มีอยู่เพื่อตรวจสอบหรือขอคําอธิบาย

แชทดีกว่าคําแนะนําแบบอินไลน์สําหรับงานที่ต้องใช้บริบทมากขึ้น ตัวอย่างเช่นการสร้างเทมเพลตทั้งหมดตั้งแต่เริ่มต้นการปรับโครงสร้างไฟล์ที่ซับซ้อนหรือขอคําอธิบายเกี่ยวกับวิธีการทํางานของทรัพยากร

Copilot พร้อม MCP (Model Context Protocol)

MCP อนุญาตให้ Copilot เชื่อมต่อกับเครื่องมือภายนอกและแหล่งข้อมูล เซิร์ฟเวอร์ MCP Bicep ให้สิทธิ์ Copilot เข้าถึงคําจํากัดความประเภท Bicep ที่ใช้งานจริง เวอร์ชัน API ปัจจุบัน และกฎการตรวจสอบความถูกต้อง ทําให้เอาต์พุต Bicep แม่นยํากว่าที่ผลิตได้จากข้อมูลการฝึกอบรมเพียงอย่างเดียว

เหตุใด IaC จึงเหมาะอย่างยิ่งสําหรับความช่วยเหลือด้าน AI

คําจํากัดความของโครงสร้างพื้นฐานมีคุณสมบัติที่ทําให้เป็นตัวเลือกที่ดีสําหรับการสร้างที่ได้รับความช่วยเหลือจาก AI:

• มีโครงสร้างสูง: คําจํากัดความของทรัพยากรเป็นไปตามสคีมา คุณสมบัติจะขึ้นอยู่กับชนิดที่รู้จัก ค่าที่ถูกต้อง และการกําหนดที่จําเป็น/ไม่บังคับ ลักษณะที่มีโครงสร้างนี้ช่วยให้โมเดลสร้างผลลัพธ์ที่ถูกต้องตามวากยสัมพันธ์ได้ง่ายขึ้น
• มีรูปแบบที่หลากหลาย: การปรับใช้ Azure ส่วนใหญ่ใช้ประเภททรัพยากรทั่วไปที่ค่อนข้างเล็ก ได้แก่ เครือข่ายเสมือน บัญชีที่เก็บข้อมูล ทรัพยากรการประมวลผล และข้อมูลประจําตัว รูปแบบเหล่านี้ปรากฏบ่อยครั้งในข้อมูลการฝึกอบรม ซึ่งหมายความว่า Copilot อาศัยตัวอย่างมากมาย
• มีราคาแพงในการวิจัยด้วยตนเอง: การค้นหาชุดค่าผสมที่ถูกต้องของเวอร์ชัน API คุณสมบัติที่จําเป็น และ SKU ที่ถูกต้องสําหรับประเภททรัพยากรที่ไม่คุ้นเคยอาจใช้เวลาอย่างมาก Copilot บีบอัดงานวิจัยนั้นให้เป็นข้อความแจ้ง
• พวกเขาปลอดภัยในการทําซ้ํา: คุณตรวจสอบความถูกต้องก่อนที่คุณจะปรับใช้ ข้อเสนอแนะที่ไม่ถูกต้องจาก Copilot ถูกจับได้ที่ az bicep build หรือ what-if ก่อนที่จะสัมผัสกับทรัพยากรจริง ตาข่ายนิรภัยนี้ส่งเสริมการทดลอง

ประเด็นสําคัญ

• IaC ถือว่าโครงสร้างพื้นฐานเป็นโค้ด: ควบคุมเวอร์ชัน ทําซ้ําได้ และตรวจสอบได้
• เครื่องมือประกาศเช่น Bicep อธิบายสถานะสิ้นสุดที่ต้องการเครื่องมือที่จําเป็นเช่น CLI อธิบายขั้นตอนในการไปถึงที่นั่น
• เวิร์กโฟลว์ IaC แบบดั้งเดิมมีแรงเสียดทานอย่างมากในทุกขั้นตอน Copilot ช่วยลดแรงเสียดทานนั้น
• GitHub Copilot ช่วยผ่านคําแนะนําแบบอินไลน์ Copilot Chat และบริบทที่ปรับปรุงด้วย MCP
• IaC เหมาะอย่างยิ่งสําหรับความช่วยเหลือด้าน AI เนื่องจากมีโครงสร้าง มีรูปแบบที่หลากหลาย และปลอดภัยในการทําซ้ํา

Note

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