เด็กน้อยสามารถเรียนรู้และใช้ Puppet ได้อย่างมีประสิทธิภาพได้อย่างไร [ปิด]


109

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

เนื่องจากการตัดสินใจได้ทำให้คนไอทีของเรากลายเป็นบิตรำคาญเกินไปบ่อยเกินไป ข้อคัดค้านที่ใหญ่ที่สุดของพวกเขาคือ:

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

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

คำตอบ:


101

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

หมายเหตุบางประการเกี่ยวกับคะแนนของคุณ ...

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

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

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

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

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

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

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

โปรดจำไว้ว่าเว็บไซต์นี้เป็นแหล่งข้อมูลที่ดีเช่นกัน


20
ฉันไม่เคยมีประสบการณ์กับหุ่นกระบอกมาก่อนเพื่อให้สภาพแวดล้อมที่สมบูรณ์ของฉันสามารถจัดการได้ภายในสองสัปดาห์ ฉันรับผิดชอบเครื่องจักรเสมือนประมาณ 40 เครื่องแม้ว่าทุกอย่างจะใช้งาน Ubuntu สิ่งที่ทำให้เข้าใจได้ง่ายขึ้นเล็กน้อย ฉันเป็นนักพัฒนาอาชีพ "ดัดแปลงหรือถูกทิ้งไว้ข้างหลัง" - ตอนนี้ฉันเลิก + sysadmin + สถาปนิก คำตอบที่ยอดเยี่ยม!
François Beausoleil

ฉันอยากจะแนะนำให้พวกเขาเริ่มปรับใช้บริการขนาดเล็กก่อนอื่นในแบบสแตนด์อโลนจากนั้นเริ่มซ่อมแซมด้วยเซิร์ฟเวอร์เพิ่มเติม ฉันไม่ต้องทำงานกับ Puppet แต่ฉันมี VPS ขนาดเล็กและฉันเพิ่งสร้างโมดูล Puppet ของตัวเอง หากพวกเขาต้องการที่จะรักษา sysadmins ที่เหลือในศตวรรษปัจจุบันพวกเขาควรจะเปิดกว้าง ฉันทำเพราะฉันชอบและฉันเดาว่าทุกคนไม่ชอบเรียนรู้สิ่งใหม่ แต่สิ่งหนึ่งที่แน่นอนคือทุกวันนี้ระบบดูแลระบบใกล้ชิดกับนักพัฒนามากกว่าที่เคย
Sergio Galvan

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

1
@ Whitewhite ฉันได้ทำงานผ่านการสอน Puppet ในเอกสารของพวกเขา แต่สงสัยว่าหนังสือเล่มไหนที่คุณใช้เมื่อเรียนรู้? ฉันรู้สึกเหมือนการสอนที่มีให้ในเอกสารขาดสิ่งที่ทำให้ทุกอย่างจากการคลิกกับฉันขณะที่ฉันทำงานกับ Puppet บนโฮสต์การทดสอบเพื่อเรียนรู้สิ่งที่ฉันกำลังทำอยู่ แก้ไข: หรือแหล่งข้อมูลเพิ่มเติมใด ๆ ที่คุณสามารถแนะนำ ขอบคุณ
Mike Keller

1
@MikeKeller ฉันชอบไปในโพสต์ของฉัน ... แต่มันก็อยู่ที่นี่
ewwhite

29

ในงานก่อนหน้านี้ฉันได้รับมอบหมายให้ทำภารกิจนำร่องของหุ่นเชิด ตอนนี้ฉันมีพื้นหลังการเขียนโปรแกรม แต่ไม่ใช่ Ruby ดังนั้นฉันจึงไม่มีปัญหามากเท่ากับที่คนอื่นทำ

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

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

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

