Які плюси і мінуси AWS Elastic Beanstalk порівняно з іншими стратегіями розгортання?

Я доволі новачок у цілому стеку Netflix OSS та розгортаннях взагалі. Як підґрунтя для мого нинішнього рівня знань, головна моя роль - це інженер додатків із додаткового інтерфейсу. Однак мені подобається операційна сторона речей, тому я намагаюся налаштувати нову стратегію розгортання та інструментарій для нового проекту.

Наші цілі

• Супер прості розгортання (ми хочемо натиснути кнопку, щоб оновити виробництво)
• Автоматизовані пристрої для тестування середовищ (за допомогою Дженкінса)
• Простота обслуговування (у нас є додаток для написання, не хочемо витрачати свій час на те, щоб поспілкуватися з виробничими проблемами)
• Можливість управління архітектурою, орієнтованою на сервіс (безліч невеликих додатків, різних мов та сховищ даних)
• Достатня гнучкість, щоб гарантувати, що незабаром нам не доведеться змінювати стратегії (ми вже намагаємося піти від RightScale)

Ми все в порядку з трохи більше початкового часу установки, якщо це врятує нас від головних болів у майбутньому.

Таким чином, я слухав подкасти, дивився розмови Ops і читав тони публікацій в блогах, і, виходячи з наших цілей і того, що я сприйняв як найкращі практики, ми почали формувати план, використовуючи Асгард, прокатуючи наш пакет в банку і згортаючи його в AMI.

Ми все це планували і подобалися переваги процесу порівняно з використанням сервера Chef та конвергування екземплярів на ходу (ми вважали, що це було помилкою, враховуючи нашу обмежену хронологію та нерозуміння навколо робочого процесу сервера Chef). Однак колега трохи озирнувся і відчув, що Еластична Бінсталька відповідає нашим потребам.

Я вивчив це і запустив тестове середовище з файлом WAR та доданою базою даних RDS. Начебто справи спрацьовують, і я вважаю, що ми можемо автоматизувати розгортання тестового середовища за допомогою Дженкінса за допомогою API AWS. Здається, досить просто ... можливо, занадто просто.

Мені цікаво, в чому улов? Якщо Elastic Beanstalk настільки простий і ефективний, то чому б про нього не говорилося більше? Мені важко знайти достатньо об'єктивних думок та фактів щодо двох різних стратегій розгортання, тому я подумав, що поцікавтесь.

Ви використовуєте Elastic Beanstalk? Якщо так, то чому і які фактори призводять до такого рішення? Що вам подобається і не подобається?

Якщо ви не використовуєте Elastic Beanstalk, але розглядали це, що ви використовуєте і чому ви не використовували Elastic Beanstalk?

Які переваги та недоліки має стратегія розгортання на основі Elastic Beanstalk для SOA? Тобто, чи буде Elastic Beanstalk добре працювати з багатьма невеликими додатками, які покладаються один на одного?

Я оцінював Elastic Beanstalk на додаток до інших пропозицій AWS, намагаючись покращити наші ручні екземпляри AWS. Причини, які я вирішив не використовувати, були через ускладнення, які можуть спричинити міграцію моєї існуючої заявки, а не через саму пропозицію. Проблема полягає в тому, що у вас не так багато контролю над розгортанням / налаштуванням серверів. Якщо ви запускаєте нову програму, то може бути корисним не розбиратися з цими речами прямо зараз, якщо у вас є вже наявна програма, то це більше завдання вписатись у модель Beanstalk.

Beanstalk надає аналогічну пропозицію для Heroku та інших постачальників PaaS, але не дуже корисна для тих, хто просто хоче зосередитись на тому, щоб зробити свою заявку. Ви хоч би хочете визначити віртуалізовані ресурси більшою мірою, ніж інші постачальники PaaS.

Проблеми, з якими я стикався з моїми додатками:

• Розгортання на основі Git - я їх люблю, але наша репо - 1 ГБ. Досить великі, щоб натискати на регулярній основі. Цей репо містить також близько 40 додатків (які дійсно слід розділити), але це потребує певного часу. Завантаження будь-якого типу пакету може спрацювати, але для більшості наших додатків потрібна велика робота, щоб перетворити його в пакет.

• Інтеграція з іншими сервісами - З того, що я бачив, Beanstalk передбачає, що все, до чого ви підключаєтесь, - це одна послуга. Це добре працює, якщо ваші служби позаду та ELB, але у нас були окремі вузли, на які ми потрапили через HAProxy, що працює на кожному сервері додатків. Якщо ви використовуєте свої сховища даних та інші послуги як єдину кінцеву точку, вам слід буде добре.

У свою оцінку я також включив OpsWorks та CloudFormation. OpsWorks має подібні проблеми інтеграції з тим, як існуюча автоматизація працювала для цих додатків. CloudFormation не набагато більше, ніж те, що деякі сценарії Python і шеф-кухар вже піклувались про нас.

Я вирішив замість того, щоб вибрати AWS групи автоматичного масштабування замість деякої автоматизації, яку надає Asgard . Це було найменшою зміною існуючого коду конфігурації / програми та надало нам переваги, які ми шукали, просте управління декількома серверами, доступними через API AWS.

Обмеження, встановлені Elastic Beanstalk щодо вашої заявки, дуже корисні. Вам доведеться переконатися, що ваша заявка здебільшого без громадянства, забезпечує кінцеву точку послуги та покладається на інші служби для держави. Якщо ви намагаєтеся зробити автономні сервіси для багаторазового використання, то кілька додатків у Beanstalk - це чудовий початок.

Якщо / коли ви досягнете необхідності отримати додаткову конфігурацію, OpsWorks - це чудовий наступний крок. Заздалегідь визначені ролі повинні зробити перехід легким для початку, і він забезпечує структуру автоматизації навколо шеф-кухаря, щоб допомогти координувати надання декількох серверів.

Я бачу сенс втрати контролю, але я не обов'язково бачу обов'язкове безгромадянство. Все, що насправді робить eb - це автоматизація розгортання, яка, до речі, є приголомшливою. Я бачу сенс великого сховища. Я взагалі думаю, що розділяти функції логічних додатків на окремі додатки для бобів, а потім мати "інсценізацію" та "прод" серед них справді приємно. У нас є модульні середовища, такі як завантажувач, це робить не дуже багато і теоретично це додає великих витрат, але тоді ви використовуєте менші екземпляри лише більше. Ми запускаємо централізований nginx і мусимо писати багато спеціальних ручок повідомлень sns, щоб повідомляти ngnix про зміни в політиці автоматичного масштабування. Ще одна велика проблема eb - неможливість зняти баланс завантаження, оскільки ми використовуємо ngnix, чому? elb не підтримує веб-розетку.