Go to Qiita Advent Calendar 2024 Top
LoginSignup
3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@kazu_kazu

【AWS DOP学習】CodePipelineを使用してLambdaを作成するチュートリアルを、CloudTrailを覗きながらやってみた

Last updated at Posted at 2021-08-14

はじめに

DOP学習にあたり、CodePipelineのイメージを掴むためにチュートリアルを行います。

対象チュートリアル

チュートリアルの構成図

codepipeline_tutorial_1.png
※チュートリアル中、Lambdaの箇所にDynamoDBも追加されます。

やってみた

Lambdaからアプリケーションを作成

まず、Lambdaのアプリケーションを一から作成します。

スクリーンショット 2021-08-12 19.09.54.png

Lambdaのアプリケーションを作成すると、Serverless Application Repositoryからアプリケーションをパイプライン付きで作成できます。

Serverless Application Repositoryとは、その名のとおりサーバレスアプリケーションのマネージド型リポジトリです。
AWSやサードパーティーだけでなく、個人もリポジトリにサーバレスアプリケーションを追加できます。

続いて、チュートリアルの指示どおり、各項目を埋めて作成します。

スクリーンショット 2021-08-12 19.10.44.png

スクリーンショット 2021-08-12 19.10.52.png

アプリケーション作成後の画面がこちらです。
AWSリソースが作成され、リソース、インフラストラクチャと分類されています。

スクリーンショット 2021-08-12 19.19.33.png

リソースはLambda。
インフラストラクチャはパイプラインに必要なAWSリソースです。
これらは、２つのCloudFormationにより作成されています。
こちらがそのCloudFormationです。

スクリーンショット 2021-08-12 19.21.58.png

my-appによりリソース、serverlessrepo-my-app-toolchainによりインフラストラクチャが作成されています。

Lambdaでアプリケーションを作成すると、まずserverlessrepo-my-app-toolchainが作成されます。
このCloudFormation Stackは、青で囲んだ以下のリソースを作成します。

codepipeline_tutorial_1-2.png

そして、CodePipelineは作成すると自動実行されるので、Deploy Stageで設定したCloudFormation=my-appがデプロイされ、リソースであるLambdaが作成される、という流れになります。

Lambdaからアプリケーションを作成する際のAPI履歴を追う

チュートリアルから脇道に逸れますが、気になるのでアプリケーション作成からのAPIの動きを、少しだけCloudTrailなどで追ってみました。

以下の画像は、CloudTrailのイベント履歴で、Lambdaでアプリケーションの作成をした直後の状態です。
アプリケーションの作成ボタンをクリックした後に走るAPIが分かります。

スクリーンショット 2021-08-13 20.10.51.png

注目していただきたいのは、下の2つです。
それより上のAPIは、ExecuteChangeSetによりリソースが作成されているだけです。

Lambdaでアプリケーションを作成すると、CreateChangeSet、CreateCloudFormationChangeSetが走っていますが、時系列的にはCreateCloudFormationChangeSet -> CreateChangeSetが正しいと思っています。

ドキュメントは提示できませんが、chromeの開発者ツールでリクエストペイロードを確認する限り、この順番の可能性が高いと考えます。

以下では、CloudTrailのAPIログ、chromeの開発者ツールの画像を用いて、Lambdaのアプリケーション作成後のAPIの動きを、時系列に沿って説明します。

こちらの画像は、アプリケーション作成ボタンクリック後のchrome開発者ツールのNetworkタブの状態です。

スクリーンショット 2021-08-13 20.35.04.png

青で選択している一つ上をご覧ください。
getApplicationAPIを実行し、今回作成するサーバレスアプリケーションの情報を、サーバーレスアプリケーションリポジトリから取得しています。

Request_Payload
{
    "service": "serverlessapplicationrepository.AWSServerlessApplicationRepository",
    "api": "getApplication",
    "payload": {
        "applicationId": "arn:aws:serverlessrepo:us-east-1:713482062377:applications/CICD-toolchain-for-serverless-applications"
    },
    "operation": "proxyAwsCall"
}

上記リクエストに対するレスポンスは抜粋して掲載します。

