เครื่องมือการจัดการการกำหนดค่า (Puppet, Chef) สามารถปรับปรุงแพ็คเกจที่ติดตั้งไว้ได้หรือไม่?

นี่อาจเป็นคำถามง่ายๆสำหรับพวกคุณที่ใช้เครื่องมือจัดการการกำหนดค่า เครื่องมือการจัดการการกำหนดค่าเช่น Puppet หรือ Chef เป็นแนวทางที่ถูกต้องในการปรับปรุงแพ็คเกจที่ติดตั้งไว้หรือไม่?

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

ขณะนี้ฉันเรียกใช้"การอัปเกรดแบบไม่ต้องใส่ข้อมูล"เพื่อให้ระบบติดตั้งอัปเดตความปลอดภัยโดยอัตโนมัติ แต่ฉันยังต้องเชื่อมต่อกับเซิร์ฟเวอร์และเรียกใช้aptitude update && aptitude safe-upgradeทุกครั้ง โดยธรรมชาติแล้วสิ่งนี้ทำให้เซิร์ฟเวอร์น่าเบื่อน่าเบื่อและเกิดข้อผิดพลาดได้ง่าย

เครื่องมือต่าง ๆ เช่น Puppet หรือ Chef เป็นแนวทางที่ถูกต้องในการปรับปรุงแพ็คเกจที่ติดตั้งไว้หรือไม่? คุณใช้เครื่องมือเหล่านี้เพื่อหลีกเลี่ยงการทำงานด้วยตนเองaptitudeหรือเทียบเท่ากับเซิร์ฟเวอร์ 15 เครื่องหรือไม่? ฉันค่อนข้างแน่ใจว่าคำตอบสำหรับคำถามเหล่านี้คือ "ใช่แน่นอน!"

แต่ฉันจะหาข้อมูลเพิ่มเติมเกี่ยวกับกรณีการใช้งานนี้ได้ที่ไหน? ฉันยังไม่ได้มีเวลาศึกษา Puppet หรือ Chef ในเชิงลึกและตัวอย่างตำราหรือชั้นเรียนจะแสดงตัวอย่างที่น่ารำคาญเล็กน้อยเกี่ยวกับการติดตั้งแพ็คเกจหนึ่งเช่น ssh คุณมีแหล่งข้อมูลใดบ้างที่จะแนะนำนอกเหนือไปจากเอกสารอย่างเป็นทางการ (แน่นอนว่าฉันจะไปศึกษาเอกสารเมื่อฉันรู้ว่าเครื่องมือใดเหมาะสำหรับฉัน)

Puppet (ฉันค่อนข้างแน่ใจว่าพ่อครัวทำเช่นนั้น) ผูกกับคลังซอฟต์แวร์apt-get / yum ของคุณ เนื่องจากพวกเขาทำการค้นหาอย่างหนักว่ามีแพ็คเกจใดบ้างนั่นหมายความว่าensure => latestใช้ได้กับ Ubuntu / CentOS / Debian เท่านั้น ตราบใดที่คุณตั้งค่าไฟล์ที่เหมาะสมให้ถูกต้อง ( /etc/apt/sources.listฯลฯ )

คุณสามารถทำได้ด้วยหุ่นเชิด

ensure => latest,

หรือ

ensure=> "1.0.2",

เพื่อระบุรุ่นล่าสุด / จำเป็น กล่าวคือ

package { apache2: ensure => "2.0.12-2" }
package { apache2: ensure => latest }

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

การรันการอัปเกรดแบบไม่ต้องใส่ข้อมูลทำให้ฉันกลัวเล็กน้อยโดยเฉพาะอย่างยิ่งหากพวกเขากำลังอัพเกรดแพ็คเกจภารกิจสำคัญ, เมล็ด, คลัง mysql, apache และอื่น ๆ โดยเฉพาะอย่างยิ่งหากสคริปต์การติดตั้งอาจต้องการเริ่มบริการใหม่!

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

วิธีที่ฉันทำคือการรักษา repo Yum โดยเฉพาะ (สำหรับ Redhat / Fedora / CentOS; ที่เก็บ APT สำหรับ Debian / Ubuntu) ซึ่งมีแพ็คเกจที่ฉันสนใจสำหรับบางไซต์ โดยทั่วไปแล้วสิ่งเหล่านี้จะขึ้นอยู่กับการพึ่งพาของแอพพลิเคชั่นนั้นเอง (Ruby, PHP, Apache, Nginx, library และอื่น ๆ ) และแพคเกจที่สำคัญต่อความปลอดภัย

เมื่อคุณตั้งค่านี้แล้ว (โดยปกติคุณสามารถทำมิเรอร์แพ็คเกจที่จำเป็นจาก repo upstream เพื่อเริ่มต้นด้วย) คุณสามารถใช้ไวยากรณ์ "มั่นใจ => ล่าสุด" ของ Puppet เพื่อให้แน่ใจว่าเครื่องของคุณทั้งหมดจะทันสมัยกับ repo

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

การกำหนดเวอร์ชันแพ็คเกจโดยอัตโนมัติขอแนะนำให้คุณนำระบบการผลิตทั้งหมดของคุณมาซิงค์กันเนื่องจากการบำรุงรักษา repos และแพ็คเกจต่าง ๆ สำหรับ distros OS ที่แตกต่างกันเวอร์ชั่นและสถาปัตยกรรมเครื่องนั้นใช้เวลานานมากและอาจนำไปสู่ปัญหาที่คลุมเครือและไม่เข้ากัน