จากการสังเกตทั้งสองนี้ฉันขอแนะนำให้คุณตรวจสอบให้แน่ใจว่าทุกคนทำการเพิ่มคลาส Puppet คำจำกัดความหรือโมดูลทุก ๆ สัปดาห์ (ควรมีอย่างน้อยสองหรือสามครั้ง) ผู้ที่ยังไม่คุ้นเคยกับมันอาจขาดทักษะในการทำ

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

  • คำตอบ : นี่คือสิ่งใหม่ แต่มันขึ้นอยู่กับคำสั่งเชลล์และ ssh ซึ่งอาจดึงดูดให้ sysadmins แบบดั้งเดิม
  • เชฟ : บางทีปัญหาของพวกเขาอาจเป็นรูปแบบที่เปิดเผยซึ่งในกรณีนี้เชฟจะดีกว่าถ้าพวกเขามีประสบการณ์ทับทิม
  • SaltStack : Python-based และ open-source
  • CFEngine : เก่าเร็วเร็ว - มันอาจชนะพวกมันได้

12
สิ่งที่ดีเกี่ยวกับ ANSIBLE ก็คือมันทำงานได้ในระยะทางกาแลคซีโดยไม่มีการหน่วงเวลาในการรับส่งข้อมูล!
Kalamane

1
ขอบคุณสำหรับการกล่าวถึง ANSIBLE ฉันไม่รู้จนกระทั่งตอนนี้
ewwhite

@ ขาวคุณยินดีต้อนรับ ฉันเองเพิ่งค้นพบมัน แต่เมื่อไม่นานมานี้เอง ถ้าเรามีหุ่นกระบอกไม่มากนักฉันจะลองดู
Daniel C. Sobral

11

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

  1. จงตระหนักว่าคุณกำลังพัฒนาซอฟต์แวร์ซึ่งคุณไม่รู้ว่าจะทำอย่างไรหรือทำไม่ดี คาดว่าจะเป็นเพราะมันใหม่
  2. โครงสร้างพื้นฐานเป็นรหัสคือความเป็นจริงและเมื่อคุณได้ผ่านโคกมันมีประสิทธิภาพมาก ฉันขอเชิญนักพัฒนาบางคนแสดงกระบวนการพัฒนาในปัจจุบันของคุณให้พวกเขา (หรือขาดเลย) อย่าทำผิดเมื่อพวกเขายกคิ้วและให้คำแนะนำอย่างจริงจัง ฉันขอแนะนำให้ใช้ระบบใด ๆ และประมวลผลผู้พัฒนาของคุณใช้เว้นแต่จะไม่เหมาะสมอย่างสมบูรณ์
  3. หุ่นกระบอกโมดูลบุคคลที่สามดูด 90% ของเวลา ฉันอ่านแล้ว ฉันจะขโมยความคิดจากพวกเขา ฉันจะไม่ดึงมันเข้าสู่ระบบของฉันหากไม่มีการแก้ไขครั้งใหญ่ อย่างไรก็ตามฉันจะดึงหุ่นเชิด stdlib ซึ่งเพิ่มฟังก์ชั่นที่ดี
  4. augeas และ hiera เรียนรู้ทั้งสอง ครั้งแรกที่ช่วยให้การแก้ไขที่ซับซ้อนของไฟล์ที่มีอยู่ในสถานที่ ที่สองคือที่เก็บข้อมูลภายนอก
  5. แยกรหัสจากข้อมูล นี่เป็นหนึ่งในแนวคิดที่ยากต่อการเรียนรู้ ค่า Hardcoding เช่น Monitoring Hosts ในโค้ดโมดูลของคุณไม่ดี วางไว้ในแหล่งข้อมูล (db, yaml (Hiera ใช้สิ่งนี้เป็นค่าเริ่มต้น), csv, อะไรก็ตาม) ที่โมดูลของคุณสามารถใช้งานได้ดี ตัวอย่างคือ webapp ที่ใช้ Mysql สิ่งนี้ทำให้ความสามารถในการส่งรหัสและข้อมูลแยกจากกัน ทำให้กระบวนการพัฒนาของคุณง่ายขึ้น
  6. parser หุ่นตรวจสอบและหุ่นเชิดผ้าสำลีเป็นส่วนหนึ่งของคุณก่อนหรือโพสต์กระบวนการเช็คอินรหัส การทดสอบ rspec อาจเป็นความคิดที่ดีเมื่อคุณมีความเร็ว
  7. เขียนคู่มือสไตล์ / มาตรฐานรหัสและใช้มัน "ที่เป็นรหัสที่ติดตั้ง Apache" เป็นปัญหาที่พบบ่อย หากโมดูลของคุณส่วนใหญ่เหมือนกันมันควรจะง่าย

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


