การปรับใช้เซิร์ฟเวอร์โดยอัตโนมัติ


28

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

เซิร์ฟเวอร์ที่ฉันปรับใช้จนถึงตอนนี้เป็นเพียง Ubuntu แต่อาจเป็นไปได้ว่าฉันเริ่มใช้ระบบปฏิบัติการ Linux อื่น ๆ หรือแม้แต่ Windows จนถึงตอนนี้ฉันได้ดูที่ Capistrano แต่ดูเหมือนจะมุ่งเน้นไปที่การเขียนโปรแกรมทับทิมเล็ก ๆ น้อย ๆ เพื่อทำงานกับและฉันไม่มีความรู้เลย


คำตอบ:


20

Puppetฟังดูสมบูรณ์แบบสำหรับสิ่งที่คุณพยายามจะทำด้วยข้อแม้ที่ ณ ตอนนี้ไม่มีการสนับสนุน Windows

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

Puppet เป็นแบบประกาศ - อนุญาตให้คุณอธิบายกล่องของคุณในแง่ของทรัพยากรที่แต่ละกล่องควรมี ดังนั้นถ้าคุณต้องการssh- คุณเขียนคลาสสำหรับทรัพยากรนั้น - และภายในชั้นเรียนคุณสามารถรวมตรรกะเกี่ยวกับวิธีที่ ssh เรียกว่าแตกต่างกันเล็กน้อยใน FreeBSD vs Ubuntu นอกจากนี้ยังรู้วิธีใช้yumภายใน Redhat และapt-getภายใน Distros ตาม Debian และportsใน BSD ตอนนี้ในโหนดเซิร์ฟเวอร์ของคุณคุณจะมีบรรทัดเหมือนinclude ssh- และหุ่นเชิดจะทำสิ่งที่ถูกต้องและวาง SSH ไว้ในเครื่องโดยที่คุณไม่ต้องจำว่าเป็น Ubuntu หรือ Redhat หรือ FreeBSD

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

ตอนนี้ฉันแค่จัดการสามกล่องโดยใช้ Puppet - แต่มันก็จ่ายไปแล้ว หลังจากใช้เวลาหนึ่งสัปดาห์ในการตั้งค่ากล่องเราจะใช้สำหรับการนำเสนอสิ่งเร้าในการทดลองมันกลับกลายเป็นว่าไดรเวอร์การ์ดแสดงผลเก่าเกินไปในเวอร์ชันของ Ubuntu ที่ฉันวางไว้ (8.04) ฉันต้องติดตั้ง Ubuntu ล่าสุด (9.04) แต่หลังจากนั้นฉันต้องรับและเรียกใช้หุ่นเชิด - และทุกอย่างที่ฉันใช้ไปในการตั้งค่าสัปดาห์ก็คืนค่า

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

ในที่สุดนี่คือวิดีโอฉบับย่อที่สาธิตหุ่นกระบอกเล็ก ๆ ที่ทำให้ฉันเริ่มต้นได้อย่างรวดเร็ว


3
Digg.com ใช้หุ่นเชิดเพื่อจัดการเซิร์ฟเวอร์ตัวอย่างพื้นฐานบางอย่างสามารถพบได้ในบล็อกของพวกเขา: blog.digg.com/?p=335 blog.digg.com/?p=562
Adam Gibbins

ฉันเชื่อว่าทีมผู้ดูแลระบบของ Fedora ใช้หุ่นเชิดด้วยเช่นกัน
พ.ค.

9

เราใช้CobblerและPuppetสำหรับสร้างและกำหนดค่าอัตโนมัติของทั้งเครื่องจริงและเสมือน

Cobbler เชื่อมโยง DHCP, PXE boot และ Kickstart เข้าด้วยกันเพื่อให้การใช้งานไม่มีอะไรมากไปกว่าการเพิ่มโปรไฟล์เครื่องและกดปุ่มเปิดปิด สำหรับ VMs koan คำสั่งจะใช้ Xen magic ในการเริ่มต้นการติดตั้งโดยdom0พิมพ์ I:

koan --system vps.fqdn --server cobbler --no-gfx

จากนั้นvirsh consoleไปดูสิ่งปลูกสร้าง VPS โดยไม่มีการโต้ตอบใด ๆ

เราใช้ RHEL และมีการตั้งค่าโปรไฟล์จำนวนมากสำหรับพาร์ติชันดิสก์กำหนดค่าเครือข่ายและติดตั้งแพ็คเกจพื้นฐานสำหรับคลาสเซิร์ฟเวอร์ที่แตกต่างกัน Cobbler รองรับสายพันธุ์ Debian และ Ubuntu แต่ฉันไม่เคยลองเลย ข้อควรระวัง: การใช้ Cobbler ที่น่าสนใจอื่น ๆ ได้แก่ การเรียกใช้ISO memtestและการอัพเดตเฟิร์มแวร์ HP

เมื่อระบบของเราถูกสร้างขึ้นด้วย Cobbler Puppet จะเข้ามากำหนดค่าแอปพลิเคชัน, daemons ของระบบ, ลงทะเบียนกล่องกับ RHN, ฯลฯ Puppet จะทำงานเป็น daemon ซึ่งจะตรวจสอบการกำหนดค่าของระบบเป็นระยะ ๆ ไปยังเซิร์ฟเวอร์ทั้งหมด นอกจากนี้ยังเป็นวิธีที่ดีในการตรวจสอบให้แน่ใจว่ากล่องที่ปิดตัวลงเพื่อการบำรุงรักษามีการกำหนดค่าที่ถูกต้องก่อนที่คุณจะส่งคืนไปยังบริการสด

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


6

ที่ฉันทำงานอยู่ในขณะนี้เราต้องจัดการส่วน Linux ของเซิร์ฟเวอร์ฟาร์มของเราซึ่งมีเซิร์ฟเวอร์ Linux เพียง 300 ตัวเท่านั้น ซึ่งรวมถึง HP Proliants ส่วนใหญ่ตามด้วย IBM 3850s เบลด IBM บางรุ่น VMware ESX และ KVM บางตัวสำหรับเซิร์ฟเวอร์การจัดการภายในของเรา

พายผลไม้

เราดูที่พายผลไม้ แต่ปัญหาที่เกิดขึ้นนั่นคือพายผลไม้เป็น RHEL / Red Hat เฉพาะมาก เราจำเป็นต้องสนับสนุน RHEL และ SLES เป็นอย่างน้อยและ Ubuntu ก็เป็นเช่นนั้น

หุ่นเชิด

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

Hotwire

Hotwire คือสิ่งที่เราใช้ (พัฒนาขึ้นภายใน แต่เป็นโอเพ่นซอร์ส) และได้ทำเช่นนั้นในช่วงไม่กี่ปีที่ผ่านมา ในตอนแรกมันจะทำการสร้างระบบที่กำลังจะสร้างขึ้นซึ่งหมายถึงการจัดทำคลังข้อมูลศูนย์ข้อมูลชั้นวางฮาร์ดแวร์ระบบปฏิบัติการเครือข่าย ฯลฯ และทำการสร้างและปรับใช้อย่างรวดเร็ว เมื่อสร้างระบบขึ้นมาแล้วสินค้าคงคลังอัตโนมัติของ hotwire จะเก็บสินค้าคงคลังไว้ในซิงค์ขณะที่ cfengine ดูแลพวกเขา Hotwire รู้เกี่ยวกับฮาร์ดแวร์เซิร์ฟเวอร์โดยการพูดคุยกับข้อมูล SMBIOS / DMI ใน BIOS ผ่านหลาม dmidecode

คะแนนโบนัสคือการรวมสินค้าคงคลังและสร้างกระบวนการเข้าด้วยกันดังนั้นจึงมีน้อยกว่าในการจัดการและคุณลักษณะของสินค้าคงคลังสดนั้นยอดเยี่ยมดังที่เราทราบว่ามีบางอย่างไม่ถูกต้อง

