ใช้การปรับปรุงความปลอดภัยอัตโนมัติสำหรับ AWS Elastic Beanstalk

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

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

• ใหม่การเปิดตัว AMI - เมื่อมีการเปิดตัว AMI ใหม่ดูเหมือนว่าเราต้องการเรียกใช้งานล่าสุด (น่าจะปลอดภัยที่สุด) แต่งานวิจัยของฉันดูเหมือนจะบ่งบอกว่าคุณต้องเปิดการตั้งค่าใหม่ด้วยตนเองเพื่อดูเวอร์ชัน AMI ล่าสุดจากนั้นสร้างสภาพแวดล้อมใหม่เพื่อใช้เวอร์ชันใหม่นั้น มีวิธีอัตโนมัติที่ดีกว่าในการหมุนอินสแตนซ์ของคุณไปเป็นรุ่น AMI ใหม่หรือไม่?
• ในระหว่างการเปิดตัวจะมีการอัพเดทความปลอดภัยสำหรับแพ็คเกจ ดูเหมือนว่าเราต้องการอัพเกรดสิ่งเหล่านั้นเช่นกัน ดูเหมือนว่างานวิจัยของฉันจะระบุว่าผู้ใช้ติดตั้งคำสั่งเพื่อเรียกใช้การปรับปรุงยำ. แต่เนื่องจากอินสแตนซ์ใหม่ถูกสร้าง / ทำลายตามการใช้งานดูเหมือนว่าอินสแตนซ์ใหม่จะไม่ได้รับการอัปเดตเสมอ (เช่นเวลาระหว่างการสร้างอินสแตนซ์และการอัปเดต yum ครั้งแรก) ดังนั้นบางครั้งคุณจะมีกรณีที่ไม่ได้รับการแก้ไข และคุณก็จะมีอินสแตนซ์ที่ปะต่อกันอยู่เรื่อย ๆ จนกว่าจะมีการใช้งาน AMI ใหม่ ข้อกังวลอื่น ๆ ของฉันคือบางทีการอัปเดตความปลอดภัยเหล่านี้อาจไม่ผ่านการตรวจสอบของ Amazon เอง (เช่นการเปิดตัว AMI) และอาจทำให้แอปของฉันอัปเดตโดยอัตโนมัติ ฉันรู้ว่า Dreamhost เคยมีปัญหา 12 ชั่วโมงเพราะพวกเขาใช้การอัพเดทเดเบียนโดยอัตโนมัติโดยไม่ต้องมีการรีวิวใด ๆ ฉันต้องการให้แน่ใจว่าสิ่งเดียวกันจะไม่เกิดขึ้นกับฉัน

ดังนั้นคำถามของฉันคือ Amazon ให้วิธีที่จะเสนอ PaaS ที่มีการจัดการอย่างเต็มที่เช่น Heroku หรือไม่? หรือ AWS Elastic Beanstalk เป็นเพียงสคริปต์การติดตั้งจริง ๆ และหลังจากนั้นคุณเป็นเจ้าของ (นอกเหนือจากเครื่องมือตรวจสอบและปรับใช้ที่มีให้)

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

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

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

อเมซอนกำลังนำเสนอ Elastic Beanstalk ที่อยู่ด้านบนของ Ec2 และ API REST ของพวกเขาและไม่ได้พยายามอย่างมากที่จะซ่อนสิ่งนั้นจากคุณ นี่เป็นเพราะพวกเขาทำเงินผ่าน IaaS และ EB เป็นเพียงการเตรียมการติดตั้งกลุ่มทรัพยากร ec2 ที่คุณสามารถตั้งค่าด้วยตัวเองให้เวลาและรู้วิธี

ตอนนี้ในแง่ของคุณสมบัติเฉพาะของ AMI อีกครั้ง AMI เป็นหนึ่งในชิ้นส่วน ec2 จำนวนมากที่ใช้เพื่ออำนวยความสะดวกให้กับ EB ไม่มีอะไรน่าอัศจรรย์เกี่ยวกับ EB AMI - เป็นเพียง Amazon linux ami ที่ตั้งค่าไว้ล่วงหน้าเพื่อทำงานกับ EB เช่นเดียวกับ AMI อื่น ๆ คุณสามารถเริ่มต้นได้ใน EC2 ปรับแต่งและรับ AMI ที่กำหนดเองใหม่จากอินสแตนซ์ที่คุณใช้งานอยู่ Amazon Linux นั้นเป็นจุดตัดระหว่าง Centos และ Fedora พร้อมกับแพทช์ paravirtualization และ repos yum ที่กำหนดไว้ล่วงหน้าโดย Amazon

อย่างที่คุณอาจทราบแล้ว Amazon linux ได้รับการกำหนดค่าให้ติดตั้งแพตช์ความปลอดภัยในเวลาบูตแล้ว อย่างไรก็ตามการใช้งานอินสแตนซ์นั้นไม่แตกต่างจากเซิร์ฟเวอร์อื่นใดที่เกี่ยวข้องกับการแพตช์ การปะแก้อาจขัดจังหวะบริการ หากคุณกังวลอย่างมากเกี่ยวกับการแก้ไขความปลอดภัยคุณสามารถใช้คำสั่ง container และ setup cron เพื่อรัน yum update - ความปลอดภัยในบางช่วงเวลา

คุณยังสามารถใช้ EB API เพื่อเปลี่ยนการกำหนดค่า EB หรือทำการสร้างสภาพแวดล้อม EB ใหม่โดยอัตโนมัติจากนั้นคุณสามารถสลับไปใช้งานได้ทันทีที่พร้อมและพร้อมตามด้วยการปิดเครื่องเก่า นี่คือคำอธิบายที่นี่: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

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

ณ เดือนเมษายน 2559 Elastic Beanstalk รองรับการอัปเดตแพลตฟอร์มอัตโนมัติ:

https://aws.amazon.com/about-aws/whats-new/2016/04/aws-elastic-beanstalk-introduces-managed-platform-updates/

แอ็พพลิเคชัน Beanstalk และสภาพแวดล้อมทั้งหมดสามารถกำหนดค่าผ่านไฟล์ EBEXTENSIONS ที่รวมอยู่ในแพ็คเกจการปรับใช้แอปพลิเคชันของคุณ (เช่นไฟล์ WAR สำหรับแอป Java) ด้วยการตั้งค่าที่ใช้ YAML เพื่ออัปเดตหรือกำหนดค่าส่วนใด ๆ PaaS เนื่องจากเป็นแพลตฟอร์มที่ช่วยให้คุณสามารถปรับใช้แอปพลิเคชันโดยไม่ต้องกังวลกับ IaaS พื้นฐาน ผู้ให้บริการ PaaS ทั้งหมดในตอนท้ายของวันทำให้งงงวย IaaS พื้นฐานผ่านรูปแบบของการทำงานอัตโนมัติบางอย่าง อย่างไรก็ตามเนื่องจากนี่คือวิทยาศาสตร์คอมพิวเตอร์เรากำลังพูดถึงว่าไม่มีรัฐที่เหมาะสมที่สุดสำหรับแอปพลิเคชันทั้งหมดและหากไม่มีความสามารถในการปรับแต่ง IaaS ภายใต้ PaaS คุณอยู่ในความเมตตาของผู้ให้บริการ PaaS เพื่อรับรองว่าแอพพลิเคชันของคุณทำงานได้อย่างราบรื่น รวดเร็วและปลอดภัย

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

ความสามารถในการปรับแต่ง IaaS ที่เป็นรากฐานของแพลตฟอร์มนั้นเป็นจุดแข็งและดึงดูดของ Beanstalk IMO