2

AWSインフラストラクチャとAWS Lambda関数のCI/CDパイプラインを設定したいとします。アイデアは、バージョン管理され、自動化されたコードですべてを持つことです。私はちょうどgit pushをリポジトリに追加し、そこからCodePipelineを引き継ぎ、インフラストラクチャを更新し、テストを実行し、成功した場合、ラムダ関数を最新のコードで更新します。CloudType、CodeBuild、CodePipelineを使用してPythonパッケージをAWS Lambdaにデプロイ

私はCloudFormationテンプレートをthis excellent exampleに基づいています。それは次のようになります。

AWSTemplateFormatVersion: 2010-09-09 
Description: playground pipeline 1 
Parameters: 
    SourceRepositoryName: 
    Type: String 
    Default: lambda-playground 
    SourceBranchName: 
    Type: String 
    Default: master 

Resources: 
    ArtifactsBucket: 
    Type: AWS::S3::Bucket 
    DependsOn: CloudFormationRole 
    DeletionPolicy: Delete 
    Properties: 
     BucketName: lambda-playground-artifacts 

    CodeBuildRole: 
    Type: AWS::IAM::Role 
    DependsOn: CloudFormationRole 
    Properties: 
     AssumeRolePolicyDocument: 
     Version: 2012-10-17 
     Statement: 
      - Effect: Allow 
      Action: 
       - sts:AssumeRole 
      Principal: 
       Service: 
       - codebuild.amazonaws.com 
     Policies: 
     - PolicyName: ServiceRole 
      PolicyDocument: 
      Version: 2012-10-17 
      Statement: 
       - Sid: CloudWatchWriteLogsPolicy 
       Effect: Allow 
       Action: 
        - logs:CreateLogGroup 
        - logs:CreateLogStream 
        - logs:PutLogEvents 
       Resource: '*' 
       - Sid: CodeCommitPullPolicy 
       Effect: Allow 
       Action: 
        - codecommit:GitPull 
       Resource: '*' 
       - Sid: S3GetObjectPolicy 
       Effect: Allow 
       Action: 
        - s3:GetObject 
        - s3:GetObjectVersion 
       Resource: '*' 
       - Sid: S3PutObjectPolicy 
       Effect: Allow 
       Action: 
        - s3:PutObject 
       Resource: '*' 

    CodePipelineRole: 
    Type: AWS::IAM::Role 
    DependsOn: CloudFormationRole 
    Properties: 
     AssumeRolePolicyDocument: 
     Version: 2012-10-17 
     Statement: 
      - Effect: Allow 
      Action: 
       - sts:AssumeRole 
      Principal: 
       Service: 
       - codepipeline.amazonaws.com 
     ManagedPolicyArns: 
     - arn:aws:iam::aws:policy/AdministratorAccess 

    CloudFormationRole: 
    Type: AWS::IAM::Role 
    Properties: 
     AssumeRolePolicyDocument: 
     Version: 2012-10-17 
     Statement: 
      - Effect: Allow 
      Action: 
       - sts:AssumeRole 
      Principal: 
       Service: 
       - cloudformation.amazonaws.com 
     ManagedPolicyArns: 
     - arn:aws:iam::aws:policy/AdministratorAccess 

    CodeCommitRepository: 
    Type: AWS::CodeCommit::Repository 
    Properties: 
     RepositoryName: !Ref SourceRepositoryName 

    CodeBuildProject: 
    Type: AWS::CodeBuild::Project 
    DependsOn: CloudFormationRole 
    Properties: 
     Description: A playground of Lambda 
     Artifacts: 
     Type: CODEPIPELINE 
     Environment: 
     ComputeType: BUILD_GENERAL1_SMALL 
     Image: aws/codebuild/python:2.7.12 
     Type: LINUX_CONTAINER 
     Name: lambda-playground 
     ServiceRole: !GetAtt CodeBuildRole.Arn 
     Source: 
     Type: CODEPIPELINE 
     TimeoutInMinutes: 5 

    CodePipeline: 
    Type: AWS::CodePipeline::Pipeline 
    Properties: 
     ArtifactStore: 
     Type: S3 
     Location: !Ref ArtifactsBucket 
     Name: !Ref AWS::StackName 
     RestartExecutionOnUpdate: true 
     RoleArn: !GetAtt CodePipelineRole.Arn 
     Stages: 
     - Name: Source 
      Actions: 
      - Name: Source 
       ActionTypeId: 
       Category: Source 
       Owner: AWS 
       Provider: CodeCommit 
       Version: 1 
       Configuration: 
       RepositoryName: !Ref SourceRepositoryName 
       BranchName: !Ref SourceBranchName 
       OutputArtifacts: 
       - Name: SourceOutput 
     - Name: PipelineDeploy 
      Actions: 
      - Name: UpdatePipeline 
       ActionTypeId: 
       Category: Deploy 
       Owner: AWS 
       Provider: CloudFormation 
       Version: 1 
       Configuration: 
       ActionMode: CREATE_UPDATE 
       Capabilities: CAPABILITY_IAM 
       RoleArn: !GetAtt CloudFormationRole.Arn 
       StackName: !Ref AWS::StackName 
       TemplatePath: SourceOutput::infra.yml 
       InputArtifacts: 
       - Name: SourceOutput 
     - Name: Build 
      Actions: 
      - Name: BuildAndTest 
       ActionTypeId: 
       Category: Build 
       Owner: AWS 
       Provider: CodeBuild 
       Version: 1 
       Configuration: 
       ProjectName: !Ref CodeBuildProject 
       InputArtifacts: 
       - Name: SourceOutput 
       OutputArtifacts: 
       - Name: BuildOutput 

    LambdaFunction: 
    Type: AWS::Lambda::Function 
    Properties: 
     Code: 
     S3Bucket: !Ref ArtifactsBucket 
     S3Key: !Ref BuildOutput # DOES NOT WORK 
     FunctionName: playground-fc 
     Handler: src.main.handler 
     # TODO: Role: foo 
     Runtime: python2.7 

