您如何处理AWS CodePipelines的配置文件？ [英] How do you handle config files for AWS CodePipelines?

问题描述

我们希望在开发过程中至少有3个阶段：staging，dev，和生产。

这些阶段之间唯一应该改变的地方是一个配置文件，告诉无服务器框架什么是lambda函数，S3存储桶和任何其他资源需要为CloudFormation堆栈创建。

但是，这使源代码控制变得更加困难。如果我们将配置文件直接放在源代码中，那么我们必须确保这些文件在我们提交/推送到原点时不会被覆盖。但CodeBuild必须以某种方式访问​​它，并且必须确保为指定阶段获取正确的配置文件。

我宁愿为此解决方案问题是AWS生态系统的一部分。

解决方案

我建议将您的环境变量存储在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：
参数存储：
 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：
环境：
 DB_PASS：$ {env：$ {env：ENVIRONMENT} _DB_PASS} 
  

你现在要做的就是创建这三个CodePipelines，每个CodePipeline都有自己的CodeBuild项目（每个项目使用不同的 $ ENVIRONMENT ）。

I am on a team of developers using Git as our version control.

We want to have a minimum of 3 stages of our development process: staging, dev, and production.

The only thing that should change between these stages is a single config file, to tell the Serverless framework what to name the lambda functions, S3 buckets, and any other resource that needs to be created for the CloudFormation stack.

However, this makes source control a bit harder. If we put the config files directly in the source code, then we have to make sure that those files don't get overridden when we commit/push to origin. But the CodeBuild has to have access to it somehow, and it has to be sure to grab the right config file for the specified stage.

I would prefer a solution to this issue that is a part of the AWS ecosystem.

解决方案

What I'd suggest is to have your environment variables stored in EC2 Parameter Store which you can reference in your CodeBuild buildspec.yml.

To use CodePipeline in your case, you also need different pipelines and different CodeBuild projects for each environment.

For example, say you store the following variables in EC2 Parameter Store (or AWS SSM),

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

In your CodeBuild project, you have to specify the environment as a variable (e.g. $ENVIRONMENT=DEVELOPMENT). Don't use buildspec for this. You can use AWS Console or CloudFormation.

Then, your buildspec.yml can look like this:

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

These variables are then accessible in your serverless.yml using ${env:ENVIRONMENT}_DB_PASS like so:

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

All you have to do now is to create those three CodePipelines each having their own CodeBuild project (with each project using a different $ENVIRONMENT).

这篇关于您如何处理AWS CodePipelines的配置文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！