Автоматическое применение обновлений безопасности для AWS Elastic Beanstalk

Я был поклонником Heroku с самых ранних дней. Но мне нравится тот факт, что AWS Elastic Beanstalk дает вам больше контроля над характеристиками экземпляров. В Heroku мне нравится то, что я могу развернуть приложение и не беспокоиться об управлении им. Я предполагаю, что Heroku обеспечивает своевременное применение всех обновлений безопасности ОС. Мне просто нужно убедиться, что мое приложение безопасно.

Мои первоначальные исследования Beanstalk показывают, что, хотя он создает и настраивает экземпляры для вас, после этого он переходит к более ручному процессу управления. Обновления безопасности не будут автоматически применяться к экземплярам. Кажется, есть две проблемы:

• Новые выпуски AMI. По мере появления новых выпусков AMI, мы хотели бы использовать самые последние версии (предположительно, наиболее безопасные). Но мои исследования показывают, что вам нужно вручную запустить новую настройку, чтобы увидеть последнюю версию AMI, а затем создать новую среду для использования этой новой версии . Есть ли лучший автоматизированный способ превращения ваших экземпляров в новые релизы AMI?
• Между выпусками будут выпущены обновления безопасности для пакетов. Кажется, мы хотим обновить и их. Мое исследование показывает, что люди устанавливают команды для периодического запуска обновления yum, Но поскольку новые экземпляры создаются / уничтожаются в зависимости от использования, кажется, что новые экземпляры не всегда будут иметь обновления (то есть время между созданием экземпляра и первым обновлением yum). Так что иногда у вас будут экземпляры, которые не исправлены. И у вас также будут постоянно обновляться экземпляры, пока не будет применен новый выпуск AMI. Моя другая проблема заключается в том, что, возможно, эти обновления безопасности не прошли собственную рецензию Amazon (как это делают релизы AMI), и это может привести к поломке моего приложения для их автоматического обновления. Я знаю, что у Dreamhost однажды произошел сбой на 12 часов, потому что они применяли обновления Debian полностью автоматически без какого-либо рассмотрения. Я хочу убедиться, что то же самое не случится со мной.

Поэтому мой вопрос заключается в том, предлагает ли Amazon способ предложить полностью управляемый PaaS, такой как Heroku? Или AWS Elastic Beanstalk - это больше, чем просто сценарий установки, и после этого вы работаете самостоятельно (кроме инструментов мониторинга и развертывания, которые они предоставляют)?

Прежде всего, чтобы быть ясным, ни один эластичный бобовый стебель не является PaaS, как вы думаете об этом. Если вы разбиваете его на части, это действительно больше похоже на виртуальные шаблоны экземпляров и автоматизацию развертывания приложений, таких как puppet или chef. Наряду с этим вы получаете автоматический доступ к сервису балансировки нагрузки awe и наблюдение за облаком, что позволяет запускать новые серверы приложений или отключать существующие на основе метрик.

Похоже на то, что PaaS - это то, что основным преимуществом является система развертывания приложений, которая берет ваш код и копирует его на все серверы приложений в вашем кластере.

Одна из жалоб, которые есть у некоторых людей в отношении PaaS, заключается в том, что поставщик PaaS принимает решения о среде приложения. Это кажется мне ценным предложением PaaS: как клиент, вы концентрируетесь на функциональности приложения и оставляете все остальные детали поставщику PaaS. Вы платите за кого-то другого, чтобы управлять инфраструктурой и обеспечивать системное администрирование. За эту простоту вы платите им премию, как в случае с Heroku, которая также управляет своей инфраструктурой поверх ec2, только прозрачным для вас способом.

Amazon действительно предлагает Elastic Beanstalk поверх Ec2 и их REST API, и не прилагает особых усилий, чтобы скрыть это от вас. Это потому, что они зарабатывают деньги через IaaS, а EB просто организует настройку группы ресурсов ec2, которую вы можете настроить самостоятельно, учитывая время и ноу-хау.

Теперь, с точки зрения специфики AMI, снова AMI являются одной из многих частей ec2, которые используются для облегчения EB. В EB AMI нет ничего волшебного - это просто Amazon linux ami, предварительно настроенный для работы с EB. Как и любой другой AMI, вы можете запустить его в EC2, настроить его и получить новый настроенный AMI из вашего запущенного экземпляра. Amazon Linux - это нечто среднее между Centos и Fedora, с патчами паравиртуализации и предварительно настроенными репозиториями yum, поддерживаемыми Amazon.

Как вы, вероятно, знаете, Amazon Linux уже настроен для установки исправлений безопасности во время загрузки. Однако работающие экземпляры ничем не отличаются от любого другого сервера в отношении исправлений. Исправление может прервать обслуживание. Если вы крайне обеспокоены исправлениями безопасности, вы всегда можете использовать команду контейнера и установить cron для запуска yum update --security с некоторой периодичностью.

Вы также можете использовать EB API для изменения конфигурации EB или автоматизировать создание новой среды EB, затем вы можете переключиться на нее, как только она будет готова, и завершить работу старой. Это описано здесь: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

Как и в остальной части AWS, есть программный доступ к каждой функции, отличной от SaaS, и управление ею, так что ничто не мешает вам создавать исправленные AMI, которые затем используются для создания новых сред EB, и развертывания. EB не собирается навязывать вам особенности конфигурации, а также не предоставляет вам группу системного администрирования для поддержки инфраструктуры.

По состоянию на апрель 2016 года Elastic Beanstalk поддерживает автоматическое обновление платформы:

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

Все приложения и среды Beanstalk можно настроить с помощью файлов EBEXTENSIONS, которые упакованы вместе с пакетом развертывания вашего приложения (например, WAR-файл для приложений Java) с конфигурацией на основе YAML для обновления или перенастройки любой части вашего приложения, контейнера, ОС и т. Д. Beanstalk - это PaaS, поскольку это платформа, которая позволяет развертывать приложения, не беспокоясь о базовом IaaS. Все поставщики PaaS в конце дня запутывают базовый IaaS с помощью некоторой формы автоматизации. Однако поскольку речь идет о компьютерных науках, мы не можем сказать, что не существует единого оптимального состояния для всех приложений, и без возможности настройки IaaS под PaaS вы зависите от поставщика услуг PaaS, чтобы обеспечить бесперебойную работу ваших приложений. быстро и надежно.

Heroku работает поверх AWS, используя другой уровень управления, вот и все. Однако это становится болью в заднице, когда вам приходится делать такие вещи, как защита вашего приложения. Несмотря на то, что они прилагают все усилия для эффективного управления своим решением и обеспечения безопасности и т. Д., Они не могут и не будут брать на себя риск и последствия уязвимости в вашем приложении в конце дня. Они хотят сделать свои услуги максимально возможными.

Способность настроить IaaS, лежащую в основе платформы, является сильной стороной и привлекательностью Beanstalk IMO.