Я новичок во всем стеке Netflix OSS и развертываниях в целом. Исходя из моего нынешнего уровня знаний, моя основная роль заключается в разработке интерфейсных приложений. Однако мне нравится операционная сторона вещей, поэтому я пытаюсь настроить новую стратегию развертывания и инструменты для нового проекта.
Наши цели
Мы согласны с немного большим количеством времени на первоначальную настройку, если это избавит нас от головной боли в будущем.
Итак, в соответствии с этим, я слушал подкасты, смотрел выступления Ops и читал тонны сообщений в блогах, и исходя из наших целей и того, что я принял за некоторые передовые практики, мы начали формировать план, используя Асгард, свертывая наш пакет в банку и скатывая ее в AMI.
Мы все это спланировали, и нам нравятся преимущества этого процесса по сравнению с использованием сервера Chef и конвергентных экземпляров на лету (мы чувствовали, что это было подвержено ошибкам, учитывая наши ограниченные сроки и отсутствие понимания рабочего процесса сервера Chef). Тем не менее, коллега сам немного осмотрелся и почувствовал, что Elastic Beanstalk отвечает нашим потребностям.
Я изучил это и создал тестовую среду с файлом WAR и присоединенной базой данных RDS. Кажется, все работает, и я считаю, что мы можем автоматизировать развертывание в тестовой среде с помощью Jenkins через API AWS. Кажется достаточно простым ... возможно, слишком простым.
Мне интересно, в чем подвох? Если Elastic Beanstalk настолько прост и эффективен, почему о нем не говорят больше? Мне сложно найти достаточно объективных мнений и фактов о двух разных стратегиях развертывания, поэтому я подумал, что поспрашиваю.
Вы используете эластичный бобовый стебель? Если да, то почему и какие факторы привели к такому решению? Что тебе нравится и не нравится?
Если вы не используете Elastic Beanstalk, но учли его, что вы используете и почему не использовали Elastic Beanstalk?
Каковы преимущества и недостатки стратегии развертывания SOA на основе эластичного бобового стебля? То есть будет ли Elastic Beanstalk хорошо работать со многими небольшими приложениями, работа которых зависит друг от друга?
Я оценил Elastic Beanstalk в дополнение к другим предложениям AWS, пытаясь улучшить наши созданные вручную экземпляры AWS. Причины, по которым я решил не использовать его, были связаны с осложнениями, которые возникнут при переносе моего существующего приложения, а не с самим предложением. Загвоздка в том, что у вас не так много контроля над развертыванием / настройкой приложений на серверах. Если вы запускаете новое приложение, может быть полезно не заниматься этими вещами прямо сейчас, если у вас есть существующее приложение, то более сложно вписаться в модель бобового стебля.
Beanstalk предоставляет аналогичное предложение для Heroku и других поставщиков PaaS, но не дает большого преимущества тем, кто просто хочет сосредоточиться на создании своего приложения. По крайней мере, вы можете определять виртуализированные ресурсы в большей степени, чем другие поставщики PaaS.
Проблемы, с которыми я столкнулся с моим приложением (ями):
Развертывания на основе Git - мне они нравятся, но наше репо составляет 1+ ГБ. Достаточно большой, чтобы нажимать на него регулярно. Это репо также содержит около 40 приложений (которые действительно следует разделить), но это займет некоторое время. Загрузка любого пакета может работать, но большинство наших приложений потребует большого объема работы, чтобы превратить его в пакет.
Интеграция с другими службами. Судя по тому, что я видел, Beanstalk вроде бы предполагает, что все, к чему вы подключаетесь, является одной службой. Это хорошо работает, если ваши сервисы отстают и ELB, но наши были отдельными узлами, которые мы задействовали через HAProxy, запущенный на каждом сервере приложений. Если вы используете свои хранилища данных и другие службы как единую конечную точку, все будет в порядке.
В свою оценку я также включил OpsWorks и CloudFormation. У OpsWorks проблемы интеграции схожи с тем, как существующая автоматизация работала для этих приложений. CloudFormation не сделала ничего, кроме того, о чем уже позаботились некоторые сценарии Python и Chef.
В итоге я решил использовать AWS Autoscaling Groups вместо этого с некоторой автоматизацией, обеспечиваемой Асгард. Это было наименьшее изменение существующей конфигурации / кода приложения, которое дало нам те преимущества, которые мы искали, а именно простое управление несколькими серверами, доступными через API AWS.
Ограничения, наложенные Elastic Beanstalk на ваше приложение, очень полезны. Вам нужно будет убедиться, что ваше приложение в основном не имеет состояния, предоставляет конечную точку для службы и полагается на другие службы для определения состояния. Если вы пытаетесь создать автономные службы многократного использования, использование нескольких приложений в Beanstalk станет отличным началом.
Если / когда вы дойдете до точки, требующей дополнительных настроек, OpsWorks - отличный следующий шаг. Предопределенные роли должны облегчить начало перехода, и они обеспечивают среду автоматизации вокруг Chef, чтобы помочь координировать предоставление нескольких серверов.
Я действительно вижу смысл потери контроля, но я не обязательно вижу обязательное безгражданство. Все, что eb действительно делает, - это автоматизация развертывания, что, кстати, потрясающе. Я вижу смысл в большом репозитории. Я думаю, что в целом разделение функций логических приложений на отдельные приложения beans, а затем наличие «промежуточной» и «производственной» среды под ними - это действительно хорошо. У нас есть среды модулей, такие как загрузчик, он не очень много работает и теоретически добавляет много затрат, но тогда вы используете меньшие экземпляры, а просто больше. Мы запустили централизованный nginx, и нам пришлось написать множество пользовательских дескрипторов sns-сообщений, чтобы уведомлять ngnix об изменениях в политике автоматического масштабирования. Еще одна большая проблема с eb - невозможность отключить балансировку нагрузки, раз уж мы используем ngnix, почему? elb не поддерживает веб-сокет.