这是本节可打印的多页视图 点击这里开始打印.

返回常规视图.

版本发布

OpenFunction v1.2.0 发布：集成 KEDA http-addon 作为同步函数运行时

OpenFunction 是一个开源的云原生 FaaS（Function as a Service，函数即服务）平台，旨在帮助开发者专注于业务逻辑的研发。我们非常高兴地宣布 OpenFunction 又迎来了一次重要的更新，即 v1.2.0 版本的发布！

本次更新中，我们继续致力于为开发者们提供更加灵活和强大的工具，并在此基础上加入了一些新的功能点。该版本集成了 KEDA http-addon 作为同步函数运行时；支持在启用 SkyWalking 跟踪时添加环境变量；支持记录构建时间等。此外，还升级了部分组件及修复了多项 bug。

以下是该版本更新的主要内容：

集成 KEDA http-addon 作为同步函数运行时

KEDA http-addon 是一个 KEDA 的附加组件，它可以根据 HTTP 流量的变化自动地调整 HTTP 服务器的规模（包括从零开始扩容和缩容到零）。

KEDA http-addon 的工作原理是，它会在 Kubernetes 集群中创建一个名为 Interceptor 的组件，用来接收所有的 HTTP 请求，并将请求转发给目标应用。同时，它会将请求队列的长度报告给一个名为 External Scaler 的组件，用来触发 KEDA 的自动扩缩容机制。这样，你的 HTTP 应用就可以根据实际的流量需求动态地调整副本数。

在 OpenFunction v1.2.0 版本中，我们集成了 KEDA http-addon 作为同步函数运行时的一种选择。这意味着，你可以使用 OpenFunction 来创建和管理基于 HTTP 的函数，并利用 KEDA http-addon 的能力来实现高效且灵活的弹性伸缩。你只需在创建 Function 资源时指定 serving.triggers[*].http.engine 的值为 keda ，并且在 serving.scaleOptions 中配置 keda.httpScaledObject 相关参数，就可以部署和运行你的 HTTP 函数了。

支持在启用 SkyWalking 跟踪时添加环境变量

SkyWalking 是一个开源的应用性能监控（APM）系统，它可以帮助你观察和分析你的应用在不同环境中的运行状况。OpenFunction 支持在部署函数时启用 SkyWalking 跟踪，以便你可以更好地理解和优化你的函数性能。

在 OpenFunction v1.2.0 版本中，我们增加了一个新的功能，即支持在启用 SkyWalking 跟踪时添加环境变量。这样，你可以在创建 Function 资源时指定一些自定义的环境变量来控制 SkyWalking 的一些配置参数。这些环境变量会被传递给函数容器，并影响 SkyWalking 的采集和上报行为。

当 Function、Builder 和 Serving 状态变化时支持记录事件

事件（Event）是 Kubernetes 中一种重要的资源类型，它可以记录集群中发生的一些重要或者有趣的事情。事件可以帮助用户和开发者了解集群中资源的状态变化和异常情况，并采取相应的措施。

在 OpenFunction v1.2.0 版本中，我们支持当 Function、Builder 和 Serving 状态变化时记录事件。这样，你可以通过查看事件来获取更多关于函数构建和运行过程中发生的事情的信息。例如，你可以看到函数构建开始、结束、失败等事件；函数运行时创建、更新、删除等事件。

其他的改进和优化

除了上述的主要变化，该版本还有以下更改和增强：

  • 升级了 KEDA 到 v2.10.1 ，HPA（自动伸缩）API 版本到 v2 ，提高了稳定性和兼容性
  • 支持记录构建时间，以便你可以了解函数构建的耗时情况
  • 调整了 CI 流程，修复了一些小问题
  • 修复了一个在 keda http-addon 运行时中的 bug ，该 bug 会导致函数无法正常运行
  • 升级了 charts 中的一些组件，包括 keda ，dapr 和 contour ，以保持最新的版本和功能

以上就是 OpenFunction v1.2.0 的主要功能变化，在此十分感谢各位贡献者的参与和贡献。