Response
{
    "applicationId": "arn:aws:serverlessrepo:us-east-1:713482062377:applications/CICD-toolchain-for-serverless-applications",
    "author": "AWS Lambda console",
    "creationTime": "2019-10-02T23:27:14.536Z",
    "description": "Automated deployment toolchain used by new serverless applications created through the AWS Lambda console",
    "name": "CICD-toolchain-for-serverless-applications",
    "version": {
        "applicationId": "arn:aws:serverlessrepo:us-east-1:713482062377:applications/CICD-toolchain-for-serverless-applications",
        "creationTime": "2021-06-14T18:49:13.628Z",
        "parameterDefinitions": [
            {
                "name": "AppId",
                "type": "String"
            },
            {
                "name": "AppResourceArns",
                "type": "CommaDelimitedList"
            },
            {
                "name": "ConnectionArn",
                "type": "String"
            },
            {
                "name": "GitHubRepositoryOwner",
                "type": "String"
            },
            {
                "name": "RepositoryName",
                "type": "String"
            },
            {
                "name": "SourceCodeBucketKey",
                "type": "String"
            },
            {
                "name": "SourceCodeBucketName",
                "type": "String"
            },
            {
                "name": "UseCodeCommit",
                "type": "String"
            }
        ],
        "requiredCapabilities": [
            "CAPABILITY_NAMED_IAM",
            "CAPABILITY_RESOURCE_POLICY"
        ],
        "sourceCodeUrl": "https://github.com/aws-samples/aws-lambda-sample-applications/tree/master/CICD-toolchain-for-serverless-applications",
        "templateUrl": "https://awsserverlessrepo-applications-eji6x7x4bodi.s3.amazonaws.com/713482062377/CICD-toolchain-for-serverless-applications/741f579c-fb69-44a8-8e3b-aae190231505/1.0.5/transformed-template.yaml?"
    }
}

その後、getApplicationで取得した情報を使用して、createCloudFormationChangeSetAPIを実行してCloudFormationのStackと変更セットを作成しています。

おそらく、このAPIを実行すると、裏でCreateChangeSetが動くのでしょう。

Request_Payload
{
    "service": "serverlessapplicationrepository.AWSServerlessApplicationRepository",
    "api": "createCloudFormationChangeSet",
    "payload": {
        "applicationId": "arn:aws:serverlessrepo:us-east-1:713482062377:applications/CICD-toolchain-for-serverless-applications",
        "stackName": "my-app-toolchain",
        "capabilities": [
            "CAPABILITY_RESOURCE_POLICY",
            "CAPABILITY_NAMED_IAM"
        ],
        "parameterOverrides": [
            {
                "name": "UseCodeCommit",
                "value": "true"
            },
            {
                "name": "SourceCodeBucketName",
                "value": "prodnrtstack-subsystemsn-apptemplatesbucket03a15d-1cj5ym80q3osj"
            },
            {
                "name": "SourceCodeBucketKey",
                "value": "sample-apps/nodejs/14.x/javascript/sam/fromScratch.zip"
            },
            {
                "name": "RepositoryName",
                "value": "app-name"
            },
            {
                "name": "AppId",
                "value": "app-name"
            },
            {
                "name": "AppResourceArns",
                "value": "arn:aws:lambda:ap-northeast-1:１１１１１１１１１１１１:function:my-app-helloFromLambda*"
            }
        ],
        "semanticVersion": "1.0.5"
    },
    "operation": "proxyAwsCall"
}
Response
{
    "sdkResponseMetadata": null,
    "sdkHttpMetadata": null,
    "applicationId": "arn:aws:serverlessrepo:us-east-1:713482062377:applications/CICD-toolchain-for-serverless-applications",
    "changeSetId": "arn:aws:cloudformation:ap-northeast-1:111111111111:changeSet/a790d7ac8-5b84-4dfd-b87e-5a2da7892a26/aedfef54-0a60-437c-9b7b-3e8f9c1c87ed",
    "semanticVersion": "1.0.5",
    "stackId": "arn:aws:cloudformation:ap-northeast-1:111111111111:stack/serverlessrepo-my-app-toolchain/0c788e40-fc2c-11eb-873e-0a94ddda7ff3"
}

