Непрерывная интеграция в AWS EMR

У нас есть давно работающий кластер EMR, на котором установлено несколько библиотек с использованием действий начальной загрузки. Некоторые из этих библиотек находятся в стадии непрерывной разработки, а их кодовая база находится на GitHub.

Я пытался подключить Travis CI к AWS EMR аналогично Travis и CodeDeploy. Идея состоит в том, чтобы протестировать код на GitHub и автоматически развернуть его в EMR, используя действия начальной загрузки для установки обновленных библиотек на всех узлах EMR.

Решение, которое я придумал, состоит в том, чтобы использовать инстанс EC2 посередине, где Travis и CodeDeploy можно сначала использовать для развертывания кода на инстансе. После этого на экземпляре запускается сценарий обеда для создания нового кластера EMR с обновленными библиотеками.

Однако приведенное выше решение означает, что нам нужно создавать новый кластер EMR каждый раз, когда мы развертываем новую версию системы.

Любые другие предложения?


amazon-web-services amazon-emr aws-code-deploy travis-ci
person Stan    schedule 28.12.2017    source источник
comment
Хороший вопрос. Мы столкнулись с похожей проблемой, и в итоге мы сделали что-то очень похожее на предложенное вами решение. С нашей системой непрерывной интеграции код развертывается на одном хосте, а затем ежедневный cron создает новый кластер каждый день. Это ограничивает нашу скорость развертывания до одного раза в день. Но упростил хендовер между кластерами. Мне также любопытно, есть ли лучший способ   -  person Nath    schedule 29.12.2017
comment
Мы используем как долгосрочные, так и временные кластеры EMR — в итоге мы запускаем около 20 кластеров в хороший день; один для производства, а остальные для разработки и контроля качества. Поддерживая это, мы увидели невероятную ценность возможности запуска кластеров. Если ваша новая архитектура требует этого, держу пари, вы обнаружите, что это хорошо: в некотором смысле то, что вы определяете, является фактически сине-зеленым развертыванием, и это очень хороший шаблон, ИМО   -  person Tom Harrison    schedule 07.01.2018
comment
@TomHarrisonJr Интересно! - спасибо. Как вы справляетесь с загрузкой новых выпусков/библиотек в давно работающем кластере? Вы завершаете старый и создаете новый кластер? Ваше здоровье   -  person Stan    schedule 08.01.2018
comment
Каждый выпуск, даже для давно работающего кластера, запускает новый кластер и завершает работу старого. Мы поддерживаем несколько механизмов ввода потоковых данных, поэтому мы построили вокруг них небольшой фреймворк для обработки мгновенного переключения во время развертывания, но помимо этого мы получаем совершенно новый набор экземпляров в каждом выпуске (то есть несколько раз в неделю).   -  person Tom Harrison    schedule 09.01.2018

Ответы (1)


arrow_upward
6
arrow_downward

Вы определенно не хотите поддерживать экземпляр EC2 для организации такого процесса CI/CD. Прежде всего, это создает ряд проблем, потому что тогда вам нужно иметь дело со всем экземпляром сервера, поддерживать его в рабочем состоянии, иметь дело с сетью, применять мониторинг и оповещения для решения проблем с доступностью, и даже в этом случае у вас не будет доступности. гарантии, которые могут вызвать другие проблемы. Прежде всего, поддержка экземпляра EC2 для такой цели просто не нужна.

Я рекомендую вам изучить возможности использования Amazon CodePipeline с лямбда-пошаговой функцией. Функцию шага можно использовать для организации подготовки вашего кластера EMR в полностью бессерверной среде. С помощью CodePipeline вы можете настроить веб-хук в своем репозитории Github, чтобы автоматически извлекать код и запускать новое развертывание всякий раз, когда изменения фиксируются в вашей основной ветке Github (или любой указанной вами ветке). Вы можете использовать EMRFS для синхронизации корзины или папки S3 с файловой системой EMR для вашего кластера, а затем получить преимущества безопасности IAM, а также дополнительные гарантии согласованности, предоставляемые EMRFS. С Lambda вы также получаете бесшовную интеграцию с другими сервисами, такими как Kinesis, DynamoDB и CloudWatch, среди многих других, что упростит многие административные задачи и задачи разработки, а также позволит вам с минимальными усилиями реализовать более сложную автоматизацию.

Есть несколько отличных ресурсов и руководств по использованию CodePipeline с EMR, а также в целом. Вот некоторые примеры:

Существуют также отличные руководства по оркестровке приложений с помощью Lambda Step Functions, включая использование EMR. Вот некоторые примеры:

В самом худшем случае, если все эти варианты не работают, например, если вам нужен очень строгий контроль над процессом запуска в кластере EMR после того, как кластер EMR завершит начальную загрузку, вы всегда можете создать JAR-файл Java, который загружается как окончательный. шаг, а затем используйте его либо для выполнения сценария оболочки, либо для использования различных библиотек Amazon Java для запуска ваших команд подготовки. Даже в этом случае вам по-прежнему не нужно поддерживать свой собственный экземпляр EC2 для целей оркестровки (что, на мой взгляд, было бы трудно оправдать, даже если бы он работал в контейнере Docker в Kubernetes), потому что вы можете легко поддерживать этот процесс развертывания, а также полностью бессерверный подход.

Есть много отличных видео с конференций Amazon re:Invent, которые вы можете посмотреть, чтобы получить толчок, прежде чем погрузиться в семинары. Например:

Еще много таких видео доступно на YouTube.

Travis CI также поддерживает развертывание Lambda, как указано здесь: https://docs.travis-ci.com/user/deployment/lambda/

person devinbost    schedule 18.12.2018