了解更多关于 OpenFunction 和本次版本更新的信息，欢迎访问我们的官方网站和 Github 页面。

  • 官网：https://openfunction.dev/
  • Github：https://github.com/OpenFunction/OpenFunction/releases/tag/v1.2.0

OpenFunction v1.1.0 发布：支持 Dapr 状态管理，重构函数触发器

OpenFunction 是一个开源的云原生 FaaS（Function as a Service，函数即服务）平台，旨在帮助开发者专注于业务逻辑的研发。在过去的几个月里，OpenFunction 社区一直在努力工作，为 OpenFunction 1.1.0 版本的发布做准备。今天，我们非常高兴地宣布 OpenFunction 1.1.0 已经发布了！感谢社区各位小伙伴的贡献和反馈！

OpenFunction 1.1.0 版本带来了两个新的功能：新增 v1beta2 API，支持 Dapr 状态管理。此外，该版本还有多项强化（重构函数触发器等）及 bug 修复，使 OpenFunction 更加稳定和易用。

以下是本次版本更新的主要内容：

新增 v1beta2 API

在此版本中，我们新增了 v1beta2 API，原 v1beta1 API 已弃用，将来会被删除。v1beta2 中有不少重构，你可以在这个 proposal 中了解更多细节。

支持 Dapr 状态管理

之前，OpenFunction 支持 Dapr 发布/订阅和绑定构建块，状态管理也是有用的构建块之一，它对于具有状态的函数非常有用。使用状态存储组件，您可以构建具有持久状态的函数，这些函数可以保存和恢复它们的状态。

现在你可以在 Function CR 中定义状态存储，OpenFunction 将管理相应的 Dapr 组件。

你的函数可以使用简单封装的 Dapr 的状态管理 API 来保存、读取和查询定义的状态存储中的键/值对。

重构函数触发器

之前，我们使用 runtime: knative 和 runtime: async 来区分同步和异步函数，这会增加学习曲线。实际上，同步和异步函数之间的区别在于触发类型:

  • 同步函数由 HTTP 事件触发，这可以通过指定 runtime: knative 来定义。
  • 异步函数由 Dapr 绑定组件或 Dapr 发布者事件触发。要指定异步函数的触发器，必须同时使用 runtime: async 和 inputs。

因此，我们可以使用 triggers 来替代 runtime 和 inputs。

HTTP Trigger 通过 HTTP 请求触发一个函数。您可以这样定义一个 HTTP Trigger：

apiVersion: core.openfunction.io/v1beta2
kind: Function
metadata:
  name: function-sample
spec:
  serving:
    triggers:
      http:
        port: 8080
        route:
          rules:
            - matches:
                - path:
                    type: PathPrefix
                    value: /echo

Dapr Trigger 使用 Dapr bindings 或 Dapr pubsub 的事件触发一个函数。你可以用 Dapr Trigger 定义一个函数：

apiVersion: core.openfunction.io/v1beta2
kind: Function
metadata:
  name: logs-async-handler
  namespace: default
spec:
  serving:
    bindings:
      kafka-receiver:
        metadata:
          - name: brokers
            value: kafka-server-kafka-brokers:9092
          - name: authRequired
            value: "false"
          - name: publishTopic
            value: logs
          - name: topics
            value: logs
          - name: consumerGroup
            value: logs-handler
        type: bindings.kafka
        version: v1
    triggers:
      dapr:
        - name: kafka-receiver
          type: bindings.kafka

其他改进和优化

  • 从网关状态中删除 lastTransitionTime 字段，以防止频繁触发 reconcile。
  • 允许在创建 Dapr 组件时设置作用域。
  • 使用 OpenFunction 策略时，支持设置缓存镜像以提高构建性能。
  • 支持设置 OpenFunction 构建策略的 bash 镜像。

以上就是 OpenFunction v1.1.0 的主要功能变化，在此十分感谢各位贡献者的参与和贡献。如果您正在寻找一款高效、灵活的云原生函数开发平台，那么 OpenFunction v1.1.0 绝对不容错过。

