Мы делаем это, используя задание CodeBuild, указанное в каждой из учетных записей stage (dev
, test
, prod
), которое использует AWS CLI для развертывания артефакта CodePipeline ( доступно как CODEBUILD_SOURCE_VERSION
в переменных среды вашего проекта сборки) до Elasti c Beanstalk. Мы запускаем это задание как часть CodePipeline в нашей общей учетной записи сборки.
Это команды AWS CLI, которые выполняет задание CodeBuild deploy :
aws elasticbeanstalk create-application-version --application-name ... --version-label ... --source-bundle S3Bucket="codepipeline-artifacts-us-east-1-123456789012",S3Key="application/deployable/XXXXXXX"
aws elasticbeanstalk update-environment --environment-name ... --version-label ...
Вы можете указать задание CodeBuild из другой учетной записи в CodePipeline, используя описанную здесь стратегию: https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create-cross-account.html. Он включает в себя настройку доступа между учетными записями к role_arn
, используемому для задания CodeBuild deploy , и ключ KMS, управляемый клиентом, для конвейера (с политикой доступа между учетными записями).
Одним из недостатков этого подхода является то, что задание развертывания CodeBuild завершается сразу после начала развертывания и не дожидается, пока развертывание ElasticBeanstalk завершится успешно или завершится неудачно, как это происходит при развертывании собственного действия CodePipeline EB. Вы должны иметь возможность позвонить aws elasticbeanstalk describe-environments
в al oop из задания, чтобы воспроизвести это поведение, но я еще не пробовал это сделать. (Пример сценария здесь: https://blog.cyplo.net/posts/2018/04/wait-for-beanstalk/)