🎅 📷 👩🏻‍🚒 AWSサーバーレスアプリケーションフレームワーク 🕴🏻 😦 😙

AWSでサーバーレスWebアプリケーション用の小さなフレームワークを作成することにしました。これをフレームワークではなくワークと呼ぶ方が正しいかもしれません-私は知りません。ただし、ポイントは、AWSでサーバーレスアプリケーションを迅速に開発するための基盤を作成することです。コードはGitHubに投稿されており、多くの改良点があります。

この記事では、サーバーレスアプリケーションをローカルで開発およびテストする方法、フロントエンドおよびバックエンドルーティング、Amazonサービスなどに焦点を当てます。誰も気にしない、猫へようこそ！

序文のようなもの

最近まで、サーバーレスアプリケーションの開発は、ラムダ関数とAPIの完全なローカルテストの手段がなかったため、非常に複雑でした。アプリケーションを作成するときは、ブラウザでコードを編集して常にオンラインで作業するか、ラムダ関数のソースコードを常にクラウドにアーカイブしてアップロードする必要がありました。

2017年の夏に突破口がありました。 AWSは、サーバーレスアプリケーションモデル（SAM）と呼ばれる新しい単純化されたCloudFormationテンプレート標準を作成し、同時にsam-localプロジェクトを開始しました。まず最初に。

Amazon CloudFormationは、JSONまたはYAMLテンプレートファイルを使用して、アプリケーションに必要なすべてのAWSインフラストラクチャを記述することができるサービスです。これは非常に便利なことです。それがないと、Webコンソールまたはコマンドインターフェイスを介して手動で必要な多くのリソースを手動で作成する必要があります：ラムダ関数、データベース、API、ロール、およびポリシー...

CloudFormationを使用すると、特別なデザイナーでインフラストラクチャを描画するか、テンプレートに手でインフラストラクチャを書き込むことができます。いずれにせよ、結果はテンプレートファイルになります。テンプレートファイルを使用すると、数回のクリックで、または1つのコマンドで、アプリケーションに必要なすべてのものを引き続き作成できます。そして、必要に応じて、このテンプレートを変更し、1つのコマンドで再度適用します。これにより、アプリケーションインフラストラクチャのサポートがはるかに簡単になります。インフラストラクチャはコードのようです。

CloudFormationは美しく、そのテンプレートを使用すると、AWSリソースのほぼ100％を記述することができます。しかし、汎用性があるため、これはかなり「冗長な」形式です。テンプレートはすぐに適切なサイズに成長できます。これを認識し、サーバーレスアプリケーションの開発を容易にすることを目指して、AWSは新しいSAM形式を作成しました。

条件付きで、通常のCloudFormationテンプレートは低レベル言語で記述されていると想定できます。また、SAMテンプレートは高水準言語であるため、簡素化された構文を使用してサーバーレスアプリケーションのインフラストラクチャを記述することができます。 SAMテンプレートは、デプロイ時にCloudFrontによって通常のテンプレートに変換されます。

sam-localとは何ですか？これは、SAMテンプレートで記述されたサーバーレスアプリケーションをローカルで操作できるコマンドラインツールです。 Sam-localを使用すると、ラムダ関数をテストしたり、さまざまなAWSサービスからイベントを生成したり、ゲートウェイAPIを実行したり、SAMテンプレートをチェックしたりできます。

Sam-localは、Dockerコンテナーを使用して、GatewayおよびLambda APIをエミュレートします。動作原理は次のとおりです。起動すると、sam-localはプロジェクトフォルダーでSAMテンプレートファイルを探します。テンプレートファイルを分析し、Dockerコンテナ内のテンプレートに割り当てられたリソースを起動します。APIを開き、ラムダ関数をそれらに接続します。さらに、サポートは実際のラムダ関数の動作に非常に近いです（制限、使用されるメモリの量、および実行時間を示しています）。

こんな感じ