了解更多关于 OpenFunction 和本次版本更新的信息，欢迎访问我们的官方网站和 Github 页面。

  • 官网：https://openfunction.dev/
  • Github：https://github.com/OpenFunction/OpenFunction/releases/tag/v1.1.0

OpenFunction v1.0.0 发布：集成 WasmEdge，支持 Wasm 函数和更完整的 CI/CD

OpenFunction 是一个开源的云原生 FaaS（Function as a Service，函数即服务）平台，旨在帮助开发者专注于业务逻辑的研发。今天，我们非常高兴地宣布 OpenFunction 迎来了一次重要的更新，即 v1.0.0 版本的发布！

本次更新中，我们继续致力于为开发者们提供更加灵活和强大的工具，并在此基础上加入了一些新的功能点。其中，该版本集成了 WasmEdge 以支持 Wasm 函数；我们还对 OpenFunction 的 CI/CD 功能进行了增强，提供了相对完整的端到端的 CI/CD 功能；除此之外，我们还在这个版本中新增了从本地代码直接构建函数或应用的镜像的功能，让开发者可以更加便捷地进行代码发布和部署。

与此同时，我们也在大力优化 OpenFunction 的性能和代码质量，使其更加稳定高效。

以下是本次版本更新的主要内容：

集成 WasmEdge，支持 Wasm 函数

WasmEdge 是一个轻量级、高性能和可扩展的 WebAssembly 运行时，适用于云原生、边缘和去中心化应用程序。它为 Serverless 应用程序、嵌入式功能、微服务、智能合约和物联网设备提供支持。

OpenFunction 现在支持构建和运行以 WasmEdge 为运行时的 Wasm 函数或应用。WasmEdge 成为 Docker、Containerd 和 CRI-O 之外的容器运行时的新选择。

Wasm 函数示例

cat <<EOF | kubectl apply -f -
apiVersion: core.openfunction.io/v1beta1
kind: Function
metadata:
  name: wasmedge-http-server
spec:
  workloadRuntime: wasmedge
  image: openfunctiondev/wasmedge_http_server:0.1.0
  imageCredentials:
    name: push-secret
  build:
    dockerfile: Dockerfile
    srcRepo:
      revision: main
      sourceSubPath: functions/knative/wasmedge/http-server
      url: https://github.com/OpenFunction/samples
  port: 8080
  route:
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /echo
  serving:
    runtime: knative
    scaleOptions:
      minReplicas: 0
    template:
      containers:
        - command:
            - /wasmedge_hyper_server.wasm
          imagePullPolicy: IfNotPresent
          livenessProbe:
            initialDelaySeconds: 3
            periodSeconds: 30
            tcpSocket:
              port: 8080
          name: function
EOF

借助 WasmEdge 引擎，开发者可以使用多种支持 Wasm 的语言和开发框架来编写及运行函数。

如何构建和运行 Wasm functions，请参考官方文档 Wasm Functions。

更完整的 CI/CD

之前，用户可以使用 OpenFunction 将函数或应用程序源代码构建为容器镜像，然后直接将构建的镜像部署到底层的同步或异步 Serverless 运行时，而无需用户干预。

但是，OpenFunction 不能在函数或应用程序源代码发生更改时重新构建镜像并重新部署它，也不能在镜像更改时重新部署它（例如手动构建和推送镜像或在其他函数中构建镜像）。

从 v1.0.0 开始，OpenFunction 在新的组件 Revision Controller 中增加了检测源代码或镜像变更的能力，并且可以在检测到变更后触发镜像重新构建或重新部署新的镜像。Revision Controller 的能力包括：

  • 检测 GitHub、GitLab 或 Gitee 中的源代码变更，然后在源代码变更时重新构建并重新部署新的镜像。
  • 检测包含源代码的镜像（Bundle Container Image）的变更，然后在该镜像变更时重新构建和重新部署新的镜像。
  • 检测函数或应用程序镜像变更，然后在函数或应用程序镜像变更时重新部署新的镜像。

更好的 CI/CD 功能确保了代码能在不同的环境中高效运行，使用者可以在开发和部署过程中更好的控制版本和代码质量，同时也为使用者提供了更好的使用体验。

