PlAwAnSaI
Administrator
Code:
https://iamondemand.com/blog/devops-concepts-pets-vs-cattle
สัตว์เลี้ยงกับปศุสัตว์กลายเป็นการเปรียบเทียบที่มีชื่อเสียงสำหรับการทำงานของ Server ในมุมของการจัดการโครงสร้างพื้นฐาน ด้วยการเพิ่มขึ้นของ Cloud Computing ธุรกิจต่างๆ จำเป็นต้องเพิ่มความได้เปรียบในการแข่งขันกับ App ของตน รับประกันความพร้อมใช้งานสูงและมีเวลาตอบสนองที่รวดเร็วยิ่งขึ้น
โดยทั่วไป Server ในศูนย์ข้อมูลภายในองค์กรจะถูกมองว่าเป็น “สัตว์เลี้ยง” ในขณะที่ Server ในระบบ Cloud ถือเป็น “ปศุสัตว์” สัตว์เลี้ยงเป็น Server ที่ขาดไม่ได้ซึ่งคุณสามารถเปลี่ยนแปลงการกำหนดค่าได้หากเกิดปัญหา ในขณะที่ ปศุสัตว์ เป็น Server ที่สามารถลบและสร้างใหม่ตั้งแต่ต้นในกรณีที่เกิดความล้มเหลว
ในบทความนี้ จะเจาะลึกแนวคิดเกี่ยวกับโครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลง (Immutable) และอธิบายว่าทำไมโครงสร้างพื้นฐานนี้จึงเริ่มครอบงำหลักการเก่าของ Workload ที่เปลี่ยนแปลงได้ (Mutable) นอกจากนี้ จะ Discuss เกี่ยวกับวิธีจัดการโครงสร้างพื้นฐานสมัยใหม่ และใช้หลักการของความไม่เปลี่ยนแปลงเพื่อสร้างสถาปัตยกรรมแบบ Cloud Native
โครงสร้างพื้นฐานที่เปลี่ยนแปลงได้ กับ โครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลง:
มีความแตกต่างระหว่างวิธีที่เราปฏิบัติต่อ Server ในศูนย์ข้อมูลภายในองค์กรกับในระบบ Cloud
Server ภายในองค์กรแบบดั้งเดิมต้องได้รับการบำรุงรักษาและไม่สามารถทำลายได้ Server ในระบบ Cloud จะถือเป็น Server ชั่วคราว ผู้ให้บริการระบบ Cloud รายใหญ่ เช่น AWS, Azure และ Google Cloud สามารถช่วยให้คุณได้รับโครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลงใน Layer ต่างๆ ใน Stack App ของคุณ
- โครงสร้างพื้นฐานที่เปลี่ยนแปลงได้: Server สามารถถูกแก้ไขได้ด้วยตัวคุณ คุณสามารถเข้าสู่ระบบ Server ทำการเปลี่ยนแปลงการกำหนดค่า และติดตั้ง/แก้ไข Package ได้
- โครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลง: เมื่อใช้งานแล้ว Server จะไม่สามารถแก้ไขได้ หากคุณต้องการเปลี่ยนแปลงการกำหนดค่า คุณสามารถ Update Image ที่มีอยู่และเปิด Server ใหม่เพื่อแทนที่ตัวเก่าได้ ไม่อนุญาตให้มีการเปลี่ยนแปลงการกำหนดค่าหรือ Code บน Server ในขณะที่ Server กำลังทำงาน
ประโยชน์ของโครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลง:
ระบบแบบ Distribute กำลังนำแนวคิดโครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลงมาใช้อย่างรวดเร็ว การสร้างความไม่เปลี่ยนแปลงในสถาปัตยกรรมระบบของคุณมีประโยชน์หลายประการ พูดง่ายๆ ก็คือ การมีโครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลงหมายความว่าหากคุณต้องการเปลี่ยนแปลงการกำหนดค่าใดๆ ใน Server คุณจะต้องไม่แก้ไข Server ที่มีอยู่ แต่คุณจะสร้าง Server เครื่องใหม่ด้วยการกำหนดค่าที่ Update แล้ว
การแก้ไข Server ในขณะที่ Server ทำงานอยู่นั้นเป็นกระบวนการที่เสี่ยงต่อความผิดพลาดและอาจทำให้เกิดการเปลี่ยนแปลงร้ายแรงได้ การสร้างโครงสร้างพื้นฐานของคุณตั้งแต่เริ่มต้นด้วยการกำหนดค่าใหม่และการมีวิธีการทดสอบที่เหมาะสมก่อนที่จะ Deploy เป็นวิธีที่ดีกว่า
- ทำให้การดำเนินงานของคุณง่ายขึ้น:
เมื่อคุณไม่ต้องจัดการกับการตรวจจับการ Drift ภายในส่วนประกอบของคุณ และสามารถเปลี่ยนส่วนประกอบของคุณแทนการแก้ไขได้ การดำเนินการของคุณก็จะง่ายขึ้น การมีโครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลง ทำให้ไม่จำเป็นต้องจัดการ Server ที่ใช้งานจริงจำนวนมาก ซึ่งหมายความว่าทีมพัฒนาของคุณสามารถมุ่งเน้นไปที่การเปลี่ยนแปลง App และให้โครงสร้างพื้นฐานอัตโนมัติของคุณเป็นคนจัดการ Environment แทน
- การกู้คืนอย่างรวดเร็วจากความล้มเหลว:
เมื่อต้องรับมือกับโครงสร้างพื้นฐาน ความล้มเหลวเป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่การมีความสามารถในการแทนที่ Node ของคุณด้วยวิธีอัตโนมัติจะช่วยให้คุณฟื้นจากความล้มเหลวได้อย่างรวดเร็ว หากไม่มีโครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลง คุณจะต้องใช้เวลาในการหาปัญหาและแก้ไข อย่างไรก็ตาม คุณสามารถลบและสร้าง Instance ใหม่ตั้งแต่ต้นด้วย Server ที่ไม่เปลี่ยนแปลงโดยใช้ Base Image ที่ Update
ไม่จำเป็นต้องวุ่นวายกับการหาการเปลี่ยนแปลงการกำหนดค่าระหว่าง Server ด้วย Server ที่ไม่เปลี่ยนแปลง คุณจะต้องรักษา Base Image ไว้ใน Source Control การ Update การกำหนดค่าจะถูกนำไปใช้กับ Base Image และทดสอบอย่างเพียงพอก่อนที่จะเปิด Server ใหม่ เช่นเดียวกับ App Code ของคุณ การเปลี่ยนแปลงการกำหนดค่า Server ใดๆ จะต้องเป็นไปตามกระบวนการ CI/CD ด้วย
- ปรับขนาดโครงสร้างพื้นฐานของคุณแบบ Dynamic:
เมื่อคุณเริ่มใช้ Base Image เพื่อเปิดใช้งานโครงสร้างพื้นฐานของคุณโดยอัตโนมัติ คุณสามารถปรับขนาด Environment ของคุณแบบ Dynamic ตาม Load App ของคุณ เมื่อ Load ลดลง คุณยังสามารถลดขนาด Workload ของคุณได้อีกด้วย การมีความสามารถในการ Spin Instance ที่เหมือนกันโดยใช้เวลาเริ่มต้นเพียงเล็กน้อยช่วยให้คุณใช้กลยุทธ์สำหรับการปรับขนาดแบบ Dynamic และเพิ่มประสิทธิภาพการใช้ Resource โครงสร้างพื้นฐานของคุณ
- การลดปัจจัยเสี่ยงให้เหลือน้อยที่สุด:
ในส่วนหนึ่งของ Pipeline CI/CD คุณต้อง Deploy App ของคุณกับ Environment ที่แตกต่างกัน เช่น Dev, QA, Integration, Staging และ Live
คุณเคยเจอเหตุการณ์ที่การเปลี่ยนแปลง Code ของคุณทำงานได้ดีใน Environment Non-production แต่ไม่สามารถใช้งานได้จริงมั้ย?
บ่อยครั้ง สิ่งนี้เกิดขึ้นเนื่องจากความแตกต่างของ State ระหว่าง Environment เมื่อใช้การกำหนดค่าด้วยตนเอง การรักษา Environment ทั้งหมดของคุณให้อยู่ใน State Synchronize จะกลายเป็นเรื่องท้าทาย วิธีแก้ปัญหาอย่างรวดเร็วคือการใช้โครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลง การใช้ Base Image เดียวกันในทุก Environment สามารถลดการ Drift และทำให้เกิด Environment ที่เป็นมาตรฐานได้
- การรักษาความปลอดภัยโครงสร้างพื้นฐานของคุณ:
เมื่อ Update Patch รักษาความปลอดภัยหรือ Update กับโครงสร้างพื้นฐานแบบเดิมของคุณ คุณอาจประสบปัญหาหลังจากการ Upgrade คุณจะจัดการกับเหตุการณ์ที่ Patch ทำให้เกิดการเปลี่ยนแปลงที่ไม่สมบูรณ์ได้อย่างไร? จะเกิดอะไรขึ้นหากคุณ Reboot Server ของคุณหลังจากการ Update แล้วมันไม่กลับมา?
ด้วยโครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลง คุณจะ Update ความปลอดภัยกับ Base Image, run ทดสอบ, จากนั้น Publish Image ที่จะใช้โดย App ของคุณ ตามแนวทางปฏิบัติที่ดีที่สุด (Best Practice) คุณควรสร้าง Base Image ของคุณเป็นประจำเพื่อให้แน่ใจว่า Agent ของคุณทั้งหมดมีความทันสมัย กระบวนการนี้ทำงานได้อย่างมีประสิทธิภาพจากมุมมองด้านความปลอดภัย เนื่องจากคุณสร้าง Instance ตั้งแต่เริ่มต้นทุกครั้งโดยใช้ Base Image ที่ได้รับอนุญาตและทดสอบแล้ว
การจัดการโครงสร้างพื้นฐานสมัยใหม่ในระบบ Cloud:
แนวคิดของปศุสัตว์เข้ากันได้ดีกับบริการที่ทำงานบน Container และการใช้เครื่องมือจัดการ Container ยอดนิยม เช่น Kubernetes คุณสามารถเปรียบเทียบ Model "สัตว์เลี้ยงสู่ปศุสัตว์" กับ Model "Bare-metal-stack สู่ Container" ได้
องค์กรต่างๆ กำลังโยกย้าย Workload จากภายในองค์กรไปยังโครงสร้างพื้นฐานระบบ Cloud อย่างต่อเนื่อง และในกระบวนการนี้ ก็ได้นำ Model ปศุสัตว์มาใช้กับ Container และ Kubernetes การจัดการกับการใช้งาน App ของคุณเหมือนกับการทำปศุสัตว์แทนที่จะเป็นสัตว์เลี้ยง จะทำให้ Environment มีความเสถียรและมีเวลาทำงานที่สูงกว่า Workload ที่ไม่เปลี่ยนแปลงเป็นที่ต้องการ เพื่อให้คุณสามารถสร้างโครงสร้างพื้นฐานใหม่ผ่านระบบอัตโนมัติได้
การสร้าง App แบบ Cloud-Native:
Technology Cloud-native ช่วยให้องค์กรต่างๆ นำ Container, Microservices, โครงสร้างพื้นฐานที่ไม่เปลี่ยนแปลง และ Service Mech มาใช้เพื่อ Run บริการใน Environment แบบ Dynamic
ความไม่เปลี่ยนแปลงเป็นหนึ่งในจุดแข็งที่ยิ่งใหญ่ที่สุดของ Workload แบบ Container ขณะออกแบบสถาปัตยกรรม Cloud-Native ตรวจสอบให้แน่ใจว่า Container ของคุณไม่เปลี่ยนแปลง และคุณไม่ได้แก้ไข App ของคุณภายใน Container ที่มีอยู่ ตามแนวทางปฏิบัติที่ดีที่สุด คุณควรจัด Package App ของคุณและ Dependency ทั้งหมดลงใน Container ด้วย เมื่อคุณต้องการเปลี่ยนแปลง App ของคุณหรือ Patch Container ที่ทำงานอยู่ คุณควร Deploy Container Version ใหม่ การใช้หลักการของความไม่เปลี่ยนแปลงในระดับ App ช่วยให้คุณลดความซับซ้อนของกลยุทธ์การ Deploy และทำให้สามารถทำซ้ำได้มากขึ้น
วิธีทำให้ App ของคุณไม่เปลี่ยนแปลง:
การเปิดรับแนวคิดเรื่องความไม่เปลี่ยนแปลงในสถาปัตยกรรมของคุณอาจเป็นการเปลี่ยนกระบวนทัศน์ มันทำให้เกิดความซับซ้อนในขั้นตอนการทำงานของคุณ และต้องใช้ระบบอัตโนมัติและการทดสอบในระดับสูงเพื่อตรวจสอบความถูกต้องของการใช้งานของคุณ คุณจะต้องใช้ประโยชน์จากเครื่องมือและบริการที่ได้รับการจัดการต่างๆ จากผู้ให้บริการระบบ Cloud ของคุณ เพื่อลดความซับซ้อนของความพยายามในการพัฒนา
- Infrastructure as Code (IaC)
- Container
- Golden Image
- Kubernetes Automated Health Checks
- Blue-Green Deployment
Last edited: