标签：镜像 函数 之五 watchdog OpenFaaS netes faas

9. 终篇，自制模板(springboot+maven+jdk8)

本篇概览

• 作为《OpenFaaS实战》系列的第五篇，咱们需要一起面对OpenFaaS的关键技术：Watchdog，不了解它后面就没法继续了；

• 标题为大话watchdog说明本文以理论为主，这也是作者的弱项，但我会努力把关键点说得简洁明白，如果您发现问题请务必及时指出，谢谢！

• 整篇文章由以下段落构成：

1. 从faas-netes谈起

2. OpenFaaS的资源

3. watchdog分析

4. 小结

5. java程序员的担忧

接下来一同开启这段旅程吧，OpenFaaS开发之路上最重要的一站！

从faas-netes谈起

1. 先看Kubernetes下OpenFaaS的整体架构，如下图，外部请求由Gateway转发到faas-netes组件：

2. 再来看官方描述，如下图红框，在K8S环境，faas-netes就是服务提供者，它提供的服务支持REST API、客户端、WEB等多种对接方式，另外，还可以用kubectl命令对其进行管理，实现K8S的operator模式(关于K8S的operator，可以先学习Controller，再想象着高度定制CDR和Controller就可以了)：

3. 虽然faas-netes很强大，但是在本文咱们只要关注一点：faas-netes提供了函数服务，也就是说，咱们前面写过的python、java的Hello world函数，都和faas-netes有关;

4. 说了一大堆，主角watchdog还不出来？再等等，因为此刻大家都有同样的疑问：我不就是写了个python脚本吗，里面只有个Hello world方法，怎么就成了faas-netes对外提供的函数了呢？

5. 对上面的疑问，官方内部架构图应该是最合理的答案，如下图，API Gateway的请求会到达faas-provider的8080端口，如果是调用已经发布的函数，就在左上角的红框内处理，如果是对资源的增删改查，就交给右下角的绿框处理：

![在这里插入图片描述](https://www.icode9.com/i/ll/?i=20201123100400282.jpg?,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nL

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】

浏览器打开：qq.cn.hn/FTf 免费领取

mNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70#pic_center)

OpenFaaS的资源

刚才提到了上图右下角的绿框，其责任是处理资源，这不是本文的重点，但作者好歹算是Kubernetes爱好者，觉得有必要科(xuan)普(yao)一下资源相关的知识点：

1. 在K8S中，Pod、Deployment、Service都是资源，也有对应的Controller根据etcd中保存的期望状态来调节和控制这些资源；

2. 对K8S环境的OpenFaaS来说，它也有自己定义的资源类型(第一篇《安装》里面提到过yaml文件夹，那里面有个crd.yml文件，记录了OpenFaaS的资源定义)；

3. OpenFaaS怎么控制自己的资源呢？faas-netes提供CRUD接口给外面调用，而这些接口的内部实现，就是上面图中你们看到的绿框了，显然，经典的K8S Controller模式不能满足OpenFaaS对资源控制的需求，于是就采用了目前流行的Operator模式：更复杂的资源定义、更复杂的资源控制逻辑

4. 至于OpenFaaS的资源具体有哪些，那要详细去看crd.yml文件，以及OpenFaaS Operator的代码了，不过上图还是给我们指明了方向：Secret、Deployment、Service，想想也是如此，咱们把业务功能发布到OpenFaaS，最关注的不就是安全(Secret)、部署配置(Deployment)、对外暴露(Service)这些东西嘛；

• 经过欣宸的一番梳(chui)理(niu)，现在对faas-netes的了解是否更进一步了呢？函数的发布、后期的资源控制和调节，都是faas-netes的Operator在负责，接下来是不是该回到正题了：函数调用

• 主角watchdog已经哭晕了吧…

watchdog分析

• 还是前面那幅图，咱们聚焦右上角那部分，我把它截出来如下图所示：

• 如果咱们用nodejs模板开发函数，写了个index.js文件，那么响应外部请求时会走到下图红框位置，进入Watchdog的8080端口，此时Watchdog会新建node进程，该进程执行index.js文件：

• 上面说得不够清楚么？那就再详细一些，咱们开发函数时会做成docker镜像，这个镜像里有些啥？再来一副官方图如下，真相大白：镜像里有个Watchdog，监听8080端口，收到请求后fork一个进程，通过stdin把请求参数传给这个进程，进程调用咱们自己写的函数方法，并且把参数传给此方法，等方法执行完毕后，返回值通过stdout给到Watchdog

• 现在，相信您在写完一个函数后，对于外部请求如何调用到您写的那段代码应该了然于胸，但是，依然有个小小的盲点：我知道了Watchdog能干啥，但是Watchdog具体是个啥？咋就进了docker镜像呢？

• 上述问题，在模板的Dockerfile文件中可以找到答案(Dockerfile是制作docker镜像的脚本文件)，咱们打开node模板的Dockerfile看看；

• 如下，一开始就从基础镜像openfaas/classic-watchdog:0.18.18里把文件fwatchdog复制过来了：

FROM --platform=${TARGETPLATFORM:-linux/amd64} openfaas/classic-watchdog:0.18.18 as watchdog

FROM --platform=${TARGETPLATFORM:-linux/amd64} node:12.13.0-alpine as ship

COPY --from=watchdog /fwatchdog /usr/bin/fwatchdog

RUN chmod +x /usr/bin/fwatchdog

• 这个Dockerfile的结尾如下，也就是说该镜像的容器一启动就会执行fwatchdog：

CMD [“fwatchdog”]

• 至此，您对Watchdog是否有了足够的了解，如果前面的信息量太大，咱们来做个小结；

小结

1. 开发函数时，当函数文件编写完成后，就开始制作docker镜像；

2. 制作的镜像中，包含有fwatchdog文件，以及咱们编写的函数，如果是python、nodejs等脚本语言，就会将脚本和nodejs或者python都复制到镜像中，如果是java类型的，还会涉及到编译构建；

3. 部署好函数后，Kubernetes环境会根据此镜像创建pod，而pod启动后，就会运行fwatchdog文件，也就是启动了watchdog进程；

4. 外部访问函数时，请求先到API Gateway，再到上一步创建的pod的8080端口；

5. 这个pod里面，是watchdog在监听8080端口，收到请求后，创建一个node进程，把请求参数通过stdin传给node进程；

6. node进程会执行咱们开发函数时编写的函数，并且将收到的参数作为函数的入参；

7. 咱们编写的函数执行完毕后，node进程将返回值写入stdout，这时候watchdog通过stdout就会收到函数的返回值；

8. watchdog将收到的返回值返回给API Gateway，最终返回给用户；

标签：镜像,函数,之五,watchdog,OpenFaaS,netes,faas
来源： https://blog.csdn.net/m0_63174618/article/details/121182773

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。