รุ่นเซิร์ฟเวอร์ที่ไม่น่าไว้วางใจที่มี Docker / Ansible vs. Ansible, Puppet และ Foreman ใน AWS?


9

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

1) ด้านหนึ่ง (ของฉัน - ฉันไม่ไร้อคติ) พบว่ารูปแบบเซิร์ฟเวอร์ที่ไม่เปลี่ยนรูปแบบน่าสนใจมากสำหรับระบบคลาวด์ ด้วยเหตุนี้เราจึงทำการย้ายต้นแบบส่วนประกอบทั้งหมดของโครงสร้างพื้นฐานของเราไปยัง Docker แอปพลิเคชันที่กำหนดเองของเราสร้างขึ้นผ่าน Jenkins โดยตรงในอิมเมจ Docker ที่ปรับใช้กับ Docker Registry ในพื้นที่ จากนั้นเราสร้างบทบาท Ansible จำนวนมากและ playbook ที่สามารถเข้าถึงเซิร์ฟเวอร์เปล่าติดตั้ง Docker แล้วบอก Docker ให้ติดตั้งคอนเทนเนอร์ทั้งหมดตามต้องการ หลังจากผ่านไปสองสามนาทีแอปทั้งหมดและโครงสร้างพื้นฐานที่รองรับทั้งหมดจะเชื่อมต่อและทำงาน - การบันทึกการตรวจสอบการสร้างฐานข้อมูล / ประชากร ฯลฯ เครื่องที่เสร็จแล้วเป็นสภาพแวดล้อมแบบ QA หรือ dev ที่มีอยู่ในตัวเองพร้อมสำเนาที่แน่นอนของ ใบสมัคร แผนของเราในการขยายขนาดนี้คือการสร้าง Playbooks ใหม่เพื่อสร้างเซิร์ฟเวอร์ AWS ใหม่จากฐานที่เชื่อถือได้ของ AMI (อาจเป็นภาพที่เปลือยเปล่า) ทำการปรับใช้แอพพลิเคชั่นการผลิตเพื่อจัดการการจัดการการกำหนดค่าและเผยแพร่ เพียงแค่ทำให้พวกเขาใหม่ ฉันไม่ได้กังวลเกี่ยวกับการได้รับสิ่งที่ฉันอธิบายการทำงานในทางปฏิบัติ - ถ้าเป็นแบบอย่างที่สมเหตุสมผล

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

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

หรือรูปแบบเซิร์ฟเวอร์ที่ไม่เปลี่ยนรูปแบบล้มเหลวในทางปฏิบัติหรือไม่ เรามีประสบการณ์ที่ดีกับทั้ง AWS และสภาพแวดล้อมคลาวด์ดังนั้นจึงไม่ใช่เรื่องที่น่าเป็นห่วง - เป็นเรื่องของการได้รับแอพที่มีความซับซ้อนพอสมควร นี่เป็นเรื่องที่น่าสนใจเป็นพิเศษเมื่อเราปล่อยค่อนข้างบ่อย

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

ความคิด / ความคิดเห็นหรือข้อเสนอแนะเกี่ยวกับวิธีการจะได้รับการชื่นชมอย่างมาก!


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

หุ่นกระบอกและตัวต่อ? คุณจะมีช่วงเวลาที่ไม่ดี
dmourati

นักเทียบท่าเปิดความเป็นไปได้ของการใช้ kubernetes ซึ่งหมายถึง autoscaling, self-healing และอื่น ๆ ฟิลด์ Container กำลังเติบโตในขณะนี้และเป็นตัวเลือกที่ดีมากหากแอปของคุณสามารถปรับใช้ microservice กระบวนทัศน์ได้
Droopy4096

คำตอบ:


1

ใน บริษัท ของเราเราประสบความสำเร็จในการนำ Puppet ไปใช้กับโครงสร้างพื้นฐานดั้งเดิมของลูกค้า นอกจากนี้เรายังใช้คอนเทนเนอร์ Docker เพื่อเรียกใช้บริการเฉพาะ (ซึ่งอันที่จริงแล้วแอปพลิเคชันเก่าที่ถูกตัดและบิดเพื่อให้พอดีกับคอนเทนเนอร์)
ฉันไม่ได้มีความสุขกับคอนเทนเนอร์ในครั้งแรกที่ฉันจ้องทำงานกับพวกเขา (ใช่ ... แอป 30kb กลายเป็นภาพหนัก 200MB) แต่เมื่อฉันต้องสร้างสภาพแวดล้อมใหม่ทั้งหมดหลังจากเกิดภัยพิบัติขนาดเล็กฉันเปลี่ยนใจ ฉันคิดว่า Docker นั้นถูกคิดค้นขึ้นมาเพื่อสิ่งนี้: การติดตั้งที่รวดเร็วและบ่อยครั้งโดยไม่ต้องกังวลเกี่ยวกับการกำหนดค่าเซิร์ฟเวอร์ หากคุณออกแบบภาชนะบรรจุอย่างถูกต้องคุณสามารถสลับไปมาระหว่างผู้ให้บริการคลาวด์แล็ปท็อปนักพัฒนาและศูนย์ข้อมูล colocation ได้อย่างง่ายดาย เพราะสิ่งที่คุณต้องการก็คือกล่องวานิลลาลินุกซ์ที่มี Docker daemon

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

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


0

นี่คือ 2 ยูโรของฉัน

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

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

โชคดี!

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