คำถามติดแท็ก puppet

Puppet เป็นเครื่องมือจัดการการกำหนดค่า (Unix & Windows) พร้อม Domain Specific Language

7
เด็กน้อยสามารถเรียนรู้และใช้ Puppet ได้อย่างมีประสิทธิภาพได้อย่างไร [ปิด]
หกเดือนที่แล้วในโครงการที่ไม่แสวงหาผลกำไรของเราเราตัดสินใจที่จะเริ่มโยกย้ายการจัดการระบบของเราไปยังสภาพแวดล้อมที่ควบคุมโดยหุ่นเพราะเราคาดว่าจำนวนเซิร์ฟเวอร์ของเราจะเติบโตอย่างมีนัยสำคัญระหว่างนี้และปีต่อจากนี้ เนื่องจากการตัดสินใจได้ทำให้คนไอทีของเรากลายเป็นบิตรำคาญเกินไปบ่อยเกินไป ข้อคัดค้านที่ใหญ่ที่สุดของพวกเขาคือ: "เราไม่ใช่โปรแกรมเมอร์เราคือ sysadmins"; มีโมดูลให้ออนไลน์ แต่ส่วนใหญ่จะแตกต่างกัน ล้อถูกคิดค้นใหม่บ่อยเกินไปคุณจะตัดสินใจเลือกหนึ่งที่เหมาะสมกับใบเรียกเก็บเงินได้อย่างไร หลักจรรยาบรรณใน repo ของเรายังไม่โปร่งใสพอที่จะค้นหาว่ามีงานอะไรที่พวกเขาจะต้องชดใช้ผ่านรายการและโมดูลที่พวกเขาอาจเขียนด้วยตัวเองสักพักแล้ว หนึ่งดีมอนใหม่ต้องเขียนโมดูลใหม่การประชุมจะต้องมีความคล้ายคลึงกับโมดูลอื่น ๆ กระบวนการที่ยาก; "ลองเรียกใช้แล้วดูว่ามันทำงานอย่างไร" ตัน 'ส่วนขยาย' ที่รู้จักกันไม่ค่อยในโมดูลชุมชน: 'trocla', 'augeas', 'hiera' ... sysadmins ของเราจะติดตามได้อย่างไร ฉันเห็นได้ว่าเหตุใดองค์กรขนาดใหญ่จึงส่งผู้ดูแลระบบไปยังหลักสูตรหุ่นกระบอกเพื่อเป็นอาจารย์หุ่นเชิด แต่ผู้เล่นที่เล็กกว่าจะเรียนรู้ Puppet ในระดับมืออาชีพได้อย่างไรถ้าพวกเขาไม่ไปเรียนและเรียนรู้ผ่านเบราว์เซอร์และเครื่องมือแก้ไขโดยทั่วไป

7
เหตุใดจึงต้องใช้ Chef / Puppet เหนือเชลล์สคริปต์
ใหม่สำหรับเครื่องมือ Puppet และ Chef ดูเหมือนว่างานที่พวกเขาทำสามารถทำได้ด้วยการเขียนสคริปต์เชลล์ บางทีมันอาจจะทำในเชลล์สคริปต์จนกระทั่งสิ่งเหล่านี้มาพร้อมกัน ฉันจะยอมรับว่าพวกเขาอ่านง่ายขึ้น แต่มีข้อได้เปรียบอื่น ๆ ของเชลล์สคริปต์นอกเหนือจากการอ่านได้หรือไม่?