ขอขอบคุณสำหรับคำแนะนำของคุณโดยเฉพาะอย่างยิ่ง augeas และ hiera เป็นสององค์ประกอบที่เราได้เริ่มดำเนินการและสิ่งนี้ทำให้เราตระหนักมากยิ่งขึ้นแม้จะมั่นใจในความสามารถของ Puppet ขอบคุณ :-)
drumfire

7

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

ฟังดูเหมือนเป็นความคิดที่ดีที่จะเริ่ม แต่เช้า - Puppet เป็นมากกว่าการจัดการปรับแต่งมันเป็นรูปแบบของเอกสารประกอบ

เนื่องจากการตัดสินใจได้ทำให้คนไอทีของเรากลายเป็นบิตรำคาญเกินไปบ่อยเกินไป

พวกเขาต้องการการปรับทัศนคติ

"We're not programmers, we're sysadmins";

ทัศนคติอีกครั้ง คุณสามารถสร้างไฟล์ conf สำหรับเซิร์ฟเวอร์ได้หรือไม่? คุณสามารถบรรเทาลงใน / Programmer 'สิ่ง templating เป็นความต้องการและความซับซ้อนของวิวัฒนาการ

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

ยากที่จะตอบ - ฉันชอบหุ่นกระบอกโมดูลมากกว่าทุกครั้ง - และถึงอย่างนั้นฉันก็ไม่ได้ใช้มันมากนัก คำพิพากษาให้โทรแน่นอน ในความคิดของฉันบางโมดูลมี 'เกินไป'

หลักจรรยาบรรณใน repo ของเรายังไม่โปร่งใสพอที่จะค้นหาว่ามีงานอะไรที่พวกเขาจะต้องชดใช้ผ่านรายการและโมดูลที่พวกเขาอาจเขียนด้วยตัวเองสักพักแล้ว

สิ่งนี้ไม่ได้ดูเหมือนปัญหาหุ่นกระบอก แต่มีปัญหาเกี่ยวกับองค์กรหรือเอกสารมากกว่านี้

หนึ่งดีมอนใหม่ต้องเขียนโมดูลใหม่การประชุมจะต้องมีความคล้ายคลึงกับโมดูลอื่น ๆ กระบวนการที่ยาก;

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

"Let's just run it and see how it works"

ไม่ใช่ความคิดที่ไม่ดีถ้าคุณทำช้าและปลอดภัย ฉันยังคงเริ่มต้นด้วย VM เพื่อรับส่วนสำคัญของสิ่งต่าง ๆ

ตัน 'ส่วนขยาย' ที่รู้จักกันไม่ค่อยในโมดูลชุมชน: 'trocla', 'augeas', 'hiera' ... sysadmins ของเราจะติดตามได้อย่างไร

postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl modules .. เลือกสิ่งที่คุณต้องการและใช้งานหรือไม่ ฉันเดาว่าเสียงนี้จะเหมือนกับทัศนคติอีกครั้ง ...

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

ฉันยังไม่ได้เข้าร่วมหลักสูตรใด ๆ - ในขณะที่ผมamโปรแกรมเมอร์มากกว่าดูแลระบบผมพบว่ามันไม่จำเป็นต้องมีทักษะการเขียนโปรแกรมมากที่จะได้รับสิ่งที่ประสบความสำเร็จ

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


FYI สิ่งนี้มาจากคนที่เพิ่งเสร็จสิ้นการเตรียมโครงสร้างพื้นฐานให้พร้อม ดังนั้นฉันจึงมีประสบการณ์ใหม่และไม่สามารถพูดได้ว่าเป็นเวลาที่สูญเปล่า
thinice