ข้อเสียคืออินเทอร์เฟซผู้ใช้ยังคงต้องขัดและมีข้อบกพร่องที่นี่และที่นั่น แต่การพัฒนายังคงร้อนและรายงานข้อบกพร่องจะค่อนข้างคงที่อย่างรวดเร็ว

cfengine

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

การกำหนดค่าและไฟล์ทั้งหมดที่ส่งออกโดย cfengine ไปยังเซิร์ฟเวอร์นั้นจะถูกเก็บไว้ใน SCM และการใช้ hooks post-commit หากเป็นไปได้เราจะตรวจสอบไวยากรณ์และหากล้มเหลวการคอมมิทจะถูกปฏิเสธ นี่เป็นเรื่องง่ายสำหรับแอปพลิเคชันที่ดีเช่น Apache แต่ไม่ใช่เรื่องง่ายสำหรับแอปพลิเคชันระดับองค์กรส่วนใหญ่


คุณตัดสินใจเลือกหุ่นกระบอกเพราะมันขึ้นอยู่กับทับทิม จากนี้คุณสามารถตัดสินใจได้เกือบทุกอย่างเพราะ libc หรืออัพเกรดเคอร์เนลอาจทำลายมัน
Cristian Ciupitu

2
คุณเพิ่มจุด แต่ในที่สุดก็ประนีประนอม - ฉันต้องการ "กังวล" เกี่ยวกับแพคเกจในการอัพเกรดครั้งต่อไป หากการอัพเกรดเคอร์เนล / glibc ผิดพลาด - โดยปกติคุณคาดหวังว่าจะพบเกือบจะทันทีเพราะมันเป็นองค์ประกอบพื้นฐานที่สุดของระบบปฏิบัติการอย่างไรก็ตามหาก Ruby ออกมาแตกต่างกันเล็กน้อยคุณจะไม่สังเกตเห็นจริง ๆ แต่เมื่อคุณทำคุณอาจ มีเซิร์ฟเวอร์ 300 ตัวที่ได้รับการอัพเกรดและใช้งานในเวอร์ชันนั้นและตอนนี้ Puppet เป็นเหยื่อ แต่อีกครั้งฉันไม่ได้สลักอะไรด้วยหิน นี่เป็นเพียงความชอบของฉันในเรื่องนี้
Xerxes

5

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


1
อย่าลืมว่า Opscode มีพ่อครัว Cookbooks ที่พร้อมใช้งาน
jtimberman

3

สำหรับการติดตั้งอัตโนมัติขึ้นอยู่กับระบบเป้าหมาย:

  • Debian / Ubuntu: FAI หรือล่วงหน้า
  • RedHat / Fedora: Kickstart
  • Novell / openSuSE: AutoYaST
  • Solaris: Jumpstart
  • Windows: unattended.sourceforge.net

สำหรับการจัดการการกำหนดค่าที่ด้านบนของที่ฉันขอแนะนำให้ใช้หุ่นเชิด



2

โหวตอีกครั้งสำหรับ Puppet ที่นี่ เราใช้อย่างกว้างขวางเพื่อทำการติดตั้งเซิร์ฟเวอร์และแอพพลิเคชั่นและการจัดการการกำหนดค่าทั้งหมด 200+ โหนดและเพิ่มขึ้นเรื่อย ๆ เห็นได้ชัดว่าการสนับสนุน Windows กำลังอยู่ในระหว่างการพัฒนาแม้ว่าจะอยู่ในสภาพที่ไม่แน่ใจ

เรายังคงมองไปที่ bootstrap ด้านต่าง ๆ ของระบบปฏิบัติการ แต่สิ่งที่กล่าวไว้ข้างต้น Cobbler ดูน่าสนใจ ขณะนี้เรากำลังใช้การบูท PXE ร่วมกับการคาดการณ์ล่วงหน้าของ Debian / Ubuntu แต่มันไม่ค่อยดีที่สุด


เฮ้ไมค์คุณคิดว่าคุณสามารถเพิ่มแท็กหุ่นเชิดในคำถามนี้ได้หรือไม่? ฉันจะทำ แต่ไม่มีตัวแทนที่จำเป็น
Paul Ivanov
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.