此处请参考官方文档 CI/CD。

从本地源代码构建函数

目前，OpenFunction v1.0.0 支持根据本地的源代码构建函数或应用。只需要将本地源代码打包到容器镜像中，并将此镜像推送到容器镜像仓库即可完成构建。以下为操作方法。

假设你的源代码在 samples 目录中，你可以根据以下 Dockerfile 来构建包含源代码的镜像。

FROM scratch
WORKDIR /
COPY samples samples/

然后如下操作：

docker build -t <your registry name>/sample-source-code:latest -f </path/to/the/dockerfile> .
docker push <your registry name>/sample-source-code:latest

推荐使用空镜像 scratch 作为基础镜像构建包含源代码的镜像，非空基础镜像可能会导致源代码拷贝失败。

另外还需要定义字段 spec.build.srcRepo.bundleContainer.image。

apiVersion: core.openfunction.io/v1beta1
kind: Function
metadata:
  name: logs-async-handler
spec:
  build:
    srcRepo:
      bundleContainer:
        image: openfunctiondev/sample-source-code:latest
      sourceSubPath: "/samples/functions/async/logs-handler-function/"

sourceSubPath 是包含源代码的镜像中源代码的绝对路径。

其他的改进和优化

除了上述的主要变化，该版本还有以下更改和增强：

  • OpenFunction
    • 核心 API v1alpha2 已弃用并删除
    • 将 sha256 添加到服务镜像
    • 将构建源信息添加到函数状态
    • 将 Shipwright 升级到 v0.11.0
    • 将 Knative 升级到 v0.32.0
    • 将 Dapr 升级到 v1.8.3
    • 将 Go 升级到 v1.18
  • functions-framework-java 发布 V1.0.0
    • 在一个 pod 中支持多个函数
    • 支持自动发布
  • Builder
    • 在一个 pod 中支持多个函数
    • 将默认的 Java 框架版本更新为 1.0.0
  • revision-controller 发布 v1.0.0（功能见上文）

以上就是 OpenFunction v1.0.0 的主要功能变化，在此十分感谢各位贡献者的参与和贡献。如果您正在寻找一款高效、灵活的云原生函数开发平台，那么 OpenFunction v1.0.0 将是您的绝佳选择。

了解更多关于 OpenFunction 和本次版本更新的信息，欢迎访问我们的官方网站和 Github 页面。

  • 官网：https://openfunction.dev/
  • Github：https://github.com/OpenFunction/OpenFunction/releases/tag/v1.0.0

OpenFunction v0.8.0 发布：通过 Dapr Proxy 加速函数启动

相较于其他函数计算项目，OpenFunction 有很多独特的功能，其中之一便是通过 Dapr 与各种后端服务（BaaS）无缝集成。目前 OpenFunction 已经支持了 Dapr 的 pub/sub 和 bindings 构建模块，未来还会支持更多功能。截止到 v0.7.0，OpenFunction 与 BaaS 的集成还不算特别丝滑，需要在每个函数实例的 Pod 中注入一个 Dapr Sidecar 容器，这就会导致一个问题：整个函数实例的启动时间会受到 Dapr Sidecar 容器启动时间的影响，甚至 Dapr Sidecar 容器可能会比函数容器本身消耗的资源更多。

为了解决这个问题，OpenFunction 发布了 v0.8.0，引入了 Dapr Standalone 模式。

Dapr Standalone 模式

在新的 Dapr Standalone 模式中，无需为每个函数实例启动一个独立的 Dapr Sidecar 容器，而是为每个函数创建一个 Dapr Proxy 服务，这个函数的所有实例都会共享这个 Dapr Proxy 服务，大大减少了函数的启动时间。

如何选择 Dapr 服务模式

当然，除了新增的 Dapr Standalone 模式之外，您还可以继续选择使用 Dapr Sidecar 模式，建议您根据自己的实际业务来选择合适的 Dapr 服务模式。默认推荐使用 Dapr Standalone 模式，如果您的函数实例不需要频繁伸缩，或者由于一些其他原因无法使用 Dapr Standalone 模式，则可以使用 Dpar Sidecar 模式。

