web-dev-qa-db-ja.com

サーバーレスフレームワークを備えたAWScodeBuild / codePipeline

アプリケーションのデプロイメントパイプラインを自動化しようとしています。これが自動化アーキテクチャです、私は思いついた： Automation Architecture

ご覧のとおり、デプロイメントを自動化するためにcodePipelineとcodeBuildを使用しています。私のバックエンドは Serverless Framework に基づいており、sls deployコマンドの起動時にラムダ関数をデプロイします。これが理由です。従来の展開ではcodeDeployを使用しませんでした。 buildspec.ymlファイルは次のようになります：

version: 0.1

phases:
  install:
    commands:
      – apt-get -y update
      – npm install -g [email protected]
  build:
    commands:
      – cd nj2jp/serverless && npm install
  post_build:
    commands:
      – serverless deploy –verbose

artifacts:
  files:
    – serverless.yml
  discard-paths: yes

今、私はCodeBuildとサーバーレスに関して3つの質問を持っています：

質問1：コマンドsls deployは、dbパスワードなどのシークレットを含むconfig.ymlというファイルに依存しています。このファイルはgitにチェックインされません。 codeBuildにconfig.ymlを含めるための最良の方法は何だと思いますか？

質問2：ロールバックは、を使用して従来のEC2アプリケーションをデプロイする必要がある場合、AWSで実行できますcodeDeploy。サーバーレスの場合、codeDeployを使用しておらず、サーバーレスはrollback機能もサポートしています。 codePipeline内でサーバーレスロールバックをどのように活用しますか？

質問3：プルリクエストが発生したときにcodePipelineをトリガーします。 codePipelineではサポートされていないという投稿をいくつか見ました。しかし、それらの投稿は昨年のものでした。プルリクエストはcodePipelineでサポートされるようになりましたか？

ハックアンサー（正しくありませんが、機能します。あなたからのより良いアンサーが必要です。）

回答1：config.ymlファイルはプライベートS3バケットに保存でき、一部としてcodeBuildにプルできますof pre-buildsetupまたはcodeBuildのEnv変数にすべてのシークレットを追加できます。すべての環境で一貫性を保ちたいので、2番目のオプションは好きではありません。この問題のより良い解決策はありますか？

回答2：これに対するハックは考えられません。あなたからの答えを探しています。

回答3：[APIGateway + Lambda + S3] を使用してcodePipelineプルリクエストの場合。しかし、この機能はすぐに使用できるものとして提供する必要があると思います。この機能のcodePipelineに更新はありますか？

amazon-web-servicesaws-lambdaserverless-frameworkaws-codepipelineaws-codebuild
14
Lakshman Diwaakar

質問1

更新：

サーバーレスフレームワークは、パラメーターストアからの変数の参照をサポートするようになりました。つまり、サーバーレスはデプロイ時にパラメーターストアからそれらを取得するため、CodeBuildでの定義をスキップできます。

例：

serverless.yaml

provider:
  name: aws
  runtime: nodejs8.10
  region: us-west-2
  stage: ${env:REGION}
  environment:
    S3_BUCKET: ${env:/s3/bucket}
    # Use ~true for SecureString parameters
    DB_USERNAME: ${ssm:/db/username~true}
    DB_PASSWORD: ${env:/db/password~true}

元の回答：

config.ymlを使い続けたい場合、それを機能させる唯一の方法は、バージョン管理されていないため、すでに行っているのと同様のハックを行うことです。

私が提案するのは、CodeBuild buildspec.ymlで参照できるEC2パラメーターストアに環境変数を保存することです。これらの変数には、serverless.ymlを使用して${env:VARIABLE_NAME}でアクセスできます。

ローカル開発の場合は、実際の環境変数を使用するのではなく、config.ymlに保存する必要があります。 direnv などのツールはこれに最適です。

質問2

前のCodeBuildジョブを再実行することにより、手動でロールバックを実行できます。 CodeDeployのように、自動的にそれを行う簡単な方法は考えられません。たぶん、Lambda関数はデプロイ後のテストを実行でき、失敗した場合は、前のCodeBuildジョブの再実行をトリガーできます。

質問3

CodePipelinesは単一のブランチに関連付けられているため、PRブランチで機能させるには、前述の記事のようなハックを行う必要があります。 API Gateway+Lambda+CodeBuild（NoCodePipeline）これを行うには。

8
dashmug

質問1で受け入れられた回答に追加するだけです（@dashmugと@Lakshman Diwaakarに感謝します）

これは、パラメータストアの値をLambdaに取り込む方法を整理します。ただし、値はLambdaコンソールにプレーンテキストとして表示されます。次に、暗号化を追加する方法を検討する必要があります。

パラメータストア

AWS Systems Manager>パラメータストアで環境変数をパラメータとして追加します

https://eu-west-1.console.aws.Amazon.com/systems-manager/parameters

buildspec.yml

version: 0.2    
phases:
  install:
    commands:
      - npm install
      - npm install -g serverless
  build:
    commands:
      - serverless deploy

serverless.yml

Serverless.ymlで作成されたパラメーターを参照します

安全な文字列の場合は〜trueを追加します。

provider:
  name: aws
  runtime: nodejs6.10
  region: eu-west-1
  stage: prod
  environment:
    FOO: ${ssm:/app/production/foo}
    DB_USERNAME: ${ssm:/app/production/myDatabase/username~true}
    DB_PASSWORD: ${ssm:/app/production/myDatabase/password~true}

handler.js

ハンドラーでenv変数を使用します

export async function main (event, context, callback) {

  console.log('process.env.FOO', process.env.FOO)
  console.log('process.env.DB_USERNAME', process.env.DB_USERNAME)
  console.log('process.env.DB_PASSWORD', process.env.DB_PASSWORD)

  callback(null, ok('success'))
}
0
L G