Workloads

    All workloads must:

    • serve HTTP traffic on TCP port 8080
    • assume ephemeral storage
    • be stateless

    And integrate with a health-check mechanism:

    On Swarm:

    • create a lock file in - removing this file signals service degradation

    On Kubernetes:

    • or enable httpProbe in the helm chart and implement /_/health as a HTTP endpoint
    • create a lock file in /tmp/.lock - removing this file signals service degradation

    If running in read-only mode, then you can write files to the /tmp/ mount only. These files may be accessible upon subsequent requests but it is not guaranteed. For instance - if you have two replicas of a function then both may have different contents in their mount. When running without read-only mode you can write files to the user's home directory subject to the same rules.

    Or build your own templates Git repository and then pass that as an argument to faas-cli template pull

    Custom binaries can also be used as a function. Just use the dockerfile language template and replace the fprocess variable with the command you want to run per request. If you would like to pipe arguments to a CLI utility you can prefix the command with xargs.

    When using Kubernetes, OpenFaaS workloads can assume a ServiceAccount in the namespace in which they are deployed.

    For example if a workload needed to read logs from the Kubernetes API usng a ServiceAccount named function-logs-sa, you could bind it in this way:

    stack.yml

    Here is an example Role that can list pods and work with Pod logs within the namespace:

    An example of a stateless microservice may be an Express.js application using Node.js, a Sinatra app with Ruby or an ASP.NET 2.0 Core website.

    Use of the is optional, but recommended for stateless microservices to provide a consistent experience for timeouts, logging and configuration.

    On Kubernetes is possible to run any container image as an OpenFaaS function as long as your application exposes port 8080 and has a HTTP health check endpoint.

    Custom HTTP health check

    You can specify the HTTP path of your health check and the initial check delay duration with the following annotations:

    • com.openfaas.health.http.path
    • om.openfaas.health.http.initialDelay

    Stack file example:

    Note: The initial delay value must be a valid Go duration e.g. 80s or 3m.