ในฐานะสมาชิกใหม่เมื่อเร็ว ๆ นี้ฉันรู้จักตัวเองทั้งหมดในความคิดเห็นของคุณ
Martijn Heemels

1
ในกรณีของฉันการเปลี่ยนทัศนคติเป็นสิ่งที่จำเป็นจริงๆ Ops ชอบระบบอัตโนมัติและมักจะเขียนบทดังนั้นมันจึงเป็นเรื่องของการใช้เครื่องมือต่าง ๆ เป็นความรู้สึกที่ยอดเยี่ยมที่ได้เห็นหุ่นกระบอกของคุณกำหนดค่าเครื่องทั้งหมดหรือบริการใหม่ตั้งแต่เริ่มต้น ความจริงที่ว่าข้อผิดพลาดสามารถส่งผลกระทบต่อหลายเครื่องในคราวเดียวจำเป็นต้องคุ้นเคยกับการทดสอบที่เข้มงวดมากขึ้นซึ่งอาจสร้างความรำคาญ แต่ก็เห็นได้ชัดว่าเป็นสิ่งที่ดี ทดลองกับ Vagrant, rspec-puppet, หุ่นกระบอก - ผ้าสำลี, Geppetto, สาขา Git และเครื่องมือฟรีอื่น ๆ แล้วคุณจะค้นพบเวิร์กโฟลว์ที่คุณชื่นชอบในไม่ช้า
Martijn Heemels

1
การทำงานกับ Puppet ช่วยให้ฉันเรียนรู้ Ruby ซึ่งมาแทนที่ Bash เป็นภาษาเครื่องมือระบบเริ่มต้นของฉัน
Martijn Heemels

5

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

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


4
... เพราะเราคาดหวังว่าจำนวนเซิร์ฟเวอร์ของเราจะเพิ่มขึ้นอย่างมากระหว่างนี้และหนึ่งปีนับจากนี้ ต้องการ?
Jeff Ferland

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

+1 สำหรับ "ใช้ขั้นต่ำเปล่าที่การปรับใช้ของคุณต้องการ" - ปัญหาหุ่นกระบอกจำนวนมากที่ฉันได้รับมาจากความพยายามทำให้หุ่นเชิดควบคุมทุกอย่างในระบบ
Sirex

5

ฉันทำงานเพื่อผลกำไรที่ไม่ดีเช่นกันและรับผิดชอบต่อการนำกล่อง Linux มาใช้ที่บ้านและหลังจากนั้นไม่นาน Puppet ก็จัดการมัน มีสองสิ่งที่เราได้ทำไว้ซึ่งช่วยให้สิ่งต่าง ๆ หมุนได้จริง

ก่อนอื่นฉันได้พยายามอยู่ห่างจากโมดูลของบุคคลที่สาม เครื่องมือ inbuilt จัดการ 90% ของการจัดการของเรา ยูทิลิตี้ของบุคคลที่สามที่ใหญ่ที่สุดที่ฉันใช้คือโมดูลไฟร์วอลล์ ข้อเท็จจริงที่กำหนดเองใด ๆ ฯลฯ ได้รับการพัฒนากับทีมงานทั้งหมดที่เกี่ยวข้อง เราได้พัฒนาโมดูลแม่แบบและเก็บการจัดการไฟล์แพ็คเกจบริการและอื่น ๆ ทั้งหมดได้มาตรฐานจากเทมเพลตนี้

ประการที่สองหลังจากสร้างมาตรฐานในการใช้โมดูล inbuilt เราเริ่มใช้ Crucible ของ Git และ Atlassian - ฟรีสำหรับองค์กรที่ไม่หวังผลกำไรโดยวิธี - สำหรับการตรวจสอบการเปลี่ยนแปลงการกำหนดค่าทั้งหมด สิ่งนี้ให้ความโปร่งใสที่ต้องการ