その後、開発者ツールでexecuteChangeSetのリクエストまで確認しましたが、CloudTrailで記録されていたCreateChangeSetをリクエストした形跡はありませんでした。

このことから、CreateCloudFormationChangeSetを実行すると、裏でCreateChangeSetが動いているのだと思います。

そもそも、CreateCloudFormationChangeSetは、Serverless Application RepositoryAPIです。

サーバーレスアプリケーションリポジトリからアプリケーションを作成する場合、CloudFormation（SAMテンプレート）により作成されます。
そのため、CreateCloudFormationChangeSetを実行すると裏でCreateChangeSetが動くのは、自然なことだと考えられます。

以下はCreateChangeSetのAPIログの抜粋です。

eventName_CreateChangeSet

{
    "eventVersion": "1.08",
    "userIdentity": {
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　略
        },
        "invokedBy": "apigateway.amazonaws.com"
    },
    "eventTime": "2021-08-12T10:11:04Z",
    "eventSource": "cloudformation.amazonaws.com",
    "eventName": "CreateChangeSet",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "apigateway.amazonaws.com",
    "userAgent": "apigateway.amazonaws.com",
    "requestParameters": {
        "notificationARNs": [],
        "capabilities": [
            "CAPABILITY_NAMED_IAM"
        ],
        "changeSetName": "a2051af8f-a86a-4459-bde7-2360d603e728",
        "stackName": "serverlessrepo-my-app-toolchain",
        "parameters": [
            {
                "parameterKey": "UseCodeCommit"
            },
            {
                "parameterKey": "SourceCodeBucketName"
            },
            {
                "parameterKey": "SourceCodeBucketKey"
            },
            {
                "parameterKey": "RepositoryName"
            },
            {
                "parameterKey": "AppId"
            },
            {
                "parameterKey": "AppResourceArns"
            }
        ],
        略
}

当初、リクエストパラメータにChangeSetTypeがないため、このCreateChangeSetのChangeSetTypeは、デフォルトのUPDATEに当たると思っていました。

UPDATEタイプの変更セットは、既存スタックの変更セット作成時に指定されるものです。
そのため、このCreateChangeSetを実行するためには、既存スタックの存在が前提となり、Stackを作成しているCreateCloudFormationChangeSet実行後でなければ実行できない。と思っていました。

しかし、変更セットタイプが何なのか確実に判断する方法は分かりませんでした。
CLIでcreate-change-setを--change-set-typeを付けて実行したところ、CloudTrailのAPIログに変更セットタイプが記録されなかったからです。
また、describe-change-setを実行しても変更セットタイプは出力されませんでした。
変更セットタイプを知るには、変更セット作成時に、CloudFormation Stackが存在していたかどうかで判別するしかなさそうです（確認する必要性はないと思いますが）。

CreateChangeSetで一点気になるのは、apigatewayによってリクエストされていることです。
CreateCloudFormationChangeSetを実行すると、裏でapigatewayによってCreateChangeSetが実行される仕組みになっているのでしょうか。
パラメータが空だったりと具体的動作が不明ですが、裏でよしなにやってくれているのでしょう。

ちなみに以下はCreateCloudFormationChangeSetのAPIログです。
開発者ツールで確認したリクエストと同じ感じですね。