Outputs: 
    ArtifactsBucketURL: 
    Description: Artifacts bucket URL 
    Value: !GetAtt ArtifactsBucket.WebsiteURL 
    RepositoryURL: 
    Description: SSH URL of the repository 
    Value: !GetAtt CodeCommitRepository.CloneUrlSsh 

は、だから私は3つの段階でCodePipeline持っている - Source、設定さCodeBuildプロジェクトを実行し、私のCloudFormationスタック必要に応じて Buildを更新CodeCommitレポ、 PipelineDeploy、からコードをつかみます。

私buildspec.ymlはここにある:

version: 0.1 

phases: 
    install: 
    commands: 
     - pip install -r requirements.txt -t lib 
    pre_build: 
    commands: 
     - python lib/pytest.py src 
artifacts: 
    type: zip 
    files: 
    - src/**/* 
    - lib/**/* 

それはちょうど、必要なライブラリをインストールしpytestを経由してテストを実行し、展開zipファイルを作成します。このzipファイルはBuildステージのOutputArtifactで、ArtifactsBucketに格納されます。しかし、毎回固有の名前(例:dfVV6Uh)が得られますが、これはLambdaFunction - > Properties - > Code - > S3Keyフィールドで参照する方法がわかりません。

私の質問は、どのようにすべての手順を実行した後、AWS Lambda関数に最新のバージョンを展開するスタック/パイプラインを作成できますか?おそらくこれを行うためにCodeDeployを使用する方法はありますか?ここでベストプラクティスは何ですか?

答えて

3

あなたが動的にCloudFormation展開アクションにAWS CodePipelineによって生成されたアーティファクト.zipの名前を提供するために、Fn::GetArtifactAttParameter OverrideObjectKey属性を使用することができます。 、そして、

Configuration: 
    ActionMode: CREATE_UPDATE 
    Capabilities: CAPABILITY_IAM 
    RoleArn: !GetAtt CloudFormationRole.Arn 
    StackName: !Ref AWS::StackName 
    TemplatePath: SourceOutput::infra.yml 
    ParameterOverrides: 
    { 
     "LambdaKey" : { "Fn::GetArtifactAtt" : ["LambdaFunctionSource", "ObjectKey"]} 
    } 
InputArtifacts: 
- Name: SourceOutput 
- Name: BuildOutput 

を宣言してからCloudFormationスタックテンプレート内LambdaKeyパラメータを参照します:あなたの例を使用して

は、あなたのUpdatePipeline CloudFormationの配備アクションの設定は、このようになります

Parameters: 
    LambdaKey: 
    Type: String 
    # ... 
Resources: 
    LambdaFunction: 
    Type: AWS::Lambda::Function 
    Properties: 
     Code: 
     S3Bucket: !Ref ArtifactsBucket 
     S3Key: !Ref LambdaKey 
     # ... 
+0

そのため、AWS :: Lambda :: Functionを別のCloudFormationテンプレートで宣言することが考えられます。もともと、私は1つのテンプレートにすべてを持つことを考えました。そのため、 'UpdatePipeline'(誤解を招くような名前、今は実現しています)のステップが私のパイプラインの第2です。私のラムダ関数コードは、CodeBuildステップの出力であり、パイプラインの3番目のものです。したがって、私は2番目のステップでそれを参照することはできません(まだ試していません)。 –

+0

私はあなたの質問で提供したテンプレートで私の答えに基づいていました。これは 'SourceOutput :: infra.yml'を参照していました。ソースリポジトリ内のテンプレートを、コードパイプラインリソースを定義するために使用するのと同じテンプレートとして設定して、自己参照を可能にすることが可能です。 GitHubを使用した完全に自己完結型の例については、https://github.com/wjordan/aws-starter-kitのレポを参照してください。 – wjordan

+0

私はaws-starter-kitを勉強しましたが、あなたのアドバイスに基づいてテンプレートを修正しようとしましたが、成功しませんでした。問題は、1つのテンプレートにすべてを収めて、インフラストラクチャをブートストラップして、継続的に更新できるようにすることです。そうするために、ラムダ関数のリソースを作成するとき、S3Keyはまだありません。これは、3番目のパイプラインステップであるビルドアクションの出力としてのみ提供されます。ブートストラップステップのためのダミーのデプロイメントパッケージを作成します。 –

1

似たような方法(CodePipeline/CodeBuild経由でラムダ関数を展開する方法)の例があります。 http://docs.aws.amazon.com/lambda/latest/dg/automating-deployment.html

この例は、NodeJSで書かれたラムダ関数ですが、基本的な考え方は同じです。 CloudFormationを使用して、CodeBuildを使用してアーティファクトを構築した後でラムダ関数をデプロイ/更新し、CodePipelineでステージ内でアーティファクト伝播を管理させます。

これが役立つかどうか教えてください。

関連する問題