关于serverless:OpenFunction-v100-发布集成-WasmEdge支持-Wasm-函数和更完整的-CICD

4次阅读

共计 3192 个字符,预计需要花费 8 分钟才能阅读完成。

OpenFunction 是一个开源的云原生 FaaS(Function as a Service,函数即服务)平台,旨在帮忙开发者专一于业务逻辑的研发。明天,咱们非常高兴地发表 OpenFunction 迎来了一次重要的更新,即 v1.0.0 版本的公布!

In this update, we continue to focus on providing developers with more flexible and powerful tools, and have added some new features on this basis. This release
本次更新中,咱们持续致力于为开发者们提供更加灵便和弱小的工具,并在此基础上退出了一些新的性能点。其中,该版本集成了 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
正文完
 0