2
ทำไมการอัพเกรดระหว่าง Red Hat และ CentOS เวอร์ชันใหญ่ถึงเป็นเรื่องยาก?
"เราสามารถอัพเกรดเซิร์ฟเวอร์ EL5 ที่ใช้งานจริงของเราเป็น EL6 ได้หรือไม่" คำขอที่ฟังง่ายจากลูกค้าสองคนที่มีสภาพแวดล้อมที่แตกต่างกันอย่างสมบูรณ์ทำให้ฉันได้รับคำตอบที่ดีที่สุดตามปกติ "ใช่ แต่จะต้องมีการประสานการสร้างระบบทั้งหมดของคุณใหม่ " ... ลูกค้าทั้งสองรู้สึกว่าการสร้างระบบใหม่อย่างสมบูรณ์เป็นตัวเลือกที่ไม่สามารถยอมรับได้เนื่องจากสาเหตุของการหยุดทำงานและทรัพยากร ... เมื่อถูกถามว่าทำไมจึงจำเป็นต้องติดตั้งระบบใหม่ทั้งหมดฉันไม่ได้รับคำตอบที่ดีเลย "นั่นคือวิธีที่มันเป็น ..." ฉันไม่ได้พยายามกระตุ้นการตอบสนองเกี่ยวกับการจัดการการกำหนดค่า ("Puppetize ทุกอย่าง " ไม่ได้นำไปใช้เสมอ ) หรือวิธีที่ลูกค้าควรวางแผนได้ดีขึ้น นี่เป็นตัวอย่างจริงของสภาพแวดล้อมที่เติบโตและเจริญเติบโตในความสามารถในการผลิต แต่ไม่เห็นเส้นทางที่สะอาดเพื่อย้ายไปยังระบบปฏิบัติการรุ่นต่อไป สภาพแวดล้อม A: องค์กรที่ไม่แสวงหาผลกำไรที่มี40 x Red Hat Enterprise Linux 5.4 และ 5.5เว็บเซิร์ฟเวอร์ฐานข้อมูลและเมลเซิร์ฟเวอร์เรียกใช้จาวาแอปพลิเคชันเว็บ Java, ตัวโหลดบาลานซ์ของซอฟต์แวร์และฐานข้อมูล Postgres ระบบทั้งหมดถูกจำลองเสมือนบน VMWare vSphere สองคลัสเตอร์ในสถานที่ต่างกันโดยแต่ละแห่งมี HA, DRS และอื่น ๆ สภาพแวดล้อม B: บริษัท การค้าทางการเงินความถี่สูงที่มีระบบ200 …

6
สิ่งที่ไม่ควรจัดการโดยหุ่นเชิด
ฉันเรียนรู้ทางของฉันผ่านจัดการการตั้งค่าทั่วไปและใช้หุ่นเชิดที่จะใช้มันโดยเฉพาะอย่างยิ่งและฉันสงสัยว่าสิ่งที่ด้านของระบบถ้ามีควรได้รับการจัดการกับหุ่น? ตัวอย่างเช่นเรามักจะเห็นว่าชื่อโฮสต์ได้รับการตั้งค่าแล้วก่อนที่จะยืมระบบเพื่อการจัดการหุ่นกระบอก การเชื่อมต่อ IP ขั้นพื้นฐานอย่างน้อยในเครือข่ายที่ใช้ในการเข้าถึง puppetmaster ต้องทำงานได้ การใช้หุ่นเชิดเพื่อสร้างไฟล์โซน dns โดยอัตโนมัตินั้นเป็นสิ่งที่ดึงดูด แต่ตัวชี้กลับ DNS ควรอยู่ในตำแหน่งก่อนที่จะเริ่มสิ่งหรือใบรับรองจะตลก ดังนั้นฉันควรออกจากการกำหนดค่า IP จากหุ่นเชิดหรือไม่ หรือฉันควรตั้งค่าก่อนเริ่มต้นหุ่นเชิดเป็นครั้งแรก แต่จัดการที่อยู่ IP ด้วยหุ่นเชิด? ระบบที่มี IP หลายตัว (เช่นสำหรับ WAN, LAN และ SAN) แล้วIPMIล่ะ คุณสามารถกำหนดค่าส่วนใหญ่หากไม่ได้ทั้งหมดของมันด้วยipmitoolช่วยให้คุณประหยัดจากการเข้าถึงคอนโซล (ทางกายภาพ, พอร์ตอนุกรมแบบ over-lan, รีโมต KVM ระยะไกล, อะไรก็ตาม) ดังนั้นมันจึงสามารถทำงานอัตโนมัติด้วยหุ่นเชิด แต่การตรวจสอบสถานะของมันอีกครั้งในการทำงานของตัวแทนหุ่นกระบอกนั้นไม่ได้ดูดีสำหรับฉันเลยและไฟขั้นพื้นฐานในการเข้าถึงระบบก็เป็นสิ่งที่ฉันต้องการก่อนที่จะทำสิ่งอื่น เรื่องราวทั้งหมดเกี่ยวกับการติดตั้งการอัปเดต ฉันไม่ได้ไปในจุดเฉพาะนี้มีคำถามมากมายเกี่ยวกับ SF และปรัชญาที่แตกต่างกันมากมายระหว่าง sysadmins ที่แตกต่างกัน ตัวเองผมจึงตัดสินใจที่จะไม่ปล่อยให้ปรับปรุงหุ่นสิ่ง (เช่น. เท่านั้นensure => installed) …

