开源软件与边缘计算、云计算打造 Serverless 物联网系统

互联网的扩散大大增加了网络边缘产生的数据量。 如包括传感器数据、由设备和网关产生的事件,诸如照相机图像的多媒体文件。虽然有许多方法可以构建,用于跨云计算和边缘计算的数据处理的定制解决方案,但标准化的可编程平台将是有益的。它将使开发、部署和操作定制数据管道变得容易,应当优先选用 新兴的 “Serverless” 事件驱动范式,最好是开源。

在这篇文章中,我们将 LEON - 一个使用 Apache OpenWhisk、Node-RED 和 Docker 构建的 Serverless 系统研究原型,它们可以在云计算和边缘计算使用相同的处理元素(OpenWhisk action),Node-RED 用于在它们之间连接数据源。

LEON:使用 Docker 和 Node-RED 本地执行 OpenWhisk 操作

我们演示了 LEON 在人脸检测的一个例子上,将大部分处理分解——在边缘设备上,在传入图像中找到脸部矩形。同时在云端,存储图像用脸部知识库用于确定图像中捕获的人物的身份。

使用 OpenWhisk 流扫描云和边缘进行面部检测,采用 Node-RED 编排

让我们更详细了解一下怎么玩吧。

使用 OpenWhisk 和 Node-RED 进行面部检测

Node-RED 能够通过在云端进行一系列动作(例如,在 Bluemix 中)将 OpenWhisk 操作(action)调用到流中,并将传递流中的来自/转出到其他节点的 JSON 输入和输出。 在脸部检测示例中,流可能如下所示:

用于面部检测的 Node-RED 流作为一系列 OpenWhisk 操作实现

流由 Node-RED 触发,监测 “images” 目录中的新文件。然后我们使用流行的 opencv 库检测脸部矩形,并使用 Bluemix 中的 Watson Visual Recognition 服务确定人的身份。最后,我们通过保持面部图像、加上名称标签(如上图所示)可视化结果。结果(原始图像和增强图像)都显示在自定义的 Node-RED 仪表板(Dashboard)页面上。

这 3 个操作(action)使用 Node.js 实现,每个大约有 50 行代码。

OpenWhisk 操作,包括脸部检测流程

请注意,由于最终识别和标识发生在云端,所以边缘的逻辑不一定是 100% 准确的,因为使用流行的 opencv 库与标准脸分类器(有一些假阳性)应该是足够的。

到目前为止,我们还没有做任何新的事情。您可以在 Raspberry Pi 上运行 Node-RED,并使上述流程在您的 IoT 环境和 Bluemix 之间运行。然而,这意味着每一个新的图像必须被发送到云端 - 即使脸部只占据原始图像的一小部分,或者甚至没有脸部(想到用于监视人的固定或移动的相机 在建筑物或停车场)。解决方案当然是在 IoT 网关上运行第一个操作(action),然后将脸部矩形发送到云端。

LEON:使用 Docker 和 Node-RED 在本地执行 OpenWhisk 操作

在之前的博客中,我们探讨了在边缘设备上运行 OpenWhisk 操作的构建块(building blocks),并且以规模(scale)管理其生命周期(1,2)。现在我们再增加一块拼图。这里是 LEON - 使用 Docker 和 Node-RED 在本地无缝协调 OpenWhisk 操作容器的技术。从用户的角度来看,它只是 Node-RED 节点的扩展版本,允许运行 OpenWhisk 操作。但是现在用户在操作(action)节点配置 - 运行系统中有一个额外的选项。它可能是云中的常规 OpenWhisk 服务,或指向 Docker 引擎的本地运行时(目前由于网络连接的原因,它必须与承载Node-RED容器本身的相同)。在这两种情况下,云中的 OpenWhisk 服务都用作集中的操作存储库。

LEON 添加了将 Node-RED 中的 OpenWhisk 操作节点配置为在本地运行的选项

在引擎盖下,当这个节点被部署时,有几件事情正在发生:

  1. 从集中式 OpenWhisk 服务检索操作的元数据和代码。
  2. 使用元数据中指定的镜像在本地 Docker 主机上配置容器。
  3. 使用标准的 OpenWhisk 内部接口将操作代码注入到容器中。
  4. 传入和传出链接将自动路由到操作容器,根据 Node-RED 流传递 JSON 输入和 JSON 输出。

脸部识别的代码和元数据

请注意,为了减轻云与本地环境之间的潜在差异(例如,x86与基于ARM的HW),LEON 假定 “base” 镜像在本地的 Docker 引擎上存在,由此部署者决定是否“只需从 Docker Hub 中拉出标准的 OpenWhisk 镜像,或者构建/使用适合本地部署的等效镜像(例如,利用 resin.io 镜像)。基本镜像的简单设置将如下所示:

$ docker pull openwhisk/nodejs6action
$ docker tag openwhisk/nodejs6action nodejs6action
$ docker pull openwhisk/pythonaction
$ docker tag openwhisk/pythonaction pythonaction

其次,为了将架构相关的库(例如 OpenCV) 从操作代码本身中分离出来,我们需要创建指定镜像的动作(包括必需的库,遵循 “黑盒” 符号)和操作代码(本地的 Node.js)。 WSK CLI 目前不支持此功能,因此我们可以直接使用 REST API:

#!/bin/sh
ACTION=facedet
ZIP=$ACTION.zip
IMAGE=glikson/nodejs6opencvaction
base64 $ZIP --wrap=0 | echo "\"$(cat)\"" | jq "{namespace:\"_\", name:\"$ACTION\", exec:{kind:\"blackbox\", image:\"$IMAGE\", code:., binary:true, main:\"main\"}}" | curl -X PUT -H "Content-Type:application/json" -H Authorization:Basic\ $(wsk property get --auth | awk '{print $3}' | base64 --wrap=0) -d @- https://openwhisk.ng.bluemix.net/api/v1/namespaces/_/actions/$ACTION?overwrite=true

以下是用于镜像的 Dockerfile:

FROM openwhisk/nodejs6action
RUN apt-get update && apt-get install -y libopencv-dev
RUN npm install -g opencv --unsafe

此外,请注意,操作容器基本上是长时间运行的,为每个传入事件提供/运行 REST 请求(由操作代理处理)。与云中的 OpenWhisk 不同,现在 LEON 不会抢占本地操作容器,更喜欢简单和低于弹性的执行延迟。这种方法在相对较小和静态的环境中是有意义的,例如 IoT 网关执行特定的一组任务。但是,我们计划在未来探索不同的方法。

最后,虽然这样的管道是相当强大的,但事实上,序列中的动作之间的状态只能通过 JSON 有效载荷来传递是有限制的。 在“本地” 的 Node-RED 函数节点中,可以维护全局变量,可以从多个函数节点访问并且跨调用持续。OpenWhisk 也可以实现类似的机制。

This it! 遵循这种方法并使用 LEON,可以轻松地构建跨云端和边缘计算的应用程序,利用 OpenWhisk,Docker 和Node-RED - 所有开放源代码。

请随时在 http://github.com/kpavel/leon-openwhisk-local/ 上试用,并分享您的印象和想法。

原文链接:https://medium.com/openwhisk/serverless-edge-to-cloud-computing-the-open-source-way-28ea33f60bf6

尚未评分
您的评分将帮助我们做出更好的玩法

观光\评论区

Copyright © 2017 玩点什么. All Rights Reserved.