您可以通过在自定义资源 Function 中添加 spec.serving.annotations 来控制使用何种 Dapr 模式与 BaaS 集成，总共有两个 annotations：

  • openfunction.io/enable-dapr：可以设置为 true 或者 false；
  • openfunction.io/dapr-service-mode：可以设置为 standalone 或者 sidecar。

当 openfunction.io/enable-dapr 设置为 true 时，可以调整 openfunction.io/dapr-service-mode 的值来选择不同的 Dapr 服务模式。

当 openfunction.io/enable-dapr 设置为 false 时，openfunction.io/dapr-service-mode 的值会被忽略，Dapr Standalone 模式与 Dapr Sidecar 模式都不会启用。

这两个 annotations 的默认值如下：

  • 如果 Function 中没有添加 spec.serving.annotations 配置块，并且 Function 中包含 spec.serving.inputs 和 spec.serving.outputs 配置块，openfunction.io/enable-dapr 会被自动设置为 true；否则 openfunction.io/enable-dapr 就会被设置为 false。
  • openfunction.io/dapr-service-mode 默认值是 standalone。

示例：

apiVersion: core.openfunction.io/v1beta1
kind: Function
metadata:
  name: cron-input-kafka-output
spec:
  ...
  serving:
    annotations:
      openfunction.io/enable-dapr: "true"
      openfunction.io/dapr-service-mode: "standalone"
    template:
      containers:
        - name: function # DO NOT change this
          imagePullPolicy: IfNotPresent 
    runtime: "async"
    inputs:
      - name: cron
        component: cron
    outputs:
      - name: sample
        component: kafka-server
        operation: "create"
    ...

关于 v0.8.0 的更多发版细节可以参考 OpenFunction v0.8.0 的 Release Notes。

OpenFunction 0.7.0 发布: OpenFunction Gateway、多语言及 Helm 安装支持

OpenFunction 是一个开源的云原生 FaaS（Function as a Service，函数即服务）平台，旨在帮助开发者专注于业务逻辑的研发。在过去的几个月里，OpenFunction 社区一直在努力工作，为 OpenFunction 0.7.0 版本的发布做准备。今天，我们非常高兴地宣布 OpenFunction 0.7.0 已经正式发布了！感谢社区各位小伙伴的贡献和反馈！

OpenFunction 0.7.0 为您带来了许多新功能，包括新增 OpenFunction Gateway 作为同步函数入口、 新增 Java 和 NodeJS 同步函数和异步函数支持、新增 Helm 安装方式。 同时， 我们对 OpenFunction 依赖的组件都进行了版本升级。

OpenFunction Gateway

OpenFunction 从 0.5.0 开始采用 Kubernetes Ingress 来提供同步函数的统一入口，并且必须安装一个 nginx-ingress-controller。

在 OpenFunction 0.7.0 中，我们基于 Kubernetes Gateway API 实现了 OpenFunction Gateway 替代之前基于 Kubernetes Ingress 的 Domain 来访问同步函数的方法。

OpenFunction Gateway 提供了更强大、更灵活的函数网关，包含以下特性：

  • 可以选择任意支持 Kubernetes Gateway API 的 Gateway 实现，如 Contour, Istio, Apache APISIX, Envoy Gateway 等。
  • 可以选择安装默认的 Gateway 实现（Contour）, 此时 OpenFunction 将自动创建 Kubernetes Gateway。OpenFunction 也可以使用您环境中现有的 Kubernetes Gateway，只需要您在 OpenFunction Gateway 中引用它即可。
  • 可以自定义访问函数的模式，如基于 host 的路由模式和基于 path 的路由模式，在您没有定义函数路由时 OpenFunction 默认提供基于 host 的路由模式来访问函数。
  • 可以在函数路由部分自定义流量应该如何到达函数，OpenFunction 基于 Gateway API HTTPRoute 为您提供了强大的函数路由功能。
  • 可以通过函数外部地址在集群外部访问函数，只需要在OpenFunction Gateway 中配置好集群外部可以访问的域名即可（同时支持 Magic DNS 和 Real DNS）。
  • 现在 OpenFunction 将流量直接转发到 Knative Revision 而不再经过 Knative 的 Gateway。 如果不需要直接访问 Knative 服务, 您可以忽略 Knative Domain 相关的错误。

