เหตุใดผู้คนจึงใช้ Puppet / Chef กับ Amazon Cloud Formation แทนที่จะใช้ CloudInit เพียงอย่างเดียว

เรากำลังวางแผนที่จะใช้อินสแตนซ์ AMI EC2 ซึ่งไม่ใช่ "การอบล่วงหน้า" กล่าวคือเมื่อมีการหมุนพวกเขาจะติดตั้ง AWS linux เพียงเล็กน้อย กระบวนการบูตของเราจะดึงการติดตั้งต่างๆที่เราต้องการเช่น python, tomcat เราจะมีอย่างน้อย 3 อินสแตนซ์และสูงสุด 8

ด้วยข้อกำหนดเหล่านี้การใช้ Puppet / Chef จะมีประโยชน์มากกว่าการใช้ Amazon Cloud Formation (CloudInit) หรือไม่

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

มีใครย้ายจาก CloudInit ไปเป็น Puppet หรือ Chef ด้วยเหตุผลเฉพาะที่พวกเขาสามารถตอบคำถามของฉันได้ที่นี่?

มีข้อได้เปรียบเหนือ CloudInit หรือไม่? ใช่แน่นอนหลายคน!

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

CloudInit ไม่ใช่การจัดการการกำหนดค่า หากคุณเลือกที่จะเริ่มใช้ซอฟต์แวร์การจัดการการกำหนดค่าให้ใช้ cloud init สำหรับงานเดียว: เพื่อบู๊ตกับ Puppet / Chef / agent อื่น ๆ

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

เมื่อแอปพลิเคชันของคุณเปลี่ยนไปและคุณเริ่มใช้เช่น RabbitMQ หรือ Jetty หรือ RDBMS ใหม่คุณสามารถทดสอบและปรับใช้การเปลี่ยนแปลงในเซิร์ฟเวอร์นับหมื่นหรือหลายพันเครื่องได้อย่างง่ายดาย

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

จุดสำคัญทั้งหมดของการจัดการการกำหนดค่าคือการหมุนเครื่องจักรอย่างคาดเดาได้และสม่ำเสมอ CloudFormation และ cloudinit นั้นยอดเยี่ยมเมื่อคุณ จำกัด เฉพาะ AWS เท่านั้น (แม้ว่าการดีบักเทมเพลต CloudFormation จะเป็นประสบการณ์ที่น่าสังเวช ) แต่แอปพลิเคชันที่ใช้ทั้งทรัพยากรดาต้าเซ็นเตอร์และ AWS หรือสภาพแวดล้อมการทดสอบในพื้นที่หรือเครื่องพัฒนาล่ะ

หากคุณมีอยู่ใน AWS อย่างหมดจดฉันคิดว่าคุณสามารถใช้ cloudinit และไม่มีอะไรอื่นได้ แต่ฉันไม่มั่นใจว่าจะเป็นจริงสำหรับแอปพลิเคชันทุกขนาด (ตัวอย่างเช่น Netflix เตรียม AMI ไว้ล่วงหน้าโดยใช้เทคโนโลยี OSS ที่พวกเขาเขียนขึ้น และเผยแพร่สู่สายตาชาวโลกพิจารณารายละเอียดจากวิดีโอนี้ ) แอปพลิเคชันที่มีความพร้อมใช้งานสูงนั้นเป็นแบบข้ามภูมิภาคซึ่งมักใช้ VPCs มีแนวโน้มที่จะสำรองข้อมูลไปยังศูนย์ข้อมูลใน VPN และสิ่งนี้ไม่ได้สัมผัสกับสภาพแวดล้อมการสาธิตการจัดเตรียมการทดสอบหรือการพัฒนา ในฐานะคนที่ต้องรับผิดชอบเรื่องการจัดเตรียมเครื่องสุดท้ายสิ่งที่ฉันต้องการทำคือทำงานซ้ำหรือติดขัดในการแก้ไขข้อบกพร่องหลายวิธี

ดังนั้นเชฟหรือหุ่น พวกเขาทำงานได้ดีสำหรับ AWS เช่นเดียวกับที่ทำกับศูนย์ข้อมูลของฉันและเช่นกันสำหรับเครื่องพัฒนาของฉันที่ใช้Vagrantเช่นเดียวกับที่ใช้กับสภาพแวดล้อมการสาธิตที่ฉันต้องการในบางครั้ง ฉันอยากจะเปิดตัว Chef หรือ Puppet จาก cloudinit มากกว่าดูแลทั้ง cloudinit และ Chef หรือ Puppet

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

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

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

เมื่อถึงจุดนั้นคุณสามารถหยุดหรือหาเครื่องมืออื่น ๆ (เช่น Chef หรือ Puppet) ที่จะช่วยให้คุณบรรลุเป้าหมายที่ซับซ้อนมากขึ้นรวมทั้งทำสิ่งที่ง่ายขึ้น

ทางเลือกของคุณ.