dotnetcorephp技巧_玩转 serverless devs 的三种支配办法

文章目录 [+]

serverless-devs 是一个开源的 Serverless 运用全生命周期管理工具。

笔者作为一名 Serverless 运用开拓者，对海内的阿里云FC，腾讯云SCF都有一定的理解。
接下来我将在此文中先容: 如何利用这个工具，来把同一个运用，通过不同的办法，支配到阿里云函数打算中。

dotnetcorephp技巧_玩转 serverless devs 的三种支配办法

文章中利用的示例项目为一个 nestjs 运用，运行环境为 nodejs，源代码见附录。
这三种支配办法，由于支配目标平台都为阿里云，统一利用阿里云函数打算（FC）组件。

（图片来自网络侵删）

预置 Runtime 支配

这个支配办法是最大略直接的，如果你只是想搭建一个大略的 web service 或者处理做一些 batch job，不须要依赖一些额外的系统库或者软件，每每利用这个办法支配就够了。
紧张的 yml 配置也很大略:

function:runtime:nodejs14#运行环境handler:index.handler#函数入口

这种办法最大的特点，便是 runtime 须要从预置的列举值中配置一个详细值，比如 nodejs12,nodejs14,python2.7,python3,java8,java11,php7.2,dotnetcore2.1 等等。
一旦你指定了详细的运行时，那么函数动态扩容伸缩所利用的镜像就已经确定了下来。
接下来便是把你的代码放入镜像创建容器中，去实行了。
此时就须要 codeUri 和 handler 这些配置项了，用它们来指定，实行代码入口。

同时除了对外暴露的 handler 中的代码会被实行外，在函数实例的生命周期中，也存在着一些回调方法。
就以 initialize 这个回调方法名为例，我们在函数配置中设置函数的 Initializer 回调程序为 index.initialize ，那么 exports.initialize 这个方法会在实例初始化时被实行，其他生命周期亦然。

Custom Runtime 支配

自定义运行环境支配，与预置 Runtime 支配办法，最大的特点便是可自定义措辞和运行时了。

我们为啥须要这种支配办法？当然是由于预置的 Runtime 不足用了。
通过这种办法，我们可以自定义运行时的措辞和版本。
比如利用 rust 和 nodejs2048。
而它紧张的 yml 配置也很大略:

function:runtime:custom#运行环境(从预置的列举值中选一个)caPort:9000customRuntimeConfig:#不用这个就用bootstrap文件，示例见附录command:-/code/node-v16.15.0-linux-x64/bin/nodeargs:-'dist/main.js'

个中 customRuntimeConfig 中声明了启动命令和参数，直接实行便可。

须要把稳的是，这种支配办法，须要你上传运行环境的解析器/运行时，再和你的代码文件，一起打包支配到函数打算。
这每每很大，比如我下载的 node-v16.15.0-linux-x64 解压后足足有 100M，以是可以找一种办法来复用运行时的包来加快你的支配速率。

Custom Runtime 支配这种办法，哀求你的代码是一个 HTTP Server 并监听指定的 caPort 端口。
而且你的函数实例生命周期回调也是由 HTTP Server 中指定路由来完成的,比如 /initialize, /pre-freeze,/pre-stop 这类。

总的来说，它比起预置 Runtime 支配有了更多的可操作性，比较来说它的速率也差一些，毕竟代码包的体积变大了，每次都要下载解压，这个速率肯定是慢一点的。
以是灵巧的代价无非便是性能差一点，我们在选择支配办法的时候也要根据情形，推敲损益。

Custom Container 支配

刚刚我们已经通过 Custom Runtime 支配来自定义代码的运行时了，但是纵然通过那种办法，我们也无法改变代码运行的容器环境。
比如我有一段代码，只有在 Windows 的 IIS 上才能运行，怎么办? 显然 Custom Runtime 支配固定的容器环境，是不知足我们的需求的。

这时候我们就须要在本地，构建我们自己的容器镜像，并把它推送到阿里云的镜像仓库里去。
以是启用 Custom Container 支配，最主要的先决条件是什么？

安装 docker 并开通阿里云容器镜像做事

它对应的 serverless-devs 也非常大略：

function:caPort:9000runtime:custom-containercustomContainerConfig:image:registry.cn-hangzhou.aliyuncs.com/som-custom-container/nest-appactions:pre-deploy:#在支配前实行，在你确当地构建镜像，以是须要你已经安装好了docker-component:fcbuild--use-docker--dockerfile./code/Dockerfile

customContainerConfig#image 便是你的镜像仓库的地址(我示例中用的公网地址，最佳实践为函数打算同地域的VPC镜像地址)，复制粘贴即可。

fc build --use-docker --dockerfile ./code/Dockerfile 这个命令，你可以理解成一堆 docker 构建发布的命令脚本。

而 Dockerfile 便是构建镜像的核心了，在这里我们可以任意的配置我们的系统环境。
比如我们要转化操作图集变成pdf文件，则预先安装好 ghostscript。

我们要在 nodejs runtime 中构建类似 Canvas 实现，额外安装 build-essential libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev librsvg2-dev.....

这里给出一个 Dockerfile 示例参考:

FROMnode:18-alpineRUNmkdir-p/usr/src/botWORKDIR/usr/src/botCOPYpackage.jsonyarn.lock/usr/src/bot/#注册alpinelinux镜像地址,防止下载过慢RUNsed-i's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g'/etc/apk/repositories\&&apkadd--no-cache\build-base\g++\cairo-dev\jpeg-dev\pango-dev\giflib-dev\&&apkadd--update--repositoryhttp://dl-3.alpinelinux.org/alpine/edge/testing\libmount\ttf-dejavu\ttf-droid\ttf-freefont\ttf-liberation\fontconfig\&&yarn--prodCOPY./src/usr/src/bot/srcEXPOSE9000ENTRYPOINT["yarn","start"]

这种支配办法最灵巧，能做到很多上述2个支配办法做不到的事情，但是它的冷启动速率也是最慢的。
缘故原由在于，容器镜像依赖的根本环境和运用很随意马虎臃肿，这带来了额外的数据下载和解压的韶光。
以是这种支配办法上生产环境，每每很多方法来赞助，比如镜像启动加速，预留实例和单实例多并发等等功能，同时自己在构建时也要做一定的优化，详见冷启动优化最佳实践

结论

灵巧性(从低到高)

单措辞&普通的 CRUD -> 预置 Runtime 支配

自定义措辞or运行版本 -> Custom Runtime 支配

自定义容器环境 -> Custom Container 支配

冷启动速率(从慢到快)/优化本钱(从高到低)

Custom Container

Custom Runtime

预置 Runtime 支配

扩展阅读(友商比拟)

前面紧张讲了，利用 serverless devs 的支配的三种办法。

现在，让我们先回到预置 Nodejs Runtime 支配这种办法，在支配时，开拓者们该当都把稳过。
我们在传统 web 框架支配到 FC 时，须要安装一个额外包: @serverless-devs/fc-http 来包裹我们的框架实例。
这个包是干啥用的呢？