はじめに
この記事ではLambdaの具体的なコーディングについては扱いません。
Cloud9 や CodeStar の動作について確認し、LambdaFunctionがどのようにデプロイされるのかを解説します。
Cloud9 によるLambda開発方法
Cloud9 でLambda開発を行う場合いくつかのアプローチがあります。
- Cloud9 でコーディングしLambdaConsoleから手動でデプロイする。
- Cloud9 のLambda連携機能によりデプロイする。
- CodeStarでLambdaを管理し、Cloud9 からCodeCommit にコミットする
LambdaConsoleでの手動デプロイについては、Cloud9 の機能では無く、
Cloud9 をエディタとして利用するだけですので、今回は省きます。
事前準備
Cloud9 のデプロイ
はじめにCloud9を用意します。
Cloud9ダッシュボードを開きCreate environmentをクリックします。
Cloud9を識別するための名前を付けます。
ダッシュボードで選べるインスタンスタイプは少し古い世代になっています。
T2インスタンスよりもT3インスタンスの方が安価ですので、
other Instance タイプ を選ぶ事をおすすめします。
OSと、自動シャットダウン時間を選択します。
Cloud9はそのままの場合デフォルトVPCに作成されます。
特定のVPC、サブネットい配置したい場合は、Network Settings を開いて、VPCとサブネットを選択します。
構成を確認し、Create environmentをクリックすると、CloudFormationによってCloud9がローンチされます。
このため、Cloud9InstanceのスペックをEC2ダッシュボードから変更するとドリフトが発生します。
Cloud9 によるLambda直接開発
Cloud9にはLambdaを直接ローンチする機能があります。
Create environmentをクリックスするとそのままCloud9の画面に遷移します。
あるいは、Cloud9ダッシュボードでOpen IDEボタンをクリックしてCloud9の画面を開きます。
Cloud9の画面を開いたら右ペインのAWS Resources タブを開きます。
Resourceタブには既存のLambda環境が表示されます。
ここで、λマークをクリックすると新しいLambdaFunctionの作成ウィザードを起動できます。
ウィザードでは初めにLambdaFunctionの名前を入力します。
Nextで進むとブループリントが表示されます。サンプル内容や使用言語からブループリントを選択します。
LambdaFunctionのトリガーを選択します。
LambdaFunctionの割り当てメモリ、割り当てロールを選択します。
設定を確認してFinishをクリックします。
LambdaFunctionがローンチされ、LambdaFunctionのコードがCloud9に表示されます。
LambdaFunctionはcloud9--<ファンクション名>-<ランダム文字列>という名称でローンチされます。
Cloud9で作成されたファンクションはCloudFormationによって構築されます。
Cloud9でコードを更新したあと、右ペインでLambdaFunctionを選択し、deployをクリックします。
変更をdeployするとCloudFormationによってアップデートがかかります。
GitHubやCodeCommitのような継続的なコード管理を行わず、Lambdaのdeployや稼働中Lambdaの変更、テストであればこの機能により気軽にデプロイを行う事ができます。
削除
Cloud9単体によるLambdaデプロイはCloudFormationによって構築されます。
LambdaFunctionを消す場合には直接Lambdaを消すのでは無くCloudFormationの削除を行います。
Cloud9 とCodeStarによるLambda開発
Cloud9単体では、コード管理の無いLambda開発を行う事ができます。
CodeStarを利用する事で、ブランチを切りながらLambda開発を行う事が出来るようになります。
CodeStarの初期設定
CodeStar ダッシュボードを開き「プロジェクトを開始する」をクリックします。
作成するプロジェクトタイプ、バックエンド、使用言語からテンプレートを選択します。
プロジェクト名を入力します。
レポジトリには今回はGitHubではなく、CodeCommitを選択します。
CodeStarによってCodePipeline, CodeCommit, CodeBuild, CloudFormation, CloudWatch が自動的に構成されます。
コードの編集方法にはCloud9を利用するためここではスキップします。
※CodeStarローンチ時に既にCloud9があったアメリカリージョンでは自動接続ができますが、2019年8月31日時点では東京リージョンでは自動接続機能がありません。
プロジェクト設定完了後、しばらく待つとプトジェクトが作成されます。
Cloud9の接続設定
Cloud9のターミナルからコマンドを実行します。
投入するコマンドは以下の通りです。
Codeを編集したのが誰かわかるようにGitコマンドでユーザ情報を設定します。
git config --global user.name <ユーザー名>
git config --global user.email ＜メールアドレス＞
続いて、Cloud9を利用しているIAMユーザーの権限でCodeCommitに接続出来るように認証情報ヘルパーの設定を行います。
git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true
CodeCommitの設定
CodeStarのコードからCodeCommitに移動します。
CodeCommitを開いたら、「接続のステップ」を選択します。
リポジトリのクローンコマンドが表示されるので、コピーボタンをクリックします。
コピーしたコマンドをCloud9のコンソールで実行します。
CodeCommit上のソースがCloud9にクローンされました。
あとは、Cloud9上でコードを編集し、gitコマンドでpushすることで、CodeCommitが更新され、CodePipelineによって、自動的にビルド、デプロイが行われます。
CodeStarを利用する事で、コードの世代管理、ブランチ管理を行いながらあLambda開発を行う事ができるようになります。
削除
CodeStarにより構築されたリソースはCodeStarを削除すれば一緒に削除することができます。
まとめ
Cloud9のLambdaデプロイ機能で単体試験等を行い
CodeStar連携機能で本番デプロイを行うような使い方が良いのではないでしょうか。
なお、Cloud9に自動設定されている認証情報は同一アカウント内のCodeCommitにしか接続することができません。
クロスアカウントのCodeCommitに接続する場合には自動接続設定では無く
通常のLinuxサーバとして、認証情報を記載する必要があります。
Cloud9で自動接続設定以外のクレデンシャル情報を設定する場合にはPreferencesのAWS CredentialsでAWS Managed temporary credentialsを無効化します。
AWS Managed temporary credentialsを無効化すると/home/ec2-user/.aws/credentialsファイルが削除されるので、新たに/home/ec2-user/.aws/credentialsファイルを作成して以下の内容を入力します。
[default]
aws_access_key_id = <IAMアクセスキー>
aws_secret_access_key = <IAMシークレットアクセスキー>
[アカウント名もしくはアカウントNo]
role_arn = arn:aws:iam::<CodeCommitが存在するアカウントID>:role/<割り当てられたIAMロール>
mfa_serial = arn:aws:iam::<IAMUserが存在するアカウントID>:mfa/<IAMユーザ名>
source_profile = default
MFA設定がされていない場合は、mfa_serial行は不要です。