5
ทำให้ dpkg- กำหนดค่า tzdata อีกครั้งโดยอัตโนมัติ
ฉันใช้หุ่นเชิดเพื่อดูแลกลุ่มเซิร์ฟเวอร์เดเบียน ฉันต้องการเปลี่ยนเขตเวลาของแต่ละเครื่องในคลัสเตอร์ dpkg-reconfigure tzdataวิธีเดเบียนที่เหมาะสมในการทำเช่นนี้คือการใช้ แต่ฉันสามารถเปลี่ยนได้ก็ต่อเมื่อฉันใช้กล่องโต้ตอบ มีวิธีที่จะทำให้สิ่งนี้เป็นแบบอัตโนมัติจากเปลือกหรือไม่ดังนั้นฉันสามารถเขียน Exec เพื่อทำให้มันง่ายขึ้นได้ไหม? ถ้าไม่ฉันคิดว่าวิธีที่ดีที่สุดถัดไปอาจจะเป็นการกระจายหุ่น/etc/timezoneและ/etc/localtimeมีข้อมูลที่ถูกต้องทั่วทั้งคลัสเตอร์ การป้อนข้อมูลใด ๆ ชื่นชม!

6
Puppet vs Chef, pro และ contra จากผู้ใช้และใช้เคส [ปิด]
ฉัน googled แล้วและอ่าน"เพื่อหุ่นเชิดหรือไปเชฟที่เป็นที่คำถาม"บทความ ฉันสนใจกรณีการใช้งานการใช้งานจริงที่ผู้คนเลือกอย่างใดอย่างหนึ่งบนพื้นฐานของปัญหาจริง ฉันสนใจเป็นพิเศษในการรวมเข้ากับปัญหาของนักพายผลไม้ (ฉันรู้ว่าหุ่นกระบอกเป็นแนวทางมาตรฐานในทิศทางนี้มาก) ใครบ้างที่มีประสบการณ์ในการรวมระบบพายผลไม้ - เชฟ ? ขอบคุณล่วงหน้า

