openfaas / faas-cli

Official CLI for OpenFaaS
https://www.openfaas.com/
Other
798 stars 225 forks source link

faas-cli should be the only thing needed in order to launch openfaas #415

Closed psoares closed 6 years ago

psoares commented 6 years ago

The current mode of deployment of OpenFaas is cumbersome. A "simple" user of the framework needs to checkout the code and run a script. By doing so, he also imports demo functions that he's probably not interested in, and the only way of getting rid of them is to remove them from the docker-compose.yml file located at the root of the project.

This also makes upgrades difficult. The only thing that I would like to have to upgrade would be the faas-cli itself...

Expected Behaviour

As a user of OpenFaas (as opposed to a project contributor), I should be able to run all the required containers by using only the faas-cli. I shouldn't need to checkout the project's source code in order to deploy it.

The usage instructions would then become, for example for MacOS users:

brew install faas-cli
faas-cli start

Upgrading to the latest version of openfaas should involve updating the faas-cli.

e.g.:

brew upgrade faas-cli

Note: this is what is available in the Fn framework.

Current Behaviour

Currently, as a user, I need to checkout the openfaas/faas project and run the deploy_stack.sh script located at the root of the project.

Upgrading to a newer version involves updating the project source code. If you made changes to docker-compose.yml locally (for example to remove unwanted functions), this will result in conflicts.

ericstoekl commented 6 years ago

Derek add label: proposal

ericstoekl commented 6 years ago

This can make sense for deploying locally, but how would you deploy to a remote cluster like GKE? How would it know that it's kubernetes and not docker swarm? This might be useful if it only deploys on docker swarm locally.

alexellis commented 6 years ago

Hi @psoares, thanks for giving us your feedback on the user experience.

While I can see where you are wanting to get with this, I don't think it's right for the project.

The responsibility of the faas-cli mirrors that of the Docker CLI (it wraps docker for some operations).

I already addressed the point of having sample functions built-in on Slack saying that you should delete them. We have an issue going back to Jan 2018 which outlines that we plan to remove the samples from the compose stack - in Kubernetes we have no samples in the default deployment.

https://github.com/openfaas/faas/issues/478

I shouldn't need to checkout the project's source code in order to deploy it.

You don't need to do this, but it is the default way to install projects which use Docker Compose / Docker Swarm. On Kubernetes you can use our Helm chart. I also recommended to you on Slack to use Kubernetes in production rather than Docker Swarm.

Please feel free to share your other suggestions via Slack or if you run into issues via GitHub too.

Alex

alexellis commented 6 years ago

Derek close: non-goal

alexellis commented 6 years ago

If anyone would like to contribute towards creating a separate stack which retains the functions that would be great. The work has been outstanding since January and our Kubernetes flavor already addresses this point.

psoares commented 6 years ago

@ericstoekl Deployment to other platforms could maybe be addressed through an integration of faas-netes with faas-cli ? Meaning faas-cli would be usable for local deployment by default, and with some options for kubernetes?... Anyway, it seems like this is a non goal for the project.