Proposal: Install command

[ewilde]

Goal:

Create a command that installs OpenFaaS in a default configuration suitable for development, proofs of concepts and demonstrations.

The command should support:

• Docker swarm
• Kubernetes

Possible goal:

Design solution that is extensible / pluggable for other provider maintainers. Maybe use something like https://github.com/hashicorp/go-plugin and have the installer for each provider in a separate process, or the faas cli just calls the provider installer:

• install command is invoked
• plugin is downloaded
• plugin invoked either through go-plugin or os/exec

Non-goal:

Implement installation for other providers:

• fargate
• nomad
• etc....

Expected Behaviour

Default

faas-cli install

Installs OpenFaaS on Docker Swarm

Platform argument

faas-cli install -p k8s

or

faas-cli install -p swarm

[stefanprodan]

It would be nice if the command would be interactive, like asking for user/pass, tiller or plain yaml, node port or lb, etc

[matipan]

It would definitely be really helpful for newcomers that are getting started. The ofc-bootstrap experience is really nice since we get a lot out of a single command.

I agree with @stefanprodan. Jenkins X is doing that for their CLI and it's really good

[zeerorg]

Maybe we can add flags and also provide interactive install. So if user just writes faas-cli install we can go ahead with interactive and if flags are provided we use those.

[alexellis]

I am not keen on the interactive idea right now, but I think I could change my mind after I've seen the non-interactive flags or file-driven version.

[alexellis]

There is a straw-man argument going around stating that we cannot possibly offer the user any configuration options, because that would mean we absolutely have to create flags to map every single configuration attribute in the helm chart. I can't see the logic in that.

The core options I would see us needing are:

• LoadBalancer - yes/no
• Operator - yes/no
• Namespace(s) - openfaas/openfaas-fn

If we want to use this for our own development to test PRs then we should be able to override the gateway and controller/operator Docker image.

Stretch goals would be to also install and configure cert-manager with a production and staging issuer with the correct email address. This also implies installing an IngressController.

Reference:

https://github.com/openfaas/workshop/blob/master/lab1b.md

I think we should also retrieve outputs from the install such as:

• basic-auth-password
• gateway URL (if possible)

[LucasRoesler]

When we say a development env, do we mean development OpenFaaS components or for function developers? faas-cli is largely targeted at function developers and it will be cleaner if we keep it that way. Our needs to tinker with settings as OpenFaaS developers is going to be different from most people, we should look at faas-cli providing the base install that we would then override manually anyway. This is, for example, the assumption of the start-kind make target in the faas-netes project. It doesn't let you toggle everything, it does a default install and then the OpenFaaS developer should know how to override it afterward (and we should of course document how to do this for each project/component).

The options mentioned by @alexellis are great, for kubernetes. I don't think they make any sense for swarm. Are there options other than the image tags that we would need for swarm?

Do we allow overriding the image tags for every component? For example, prometheus and alert manager?

I assume we would use the current default values in the helm chart, to answer config questions for each component. That is, faas-cli install -p k8s should effectively be the same as helm install openfaas/openfaas. But with that in mind, do we want to change the default image pull policy to IfNotPresent? This could be good for dev environments and demos

[alexellis]

Controversial idea - what if we only did Kubernetes?

[alexellis]

There are 2-3 personas that I can think of:

• end-user - 1 click install ala Rio / K3s
• platform developer who needs to deploy OpenFaaS in CI or for testing PRs - think BT or our CI/ kind script / ofc-bootstrap
• OpenFaaS contributor - OpenFaaS is basically, cattle not a pet. We install 1-5 times per day that we are active. Possibly to test a PR, to reproduce a user issue, to write a blog or docs page or for feature development. We have fatigue from running 5-10 helm/kubectl commands

[zeerorg]

I do think faas-cli install could be beneficial in a lot of cases for many people, it could take a lot of friction away from getting up and running with the project. Maybe we can start with kubernetes at first and docker can be implemented afterwards ?

Also there are different ways of going about this:

• Using the kubernetes API
• Using helm commands

If we are going to use helm indirectly we might be able to implement all the options that the chart provides.

A --noprompt flag could be used for script and testing use cases. Whereas an involved step by step install could be used for self deployments or demo purposes.

[veggiemonk]

Hi,

I think there is a bit of confusion between install and deploy.

The first one is simply meant for local development and trying things out. The second is meant to be use in a production environment.

For adoption purposes, it would be nice to let people try out OpenFaas in, more or less, the same amount of time it takes to download a container image.

Once the exploration phase is over, deploying it in on a cluster makes more sense.

Those are 2 different use cases and should be treated as such.

These are just ideas, feel free to disregard.

[alexellis]

I would love to see the CLI being able to install cert-manager and Nginx Ingress, so that we can get users up and running with TLS as simply as possible.

It may be that we develop a separate tool to install these, or we call them "add-ons" and use the faas-cli to add them.

[tmiklas]

For me it would be EXTREMELY helpful.

I'm good with docker etc. but kubernetes is just not my cup of tea - unless you know the entire k8s ecosystem, setting it all up just to get OpenFaasS running is still massive PITA. Even more so when you want to expose it fairly reasonably for demo or similar use. Not everyone has the time to learn kubernetes before they can start using OpenFaaS in anger...

Easily deployed load balancer of sorts on ingress with sane default ports (customisable), with TLS (letsencrypt as defult?) support out of the box or option/docs for mutual TLS, etc. would go a very long way.

My ideal simplistic scenario: 1 - install k3s 2 - deploy OpenFaaS 3 - deploy 'add-ons' and to expose OpenFaaS and/or OFC (admin console + functions) with TLS on normal 443/tcp 4 - start working on functions...

Non-interactive wins for me every day - helps with scripting :-)

[jonatasbaldin]

What about adding the cert-manager and nginx-ingress templates into the Helm one as dependencies, enabled/disabled through a flag? It could be at least a nice way to prototype the deployment of the "add ons" through Helm!

[utsavanand2]

Just like the idea behind k3sup, we should go from a function to an endpoint with TLS (Great for developer workflow and for devs not familiar with the underlying platform like Kubernetes). Infact this is what the end goal of our platform should be - from function to an endpoint with TLS.