Georgiy@Baltimore MINGW64 /h/dropbox/projects/aberp/lambda (master) $ sam local start-api --docker-volume-basedir /h/Dropbox/Projects/aberp/lambda "aberp" ←[34mINFO←[0m[0000] Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows 2018/04/04 22:33:49 Connected to Docker 1.35 ←[34mINFO←[0m[0001] Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows 2018/04/04 22:33:50 Fetching lambci/lambda:nodejs6.10 image for nodejs6.10 runtime... nodejs6.10: Pulling from lambci/lambda ←[1B06c3813f: Already exists ←[1B967675e1: Already exists ←[1Bdaa0d714: Pulling fs layer ←[1BDigest: sha256:56205b1ec69e0fa6c32e9658d94ef6f3f5ec08b2d60876deefcbbd72fc8cb12f52kB/2.052kBB Status: Downloaded newer image for lambci/lambda:nodejs6.10 ←[32;1mMounting index.handler (nodejs6.10) at http://127.0.0.1:3000/{proxy+} [OPTIONS GET HEAD POST PUT DELETE PATCH]←[0 m You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions, changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template.

次に、ローカルAPIにアクセスし、対応するラムダ関数を呼び出すことは、ラムダ関数がCloudWatchログに情報を表示するのと同じ方法でコンソールに表示されます。

 2018/04/04 22:36:06 Invoking index.handler (nodejs6.10) 2018/04/04 22:36:06 Mounting /h/Dropbox/Projects/aberp/lambda as /var/task:ro inside runtime container ←[32mSTART RequestId: 9fee783c-285c-127d-b5b5-491bff5d4df5 Version: $LATEST←[0m ←[32mEND RequestId: 9fee783c-285c-127d-b5b5-491bff5d4df5←[0m ←[32mREPORT RequestId: 9fee783c-285c-127d-b5b5-491bff5d4df5 Duration: 476.26 ms Billed Duration: 500 ms Memory S ize: 128 MB Max Memory Used: 37 MB ←[0m

Sam-localはまだパブリックベータステータスですが、非常に安定して動作しているように思えました。

一般に、これらすべてにより、ローカルコンピューターでサーバーレスアプリケーションを作成することができます。これは、従来のWebアプリケーションを作成するよりも複雑ではありません。

言及するしかありません。 Sam-localには類似点があります-Serverless frameworkです。サーバーレスフレームワークは非常に人気があります。これは、主に以前に代替手段がなかったためです。私はそれを使用した経験はあまりありませんが、私が知る限り、sam-localのような完全なローカル環境を提供していません。 Sam-localはAWS自体で開発されており、別の愛好家チームがサーバーレスフレームワークを作成しています。ただし、サーバーレスフレームワークを支持することで、特定のベンダーへのアプリケーションの接続を減らすことができるという事実に起因する可能性があります。

フレームワークについて

すでに書いたように、新しいサーバーレスアプリケーションを作成するときにクイックスタートを提供するために必要です。現時点では、Webトークンの承認のみをサポートしています。さらに、エラー処理の追加、フォームの操作、表形式データの出力、展開メカニズムの構成を計画しています。一般に、将来的にAB-ERPリポジトリのクローンを作成し、アプリケーションの作業をすぐに開始できるようにします。

ERPシステムを作成するため、他の製品の名前AB-TASKSおよびAB-DOCとの類推によりAB-ERPと呼びました。同時に、ERPシステムの作成にはAB-ERPは必要ありません;それに基づいて、サーバーレスWebアプリケーションを作成できます。

アプリケーションには、フロントエンドコードとバックエンドコードがあります。したがって、プロジェクトルートには2つのフォルダーがあります： lambda （バックエンド）とpublic （フロントエンド）：

 +---lambda | +---api | +---core \---public +---css | \---core +---img +---js | \---core \---views

AB-ERPは、1ページのWebアプリケーション（SPA）の原則に基づいて動作します。アプリケーションをデプロイする場合、フロントエンドコードをAWS S3に配置し、その前にCloudFrontを構成する必要があります。これは、以前の AB-DOC に関する記事の「開発と展開」セクションで説明されていました。

デプロイ中のバックエンドコードはAWS Lambdaにアップロードされます。

AB-ERPはMariaDBをデータベースとして使用します。 MariaDBはAWS RDSにデプロイされます。必要に応じて、たとえばAWS DynamoDBと連携するようにAB-ERPを再構成できます。

ユーザーファイルはAWS S3に保存されます。

これは、アプリケーションアーキテクチャの外観です。

バックエンド

現時点では、すべてが非常にシンプルです。 1つのゲートウェイAPIリソースと1つのラムダ関数のみ。

SAMテンプレートは次のようになります。

 AWSTemplateFormatVersion : '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: An example RESTful service Resources: ABLambdaRouter: Type: AWS::Serverless::Function Properties: Runtime: nodejs6.10 Handler: index.handler Events: ABAPI: Type: Api Properties: Path: /{proxy+} Method: any

SAMテンプレートには、ラムダ関数であるABLambdaRouterのリソースの1つがあります。 ABLambdaRouterは、APIからの1つのABAPIイベントによってのみ呼び出されます。

API Gatewayリソースは、任意のメソッド（ ANY ）によるURL / {proxy +}のパスへのリクエストを受け入れます。つまり、言い換えれば、通常の双方向プロキシとして機能します。 Lambda関数はそれぞれ、リクエストに応じて異なるコードを実行するルーターの役割を引き受ける必要があります。

Lambda関数コード（ルーター）

 'use strict'; const jwt = require('jsonwebtoken'); //process.env.PROD and other env.vars are set in production only if(process.env.PROD === undefined){ process.env.PROD = 0; process.env.SECRET = 'SOME_SECRET_CODE_672967256'; process.env.DB_HOST = '192.168.1.5'; process.env.DB_NAME = 'ab-erp'; process.env.DB_USER = 'ab-erp'; process.env.DB_PASSWORD = 'ab-erp'; } //core modules const HTTP = require('core/http'); const DB = require('core/db'); //main handler exports.handler = (event, context, callback) => { context.callbackWaitsForEmptyEventLoop = false; let api; const [resource, action] = event.pathParameters['proxy'].split('/'); //OPTIONS requests are proccessed by API GateWay using mock //sam-local can't do it, so for local development we need this if(event.httpMethod === 'OPTIONS'){ return callback(null, HTTP.response()); } //require resource module try { api = require('api/' + resource)(HTTP, DB); } catch(e) { if (e.code === 'MODULE_NOT_FOUND') { return callback(null, HTTP.response(404, {error: 'Resource not found.'})); } return callback(null, HTTP.response(500)); } //call resource action if(api.hasOwnProperty(action)) { if(api[action].protected === 0){ api[action](event, context, callback); } else if (event.headers['X-Access-Token'] !== undefined) { let token = event.headers['X-Access-Token']; try { event.userData = jwt.verify(token, process.env.SECRET); api[action](event, context, callback); } catch(error) { return callback(null, HTTP.response(403, {error: 'Failed to verify token.'})); } } else { return callback(null, HTTP.response(403, {error: 'No token provided.'})); } } else { return callback(null, HTTP.response(404, {error: 'Action not found.'})); } }

APIには2つのレベルの階層があります。最初のレベルはモジュールで、2番目のレベルはアクションです。 URLはapi.app.com/module/actionです。ルーター関数は、着信要求のpathParametersを分析し、目的のモジュールをlambda / apiフォルダーから接続してから、要求をこのモジュール内の目的の関数に転送しようとします。

デフォルトでは、モジュール内の関数は承認を必要とするため、モジュールから関数を呼び出す前に、ルーターはX-Access-Tokenリクエストヘッダー内の有効なトークンをチェックします。トークンが有効な場合、モジュールから関数が呼び出されます;有効でない場合、エラー403が返されます。

多数の個別のGateway APIリソースと多数のラムダ関数を作成する代わりに、なぜこのアプローチを選択したのですか？まず、そして最も重要なことは、構成、展開、およびそのようなアーキテクチャの実際の操作の容易さです。第二に、このアプローチは関数のコールドスタートを最小限に抑えます。実際、関数に長い呼び出しがない場合、AWSはそのコンテナーを削除し、新しい呼び出しはリクエストの処理に時間がかかります。

このアプローチには欠点もあります。さまざまなAPIリソースに対して、API Gatewayレベルで特別な設定を行うことはできません。

誰かが質問があるかもしれませんが、なぜゲートウェイAPIが必要なのですか、ブラウザからラムダに直接アクセスしないのはなぜですか？ Gateway APIには多くの利点があります。 Edge Optimizedモードでは、CDNのように機能し、応答のキャッシュがあり、バックエンドへの呼び出しなしでOPTION要求に応答できます（MOCK統合）。これにより、アプリケーションが大幅に高速化されます。また、DDOS保護と、制限を使用してトラフィックを規制する機能も備えています。また、サードパーティの開発者向けにアプリケーションAPIを開くこともできます。

フロントエンド

フロントエンドでは、React、Vue.js、Angular.jsのような「大きな」フレームワークを使用しないことにしたため、SPAアプリケーション用の小さなルーターを作成しました。

ルーターは各ページの説明を保存します：どのhtmlテンプレートとどのcss、jsファイルが必要か。ページが要求されると、ルーターは必要なすべてのファイルをプレーンテキストでロードし、それらを結合して、アプリケーションインターフェイスのdivコンテナーに挿入します。コンテナに挿入されると、開かれたページのJavaScriptが実行されます。

ルーターコード

 "use strict"; //ROUTER object const ROUTER = { pages: { "index": ["css/index.css", "views/index.html", "js/index.js"], "login": ["css/login.css", "views/login.html", "js/login.js"] }, open: function(page){ let self = this; $container.html(big_preloader_html); if(self.pages.hasOwnProperty(page)){ const parts = self.pages[page]; let getters = []; let wrappers = []; for (let i = 0; i < parts.length; i++) { if( /^.*\.css$/i.test(parts[i]) ){ wrappers.push('style'); } else if ( /^.*\.js$/i.test(parts[i]) ){ wrappers.push('script'); } else { wrappers.push(''); } getters.push( $.get(parts[i], null, null, 'text').promise() ); } Promise.all(getters).then(function(results) { let html = ''; for (let i = 0; i < results.length; i++) { if(wrappers[i] === ''){ html += results[i]; } else { html += `<${wrappers[i]}>${results[i]}</${wrappers[i]}>`; } } self.updatePath(page); $container.html(html); }); } else { //TODO console.log('404'); } }, updatePath: function(newPath){ if(newPath !== window.location.pathname) { history.pushState({}, null, newPath); } } }

環境設定

コンピューターでプロジェクトを開始するために必要なものはすべて、プロジェクトgithubの READMEで手順を説明しようとしました。何かがうまくいかない場合は、コメントを書いてください-私たちは助けようとします。したがって、READMEを補充します。

ローカルテストのために、Node.jsに小さなHTTPサーバーを作成しました。

 const express = require('express'); const app = express(); app.use(express.static('public')); app.use(function(req, res, next) { req.url = 'app.html'; next(); }); app.use(express.static('public')); app.listen(80, () => console.log('Listening..'))

開始する前に、 node abserver.jsコマンドを使用して実行する必要があります。要求が到着すると、 パブリックフォルダー内のファイルを検索し、見つかった場合はそれを提供します。ファイルが見つからない場合は、メインアプリケーションファイルpublic \ app.htmlが提供されます。 SPAアプリケーションが機能するには、これで十分です。本番環境では、Amazon CloudFrontは同じことを行います。

おわりに

AB-ERPはまだ非常に未加工です。提案やコメント、さらに多くのコミットを歓迎します。

現在、承認のみが多かれ少なかれAB-ERPに実装されています。これについては、次のいずれかの記事で説明する予定です。 Gateway APIを使用する際にどのような認証オプションがあり、カスタム認証やCognitoとの統合を実装しなかった理由。

プロジェクトのさらなる開発のためのいくつかの計画。

データアプリケーションの主要なコンポーネントは、出力用のデータとテーブルを入力するためのフォームです。したがって、フォームとテーブルを操作する機能が最初に追加されます。

YAMLテンプレートを使用して、フォームでの作業（ページでのフォームの作成、バックエンドとフロントエンドでの検証、データベースへの保存）を標準化するというアイデアがあります。つまり、YAMLテンプレートでフォームを記述し、フロントエンドとバックエンドで残りのすべての作業を記述できるようにして、AB-ERPコードで行われるようにします。テーブルには、タスクトラッカーAB-TASKSで使用したDatatablesライブラリを使用します。

記事を書くとき、次のツールが役に立ちました。

オンラインチャートサービスdraw.io
ディレクトリツリーを描画するWindowsコマンドラインツリーコマンド

AWSサーバーレスアプリケーションフレームワーク