Documentation Revamp (#496)
Added a new documentation structure with details of concepts, tutorials and examples
This commit is contained in:
Vishal
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Fission Concepts"
|
||||
chapter: true
|
||||
draft: false
|
||||
weight: 30
|
||||
---
|
||||
|
||||
# Fission Concepts
|
||||
|
||||
#### Understanding Fission terminology and concepts
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Environment"
|
||||
draft: false
|
||||
weight: 32
|
||||
---
|
||||
|
||||
An environment contains the language and runtime specific parts of a function. An environment is essentially a container with a webserver and a dynamic loader for the function code.
|
||||
|
||||
The following pre-built environments are currently available for use in Fission:
|
||||
|
||||
| Environment | Image |
|
||||
| ------------------------------------ | ------------------------- |
|
||||
| Binary (for executables or scripts) | `fission/binary-env` |
|
||||
| Go | `fission/go-env` |
|
||||
| .NET | `fission/dotnet-env` |
|
||||
| .NET 2.0 | `fission/dotnet20-env` |
|
||||
| NodeJS (Alpine) | `fission/node-env` |
|
||||
| NodeJS (Debian) | `fission/node-env-debian` |
|
||||
| Perl | `fission/perl-env` |
|
||||
| PHP 7 | `fission/php-env` |
|
||||
| Python 3 | `fission/python-env` |
|
||||
| Ruby | `fission/ruby-env` |
|
||||
|
||||
To create custom environments you can extend one of the environments in the list or create your own environment from scratch.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Controlling Function Execution"
|
||||
draft: false
|
||||
weight: 33
|
||||
---
|
||||
# Executors
|
||||
|
||||
When you create a function, you can specify an executor for a function. An executor controls how function pods are created and what capabilities are available for that executor type.
|
||||
|
||||
## Pool-based executor
|
||||
|
||||
A pool based executor (Refered to as poolmgr) creates a pool of generic environment pods as soon as you create an environment. The pool size of initial "warm" containers can be configured based on user needs. These warm containers contain a small dynamic loader for loading the function. Resource requirements are specified at environment level and are inherited by specialized function pods.
|
||||
|
||||
Once you create a function and invoke it, one of pods from the pool is taken out and "specialized" and used for execution. This pod is used for subseqnent requests for that function. If there are no more requests for a certain idle duration, then this pod is cleaned up. If a new requests come after the earlier specialized pod was cleaned up, then a new pod is specialised from the pool and used for execution.
|
||||
|
||||
Poolmgr executortype is great for functions where lower latency is a requirement. Poolmgr executortype has certain limitations: for example, you can not autoscale them based on demand.
|
||||
|
||||
|
||||
## New-deployment executor
|
||||
|
||||
New-Deployment executor (Newdeploy) creates a Kubernetes Deployment along with a Service and HorizontalPodAutoscaler for function execution. This enables autoscaling of function pods and load balancing the requests between pods. In future additional capabilities will be added for newdeploy executortype such as support for volume etc. In the new-deploy executor, resource requirements can be specified at the function level. These requirements override those specified in the environment.
|
||||
|
||||
Newdeploy executortype can be used for requests with no particular low-latency requirements, such as those invoked asynchronously, minscale can be set to zero. In this case the Kubernetes deployment and other objects will be created on first invocation of the function. Subsequent requests can be served by the same deployment. If there are no requests for certain duration then the idle objects are cleaned up. This mechanism ensures resource consumption only on demand and is a good fit for asynchronous requests.
|
||||
|
||||
For requests where latency requirements are stringent, a minscale greater than zero can be set. This essentially keeps a minscale number of pods ready when you create a function. When the function is invoked, there is no delay since the pod is already created. Also minscale ensures that the pods are not cleaned up even if the function is idle. This is great for functions where lower latency is more important than saving resource consumption when functions are idle.
|
||||
|
||||
### The latency vs. idle-cost tradeoff
|
||||
|
||||
The executors allow you as a user to decide between latency and a small idle cost tradeoff. Depending on the need you can choose one of the combinations which is optimal for your use case. In future, a more intelligent dispatch mechanism will enable more complex combinations of executors.
|
||||
|
||||
| Executor Type | Min Scale| Latency | Idle cost |
|
||||
|:---------|:---------:|:---------:|:---------|
|
||||
|Newdeploy|0|High|Very low - pods get cleaned up after idlle time|
|
||||
|Newdeploy|>0|Low|Medium, Min Scale number of pods are always up|
|
||||
|Poolmgr|0|Low|Low, pool of pods are always up|
|
||||
|
||||
### Autoscaling
|
||||
|
||||
The new deployment based executor provides autoscaling for functions based on CPU usage. In future custom metrics will be also supported for scaling the functions. You can set the intial and maximum CPU for a function and target CPU at which autoscaling will be trigerred. Autoscaling is useful for workloads where you expect intermittant spikes in workloads. It also enables optimal usage of resources to execute functions, by using a baseline capacity with minimum scale and ability to burst up to maximum scale based on spikes in demand.
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "Function"
|
||||
draft: true
|
||||
weight: 31
|
||||
---
|
||||
A function is a piece of code that will be invoked based on a [trigger](../trigger). The code follows the Fission interface. In practice, the function is only an entry point for execution and it can be backed by a larger program or module.
|
||||
|
||||
A function is registered with Fission through a CLI and associated with a trigger. A function can be created based on a single source file or a source archive or a deployment archive.
|
||||
|
||||
It is possible to associate and use Kubernetes secrets and configmaps with a function.
|
||||
|
||||
Functions also accept minimum and maximum CPU and memory to be assigned, the behaviour of which varies based on executor types which are discussed in greater detail [here](../executor)
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "Builder and Packages"
|
||||
draft: false
|
||||
weight: 36
|
||||
---
|
||||
|
||||
Most real world applications are more than a single file of code and typically have dependencies on libraries etc. Packages in fission solve three distinct problems:
|
||||
|
||||
1) Enable a mechanism to store more than one file as a single unit and use them with functions. This is done through a combination of deployment archive builder environment associated with the environment.
|
||||
|
||||
2) Provide a mechanism to build from source code and dependencies into a binary based on a build command and store it as an object. User should be able to use this built artifact with a function. This is achieved with a source archive and a builder environment.
|
||||
|
||||
3) Decouple the execution logic from the functions and thus enable reuse of same logic for multiple functions. This will enable user to run same logic with different functions having different runtime charateristics and executor types.
|
||||
|
||||
When you create a function with a single source file, fission internally creates a package and links it to a function. Creating a package explicitly gives more flexibility in some use cases as explained above.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Trigger"
|
||||
draft: false
|
||||
weight: 34
|
||||
---
|
||||
|
||||
Triggers are events that can invoke a [function](../function). Fission has three kinds of triggers that can be used to invoke functions.
|
||||
|
||||
## Http Trigger
|
||||
|
||||
HTTP triggers enable calling functions with HTTP requests. Supported methods are GET, POST, PUT, DELETE, HEAD and by default GET is used. URL pattern follow the gorilla/mux supported patterns.
|
||||
|
||||
## Time Trigger
|
||||
|
||||
If you want a function to be called at a periodic frequency then the time triggers are perfect for the use case. Time triggers follow cron like specifications and are invoked based on the cron schedule.
|
||||
|
||||
Time trigger based invocations are great for running scheduled jobs, periodic cleanup jobs, periodic polling based invocations etc.
|
||||
|
||||
## MQ Trigger
|
||||
|
||||
Message queue based trigger enables ability to listen on a topic and invoke a function for each message. You can optinally send a response to another topic. By default it is assumed that the messages in queue are in application/json format but you can specify otherwise while creating the trigger. Currently `nats-streaming` and `azure-storage-queue` are supported message queues supported.
|
||||
|
||||
MQ triggers are great for integrating various systems in a decoupled and asynchronous manner.
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Contributing to Fission"
|
||||
draft: false
|
||||
weight: 50
|
||||
chapter: true
|
||||
---
|
||||
|
||||
# Contributing to Fission
|
||||
|
||||
### Development guide
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
title: "Compiling Fission"
|
||||
date: 2017-09-07T20:10:05-07:00
|
||||
draft: false
|
||||
weight: 1
|
||||
weight: 51
|
||||
---
|
||||
|
||||
[You only need to do this if you're making Fission changes; if you're
|
||||
@@ -1,181 +1,10 @@
|
||||
---
|
||||
title: "Installation Guide"
|
||||
date: 2017-09-07T20:10:05-07:00
|
||||
draft: false
|
||||
weight: 20
|
||||
chapter : true
|
||||
---
|
||||
|
||||
Welcome! This guide will get you up and running with Fission on a
|
||||
Kubernetes cluster.
|
||||
|
||||
### Cluster preliminaries
|
||||
|
||||
If you don't have a Kubernetes cluster, [here's a quick guide to set
|
||||
one up](../kubernetessetup).
|
||||
|
||||
Let's ensure you have the Kubernetes CLI and Helm installed and
|
||||
ready. If you already have helm, [skip ahead to the fission install](#install-fission).
|
||||
|
||||
#### Kubernetes CLI
|
||||
|
||||
Ensure you have the Kubernetes CLI.
|
||||
|
||||
You can get the Kubernetes CLI for OSX like this:
|
||||
```
|
||||
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin
|
||||
```
|
||||
|
||||
Or, for Linux:
|
||||
```
|
||||
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin
|
||||
```
|
||||
|
||||
Ensure you have access to a cluster; use kubectl to check your
|
||||
Kubernetes version:
|
||||
|
||||
```
|
||||
$ kubectl version
|
||||
```
|
||||
|
||||
We need at least Kubernetes 1.6 (older versions may work, but we don't
|
||||
test them).
|
||||
|
||||
#### Helm
|
||||
|
||||
Helm is an installer for Kubernetes. If you already use helm, [skip to
|
||||
the next section](#install-fission).
|
||||
|
||||
First, you'll need the helm CLI:
|
||||
|
||||
On __OS X__:
|
||||
```
|
||||
$ curl -LO https://storage.googleapis.com/kubernetes-helm/helm-v2.7.0-darwin-amd64.tar.gz
|
||||
|
||||
$ tar xzf helm-v2.7.0-darwin-amd64.tar.gz
|
||||
|
||||
$ mv darwin-amd64/helm /usr/local/bin
|
||||
```
|
||||
|
||||
On __Linux__:
|
||||
```
|
||||
$ curl -LO https://storage.googleapis.com/kubernetes-helm/helm-v2.7.0-linux-amd64.tar.gz
|
||||
|
||||
$ tar xzf helm-v2.7.0-linux-amd64.tar.gz
|
||||
|
||||
$ mv linux-amd64/helm /usr/local/bin
|
||||
```
|
||||
|
||||
Next, install the Helm server on your Kubernetes cluster:
|
||||
|
||||
```
|
||||
$ helm init
|
||||
```
|
||||
|
||||
### Install Fission
|
||||
|
||||
#### Minikube
|
||||
|
||||
```
|
||||
$ helm install --namespace fission --set serviceType=NodePort https://github.com/fission/fission/releases/download/0.5.0/fission-all-0.5.0.tgz
|
||||
```
|
||||
|
||||
The serviceType variable allows configuring the type of Kubernetes
|
||||
service outside the cluster. You can use `ClusterIP` if you don't
|
||||
want to expose anything outside the cluster.
|
||||
|
||||
#### Cloud hosted clusters (GKE, AWS, Azure etc.)
|
||||
|
||||
```
|
||||
$ helm install --namespace fission https://github.com/fission/fission/releases/download/0.5.0/fission-all-0.5.0.tgz
|
||||
```
|
||||
|
||||
#### Minimal version
|
||||
|
||||
The fission-all helm chart installs a full set of services including
|
||||
the NATS message queue, influxDB for logs, etc. If you want a more
|
||||
minimal setup, you can install the fission-core chart instead:
|
||||
|
||||
```
|
||||
$ helm install --namespace fission https://github.com/fission/fission/releases/download/0.5.0/fission-core-0.5.0.tgz
|
||||
```
|
||||
|
||||
### Install the Fission CLI
|
||||
|
||||
#### OS X
|
||||
|
||||
Get the CLI binary for Mac:
|
||||
|
||||
```
|
||||
$ curl -Lo fission https://github.com/fission/fission/releases/download/0.5.0/fission-cli-osx && chmod +x fission && sudo mv fission /usr/local/bin/
|
||||
```
|
||||
|
||||
#### Linux
|
||||
|
||||
```
|
||||
$ curl -Lo fission https://github.com/fission/fission/releases/download/0.5.0/fission-cli-linux && chmod +x fission && sudo mv fission /usr/local/bin/
|
||||
```
|
||||
|
||||
#### Windows
|
||||
|
||||
For Windows, you can use the linux binary on WSL. Or you can download
|
||||
this windows executable: [fission.exe](https://github.com/fission/fission/releases/download/0.5.0/fission-cli-windows.exe)
|
||||
|
||||
### Set environment vars
|
||||
|
||||
Set the FISSION_URL and FISSION_ROUTER environment variables.
|
||||
FISSION_URL is used by the fission CLI to find the server.
|
||||
(FISSION_ROUTER is only needed for the examples below to work.)
|
||||
|
||||
#### Minikube
|
||||
|
||||
If you're using minikube, use these commands:
|
||||
|
||||
```
|
||||
$ export FISSION_URL=http://$(minikube ip):31313
|
||||
$ export FISSION_ROUTER=$(minikube ip):31314
|
||||
```
|
||||
#### Cloud setups
|
||||
|
||||
Save the external IP addresses of controller and router services in
|
||||
FISSION_URL and FISSION_ROUTER, respectively. Wait for services to
|
||||
get IP addresses (check this with ```kubectl --namespace fission get
|
||||
svc```). Then:
|
||||
|
||||
##### AWS
|
||||
```
|
||||
$ export FISSION_URL=http://$(kubectl --namespace fission get svc controller -o=jsonpath='{..hostname}')
|
||||
$ export FISSION_ROUTER=$(kubectl --namespace fission get svc router -o=jsonpath='{..hostname}')
|
||||
```
|
||||
|
||||
##### GCP
|
||||
```
|
||||
$ export FISSION_URL=http://$(kubectl --namespace fission get svc controller -o=jsonpath='{..ip}')
|
||||
$ export FISSION_ROUTER=$(kubectl --namespace fission get svc router -o=jsonpath='{..ip}')
|
||||
```
|
||||
|
||||
### Run an example
|
||||
|
||||
Finally, you're ready to use Fission!
|
||||
|
||||
```
|
||||
$ fission env create --name nodejs --image fission/node-env:0.5.0
|
||||
|
||||
$ curl -LO https://raw.githubusercontent.com/fission/fission/master/examples/nodejs/hello.js
|
||||
|
||||
$ fission function create --name hello --env nodejs --code hello.js
|
||||
|
||||
$ fission route create --method GET --url /hello --function hello
|
||||
|
||||
$ curl http://$FISSION_ROUTER/hello
|
||||
Hello, world!
|
||||
```
|
||||
|
||||
### What's next?
|
||||
|
||||
If something went wrong, we'd love to help -- please [drop by the
|
||||
slack channel](http://slack.fission.io) and ask for help.
|
||||
|
||||
Check out the
|
||||
[examples](https://github.com/fission/fission/tree/master/examples)
|
||||
for some example functions.
|
||||
# Installation
|
||||
|
||||
### Installing and upgrading Fission
|
||||
@@ -0,0 +1,179 @@
|
||||
---
|
||||
title: "Installation Guide"
|
||||
draft: false
|
||||
weight: 20
|
||||
---
|
||||
|
||||
Welcome! This guide will get you up and running with Fission on a
|
||||
Kubernetes cluster.
|
||||
|
||||
### Cluster preliminaries
|
||||
|
||||
If you don't have a Kubernetes cluster, [here's a quick guide to set
|
||||
one up](../kubernetessetup).
|
||||
|
||||
Let's ensure you have the Kubernetes CLI and Helm installed and
|
||||
ready. If you already have helm, [skip ahead to the fission install](#install-fission).
|
||||
|
||||
#### Kubernetes CLI
|
||||
|
||||
Ensure you have the Kubernetes CLI.
|
||||
|
||||
You can get the Kubernetes CLI for OSX like this:
|
||||
```
|
||||
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin
|
||||
```
|
||||
|
||||
Or, for Linux:
|
||||
```
|
||||
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin
|
||||
```
|
||||
|
||||
Ensure you have access to a cluster; use kubectl to check your
|
||||
Kubernetes version:
|
||||
|
||||
```
|
||||
$ kubectl version
|
||||
```
|
||||
|
||||
We need at least Kubernetes 1.6 (older versions may work, but we don't
|
||||
test them).
|
||||
|
||||
#### Helm
|
||||
|
||||
Helm is an installer for Kubernetes. If you already use helm, [skip to
|
||||
the next section](#install-fission).
|
||||
|
||||
First, you'll need the helm CLI:
|
||||
|
||||
On __OS X__:
|
||||
```
|
||||
$ curl -LO https://storage.googleapis.com/kubernetes-helm/helm-v2.7.0-darwin-amd64.tar.gz
|
||||
|
||||
$ tar xzf helm-v2.7.0-darwin-amd64.tar.gz
|
||||
|
||||
$ mv darwin-amd64/helm /usr/local/bin
|
||||
```
|
||||
|
||||
On __Linux__:
|
||||
```
|
||||
$ curl -LO https://storage.googleapis.com/kubernetes-helm/helm-v2.7.0-linux-amd64.tar.gz
|
||||
|
||||
$ tar xzf helm-v2.7.0-linux-amd64.tar.gz
|
||||
|
||||
$ mv linux-amd64/helm /usr/local/bin
|
||||
```
|
||||
|
||||
Next, install the Helm server on your Kubernetes cluster:
|
||||
|
||||
```
|
||||
$ helm init
|
||||
```
|
||||
|
||||
### Install Fission
|
||||
|
||||
#### Minikube
|
||||
|
||||
```
|
||||
$ helm install --namespace fission --set serviceType=NodePort https://github.com/fission/fission/releases/download/0.5.0/fission-all-0.5.0.tgz
|
||||
```
|
||||
|
||||
The serviceType variable allows configuring the type of Kubernetes
|
||||
service outside the cluster. You can use `ClusterIP` if you don't
|
||||
want to expose anything outside the cluster.
|
||||
|
||||
#### Cloud hosted clusters (GKE, AWS, Azure etc.)
|
||||
|
||||
```
|
||||
$ helm install --namespace fission https://github.com/fission/fission/releases/download/0.5.0/fission-all-0.5.0.tgz
|
||||
```
|
||||
|
||||
#### Minimal version
|
||||
|
||||
The fission-all helm chart installs a full set of services including
|
||||
the NATS message queue, influxDB for logs, etc. If you want a more
|
||||
minimal setup, you can install the fission-core chart instead:
|
||||
|
||||
```
|
||||
$ helm install --namespace fission https://github.com/fission/fission/releases/download/0.5.0/fission-core-0.5.0.tgz
|
||||
```
|
||||
|
||||
### Install the Fission CLI
|
||||
|
||||
#### OS X
|
||||
|
||||
Get the CLI binary for Mac:
|
||||
|
||||
```
|
||||
$ curl -Lo fission https://github.com/fission/fission/releases/download/0.5.0/fission-cli-osx && chmod +x fission && sudo mv fission /usr/local/bin/
|
||||
```
|
||||
|
||||
#### Linux
|
||||
|
||||
```
|
||||
$ curl -Lo fission https://github.com/fission/fission/releases/download/0.5.0/fission-cli-linux && chmod +x fission && sudo mv fission /usr/local/bin/
|
||||
```
|
||||
|
||||
#### Windows
|
||||
|
||||
For Windows, you can use the linux binary on WSL. Or you can download
|
||||
this windows executable: [fission.exe](https://github.com/fission/fission/releases/download/0.5.0/fission-cli-windows.exe)
|
||||
|
||||
### Set environment vars
|
||||
|
||||
Set the FISSION_URL and FISSION_ROUTER environment variables.
|
||||
FISSION_URL is used by the fission CLI to find the server.
|
||||
(FISSION_ROUTER is only needed for the examples below to work.)
|
||||
|
||||
#### Minikube
|
||||
|
||||
If you're using minikube, use these commands:
|
||||
|
||||
```
|
||||
$ export FISSION_URL=http://$(minikube ip):31313
|
||||
$ export FISSION_ROUTER=$(minikube ip):31314
|
||||
```
|
||||
#### Cloud setups
|
||||
|
||||
Save the external IP addresses of controller and router services in
|
||||
FISSION_URL and FISSION_ROUTER, respectively. Wait for services to
|
||||
get IP addresses (check this with ```kubectl --namespace fission get
|
||||
svc```). Then:
|
||||
|
||||
##### AWS
|
||||
```
|
||||
$ export FISSION_URL=http://$(kubectl --namespace fission get svc controller -o=jsonpath='{..hostname}')
|
||||
$ export FISSION_ROUTER=$(kubectl --namespace fission get svc router -o=jsonpath='{..hostname}')
|
||||
```
|
||||
|
||||
##### GCP
|
||||
```
|
||||
$ export FISSION_URL=http://$(kubectl --namespace fission get svc controller -o=jsonpath='{..ip}')
|
||||
$ export FISSION_ROUTER=$(kubectl --namespace fission get svc router -o=jsonpath='{..ip}')
|
||||
```
|
||||
|
||||
### Run an example
|
||||
|
||||
Finally, you're ready to use Fission!
|
||||
|
||||
```
|
||||
$ fission env create --name nodejs --image fission/node-env:0.5.0
|
||||
|
||||
$ curl -LO https://raw.githubusercontent.com/fission/fission/master/examples/nodejs/hello.js
|
||||
|
||||
$ fission function create --name hello --env nodejs --code hello.js
|
||||
|
||||
$ fission route create --method GET --url /hello --function hello
|
||||
|
||||
$ curl http://$FISSION_ROUTER/hello
|
||||
Hello, world!
|
||||
```
|
||||
|
||||
### What's next?
|
||||
|
||||
If something went wrong, we'd love to help -- please [drop by the
|
||||
slack channel](http://slack.fission.io) and ask for help.
|
||||
|
||||
Check out the
|
||||
[examples](https://github.com/fission/fission/tree/master/examples)
|
||||
for some example functions.
|
||||
+2
-2
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Kubernetes Quick Install"
|
||||
date: 2017-09-07T20:10:05-07:00
|
||||
weight: 10
|
||||
draft: false
|
||||
weight: 21
|
||||
---
|
||||
|
||||
This is a quick guide to help you get started running Kubernetes on
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "Release notes"
|
||||
draft: false
|
||||
weight: 22
|
||||
---
|
||||
|
||||
- The fission team is on http://slack.fission.io if you have any questions.
|
||||
|
||||
### 0.4.0
|
||||
|
||||
- This release is compatible with Kubernetes 1.7 onwards.
|
||||
- We switched from ThirdPartyResources to CustomResourceDefinitions. ThirdPartyResources are removed in Kubernetes 1.8, so upgrade with caution, using the upgrade guide below.
|
||||
- Upgrade guides:
|
||||
- [Upgrade guide from 0.3.0](../upgrade/upgrade-from-v0.3)
|
||||
- To upgrade from 0.2.1, please upgrade to 0.3.0 first, following the upgrade guide in the 0.3.0 release.
|
||||
|
||||
### 0.3.0
|
||||
|
||||
Note: This release is incompatible with Kubernetes 1.8 (Because it uses ThirdPartyResources; see #314)
|
||||
|
||||
This release introduces:
|
||||
|
||||
- Build pipeline. Currently, only the Python environment supports this.
|
||||
- Workflow engine support (compatible with fission-workflows 0.1.1)
|
||||
|
||||
### v0.2.1
|
||||
|
||||
Lots of big changes in this release!
|
||||
|
||||
- Most importantly, the API has changed a lot. We switched to Kubernetes
|
||||
ThirdPartyResources, and improved various pieces of the API to support
|
||||
new environments.
|
||||
|
||||
- The old API was too different from widely used Kubernetes patterns,
|
||||
and so we decided to fully break compatibility for this release. We're still in
|
||||
alpha, so you should expect the occasional API breakage; we'll be
|
||||
better at preserving compatibility once we reach beta.
|
||||
|
||||
- The CLI is still compatible. Environments are also still compatible --
|
||||
environment images that worked before continue to work.
|
||||
|
||||
- We're creating an upgrade tool to help migrate; if you're upgrading
|
||||
v0.1.0 and can't do a fresh install, wait for the upgrade tool.
|
||||
|
||||
- We now use Helm for installation instead of a set of YAML files.
|
||||
|
||||
- The Fission "controller" is now stateless. Fission's etcd deployment
|
||||
is removed, since Fission stores state in ThirdPartyResources. Large
|
||||
function files are stored in a new function storage service, which
|
||||
uses a persistent volume.
|
||||
|
||||
- And, we've started a new docs site; for now it's just the installation
|
||||
and upgrade guides, but we'll be writing more docs soon.
|
||||
+1
-2
@@ -1,6 +1,5 @@
|
||||
---
|
||||
title: "Upgrade"
|
||||
date: 2017-09-07T20:10:05-07:00
|
||||
weight: 30
|
||||
---
|
||||
|
||||
@@ -11,4 +10,4 @@ weight: 30
|
||||
* [Upgrade guide](upgrade-from-v0.3)
|
||||
|
||||
### From v0.1 to v0.2.x
|
||||
* [Upgade guide](upgrade-from-v0.1)
|
||||
* [Upgrade guide](upgrade-from-v0.1)
|
||||
-1
@@ -1,6 +1,5 @@
|
||||
---
|
||||
title: "Upgrading from v0.1 to v0.2.x"
|
||||
date: 2017-09-08T16:26:29-07:00
|
||||
draft: false
|
||||
weight: 31
|
||||
---
|
||||
-1
@@ -1,6 +1,5 @@
|
||||
---
|
||||
title: "Upgrading from v0.3 to v0.4.x"
|
||||
date: 2017-11-04T03:38:29+08:00
|
||||
draft: false
|
||||
weight: 32
|
||||
---
|
||||
-1
@@ -1,6 +1,5 @@
|
||||
---
|
||||
title: "Upgrading from v0.4.x to v0.5.0"
|
||||
date: 2018-2-08T04:40:29+08:00
|
||||
draft: false
|
||||
weight: 33
|
||||
---
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
title: "Tutorials"
|
||||
weight: 40
|
||||
---
|
||||
|
||||
* [Access Secret/ConfigMap In Function](./access-secret-cfgmap-in-function)
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Using Fission"
|
||||
chapter: true
|
||||
draft: false
|
||||
weight: 40
|
||||
---
|
||||
|
||||
# Using Fission
|
||||
|
||||
### Usage guides, tutorials and examples
|
||||
+2
-2
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Access secret/configmap in function"
|
||||
title: "Accessing Secret/configmap in function"
|
||||
draft: false
|
||||
weight: 41
|
||||
weight: 47
|
||||
---
|
||||
|
||||
From fission v0.5.0 and later, functions are able to access [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) and [ConfigMaps](https://kubernetes.io/docs/concepts/storage/volumes/#configmap) specified by users.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Environment"
|
||||
draft: false
|
||||
weight: 42
|
||||
---
|
||||
|
||||
### Create an environment
|
||||
|
||||
You can create an environment on your cluster from an image for that language. Optionally, you can specify CPU and memory resource limits. You can also specify the number of initially pre-warmed pods, which is called the poolsize.
|
||||
|
||||
```
|
||||
fission env create --name node --image fission/node-env:0.4.0 --mincpu 40 --maxcpu 80 --minmemory 64 --maxmemory 128 --poolsize 4
|
||||
```
|
||||
|
||||
In case of pool based executor, the resources specified for environment are used for function pod as well. In case of new deployment executor, you can override the resources when you create a function.
|
||||
|
||||
### Using a builder
|
||||
|
||||
When you create an environment, you can specify a builder image and builder command which will be used for building from source code. You can override the build command when creating a function. For more details on builder and packages you should check out examples in [Functions](../functions) and [packages](../package)
|
||||
|
||||
```
|
||||
fission env create --name python --image fission/python-env:latest --builder fission/python-builder:latest
|
||||
```
|
||||
|
||||
### Viweing environment information
|
||||
|
||||
You can list the environments or view information of an individual environment:
|
||||
|
||||
```
|
||||
$ fission env list
|
||||
NAME UID IMAGE POOLSIZE MINCPU MAXCPU MINMEMORY MAXMEMORY
|
||||
node ac84d62e-001f-11e8-85c9-42010aa00010 fission/node-env:0.4.0 4 40m 80m 64Mi 128Mi
|
||||
$
|
||||
$ fission env get --name node
|
||||
NAME UID IMAGE
|
||||
node ac84d62e-001f-11e8-85c9-42010aa00010 fission/node-env:0.4.0
|
||||
```
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: "Controlling Function Execution"
|
||||
draft: false
|
||||
weight: 43
|
||||
---
|
||||
|
||||
### Autoscaling
|
||||
|
||||
Let's create a function to demonstrate the autoscaling behaviour in Fission. We create a simple function which outputs "Hello World" in using NodeJS. We have kept the CPU request and limit purposefully low to simulate the load and also kept the target CPU percent to 50%.
|
||||
|
||||
```
|
||||
$ fission fn create --name hello --env node --code hello.js --mincpu 10 --maxcpu 40 --minmemory 64 --maxmemory 128 --minscale 1 --maxscale 6 --executortype newdeploy --targetcpu 50
|
||||
function 'hello' created
|
||||
```
|
||||
|
||||
Now let's use [hey](https://github.com/rakyll/hey) to generate the load with 250 concurrent and a total of 10000 requests:
|
||||
|
||||
```
|
||||
$ hey -c 250 -n 10000 http://$FISSION_ROUTER/hello
|
||||
Summary:
|
||||
Total: 67.3535 secs
|
||||
Slowest: 4.6192 secs
|
||||
Fastest: 0.0177 secs
|
||||
Average: 1.6464 secs
|
||||
Requests/sec: 148.4704
|
||||
Total data: 160000 bytes
|
||||
Size/request: 16 bytes
|
||||
|
||||
Response time histogram:
|
||||
0.018 [1] |
|
||||
0.478 [486] |∎∎∎∎∎∎∎
|
||||
0.938 [971] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎
|
||||
1.398 [2686] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
|
||||
1.858 [2326] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
|
||||
2.318 [1641] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
|
||||
2.779 [1157] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
|
||||
3.239 [574] |∎∎∎∎∎∎∎∎∎
|
||||
3.699 [120] |∎∎
|
||||
4.159 [0] |
|
||||
4.619 [38] |∎
|
||||
|
||||
Latency distribution:
|
||||
10% in 0.7037 secs
|
||||
25% in 1.1979 secs
|
||||
50% in 1.5038 secs
|
||||
75% in 2.1959 secs
|
||||
90% in 2.6670 secs
|
||||
95% in 2.8855 secs
|
||||
99% in 3.4102 secs
|
||||
|
||||
Details (average, fastest, slowest):
|
||||
DNS+dialup: 0.0058 secs, 0.0000 secs, 1.0853 secs
|
||||
DNS-lookup: 0.0000 secs, 0.0000 secs, 0.0000 secs
|
||||
req write: 0.0000 secs, 0.0000 secs, 0.0026 secs
|
||||
resp wait: 1.6405 secs, 0.0176 secs, 3.6144 secs
|
||||
resp read: 0.0001 secs, 0.0000 secs, 0.0056 secs
|
||||
|
||||
Status code distribution:
|
||||
[200] 10000 responses
|
||||
|
||||
```
|
||||
While the load is being generated, we will watch the HorizontalPodAutoscaler and how it scales over period of time. As you can notice, the number of pods is scaled from 1 to 3 after the load rises from 8 - 103%. After the load generator stops, it takes a few iterations to scale down from 3 to 1 pod.
|
||||
|
||||
```
|
||||
$ k -n fission-function get hpa -w
|
||||
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 5% / 50% 1 6 1 3m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 8% / 50% 1 6 1 3m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 103% / 50% 1 6 1 4m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 103% / 50% 1 6 3 5m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 25% / 50% 1 6 3 5m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 25% / 50% 1 6 3 6m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 5% / 50% 1 6 3 6m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 5% / 50% 1 6 3 7m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 5% / 50% 1 6 3 7m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 5% / 50% 1 6 3 8m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 5% / 50% 1 6 3 8m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 5% / 50% 1 6 3 9m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 5% / 50% 1 6 3 9m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 5% / 50% 1 6 3 10m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 5% / 50% 1 6 3 10m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 7% / 50% 1 6 1 11m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 6% / 50% 1 6 1 11m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 6% / 50% 1 6 1 12m
|
||||
hello-qoxmothj Deployment/hello-qoxmothj 6% / 50% 1 6 1 12m
|
||||
```
|
||||
@@ -0,0 +1,238 @@
|
||||
---
|
||||
title: "Function"
|
||||
draft: false
|
||||
weight: 41
|
||||
---
|
||||
|
||||
### Create a function
|
||||
|
||||
Before creating a function the environment should be created, we will assume that you have already created environment named `node`.
|
||||
|
||||
Let's create a simple code snippet in nodejs which will output Hello world:
|
||||
|
||||
```
|
||||
module.exports = async function(context) {
|
||||
return {
|
||||
status: 200,
|
||||
body: "Hello, world!\n"
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Let's create a route for the function which can be used for making HTTP requests:
|
||||
|
||||
```
|
||||
$ fission route create --function hello --url /hello
|
||||
trigger '5327e9a7-6d87-4533-a4fb-c67f55b1e492' created
|
||||
```
|
||||
|
||||
Let's create a function based on pool based executor.
|
||||
|
||||
```
|
||||
fission fn create --name hello --code hello.js --env node --executortype poolmgr
|
||||
```
|
||||
|
||||
When you hit this function's URL , you get a response:
|
||||
|
||||
```
|
||||
$ curl http://$FISSION_ROUTER/hello
|
||||
Hello, world!
|
||||
```
|
||||
Similarly you can create a new deployment executor type function and provide minmum and maximum scale for the function.
|
||||
|
||||
```
|
||||
fission fn create --name hello --code hello.js --env node --minscale 1 --maxscale 5 --executortype newdeploy
|
||||
```
|
||||
|
||||
### View & update function source code
|
||||
|
||||
You can look at the source code associated with given function:
|
||||
|
||||
```
|
||||
$ fission fn get --name hello
|
||||
module.exports = async function(context) {
|
||||
return {
|
||||
status: 200,
|
||||
body: "Hello, world!\n"
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Let's say you want to update the function to output "Hello Fission" instead of "Hello world", you can update the source file and update the source code for function:
|
||||
|
||||
```
|
||||
$ fission fn update --name hello --code ../hello.js
|
||||
package 'hello-js-ku9s' updated
|
||||
function 'hello' updated
|
||||
```
|
||||
|
||||
Let's verify that the function now respond with a different output than earlier:
|
||||
|
||||
```
|
||||
$ curl http://$FISSION_ROUTER/hello
|
||||
Hello, Fission!
|
||||
```
|
||||
|
||||
### Test and debug function
|
||||
|
||||
You can directly test a function using test command. If the function call succeeds, it will output the function's response.
|
||||
```
|
||||
$ fission fn test --name hello
|
||||
Hello, Fission!
|
||||
```
|
||||
|
||||
But if there is an error in function execution then the logs of function execution are displayed:
|
||||
```
|
||||
$ fission fn test --name hello
|
||||
Error calling function hello: 500 Internal server error (fission)
|
||||
|
||||
> fission-nodejs-runtime@0.1.0 start /usr/src/app
|
||||
> node server.js
|
||||
|
||||
Codepath defaulting to /userfunc/user
|
||||
Port defaulting to 8888
|
||||
user code load error: SyntaxError: Unexpected token function
|
||||
::ffff:10.8.1.181 - - [16/Feb/2018:08:44:33 +0000] "POST /specialize HTTP/1.1" 500 2 "-" "Go-http-client/1.1"
|
||||
|
||||
```
|
||||
|
||||
You can also look at function execution logs explicitly:
|
||||
```
|
||||
$ fission fn logs --name hello
|
||||
[2018-02-16 08:41:43 +0000 UTC] 2018/02/16 08:41:43 fetcher received fetch request and started downloading: {1 {hello-js-rqew default 0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] nil [] } user [] []}
|
||||
[2018-02-16 08:41:43 +0000 UTC] 2018/02/16 08:41:43 Successfully placed at /userfunc/user
|
||||
[2018-02-16 08:41:43 +0000 UTC] 2018/02/16 08:41:43 Checking secrets/cfgmaps
|
||||
[2018-02-16 08:41:43 +0000 UTC] 2018/02/16 08:41:43 Completed fetch request
|
||||
[2018-02-16 08:41:43 +0000 UTC] 2018/02/16 08:41:43 elapsed time in fetch request = 89.844653ms
|
||||
[2018-02-16 08:41:43 +0000 UTC] user code loaded in 0sec 4.235593ms
|
||||
[2018-02-16 08:41:43 +0000 UTC] ::ffff:10.8.1.181 - - [16/Feb/2018:08:41:43 +0000] "POST /specialize HTTP/1.1" 202 - "-" "Go-http-client/1.1"
|
||||
[2018-02-16 08:41:43 +0000 UTC] ::ffff:10.8.1.182 - - [16/Feb/2018:08:41:43 +0000] "GET / HTTP/1.1" 200 16 "-" "curl/7.54.0"
|
||||
```
|
||||
|
||||
### Fission builds & compiled artifacts
|
||||
|
||||
Most real world functions will require more than one source files. It is also easier to simply provide source files and let Fission take care of building from source files. Fission provides first class support for building from source as well as using compiled artifacts to create functions.
|
||||
|
||||
You can attach the source/deployment packages to a function or explicitly create packages and use them across functions. Check documentation for [package](../package) for more information.
|
||||
|
||||
#### Building function from source
|
||||
|
||||
Let's take a simple python function which has dependency on a python pyyaml module. We can specify the dependencies in requirements.txt and a simple command to build from source. The tree structure of directory looks like:
|
||||
|
||||
```
|
||||
sourcepkg/
|
||||
├── __init__.py
|
||||
├── build.sh
|
||||
├── requirements.txt
|
||||
└── user.py
|
||||
```
|
||||
And the file contents:
|
||||
```
|
||||
$ cat user.py
|
||||
import sys
|
||||
import yaml
|
||||
|
||||
document = """
|
||||
a: 1
|
||||
b:
|
||||
c: 3
|
||||
d: 4
|
||||
"""
|
||||
|
||||
def main():
|
||||
return yaml.dump(yaml.load(document))
|
||||
|
||||
$ cat requirements.txt
|
||||
pyyaml
|
||||
|
||||
$ cat build.sh
|
||||
#!/bin/sh
|
||||
pip3 install -r ${SRC_PKG}/requirements.txt -t ${SRC_PKG} && cp -r ${SRC_PKG} ${DEPLOY_PKG}
|
||||
```
|
||||
|
||||
You first need to create an environment with environment image and python-builder image specified:
|
||||
|
||||
```
|
||||
$fission env create --name python --image fission/python-env:latest --builder fission/python-builder:latest --mincpu 40 --maxcpu 80 --minmemory 64 --maxmemory 128 --poolsize 2
|
||||
```
|
||||
Now let's zip the directory containing the source files and create a function with source package:
|
||||
|
||||
```
|
||||
$zip -jr demo-src-pkg.zip sourcepkg/
|
||||
adding: __init__.py (stored 0%)
|
||||
adding: build.sh (deflated 24%)
|
||||
adding: requirements.txt (stored 0%)
|
||||
adding: user.py (deflated 25%)
|
||||
|
||||
$ fission fn create --name hellopy --env python --src demo-src-pkg.zip --entrypoint "user.main" --buildcmd "./build.sh"
|
||||
function 'hellopy' created
|
||||
|
||||
$ fission route create --function hellopy --url /hellopy
|
||||
```
|
||||
Once we create the function, the build process is started. You can check logs of the builder in fission-builder namespace:
|
||||
|
||||
```
|
||||
$ k -n fission-builder logs -f py3-4214348-59555d9bd8-ks7m4 builder
|
||||
2018/02/16 11:44:21 Builder received request: {demo-src-pkg-zip-ninf-djtswo ./build.sh}
|
||||
2018/02/16 11:44:21 Starting build...
|
||||
|
||||
=== Build Logs ===command=./build.sh
|
||||
env=[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=py3-4214348-59555d9bd8-ks7m4 PYTHON_4212095_PORT_8000_TCP_PROTO=tcp PY3_4214348_SERVICE_HOST=10.11.250.161 KUBERNETES_PORT=tcp://10.11.240.1:443 PYTHON_4212095_PORT=tcp://10.11.244.134:8000 PYTHON_4212095_PORT_8000_TCP=tcp://10.11.244.134:8000 PYTHON_4212095_PORT_8001_TCP_PROTO=tcp PYTHON_4212095_PORT_8001_TCP_ADDR=10.11.244.134 PY3_4214348_SERVICE_PORT=8000 PY3_4214348_SERVICE_PORT_BUILDER_PORT=8001 PY3_4214348_PORT_8001_TCP=tcp://10.11.250.161:8001 KUBERNETES_PORT_443_TCP_PORT=443 KUBERNETES_PORT_443_TCP_ADDR=10.11.240.1 PY3_4214348_SERVICE_PORT_FETCHER_PORT=8000 PY3_4214348_PORT_8000_TCP=tcp://10.11.250.161:8000 PY3_4214348_PORT_8001_TCP_PORT=8001 PYTHON_4212095_SERVICE_PORT_FETCHER_PORT=8000 PYTHON_4212095_PORT_8000_TCP_ADDR=10.11.244.134 KUBERNETES_SERVICE_HOST=10.11.240.1 PY3_4214348_PORT=tcp://10.11.250.161:8000 PYTHON_4212095_SERVICE_PORT_BUILDER_PORT=8001 PYTHON_4212095_PORT_8001_TCP=tcp://10.11.244.134:8001 PY3_4214348_PORT_8000_TCP_PROTO=tcp PY3_4214348_PORT_8000_TCP_PORT=8000 KUBERNETES_SERVICE_PORT_HTTPS=443 KUBERNETES_PORT_443_TCP=tcp://10.11.240.1:443 PYTHON_4212095_PORT_8001_TCP_PORT=8001 PY3_4214348_PORT_8000_TCP_ADDR=10.11.250.161 PY3_4214348_PORT_8001_TCP_PROTO=tcp KUBERNETES_SERVICE_PORT=443 PYTHON_4212095_SERVICE_PORT=8000 PYTHON_4212095_PORT_8000_TCP_PORT=8000 PY3_4214348_PORT_8001_TCP_ADDR=10.11.250.161 KUBERNETES_PORT_443_TCP_PROTO=tcp PYTHON_4212095_SERVICE_HOST=10.11.244.134 HOME=/root SRC_PKG=/packages/demo-src-pkg-zip-ninf-djtswo DEPLOY_PKG=/packages/demo-src-pkg-zip-ninf-djtswo-c40gfu]
|
||||
Collecting pyyaml (from -r /packages/demo-src-pkg-zip-ninf-djtswo/requirements.txt (line 1))
|
||||
Downloading PyYAML-3.12.tar.gz (253kB)
|
||||
Installing collected packages: pyyaml
|
||||
Running setup.py install for pyyaml: started
|
||||
Running setup.py install for pyyaml: finished with status 'done'
|
||||
Successfully installed pyyaml-3.12
|
||||
==================
|
||||
2018/02/16 11:44:24 elapsed time in build request = 3.460498847s
|
||||
```
|
||||
|
||||
Once the build has succeeded, you can hit the function URL to test the function:
|
||||
```
|
||||
$curl http://$FISSION_ROUTER/hellopy
|
||||
a: 1
|
||||
b: {c: 3, d: 4}
|
||||
```
|
||||
|
||||
#### Using compiled artifacts with Fission
|
||||
|
||||
In some cases you have a pre-built deployment package which you need to deploy to Fission. For this example let's use a simple python file as a deployment package but in practice it can be any other compiled package.
|
||||
|
||||
We will use a simple python file in a directory and turn it into a deployment package:
|
||||
|
||||
```
|
||||
$ cat testDir/hello.py
|
||||
def main():
|
||||
return "Hello, world!"
|
||||
|
||||
$zip -jr demo-deploy-pkg.zip testDir/
|
||||
|
||||
```
|
||||
Let's use the deployment package to create a function and route and then test it.
|
||||
|
||||
```
|
||||
$ fission fn create --name hellopy --env python --deploy demo-deploy-pkg.zip --entrypoint "hello.main"
|
||||
function 'hellopy' created
|
||||
|
||||
$ fission route create --function hellopy --url /hellopy
|
||||
|
||||
$ curl http://$FISSION_ROUTER/hellopy
|
||||
Hello, world!
|
||||
```
|
||||
|
||||
### View function information
|
||||
|
||||
You can retrieve metadata information of a single function or list all functions to look at basic information of functions:
|
||||
|
||||
```
|
||||
$ fission fn getmeta --name hello
|
||||
NAME UID ENV
|
||||
hello 34234b50-12f5-11e8-85c9-42010aa00010 node
|
||||
|
||||
$ fission fn list
|
||||
NAME UID ENV EXECUTORTYPE MINSCALE MAXSCALE TARGETCPU
|
||||
hello 34234b50-12f5-11e8-85c9-42010aa00010 node poolmgr 0 1 80
|
||||
hello2 e37a46e3-12f4-11e8-85c9-42010aa00010 node newdeploy 1 5 80
|
||||
|
||||
```
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
title: "Packaging source code"
|
||||
draft: false
|
||||
weight: 46
|
||||
---
|
||||
|
||||
### Creating source package
|
||||
|
||||
Before you create a package, you need to create an environment with associated builder image:
|
||||
|
||||
```
|
||||
$ fission env create --name pythonsrc --image fission/python-env:latest --builder fission/python-builder:latest --mincpu 40 --maxcpu 80 --minmemory 64 --maxmemory 128 --poolsize 2
|
||||
environment 'pythonsrc' created
|
||||
```
|
||||
|
||||
Let's take a simple python function which has dependency on a python pyyaml module. We can specify the dependencies in requirements.txt and a simple command to build from source. The tree structure of directory and contents of the file looks like:
|
||||
|
||||
```
|
||||
sourcepkg/
|
||||
├── __init__.py
|
||||
├── build.sh
|
||||
├── requirements.txt
|
||||
└── user.py
|
||||
```
|
||||
And the file contents:
|
||||
```
|
||||
$ cat user.py
|
||||
import sys
|
||||
import yaml
|
||||
|
||||
document = """
|
||||
a: 1
|
||||
b:
|
||||
c: 3
|
||||
d: 4
|
||||
"""
|
||||
|
||||
def main():
|
||||
return yaml.dump(yaml.load(document))
|
||||
|
||||
$ cat requirements.txt
|
||||
pyyaml
|
||||
|
||||
$ cat build.sh
|
||||
#!/bin/sh
|
||||
pip3 install -r ${SRC_PKG}/requirements.txt -t ${SRC_PKG} && cp -r ${SRC_PKG} ${DEPLOY_PKG}
|
||||
|
||||
$zip -jr demo-src-pkg.zip sourcepkg/
|
||||
adding: __init__.py (stored 0%)
|
||||
adding: build.sh (deflated 24%)
|
||||
adding: requirements.txt (stored 0%)
|
||||
adding: user.py (deflated 25%)
|
||||
```
|
||||
Using the source archive creared in previous step, you can create a package in Fission:
|
||||
|
||||
```
|
||||
$ fission package create --sourcearchive demo-src-pkg.zip --env pythonsrc --buildcmd "./build.sh"
|
||||
Package 'demo-src-pkg-zip-8lwt' created
|
||||
```
|
||||
|
||||
Since we are working with source package, we provided the build command. Once you create the package, the build process will start and you can check the build logs by getting information of the package:
|
||||
|
||||
```
|
||||
$ fission pkg info --name demo-src-pkg-zip-8lwt
|
||||
Name: demo-src-pkg-zip-8lwt
|
||||
Environment: pythonsrc
|
||||
Status: succeeded
|
||||
Build Logs:
|
||||
Collecting pyyaml (from -r /packages/demo-src-pkg-zip-8lwt-v57qil/requirements.txt (line 1))
|
||||
Using cached PyYAML-3.12.tar.gz
|
||||
Installing collected packages: pyyaml
|
||||
Running setup.py install for pyyaml: started
|
||||
Running setup.py install for pyyaml: finished with status 'done'
|
||||
Successfully installed pyyaml-3.12
|
||||
```
|
||||
|
||||
Using the package above you can create the function. Since package already is associated with a source package, environment and build command, these will be ignored when creating a function. Only addition thing you will need to provide is the entrypoint. Assuming you hace created the route, the function should be reachable with successful output:
|
||||
|
||||
```
|
||||
$ fission fn create --name srcpy --pkg demo-src-pkg-zip-8lwt --entrypoint "user.main"
|
||||
function 'srcpy' created
|
||||
|
||||
$ curl http://$FISSION_ROUTER/srcpy
|
||||
a: 1
|
||||
b: {c: 3, d: 4}
|
||||
```
|
||||
|
||||
### Creating deployment package
|
||||
|
||||
Before you create a package you need to create an environment with the builder image:
|
||||
```
|
||||
$ fission env create --name pythondeploy --image fission/python-env:latest --builder fission/python-builder:latest --mincpu 40 --maxcpu 80 --minmemory 64 --maxmemory 128 --poolsize 2
|
||||
environment 'pythonsrc' created
|
||||
```
|
||||
|
||||
We will use a simple Python example which outputs "Hello World!" in a directory to create a deployment archive:
|
||||
|
||||
```
|
||||
$ cat testDir/hello.py
|
||||
def main():
|
||||
return "Hello, world!"
|
||||
|
||||
$zip -jr demo-deploy-pkg.zip testDir/
|
||||
|
||||
```
|
||||
Using the archive and environments created previously, you can create a package:
|
||||
|
||||
```
|
||||
$ fission package create --deployarchive demo-deploy-pkg.zip --env pythondeploy
|
||||
Package 'demo-deploy-pkg-zip-whzl' created
|
||||
```
|
||||
|
||||
Since it is a deployment archive, there is no need to build it, hence the build logs for the package will be empty:
|
||||
|
||||
```
|
||||
$ fission package info --name demo-deploy-pkg-zip-whzl
|
||||
Name: demo-deploy-pkg-zip-xlaw
|
||||
Environment: pythondeploy2
|
||||
Status: succeeded
|
||||
Build Logs:
|
||||
```
|
||||
|
||||
Finally you can create a function with the package and test the function:
|
||||
|
||||
```
|
||||
$fission fn create --name deploypy --pkg demo-deploy-pkg-zip-whzl --entrypoint "hello.main"
|
||||
|
||||
$curl http://$FISSION_ROUTER/deploypy
|
||||
Hello, world!
|
||||
```
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Trigger"
|
||||
draft: false
|
||||
weight: 44
|
||||
---
|
||||
|
||||
### Create a HTTP Trigger
|
||||
|
||||
You can create a HTTP trigger with default method (GET) for a function:
|
||||
|
||||
```
|
||||
$ fission ht create --url /hello --function hello
|
||||
trigger '94cd5163-30dd-4fb2-ab3c-794052f70841' created
|
||||
```
|
||||
|
||||
### Create a Time Trigger
|
||||
|
||||
Time based triggers can be created with cron specifications:
|
||||
|
||||
```
|
||||
$ fission tt create --name halfhourly --function hello --cron "0 30 * * *"
|
||||
trigger 'halfhourly' created
|
||||
```
|
||||
|
||||
Also a more friendly syntax such "every 1m" or "@hourly" can be used to create a time based trigger.
|
||||
|
||||
```
|
||||
$ fission tt create --name minute --function hello --cron "@every 1m"
|
||||
trigger 'minute' created
|
||||
```
|
||||
|
||||
You can list time based triggers to inspect their associated function and cron specifications:
|
||||
|
||||
```
|
||||
$ fission tt list
|
||||
NAME CRON FUNCTION_NAME
|
||||
halfhourly 0 30 * * * hello
|
||||
minute @every 1m hello
|
||||
```
|
||||
|
||||
### Create a MQ Trigger
|
||||
|
||||
For creating a MQ based trigger which will invoke the function when a new message arrives in newfile topic, you can use the syntax below. The response of the function execution will be sent to topic newfileresponse.
|
||||
|
||||
```
|
||||
$ fission mqt create --name hellomsg --function hello --mqtype nats-streaming --topic newfile --resptopic newfileresponse
|
||||
trigger 'hellomsg' created
|
||||
```
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Workflows Installation Guide"
|
||||
date: 2018-01-22T16:03:27.761Z
|
||||
title: "Fission Workflows"
|
||||
draft: false
|
||||
weight: 70
|
||||
---
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user