ประการที่สามฉันตั้งค่าอัตโนมัติสำหรับ Puppet เพื่อให้สามารถเพิ่มโฮสต์ใหม่โดยอัตโนมัติด้วยชุดตัวเลือกเริ่มต้น มีหลายวิธีในการจัดการกับเรื่องนี้ เนื่องจากฉันมีสภาพแวดล้อม Kickstart ที่สมบูรณ์ฉันเลือกที่จะเพิ่มสคริปต์ที่นั่น


4

"เราไม่ใช่โปรแกรมเมอร์เราเป็นผู้ดูแลระบบ"

ฉันว่าเวลามีการเปลี่ยนแปลงที่เลวร้ายกว่าที่: greybeard เหมือนผมได้รับการคาดหวังว่าจะเป็นโปรแกรมเมอร์ที่ดีกว่าโปรแกรมเมอร์มืออาชีพหรืออื่น ๆ จะไม่เคยได้รับสามารถที่จะผ่านสำหรับผู้ดูแลระบบ

ตอนนี้เรามี "ผู้ดูแลระบบ" ซึ่งโดยทั่วไปคือผู้ใช้เดสก์ท็อป Windows ที่มีบางจุดที่แปลงเป็น Linux และไม่สามารถโปรแกรมได้และไม่พบสิ่งใด ๆ ที่ผิดปกติ

ช้างในห้องพักเป็นเหตุผลที่ผู้บริหารทนต่อทัศนคติที่ทำลายล้างเช่นนี้ เป็นอันตรายต่อใครหรืออะไร เพื่อธุรกิจและโครงสร้างพื้นฐาน

กลับไปที่ Puppet [, CFEngine, Chef] หัวเรื่อง: ทันทีที่คนหนึ่งตั้งค่าวิธีแก้ปัญหาแบบนั้น ทุกคนแพ้ ทำไม? เนื่องจากผู้ใดก็ตามที่มีแนวคิดนี้ไม่สามารถออกแบบการจัดการการกำหนดค่าที่ห่อหุ้มในรูปแบบของดี, สะอาด, Kickstart [, JumpStart, โปรแกรมติดตั้งอัตโนมัติ, AutoYaST, Ignite-UX, NIM] แพ็คเกจระบบปฏิบัติการ เมื่อคุณต้องใช้เครื่องมือแฮ็คอัตโนมัติเช่น Puppet (หรือ Chef หรือ CFEngine) นั่นหมายความว่าคุณขาดเครื่องมือที่จะออกแบบและใช้กระบวนการที่จะทำให้การออกแบบสมบูรณ์แบบและสมบูรณ์แบบด้วยระบบการจัดการที่สมบูรณ์ อัตโนมัติและไม่โต้ตอบทั้งหมด

อีกจุดที่สำคัญคือถ้าคุณต้องมีหุ่นหรือวิธีการแก้ปัญหาดังกล่าวเพื่อแก้ไขคนแฮ็คระบบหรือการตั้งค่าโปรแกรมด้วยมือที่ยังกลับไปไม่ได้มีประสบการณ์ในการออกแบบกระบวนการและในกระบวนการที่กรอบที่กำหนดค่าเป็นแพคเกจ เป็นองค์ประกอบที่ไม่ต่อเนื่อง ใครก็ตามที่ใช้ Puppet และที่คล้าย ๆ กันนั้นไม่มีแนวคิดของเจ้าของส่วนประกอบ, การเผยแพร่, การจัดการการกำหนดค่า, Capability Maturity Model นี่คือการพัฒนาอย่างรวดเร็วเป็นปัญหาที่ร้ายแรงมากในอุตสาหกรรม

การทำงานกับ Puppet ช่วยให้ฉันเรียนรู้ Ruby ซึ่งมาแทนที่ Bash เป็นภาษาเครื่องมือระบบเริ่มต้นของฉัน "

