แนวทางปฏิบัติที่ดีที่สุดสำหรับการอัปเดต Linux อัตโนมัติ

เรากำลังดำเนินการเพื่อทำการอัปเดตอัตโนมัติสำหรับเซิร์ฟเวอร์ที่ใช้ RHEL / RHEL ของเรา

แนวคิดเริ่มต้น:การใช้ Puppet เราจะปิดการใช้งานที่เก็บข้อมูลเริ่มต้นและชี้ไปที่ของเราเอง จากนั้นเราใช้ensure => latestสำหรับแพ็คเกจที่เราต้องการอัพเดทโดยอัตโนมัติ

ปัญหา:เราเห็นว่าบริการบางอย่างเริ่มต้นใหม่หลังจากการอัปเดต (duh)

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

แก้ไข

วิธีแก้ปัญหาที่เป็นไปได้:ฉันส่งโซลูชันที่ใช้ @ voretaq7 และ @ewwhite ที่แนะนำไว้จำนวนมาก ดูเหมือนว่านี่เป็นเส้นทางที่ฉันจะไปในเวลานี้ หากคุณมีข้อเสนอแนะอื่น ๆ โปรดแสดงความคิดเห็นหรือส่งคำตอบ

กลยุทธ์การอัพเดททั่วไปของคุณคือเสียง: คุณมี repo ในพื้นที่ (ซึ่งฉันถือว่าคุณทดสอบในสภาพแวดล้อมแบบ dev) และคุณอัปเดตทุกอย่างตามนั้น (ฉันถือว่าดี) repo

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

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

ความซ้ำซ้อนที่เพิ่มเข้ามายังช่วยคุณในกรณีที่เกิดความล้มเหลวของฮาร์ดแวร์ซึ่งหลีกเลี่ยงไม่ได้ในช่วงเวลาที่นานพอ

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

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

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

@Beaming Mel-Bin

การทำให้เข้าใจง่ายจะไม่จำเป็นต้องใช้ ssh สำหรับเครื่องมือลูปเพื่อเริ่ม / หยุดหุ่นเชิด

ก่อนอื่นคุณจะต้องเปลี่ยนรายการของคุณเพื่อรวมตัวแปรที่เรียกว่า "noop" ซึ่งมีค่าที่มาจาก ENC

ดังนั้นคุณจะมีสิ่งนี้ในชั้นเรียน:

noop => $noop_status

noop_statusตั้งอยู่ที่ไหนใน ENC ของคุณ เมื่อคุณตั้งค่าเป็นnoop_statusถึงtrueรายการจะทำงานในโหมด noop เท่านั้น

หากคุณมีโฮสต์ 100s หรือ 1,000 คุณสามารถใช้ ENC เช่น Dashboard หรือ Foreman ที่ช่วยให้คุณสามารถเปลี่ยนพารามิเตอร์จำนวนมากสำหรับโฮสต์จำนวนมากโดยรับมรดกในระดับ "Hostgroup" หรือ "Domain" จากนั้นคุณสามารถตั้งค่าเป็น "false" สำหรับโฮสต์ทดสอบจำนวนน้อยโดยแทนที่ค่าโฮสต์กรุ๊ป

ด้วยสิ่งนี้การเปลี่ยนแปลงใด ๆ จะถูกนำไปใช้กับโฮสต์ที่เลือกเท่านั้น

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

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

หากคุณต้องการความละเอียดมากขึ้น (และความซับซ้อน) คุณสามารถมีพารามิเตอร์ต่อคลาสเช่นnoop_status_apacheClassและอื่น ๆ

อาจจัดการได้ยากกว่าหากคุณincludeเรียนในชั้นเรียนอื่น

โซลูชันที่เป็นไปได้ตามคำตอบของ @ voretaq7:

1. แพคเกจหมายเลขเวอร์ชันของรหัสฮาร์ดโค้ดในpuppetรายการและบำรุงรักษาแพ็กเกจในที่เก็บของเราเอง

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

3. ทดสอบแพ็คเกจที่อัพเดตบนเซิร์ฟเวอร์ทดสอบ

4. เมื่อมีการทดสอบการอัปเดตให้ใช้สิ่งที่ต้องการfuncหรือpsshปิดpuppetเอเจนต์บนโหนดที่ได้รับผลกระทบ

5. อัพเดตpuppetรายการเพื่อให้แน่ใจว่ามีการติดตั้งแพ็กเกจเวอร์ชั่นใหม่บนโหนดที่ได้รับผลกระทบ

6. ในที่สุดรันpuppet agent --onetime && rebootบนเซิร์ฟเวอร์โดยใช้funcหรือpssh

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