New Relic ลดเวลาการเผยแพร่ลง 99% ได้อย่างไรด้วย GitHub workflows

New Relic ลดเวลาการเผยแพร่ลง 99% ได้อย่างไรด้วย GitHub workflows

ทีม Kubernetes Agents ของ New Relic ลดเวลาการเผยแพร่ลง 99% ได้อย่างไรด้วย GitHub workflows

ในฐานะที่เป็นบริษัทด้านการสังเกตการณ์ New Relic สร้างและดูแลเอเจนต์เฉพาะภาษาและเทคโนโลยีต่างๆ เพื่อรวบรวมข้อมูล telemetry จากสภาพแวดล้อมของลูกค้า เมื่อทีมเอเจนต์เหล่านี้ปล่อยอัปเดตใหม่ด้วยตนเอง พวกเขาจะดำเนินการตรวจสอบหลายอย่างเพื่อให้แน่ใจว่ากระบวนการดังกล่าวจะไม่ก่อให้เกิดการถอยหลังอันเนื่องมาจากข้อผิดพลาดของมนุษย์เพื่อลดเวลาในการปล่อยอัปเดตใหม่ ทีมเอเจนต์ Kubernetes ได้ทำใหกระบวนการปล่อยซอฟต์แวร์เอเจนต์เป็นระบบอัตโนมัติทั้งหมด เวิร์กโฟลว์ GitHub Actions ที่สามารถนำกลับมาใช้ใหม่ได้ ทำหน้าที่ติดตามจุดอ่อนของการพึ่งพา ตีพิมพ์เอกสาร และซิงค์ข้อมูลกับพันธมิตรอย่าง Amazon Elastic Kubernetes Service (Amazon EKS) ได้ ทุกที่ก่อนหน้านี้ การส่งอัปเดตไปยังการผสานรวม Kubernetes ของเราเป็นแบบแมนนวล ซึ่งใช้เวลานานถึงสองสัปดาห์ ขณะนี้ กระบวนการอัตโนมัติใช้เวลาเพียง 1 ชั่วโมงต่อสัปดาห์

การลดเวลาตอบสนองต่อเหตุการณ์ด้านความปลอดภัย

ข้อความนี้ชี้ให้เห็นถึงความท้าทายหนึ่งที่บริษัทประสบพบเจอ นั่นคือ การตอบสนองต่อช่องโหว่ด้านความปลอดภัย โดยบริษัทจะดำเนินการแก้ไขความเสี่ยงนี้ เฉพาะเมื่อลูกค้าติดต่อ Global Technical Support (GTS)

เพื่อยกปัญหา ซึ่งส่งผลต่อ

เพื่อเป็นส่วนหนึ่งของกระบวนการ Continuous Integration (CI) เราได้เปิดใช้งานเครื่องมือสแกนโค้ดเพื่อคอยอัปเดตเกี่ยวกับช่องโหว่ล่าสุดที่พบในโค้ดของเรา เราได้เปิดใช้งาน CodeQL เพื่อค้นหาช่องโหว่ในฐานข้อมูลโค้ดของเรา และเราใช้ Trivy เพื่อให้แน่ใจว่า Docker image ของเราไม่มีช่องโหว่ที่แทรกเข้ามาจาก base image และไลบรารี่ที่รวมอยู่ด้วย

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

ตัวอย่างที่ชัดเจนของการตอบสนองที่รวดเร็วขึ้นของเราคือ แดชบอร์ดความปลอดภัยแจ้งเตือนเราเกี่ยวกับช่องโหว่ด้านความปลอดภัยดังต่อไปนี้ใน alpine:3.18.4

(ซึ่งเป็นภาพที่เราใช้ใน nri-kubernetes integration ในเวลานั้น)

ช่องโหว่ที่รอดำเนินการแก้ไขทั้งสองรายการนั้น ถูกติดธงแจ้งเตือนไว้ในแดชบอร์ดความปลอดภัยของเราเรียบร้อยแล้ว

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

การให้การสนับสนุน Kubernetes เวอร์ชันล่าสุดอย่างล้ำสมัย

การให้การสนับสนุน Kubernetes เวอร์ชันใหม่เกี่ยวข้องกับการอัปเดตเครื่องมือทดสอบของบุคคลที่สามและการทำการทดสอบความสอดคล้องอย่างละเอียดเพื่อให้แน่ใจว่า Kubernetes เวอร์ชันใหม่ไม่มีการเปลี่ยนแปลงที่สร้างความเสียหายต่อการรวมระบบของเรา

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

