func/docs
Luke Kingland e918f74b9e
feat!: invoke (#705)
* feat!: rename 'emit' to 'invoke' and default to local

This commit renames 'func emit' command to 'func invoke' and makes the
default behavior to send an event to localhost. The special '--sink'
value 'local' is changed to 'cluster' to indicate that the function
should be invoked on the cluster instead of locally. All other behavior
has remained the same.

BREAKING CHANGE

Signed-off-by: Lance Ball <lball@redhat.com>

* fixup: update commands.md doc

Signed-off-by: Lance Ball <lball@redhat.com>

* squash: change Emitter interface to Invoker

Changes Emit() to Send() in the (now named) Invoker interface, and changes
Emit() to Invoke() in the client.

BREAKING CHANGE

Signed-off-by: Lance Ball <lball@redhat.com>

* squash: use a common Invoker interface for HTTP and events

Signed-off-by: Lance Ball <lball@redhat.com>

* checkpoint

Signed-off-by: Lance Ball <lball@redhat.com>

* fixup: change Emitter to EventInvoker

Signed-off-by: Lance Ball <lball@redhat.com>

* Invoke v2 Draft

* feat: client invoke function

* static invoke defaults and methods

* remove assimilated invoker package

* includes an ignored .func directory on create

* Instances manager with local and remote defaults

Funciton Info is now Instance, representing a Function in a given
environment.

Describing a Function instance is now Instances().Get(f, environment)

Moves Runner to be async with a Stop method to enable returning runtime pid
and port for persisting.

Instances now have a place for primary Route in addition to all routes slice

Running Functions write PID and Port to .func

* cascading targets: local vs remote vs ad-hoc endpoint

* runner start signals and cancel cleanup

* return run on context done or err on channel

* async runner

Refactors the image runner to start the container asynchronously,
reporting back the port on which it started.  Errors are communicated
back via a provided channel and stop is signaled using context
cancelation.

* pid neither required nor available

* add withTransport option

Incorporates addition of custom transport of the emitter into the
renamed version invoker. Flag and help text cleanup.  Re-additionof the
Info accessor.

* schema now includes invocation data

* loop build msg

* run jobs

Externally exposed port is now chosen based on availability, with 8080
preferred and falling back to an os-chosen open port.
The Client Run method is now async, returning the port assigned to the
running Function, a stop/cleanup function and a runtime errors channel.
The Runner is internally divided into the runner and its started Jobs.

* job metadata

Extracts job metadata tracking to a Job object in the core,
Handles multiple instances of the same Function by creating a single
file for each instances in .func/instances/<port>

* remove superfluous error types and flag bindings

* feat: enable invoke target remote

* feat: preferentially invoke local, remote if running

* feat: read --file for invoke

* feat: invoke confirm prompts

* fixup cli tests

- Updates to handle asynchronous Runner
- Standardize on the naming convention for selective running

* docker runner tests and lint errors

* test refactor

* feat: invoke format override

* comments, spelling and other cleanup

* invoke command doc

* feat: invoke format interactive option

* rename runjob.go to job.go

* e2e test flag update

* test naming homoginization

* silence build activity messages when verbose

* test debugging

* code review updates

- return Job from Client.Run rather than constituent members
- Treat .gitignore as contentious, punting on feature to mutate if
  extant.
- docs wording changes
- add invocation format to pertinent manifest.yaml files

* help text spelling etc.

Co-authored-by: Lance Ball <lball@redhat.com>
2022-01-21 12:04:05 -08:00
..
guides feat!: invoke (#705) 2022-01-21 12:04:05 -08:00
knative rename function -> func (#217) 2020-11-06 12:47:30 +01:00
provisioning docs: major overhaul of docs (#284) 2021-03-24 14:07:09 +01:00
tls docs: Kind cluster provisioning and TLS 2020-08-18 10:01:16 +09:00
DEVELOPMENT.md fix: move integration port to unregistered range (#701) 2021-12-07 15:05:38 -08:00
README.md doc: DEVELOPMENT.md (#432) 2021-07-23 07:01:45 -07:00
getting_started_kubernetes.md Change github.com links to the new home (#424) 2021-07-26 10:30:15 -07:00
getting_started_localhost.md Update getting_started_localhost.md (#672) 2021-11-22 03:59:14 -08:00
installing_cli.md Update installing_cli.md (#539) 2021-09-18 09:26:32 -07:00

README.md

Boson Functions

Telegram Image Analysis Demo Screencast

Telegram Image Analysis Demo Screencast

func is a Client Library and CLI for enabling the development of implicitly deployed, platform agnostic functions.

Functions can be written in the following languages:

  • Go (Golang)
  • Node.js (JavaScript)
  • Quarkus (Java)
  • SpringBoot (Java)
  • Python
  • Rust

Functions can be deployed on the following platforms:

  • Kubernetes
  • OpenShift
  • Localhost

Client Installation

Install the latest CLI

Functions can be created and managed using the CLI interactively, scripted, or by direct integration with the client library. The Function Developer's Guide and examples herein demonstrate the CLI-based approach.

For direct integration using the Go client library, it is advisible to first follow these CLI-based guides to become familiar with creating and deploying software in this way, and then proceed to the Function Integrator's Guide.

Platform Configuration

Getting Started with Kubernetes

Getting Started on Localhost

Functions are portable between different infrastructure configurations. While your Function itself remains the same, the platform upon which it is deployed will provide different services and guarantees. For instance, a Function deployed to your local host will not autoscale, nor be highly available nor externally routable by default. Deploying to a properly configured Kubernetes cluster would however provide these features. There is also variance within infrastrucutre types. For instance, a small kubernetes cluster will be limited in the amount of resources which will be ultimately available for allocation to your Function.

Function Development

Function Developer's Guide

Any code which provides one of a set of supported function signatures can be deployed to any of the supported platforms using this client library. No process boundary code, container, or configuration outside of the function itself is required.

At their most fundamental, a Function is a set of instructions which export a public function whose method signature conforms to one of the supported forms. It is implicitly deployed to a supported platform when created using the client library, and can be migrated between platforms without code changes. Runtime execution is handled by the platform, which may offer guarantees such as autoscaling and load balancing.

Contributing

We are always looking for contributions to the project from the Function Developer community. For more information on how to participate, see the Development Guide