mirror of
https://github.com/fnproject/fn.git
synced 2022-10-28 21:29:17 +03:00
Remove iron...
This commit is contained in:
Travis Reeder
committed by
Reed Allman
Reed Allman
parent
521df8c1ff
commit
9cc12b4b12
@@ -1,10 +1,10 @@
|
||||
# IronFunctions Documentation
|
||||
# Oracle Functions Documentation
|
||||
|
||||
* [FAQ](faq.md)
|
||||
|
||||
## For Developers
|
||||
|
||||
If you are a developer using IronFunctions through the API, this section is for you.
|
||||
If you are a developer using Oracle Functions through the API, this section is for you.
|
||||
|
||||
* [Quickstart](https://github.com/treeder/functions#quickstart)
|
||||
* [Definitions](definitions.md)
|
||||
@@ -19,7 +19,7 @@ If you are a developer using IronFunctions through the API, this section is for
|
||||
|
||||
## For Operators
|
||||
|
||||
If you are operating IronFunctions, this section is for you.
|
||||
If you are operating Oracle Functions, this section is for you.
|
||||
|
||||
* [Running in Production Overview](operating/production.md)
|
||||
* [Runtime Options](operating/options.md)
|
||||
@@ -29,9 +29,9 @@ If you are operating IronFunctions, this section is for you.
|
||||
* [Logging](operating/logging.md)
|
||||
* [Metrics](operating/metrics.md)
|
||||
* [Triggers](operating/triggers.md)
|
||||
* [Extending IronFunctions](operating/extending.md)
|
||||
* [Extending Oracle Functions](operating/extending.md)
|
||||
* [Docker Configuration](operating/docker.md)
|
||||
* [Operating On Windows](operating/windows.md)
|
||||
* Running IronFunctions on:
|
||||
* Running Oracle Functions on:
|
||||
* [Kubernetes](operating/kubernetes/README.md)
|
||||
* [Docker Swarm](operating/docker-swarm/README.md)
|
||||
|
||||
@@ -58,10 +58,10 @@ Note: Route level configuration overrides app level configuration.
|
||||
Using `fn`:
|
||||
|
||||
```sh
|
||||
fn routes create myapp /path --config k1=v1 --config k2=v2 --image iron/hello
|
||||
fn routes create myapp /path --config k1=v1 --config k2=v2 --image treeder/hello
|
||||
```
|
||||
|
||||
Or using a cURL:
|
||||
Or using cURL:
|
||||
|
||||
```sh
|
||||
curl -H "Content-Type: application/json" -X POST -d '{
|
||||
@@ -80,7 +80,7 @@ curl -H "Content-Type: application/json" -X POST -d '{
|
||||
```json
|
||||
{
|
||||
"path": "/hello",
|
||||
"image": "iron/hello",
|
||||
"image": "treeder/hello",
|
||||
"type": "sync",
|
||||
"memory": 128,
|
||||
"config": {
|
||||
@@ -150,4 +150,4 @@ This properties are only used if the function is in `hot function` mode
|
||||
|
||||
#### max_concurrency (string)
|
||||
|
||||
This property defines the maximum amount of concurrent hot functions instances the function should have (per IronFunction node).
|
||||
This property defines the maximum amount of concurrent hot functions instances the function should have (per Oracle Functions node).
|
||||
14
docs/faq.md
14
docs/faq.md
@@ -6,16 +6,16 @@ Since we use containers as the base building block, all languages can be used. T
|
||||
helper libraries like our Lambda wrapper for every language, but you can use any language if you follow the
|
||||
base [function format](function-format.md).
|
||||
|
||||
## Where can I run IronFunctions?
|
||||
## Where can I run Oracle Functions?
|
||||
|
||||
Anywhere. Any cloud, on-premise, on your laptop. As long as you can run a Docker container, you can run IronFunctions.
|
||||
Anywhere. Any cloud, on-premise, on your laptop. As long as you can run a Docker container, you can run Oracle Functions.
|
||||
|
||||
## Which orchestration tools does IronFunctions support?
|
||||
## Which orchestration tools does functions support?
|
||||
|
||||
IronFunctions can be deployed using any orchestration tool.
|
||||
Functions can be deployed using any orchestration tool.
|
||||
|
||||
## Does IronFunctions require Docker?
|
||||
## Does Oracle Functions require Docker?
|
||||
|
||||
For now we require Docker primarily for the packaging and distribution via Docker Registries,
|
||||
but we've built IronFunctions in a way that abstracts the container technology so we can support others as
|
||||
needed. For instance, we'll eventually add rkt support.
|
||||
but we've built Functions in a way that abstracts the container technology so we can support others as
|
||||
needed. For instance, we may add rkt support.
|
||||
|
||||
@@ -54,7 +54,7 @@ hello world
|
||||
|
||||
The header keys and values would be populated with information about the function call such as the request URL and query parameters.
|
||||
|
||||
`Content-Length` is determined by the [Content-Length](https://tools.ietf.org/html/rfc7230#section-3.3.3) header, which is mandatory both for input and output. It is used by IronFunctions to know when stop writing to STDIN and reading from STDOUT.
|
||||
`Content-Length` is determined by the [Content-Length](https://tools.ietf.org/html/rfc7230#section-3.3.3) header, which is mandatory both for input and output. It is used by Functions to know when stop writing to STDIN and reading from STDOUT.
|
||||
|
||||
Pros:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Hot functions
|
||||
|
||||
IronFunctions is built on top of container technologies, for each incoming
|
||||
Oracle Functions is built on top of container technologies, for each incoming
|
||||
workload, it spins a new container, feed it with the payload and sends the
|
||||
answer back to the caller. You can expect an average start time of 300ms per
|
||||
container. You may refer to [this blog](https://medium.com/travis-on-docker/the-overhead-of-docker-run-f2f06d47c9f3#.96tj75ugb) post to understand the details better.
|
||||
@@ -13,7 +13,7 @@ Thus, it means that once you decide to use a hot function, you must be able to
|
||||
tell the moment it should reading from standard input to start writing to
|
||||
standard output.
|
||||
|
||||
Currently, IronFunctions implements a HTTP-like protocol to operate hot
|
||||
Currently, Functions implements a HTTP-like protocol to operate hot
|
||||
containers, but instead of communication through a TCP/IP port, it uses standard
|
||||
input/output.
|
||||
|
||||
@@ -57,7 +57,7 @@ The next step in the cycle is to do some processing:
|
||||
```
|
||||
|
||||
And finally, we return the result with a `Content-Length` header, so
|
||||
IronFunctions daemon would know when to stop reading the gotten response.
|
||||
Functions daemon would know when to stop reading the gotten response.
|
||||
|
||||
```go
|
||||
res := http.Response{
|
||||
@@ -78,7 +78,7 @@ Rinse and repeat for each incoming workload.
|
||||
## Deploying a hot function
|
||||
|
||||
Once your functions is adapted to be handled as hot function, you must tell
|
||||
IronFunctions daemon that this function is now ready to be reused across
|
||||
Functions daemon that this function is now ready to be reused across
|
||||
requests:
|
||||
|
||||
```json
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Lambda everywhere
|
||||
|
||||
Lambda support for IronFunctions enables you to take your AWS Lambda functions and run them
|
||||
Lambda support for Oracle Functios enables you to take your AWS Lambda functions and run them
|
||||
anywhere. You should be able to take your code and run them without any changes.
|
||||
|
||||
## Creating Lambda Functions
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
|
||||
AWS Lambda introduced serverless computing to the masses. Wouldn't it be nice
|
||||
if you could run the same Lambda functions on any platform, in any cloud?
|
||||
Iron.io is proud to release a set of tools that allow just this. Package your
|
||||
Oracle is proud to release a set of tools that allow just this. Package your
|
||||
Lambda function in a Docker container and run it anywhere with an environment
|
||||
similar to AWS Lambda.
|
||||
|
||||
Using a job scheduler such as IronFunctions, you can connect these functions to
|
||||
Using a job scheduler such as Oracle Functions, you can connect these functions to
|
||||
webhooks and run them on-demand, at scale. You can also use a container
|
||||
management system paired with a task queue to run these functions in
|
||||
a self-contained, platform-independent manner.
|
||||
|
||||
@@ -1,8 +1,10 @@
|
||||
# Creating Docker images out of Lambda functions
|
||||
|
||||
Docker images created by running the `create-function` subcommand on a Lambda function are ready to execute.
|
||||
|
||||
You can convert any Lambda function of type nodejs 0.10, python 2.7 and Java 8 into an
|
||||
IronFunction compatible Docker Image as follows:
|
||||
Oracle Functions compatible Docker Image as follows:
|
||||
|
||||
```bash
|
||||
fn lambda create-function <name> <runtime> <handler> <files...>
|
||||
```
|
||||
@@ -16,7 +18,8 @@ fn lambda create-function <name> <runtime> <handler> <files...>
|
||||
* file: the files to be converted, however for java8 only one file of type `jar` is allowed.
|
||||
|
||||
e.g:
|
||||
|
||||
```bash
|
||||
fn lambda create-function irontest/node-exec:1 nodejs node_exec.handler node_exec.js
|
||||
fn lambda create-function test/node-exec:1 nodejs node_exec.handler node_exec.js
|
||||
```
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ Lambda and Dockerized Lambda.
|
||||
|
||||
## Request/Response
|
||||
|
||||
IronFunctions has sync/async communication with Request/Response workflows.
|
||||
Functions has sync/async communication with Request/Response workflows.
|
||||
* sync: returns the result as the body of the response
|
||||
* async: returns the task id in the body of the response as a json
|
||||
|
||||
@@ -21,11 +21,11 @@ such assumptions, please rewrite it.
|
||||
|
||||
## nodejs
|
||||
|
||||
* node.js version [0.10.42][iron/node]
|
||||
* node.js version [0.10.42][funcy/node]
|
||||
* ImageMagick version [6.9.3][magickv] and nodejs [wrapper 6.9.3][magickwrapperv]
|
||||
* aws-sdk version [2.2.12][awsnodev]
|
||||
|
||||
[iron/node]: https://github.com/treeder/dockers/blob/master/node/Dockerfile
|
||||
[funcy/node]: https://github.com/treeder/dockers/blob/master/node/Dockerfile
|
||||
[magickv]: https://pkgs.alpinelinux.org/package/main/x86_64/imagemagick
|
||||
[magickwrapperv]: https://www.npmjs.com/package/imagemagick
|
||||
[awsnodev]: https://aws.amazon.com/sdk-for-node-js/
|
||||
@@ -38,12 +38,12 @@ Payloads MUST be a valid JSON object literal.
|
||||
|
||||
* context.fail() does not currently truncate error logs.
|
||||
* `context.functionName` is of the form of a docker image, for example
|
||||
`iron/test-function`.
|
||||
`username/test-function`.
|
||||
* `context.functionVersion` is always the string `"$LATEST"`.
|
||||
* `context.invokedFunctionArn` is not supported. Value is empty string.
|
||||
* `context.memoryLimitInMB` does not reflect reality. Value is always `256`.
|
||||
* `context.awsRequestId` reflects the environment variable `TASK_ID`. On local
|
||||
runs from `ironcli` this is a UUID. On IronFunctions this is the task ID.
|
||||
runs from `fn` tool this is a UUID. On Functions server this is the task ID.
|
||||
* `logGroupName` and `logStreamName` are empty strings.
|
||||
* `identity` and `clientContext` are always `null`.
|
||||
|
||||
@@ -57,7 +57,7 @@ If your handler throws an exception, we only log the error message. There is no
|
||||
* CPython [2.7.11][pythonv]
|
||||
* boto3 (Python AWS SDK) [1.2.3][botov].
|
||||
|
||||
[pythonv]: https://hub.docker.com/r/iron/python/tags/
|
||||
[pythonv]: https://hub.docker.com/r/funcy/python/tags/
|
||||
[botov]: https://github.com/boto/boto3/releases/tag/1.2.3
|
||||
|
||||
### Event
|
||||
@@ -68,11 +68,11 @@ literal.
|
||||
### Context object
|
||||
|
||||
* `context.functionName` is of the form of a docker image, for example
|
||||
`iron/test-function`.
|
||||
`username/test-function`.
|
||||
* `context.functionVersion` is always the string `"$LATEST"`.
|
||||
* `context.invokedFunctionArn` is `None`.
|
||||
* `context.awsRequestId` reflects the environment variable `TASK_ID` which is
|
||||
set to the task ID on IronFunctions. If TASK_ID is empty, a new UUID is used.
|
||||
set to the task ID on Functions. If TASK_ID is empty, a new UUID is used.
|
||||
* `logGroupName`, `logStreamName`, `identity` and `clientContext` are `None`.
|
||||
|
||||
### Exceptions
|
||||
@@ -84,7 +84,7 @@ a JSON object with trace information.
|
||||
|
||||
* OpenJDK Java Runtime [1.8.0][javav]
|
||||
|
||||
[javav]: https://hub.docker.com/r/iron/java/tags/
|
||||
[javav]: https://hub.docker.com/r/funcy/java/tags/
|
||||
|
||||
The Java8 runtime is significantly lacking at this piont and we **do not
|
||||
recommend** using it.
|
||||
@@ -163,8 +163,8 @@ to CloudWatch are not supported.
|
||||
### Context object
|
||||
|
||||
* `context.getFunctionName()` returns a String of the form of a docker image,
|
||||
for example `iron/test-function`.
|
||||
for example `username/test-function`.
|
||||
* `context.getFunctionVersion()` is always the string `"$LATEST"`.
|
||||
* `context.getAwsRequestId()` reflects the environment variable `TASK_ID` which is
|
||||
set to the task ID on IronFunctions. If TASK_ID is empty, a new UUID is used.
|
||||
set to the task ID on Functions. If TASK_ID is empty, a new UUID is used.
|
||||
* `getInvokedFunctionArn()`, `getLogGroupName()`, `getLogStreamName()`, `getIdentity()`, `getClientContext()`, `getLogger()` return `null`.
|
||||
|
||||
@@ -1,128 +0,0 @@
|
||||
# Introduction
|
||||
|
||||
This guide will walk you through creating and testing a simple Lambda function.
|
||||
|
||||
We need the the `fn` tool for the rest of this guide. You can install it
|
||||
by following [these instructions](https://github.com/treeder/function/fn).
|
||||
|
||||
*For this getting started we are assuming you already have working lambda function code available, if not head to the [import instructions] (import.md) and skip the next section.*
|
||||
|
||||
## Creating the function
|
||||
|
||||
Let's convert the `hello_world` AWS Lambda example to Docker.
|
||||
|
||||
```python
|
||||
def my_handler(event, context):
|
||||
message = 'Hello {} {}!'.format(event['first_name'],
|
||||
event['last_name'])
|
||||
return {
|
||||
'message' : message
|
||||
}
|
||||
```
|
||||
|
||||
Create an empty directory for your project and save this code in a file called
|
||||
`hello_world.py`.
|
||||
|
||||
Now let's use `fn`'s Lambda functionality to create a Docker image. We can
|
||||
then run the Docker image with a payload to execute the Lambda function.
|
||||
|
||||
```sh
|
||||
$ fn lambda create-function irontest/hello_world:1 python2.7 hello_world.my_handler hello_world.py
|
||||
Creating directory: irontest/hello_world:1 ... OK
|
||||
Creating Dockerfile: irontest/hello_world:1/Dockerfile ... OK
|
||||
Copying file: irontest/hello_world/hello_world:1.py ... OK
|
||||
Creating function.yaml ... OK
|
||||
```
|
||||
|
||||
As you can see, this is very similar to creating a Lambda function using the
|
||||
`aws` CLI tool. We name the function as we would name other Docker images. The
|
||||
`1` indicates the version. You can use any string. This way you can configure
|
||||
your deployment environment to use different versions. The handler is
|
||||
the name of the function to run, in the form that python expects
|
||||
(`module.function`). Where you would package the files into a `.zip` to upload
|
||||
to Lambda, we just pass the list of files to `fn`.
|
||||
|
||||
## Deploying the function to IronFunctions
|
||||
|
||||
Next we want to deploy the function to our IronFunctions
|
||||
```sh
|
||||
$ fn deploy -v -d ./irontest irontest
|
||||
deploying irontest/hello_world:1/function.yaml
|
||||
Sending build context to Docker daemon 4.096 kB
|
||||
Step 1 : FROM iron/lambda-python2.7
|
||||
latest: Pulling from iron/lambda-python2.7
|
||||
c52e3ed763ff: Pull complete
|
||||
789cf808491a: Pull complete
|
||||
d1b635efed57: Pull complete
|
||||
fe23c3dbcfa8: Pull complete
|
||||
63c874a9687e: Pull complete
|
||||
a6d462dae1df: Pull complete
|
||||
Digest: sha256:c5dde3bf3be776c0f6b909d4ad87255a0af9b6696831fbe17c5f659655a0494a
|
||||
Status: Downloaded newer image for iron/lambda-python2.7:latest
|
||||
---> 66d3adf47835
|
||||
Step 2 : ADD hello_world.py ./hello_world:1.py
|
||||
---> 91a592e0dfa9
|
||||
Removing intermediate container 1a1ef40ff0dd
|
||||
Step 3 : CMD hello_world.my_handler
|
||||
---> Running in 318da1bba060
|
||||
---> db9b9644168e
|
||||
Removing intermediate container 318da1bba060
|
||||
Successfully built db9b9644168e
|
||||
The push refers to a repository [docker.io/irontest/hello_world:1]
|
||||
5d9d142e21b2: Pushed
|
||||
11d8145d6038: Layer already exists
|
||||
23885f85dbd0: Layer already exists
|
||||
6a350a8d14ee: Layer already exists
|
||||
e67f7ef625c5: Layer already exists
|
||||
321db514ef85: Layer already exists
|
||||
6102f0d2ad33: Layer already exists
|
||||
latest: digest: sha256:5926ff413f134fa353e4b42f2d4a0d2d4f5b3a39489cfdf6dd5b4a63c4e40dee size: 1784
|
||||
updating API with appName: irontest route: /hello_world:1 image: irontest/hello_world:1
|
||||
path result
|
||||
irontest/hello_world:1/function.yaml done
|
||||
```
|
||||
|
||||
This will deploy the generated function under the app `irontest` with `hello_world` as a route, e.g:
|
||||
`http://<hostname>/r/irontest/hello_world:1`,
|
||||
|
||||
You should also now see the generated Docker image.
|
||||
|
||||
```sh
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
|
||||
irontest/hello_world:1 latest db9b9644168e About a minute ago 108.4 MB
|
||||
...
|
||||
```
|
||||
|
||||
## Testing the function
|
||||
|
||||
The `test-function` subcommand can launch the Dockerized function with the
|
||||
right parameters.
|
||||
|
||||
```sh
|
||||
$ fn lambda test-function irontest/hello_world:1 --payload '{ "first_name": "Jon", "last_name": "Snow" }'
|
||||
{"message": "Hello Jon Snow!"}
|
||||
```
|
||||
|
||||
You should see the output.
|
||||
|
||||
## Calling the function from IronFunctions
|
||||
|
||||
The `fn call` command can call the deployed version with a given payload.
|
||||
|
||||
```sh
|
||||
$ echo '{ "first_name": "Jon", "last_name": "Snow" }' | ./fn call irontest /hello_world:1
|
||||
{"message": "Hello Jon Snow!"}
|
||||
```
|
||||
|
||||
You should see the output.
|
||||
|
||||
|
||||
## Commands documentation
|
||||
* [create-function](create.md)
|
||||
* [test-function](test.md)
|
||||
* [aws-import](import.md)
|
||||
|
||||
## More documentation
|
||||
* [env](environment.md)
|
||||
* [aws](aws.md)
|
||||
@@ -38,7 +38,7 @@ fn lambda aws-import arn:aws:lambda:us-west-2:123141564251:function:my-function
|
||||
|
||||
will import the function code from the region `us-east-1` to a directory called `./user/my-function`. Inside the directory you will find the `function.yml`, `Dockerfile`, and all the files needed for running the function.
|
||||
|
||||
Using Lambda with Docker Hub and IronFunctions requires that the Docker image be
|
||||
Using Lambda with Docker Hub and Oracle Functions requires that the Docker image be
|
||||
named `<Docker Hub username>/<image name>`. This is used to uniquely identify
|
||||
images on Docker Hub. Please use the `<Docker Hub username>/<image
|
||||
name>` as the image name with `aws-import` to create a correctly named image.
|
||||
@@ -50,6 +50,6 @@ by passing `--version <version>.`
|
||||
|
||||
You can then deploy the imported lambda as follows:
|
||||
```
|
||||
./fn deploy -d ./user/my-function user
|
||||
./fn deploy myapp
|
||||
````
|
||||
Now the function can be reached via ```http://$HOSTNAME/r/user/my-function```
|
||||
@@ -20,7 +20,7 @@ the directory on your host. eg: `docker run -v $PWD/data:/functions/data -e DB_U
|
||||
|
||||
URL: `postgres://user123:pass456@ec2-117-21-174-214.compute-1.amazonaws.com:6212/db982398`
|
||||
|
||||
Use a PostgreSQL database. If you're using IronFunctions in production, you should probably start here.
|
||||
Use a PostgreSQL database. If you're using Functions in production, you should probably start here.
|
||||
|
||||
[More on PostgreSQL](postgres.md)
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# IronFunctions using BoltDB
|
||||
# Oracle Functions using BoltDB
|
||||
|
||||
BoltDB is the default database, you just need to run the API.
|
||||
|
||||
@@ -7,5 +7,5 @@ BoltDB is the default database, you just need to run the API.
|
||||
To keep it persistent, add a volume flag to the command:
|
||||
|
||||
```
|
||||
docker run --rm -it --privileged -v $PWD/bolt.db:/app/bolt.db -p 8080:8080 iron/functions
|
||||
```
|
||||
docker run --rm -it --privileged -v $PWD/bolt.db:/app/bolt.db -p 8080:8080 treeder/functions
|
||||
```
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
# IronFunctions using Postgres
|
||||
# Oracle Functions using Postgres
|
||||
|
||||
Let's presuppose you don't have even a MySQL DB ready.
|
||||
|
||||
### 1. Let's start a MySQL instance:
|
||||
|
||||
```
|
||||
docker run --name iron-mysql \
|
||||
-e MYSQL_DATABASE=funcs -e MYSQL_USER=iron -e MYSQL_PASSWORD=ironfunctions -d mysql
|
||||
docker run --name func-mysql \
|
||||
-e MYSQL_DATABASE=funcs -e MYSQL_USER=funcy -e MYSQL_PASSWORD=funcypass -d mysql
|
||||
```
|
||||
|
||||
For more configuration options, see [docker mysql docs](https://hub.docker.com/_/mysql/).
|
||||
|
||||
### 2. Now let's start IronFunctions connecting to our new mysql instance
|
||||
### 2. Now let's start Functions connecting to our new mysql instance
|
||||
|
||||
```
|
||||
docker run --rm --privileged --link "iron-mysql:mysql" \
|
||||
-e "DB_URL=mysql://iron:ironfunctions@tcp(mysql:3306)/funcs" \
|
||||
-it -p 8080:8080 iron/functions
|
||||
-e "DB_URL=mysql://funcy:funcypass@tcp(mysql:3306)/funcs" \
|
||||
-it -p 8080:8080 treeder/functions
|
||||
```
|
||||
|
||||
@@ -1,34 +1,34 @@
|
||||
# IronFunctions using Postgres
|
||||
# Oracle Functions using Postgres
|
||||
|
||||
Let's presuppose you don't have even a postgres DB ready.
|
||||
|
||||
### 1. Let's start a postgres instance:
|
||||
|
||||
```
|
||||
docker run --name iron-postgres \
|
||||
-e POSTGRES_PASSWORD=ironfunctions -d postgres
|
||||
docker run --name funcy-postgres \
|
||||
-e POSTGRES_PASSWORD=funcypass -d postgres
|
||||
```
|
||||
|
||||
### 2. Now let's create a new database to IronFunctions
|
||||
### 2. Now let's create a new database for Functions
|
||||
|
||||
Creating database:
|
||||
|
||||
```
|
||||
docker run -it --rm --link iron-postgres:postgres postgres \
|
||||
docker run -it --rm --link funcy-postgres:postgres postgres \
|
||||
psql -h postgres -U postgres -c "CREATE DATABASE funcs;"
|
||||
```
|
||||
|
||||
Granting access to postgres user
|
||||
|
||||
```
|
||||
docker run -it --rm --link iron-postgres:postgres postgres \
|
||||
docker run -it --rm --link funcy-postgres:postgres postgres \
|
||||
psql -h postgres -U postgres -c 'GRANT ALL PRIVILEGES ON DATABASE funcs TO postgres;'
|
||||
```
|
||||
|
||||
### 3. Now let's start IronFunctions connecting to our new postgres instance
|
||||
### 3. Now let's start Functions connecting to our new postgres instance
|
||||
|
||||
```
|
||||
docker run --rm --privileged --link "iron-postgres:postgres" \
|
||||
-e "DB_URL=postgres://postgres:ironfunctions@postgres/funcs?sslmode=disable" \
|
||||
-it -p 8080:8080 iron/functions
|
||||
-e "DB_URL=postgres://postgres:funcypass@postgres/funcs?sslmode=disable" \
|
||||
-it -p 8080:8080 treeder/functions
|
||||
```
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Docker Swarm and IronFunctions
|
||||
# Docker Swarm and Oracle Functions
|
||||
|
||||
How to run IronFunction as a scheduler on top of Docker Standalone Swarm cluster.
|
||||
How to run Oracle Functions as a scheduler on top of Docker Standalone Swarm cluster.
|
||||
|
||||
## Quick installation
|
||||
|
||||
@@ -8,11 +8,11 @@ How to run IronFunction as a scheduler on top of Docker Standalone Swarm cluster
|
||||
|
||||
*Prerequisite 2: It assumes that your running environment is already configured to use Swarm's master scheduler.*
|
||||
|
||||
This is a step-by-step procedure to execute IronFunction on top of Docker Swarm cluster. It works by having IronFunction daemon started through Swarm's master, and there enqueueing tasks through Swarm API.
|
||||
This is a step-by-step procedure to execute Oracle Functions on top of Docker Swarm cluster. It works by having Oracle Functions daemon started through Swarm's master, and there enqueueing tasks through Swarm API.
|
||||
|
||||
### Steps
|
||||
|
||||
1. Start IronFunction in the Swarm Master. It expects all basic Docker environment variables to be present (DOCKER_TLS_VERIFY, DOCKER_HOST, DOCKER_CERT_PATH, DOCKER_MACHINE_NAME). The important part is that the working Swarm master environment must be passed to Functions daemon:
|
||||
1. Start Oracle Functions in the Swarm Master. It expects all basic Docker environment variables to be present (DOCKER_TLS_VERIFY, DOCKER_HOST, DOCKER_CERT_PATH, DOCKER_MACHINE_NAME). The important part is that the working Swarm master environment must be passed to Functions daemon:
|
||||
```ShellSession
|
||||
$ docker login # if you plan to use private images
|
||||
$ docker volume create --name functions-datafiles
|
||||
@@ -24,7 +24,7 @@ $ docker run -d --name functions \
|
||||
-e DOCKER_MACHINE_NAME \
|
||||
-v $DOCKER_CERT_PATH:/docker-cert \
|
||||
-v functions-datafiles:/app/data \
|
||||
iron/functions
|
||||
treeder/functions
|
||||
```
|
||||
|
||||
2. Once the daemon is started, check where it is listening for connections:
|
||||
@@ -32,23 +32,23 @@ $ docker run -d --name functions \
|
||||
```ShellSession
|
||||
# docker info
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
5a0846e6a025 iron/functions "/usr/local/bin/entry" 59 seconds ago Up 58 seconds 2375/tcp, 10.0.0.1:8080->8080/tcp swarm-agent-00/functions
|
||||
5a0846e6a025 treeder/functions "/usr/local/bin/entry" 59 seconds ago Up 58 seconds 2375/tcp, 10.0.0.1:8080->8080/tcp swarm-agent-00/functions
|
||||
````
|
||||
|
||||
Note `10.0.0.1:8080` in `PORTS` column, this is where the service is listening. IronFunction will use Docker Swarm scheduler to deliver tasks to all nodes present in the cluster.
|
||||
Note `10.0.0.1:8080` in `PORTS` column, this is where the service is listening. Oracle Functions will use Docker Swarm scheduler to deliver tasks to all nodes present in the cluster.
|
||||
|
||||
3. Test the cluster:
|
||||
|
||||
```ShellSession
|
||||
$ export IRON_FUNCTION=$(docker port functions | cut -d ' ' -f3)
|
||||
$ export FUNCTIONS=$(docker port functions | cut -d ' ' -f3)
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "app": { "name":"myapp" } }' http://$IRON_FUNCTION/v1/apps
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "app": { "name":"myapp" } }' http://$FUNCTIONS/v1/apps
|
||||
{"message":"App successfully created","app":{"name":"myapp","config":null}}
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "route": { "type": "sync", "path":"/hello-sync", "image":"iron/hello" } }' http://$IRON_FUNCTION/v1/apps/myapp/routes
|
||||
{"message":"Route successfully created","route":{"app_name":"myapp","path":"/hello-sync","image":"iron/hello","memory":128,"type":"sync","config":null}}
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "route": { "type": "sync", "path":"/hello-sync", "image":"treeder/hello" } }' http://$FUNCTIONS/v1/apps/myapp/routes
|
||||
{"message":"Route successfully created","route":{"app_name":"myapp","path":"/hello-sync","image":"treeder/hello","memory":128,"type":"sync","config":null}}
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "name":"Johnny" }' http://$IRON_FUNCTION/r/myapp/hello-sync
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "name":"Johnny" }' http://$FUNCTIONS/r/myapp/hello-sync
|
||||
Hello Johnny!
|
||||
```
|
||||
|
||||
@@ -58,7 +58,7 @@ Hello Johnny!
|
||||
|
||||
*Prerequisite 2: It assumes that your running environment is already configured to use Swarm's master scheduler.*
|
||||
|
||||
This is a step-by-step procedure to execute IronFunction on top of Docker Swarm cluster. It works by having IronFunction daemon started through Swarm's master, however the tasks are executed on each host locally. In production, database and message queue must be external to IronFunction execution, this guarantees robustness of the service against failures.
|
||||
This is a step-by-step procedure to execute Oracle Functions on top of Docker Swarm cluster. It works by having Oracle Functions daemon started through Swarm's master, however the tasks are executed on each host locally. In production, database and message queue must be external to Oracle Functions execution, this guarantees robustness of the service against failures.
|
||||
|
||||
We strongly recommend you deploy your own HA Redis and PostgreSQL clusters. Otherwise, you can follow the instructions below and have them set in single nodes.
|
||||
|
||||
@@ -74,7 +74,7 @@ docker-machine create -d virtualbox --swarm --swarm-master --swarm-discovery etc
|
||||
# Set aside one host for DB activities
|
||||
docker-machine create -d virtualbox --engine-label use=db --swarm --swarm-discovery etcd://$ETCD_HOST:2379/swarm --engine-opt="cluster-store=etcd://$ETCD_HOST:2379/network" --engine-opt="cluster-advertise=eth1:2376" swarm-db;
|
||||
|
||||
# The rest is a horizontally scalable set of hosts for IronFunction
|
||||
# The rest is a horizontally scalable set of hosts for Oracle Functions
|
||||
docker-machine create -d virtualbox --engine-label use=worker --swarm --swarm-discovery etcd://$ETCD_HOST:2379/swarm --engine-opt="cluster-store=etcd://$ETCD_HOST:2379/network" --engine-opt="cluster-advertise=eth1:2376" swarm-worker-00;
|
||||
docker-machine create -d virtualbox --engine-label use=worker --swarm --swarm-discovery etcd://$ETCD_HOST:2379/swarm --engine-opt="cluster-store=etcd://$ETCD_HOST:2379/network" --engine-opt="cluster-advertise=eth1:2376" swarm-worker-01
|
||||
```
|
||||
@@ -83,7 +83,7 @@ docker-machine create -d virtualbox --engine-label use=worker --swarm --swarm-di
|
||||
|
||||
If you using externally deployed Redis and PostgreSQL cluster, you may skip to step 4.
|
||||
|
||||
1. Build a multi-host network for IronFunction:
|
||||
1. Build a multi-host network for Oracle Functions:
|
||||
```ShellSession
|
||||
$ docker network create --driver overlay --subnet=10.0.9.0/24 functions-network
|
||||
````
|
||||
@@ -100,7 +100,7 @@ $ docker create -e constraint:use==db --network=functions-network -v /var/lib/po
|
||||
$ docker run -d -e constraint:use==db --network=functions-network --volumes-from postgresql-data --name functions-postgres -e POSTGRES_PASSWORD=mysecretpassword postgres
|
||||
```
|
||||
|
||||
4. Start IronFunctions:
|
||||
4. Start Oracle Functions:
|
||||
```ShellSession
|
||||
$ docker run -d --name functions-00 \
|
||||
-l functions \
|
||||
@@ -110,7 +110,7 @@ $ docker run -d --name functions-00 \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
-e 'MQ_URL=redis://functions-redis' \
|
||||
-e 'DB_URL=postgres://postgres:mysecretpassword@functions-postgres/?sslmode=disable' \
|
||||
iron/functions
|
||||
treeder/functions
|
||||
```
|
||||
|
||||
5. Load Balancer:
|
||||
@@ -120,14 +120,14 @@ $ export BACKENDS=$(docker ps --filter label=functions --format="{{ .ID }}" | xa
|
||||
|
||||
$ docker run -d --name functions-lb -p 80:80 -e BACKENDS noqcks/haproxy
|
||||
|
||||
$ export IRON_FUNCTION=$(docker port functions-lb | cut -d ' ' -f3)
|
||||
$ export FUNCTIONS=$(docker port functions-lb | cut -d ' ' -f3)
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "app": { "name":"myapp" } }' http://$IRON_FUNCTION/v1/apps
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "app": { "name":"myapp" } }' http://$FUNCTIONS/v1/apps
|
||||
{"message":"App successfully created","app":{"name":"myapp","config":null}}
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "route": { "type": "sync", "path":"/hello-sync", "image":"iron/hello" } }' http://$IRON_FUNCTION/v1/apps/myapp/routes
|
||||
{"message":"Route successfully created","route":{"app_name":"myapp","path":"/hello-sync","image":"iron/hello","memory":128,"type":"sync","config":null}}
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "route": { "type": "sync", "path":"/hello-sync", "image":"treeder/hello" } }' http://$FUNCTIONS/v1/apps/myapp/routes
|
||||
{"message":"Route successfully created","route":{"app_name":"myapp","path":"/hello-sync","image":"treeder/hello","memory":128,"type":"sync","config":null}}
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "name":"Johnny" }' http://$IRON_FUNCTION/r/myapp/hello-sync
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "name":"Johnny" }' http://$FUNCTIONS/r/myapp/hello-sync
|
||||
Hello Johnny!
|
||||
```
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
# Extending IronFunctions
|
||||
# Extending Oracle Functions
|
||||
|
||||
IronFunctions is extensible so you can add custom functionality and extend the project without needing to modify the core.
|
||||
Oracle Functions is extensible so you can add custom functionality and extend the project without needing to modify the core.
|
||||
|
||||
There are multiple ways to extend the functionality of IronFunctions.
|
||||
There are multiple ways to extend the functionality of Oracle Functions.
|
||||
|
||||
1. Listeners - listen to API events such as a route getting updated and react accordingly.
|
||||
1. Middleware - a chain of middleware is executed before an API handler is called.
|
||||
1. Add API Endpoints - extend the default IronFunctions API.
|
||||
1. Add API Endpoints - extend the default Oracle Functions API.
|
||||
|
||||
## Listeners
|
||||
|
||||
Listeners are the main way to extend IronFunctions.
|
||||
Listeners are the main way to extend Oracle Functions.
|
||||
|
||||
The following listener types are supported:
|
||||
|
||||
@@ -19,7 +19,7 @@ The following listener types are supported:
|
||||
|
||||
### Creating a Listener
|
||||
|
||||
You can easily use app and runner listeners by creating a struct with valid methods satisfying the interface for the respective listener and adding it to the IronFunctions API
|
||||
You can easily use app and runner listeners by creating a struct with valid methods satisfying the interface for the respective listener and adding it to the Oracle Functions API
|
||||
|
||||
Example:
|
||||
|
||||
@@ -67,6 +67,6 @@ See examples of this in [examples/middleware/main.go](../../examples/middleware/
|
||||
|
||||
## Adding API Endpoints
|
||||
|
||||
You can add API endpoints to the IronFunctions server by using the `AddEndpoint` and `AddEndpointFunc` methods.
|
||||
You can add API endpoints to the Oracle Functions server by using the `AddEndpoint` and `AddEndpointFunc` methods.
|
||||
|
||||
See examples of this in [examples/extensions/main.go](../../examples/extensions/main.go).
|
||||
@@ -1,4 +1,4 @@
|
||||
# HOWTO run IronFunction in Kubernetes at AWS
|
||||
# HOWTO run Oracle Functions in Kubernetes at AWS
|
||||
|
||||
*Prerequisite 1: it assumes you have a working Kubernetes, and a locally configured kubectl.*
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
|
||||
### Steps
|
||||
|
||||
1. Start IronFunction in the Kubernetes cluster:
|
||||
1. Start Oracle Functions in the Kubernetes cluster:
|
||||
```ShellSession
|
||||
$ cd docs/
|
||||
$ kubectl create -f kubernetes-quick
|
||||
@@ -44,15 +44,15 @@ Note `a23122e39900111e681ba0e29b70bb46-630391493.us-east-1.elb.amazonaws.com` in
|
||||
3. Test the cluster:
|
||||
|
||||
```ShellSession
|
||||
$ export IRON_FUNCTION=$(kubectl get -o json svc functions | jq -r '.status.loadBalancer.ingress[0].hostname'):8080
|
||||
$ export FUNCTIONS=$(kubectl get -o json svc functions | jq -r '.status.loadBalancer.ingress[0].hostname'):8080
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "app": { "name":"myapp" } }' http://$IRON_FUNCTION/v1/apps
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "app": { "name":"myapp" } }' http://$FUNCTIONS/v1/apps
|
||||
{"message":"App successfully created","app":{"name":"myapp","config":null}}
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "route": { "type": "sync", "path":"/hello-sync", "image":"iron/hello" } }' http://$IRON_FUNCTION/v1/apps/myapp/routes
|
||||
{"message":"Route successfully created","route":{"app_name":"myapp","path":"/hello-sync","image":"iron/hello","memory":128,"type":"sync","config":null}}
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "route": { "type": "sync", "path":"/hello-sync", "image":"treeder/hello" } }' http://$FUNCTIONS/v1/apps/myapp/routes
|
||||
{"message":"Route successfully created","route":{"app_name":"myapp","path":"/hello-sync","image":"treeder/hello","memory":128,"type":"sync","config":null}}
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "name":"Johnny" }' http://$IRON_FUNCTION/r/myapp/hello-sync
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "name":"Johnny" }' http://$FUNCTIONS/r/myapp/hello-sync
|
||||
Hello Johnny!
|
||||
```
|
||||
|
||||
@@ -60,7 +60,7 @@ Hello Johnny!
|
||||
|
||||
### Steps
|
||||
|
||||
1. Start IronFunction and its dependencies:
|
||||
1. Start Oracle Functions and its dependencies:
|
||||
```ShellSession
|
||||
$ cd docs/
|
||||
$ kubectl create -f kubernetes-production
|
||||
@@ -97,14 +97,14 @@ Note `a23122e39900111e681ba0e29b70bb46-630391493.us-east-1.elb.amazonaws.com` in
|
||||
3. Test the cluster:
|
||||
|
||||
```ShellSession
|
||||
$ export IRON_FUNCTION=$(kubectl get -o json svc functions | jq -r '.status.loadBalancer.ingress[0].hostname'):8080
|
||||
$ export FUNCTIONS=$(kubectl get -o json svc functions | jq -r '.status.loadBalancer.ingress[0].hostname'):8080
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "app": { "name":"myapp" } }' http://$IRON_FUNCTION/v1/apps
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "app": { "name":"myapp" } }' http://$FUNCTIONS/v1/apps
|
||||
{"message":"App successfully created","app":{"name":"myapp","config":null}}
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "route": { "type": "sync", "path":"/hello-sync", "image":"iron/hello" } }' http://$IRON_FUNCTION/v1/apps/myapp/routes
|
||||
{"message":"Route successfully created","route":{"app_name":"myapp","path":"/hello-sync","image":"iron/hello","memory":128,"type":"sync","config":null}}
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "route": { "type": "sync", "path":"/hello-sync", "image":"treeder/hello" } }' http://$FUNCTIONS/v1/apps/myapp/routes
|
||||
{"message":"Route successfully created","route":{"app_name":"myapp","path":"/hello-sync","image":"treeder/hello","memory":128,"type":"sync","config":null}}
|
||||
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "name":"Johnny" }' http://$IRON_FUNCTION/r/myapp/hello-sync
|
||||
$ curl -H "Content-Type: application/json" -X POST -d '{ "name":"Johnny" }' http://$FUNCTIONS/r/myapp/hello-sync
|
||||
Hello Johnny!
|
||||
```
|
||||
@@ -14,7 +14,7 @@ spec:
|
||||
spec:
|
||||
containers:
|
||||
- name: functions
|
||||
image: iron/functions
|
||||
image: treeder/functions
|
||||
securityContext:
|
||||
privileged: true
|
||||
env:
|
||||
|
||||
@@ -14,7 +14,7 @@ spec:
|
||||
spec:
|
||||
containers:
|
||||
- name: functions
|
||||
image: iron/functions
|
||||
image: treeder/functions
|
||||
securityContext:
|
||||
privileged: true
|
||||
env:
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Logging
|
||||
|
||||
There are a few things to note about what IronFunctions logs.
|
||||
There are a few things to note about what Oracle Functions logs.
|
||||
|
||||
## Logspout
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Message Queues
|
||||
|
||||
A message queue is used to coordinate asynchronous function calls that run through IronFunctions.
|
||||
A message queue is used to coordinate asynchronous function calls that run through Oracle Functions.
|
||||
|
||||
We currently support the following message queues and they are passed in via the `MQ_URL` environment variable. For example:
|
||||
|
||||
@@ -23,7 +23,7 @@ See Redis in databases above.
|
||||
|
||||
URL: `ironmq://project_id:token@mq-aws-us-east-1.iron.io/queue_prefix`
|
||||
|
||||
IronMQ is a hosted message queue service provided by [Iron.io](http://iron.io). If you're using IronFunctions in production and don't
|
||||
IronMQ is a hosted message queue service provided by [Iron.io](http://iron.io). If you're using Oracle Functions in production and don't
|
||||
want to manage a message queue, you should start here.
|
||||
|
||||
The IronMQ connector uses HTTPS by default. To use HTTP set the scheme to
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# IronFunctions Runtime Options
|
||||
# Oracle Functions Runtime Options
|
||||
|
||||
## Configuration
|
||||
|
||||
When starting IronFunctions, you can pass in the following configuration variables as environment variables. Use `-e VAR_NAME=VALUE` in
|
||||
When starting Oracle Functions, you can pass in the following configuration variables as environment variables. Use `-e VAR_NAME=VALUE` in
|
||||
docker run. For example:
|
||||
|
||||
```sh
|
||||
@@ -13,7 +13,7 @@ docker run -e VAR_NAME=VALUE ...
|
||||
| --------------|-------------|----------------|
|
||||
| DB_URL | The database URL to use in URL format. See [Databases](databases/README.md) for more information. | bolt:///app/data/bolt.db |
|
||||
| MQ_URL | The message queue to use in URL format. See [Message Queues](mqs/README.md) for more information. | bolt:///app/data/worker_mq.db |
|
||||
| API_URL | The primary IronFunctions API URL to that this instance will talk to. In a production environment, this would be your load balancer URL. | N/A |
|
||||
| API_URL | The primary Oracle Functions API URL to that this instance will talk to. In a production environment, this would be your load balancer URL. | N/A |
|
||||
| PORT | Sets the port to run on | 8080 |
|
||||
| LOG_LEVEL | Set to DEBUG to enable debugging | INFO |
|
||||
| DOCKER_HOST | Docker remote API URL | /var/run/docker.sock:/var/run/docker.sock |
|
||||
@@ -23,12 +23,12 @@ docker run -e VAR_NAME=VALUE ...
|
||||
|
||||
## Starting without Docker in Docker
|
||||
|
||||
The default way to run IronFunctions, as it is in the Quickstart guide, is to use docker-in-docker (dind). There are
|
||||
The default way to run Oracle Functions, as it is in the Quickstart guide, is to use docker-in-docker (dind). There are
|
||||
a couple reasons why we did it this way:
|
||||
|
||||
* It's clean. Once the container exits, there is nothing left behind including all the function images.
|
||||
* You can set resource restrictions for the entire IronFunctions instance. For instance, you can set `--memory` on
|
||||
the docker run command to set the max memory for the IronFunctions instance AND all of the functions it's running.
|
||||
* You can set resource restrictions for the entire Oracle Functions instance. For instance, you can set `--memory` on
|
||||
the docker run command to set the max memory for the Oracle Functions instance AND all of the functions it's running.
|
||||
|
||||
There are some reasons you may not want to use dind, such as using the image cache during testing or you're running
|
||||
[Windows](windows.md).
|
||||
@@ -38,7 +38,7 @@ There are some reasons you may not want to use dind, such as using the image cac
|
||||
One way is to mount the host Docker. Everything is essentially the same except you add a `-v` flag:
|
||||
|
||||
```sh
|
||||
docker run --rm --name functions -it -v /var/run/docker.sock:/var/run/docker.sock -v $PWD/data:/app/data -p 8080:8080 iron/functions
|
||||
docker run --rm --name functions -it -v /var/run/docker.sock:/var/run/docker.sock -v $PWD/data:/app/data -p 8080:8080 treeder/functions
|
||||
```
|
||||
|
||||
### Run outside Docker
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
# Running IronFunctions in Production
|
||||
# Running Oracle Functions in Production
|
||||
|
||||
The [QuickStart guide](/README.md#quickstart) is intended to quickly get started and kick the tires. To run in production and be ready to scale, you need
|
||||
to use more production ready components.
|
||||
|
||||
* Put the IronFunctions API behind a load balancer and launch run several instances of them (the more the merrier).
|
||||
* Put the Oracle Functions API behind a load balancer and launch run several instances of them (the more the merrier).
|
||||
* Run a database that can scale.
|
||||
* Asynchronous functions requires a message queue (preferably one that scales).
|
||||
|
||||
Here's a rough diagram of what a production deployment looks like:
|
||||
|
||||
|
||||
|
||||
|
||||
## Load Balancer
|
||||
|
||||
Any load balancer will work, put every instance of IronFunctions that you run behind the load balancer.
|
||||
Any load balancer will work, put every instance of Oracle Functions that you run behind the load balancer.
|
||||
|
||||
**Note**: We will work on a smart load balancer that can direct traffic in a smarter way. See [#151](https://github.com/treeder/functions/issues/151).
|
||||
|
||||
@@ -26,13 +26,13 @@ The database is pluggable and we currently support a few options that can be [fo
|
||||
## Message Queue
|
||||
|
||||
The message queue is an important part of asynchronous functions, essentially buffering requests for processing when resources are available. The reliability and scale of the message queue will play an important part
|
||||
in how well IronFunctions runs, in particular if you use a lot of asynchronous function calls.
|
||||
in how well Oracle Functions runs, in particular if you use a lot of asynchronous function calls.
|
||||
|
||||
The message queue is pluggable and we currently support a few options that can be [found here](mqs/README.md). We welcome pull requests for more!
|
||||
|
||||
## Logging, Metrics and Monitoring
|
||||
|
||||
Logging is a particularly important part of IronFunctions. It not only emits logs, but metrics are also emitted to the logs. Ops teams can then decide how they want
|
||||
Logging is a particularly important part of Oracle Functions. It not only emits logs, but metrics are also emitted to the logs. Ops teams can then decide how they want
|
||||
to use the logs and metrics without us prescribing a particular technology. For instance, you can [logspout-statsd](https://github.com/treeder/logspout-statsd) to capture metrics
|
||||
from the logs and forward them to statsd.
|
||||
|
||||
@@ -41,5 +41,5 @@ from the logs and forward them to statsd.
|
||||
## Scaling
|
||||
|
||||
There are metrics emitted to the logs that can be used to notify you when to scale. The most important being the `wait_time` metrics for both the
|
||||
synchronous and asynchronous functions. If `wait_time` increases, you'll want to start more IronFunctions instances.
|
||||
synchronous and asynchronous functions. If `wait_time` increases, you'll want to start more Oracle Functions instances.
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# IronFunctions Routes
|
||||
# Oracle Functions Routes
|
||||
|
||||
Routes have a many-to-one mapping to an [app](apps.md).
|
||||
|
||||
A good practice to get the best performance on your IronFunctions API is define
|
||||
A good practice to get the best performance on your Oracle Functions API is define
|
||||
the required memory for each function.
|
||||
|
||||
## Route level configuration
|
||||
@@ -26,9 +26,9 @@ Note: Route level configuration overrides app level configuration.
|
||||
|
||||
TODO: link to swagger doc on swaggerhub after it's updated.
|
||||
|
||||
## Understanding IronFunctions memory management
|
||||
## Understanding Oracle Functions memory management
|
||||
|
||||
When IronFunctions starts it registers the total available memory in your system
|
||||
When Oracle Functions starts it registers the total available memory in your system
|
||||
in order to know during its runtime if the system has the required amount of
|
||||
free memory to run each function. Every function starts the runner reduces the
|
||||
amount of memory used by that function from the available memory register. When
|
||||
@@ -56,7 +56,7 @@ some container configuration values.
|
||||
curl -H "Content-Type: application/json" -X POST -d '{
|
||||
"route": {
|
||||
"path":"/hello",
|
||||
"image":"iron/hello",
|
||||
"image":"treeder/hello",
|
||||
"memory": 100,
|
||||
"type": "sync",
|
||||
"config": {"APPLOG": "stderr"}
|
||||
|
||||
@@ -1,2 +1,2 @@
|
||||
|
||||
# Scaling IronFunctions
|
||||
# Scaling Oracle Functions
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Triggers
|
||||
|
||||
Triggers are integrations that you can use in other systems to fire off functions in IronFunctions.
|
||||
Triggers are integrations that you can use in other systems to fire off functions in Oracle Functions.
|
||||
|
||||
## OpenStack
|
||||
|
||||
@@ -12,7 +12,7 @@ Triggers are integrations that you can use in other systems to fire off function
|
||||
* Kernel: 4.7 or newer with overlay2 or aufs module
|
||||
* Docker: 1.12 or newer
|
||||
|
||||
2. [Picasso](https://github.com/openstack/picasso) - Picasso provides an OpenStack API and Keystone authentication layer on top of IronFunctions.
|
||||
2. [Picasso](https://github.com/openstack/picasso) - Picasso provides an OpenStack API and Keystone authentication layer on top of Oracle Functions.
|
||||
Please refer to the [Picasso on DevStack](https://github.com/openstack/picasso/blob/master/devstack/README.md) guide for setup instructions.
|
||||
|
||||
### Examples
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# User Interface for IronFunctions
|
||||
# User Interface for Oracle Functions
|
||||
|
||||
### Run Functions UI
|
||||
|
||||
```sh
|
||||
docker run --rm -it --link functions:api -p 4000:4000 -e "API_URL=http://api:8080" iron/functions-ui
|
||||
docker run --rm -it --link functions:api -p 4000:4000 -e "API_URL=http://api:8080" treeder/functions-ui
|
||||
```
|
||||
|
||||
For more information, see: https://github.com/treeder/functions-ui
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Windows doesn't support Docker in Docker so you'll change the run command to the following:
|
||||
|
||||
```sh
|
||||
docker run --rm --name functions -it -v /var/run/docker.sock:/var/run/docker.sock -v ${pwd}/data:/app/data -p 8080:8080 iron/functions
|
||||
docker run --rm --name functions -it -v /var/run/docker.sock:/var/run/docker.sock -v ${pwd}/data:/app/data -p 8080:8080 treeder/functions
|
||||
```
|
||||
|
||||
Then everything should work as normal.
|
||||
|
||||
@@ -11,19 +11,13 @@ Once it's pushed to a registry, you can use it by referencing it when adding a r
|
||||
|
||||
This is the easiest way to build, package and deploy your functions.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
##
|
||||
|
||||
### Creating an image
|
||||
|
||||
The basic Dockerfile for most languages is along these lines:
|
||||
|
||||
```
|
||||
# Choose base image
|
||||
FROM iron/go
|
||||
FROM golang:alpine
|
||||
# Set the working directory
|
||||
WORKDIR /function
|
||||
# Add your binary or code to the working directory
|
||||
@@ -35,7 +29,7 @@ ENTRYPOINT ["./funcbin"]
|
||||
Then you simply build your function:
|
||||
|
||||
```sh
|
||||
docker run --rm -v ${pwd}:/go/src/$FUNCPKG -w /go/src/$FUNCPKG iron/go:dev go build -o funcbin
|
||||
docker run --rm -v ${pwd}:/go/src/$FUNCPKG -w /go/src/$FUNCPKG funcy/go:dev go build -o funcbin
|
||||
docker build -t $USERNAME/myfunction .
|
||||
```
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# This is the IronFunctions API spec
|
||||
# This is the Oracle Functions API spec
|
||||
# If you make changes here, remember to run `go generate` in api/models/ and
|
||||
# api/server to make sure you use the changes.
|
||||
|
||||
swagger: '2.0'
|
||||
info:
|
||||
title: IronFunctions
|
||||
title: Oracle Functions
|
||||
description: The open source serverless platform.
|
||||
version: "0.1.29"
|
||||
# the domain of the service
|
||||
|
||||
Reference in New Issue
Block a user