直樹2022.05.16302この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。AWS事業本部コンサルティング部の後藤です。CLIを実行した方が構成的にもスッキリして簡単に実装出来そう?と思ったので、実際に試してみました。今回はCodeBuildとLambda関数が異なるアカウントになる事を想定していますので、以下のような構成で行っていきます。CodeBuild等を構築するアカウントをAccount(A)、Lambda関数を構築するアカウントをAccount(B)としています。CodeCommit、CodeBuild、S3Bucket作成Lambda関数を更新するために使用するCodeCommit、CodeBuild、S3BucketをAccount(A)に作成します。複雑な設定は行っていないため、今回は説明を省略致します。AssumeRole用IAMロール作成Account(A)のCodeBuildがAccount(B)の権限でLambda関数を更新出来るようにするため、AssumeRole用のIAMロールを作成します。今回はLambda関数の更新のみ行うため、以下のIAMポリシーを与えています。]}Account(A)のS3Bukcetに対する権限は、CodeBuildでLambda関数をzip化した後S3にアップロードしてから更新コマンドを実行するために付与しています。CodeBuildで実行するbuildspec.ymlに関しては後述します。AssumeRole用IAMロールには信頼エンティティでAccount(A)からのAssumeRoleを許可するよう、以下のように設定しています。ServiceRoleに権限追加CodeBuildのServiceRoleからAccount(B)に作成したAssumeRole用IAMロールを使用するため、以下のような権限を追加します。CodeBuildのServiceRole自体は自動生成されたものを使用しています。前述で軽く触れた通り、Lambda関数のコードはCodeBuildで一度Account(A)のS3にアップロードしています。CodeBuildがLambda関数を更新する際にはAccount(B)の権限を使用するため、Account(A)のS3にバケットにAccount(B)からのアクセスを許可するようバケットポリシーを設定する必要があります。設定したバケットポリシーが以下の通りです。]}CodeBuildではS3にアップロードされたLambda関数のコードを読み取るだけなので、getとlistのみ許可しています。諸々AWSリソース周りの設定が出来上がってきたので、次はCodeBuildで実行するbuildspec.ymlを作成していきます。buildspec.yml実行時における権限変更の方法等は、以下ブログを参考に行っています。buildspec.ymlで実行する内容は主に以下になります。出来上がったbuildspec.ymlは以下の通りです。get-caller-identityを実行しています。11行目の${ASSUME_ROLE_ARN}ではCodeBuildの環境変数にAccount(B)のIAMロールARN値を設定しています。CodeCommitにpushするリポジトリの中身は以下のような構造としています。buildspec.ymlLambda関数自体はPython3.9のLambda関数を作成した際にデフォルトで作成されるHelloWorldのスクリプトを少し弄ってLambda関数が更新出来ているか確認をしていきます。CodeBuildを実行してみる今回はCodePipeline等は使用していないため、CodeCommitにpush後手動でCodeBuildを実行しています。CLI実行ログが出力されれば成功となります。]}Account(B)のLambda関数を確認すると、コードだけ更新されている事が確認出来ると思います。まとめ今回はCodeBuildを使用して他アカウントのLambda関数更新をやってみました。Lambda関数のCICD方法は幾つか方法があります。今回の方法ではCFnよりも簡単に実装する事が出来たと思いますが、Lambda関数の細かい設定も一緒にデプロイしたい場合や、他のサーバレスリソースの設定も変更したい要件だとbuildspec.ymlに記述する内容が複雑になりそうなので、環境や管理の方法によって適材適所を見極めて使っていきたいですね。この記事が何方かのお役に立てば幸いです。