ข้อดีและข้อเสียของ AWS Elastic Beanstalk เมื่อเปรียบเทียบกับกลยุทธ์การปรับใช้อื่น ๆ คืออะไร

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

เป้าหมายของเรา

• ปรับใช้ง่ายสุด (เราต้องการกดปุ่มเพื่ออัปเดตการผลิต)
• ปรับใช้อัตโนมัติเพื่อทดสอบสภาพแวดล้อม (ใช้ Jenkins)
• บำรุงรักษาง่าย (เรามีแอพที่เขียนไม่ต้องการใช้เวลาเล่นซอกับปัญหาการผลิต)
• ความสามารถในการจัดการสถาปัตยกรรมที่มุ่งเน้นบริการ (แอพขนาดเล็กจำนวนมากภาษาต่างๆและที่เก็บข้อมูล)
• มีความยืดหยุ่นเพียงพอที่จะทำให้แน่ใจว่าเราจะไม่ต้องเปลี่ยนกลยุทธ์เมื่อใดก็ตามในไม่ช้า (เรากำลังพยายามหนีจาก RightScale ไปแล้ว)

เราตกลงกับการตั้งค่าเริ่มต้นอีกเล็กน้อยถ้าทำเช่นนั้นจะช่วยให้เราปวดหัวในอนาคต

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

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

ฉันได้ดูและสร้างสภาพแวดล้อมการทดสอบด้วยไฟล์ WAR และฐานข้อมูล RDS ที่แนบมา สิ่งต่าง ๆ ดูเหมือนจะใช้งานได้และฉันเชื่อว่าเราสามารถปรับใช้สภาพแวดล้อมการทดสอบโดยใช้ Jenkins ผ่าน AWS API ได้โดยอัตโนมัติ ดูเหมือนง่ายพอ ... อาจจะง่ายเกินไป

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

คุณใช้ Elastic Beanstalk หรือไม่? ถ้าเป็นเช่นนั้นทำไมและปัจจัยอะไรนำไปสู่การตัดสินใจนั้น คุณชอบและไม่ชอบอะไร

หากคุณไม่ได้ใช้ Elastic Beanstalk แต่พิจารณาแล้วคุณจะใช้อะไรและทำไมคุณถึงไม่ใช้ Elastic Beanstalk

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

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

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

ปัญหาที่ฉันพบเมื่อใช้งานแอปพลิเคชันของฉัน:

• การปรับใช้ตาม Git - ฉันรักพวกเขา แต่ repo ของเราคือ 1+ GB ค่อนข้างใหญ่ในการผลักดันเป็นประจำ ธุรกรรมซื้อคืนนี้มีแอปพลิเคชั่นประมาณ 40 รายการ (ซึ่งควรจะแยกจริงๆ) แต่อาจใช้เวลาสักครู่ การอัปโหลดแพ็คเกจประเภทใดก็ได้สามารถใช้งานได้ แต่แอปพลิเคชันส่วนใหญ่ของเราจะใช้งานจำนวนมากเพื่อทำให้เป็นแพคเกจ

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

ในการประเมินของฉันฉันยังรวม OpsWorks และ CloudFormation OpsWorks มีปัญหาการรวมที่คล้ายกันกับวิธีการทำงานอัตโนมัติที่มีอยู่สำหรับแอปพลิเคชันเหล่านี้ CloudFormation ไม่ได้ทำอะไรมากไปกว่าสิ่งที่สคริปต์ Python และ Chef บางคนดูแลเราอยู่แล้ว

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

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

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

ฉันเห็นจุดสูญเสียการควบคุม แต่ฉันไม่เห็นความไร้สัญชาติที่ได้รับคำสั่ง eb ทั้งหมดทำจริงๆคือปรับใช้ระบบอัตโนมัติซึ่งเป็นวิธีที่ยอดเยี่ยม ฉันเห็นจุดเก็บข้อมูลขนาดใหญ่ ฉันคิดว่าโดยทั่วไปแล้วการแยกฟังก์ชั่นแอปแบบลอจิคัลออกเป็นแอพ beans แยกต่างหากจากนั้นก็มีสภาพแวดล้อม "การจัดเตรียม" และ "แยง" ใต้ดีมาก เรามีสภาพแวดล้อมโมดูลเช่นอัพโหลดไม่ได้ทำอะไรมากและในทางทฤษฎีมันเพิ่มค่าใช้จ่ายจำนวนมาก แต่จากนั้นคุณใช้อินสแตนซ์ขนาดเล็กมากขึ้น เราเรียกใช้ nginx แบบรวมศูนย์และต้องเขียนข้อความจัดการ sns ที่กำหนดเองจำนวนมากเพื่อแจ้งให้ ngnix ทราบถึงการเปลี่ยนแปลงในนโยบายมาตราส่วนอัตโนมัติ ปัญหาใหญ่อื่น ๆ ของ eb คือการไม่สามารถโหลดยอดคงเหลือได้เนื่องจากเราใช้ ngnix ทำไม elb ไม่สนับสนุน websocket