แนวปฏิบัติที่ดีสำหรับการจัดการการอัพเดตแพ็คเกจสำหรับเซิร์ฟเวอร์ CentOS จำนวนมาก

เป็นส่วนหนึ่งของงานของฉันฉันจัดการเซิร์ฟเวอร์ CentOS 5 ไม่กี่สิบใช้หุ่นเชิดสำหรับการตั้งค่าหลัก เซิร์ฟเวอร์ของเราประมาณครึ่งหนึ่งมีการตั้งค่าแบบมาตรฐานสำหรับการโฮสต์เว็บไซต์ django ต่างๆในขณะที่ส่วนที่เหลือเป็นแอปพลิเคชั่นที่ผิดพลาด

ฉันค่อยแยกแยะวิธีปฏิบัติเกี่ยวกับการโฮสต์ของเราและตอนนี้ฉันก็ถึงจุดที่จะหาวิธีจัดการการปรับปรุงความปลอดภัยในระดับระบบปฏิบัติการ ฉันระวังที่จะมีงาน cron ทำyum -y updateแต่ยังไม่ต้องการที่จะต้องไปรอบ ๆ แต่ละเซิร์ฟเวอร์ในเวลาและตรวจสอบทุกแพคเกจที่มีการปรับปรุงพร้อมใช้งานซึ่งอาจใช้เวลาสักครู่

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

ขั้นตอนที่ฉันตัดสินใจมา:

• ปิดการใช้งานที่เก็บของบุคคลที่สามทั้งหมดและตั้งค่าพื้นที่เก็บข้อมูลของเราเองเพื่อให้ฉันสามารถควบคุมสิ่งที่อัปเดตผ่านไปได้
• เรามีเซิร์ฟเวอร์ทดสอบสำหรับ (ส่วนใหญ่) เซิร์ฟเวอร์ที่ใช้งานจริงของเราที่ฉันสามารถทำการทดสอบได้ (แต่การทดสอบเพียงพอที่จะทดสอบเท่าไหร่?)

นอกจากนี้ทราบว่าฉันได้มองเข้าไปในปลั๊กอินการรักษาความปลอดภัย yumแต่มันไม่ทำงานบน CentOS

ดังนั้นคุณจะจัดการอัพเดตสำหรับเซิร์ฟเวอร์ CentOS จำนวนมากที่ใช้งานแอพพลิเคชั่นที่หลากหลายได้อย่างไร

ในสภาพแวดล้อมส่วนใหญ่ของฉันมักจะเป็นสคริปต์เริ่มต้นและหลังการติดตั้งเพื่อทำให้ระบบหลักเป็นปัจจุบันและเป็นปัจจุบันด้วยการอัปเดตในขณะนั้น ฉันมักจะมี repo ในพื้นที่ที่ซิงค์กับ CentOS mirror ทุกวันหรือทุกสัปดาห์ ฉันมักจะหยุดการทำงานของเคอร์เนลแพ็กเกจตามเวลาปัจจุบันของเวลาการติดตั้งและอัปเดตแพ็คเกจแยกต่างหากหรือตามความจำเป็น บ่อยครั้งที่เซิร์ฟเวอร์ของฉันมีอุปกรณ์ต่อพ่วงที่มีไดรเวอร์เชื่อมโยงอย่างใกล้ชิดกับเคอร์เนลเวอร์ชันดังนั้นจึงเป็นข้อพิจารณา

CentOS 5 ครบกำหนดจนถึงจุดที่ไม่จำเป็นต้องทำการอัพเดทอย่างต่อเนื่อง แต่โปรดจำไว้ว่า CentOS 5 นั้นกำลังคดเคี้ยว อัตราของการอัปเดตค่อนข้างช้าและลักษณะของการอัพเดตนั้นสอดคล้องกับบั๊กมากขึ้นและน้อยลงเกี่ยวกับการเปลี่ยนแปลงการทำงานที่สำคัญ

ดังนั้นในกรณีเฉพาะนี้สิ่งแรกที่คุณสามารถทำได้คือสร้างมิเรอร์ / ซื้อคืนภายในเครื่อง ใช้การจัดการการกำหนดค่าที่มีอยู่เพื่อควบคุมการเข้าถึง repos ของบุคคลที่สาม อาจกำหนดนโยบายเพื่อให้ยำปรับปรุงบริการที่สำคัญหรือสาธารณะ (ssh, http, ftp, dovecot และอื่น ๆ ) ทุกอย่างอื่นจะต้องมีการทดสอบ แต่ฉันรู้สึกว่าสภาพแวดล้อมส่วนใหญ่ไม่ทำงานด้วยระบบที่อัปเดต / แก้ไขเต็ม

มีเครื่องมือมากมายที่สามารถช่วยได้! โดยทั่วไประบบแพ็กเกจและแพ็กเกจที่ไปในที่ซึ่งจัดการโดยการจัดการการกำหนดค่า เครื่องมือเหล่านี้มักจะครอบคลุมมากกว่าแค่ยำและ rpms เท่านั้นและจะช่วยคุณประหยัดเวลาและป้องกันอาการปวดหัวจำนวนมาก!

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

http://people.redhat.com/dlutter/puppet-app.html

ปัจจุบันมีเครื่องมือจัดการการกำหนดค่าจำนวนหนึ่งซึ่งมีกลุ่มผู้ใช้ที่ค่อนข้างใหญ่:

• Cfengine http://cfengine.com/cfengine3
• หุ่นกระบอกhttp://puppetlabs.com/puppet/puppet-difference/
• Chef http://wiki.opscode.com/display/chef/Home (ไม่กี่คนที่ฉันรู้ว่าเพิ่งติดตั้งและใช้งานมัน)

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

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

ส่วนหนึ่งที่สำคัญมากเกี่ยวกับการทดสอบคือการจำลองข้อมูล / การใช้งาน คุณพูดถึงว่าคุณมีฮาร์ดแวร์ที่ใช้ในการผลิตส่วนใหญ่ พวกเขามีสำเนาของข้อมูลการผลิตเหมือนกันหรือไม่ คุณสามารถเล่นซ้ำโหลดการผลิตใด ๆ กับมันได้หรือไม่ คุณสามารถทำให้เป็นส่วนหนึ่งของคลัสเตอร์การผลิตโดยใช้ Traffic Mirroring ได้หรือไม่? ซึ่งมักจะเป็นการแลกเปลี่ยนโดยตรงระหว่างปริมาณทรัพยากรที่ธุรกิจยินดีใช้ในการทดสอบ / QA ยิ่งทดสอบมากเท่าไหร่ก็ยิ่งดีเท่านั้นอย่าพยายาม จำกัด ตัวเอง (ด้วยเหตุผล) และดูว่าธุรกิจจะให้การสนับสนุนอะไรบ้าง