คำแนะนำทั้งหมดนี้นำไปใช้อย่างเท่าเทียมกันกับพลอย Ruby, Python Egg และระบบแพ็คเกจอื่น ๆ ที่คุณอาจใช้

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

ขณะที่หุ่น / เชฟมีลุ้นที่เป็นไปได้สำหรับการทำงานนี้จะทำให้พวกเขาเก็บทุกอย่างในระบบ up-to-date ต้องใช้ประเภทที่กำหนดเองหรือรายชื่อทุกแพคเกจ (รวมทั้งที่อยู่ภายใต้ระบบห้องสมุดเช่น libc6) ensure => latestเป็นทรัพยากรที่มี สำหรับกรณีเฉพาะของการอัปเดตแพ็คเกจอัตโนมัติคุณอาจต้องการตรวจสอบcron-aptแพ็คเกจซึ่งทำสิ่งที่คุณต้องการเช่นกัน

คำถามนี้เก่า แต่ฉันคิดว่าฉันจะตอบอย่างเป็นปัจจุบันเนื่องจากคำตอบที่มีอยู่ในปัจจุบันไม่สามารถใช้งานได้ในตอนนั้น

หากคุณกำลังใช้หุ่นเชิดหรือพ่อครัว มันเป็นเครื่องมือที่ดีมากโดยพวก puppetlabs ที่ให้คุณส่งคำสั่งไปยังกลุ่มของเซิร์ฟเวอร์ http://docs.puppetlabs.com/mcollective/

นอกจากนี้ยังมีปลั๊กอิน apt ซึ่งสามารถใช้อัปเดต apt บนเซิร์ฟเวอร์จำนวนเท่าใดก็ได้: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt

ฉันรู้ว่ามันค่อนข้างช้าสำหรับคำถามต้นฉบับของคุณ แต่ที่นี่มันอยู่ในจิตวิญญาณของ "ดีกว่าไม่สาย"

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

นี่คือตัวอย่างสัญญาจากการกำหนดค่า cfengine ของฉัน:

    packages:
            "apache2"
                    package_method => "apt",
                    package_policy => "update";

หวังว่านี่จะช่วยได้

ฉันเห็นด้วยกับโจนาธาน วิธี Cfengine 3 นั้นดีเพราะคุณสามารถควบคุมการจัดการบรรจุภัณฑ์ได้ทุกด้านโดยไม่ต้องทำการถอดรหัสในระดับต่ำ

เราใช้หุ่นเชิด + apt-dater

คุณยังสามารถใช้เครื่องมือการจัดการแพ็คเกจเช่น Canonicals Landscape ซึ่งออกแบบมาเพื่อจัดการและตรวจสอบระบบ Ubuntu / Debian มันจัดการหลายระบบช่วยให้คุณสามารถอัปเดตพร้อมกันและให้ความสามารถในการตรวจสอบขั้นพื้นฐานบางอย่าง

อัปเดตความปลอดภัย

โดยทั่วไปฉันคิดว่าการใช้ Ansible หรือคล้ายกันนั้นง่ายที่สุดในการตั้งค่าแพ็คเกจการอัปเกรดแบบไม่ต้องใส่ข้อมูลที่แข็งแกร่งสำหรับ Ubuntu / Debian (หรือyum-cronสำหรับ RHEL / CentOS) คุณสามารถใช้ Puppet, Chef หรือเครื่องมืออื่น ๆ ได้ แต่ฉันจะพูดถึง Ansible ที่นี่

• unattended-upgrades สามารถใช้เพื่ออัปเดตที่ไม่ใช่ความปลอดภัยในเวลาเดียวกันหากคุณต้องการซึ่งง่ายกว่าการรันคำสั่งผ่าน Ansible ทุกวัน

• unattended-upgradesดูแลการอัปเดตอัตโนมัติทุกวันและตามปกติจะ จำกัด การอัปเดตความปลอดภัยเท่านั้น (เพื่อเพิ่มความเสถียร) หากเซิร์ฟเวอร์ต้องการการรีบูตหลังการอัพเดตเครื่องมือนี้สามารถรีบูตอัตโนมัติในเวลาที่กำหนด

หากการรีบูตเครื่องมีความซับซ้อนมากขึ้นคุณunattended upgradesสามารถส่งอีเมลถึงคุณและสร้างได้/var/run/reboot-requiredขึ้นเพื่อให้ Ansible (หรือที่คล้ายกัน) สามารถจัดการการรีบูตในเวลาที่เหมาะสม (เช่นการรีบูตเครื่องใหม่ของคลัสเตอร์ของเว็บหรือเซิร์ฟเวอร์ DB เพื่อหลีกเลี่ยงการหยุดทำงาน เซิร์ฟเวอร์ที่พร้อมใช้งานบนพอร์ต TCP ที่แน่นอนก่อนดำเนินการต่อ)

คุณสามารถใช้บทบาทAnsibleเช่นjnv.unattended-upgradeสำหรับระบบ Ubuntu / Debian หรือใช้งานง่าย แต่มีประสิทธิภาพ geerlingguy.security ที่ซึ่งยังครอบคลุมถึง RHEL / CentOS (และปรับแต่ง SSH ได้ยากขึ้น)

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

อัพเดททั่วไป

การอัปเดตอื่น ๆ นอกเหนือจากการรักษาความปลอดภัยควรผ่านกระบวนการบูรณาการและการทดสอบอย่างต่อเนื่องตามปกติเพื่อให้แน่ใจว่าสิ่งต่าง ๆ จะไม่หยุดชะงัก

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