5
ไม่สามารถหาชั้นเรียนและยังมี
เมื่อทำการpuppet agentโทรจากภาพใหม่ฉันได้รับerr: Could not find class custommodข้อผิดพลาด ตัวโมดูลนั้น/etc/puppet/modules/custommodเหมือนกับโมดูลอื่น ๆ ทั้งหมดที่เรากำลังเรียก แต่อันนี้เป็นสิ่งที่ท้าทาย [site.pp] node /clunod-wk\d+\.sub\.example\.local/ { include base include curl include custommod class{ "custommod::apps": frontend => "false} [...] } เมื่อ puppetmaster รันด้วยเอาต์พุต debug มันจะค้นหาข้อมูลสำหรับฐานและขดอย่างชัดเจน: debug: importing '/etc/puppet/modules/base/manifests/init.pp' in environment production debug: Automatically imported base from base into production debug: importing '/etc/puppet/modules/curl/manifests/init.pp' …

5
ผู้ดูแลระบบ Linux สามารถพัฒนาทักษะการสคริปต์เชลล์และระบบอัตโนมัติได้อย่างไร
ในองค์กรของฉันฉันทำงานกับกลุ่มของพนักงาน NOC วิศวกรรุ่นแรกและวิศวกรอาวุโสจำนวนหนึ่ง ทั้งหมดมุ่งเน้นไปที่ Linux ขั้นตอนหนึ่งที่น่าสนใจในการเพิ่มความสามารถของ บริษัท คือมีเส้นทางจาก NOC ไปจนถึงวิศวกรรมอันดับอาวุโส การดูกลุ่มคนที่มีความสามารถเป็นผู้มาใหม่ฉันเห็นว่ามีการแบ่งชุดทักษะที่มีแนวโน้มที่จะเติบโตตลอดเวลา ... มีวิศวกรที่รู้จักเทคโนโลยีหนึ่งหรือหลายอย่างดีและแช่อยู่ตลอดเวลาเช่น MySQL, ไฟร์วอล, ที่เก็บ SAN, โหลดบาลานซ์ ... มีคนอื่นที่เป็นคนทั่วไปและสามารถนำทางเทคโนโลยีหลายอย่างได้ ทั้งหมดเรียนรู้ Linux (คำสั่งกระบวนการ) เพียงพอที่จะทำสิ่งที่พวกเขาต้องการและใช้ในชีวิตประจำวัน ปัจจัยที่แตกต่างระหว่างพนักงานบางคนก็คือวิธีที่พวกเขายอมรับการเขียนสคริปต์อัตโนมัติและวิธีการจัดการการกำหนดค่า ตัวอย่างเช่นเรามีวิศวกรสองคนที่ทำงานเป็นกลุ่มของ Amazon AWS CloudFormationและอีกคนหนึ่งที่จัดการโครงสร้างพื้นฐานหุ่นกระบอกส่วนใหญ่ บางทีหนึ่งในสี่ของวิศวกรมีความเชี่ยวชาญในการเขียนสคริปต์เชลล์ของ BASH เมื่อมองถึงสิ่งนี้ในบริบทของความต้องการDevOps ที่สูงอย่างไม่น่าเชื่อในตลาดงานฉันอยากรู้ว่าองค์กรอื่น ๆ ส่งเสริมการพัฒนาทักษะเหล่านี้และพัฒนาความสามารถภายในของพวกเขาได้อย่างไร การเขียนสคริปต์ดูเหมือนจะเป็นแนวคิดที่สอนไม่ได้โดยเฉพาะ ดูแลระบบปรับปรุงการเขียนสคริปต์เชลล์ได้อย่างไร ยังมีที่สำหรับวิศวกรที่ไม่ทำหรือไม่สามารถติดตามกระบวนทัศน์ DevOps ได้หรือไม่? เราเพียงแค่คิดว่าบางคนจะถูกทิ้งไว้ข้างหลังในขณะที่เทคโนโลยีเหล่านี้วิวัฒนาการ? ไม่เป็นไร

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

10
เครื่องมือการจัดการการกำหนดค่า (Puppet, Chef) สามารถปรับปรุงแพ็คเกจที่ติดตั้งไว้ได้หรือไม่?
นี่อาจเป็นคำถามง่ายๆสำหรับพวกคุณที่ใช้เครื่องมือจัดการการกำหนดค่า เครื่องมือการจัดการการกำหนดค่าเช่น Puppet หรือ Chef เป็นแนวทางที่ถูกต้องในการปรับปรุงแพ็คเกจที่ติดตั้งไว้หรือไม่? สมมติว่าฉันใช้เซิร์ฟเวอร์จำนวนหนึ่งซึ่งส่วนใหญ่ใช้ Debian และ Ubuntu เครื่องมือการจัดการการกำหนดค่าช่วยให้สามารถอัปเดตแพ็คเกจที่ติดตั้งจากที่เก็บได้ง่ายขึ้นเมื่อมีการอัปเดตความปลอดภัยหรือแก้ไขข้อบกพร่องหรือไม่ ขณะนี้ฉันเรียกใช้"การอัปเกรดแบบไม่ต้องใส่ข้อมูล"เพื่อให้ระบบติดตั้งอัปเดตความปลอดภัยโดยอัตโนมัติ แต่ฉันยังต้องเชื่อมต่อกับเซิร์ฟเวอร์และเรียกใช้aptitude update && aptitude safe-upgradeทุกครั้ง โดยธรรมชาติแล้วสิ่งนี้ทำให้เซิร์ฟเวอร์น่าเบื่อน่าเบื่อและเกิดข้อผิดพลาดได้ง่าย เครื่องมือต่าง ๆ เช่น Puppet หรือ Chef เป็นแนวทางที่ถูกต้องในการปรับปรุงแพ็คเกจที่ติดตั้งไว้หรือไม่? คุณใช้เครื่องมือเหล่านี้เพื่อหลีกเลี่ยงการทำงานด้วยตนเองaptitudeหรือเทียบเท่ากับเซิร์ฟเวอร์ 15 เครื่องหรือไม่? ฉันค่อนข้างแน่ใจว่าคำตอบสำหรับคำถามเหล่านี้คือ "ใช่แน่นอน!" แต่ฉันจะหาข้อมูลเพิ่มเติมเกี่ยวกับกรณีการใช้งานนี้ได้ที่ไหน? ฉันยังไม่ได้มีเวลาศึกษา Puppet หรือ Chef ในเชิงลึกและตัวอย่างตำราหรือชั้นเรียนจะแสดงตัวอย่างที่น่ารำคาญเล็กน้อยเกี่ยวกับการติดตั้งแพ็คเกจหนึ่งเช่น ssh คุณมีแหล่งข้อมูลใดบ้างที่จะแนะนำนอกเหนือไปจากเอกสารอย่างเป็นทางการ (แน่นอนว่าฉันจะไปศึกษาเอกสารเมื่อฉันรู้ว่าเครื่องมือใดเหมาะสำหรับฉัน)

1
วิธีอัปเดตแพคเกจโดยใช้หุ่นเชิดและไฟล์. deb
ฉันกำลังพยายามหาวิธีที่เหมาะสมในการอัปเดต / อัปเดตแพ็คเกจ deb โดยใช้หุ่นเชิดจากไฟล์ deb แหล่งภายใน การกำหนดค่าปัจจุบันของฉันมีลักษณะเช่นนี้ ... class adobe-air-2-0-4 { file { "/opt/air-debs": ensure => directory } file { "/opt/air-debs/adobeair-2.0.4.deb": owner => root, group => root, mode => 644, ensure => present, source => "puppet://puppet/adobe-air-2-0-4/adobeair-2.0.4.deb" } package { "adobeair": provider => dpkg, ensure => installed, source => "/opt/air-debs/adobeair-2.0.4.deb" …

7
เพิ่ม repo yum ให้กับ puppet ก่อนทำอะไรอย่างอื่น
มีวิธีบังคับให้หุ่นทำสิ่งต่าง ๆ ก่อนไหม? ตัวอย่างเช่นฉันต้องการให้ติดตั้ง RPM บนเซิร์ฟเวอร์ทั้งหมดเพื่อเพิ่มที่เก็บ yum (ชุมชน IUS) ก่อนที่ฉันจะติดตั้งแพ็คเกจใด ๆ
26 puppet 

7
ความปลอดภัยหุ่นกระบอกและทอพอโลยีเครือข่าย
พื้นหลัง: ในที่สุดฉันก็สละเวลาเพื่อเข้าร่วมศตวรรษที่ 21 และดูหุ่นกระบอก ในฐานะที่เป็นในวันนี้เรารุ่นควบคุมการกำหนดค่าเซิร์ฟเวอร์ทั้งหมดในพื้นที่เก็บข้อมูลที่จัดขึ้นภายในที่สำนักงาน เมื่อจำเป็นต้องมีการอัพเดตการเปลี่ยนแปลงจะถูกตรวจสอบกลับเข้าไปใน repos และผลักออกไปยังเครื่องด้วยตนเอง ซึ่งมักจะหมายถึง SFTP'ing ไปยังเครื่องระยะไกลและจากนั้นย้ายไฟล์เข้าที่มีสิทธิ์ที่เกี่ยวข้องจากเปลือก ดังนั้นฉันหวังว่า Puppet จะเป็นส่วนเสริมที่เรียบง่าย แต่น่าทึ่งสำหรับสิ่งที่เรามีอยู่แล้ว ตอนนี้ฉันพิจารณากระบวนการที่เราต้องมีความปลอดภัยอย่างสมเหตุสมผล บนสมมติฐานที่ว่าเครือข่ายภายในของเราจะมีความปลอดภัยมากกว่าเครือข่ายสาธารณะในศูนย์ข้อมูลของเรา กระบวนการนี้เป็นวิธีหนึ่งเสมอ เปลี่ยนการเคลื่อนที่จากสภาพแวดล้อมที่ปลอดภัยไปเป็นที่ไม่ปลอดภัยและจะไม่มีทางกลับกัน ร้านค้าหลักอยู่ในสถานที่ที่ปลอดภัยที่สุด ความเสี่ยงของการประนีประนอมไม่ว่าจะโดยการขโมยการกำหนดค่าหรือการส่งการดัดแปลงที่เป็นอันตรายจะลดลงอย่างมาก คำถาม: จากสิ่งที่ฉันเข้าใจเกี่ยวกับ Puppet server / client model คือการสำรวจความคิดเห็นของลูกค้าและดึงการอัพเดทโดยตรงจากเซิร์ฟเวอร์ การรับส่งข้อมูลถูกห่อด้วย SSL ดังนั้นจึงไม่สามารถดักจับหรือปลอมแปลงได้ แต่มันแตกต่างจากสิ่งที่เราทำอยู่ในขณะนี้เพราะเซิร์ฟเวอร์ Puppet [s] จะต้องถูกโฮสต์ในที่สาธารณะ ไม่ว่าจะเป็นศูนย์กลางหรือหนึ่งแห่งสำหรับแต่ละศูนย์ข้อมูลที่เราดูแล ดังนั้นฉันสงสัย: ฉันถูกหวาดระแวงโดยไม่จำเป็นเกี่ยวกับการเปลี่ยนแปลงจากการผลักไปสู่การดึง? ฉันถูกหวาดระแวงโดยไม่จำเป็นเกี่ยวกับการจัดเก็บข้อมูลทั้งหมดจากส่วนกลางบนเครือข่ายสาธารณะหรือไม่? คนอื่น ๆ ดูแลเครือข่ายหลายแห่งอย่างไร - แยกเซิร์ฟเวอร์สำหรับแต่ละไซต์ อัปเดต 30/07/09: ฉันเดาว่าหนึ่งในข้อกังวลสำคัญอื่น ๆ ของฉันคือการวางดังนั้นต้องเชื่อมั่นในเครื่องเดียว …

4
ฉันจะลงชื่อใบรับรองหุ่นเชิดล่วงหน้าได้อย่างไร
คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Server Fault อพยพ 9 ปีที่ผ่านมา Puppetต้องการใบรับรองระหว่างไคลเอนต์ (puppet) ที่ถูกจัดการและเซิร์ฟเวอร์ (puppetmaster) คุณสามารถรันด้วยตัวเองบนไคลเอนต์จากนั้นไปที่เซิร์ฟเวอร์เพื่อลงนามใบรับรอง แต่คุณจะทำกระบวนการนี้โดยอัตโนมัติสำหรับกลุ่ม / เครื่องคลาวด์ได้อย่างไร
26 cluster  puppet  cloud 

2
การจัดการการกำหนดค่า: โทโพโลยีแบบพุชและแบบพุช
ระบบการจัดการการกำหนดค่า (CM) ที่เป็นที่ยอมรับมากขึ้นเช่น Puppet และ Chef ใช้วิธีการแบบดึง: ไคลเอนต์สำรวจต้นแบบหลักที่ส่วนกลางเป็นระยะสำหรับการปรับปรุง บางคนเสนอวิธีการที่ไม่เชี่ยวชาญเช่นกัน (เช่นเป็นแบบ push-based) แต่ระบุว่ามันไม่ใช่ 'สำหรับการผลิต' (Saltstack) หรือ 'scalable ที่น้อยลง' (Puppet) ระบบเดียวที่ฉันรู้ว่าเป็นแบบ push-based ตั้งแต่เริ่มต้นคือวิ่ง Ansible อะไรคือข้อได้เปรียบในการปรับขนาดที่เฉพาะเจาะจงของระบบที่ใช้แรงดึง ทำไมมันจึงง่ายกว่าที่จะเพิ่ม pull-masters มากกว่า push-agent ตัวอย่างเช่นagiletesting.blogspot.nlเขียน: ในระบบ 'ดึง' ลูกค้าจะติดต่อกับเซิร์ฟเวอร์โดยไม่ขึ้นต่อกันดังนั้นระบบโดยรวมสามารถปรับขนาดได้มากกว่าระบบ 'ดัน' ในอีกทางหนึ่ง Rackspace แสดงให้เห็นว่าพวกเขาสามารถจัดการกับระบบ 15Kด้วยรูปแบบการผลักดัน infastructures.orgเขียน: เราสาบานด้วยวิธีการดึงสำหรับการบำรุงรักษาโครงสร้างพื้นฐานโดยใช้เครื่องมือเช่น SUP, CVSup, เซิร์ฟเวอร์ rsync หรือ cfengine แทนที่จะผลักดันการเปลี่ยนแปลงไปยังไคลเอนต์แต่ละเครื่องไคลเอนต์แต่ละคนจะต้องรับผิดชอบในการสำรวจเซิร์ฟเวอร์ทองคำตอนบูตและหลังจากนั้นเป็นระยะเพื่อรักษาระดับการหมุนรอบของตัวเอง ก่อนที่จะนำมุมมองนี้มาใช้เราได้พัฒนาสคริปต์แบบพุชอิงที่มีพื้นฐานมาจาก ssh, rsh, rcp และ …

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