将来，OpenFunction 将支持在函数的不同版本之间进行流量分发。

多语言支持

OpenFunction 社区一直在努力完善多语言的支持：

OpenFunction 将会在后续版本支持更多语言如 Python、Dotnet 等。

Helm 安装 OpenFunction 及所有依赖组件

原来基于 CLI 安装的方法已弃用。

现在 OpenFunction 支持通过 Helm 安装 OpenFunction 及所有依赖的组件，相比原来通过 CLI 安装的方式更加云原生， 并且解决了部分用户访问 Google Container Registry（gcr.io）镜像受限的问题， 并且将长期维护。

TL;DR

helm repo add openfunction https://openfunction.github.io/charts/
helm repo update
helm install openfunction openfunction/openfunction -n openfunction --create-namespace

依赖组件升级

ComponentsOpenFunction 0.6.0OpenFunction 0.7.0
Knative Serving1.0.11.3.2
Dapr1.5.11.8.3
Keda2.4.02.7.1
Shipwright0.6.10.10.0
Tekton Pipelines0.30.00.37.0

OpenFunction 0.6.0 发布: FaaS 可观测性、HTTP 同步函数能力增强及更多特性

OpenFunction 是一个开源的云原生 FaaS（Function as a Service，函数即服务）平台，旨在帮助开发者专注于业务逻辑的研发。在过去的几个月里，OpenFunction 社区一直在努力工作，为 OpenFunction 0.6.0 版本的发布做准备。今天，我们非常高兴地宣布 OpenFunction 0.6.0 已经正式发布了！感谢社区各位小伙伴对新功能、增强功能和错误修复的各种帮助！

OpenFunction 0.6.0 为您带来了许多值得关注的功能，包括函数插件、函数的分布式跟踪、控制自动缩放、HTTP 函数触发异步函数等。同时，异步运行时定义也被重构了。核心 API 也已经从 v1alpha1 升级到 v1beta1。

面向 Serverless 函数的分布式追踪

当试图了解和诊断分布式系统和微服务时，最有效的方法之一是通过追踪函数的调用链路。分布式追踪为 Serverless 函数提供了一个关于消息流动和分布式事务监控方式的整体视图。OpenFunction 团队与 Apache SkyWalking 社区合作，增加了 FaaS 的可观测性，使得您可以在 SkyWalking UI 上通过图表来可视化 Serverless 函数的依赖关系并追踪函数的调用。

openfunction-tracing-skywalking

将来，OpenFunction 将在日志、指标和追踪方面为 Serverless 功能增加更多的功能。您将能够使用 Apache SkyWalking 和 OpenFunction，为您的 Serverless 工作负载建立一个开箱即用的全栈 APM（Application Performance Monitoring）。此外，OpenFunction 将支持 OpenTelemetry，帮助您利用 Jaeger 或 Zipkin 作为分布式追踪的其它选项。

支持 Dapr 发布/订阅和绑定（Binding）

Dapr Binding 允许您使用来自外部系统的事件触发您的应用程序或服务，或与外部系统对接。OpenFunction 0.6.0 为其同步函数增加了 Dapr 输出绑定（Output Binding），使异步函数通过 HTTP 同步函数进行触发成为了可能。例如，由 Knative 运行时支持的同步函数现在可以与由 Dapr 输出绑定或 Dapr Pub/Sub 中间件 进行交互，异步函数将被同步函数发送的事件所触发。您可以通过这个 指南 获得快速入门样例。

异步函数则引入了 Dapr Pub/Sub，提供一个平台无关的 API 来发送和接收消息。一个典型的用例是，您可以利用同步函数来接收纯 JSON 或 Cloud Event 格式的事件，然后将收到的事件发送到 Dapr 输出绑定或 Pub/Sub 组件，比如是一个消息队列（如 Kafka、NATS Streaming、GCP PubSub）。最后，异步函数可以从消息队列中被触发。您可以通过这个 指南 获得快速入门样例。

