Go 夜读第 16 期：OpenFaaS 快速入门实战——从 faas-cli 创建到部署调用的完整指南

Go 夜读第 16 期OpenFaaS 快速入门实战——从 faas-cli 创建到部署调用的完整指南【免费下载链接】nightWeekly Go Online Meetup via BilibiliGo 夜读通过 bilibili 在线直播的方式分享 Go 相关的技术话题每天大家在微信/telegram/Slack 上及时沟通交流编程技术话题。项目地址: https://gitcode.com/gh_mirrors/ni/night本篇技术指南基于 Go 夜读第 16 期分享整理围绕 OpenFaaS 的快速入门展开完整演示了使用faas-cli从创建函数、构建镜像、推送镜像到部署函数并调用验证的端到端流程并结合同期的 openfaas-guide、watchdog、faas-provider、gateway 与 queue-worker 源码分析文档带你理解一次faas-cli deploy背后 Gateway、Provider、watchdog 是如何协作的。读完你可以独立用 OpenFaaS 跑通写一个函数到线上可调用的全过程。第 16 期分享背景OpenFaaS 是什么第 16 期分享由 Lucas 主讲对应讲义见 openfaas-guide内容覆盖 OpenFaaS 的简介、快速入门、基础组件、源码分析与定制五个部分。OpenFaaSFunctions as a Service是一个基于容器的无服务器函数框架开发者只需要写好一个函数handler框架负责构建镜像、调度运行、暴露 HTTP 入口、监控指标与自动伸缩。从整体架构看OpenFaaS 由几个核心组件协同工作Gateway一个 Go 实现的请求转发网关承担 UI、函数部署入口、监控与自动伸缩调度详见 gateway-readingProvider真正操作容器编排系统的后台实现官方提供 Docker Swarm 与 Kubernetes 两套详见 faas-providerwatchdog嵌入每个函数容器的监视器进程负责把 HTTP 请求转成进程调用详见 watchdogqueue-worker异步函数的消息订阅与执行者详见 queue-worker。本篇文章聚焦其中的快速入门部分不深入源码先把一个函数跑起来。第一步faas-cli new 创建新函数OpenFaaS 提供了faas-cli命令行工具它抽象了所有 Docker 相关的知识开发者只需要编写所支持语言的 handler 文件即可。创建一个新函数只需要一条命令faas-cli new --lang node hello-node这条命令做了两件事根据--lang node指定的语言模板这里是 Node.js生成一个函数目录里面包含 handler 的源文件在当前目录生成一个hello-node.yml配置文件记录函数名、语言、镜像地址等元信息。后续的build、push、deploy三个步骤都要通过-f hello-node.yml显式指定这个配置文件说明faas-cli的整个生命周期都是以该 yml 为函数描述文件来驱动的。第二步构建函数镜像函数本身要打包成 Docker 镜像才能被调度运行构建命令如下faas-cli build -f hello-node.ymlfaas-cli build会根据模板和函数代码自动生成并构建一个 Docker 镜像整个过程对开发者屏蔽了 Dockerfile 的细节。如果你想理解这个镜像内部到底是什么样的可以参考 watchdog 中的手工打包方式FROM alpine:3.7 ADD https://github.com/openfaas/faas/releases/download/0.8.0/fwatchdog /usr/bin RUN chmod x /usr/bin/fwatchdog # Define your binary here ENV fprocess/bin/cat CMD [fwatchdog]这段 Dockerfile 揭示了函数镜像的本质基础镜像 fwatchdogwatchdog 二进制 指定函数进程的环境变量fprocess 暴露 8080 端口 以fwatchdog作为容器启动命令。也就是说任何可执行程序都可以通过这种方式被打包成一个 OpenFaaS 函数这正是faas-cli new在后台替你完成的事情。第三步推送镜像到镜像仓库构建完成后的镜像是本地产物要让集群节点能拉取到需要推送到 Docker 镜像仓库faas-cli push -f hello-node.yml这一步会把hello-node.yml中声明的镜像推送到对应的 registry。在使用 Docker Swarm 或 Kubernetes 作为 Provider 的多节点环境下这一步是部署成功的前提——Gateway 与 Provider 调度函数容器时都需要从该镜像仓库拉取镜像。第四步部署函数镜像就绪后部署函数只需要一条命令faas-cli deploy -f hello-node.ymlfaas-cli deploy会将部署请求发送给 OpenFaaS 的 Gateway通常是http://网关地址:8080可通过--gateway指定。Gateway 本身不直接创建容器它只作为代理把请求转发给后端的 Provider详见下文Gateway 与 Provider 的分工由 Provider 调用 Docker Swarm 或 Kubernetes 的 API 真正创建函数服务。部署完成后稍等几秒钟等待容器调度与启动在 Rancher 等容器管理界面中可以观察到函数服务从部署到 Running 的状态变化之后就可以通过 HTTP 调用函数了。第五步调用函数验证部署完成后可以用 Postman 向函数发送 GET 或 POST 请求进行验证。OpenFaaS 的函数调用入口统一走 Gateway同步调用/function/function_name例如http://gateway:8080/function/hello-node异步调用/async-function/function_name。同步调用会保持连接直到函数返回结果异步调用则立即返回202响应码由 queue-worker 在后台执行详见下文同步与异步函数。也可以直接用 curl 验证curl http://gateway:8080/function/hello-node -X POST -d hello返回的内容就是你的 handler 对请求体的处理结果。源码纵深watchdog 如何执行你的函数函数之所以能用任意语言写、通过 HTTP 调用关键在于每个容器里嵌入的 watchdog 进程。从 watchdog 的分析可知watchdog 是一个小型的 Go 服务它提供外部世界与函数之间非托管的通用接口它作为容器的初始化进程ENTRYPOINT或CMD启动每个传入的 HTTP 请求到达后watchdog 会为它分配fork一个函数进程请求通过stdin传给函数进程函数的输出从stdout读回作为 HTTP 响应。这意味着你的程序完全不需要知道 HTTP 的任何细节一个普通的命令行程序就可以成为一个函数。watchdog 还支持把 HTTP 头等信息注入环境变量供函数使用默认通过cgi_headers启用例如X-Forwarded-By头会变成Http_X_Forwarded_By同时提供Http_Method、Http_Query、Http_ContentLength等变量函数响应默认匹配客户端的Content-Type也可用content_type环境变量覆盖。watchdog 内部启动 HTTP 服务时会在/tmp/下创建.lock文件配合 Dockerfile 中的HEALTHCHECK如HEALTHCHECK --interval5s CMD [ -e /tmp/.lock ] || exit 1可以确保 Gateway 在转发请求前函数已就绪。源码纵深Gateway 与 Provider 的分工部署与调用函数背后是 Gateway 与 Provider 的协作。从 gateway-reading 的源码分析可以看到Gateway 是纯转发层MakeForwardingProxyHandler会把请求转发给 Provider 的地址并同时把监控指标发给 Prometheus它本身不做任何部署或发布函数的事。而 Provider 侧见 faas-provider则是一个可插拔的接口层。OpenFaaS 官方提供了 Docker Swarm 与 Kubernetes 两套 Providerfaas-provider本质是一个模板其中Serve方法把 OpenFaaS 规定的路由规范与自定义 handler 绑定r.HandleFunc(/system/functions, handlers.FunctionReader).Methods(GET) r.HandleFunc(/system/functions, handlers.DeployHandler).Methods(POST) r.HandleFunc(/system/functions, handlers.DeleteHandler).Methods(DELETE) r.HandleFunc(/system/function/{name:[-a-zA-Z_0-9]}, handlers.ReplicaReader).Methods(GET) r.HandleFunc(/system/scale-function/{name:[-a-zA-Z_0-9]}, handlers.ReplicaUpdater).Methods(POST) r.HandleFunc(/function/{name:[-a-zA-Z_0-9]}, handlers.FunctionProxy)只要实现FaaSHandlers结构体中的这些 handler就能自定义一套 Provider。以 Kubernetes 的 faas-netes 实现为例FunctionProxy负责把调用函数的请求组装成http://函数名.namespace:watchdog端口/路径的形式转发给函数容器DeployHandler/DeleteHandler/FunctionReader等则直接调用 Kubernetes 的 API如clientset.ExtensionsV1beta1().Deployments(functionNamespace)操作 Deployment 与 Service。所以一次faas-cli deploy的完整链路是CLI → Gateway转发→ Provider调用编排系统 API→ 创建函数容器内部跑 watchdog→ 之后调用/function/xxx时 Gateway 再把请求代理给函数容器。源码纵深同步与异步函数OpenFaaS 支持同步与异步两种调用模式二者的差异在 queue-worker 中有清晰的对比同步函数路由为/function/function_name调用方必须等待在结束时拿到结果能明确知道成功还是失败异步函数路由为/async-function/function_name客户端立即获得202响应实际执行由 queue-worker 完成默认情况下执行结果会被丢弃。异步场景下Gateway 的角色是发布者MakeQueuedProxy读取请求体、解析X-Callback-Url头构造异步请求对象并调用CanQueueRequests接口的Queue方法把请求发布到 NATS Streaming 队列中。queue-worker 则作为订阅者消费消息反序列化请求后以 POST 方式调用函数并把结果回传若请求携带X-Callback-Url执行结果会通过postResult回调到该 URL可用 requestbin 这类服务接收否则通过postReport把执行情况上报到 Gateway 的/system/async-report接口之后可从此处查询异步函数执行结果。CanQueueRequests接口的设计使得任何实现该接口的组件都可以成为一个 queue-worker体现了 OpenFaaS 良好的可扩展性。总结本篇文章基于 Go 夜读第 16 期分享完整走通了 OpenFaaS 快速入门的四个关键命令faas-cli new --lang node hello-node # 创建函数 faas-cli build -f hello-node.yml # 构建镜像 faas-cli push -f hello-node.yml # 推送镜像 faas-cli deploy -f hello-node.yml # 部署函数并在此基础上深入理解了函数镜像内部的 watchdog 机制、Gateway 与 Provider 的转发分工以及同步/异步调用的完整链路。第 16 期的配套讲义还包含 OpenFaaS 介绍与源码分析、faas-provider、watchdog、Gateway 源码阅读 与 queue-worker 源码分析 等文档想要深入源码细节的读者可以继续阅读这些仓库内资料也可以参考同目录下的 第 16 期 PDF 讲义。【免费下载链接】nightWeekly Go Online Meetup via BilibiliGo 夜读通过 bilibili 在线直播的方式分享 Go 相关的技术话题每天大家在微信/telegram/Slack 上及时沟通交流编程技术话题。项目地址: https://gitcode.com/gh_mirrors/ni/night创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考