Подходит ли Elastic Beanstalk для компакт-дисков корпоративного уровня?


11

Я работаю с проектом, который использует Jenkins для создания и развертывания микросервисов в Elastic Beanstalk. Мы разворачиваем ветвь интеграции в тестовой среде, выпускаем ветки в промежуточную среду, а затем производим окончательную сборку. У меня есть пара проблем с этим: во-первых, это означает, что мы получаем матрицу по одной сборке на проект на среду, дублирующую усилия; и во-вторых, это означает, что мы не внедряем в производство те же артефакты сборки, которые были проверены при подготовке.

Я склонен отказаться от Beanstalk и перейти к обычным ASG, используя что-то вроде Chef для развертываний. В результате у нас останется одна сборка на проект, создающий артефакт сборки, и мы сможем развернуть тот же артефакт для производства, который был одобрен при постановке. Однако переход имеет немалые первоначальные затраты. Есть ли способ лучше использовать Beanstalk, который позволил бы создать более надежный и простой в управлении CI / CD?

Примечание : продвижение того же артефакта сборки - это именно то, что я хочу сделать, но из документов я не вижу четкого способа сделать это; в нем объясняется, как выполнить развертывание в EB из источника приложения, а не как продвигать существующую версию в другую среду, если только мне не удалось прокрутить ее сразу. Если он доступен в самом EB, возможно, в плагине развертывания Jenkins EB есть ограничение, которое не позволяет делать это специально в Jenkins, но я вообще не видел способа сделать это.


Это ваша среда Jenkins, которая представляет собой единую сборку на ограничение среды? Я использую Elastic Beanstalk для развертывания приложений, и загруженные артефакты приложений могут быть легко развернуты (развернуты) в нескольких средах. Поэтому я не вижу ограничений, которые вы описываете. Похоже , там может быть , как вы можете использовать Elastic Beanstalk делать то , что вы хотите. Но этот вопрос достаточно широк, как он сейчас стоит.
Энди Шинн

Почему вы перестраиваете свои активы вместо того, чтобы продвигать тот же актив в другие среды после тестирования?
Евгений

Ответы:


4

По мнению IMO, ваша проблема не в Elastic Beanstalk в этом сценарии, а в Дженкинсе или, по крайней мере, в том, как вы его используете. Вы действительно должны сосредоточиться на создании «вещи» только один раз, независимо от того, что это за вещь.

Полное раскрытие: я работаю на ThoughtWorks и невероятно предвзято отношусь к GoCD. Я постараюсь объяснить, что я имею в виду, так нейтрально, как я могу. Я буду использовать документы нашего инструмента в качестве примеров, но, надеюсь, люди смогут экстраполировать их системы.

Где-то в начале вашего конвейера вы создаете «артефакты». Это могут быть двоичные файлы, представляющие все или часть вашего приложения, или они могут быть выведены из любого количества инструментов, таких как инструменты тестирования. Эти артефакты должны храниться системой и никогда не создаваться заново. Затем система должна получить артефакт из соответствующей ревизии, когда это необходимо.

Например...

  1. Я создаю файл .jar и запускаю на нем несколько модульных тестов, базовых C / I. Если он проходит, этот файл .jar и выходные данные тестов загружаются в конкретное конвейерное задание .
  2. Следующим конвейером может стать развертывание в более сложной среде тестирования. Это должно принести точную флягу от точной работы, которая построила это. Затем он выполняет Elastic Beanstalk, чтобы развернуть эту банку в правильной среде.
  3. Следующий конвейер - ваше промежуточное развертывание. Он проходит весь путь назад к первому трубопроводу и извлекает точную баночку с точной работы , который построил его. В последующем executus Elastic Beanstalk для развертывания этой банки в правильной среде.

Это каждый отдельный конвейер, потому что это позволяет вам работать больше параллельно или по требованию без блокировки.

Вы можете использовать Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy или любое количество других инструментов для выполнения реальных развертываний. Это не то, откуда твоя проблема. Серверы непрерывной интеграции изначально не были созданы для этого. Конечно, есть много плагинов, которые вы можете использовать, чтобы попасть в одно и то же место, если вы этого хотите.

Серверы непрерывной доставки, такие как GoCD , Chef Automate и ConcourseCI, были созданы специально для решения подобных задач.


Да, моя цель - построить один раз и продвигать производство. Мой вопрос, подходит ли beanstalk для этого типа использования. Из того, что я могу сказать, на самом деле это не так; например, рекомендуемый метод развертывания приложения .NET - это делать это из Visual Studio, что является едва ли не худшей практикой, о которой я могу подумать.
Адриан,

Я не использовал его лично, но похоже, что было бы, если вы измените слово «продвигать» на «развернуть». Ваша система CD вызывает beanstalk для развертывания в тестировании, запускает некоторые тесты и затем сообщает об успехе / неудаче. Если это удастся, ваша система CD вызывает beanstalk для развертывания в стадии подготовки и т. Д. Итак, продвижение осуществляется вашим инструментом оркестровки, развертывание - вашим инструментом развертывания. (К вашему сведению, именно поэтому такие компании, как Chef, имеют Hibernate (вещь), Automate (продвигать вещь) и Chef (разверните вещь).
Кен Муградж,

К вашему сведению, похоже, вы могли бы написать это (инфраструктура как код - «хорошая вещь») docs.aws.amazon.com/elasticbeanstalk/latest/dg/… - но опять же, абсолютно нулевой личный опыт.
Кен Муграге,

Насколько я могу судить, какое бы слово вы ни использовали, бобовый стебель этого не делает. Похоже, что он ориентирован на развертывание из источника, а не из артефактов. На странице, на которую вы ссылаетесь: «Когда вы запускаете eb deploy, EB CLI связывает содержимое каталога вашего проекта и развертывает его в вашей среде». Я ценю ответ, но мой вопрос специфичен для
Адриан

Ах, извините за это. Я интерпретировал, ~/eb$ eb deploy Creating application version archive "app-150630_014338". Uploading elastic-beanstalk-example/app-150630_014338.zip to S3чтобы иметь в виду любой zip-файл, который вы застряли в этом каталоге. Удачи!
Кен Муграге
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.