eventName_CreateCloudFormationChangeSet
{
    "eventVersion": "1.08",
　　　　　　　略
    "eventTime": "2021-08-12T10:11:05Z",
    "eventSource": "serverlessrepo.amazonaws.com",
    "eventName": "CreateCloudFormationChangeSet",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "${MyIP}",
    "userAgent": "aws-internal/3 aws-sdk-java/1.11.1030 Linux/5.4.116-64.217.amzn2int.x86_64 OpenJDK_64-Bit_Server_VM/25.292-b10 java/1.8.0_292 vendor/Oracle_Corporation cfg/retry-mode/legacy, AWSLambdaConsole/1.1",
    "requestParameters": {
        "capabilities": [
            "CAPABILITY_RESOURCE_POLICY",
            "CAPABILITY_NAMED_IAM"
        ],
        "semanticVersion": "1.0.5",
        "stackName": "my-app-toolchain",
        "parameterOverrides": [
            {
                "name": "UseCodeCommit",
                "value": "***"
            },
            {
                "name": "SourceCodeBucketName",
                "value": "***"
            },
            {
                "name": "SourceCodeBucketKey",
                "value": "***"
            },
            {
                "name": "RepositoryName",
                "value": "***"
            },
            {
                "name": "AppId",
                "value": "***"
            },
            {
                "name": "AppResourceArns",
                "value": "***"
            }
        ],
 　　　　　　　　　　　　　　略
}

脇道に逸れましたが、そろそろチュートリアルに戻ります。

Lambdaのテスト

作成されたLambdaをテストし、正常に動作するか確認します。

スクリーンショット 2021-08-12 19.42.25.png

正常に動作できていますね。

DynamoDBを追加

次に、このアプリケーションにDynamoDBを追加してみます。
ローカルからCodeCommitに接続するため、認証情報を取得します。
私はHTTPS認証情報を生成しました。

スクリーンショット 2021-08-12 19.56.16.png

ローカルにリポジトリのクローンを作成しようとしましたが、失敗しました。

# git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/my-app-repo
Cloning into 'my-app-repo'...
fatal: unable to access 'https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/my-app-repo/': The requested URL returned error: 403

私が以前CodeCommitにアクセスした際に使用したKeychain Accessユーティリティで保存されている認証情報の有効期限が切れているからです。

以下を参考に修正後、クローンします。

DynamoDBをSAMに追加してプッシュします。
（gitの操作は省略します。）

スクリーンショット 2021-08-12 20.21.58.png

DynamoDBのデプロイが確認できました。

スクリーンショット 2021-08-12 20.22.46.png

Lambdaのアクセス権限の境界を変更

しかし、このままだとLambdaはDynamoDBへのアクセス許可がありません。
Lambdaの実行ロールはアクセス権限の境界が設定されており、その中でDynamoDBが許容されていないからです。

以下が設定されているアクセス権限の境界です。
許容しているのは、

  • Lambdamy-app-helloFromLambda*に対して行える全てのAPI許可
  • CloudWatchLogsのロググループ作成やログの送信
  • X-Rayに対する送信
  • 特定のタグキーを持つリソースに対するタグ付け

です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "*"
            ],
            "Resource": [
                "arn:aws:lambda:ap-northeast-1:111111111111:function:my-app-helloFromLambda*"
            ],
            "Effect": "Allow",
            "Sid": "StackResources"
        },
        {
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:DescribeLogGroups",
                "logs:PutLogEvents",
                "xray:Put*"
            ],
            "Resource": "*",
            "Effect": "Allow",
            "Sid": "StaticPermissions"
        },
        {
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/aws:cloudformation:stack-name": [
                        "my-app"
                    ]
                },
                "ForAllValues:StringEquals": {
                    "aws:TagKeys": "aws:cloudformation:stack-name"
                }
            },
            "Action": "*",
            "Resource": "*",
            "Effect": "Allow",
            "Sid": "StackResourcesTagging"
        }
    ]
}

アクセス権限の境界の変更は、チュートリアルどおり行います。
アクセス権限の境界用のIAMポリシーを作成し、それをIAMロールの古いアクセス権限の境界と入れ替えます。

LambdaのコードをDynamoDBテーブルを更新するように変更し、動作を確認

次に、DynamoDBテーブルを更新するようにコードを更新します。
以下のチュートリアル提供のコードをsrc/handlers/index.jsに追加します。

const dynamodb = require('aws-sdk/clients/dynamodb');
const docClient = new dynamodb.DocumentClient();

exports.handler = async (event, context) => {
    const message = 'Hello from Lambda!';
    const tableName = process.env.DDB_TABLE;
    const logStreamName = context.logStreamName;
    var params = {
        TableName : tableName,
        Key: { id : logStreamName },
        UpdateExpression: 'set invocations = if_not_exists(invocations, :start) + :inc',
        ExpressionAttributeValues: {
            ':start': 0,
            ':inc': 1
        },
        ReturnValues: 'ALL_NEW'
    };
    await docClient.update(params).promise();

    const response = {
        body: JSON.stringify(message)
    };
    console.log(`body: ${response.body}`);
    return response;
}

