Announcing riff v0.4.0

August 21, 2019

We are happy to announce the release of riff v0.4.0. Thank you all riff, Cloud Native Buildpack, and Knative contributors.

The riff CLI can be downloaded from our releases page on GitHub. Please follow one of the getting started guides, to create a new cluster on GKE, Minikube, Docker Desktop for Mac, or Docker Desktop for Windows.

A lot has changed, buckle up.

Boston skyline at night

Notable changes

Knative and Istio

riff no longer has a hard dependency on Knative and Istio. Knative integration is provided by riff's Knative runtime, which is available in clusters with Knative Serving installed. Istio is only required for the Knative runtime.

builds

riff now supports builds for applications and containers as well as function builds. Each build resource reports the latest image that a runtime uses to deploy the built workload. The built image is always reported as a digested image, making the detection and rollout of changes more deterministic.

With builds transitioning from one-off tasks to continuous streams of images, riff 0.4 sets up the API to enable hooking into source repositories and triggering automated rebuilds.

function builds

A riff function uses buildpacks with function invokers to convert function source code into a runnable container. The same invokers and buildpacks provided by riff 0.3 are available. Unlike riff 0.3, a function resource is only responsible for building a container image. The deployment of the container is managed by the runtime.

application builds

In addition to functions, riff can now build applications using the Cloud Foundry, Cloud Native Buildpack builder.

container builds

A riff container resource is a way to bring your own builds to riff. It resolves an existing container image to a digest, providing the same interface as Application and Function.

runtimes

Runtimes deploy built containers in different ways. By offering users a choice of runtimes, we plan to make the platform more extensible and support a variety of workloads including long-running applications, stream processors, and finite jobs. This release includes two runtimes, Core and Knative. A streaming runtime is under development.

Core runtime

The Core runtime is a thin layer creating a Kubernetes deployment and a service that targets the deployment. The deployment is automatically updated for new images, creating a new replicaset based on the deployment rollout strategy.

The workload is accessible from within the cluster by default, but must be explicitly exposed externally. A single replica is run by default, but the deployment can be targeted by a HorizontalPodAutoscaler or any other scaler that supports the /scale subresource on deployment. Custom scalers, observability and ingress can be provided for deployers as none are provided by default.

See the Core runtime docs for details.

Knative runtime

The Knative runtime is most analogous to riff 0.3. It requires that Knative Serving and Istio are installed into the cluster in addition to riff. There are two models for consuming Knative: Deployers and Adapters.

Deployers create a Knative configuration and route for a referenced build. The configuration is updated as the build produces new images.

Adapters reference an existing Knative service or configuration, updating the image property as the build produces new ones. Route rules are preserved when new images trigger the creation of Knative revisions.

See the Knative runtime docs for details.

Streaming runtime

The new streaming runtime is under active development, and not included in this release.

The goal of the streaming runtime is to enable workloads to consume, process, and produce message streams, in conjunction with streaming platforms like Kafka.

Streaming component development can be tracked on GitHub, including:

riff CLI

The riff CLI was rewritten from the ground up to support the new riff Build and Runtime models. The CLI behavior is more consistent and predictable. No more deleting a "service" which was created as a function.

The most significant change is that creating a function builds the container image, but it no longer deploys the function as a Knative workload. Functions are deployed using the deployment features of the runtime, and Knative is just one runtime option

riff is no longer installed into a Kubernetes cluster using the CLI. Helm charts are available to aid the installation, and we are exploring other installation options, like Cloud Native Application Bundles (CNAB).

Other highlights of the new CLI include:

  • table listings with rolled up status
  • colorized output
  • --tail to watch logs during create until the resource is ready or fails
  • tail command to watch all logs for a resource until canceled
  • delete and list for every resource that is created

riff System and CRDs

Powering the new build and runtime models is riff System. riff System provides Kubernetes CRDs and a controller to reconcile the state of custom riff resources with other resources.

The system provides four API groups, one for builds and one per runtime:

  • build.projectriff.io/v1alpha1
    • Application - applications built from source using application buildpacks
    • Function - functions built from source using function buildpacks
    • Container - polls a container repository for updated images
  • core.projectriff.io/v1alpha1
    • Deployer - deployers map applications, functions, or containers to Kubernetes core resources: Deployment and Service
  • streaming.projectriff.io/v1alpha1
    • Stream - streams of messages
    • Processor - processors apply functions to messages on streams
  • knative.projectriff.io/v1alpha1
    • Adapter - adapters map applications, functions, or containers to an existing Knative Service or Configuration.
    • Deployer - deployers map applications, functions, or containers to Knative resources: Configuration and Route

The riff CLI is but one client that interacts with these CRDs. One the the design goals was to avoid deep knowledge of the system implementation in the CLI. All of that knowledge lives behind the CRDs and is managed by the system. We hope to see additional clients consume these CRDs to provide riff outcomes.

Helm charts

riff and its dependencies are published as Helm charts in a custom chart repository.

helm repo add projectriff https://projectriff.storage.googleapis.com/charts/releases

More information about the charts is available on GitHub.

Looking to the future

Recent Posts