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

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

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

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

По мнению 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, были созданы специально для решения подобных задач.