ทดสอบทรัพยากรของคุณหลังจากการปรับใช้
ด้วยการตรวจสอบและแสดงตัวอย่างการปรับใช้ Bicep ของคุณ คุณจะสามารถสร้างความเชื่อมั่นว่าไฟล์ Bicep ของคุณจะปรับใช้ได้สําเร็จ แต่การปรับใช้ไม่ใช่ทั้งหมด หลังจากการปรับใช้เสร็จสิ้น การตรวจสอบว่าการปรับใช้ของคุณได้ทําสิ่งที่คุณคาดหวังไว้หรือไม่
ในหน่วยนี้ คุณจะได้เรียนรู้เกี่ยวกับการทดสอบที่คุณสามารถเรียกใช้หลังจากการปรับใช้ของคุณเสร็จสิ้นแล้ว นอกจากนี้คุณยังจะได้เรียนรู้เกี่ยวกับการย้อนกลับการปรับใช้ของคุณหากสิ่งต่าง ๆ ไม่เปิดตามที่คุณคาดไว้
เรียกใช้การทดสอบควันและการทดสอบเชิงลบ
เมื่อคุณกําหนดทรัพยากรในไฟล์ Bicep เป้าหมายของคุณไม่ใช่แค่เพื่อสร้างทรัพยากรใน Azure เท่านั้น ซึ่งเป็นการส่งมอบคุณค่าให้กับองค์กรของคุณในขณะที่ตอบสนองความต้องการขององค์กรของคุณ เมื่อคุณตรวจสอบและแสดงตัวอย่างไฟล์ Bicep ของคุณ คุณได้รับความเชื่อมั่นว่าข้อกําหนดของทรัพยากรนั้นถูกต้อง แต่คุณไม่จําเป็นต้องทราบว่าทรัพยากรจะทําอะไรตามที่คุณต้องการ
ตัวอย่างเช่น สมมติว่าคุณปรับใช้เซิร์ฟเวอร์เชิงตรรกะ Azure SQL ใหม่โดยใช้ไปป์ไลน์การปรับใช้ Bicep ข้อกําหนด Bicep สําหรับเซิร์ฟเวอร์ของคุณถูกต้อง ดังนั้นจึงผ่านขั้นตอนการตรวจสอบ linter และ preflight คําสั่ง What-if แสดงว่าจะมีการสร้างเซิร์ฟเวอร์ซึ่งเป็นสิ่งที่คุณคาดหวัง การปรับใช้จะเสร็จสมบูรณ์ด้วย แต่ในตอนท้ายของกระบวนการปรับใช้ คุณยังอาจไม่มีเซิร์ฟเวอร์ฐานข้อมูลที่ใช้งานได้ที่พร้อมสําหรับการใช้งาน เหตุผลอาจรวมถึง:
- คุณยังไม่ได้กําหนดค่ากฎไฟร์วอลล์เพื่ออนุญาตให้การรับส่งข้อมูลเครือข่ายเข้าถึงเซิร์ฟเวอร์ของคุณ
- คุณได้เปิดใช้งานการรับรองความถูกต้องของ Microsoft Entra บนเซิร์ฟเวอร์ของคุณเมื่อคุณไม่ควรมีหรือในทางกลับกัน
แม้ว่าคุณเพิ่งปรับใช้ไฟล์ Bicep พื้นฐานแต่ก็คุ้มค่าที่จะพิจารณาว่าคุณสามารถตรวจสอบว่าทรัพยากรที่คุณปรับใช้ทํางานจริงและตรงตามข้อกําหนดของคุณได้อย่างไร นี่คือตัวอย่างของวิธีที่คุณสามารถใช้การตรวจสอบนี้:
- เมื่อคุณปรับใช้เว็บไซต์ ให้ลองเข้าถึงเว็บแอปพลิเคชันจากไปป์ไลน์ของคุณ ตรวจสอบว่าไปป์ไลน์ของคุณเชื่อมต่อกับเว็บไซต์เรียบร้อยแล้วและได้รับรหัสตอบกลับที่ถูกต้อง
- เมื่อคุณปรับใช้เครือข่ายการจัดส่งเนื้อหา (CDN) ลองเชื่อมต่อกับทรัพยากรผ่าน CDN ตรวจสอบว่าไปป์ไลน์เชื่อมต่อกับ CDN เรียบร้อยแล้วและได้รับรหัสการตอบสนองที่ถูกต้อง
การทดสอบเหล่านี้บางครั้งเรียกว่า การทดสอบควันโครงสร้างพื้นฐาน การทดสอบควันเป็นรูปแบบง่าย ๆ ของการทดสอบที่ออกแบบมาเพื่อเปิดเผยปัญหาที่สําคัญในการปรับใช้ของคุณ
โน้ต
ทรัพยากร Azure บางอย่างไม่ง่ายที่จะเข้าถึงจากตัวแทนไปป์ไลน์ที่โฮสต์ Microsoft คุณอาจต้องพิจารณาใช้ตัวแทนที่โฮสต์ด้วยตนเองเพื่อเรียกใช้ขั้นตอนการทดสอบการสูบบุหรี่หากพวกเขาต้องการเข้าถึงทรัพยากรผ่านเครือข่ายส่วนตัว
นอกจากนี้ยังเป็นความคิดที่ดีที่จะทําการทดสอบ เชิงลบ การทดสอบเชิงลบช่วยให้คุณยืนยันว่าทรัพยากรของคุณไม่มีพฤติกรรมในลักษณะที่ไม่พึงประสงค์ ตัวอย่างเช่น เมื่อคุณปรับใช้เครื่องเสมือน คุณควรใช้ Azure Bastion เพื่อเชื่อมต่อกับเครื่องเสมือนอย่างปลอดภัย คุณสามารถเพิ่มการทดสอบเชิงลบให้กับไปป์ไลน์ของคุณเพื่อตรวจสอบว่าคุณไม่สามารถเชื่อมต่อกับเครื่องเสมือนได้โดยตรงโดยใช้การเชื่อมต่อเดสก์ท็อประยะไกลหรือ SSH
สําคัญ
เป้าหมายของการทดสอบเหล่านี้ไม่ใช่เพื่อตรวจสอบว่า Bicep ได้ปรับใช้ทรัพยากรของคุณอย่างถูกต้อง เมื่อคุณใช้ Bicep คุณตั้งสมมติฐานว่าจะปรับใช้ทรัพยากรที่คุณระบุในไฟล์ Bicep ของคุณ แต่เป้าหมายคือการตรวจสอบว่าทรัพยากรที่คุณกําหนดจะทํางานได้กับสถานการณ์ของคุณและตรงตามข้อกําหนดของคุณหรือไม่
เรียกใช้การทดสอบจากไปป์ไลน์ Azure
มีหลายวิธีที่คุณสามารถเรียกใช้การทดสอบในไปป์ไลน์ของคุณ ในโมดูลนี้คุณจะใช้ Pester ซึ่งเป็นเครื่องมือโอเพนซอร์สที่เรียกใช้การทดสอบที่เขียนผ่าน PowerShell คุณอาจเลือกที่จะใช้เฟรมเวิร์กการทดสอบอื่นหรือแม้แต่เลือกที่จะเรียกใช้การทดสอบของคุณโดยไม่ต้องใช้เครื่องมือทดสอบ ตัวอย่างเช่น เครื่องมือทดสอบอื่นที่ต้องพิจารณาคือ PSRule สําหรับ Azure ซึ่งรวมถึงกฎและการทดสอบที่สร้างไว้ล่วงหน้าสําหรับ Azure ซึ่งสามารถเรียกใช้การตรวจสอบความถูกต้องบนเทมเพลตของคุณ และยังเรียกใช้การทดสอบกับทรัพยากร Azure ที่ถูกปรับใช้ของคุณ มีลิงก์ไปยัง PSRule ในสรุปมอดูล
เมื่อคุณใช้เฟรมเวิร์กการทดสอบที่ได้รับการสนับสนุน Azure Pipelines จะเข้าใจผลลัพธ์ของแต่ละการทดสอบ ซึ่งแสดงผลลัพธ์การทดสอบควบคู่ไปกับข้อมูลการเรียกใช้ไปป์ไลน์และจะติดตามประวัติของแต่ละการทดสอบเมื่อเวลาผ่านไป ในแบบฝึกหัดถัดไป คุณจะเห็นวิธีที่คุณสามารถใช้ Azure Pipelines กับการทดสอบควันโครงสร้างพื้นฐาน
ส่งผ่านข้อมูลระหว่างขั้นตอนและขั้นตอน
เมื่อคุณแบ่งไปป์ไลน์ของคุณออกเป็นขั้นตอน แต่ละรายการด้วยความรับผิดชอบของตนเองบางครั้งคุณต้องส่งผ่านข้อมูลระหว่างขั้นตอนเหล่านี้ ตัวอย่างเช่น ขั้นหนึ่งอาจสร้างทรัพยากร Azure ที่ขั้นตอนอื่นจําเป็นต้องทํางานด้วย หากต้องการส่งผ่านข้อมูล ลําดับขั้นที่สองจําเป็นต้องทราบชื่อของทรัพยากรที่สร้างขึ้น ตัวอย่างเช่น ในแบบฝึกหัดต่อไปนี้ ขั้นตอนการทดสอบควันจําเป็นต้องเข้าถึงทรัพยากรที่ขั้นตอนการปรับใช้
ไฟล์ Bicep ของคุณปรับใช้ทรัพยากรเพื่อให้สามารถเข้าถึงคุณสมบัติของทรัพยากรและเผยแพร่เป็นเอาต์พุตการปรับใช้ คุณสามารถเข้าถึงผลลัพธ์การปรับใช้ในไปป์ไลน์ของคุณได้ ใน Azure Pipelines มีไวยากรณ์พิเศษสําหรับการเผยแพร่ตัวแปรเพื่อให้พร้อมใช้งานในทุกขั้นตอน
ก่อนอื่น คุณจําเป็นต้องเผยแพร่ตัวแปรผลลัพธ์สําหรับขั้นตอนไปป์ไลน์ เมื่อต้องการส่งออกตัวแปร คุณเขียนสตริงที่จัดรูปแบบพิเศษไปยังบันทึกไปป์ไลน์ ซึ่ง Azure Pipelines สามารถอ่านได้ ในตัวอย่างต่อไปนี้ ตัวแปรที่ชื่อ myVariable ถูกตั้งค่าเป็นค่า myValue:
echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"
Azure Pipelines อ่านและตีความสตริงจากบันทึกไปป์ไลน์ และทําให้ค่าของตัวแปรพร้อมใช้งานเป็นเอาต์พุต คุณสามารถรวมค่านี้กับการเขียนสคริปต์เพิ่มเติมเพื่อเผยแพร่ค่าของผลลัพธ์การปรับใช้ Bicep เป็นตัวแปรเอาต์พุตสําหรับขั้นตอนไปป์ไลน์ คุณจะเห็นวิธีการเขียนสคริปต์นี้ในแบบฝึกหัดถัดไป
ประการที่สองคุณต้องทําให้ตัวแปรพร้อมใช้งานสําหรับงานของขั้นตอนการทดสอบควันของคุณ คุณจะกําหนดตัวแปรสําหรับงาน และใช้สตริง YAML ที่จัดรูปแบบเป็นพิเศษอื่น:
- stage: SmokeTest
jobs:
- job: SmokeTest
variables:
myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]
ตอนนี้ ขั้นตอนใด ๆ ภายในงานทดสอบควันสามารถเข้าถึงค่า myVariable ได้เช่นเดียวกับตัวแปรอื่น ๆ โดยใช้ไวยากรณ์ $(myVariable) คุณจะใช้ตัวแปรในแบบฝึกหัดถัดไป
ประเภทการทดสอบอื่น ๆ
การทดสอบการทํางาน และการทดสอบการรวม มักใช้ เพื่อตรวจสอบว่าทรัพยากรที่ปรับใช้ทํางานตามที่คุณคาดหวังหรือไม่ ตัวอย่างเช่น การทดสอบการรวมอาจเชื่อมต่อกับเว็บไซต์ของคุณส่งธุรกรรมทดสอบแล้วรอเพื่อยืนยันว่าธุรกรรมเสร็จสิ้นแล้ว โดยการใช้การทดสอบการรวมคุณสามารถทดสอบโซลูชันที่ทีมของคุณสร้างขึ้นพร้อมกับโครงสร้างพื้นฐานที่กําลังทํางานอยู่ได้ ในมอดูลในอนาคต คุณจะเห็นวิธีที่คุณสามารถเพิ่มการทดสอบประเภทเหล่านี้ไปยังไปป์ไลน์ของคุณ
นอกจากนี้ยังเป็นไปได้ที่จะเรียกใช้การทดสอบชนิดอื่น ๆ จากไปป์ไลน์การปรับใช้รวมถึงการทดสอบประสิทธิภาพและการทดสอบการเจาะระบบความปลอดภัย การทดสอบเหล่านี้อยู่นอกขอบเขตของโมดูลนี้ แต่พวกเขาสามารถเพิ่มค่าไปยังกระบวนการปรับใช้อัตโนมัติได้
ย้อนกลับหรือย้อนกลับไปข้างหน้า
สมมติว่าไปป์ไลน์ของคุณปรับใช้ทรัพยากรของคุณเรียบร้อยแล้ว แต่การทดสอบของคุณล้มเหลว แล้วคุณควรทําอย่างไรล่ะ?
ก่อนหน้านี้ในโมดูลนี้ คุณได้เรียนรู้ว่าไปป์ไลน์ Azure ช่วยให้คุณสามารถสร้างขั้นตอนการย้อนกลับ ที่ทํางานเมื่อขั้นตอนก่อนหน้าล้มเหลว คุณสามารถใช้วิธีนี้เพื่อสร้างขั้นตอนย้อนกลับเมื่อขั้นตอนการทดสอบของคุณรายงานผลลัพธ์ที่ไม่คาดคิด คุณยังสามารถย้อนกลับการเปลี่ยนแปลงของคุณหรือเรียกใช้ไปป์ไลน์ทั้งหมดของคุณด้วยตนเองถ้าคุณคิดว่าความล้มเหลวนั้นเกิดจากปัญหาชั่วคราวที่ได้รับการแก้ไขแล้ว
โน้ต
เมื่อคุณส่งการปรับใช้ไปยัง Azure Resource Manager คุณสามารถขอให้ Resource Manager เรียกใช้การปรับใช้ที่สําเร็จครั้งล่าสุดของคุณโดยอัตโนมัติหากล้มเหลว ในการทําเช่นนี้ คุณจําเป็นต้องใช้ขั้นตอน Azure CLI เพื่อปรับใช้ไฟล์ของคุณ และเพิ่มพารามิเตอร์ --rollback-on-error เมื่อคุณส่งการปรับใช้โดยใช้คําสั่ง az deployment group create
บ่อยครั้งที่เป็นเรื่องยากที่จะทํางานขั้นตอนที่ควรดําเนินการขั้นตอนการย้อนกลับ โดยทั่วไป การปรับใช้ Bicep มีความซับซ้อนและการเปลี่ยนแปลงย้อนกลับไม่ใช่เรื่องง่าย ซึ่งจะยากอย่างยิ่งที่จะย้อนกลับเมื่อการปรับใช้ของคุณมีคอมโพเนนต์อื่น ๆ
ตัวอย่างเช่น สมมติว่าไปป์ไลน์ของคุณปรับใช้ไฟล์ Bicep ที่กําหนดฐานข้อมูล Azure SQL จากนั้นเพิ่มข้อมูลบางอย่างไปยังฐานข้อมูล เมื่อการปรับใช้ของคุณจะย้อนกลับ ข้อมูลควรถูกลบหรือไม่ ควรลบฐานข้อมูลด้วยหรือไม่? เป็นเรื่องยากที่จะคาดเดาว่าทุกความล้มเหลวและทุกการย้อนกลับอาจส่งผลกระทบต่อสภาพแวดล้อมการทํางานของคุณ
ด้วยเหตุผลนี้ องค์กรจํานวนมากต้องการ กลิ้งไปข้างหน้าซึ่งหมายความว่าพวกเขาแก้ไขเหตุผลสําหรับความล้มเหลวได้อย่างรวดเร็วแล้วจึงปรับใช้อีกครั้ง ด้วยการสร้างกระบวนการปรับใช้อัตโนมัติคุณภาพสูงและด้วยการปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดทั้งหมดที่คุณได้เรียนรู้ตลอดเส้นทางการเรียนรู้เหล่านี้ คุณจะสามารถแก้ไขปัญหาและปรับใช้ไฟล์ Bicep ของคุณใหม่ในขณะที่ยังคงรักษาคุณภาพสูงได้
ปลาย
หนึ่งในหลักการของแนวคิด DevOps คือการเรียนรู้จากข้อผิดพลาด หากคุณจําเป็นต้องย้อนกลับการปรับใช้ ให้พิจารณาอย่างรอบคอบว่าทําไมข้อผิดพลาดเกิดขึ้นและเพิ่มการทดสอบอัตโนมัติก่อนที่การปรับใช้ของคุณจะเริ่มทํางานเพื่อตรวจหาปัญหาเดียวกันหากเกิดขึ้นในอนาคต