http-trigger-openfunction

函数的自动伸缩行为控制

OpenFunction 0.6.0 集成了 KEDA ScaledObject 规范，用于定义 KEDA 应该如何扩展您的应用程序以及触发器是什么。您只需要在 OpenFunction 函数的 CRD 中定义伸缩下限和上限，而无需改变您的代码。

同时，OpenFunction 社区也在开发控制并发性和同时请求数的能力，它继承了 Dapr 和 Knative 的定义。分布式计算的一个典型用例是只允许一定数量的请求同时执行。您将能够控制多少个请求和事件将同时调用您的应用程序。这个功能将在下一个版本中得到完全支持，敬请期待！如果您对这个功能感兴趣，请查看官方代码仓库中的 讨论，了解详细的背景。

在实践中学习

OpenFunction 的创始人霍秉杰先生在 Dapr 社区会议上介绍了 OpenFunction 0.6.0 的两个典型用例：

  1. HTTP trigger for asynchronous functions with OpenFunction and Kafka
  2. Elastic Kubernetes log alerts with OpenFunction and Kafka

您可以观看下面这两段视频，并按照实践指南进行练习。

您还可以从 发布说明 中了解更多关于 OpenFunction 0.6.0 的信息。参照 快速入门 和 样例 开始使用 OpenFunction。

Release v0.4.0

@wanjunlei wanjunlei 发布于 2021.10.19

版本地址：v0.4.0

版本说明:

特性

  • Upgrade core.openfunction.io from v1alpha1 to v1alpha2. #115
  • Make event handlers self driven. #115

改善增强

  • Update dependent Dapr version to v1.3.1. #123
  • Update dependent Tekton pipeline version to 0.28.1. #131
  • Update dependent Knative serving version to 0.26.0. #131
  • Update dependent Shipwright build version to 0.6.0. #131
  • Update go version to 1.16. #131
  • Now Function supports environment variables with commas. #131

修复

  • Fix bug rerun serving failed. #132

文档

  • Use installation script to deploy OpenFunction and deprecate the installation guide. #122

OpenFunction/website

  • Add OpenFunction Website. #1

OpenFunction/cli

  • Add OpenFunction CLI. #11

OpenFunction/builder

  • Upgrade the functions-framework-go from v0.0.0-20210628081257-4137e46a99a6 to v0.0.0-20210922063920-81a7b2951b8a. #17
  • Add Ruby builder. #11

OpenFunction/functions-framework-go

  • Supports multiple input sources && Replace int return with ctx.Return. #13

OpenFunction/functions-framework-nodejs

  • Support OpenFunction type function. #7

OpenFunction/events-handlers

  • Add handler functions. #7

感谢

感谢为 v0.4.0 版本的作出贡献的贡献者们！

@wanjunlei @benjaminhuo @tpiperatgod @linxuyalun @penghuima @lizzzcai

Release v0.3.1

@wanjunlei wanjunlei 发布于 2021.8.27

版本地址：v0.3.1

版本说明：

  • Delete the old serving CR only after the new serving CR is running. #107

Release v0.3.0

@tpiperatgod tpiperatgod 发布于 2021.8.19

版本地址：v0.3.0

版本说明：

Release v0.2.0

@benjaminhuo benjaminhuo 发布于 2021.5.17

版本地址：v0.2.0

版本说明：

  • Support OpenFunctionAsync serving runtime（backed by Dapr + KEDA + Deployment/Job)
  • Functions framework supports async function now
  • Customized go function framework & builders for both Knative and OpenFunctionAsync serving runtime

Release v0.1.0

@benjaminhuo benjaminhuo 发布于 2021.5.17

版本地址：v0.1.0

版本说明：

  • Add Function, Builder, and Serving CRDs and corresponding controllers
  • Support using existing function framework & buildpacks such as Google Cloud Functions to build functions
  • Support Tekton and Cloud Native Buildpacks as Builder backend
  • Support Knative as Serving backend
  • Optimize and localize existing function framework & buildpacks