serverless 構建_使用Serverless，StepFunctions和StackStorm Exchange構建社區注冊應用程序-Episode…...

serverless 構建

by Dmitri Zimine

由Dmitri Zimine

Build a real-world serverless application on AWS with Serverless framework and ready-to-use functions from StackStorm Exchange open-source catalog.

使用無服務器框架和StackStorm Exchange開源目錄中的即用型功能，在AWS上構建真實的無服務器應用程序。

Episode One | Episode Two | Episode Three | Episode Four

第一集 | 第二集 | 第三集| 第四集

We are at Episode Three. Quick recap:

我們在第三集。快速回顧：

In Episode One, I described the application we are building, walked you through setting up the development environment and creating a Serverless project, and showed how to build your first Lambda function from a StackStorm Exchange action with Serverless Framework.
在第一集中，我描述了我們正在構建的應用程序，引導您完成了開發環境的創建并創建了無服務器項目，并展示了如何使用無服務器框架通過StackStorm Exchange操作構建第一個Lambda函數。
In Episode Two, we added more actions: one native Lambda to record user info to DynamoDB, and another one from StackStorm Exchange to make a call to ActiveCampaign CRM system. You learned more of serverless.yml syntax and practiced the development workflow with Lambda functions.
在第二集中，我們添加了更多操作：一個本機Lambda將用戶信息記錄到DynamoDB，另一種Lambda從StackStorm Exchange調用ActiveCampaign CRM系統。您了解了更多serverless.yml語法，并使用Lambda函數練習了開發工作流程。

In this third episode, I’ll show how to use AWS StepFunction to wire the actions into a workflow.

在第三集中，我將展示如何使用AWS StepFunction將操作連接到工作流中。

You can get the final code for this episode from GitHub.

您可以從GitHub獲取此劇集的最終代碼。

與StepFunction一起接線功能 (Wiring functions together with StepFunction)

Now that our building blocks — Lambda functions — are all lined up, it’s time to string them together. An AWS StepFunction will define the sequence of calls, maintain the state of the sign-up workflow, and carry the data between the steps. I’ll use theserverless-step-functions plugin from Serverless Champion @horike37, give him a heart:

現在我們的構建塊(Lambda函數)都已對齊，是時候將它們串在一起了。 AWS StepFunction將定義調用順序，維護注冊工作流程的狀態，并在步驟之間傳遞數據。我將使用Serverless Champion @ horike37的serverless serverless-step-functions插件，給他一個心：

Let’s get busy. Install the plugin:

忙吧安裝插件：

npm install --save-dev serverless-step-functions

Add the plugin to the serverless.yml file:

將插件添加到serverless.yml文件：

plugins:  - serverless-plugin-stackstorm  - serverless-step-functions

The Step Function definition will require my accountID. As it is something I want to keep to myself, I add it to env.yml, which now looks like this:

步驟功能定義將需要我的accountID 。因為這是我想保留的東西，所以將其添加到env.yml ，現在看起來像這樣：

# ./env.yml# Don't commit to Github :)

slack:  admin_token: "xoxs-111111111111-..."  organization: "your-team"active_campaign:  url: "https://YOUR-COMPANY.api-us1.com"  api_key: "1234567a9012a12345z12aa2aaa..."private:  accountId: "000000000000"

Go back to serverless.yml and add the following two blocks:

返回serverless.yml并添加以下兩個塊：

# ./serverless.yml......custom:  private: ${file(env.yml):private}  stage: ${opt:stage, self:provider.stage}  region: ${opt:region, self:provider.region}

stepFunctions:  stateMachines:    signup:      events:        - http:            path: signup            method: POST            cors: true      definition: ${file(stepfunction.yml)}

In the custom block, I assigned the private object from the private key in env.yml. I also defined variables for stage and region so that the values are picked from CLI options, if provided, or default to the current AWS settings.

在custom塊中，我從env.yml的private分配了private對象。我還定義了stage和region變量，以便從CLI選項(如果提供)中選擇值，或者默認為當前AWS設置。

The stepFunctions block is here to define - you have already guessed - StepFunctions. Mine is called "signup".

stepFunctions塊在這里定義-您已經猜到了-StepFunctions。我的被??稱為“ signup ”。

The events section here is doing exactly what events sections do in function definitions: it configures an API Gateway endpoint for invoking StepFunction from outside of AWS. We'll use it later to call the back-end from a Web form.

這里的events部分完全執行函數定義中的events部分：它配置了API網關終端節點，以從AWS外部調用StepFunction。稍后我們將使用它從Web表單調用后端。

The definition can be written as YAML right here in serverless.yml, but I prefer to include it from a separate file, keeping the logic separate from the configuration. Here it is:

該definition可以在serverless.yml寫為YAML，但是我更喜歡將其包含在單獨的文件中，以使邏輯與配置分開。這里是：

StepFunction definitions are written in Amazon States Language. The spec is short, well written and worth a read. Using YAML instead of JSON is a nice perk from the plugin — it reads better and allows comments. But if you want JSON — no problem, help yourself.

StepFunction定義使用Amazon States Language編寫。該規范簡短，寫得很好，值得一讀。使用YAML代替JSON是插件的一個不錯的選擇-它讀起來更好，并允許注釋。但是，如果您想要JSON-沒問題，請自助。

Resource refers to Lambda functions by ARN. I used the variables we defined earlier to construct the ARNs matching account ID, region, and stage with the function name: arn:aws:lambda:${self:custom.region}:${self:custom.private.accountId}:function:${self:service}-${self:custom.stage}-RecordDB
Resource是指ARN的Lambda函數。我使用我們先前定義的變量來構造與帳戶ID，區域和階段匹配的ARN，并帶有函數名稱： arn:aws:lambda:${self:custom.region}:${self:custom.private.accountId}:function:${self:service}-${self:custom.stage}-RecordDB
ResultPath is used to pass data between steps. By default, StepFunctions work on a "need-to-know" basis: the step downstream receives only the output from the step directly upstream. If you think it logical, think again: if only RecordDB receives the workflow input, how will RecordAC and InviteSlack get it? RecordDB may just return "200 OK", not email. Changing the code of functions to return their input would make them inappropriately intimate. The trick is to use ResultPath to write the function output under a function-specific key, like ResultPath: $results.RecordDB. This preserves initial workflow input in the step output for downstream Lambda steps, while appending the output of each Lambda. Like this:
ResultPath用于在步驟之間傳遞數據。默認情況下，StepFunctions在“需要了解”的基礎上工作：下游步驟僅接收直接上游步驟的輸出。如果您認為這是合乎邏輯的，請再考慮一下：如果只有RecordDB接收工作流輸入，RecordAC和InviteSlack將如何獲得它？ RecordDB可能只返回“ 200 OK”，而不是email 。更改功能代碼以返回其輸入將使它們不恰當地親密。訣竅是使用ResultPath在特定于函數的鍵下編寫函數輸出，例如ResultPath: $results.RecordDB 。這將在下游Lambda步驟的步驟輸出中保留初始工作流輸入，同時追加每個Lambda的輸出。像這樣：

{  "body": {    "name": "Vasili Terkin",    "email": "dmitri.zimine+terkin@gmail.com",    "first_name": "Vasili",    "last_name": "Terkin"  },  "results": {    "RecordDB": {      "statusCode": 200    },    "RecordAC": ...    ...  }}

To fully grasp it, read the “Input and Output” section in the spec. Ansd entertain youself with a video from “AWS Step Functions Tutorial” by Marcia Villalba.

要完全掌握它，請閱讀規范中的“輸入和輸出”部分。 Ansd提供了Marcia Villalba的 “ AWS Step Functions教程 ”中的視頻來娛樂自己。

PRO TIP: I made the workflow sequential to demonstrate the data passing trick. It is more proper to run all three steps in parallel: it is faster and more resilient: the failure of one step will not prevent the other function invocations. Go ahead change the StepFunctions to parallel.

專家提示：我按順序進行了工作流程，以演示數據傳遞技巧。并行運行所有三個步驟更為合適：它更快且更具彈性：一個步驟的失敗不會阻止其他功能的調用。繼續，將StepFunctions更改為parallel。

That is it. Time to try. Deploy, invoke, check the logs.

這就對了。該嘗試了。部署，調用，檢查日志。

You CURL fans know what to do with the new API Gateway endpoint for our StepFunction. If you forgot the endpoint, sls info to the rescue. I’ll show off again with httpie:

您的CURL粉絲知道如何使用我們的StepFunction的新API Gateway端點。如果您忘記了端點，請向救援人員發送sls info 。我將再次通過httpie炫耀：

# DON'T COPY! Use YOUR ENDPOINT!

http POST https://YOUR.ENDPOINT.amazonaws.com/dev/signup \body:='{"email":"santa@mad.russian.xmas.com", "first_name":"Santa", "last_name": "Claus"}'

Ok, http or curl, either way it returns the StepFunction execution ARN so that we can check on it to see how our StepFunction is being executed. How do we check on it? I’m afraid you gotta open a browser and login to your AWS Console. If you want to use AWS CLI first, fine, don’t say I didn’t show you how:

好的， http或curl ，都可以通過它返回StepFunction執行ARN的方式，以便我們可以對其進行檢查以查看StepFunction的執行方式。我們如何檢查呢？恐怕您必須打開瀏覽器并登錄到AWS控制臺。如果您想首先使用AWS CLI，請不要說我沒有向您展示如何：

aws stepfunctions describe-execution --execution-arn arn:aws:states:us-east-1:00000000000:execution:SignupStepFunctionsStateMac-seo9CrijATLU:cbeda709-e530-11e7-86d3-49cbe4261318 --output json{    "status": "FAILED",     "startDate": 1513738340.18,     "name": "cbeda709-e530-11e7-86d3-49cbe4261318",     "executionArn": "arn:aws:states:us-east-1:00000000000:execution:SignupStepFunctionsStateMac-seo9CrijATLU:cbeda709-e530-11e7-86d3-49cbe4261318",     "stateMachineArn": "arn:aws:states:us-east-1:00000000000:stateMachine:SignupStepFunctionsStateMac-seo9CrijATLU",     "stopDate": 1513738370.481,     "input": "{\"body\":{\"email\":\"santa@mad.russian.xmas.com\",\"first_name\":\"Santa\",\"last_name\":\"Claus\"}}"}

This is the output for an execution that failed because the RecordAC function timed out. Can you infer this from the output? The only valuable info here is FAILED. No kidding! I must say AWS don't give StepFunction the love it deserves. Not in CLI. If you think I missed something, check the CLI docs, find it and tell me.

這是執行失敗的結果，因為RecordAC函數超時。您可以從輸出中推斷出來嗎？唯一有價值的信息是FAILED 。別開玩笑了！我必須說AWS不會給StepFunction它應有的愛。不在CLI中。如果您認為我錯過了什么，請查看CLI文檔，找到并告訴我。

The most irritating part is that the CLI doesn’t tell me which step failed. They make me call the logs on every Lambda, one by one. Luckily I only have 3 functions, what if there were more?

最令人煩惱的部分是CLI不會告訴我哪一步失敗了。他們讓我逐一調用每個Lambda上的日志。幸運的是，我只有3個功能，如果還有更多功能呢？

Or, open a browser and hop on AWS Console.

或者，打開瀏覽器并跳至AWS Console。

Even there, debugging some Lambda failures, like timeouts, is tricky. StepFunction execution “Exception” report says "The cause could not be determined because Lambda did not return an error type."Go to the lambda logs to see what happened there.

即使在那兒，調試一些Lambda故障(例如超時)也很棘手。 StepFunction執行“異常”報告顯示"The cause could not be determined because Lambda did not return an error type." 轉到lambda日志以查看發生了什么。

There I find the line which I wish I saw in the StepFunction exception:

在那找到了希望在StepFunction異常中看到的行：

2017-12-20T04:21:44.298Z 4230a73b-e53d-11e7-be6b-bff82b9b3572 Task timed out after 6.00 seconds

PRO TIP: For debugging, invoke the StepFunction with sls invoke stepf: it creates the execution, waits for completion, and prints the output to the terminal. Three AWS CLI commands in one.

專業提示：要進行調試，請使用sls invoke stepf ：它創建執行，等待完成，然后將輸出打印到終端。包含三個AWS CLI命令。

sls invoke stepf --name signup \--data  '{"body": {"email":"santa@mad.russian.xmas.com", "first_name":"Santa", "last_name": "Clause"}}'

Your StepFunction executions may work just fine — we already adjusted the timeouts. I took you on this debugging detour for a taste of StepFunction troubleshooting, admittedly a bit bitter. On the sweet side, once debugged, StepFunctions run reliably like Toyota cars.

您的StepFunction執行可能工作得很好-我們已經調整了超時。我帶著您繞過了這個調試彎路，以品嘗一下StepFunction的故障排除功能，雖然有點苦。從好的方面說，一旦調試，StepFunctions就可以像豐田汽車一樣可靠地運行。

As a back-end developer, I am tempted to call it done here. But to make it a “complete example” we need one more thing. The Web front-end.

作為后端開發人員，我很想在這里稱呼它。但是要使其成為“完整的例子”，我們還需要做一件事。 Web前端。

Let’s call it a day and save the web part and conclusions for the next and final episode.

讓我們稱之為一天，保存下一部分和最后一集的網絡部分和結論。

Episode 4: Adding Web Front-end, Reflection and Summary

第4集 ：添加Web前端，反射和摘要

Hope this helped you learn something new, find something interesting, or provoked some good thoughts. Please share your thoughts in the comments here, or tweet me @dzimine.

希望這可以幫助您學習新知識，發現有趣事物或激發一些好的想法。請在此處的評論中分享您的想法，或在推特上給我@dzimine 。