DevOps Day 58: ฝึกติดตั้ง Grafana และจัดการดิสก์บน Azure
บันทึกการเรียนรู้ DevOps วันที่ 58 จาก KodeKloud อธิบายขั้นตอนการ deploy Grafana บน Kubernetes ผ่านไฟล์ manifest และการเชื่อมต่อ Managed Disk เข้ากับ Azure VM พร้อมเทคนิคการตรวจสอบสถานะและข้อควรระวังเรื่องทรัพยากร
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- บันทึก DevOps วันที่ 58 มุ่งเน้นไปที่งาน Kubernetes หนึ่งงานและงาน Azure หนึ่งงานจากแพลตฟอร์ม KodeKloud
- การใช้งาน Deployment และ Service แบบ NodePort เพื่อเปิดพอร์ต 32000 ให้ Grafana พร้อมกำหนดค่า resource requests และ limits
- การเชื่อมต่อ Managed Disk ชื่อ datacenter-disk เข้ากับ Azure VM พร้อมวิเคราะห์ความต่างของพารามิเตอร์เวอร์ชัน Azure CLI
การเรียนรู้ DevOps ดำเนินมาถึงวันที่ 58 และวันที่ 8 บนคลาวด์ Azure โดยโจทย์ในวันนี้สะท้อนให้เห็นถึงช่องว่างระหว่างสถานะ "สร้างแล้ว" กับ "พร้อมใช้งานจริง" เช่น การที่ Deployment รายงานสถานะ 1/1 ก่อนที่ตัวเว็บ Grafana จะเริ่มให้บริการจริงๆ หรือการที่ดิสก์แสดงสถานะ Attached ในขณะที่ระบบปฏิบัติการยังมองเห็นเป็นอุปกรณ์เปล่า โจทย์ฝึกปฏิบัติจากแพลตฟอร์ม KodeKloud ในวันนี้จึงแบ่งออกเป็นฝั่ง Kubernetes และฝั่ง Azure อย่างละหนึ่งงาน
งานแรกคือการสร้าง Deployment ชื่อ grafana-deployment-datacenter ด้วยภาพ container ของ Grafana และเปิดใช้งานผ่าน NodePort Service บนพอร์ต 32000 โดยในไฟล์ manifest เดียวกันสามารถรวมทั้งสอง object เข้าด้วยกันได้ผ่านตัวคั่นเครื่องหมายสามขีด โดยมี label app: grafana ทำหน้าที่เป็นสะพานเชื่อมระหว่าง Deployment, pod template และ Service เข้าด้วยกันโดยไม่มีการอ้างอิงชื่อตรงๆ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เมื่อนำไฟล์ manifest ไปปรับใช้ผ่านคำสั่ง kubectl apply และตรวจสอบสถานะด้วยคำสั่ง kubectl get ทรัพยากรทั้งหมดควรแสดงผลความพร้อมตามที่กำหนด นอกจากนี้ยังสามารถใช้คำสั่ง kubectl port-forward เพื่อเข้าถึงหน้าเว็บผ่านโลคอลโฮสต์ได้ในกรณีที่ไอพีของโหนดไม่สามารถเข้าถึงได้โดยตรง ส่วนการเข้าสู่ระบบครั้งแรกสามารถใช้ชื่อผู้ใช้และรหัสผ่านเริ่มต้นเป็น admin ก่อนที่ระบบจะบังคับให้เปลี่ยนรหัสผ่านใหม่
ช่องว่างระหว่างสถานะของระบบ เช่น การที่ Kubernetes รายงานว่าพ็อดพร้อมทำงาน (Ready 1/1) แต่เบราว์เซอร์ยังไม่สามารถโหลดหน้าเว็บได้ทันที เป็นอุปสรรคคลาสสิกที่มักเกิดขึ้นเพราะตัวพ็อดเริ่มต้นทำงานเร็วกว่าตัวแอปพลิเคชันภายใน การใช้งาน readinessProbe และ livenessProbe จึงเป็นแนวทางสำคัญในการตรวจสอบสถานะเชิงลึกของแอปพลิเคชันอย่างแท้จริง ไม่ใช่แค่ตรวจดูว่า container รันอยู่หรือไม่
อย่างไรก็ตาม ไฟล์ manifest ที่ใช้งานในการฝึกอบรมยังขาดองค์ประกอบสำคัญหลายประการเมื่อเทียบกับแนวปฏิบัติของ Grafana เช่น การกำหนดหน่วยความจำและซีพียูขั้นต่ำที่แนะนำ ซึ่งหากกำหนดต่ำเกินไปอาจนำไปสู่ปัญหาหน่วยความจำหมดและถูกระบบฆ่ากระบวนการทิ้ง (Out-Of-Memory Kill) รวมถึงเรื่องการจัดเก็บข้อมูลบนฐานข้อมูล SQLite ภายใน container ที่จะสูญหายทั้งหมดหากไม่มีการ mount พื้นที่จัดเก็บภายนอก
"By default, Grafana uses an embedded SQLite version 3 database to store configuration, users, dashboards, and other data."
Grafana Documentation
ในส่วนของภารกิจฝั่ง Azure โจทย์คือการเชื่อมต่อดิสก์ที่มีอยู่แล้วชื่อ datacenter-disk เข้ากับเครื่องเสมือน datacenter-vm ที่กำลังทำงานอยู่ โดยใช้คำสั่ง az vm disk attach ซึ่งระบบจะทำการกำหนดหมายเลข LUN ต่ำสุดที่ว่างให้อัตโนมัติคือ 0 ทั้งนี้ดิสก์ที่เชื่อมต่อเข้ามาใหม่จะยังคงเป็นดิสก์ดิบที่ไม่มีการแบ่งพาร์ติชันหรือฟายล์ระบบใดๆ ตามขอบเขตของงานที่ได้รับมอบหมาย
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ประเด็นที่น่าสนใจระหว่างการตรวจสอบขนาดดิสก์ผ่านคำสั่ง az disk show และ az vm show คือผลลัพธ์ของคีย์ที่แตกต่างกันเล็กน้อยระหว่างตัวพิมพ์ใหญ่และตัวพิมพ์เล็กใน JMESPath ซึ่งสะท้อนให้เห็นว่าความแตกต่างของเวอร์ชัน Azure CLI อาจส่งผลต่อโครงสร้างข้อมูลที่ส่งคืนกลับมาได้ในทางปฏิบัติ
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น