Как вы обрабатываете файлы конфигурации для AWS CodePipelines?

Я в команде разработчиков, использующих Git в качестве системы контроля версий.

Мы хотим иметь как минимум 3 этапа нашего процесса разработки: стадия, разработка и продакшн.

Единственное, что должно меняться между этими этапами, - это один файл конфигурации, чтобы сообщить бессерверной платформе, как называть лямбда-функции, сегменты S3 и любые другие ресурсы, которые необходимо создать для стека CloudFormation.

Однако это немного усложняет управление исходным кодом. Если мы помещаем файлы конфигурации непосредственно в исходный код, мы должны убедиться, что эти файлы не будут переопределены, когда мы фиксируем / нажимаем на источник. Но CodeBuild должен каким-то образом иметь к нему доступ, и он должен быть уверен, что получил правильный файл конфигурации для указанного этапа.

Я бы предпочел решение этой проблемы, которое является частью экосистемы AWS.


git amazon-web-services aws-codebuild aws-codepipeline staging
person Turner Houghton    schedule 25.09.2017    source источник
comment
Вы читали aws.amazon.com/blogs/devops/? Это очень похоже на то, что вы хотите сделать.   -  person aderubaru    schedule 25.09.2017

Ответы (2)


arrow_upward
4
arrow_downward

Я бы предложил хранить переменные среды в хранилище параметров EC2, на которое вы можете ссылаться в своем CodeBuild buildspec.yml.

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

Например, предположим, что вы храните следующие переменные в хранилище параметров EC2 (или AWS SSM),

DEVELOPMENT_DB_PASSWORD='helloworld'
STAGING_DB_PASSWORD='helloworld'
PRODUCTION_DB_PASSWORD='helloworld'

В вашем проекте CodeBuild вы должны указать среду как переменную (например, $ENVIRONMENT=DEVELOPMENT). Не используйте для этого buildspec. Вы можете использовать Консоль AWS или CloudFormation.

Тогда ваш buildspec.yml может выглядеть так:

env:
  parameter-store:
    DEVELOPMENT_DB_PASS: "DEVELOPMENT_DB_PASSWORD"
    STAGING_DB_PASS: "DEVELOPMENT_DB_PASSWORD"
    PRODUCTION_DB_PASS: "DEVELOPMENT_DB_PASSWORD"

Затем эти переменные становятся доступными в вашем serverless.yml с помощью ${env:ENVIRONMENT}_DB_PASS, например:

provider:
  environment:
    DB_PASS: ${env:${env:ENVIRONMENT}_DB_PASS}

Все, что вам нужно сделать сейчас, это создать эти три CodePipelines, каждый из которых имеет свой собственный проект CodeBuild (причем каждый проект использует свой $ENVIRONMENT).

person Noel Llevares    schedule 25.09.2017
comment
Я застрял на последнем шаге, я думаю, что мой файл serverless.yml интерпретирует значение как буквальную строку, не понимая, что это переменная среды - person Turner Houghton; 25.09.2017

arrow_upward
2
arrow_downward

Почему бы вам не использовать три файла конфигурации? по одному на каждый этап.

person Taylor21    schedule 25.09.2017