ハンドラーを変更しているため、テンプレートも変更します。
（関係箇所抜粋）

template.yml
  helloFromLambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: ./
      Handler: src/handlers/index.handler
      Runtime: nodejs10.x

gitでプッシュ後、デプロイまで確認したらLambdaのテスト、DynamoDBテーブル確認を繰り返し、正常に動作しているかチェックします。

スクリーンショット 2021-08-12 21.08.05.png

確認の中で、DynamoDBのデータが更新されていれば、成功です。

スクリーンショット 2021-08-12 21.18.10.png

以上でチュートリアルは終了です。

CodePipelineを調べてみた

チュートリアルは終了しましたが、本記事はそもそもCodePipelineの学習のため始めました。
そのため、次はCodePipelineの内容に注目します。

今回、CodePipelineは3つのステージを作成しています。
Source,Build,Deployです。

スクリーンショット 2021-08-14 9.36.06.png

スクリーンショット 2021-08-14 9.36.18.png

簡単に説明すると、SourceのCodeCommitの変更によりCodePipelineはトリガーされ、BuildによりSAMテンプレートが作成され、DeployによりCloudFormation Stackの変更セットが実行される流れです。

以下、具体的に説明します。

Sourceステージ

Sourceに設定しているCodeCommitリポジトリのブランチが変更されると、EventBridgeルールによりCodePipelineが実行されます（CodePipelineは作成時にも実行されます）。

CodePipelineは、Sourceの出力アーティファクトとして、CodeCommitリポジトリ内のファイルをまとめたzipファイルを、指定したS3の〇〇-Pipeline/〇〇-Sou/にアップロードします。

Buildステージ

Buildでは、Sourceにより出力されたアーティファクトを使用します。

Sourceのアーティファクト
.
├── LICENSE
├── README.md
├── __tests__
│   └── unit
│       └── handlers
│           └── hello-from-lambda.test.js
├── buildspec.yml
├── package.json
├── src
│   └── handlers
│       ├── hello-from-lambda.js
│       └── index.js
└── template.yml

buildspec.ymlによりビルドの方法が指定されているので、Buildではその手順どおり実行します。

buildspec.yml
version: 0.2
phases:
  install:
    commands:
      - npm install
  pre_build:
    commands:
      - npm run test
      - npm prune --production
  build:
    commands:
      - aws cloudformation package --template template.yml --s3-bucket $S3_BUCKET --output-template-file template-export.yml
artifacts:
  files:
    - template-export.yml

今回のBuildは、

  • package.json記載のパッケージインストール
  • テスト
  • 不要パッケージ削除
  • cloudformation packageコマンド

を実行しています。

出力アーティファクトとして、cloudformation packageコマンドにより作成されたtemplate-export.ymlを指定しています。
このファイルが、変更セットのテンプレートとして使用されます。

また、Lambdaのコードはアーティファクトと同じS3バケットにアップロードされており、template-export.ymlでLambdaのコードとして指定されています。

Buildの出力アーティファクトは、指定したS3の〇〇-Pipeline/〇〇-Bui/にZipとしてアップロードされます。

Deployステージ

Deployでは、Buildで出力したアーティファクト（SAMテンプレート）を使用し、CloudFormation変更セットを作成・実行します。

その結果、テンプレート内で設定したリソース、今回の場合はLambda（追加していたらDynamoDBも）が作成されます。

パイプラインの流れ

パイプラインの流れを構成図で表すと以下のとおりです。

codepipeline_tutorial_1-CodePipeline.png

さいごに

チュートリアル自体はすぐに終わりましたが、裏でどのようにAPIが動いているのか調べると、思った以上に時間がかかってしまいました。

その代わりにServerless Application Repositoryや、CodePipelineの仕組みがなんとなく分かってきました。
また、CloudTrailで記録したAPIログのリクエスト内容は、CLIなどで実行するときのパラメーター全てを記載している訳ではないということを、改めて実感できたのは良かったと思います。

自身の学習目的の記事ですが、誰かのお役に立てたら幸いです。

3
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?