本文说明了如何基于docker image, 给openwhisk action创建更复杂的runtime 环境。并描述了其步骤和一些注意事项, 以及现有的一些限制。
1 创建和调用 Docker actions
Openwhisk支持创建基于自定义的Docker image来作为Action的runtime, 利用这个特性我们就可以创建自己的docker image runtime来支持tensorflow相关的action的运行。自定义的image runtime可以是把源代码打包进去, 也可以在初始化时平台自动注入代码。使用自定义的运行时环境, 是针对需要较大的外部依赖的项目的标准解决方案, 例如tensorflow运行时或其它机器学习环境的支持。 (这也部分时因为action size在48M以内的限制)。
1.1 例子
OpenWhisk CLI 有一个 --docker 的选项来配置自定义的Docker运行时环境。语法如下:
wsk action create <ACTION_NAME> --docker <IMAGE> source.js
ps : 必须是在 Docker Hub. 上的一个公开镜像.
–docker 也可以不添加额外的代码来生成action, 例如:
wsk action create <ACTION_NAME> --docker <IMAGE>
在这种场景中，action的源代码可以在openwhisk冷启动运行时环境时注入。 容器运行时环境会直接处理平台的调用请求。
1.2 限制说明
自定义的镜像运行时必须实现 Action interface. 这是根据 交互协议 来传递调用请求到运行时环境。容器用暴露HTTP服务(8080)的方式, 分 /init 和 /run 两段运行。
自定义的容器运行时环境必须在 Docker Hub上可用。Docker Hub 目前时唯一支持的 registry。这意味着所有的openwhisk自定义docker运行时环境必须是公开的。
自定义的镜像运行时环境第一次运行时会从Docker Hub拉取到本地平台。这会导致第一次冷启动调用时耗时比较长。但拉下来以后就会在本地有缓存了。
1.3 镜像更新逻辑
自定义的runtime用tag来标记版本。当一个docker image的tag是“latest”(或者不带tag)时, 从自定义镜像创建一个新的runtime, 总是会registry去检查一下有没有最新版本。由于拉取一个image可能因为网络不稳定或者Docker Hub挂掉而不成功, 所以最好不要这么做, 而是精确指定的tag版本。这样本地系统会直接使用本地缓存, 加快了速度和稳定性。
所以latest标签最好只用在做快速原型时使用, 这时候获取最新代码比运行时稳定性更重要, 其它情况都使用确定版本。
1.4 已有镜像
openwhisk在Docker bub上发布了其所有运行时镜像 。很容易从这些镜像开始扩展，再加入其它的依赖包和外部依赖。从而生成新docker image runtime。以下是一些常用的镜像:
openwhisk/action-nodejs-v10 - Node.js 10 (Source)
openwhisk/python3action - Python 3 (Source)
openwhisk/java8action - Java 8 (Source)
openwhisk/action-swift-v4.2 - Swift 4.2 (Source)
openwhisk/action-php-v7.3 - PHP 7.3 (Source)
openwhisk/action-ruby-v2.5 - Ruby 2.5 (Source)
**
2 扩展已有的镜像
如果你想在action中使用外部依赖, 而外部依赖又因为action的大小限制不能被部署, 这时可以考虑扩展一个新的镜像运行时来解决这个问题。一般从一个已存在的语言运行时镜像(这样容器会已经被配置好能接收平台关于这个语言的调用请求)开始, 再安装扩展包和其它依赖包就好了。
以下是一些例子, 包括Nodejs和Python的自定义运行时:
2.1 Node.js的例子
Tensorflow.js 是一个 JavaScript 实现的 TensorFlow。它包括了一个 Node.js 后端驱动 来在Node.js运行环境上使用CPU或者GPU设备。
Node.js的tensorflow的核心依赖和CPU驱动(tfjs和tfjs-node)都可以NPM来安装, 然而由于openwhisk action大小的限制, 我们不能直接通过zip包来部署tfjs和tfjs-node到oopenwhisk的Node.js runtime上(单单是tfjs-node包就已经超过了170MB)。我们要创建一个直接包含tfjs和tfjs-node的Node.js runtime来支持action的运行。我们可以通过扩展标准Node.js runtime image 并运行 npm install 来把这些依赖预安装到自定义的runtime image上。
步骤如下:
创建 Dockerfile
FROM openwhisk/action-nodejs-v10:latest
RUN npm install @tensorflow/tfjs-node
打包镜像
docker build -t action-nodejs-v10:tf-js .
加上tag
docker tag action-nodejs-v10:tf-js <USER_NAME>/action-nodejs-v10:tf-js
推送到 Docker Hub
docker push <USER_NAME>/action-nodejs-v10:tf-js
创建action
const tf = require('@tensorflow/tfjs-node')
const main = () => {
return { tf: tf.version }
}
wsk action create tfjs --docker <USER_NAME>/action-nodejs-v10:tf-js action.js
测试调用并返回TensorFlow.js依赖的版本号
wsk action invoke tfjs --result
{
"tf": {
"tfjs": "1.0.4",
"tfjs-converter": "1.0.4",
"tfjs-core": "1.0.4",
"tfjs-data": "1.0.4",
"tfjs-layers": "1.0.4",
"tfjs-node": "1.0.3"
}
}
2.2 Python的例子
由于类似很多 numpy 这样的好用的包存在, python已经成为机器学习领域最流行的语言。openwhisk上也支持了python。Python的依赖同样可以通过部署zip包的方式来安装到openwhisk上(方法), 然而超过48MB的action就不能这么干了。我们同样可以通过扩展 Python runtime image并运行 pip install安装依赖包来创建新的运行时镜像。
步骤如下:
创建 Dockerfile
FROM openwhisk/python3action:latest
RUN apk add --update py-pip
RUN pip install numpy
打包镜像
docker build -t python3action:ml-libs .
加上tag
docker tag python3action:ml-libs <USER_NAME>/python3action:ml-libs
推送到Docker Hub
docker push <USER_NAME>/python3action:ml-libs
创建action
import numpy
def main(params):
return {
"numpy": numpy.__version__
}
wsk action create ml-libs --docker <USER_NAME>/python3action:ml-libs action.py
测试调用并返回numpy的版本号
wsk action invoke ml-libs --result
{
"numpy": "1.16.2"
}
以上就是创建自定义的docker image作为action的runtime的例子。