เมื่อ Kubernetes เวอร์ชันใหม่เปิดตัว การอัปเดตเวิร์กโฟลว์การทดสอบของเราให้รวมเวอร์ชันล่าสุดนั้นถือเป็นสิ่งสำคัญ Renovate เครื่องมือจัดการการพึ่งพาของเรา สร้าง pull request (PR) โดยอัตโนมัติเพื่ออัปเดต Minikube เป็นเวอร์ชันล่าสุด

เราใช้ minikube เพื่อสร้างคลัสเตอร์ Kubernetes ขึ้นมาอย่างรวดเร็ว จากนั้นจึงรันการทดสอบแบบ end-to-end และดำเนินการทดสอบทั้งหมดในแต่ละเวอร์ชันของ Kubernetes ที่เรารองรับ เมื่อ minikube อัปเดตเป็นเวอร์ชันล่าสุดของ Kubernetes เราจะเปิดใช้งานการทดสอบสำหรับเวอร์ชันนั้นในเฟรมเวิร์กการทดสอบของเรา ถ้าการทดสอบยืนยันว่าการรวมระบบทำงานตามที่คาดหวัง เราสามารถประกาศรองรับ Kubernetes เวอร์ชันล่าสุดได้ เนื่องจากเวิร์กโฟลว์ของเราเป็นระบบอัตโนมัติ เราจึงอัปเดตชุดทดสอบเพื่อใช้ประโยชน์จาก Kubernetes เวอร์ชันล่าสุดในวันเดียวกันที่ minikube ประกาศวางจำหน่าย สิ่งนี้ทำให้เราสามารถทดสอบความเข้ากันได้ภายในหนึ่งวัน และประกาศว่าการรวมระบบ Kubernetes ของเรารองรับการเปิดตัวล่าสุดได้ภายในเจ็ดวันหลังจากที่ minikube วางจำหน่าย

ซิงค์การเผยแพร่ตัวแทนล่าสุดกับ AWS EKS Anywhere Add Ons

New Relic สนับสนุนโปรแกรมพาร์ทเนอร์ Amazon EKS Anywhere โดยนำเสนอเอเจนต์ Kubernetes ของเราเป็น Add-on สำเร็จรูปสำหรับคลัสเตอร์ Amazon EKS Anywhere เราพัฒนาเวิร์กโฟลว์ GitHub Actions เพื่อเปิดการ Pull Request โดยอัตโนมัติเมื่อเราดำเนินการเผยแพร่รุ่นใหม่ของเอเจนต์ สิ่งนี้ช่วยให้ผู้ใช้ปลายทางของ Amazon EKS Anywhere ของเราได้รับการอัปเดตกับเวอร์ชันเอเจนต์ล่าสุดอย่างต่อเนื่อง ทำให้แน่ใจว่า New Relic ยังคงผ่านการทดสอบความสอดคล้องล่าสุดและยังคงเป็นพาร์ทเนอร์ที่ได้รับการรับรองของ Amazon EKS Anywhere

การทำให้ changelog การสื่อสาร และเอกสารเป็นไปโดยอัตโนมัติ

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

สรุป

CI (Continuous Integration) มอบประโยชน์มากมายให้กับนักพัฒนา แต่ประโยชน์เหล่านั้นขยายไปไกลกว่าการทำให้ชีวิตของพวกเขาสะดวกขึ้น ลูกค้ายังได้รับผลประโยชน์อย่างมากจากกระบวนการนี้ด้วยคุณพูดถูกอย่างแน่นอน ท่อ CI ที่มีประสิทธิภาพนั้นเหนือกว่าการสร้างระบบอัตโนมัติในกระบวนการเผยแพร่ตัวแทน มันเกี่ยวข้องกับการปรับปรุงการทดสอบเพื่อรับประกันว่าไม่มีการถอยหลังเกิดขึ้นในกระบวนการ ตรวจสอบช่องโหว่ด้านความปลอดภัยอย่างรวดเร็วและแก้ไขทันที และสื่อสารกับผู้มีส่วนได้เสียทั้งหมดอย่างชัดเจนและมีประสิทธิภาพ

ข้อมูลจาก : newrelic.com

Naruemon Paengjaem
Naruemon Paengjaem