serverless 构建

by Dmitri Zimine

由Dmitri Zimine

使用Serverless，StepFunctions和StackStorm Exchange构建社区注册应用程序-第3集 (Building a community sign-up app with Serverless, StepFunctions, and StackStorm Exchange — Episode 3)

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 。

翻译自: https://www.freecodecamp.org/news/building-a-community-sign-up-app-with-serverless-stepfunctions-and-stackstorm-exchange-episode-6efb9c102b0a/

serverless 构建