เหตุใดจึงจำเป็นต้องใช้ Ruby เมื่อการจัดการการกำหนดค่าแบบครบวงจรสามารถครอบคลุมในการติดตั้ง preinstall poster preremove และ postremove ส่วนของแพ็คเกจระบบปฏิบัติการเพียงแค่ใช้โปรแกรม Bourne shell, AWK, และ sed? คนนั้นจะต้องเรียนรู้ภาษารูบีที่ลึกลับและภาษาถิ่นในบริบทของ Puppet นั้นไม่จำเป็นเลย ปัญหาของการจัดการการกำหนดค่าสามารถแก้ไขได้อย่างง่ายดาย (และปัญญาได้รับการแก้ไข) ด้วยโปรแกรมเชลล์และ AWK และสิ่งเล็กน้อย (1) ที่นี่และที่นั่นเป็นกาว

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

มันเป็นสิ่งที่เย็นเห็นมันทำโดยการกระตุ้น AutoYaST หรือ JumpStart, โดยไม่ต้องมีบรรทัดเดียวของรหัสและความสามารถในการค้นหาระบบปฏิบัติการโดยใช้สร้างขึ้นในเครื่องมือโดยไม่จำเป็นต้องซอฟต์แวร์ลึกลับหรือเพิ่มเติมใด ๆ , ไม่มีไคลเอนต์เซิร์ฟเวอร์ สถาปัตยกรรมที่ต้องการ (SSH นั้นดีกว่าดีกว่าดีกว่า) และเห็นระบบปฏิบัติการของคุณตระหนักถึงการเปลี่ยนแปลงทุกครั้งที่เกิดขึ้น

5. แยกรหัสออกจากข้อมูล นี่เป็นหนึ่งในแนวคิดที่ยากต่อการเรียนรู้ ค่า Hardcoding เช่น Monitoring Hosts ในโค้ดโมดูลของคุณไม่ดี วางไว้ในแหล่งข้อมูล (db, yaml (Hiera ใช้สิ่งนี้เป็นค่าเริ่มต้น), csv, อะไรก็ตาม) ที่โมดูลของคุณสามารถใช้งานได้ดี ตัวอย่างคือเว็บแอปที่ใช้ Mysql สิ่งนี้ทำให้ความสามารถในการส่งรหัสและข้อมูลแยกจากกัน ทำให้กระบวนการพัฒนาของคุณง่ายขึ้น

... หรือคุณสามารถเทมเพลตไฟล์การตั้งค่าของคุณด้วยตัวแปรเชลล์แม้แต่แบ็คโค๊ต (ตัวอย่างls -1 ...) และเขียนเชลล์สคริปซึ่งใช้ AWK เพื่อเรียก eval (1) และขยายตัวแปรทั้งหมดในเทมเพลต parser ที่เชลล์มีอยู่แล้ว ทำไมต้องทำให้มันซับซ้อนเมื่อมันง่ายจริง ๆ จริง ๆ ? คุณจะเก็บค่าการตั้งค่าไว้ที่ไหน ทำไมทุกที่ที่คุณโปรดเช่นตัวอย่างเช่น pkginfo (4) ไฟล์หรือฐานข้อมูลเช่น Oracle หรือสวยมากทุกที่ ไม่จำเป็นต้องใช้โซลูชั่น ultracomplex ไลบรารี่ที่ฉันพูดถึงข้างต้นนั้นอาจจะมาจากส่วน preinstall หรือ postinstall ในแพ็คเกจระบบปฏิบัติการซึ่งจะเป็นการลบการทำซ้ำและใช้ประโยชน์จากรหัสกลาง ...

แต่เหนือสิ่งอื่นใดผมพบว่าคำพูดดังกล่าวข้างต้นเป็นตัวอย่างของรุ่นต่อไปของผู้ดูแลระบบต้องสอนไม่ได้โดยผู้ดูแลระบบ แต่โดยวิศวกรระบบ พบว่าตัวเองเป็นสีเทาและลงนามในฐานะผู้ฝึกงาน


1
คุณดูเหมือนจะลืมคำตอบสำหรับคำถามผู้แต่ง
M. Glatki

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