This adds the following commands: - faas-cli - faas-cli help - faas-cli build - faas-cli deploy - faas-cli remove (alias: rm) - faas-cli version - faas-cli push Note that the following is also added but hidden from help pending a more robust bash completion solution, initially using the Cobra generated bash completion but needs spf13/cobra#520 to merge before it'll work on the OSX default Bash 3.x. - faas-cli bashcompletion This commit intercepts the command line args passed to `faas-cli` and attempts to translate them from the deprecated go flag based syntax (`faas-cli -action xxx`) to the new Cobra verb/noun based syntax (`faas-cli xxx`), it also translates a frozen set of legacy flags (with the go-style single-dash) into a GNU style double-dash. Note that some special cases are included: - changing the delete action to remove - passing the function name as a noun to remove rather than as an arg to `-name` - it also handles the legacy format where args are passed after = (`-name=fnname`). If the translation results in a new set of args then a message is displayed to the user (stderr) telling warning that they are using the deprecated cli syntax and also prints the new syntax command that is being executed and which they should use going forward. Any errors thrown during translation result in the command failing with it printing the error cause to stderr. This renames the `fetchTemplates.go` file to use snake case. The convention appears to be for snakecase - as observed in both the Go and Kubernetes source. For example heres a random selection of source files. - https://github.com/kubernetes/kubernetes/blob/master/pkg/kubeapiserver/default_storage_factory_builder.go - https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/bash_comp_utils.go - https://github.com/golang/go/blob/master/src/compress/bzip2/move_to_front.go Note that the language spec does not set a hard rule for source file names, only for package names, but making this change for consistency. Note that this file was initially generated by Cobra, but has been tweaked to include some fixes. It it an experimental initial version. This commit adds some instructions on enabling the `faas-cli` bash auto-completion support. Instructions for Linux users are very light as it differs per-distro and the assumption is that Linux users should be capable of following their Distros instructions on enabling bash completion support. Signed-off-by: John McCabe <john@johnmccabe.net>
2.0 KiB
Manual CLI options
In addition to YAML file support, you can use the CLI to build and deploy individual functions as follows:
Worked example with Node.js
So if you want to write in another language, just prepare a Dockerfile and build an image manually, like in the FaaS samples.
Build a FaaS function in NodeJS from a template:
This will generate a Docker image for a Node.js function using the code in /samples/info.
- The
faas-cli buildcommand can accept a--langoption ofpythonornodeand isnodeby default.
$ faas-cli build \
--image=alexellis2/node_info \
--name=node_info \
--handler=./sample/node_info
Building: alexellis2/node_info with Docker. Please wait..
...
Image: alexellis2/node_info built.
You can customise the code by editing the handler.js file and changing the --handler parameter. You can also edit the packages.json file, which will be used during the build to make sure all your dependencies are available at runtime.
For example:
"use strict"
module.exports = (context, callback) => {
console.log("echo - " + context);
callback(undefined, {status: "done"});
}
The CLI will then build a Docker image containing the FaaS watchdog and a bootstrap file to invoke your NodeJS function.
Deploy the Docker image as a FaaS function:
Now we can deploy the image as a named function called node_info.
$ faas-cli deploy \
--image=alexellis2/node_info \
--name=node_info
200 OK
URL: http://localhost:8080/function/node_info
This tool can be used to deploy any Docker image as a FaaS function, as long as it includes the watchdog binary as the
CMDorENTRYPOINTof the image.
Deploy remotely
You can deploy to a remote FaaS instance as along as you push the image to the Docker Hub, or another accessible Docker registry. Specify your remote gateway with the following flag: --gateway=http://remote-site.com:8080